lancer startx automatiquement au boot ( autologin sans truc-dm ;-)
10 réponses
Philippe Weill
bonjour
je cherche à lancer automatiquement un startx sous un utilisateur particulier
directement au boot sans utiliser kdm ou gdm sur une mandriva 2008.1
en faisant du style :
su - user -c ' startx ' directement dans l'inittab
on se heurte au probleme de droit sur la console ( udev et pam ) et
là je doit dire que je ne trouve pas
[root@dhcp-58 init.d]# su vmplayer -c 'startx :0'
xauth: creating new authority file /home/vmplayer/.serverauth.5787
Authentication failed - cannot start X server.
Perhaps you do not have console ownership?giving up.
Autre possibilité: kdm et gdm peuvent connecter automatiquement un utilisateur sous X au démarrage.
A+ JF
Philippe Weill
Cumbalero wrote:
effectivement merci pour la solution
Autre possibilité: kdm et gdm peuvent connecter automatiquement un utilisateur sous X au démarrage.
kdm et gdm font partie de truc-dm ;-) dont je me passerais bien car c'est au minimum une centaine de packages supplémentaires sur la distribution de base alors que l'on utilise xfce4.4 comme window manager
pour donner quelques précisions , c'est un projet de virtualisation d'OS sur poste de travail pour un organisme de formation
A+ JF
Cumbalero wrote:
effectivement merci pour la solution
Autre possibilité: kdm et gdm peuvent connecter automatiquement un
utilisateur sous X au démarrage.
kdm et gdm font partie de truc-dm ;-) dont je me passerais bien
car c'est au minimum une centaine de packages supplémentaires sur la
distribution de base alors que l'on utilise xfce4.4 comme window manager
pour donner quelques précisions , c'est un projet de virtualisation d'OS sur
poste de travail pour un organisme de formation
Autre possibilité: kdm et gdm peuvent connecter automatiquement un utilisateur sous X au démarrage.
kdm et gdm font partie de truc-dm ;-) dont je me passerais bien car c'est au minimum une centaine de packages supplémentaires sur la distribution de base alors que l'on utilise xfce4.4 comme window manager
pour donner quelques précisions , c'est un projet de virtualisation d'OS sur poste de travail pour un organisme de formation
A+ JF
Nicolas George
Luc Habert wrote in message <funl94$6i0$:
/sbin/getty -n -l /root/login-startx 38400 tty1
Ça va Hector ?
C'est quand même ultimement beurk, comme solution. Ça monopolise une console virtuelle, et ce uniquement pour le plaisir de permettre à n'importe qui de flinguer le serveur X11 par erreur d'un simple Ctrl-C.
La solution correcte à la question initiale, c'est de lancer le serveur X11 avec les droits de root (de toutes façons il en a besoin), et de perdre les privilèges ensuite. Donc quelque chose comme :
Avec dans /etc/vmplayer/xinitrc-root quelque chose comme :
exec env -i su vmplayer -c "exec /etc/vmplayer/xinitrc"
(Je conseille fortement, une fois que tout est en place et fonctionne, de faire un « ps auxwwf | less -S » et de regarder s'il ne reste pas des « sh -c » un peu partout, et si c'est le cas de les enlever en ajoutant un exec là où il faut.)
Le plus dur dans l'histoire, c'est de créer un fichier d'autorisation et de le passer à la fois au client et au serveur. Ici, c'est assez facile, parce que le client ne fait que ça, donc il n'est pas nécessaire de faire attention aux autres autorisations déjà présentes. On peut donc faire quelque chose comme :
- passé en argument au serveur X11 avec l'option -auth ;
- passé aux clients, soit en le désignant par la variable d'environnement XAUTHORITY, soit en le copiant dans ~/.Xauthority (la seconde solution étant plus robuste).
Il faut évidemment faire attention aux droits pour que les cookies restent confidentiels.
Luc Habert wrote in message <funl94$6i0$1@nef.ens.fr>:
/sbin/getty -n -l /root/login-startx 38400 tty1
Ça va Hector ?
C'est quand même ultimement beurk, comme solution. Ça monopolise une console
virtuelle, et ce uniquement pour le plaisir de permettre à n'importe qui de
flinguer le serveur X11 par erreur d'un simple Ctrl-C.
La solution correcte à la question initiale, c'est de lancer le serveur X11
avec les droits de root (de toutes façons il en a besoin), et de perdre les
privilèges ensuite. Donc quelque chose comme :
Avec dans /etc/vmplayer/xinitrc-root quelque chose comme :
exec env -i su vmplayer -c "exec /etc/vmplayer/xinitrc"
(Je conseille fortement, une fois que tout est en place et fonctionne, de
faire un « ps auxwwf | less -S » et de regarder s'il ne reste pas des « sh
-c » un peu partout, et si c'est le cas de les enlever en ajoutant un exec
là où il faut.)
Le plus dur dans l'histoire, c'est de créer un fichier d'autorisation et de
le passer à la fois au client et au serveur. Ici, c'est assez facile, parce
que le client ne fait que ça, donc il n'est pas nécessaire de faire
attention aux autres autorisations déjà présentes. On peut donc faire
quelque chose comme :
- passé en argument au serveur X11 avec l'option -auth ;
- passé aux clients, soit en le désignant par la variable d'environnement
XAUTHORITY, soit en le copiant dans ~/.Xauthority (la seconde solution
étant plus robuste).
Il faut évidemment faire attention aux droits pour que les cookies restent
confidentiels.
C'est quand même ultimement beurk, comme solution. Ça monopolise une console virtuelle, et ce uniquement pour le plaisir de permettre à n'importe qui de flinguer le serveur X11 par erreur d'un simple Ctrl-C.
La solution correcte à la question initiale, c'est de lancer le serveur X11 avec les droits de root (de toutes façons il en a besoin), et de perdre les privilèges ensuite. Donc quelque chose comme :
Avec dans /etc/vmplayer/xinitrc-root quelque chose comme :
exec env -i su vmplayer -c "exec /etc/vmplayer/xinitrc"
(Je conseille fortement, une fois que tout est en place et fonctionne, de faire un « ps auxwwf | less -S » et de regarder s'il ne reste pas des « sh -c » un peu partout, et si c'est le cas de les enlever en ajoutant un exec là où il faut.)
Le plus dur dans l'histoire, c'est de créer un fichier d'autorisation et de le passer à la fois au client et au serveur. Ici, c'est assez facile, parce que le client ne fait que ça, donc il n'est pas nécessaire de faire attention aux autres autorisations déjà présentes. On peut donc faire quelque chose comme :
- passé en argument au serveur X11 avec l'option -auth ;
- passé aux clients, soit en le désignant par la variable d'environnement XAUTHORITY, soit en le copiant dans ~/.Xauthority (la seconde solution étant plus robuste).
Il faut évidemment faire attention aux droits pour que les cookies restent confidentiels.
Erwan David
Philippe Weill écrivait :
Cumbalero wrote:
effectivement merci pour la solution
Autre possibilité: kdm et gdm peuvent connecter automatiquement un utilisateur sous X au démarrage.
kdm et gdm font partie de truc-dm ;-) dont je me passerais bien car c'est au minimum une centaine de packages supplémentaires sur la distribution de base alors que l'on utilise xfce4.4 comme window manager
xdm est NETTEMENT plus léger.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Philippe Weill <Philippe.Weill@aero.jussieu.fr> écrivait :
Cumbalero wrote:
effectivement merci pour la solution
Autre possibilité: kdm et gdm peuvent connecter automatiquement un
utilisateur sous X au démarrage.
kdm et gdm font partie de truc-dm ;-) dont je me passerais bien
car c'est au minimum une centaine de packages supplémentaires sur la
distribution de base alors que l'on utilise xfce4.4 comme window
manager
xdm est NETTEMENT plus léger.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Autre possibilité: kdm et gdm peuvent connecter automatiquement un utilisateur sous X au démarrage.
kdm et gdm font partie de truc-dm ;-) dont je me passerais bien car c'est au minimum une centaine de packages supplémentaires sur la distribution de base alors que l'on utilise xfce4.4 comme window manager
xdm est NETTEMENT plus léger.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Philippe Weill
Erwan David wrote:
xdm est NETTEMENT plus léger.
oui mais il ne fait pas à ma connaissance d'autologin
Erwan David wrote:
xdm est NETTEMENT plus léger.
oui mais il ne fait pas à ma connaissance d'autologin
oui mais il ne fait pas à ma connaissance d'autologin
Nicolas George
Nicolas George wrote in message <48104973$0$23617$:
- passé en argument au serveur X11 avec l'option -auth ;
- passé aux clients, soit en le désignant par la variable d'environnement XAUTHORITY, soit en le copiant dans ~/.Xauthority (la seconde solution étant plus robuste).
Petite précision : il faut en particulier qu'il soit passé à xinit lui-même. Donc si on a deux exemplaires du fichier :
/var/lib/vmplayer/Xauthority (privé pour root) /home/vmplayer/.Xauthority (privé pour vmplayer)
le mieux est de mettre XAUTHORITY=/var/lib/vmplayer/Xauthority dans l'environnement avant de lancer xinit. L'« env -i » se chargera de l'enlever un peu plus tard.
Nicolas George wrote in message
<48104973$0$23617$426a74cc@news.free.fr>:
- passé en argument au serveur X11 avec l'option -auth ;
- passé aux clients, soit en le désignant par la variable d'environnement
XAUTHORITY, soit en le copiant dans ~/.Xauthority (la seconde solution
étant plus robuste).
Petite précision : il faut en particulier qu'il soit passé à xinit lui-même.
Donc si on a deux exemplaires du fichier :
/var/lib/vmplayer/Xauthority (privé pour root)
/home/vmplayer/.Xauthority (privé pour vmplayer)
le mieux est de mettre XAUTHORITY=/var/lib/vmplayer/Xauthority dans
l'environnement avant de lancer xinit. L'« env -i » se chargera de l'enlever
un peu plus tard.
Nicolas George wrote in message <48104973$0$23617$:
- passé en argument au serveur X11 avec l'option -auth ;
- passé aux clients, soit en le désignant par la variable d'environnement XAUTHORITY, soit en le copiant dans ~/.Xauthority (la seconde solution étant plus robuste).
Petite précision : il faut en particulier qu'il soit passé à xinit lui-même. Donc si on a deux exemplaires du fichier :
/var/lib/vmplayer/Xauthority (privé pour root) /home/vmplayer/.Xauthority (privé pour vmplayer)
le mieux est de mettre XAUTHORITY=/var/lib/vmplayer/Xauthority dans l'environnement avant de lancer xinit. L'« env -i » se chargera de l'enlever un peu plus tard.
Philippe Weill
Nicolas George wrote:
Luc Habert wrote in message <funl94$6i0$:
/sbin/getty -n -l /root/login-startx 38400 tty1
Ça va Hector ?
C'est quand même ultimement beurk, comme solution. Ça monopolise une console virtuelle, et ce uniquement pour le plaisir de permettre à n'importe qui de flinguer le serveur X11 par erreur d'un simple Ctrl-C.
bon pour l'instant je dois avancer sur d'autres choses donc j'en reste à la solution qui monopolise une console avec tout de même quelques modifications
.bash_profile de vmplayer ( appartenant à root ) if [ "`tty`" = "/dev/tty6" ] then trap "" SIGINT startx exit fi
j'exporerais l'autre piste plus tard
La solution correcte à la question initiale, c'est de lancer le serveur X11 avec les droits de root (de toutes façons il en a besoin), et de perdre les privilèges ensuite. Donc quelque chose comme :
Avec dans /etc/vmplayer/xinitrc-root quelque chose comme :
exec env -i su vmplayer -c "exec /etc/vmplayer/xinitrc"
(Je conseille fortement, une fois que tout est en place et fonctionne, de faire un « ps auxwwf | less -S » et de regarder s'il ne reste pas des « sh -c » un peu partout, et si c'est le cas de les enlever en ajoutant un exec là où il faut.)
Le plus dur dans l'histoire, c'est de créer un fichier d'autorisation et de le passer à la fois au client et au serveur. Ici, c'est assez facile, parce que le client ne fait que ça, donc il n'est pas nécessaire de faire attention aux autres autorisations déjà présentes. On peut donc faire quelque chose comme :
- passé en argument au serveur X11 avec l'option -auth ;
- passé aux clients, soit en le désignant par la variable d'environnement XAUTHORITY, soit en le copiant dans ~/.Xauthority (la seconde solution étant plus robuste).
Il faut évidemment faire attention aux droits pour que les cookies restent confidentiels.
Nicolas George wrote:
Luc Habert wrote in message <funl94$6i0$1@nef.ens.fr>:
/sbin/getty -n -l /root/login-startx 38400 tty1
Ça va Hector ?
C'est quand même ultimement beurk, comme solution. Ça monopolise une console
virtuelle, et ce uniquement pour le plaisir de permettre à n'importe qui de
flinguer le serveur X11 par erreur d'un simple Ctrl-C.
bon pour l'instant je dois avancer sur d'autres choses donc j'en reste à la
solution qui monopolise une console avec tout de même quelques modifications
.bash_profile de vmplayer ( appartenant à root )
if [ "`tty`" = "/dev/tty6" ]
then
trap "" SIGINT
startx
exit
fi
j'exporerais l'autre piste plus tard
La solution correcte à la question initiale, c'est de lancer le serveur X11
avec les droits de root (de toutes façons il en a besoin), et de perdre les
privilèges ensuite. Donc quelque chose comme :
Avec dans /etc/vmplayer/xinitrc-root quelque chose comme :
exec env -i su vmplayer -c "exec /etc/vmplayer/xinitrc"
(Je conseille fortement, une fois que tout est en place et fonctionne, de
faire un « ps auxwwf | less -S » et de regarder s'il ne reste pas des « sh
-c » un peu partout, et si c'est le cas de les enlever en ajoutant un exec
là où il faut.)
Le plus dur dans l'histoire, c'est de créer un fichier d'autorisation et de
le passer à la fois au client et au serveur. Ici, c'est assez facile, parce
que le client ne fait que ça, donc il n'est pas nécessaire de faire
attention aux autres autorisations déjà présentes. On peut donc faire
quelque chose comme :
- passé en argument au serveur X11 avec l'option -auth ;
- passé aux clients, soit en le désignant par la variable d'environnement
XAUTHORITY, soit en le copiant dans ~/.Xauthority (la seconde solution
étant plus robuste).
Il faut évidemment faire attention aux droits pour que les cookies restent
confidentiels.
C'est quand même ultimement beurk, comme solution. Ça monopolise une console virtuelle, et ce uniquement pour le plaisir de permettre à n'importe qui de flinguer le serveur X11 par erreur d'un simple Ctrl-C.
bon pour l'instant je dois avancer sur d'autres choses donc j'en reste à la solution qui monopolise une console avec tout de même quelques modifications
.bash_profile de vmplayer ( appartenant à root ) if [ "`tty`" = "/dev/tty6" ] then trap "" SIGINT startx exit fi
j'exporerais l'autre piste plus tard
La solution correcte à la question initiale, c'est de lancer le serveur X11 avec les droits de root (de toutes façons il en a besoin), et de perdre les privilèges ensuite. Donc quelque chose comme :
Avec dans /etc/vmplayer/xinitrc-root quelque chose comme :
exec env -i su vmplayer -c "exec /etc/vmplayer/xinitrc"
(Je conseille fortement, une fois que tout est en place et fonctionne, de faire un « ps auxwwf | less -S » et de regarder s'il ne reste pas des « sh -c » un peu partout, et si c'est le cas de les enlever en ajoutant un exec là où il faut.)
Le plus dur dans l'histoire, c'est de créer un fichier d'autorisation et de le passer à la fois au client et au serveur. Ici, c'est assez facile, parce que le client ne fait que ça, donc il n'est pas nécessaire de faire attention aux autres autorisations déjà présentes. On peut donc faire quelque chose comme :
- passé en argument au serveur X11 avec l'option -auth ;
- passé aux clients, soit en le désignant par la variable d'environnement XAUTHORITY, soit en le copiant dans ~/.Xauthority (la seconde solution étant plus robuste).
Il faut évidemment faire attention aux droits pour que les cookies restent confidentiels.
Kevin Denis
On 2008-04-24, Philippe Weill wrote:
xdm est NETTEMENT plus léger.
oui mais il ne fait pas à ma connaissance d'autologin
xdm lance xlogin et le fichier Xsetup. xlogin est récupéré depuis le
Xresources. Je suis quasiment sur qu'il y a moyen de tweaker soit le Resources, soit le Xsetup pour t'autologuer. Mais la syntaxe, c'est pas simple à comprendre. -- Kevin
On 2008-04-24, Philippe Weill <Philippe.Weill@aero.jussieu.fr> wrote:
xdm est NETTEMENT plus léger.
oui mais il ne fait pas à ma connaissance d'autologin
xdm lance xlogin et le fichier Xsetup. xlogin est récupéré depuis le
Xresources.
Je suis quasiment sur qu'il y a moyen de tweaker soit le Resources,
soit le Xsetup pour t'autologuer.
Mais la syntaxe, c'est pas simple à comprendre.
--
Kevin
oui mais il ne fait pas à ma connaissance d'autologin
xdm lance xlogin et le fichier Xsetup. xlogin est récupéré depuis le
Xresources. Je suis quasiment sur qu'il y a moyen de tweaker soit le Resources, soit le Xsetup pour t'autologuer. Mais la syntaxe, c'est pas simple à comprendre. -- Kevin
