* Jean-Charles Giardina: > Tu devrais cr�er un fichier "/etc/init.d/mon_robot" contenant : > > #!/bin/sh > su - robot -c /usr/local/bin/monrobot.pl > > Ou "robot" est le login de ton user et "/usr/local/bin/monrobot.pl" le > programme de ton robot. > > Cette technique a pour effet de laisser ton ordi en mode non-connect� > Se qui est bien plus s�cruris�.
J'imagine que ce script sera lanc� vers la fin du processus de boot. D'un c�t�, c'est "boot -> init scripts (en root) -> (su user) programme du robot", de l'autre c'est "boot -> init scripts -> getty/login (en root) -> ([auto]login user) programme du robot". D'un c�t�, c'est su qui change d'utilisateur, de l'autre c'est *getty. Tout �a pour dire, ce n'est pas tr�s diff�rent. En passant, pourquoi dis-tu que la solution par script /etc/init.d est plus s�curis� ? Sinon, quelques remarques : Il faut faire attention � ce que le script d'init se termine, pour ne pas bloquer le boot. Par ailleurs, l'autologin permet � peu de frais de relancer le programme automatiquement si jamais il se termine (parfois c'est souhaitable, parfois non). Enfin, l'environnement dans lequel s'ex�cute le programme est exactement le m�me que celui d'un utilisateur lambda - en particulier, avec des entr�es/sorties et une console accessible (enfin, �a d�pend du mat�riel...). �a peut �tre pratique pour le d�veloppement, pour utiliser un debugger par exemple. Si il y a un truc que j'ai appris en d�veloppement embarqu�, c'est l'importance de pouvoir debugger sur machine cible. Une autre solution est de lancer directement le programme depuis init (i.e. de le mettre � la place du getty dans inittab), ce qui permet de lui donner acc�s � une console et d'obtenir le respawn. C'est cependant moins flexible en d�veloppement. -- ubuntu-fr mailing list [email protected] http://lists.ubuntu.com/mailman/listinfo/ubuntu-fr
