login au demarrage en console

[Raphaël Berbain]

* 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.