Peut-on, par liaison ssh récupérer l'écran d'une session tty
lors du boot peut-on récupérer (après démarrage de sshd bien entendu) la
session de boot pour pouvoir répondre aux demandes éventuelles.
Peut-on, par liaison ssh récupérer l'écran d'une session tty
lors du boot peut-on récupérer (après démarrage de sshd bien entendu) la
session de boot pour pouvoir répondre aux demandes éventuelles.
Peut-on, par liaison ssh récupérer l'écran d'une session tty
lors du boot peut-on récupérer (après démarrage de sshd bien entendu) la
session de boot pour pouvoir répondre aux demandes éventuelles.
On Sun, Nov 28, 2004 at 11:16:05AM +0100, "hervé t." wrote:Peut-on, par liaison ssh récupérer l'écran d'une session tty
Si tu veux dire « se réattacher à un tty qui tourne sur une
autre machine », oui, regarde le programme screen.lors du boot peut-on récupérer (après démarrage de sshd bien entendu) la
session de boot pour pouvoir répondre aux demandes éventuelles.
session de boot? Je ne comprend pas la question.
Y.
On Sun, Nov 28, 2004 at 11:16:05AM +0100, "hervé t." wrote:
Peut-on, par liaison ssh récupérer l'écran d'une session tty
Si tu veux dire « se réattacher à un tty qui tourne sur une
autre machine », oui, regarde le programme screen.
lors du boot peut-on récupérer (après démarrage de sshd bien entendu) la
session de boot pour pouvoir répondre aux demandes éventuelles.
session de boot? Je ne comprend pas la question.
Y.
On Sun, Nov 28, 2004 at 11:16:05AM +0100, "hervé t." wrote:Peut-on, par liaison ssh récupérer l'écran d'une session tty
Si tu veux dire « se réattacher à un tty qui tourne sur une
autre machine », oui, regarde le programme screen.lors du boot peut-on récupérer (après démarrage de sshd bien entendu) la
session de boot pour pouvoir répondre aux demandes éventuelles.
session de boot? Je ne comprend pas la question.
Y.
>[...]
Non, je ne parle pas d'utiliser "screen". Ce que je veux c'est savoir si
on peut prendre la main à partir d'un ssh sur une autre session en cours
notamment récupérer la main sur le déroulement du boot par ce que l a
machine est en attente d'une information à valider. La seule chose que
je trouve c'est se connecter en root (mon login habituel étant refusé
pendant le boot), lister les process pour détruire celui qui bloque la
fin d'exécution du boot, relancer le process pour répondre à la que stion
demandée. Dans mon cas il ne s'agit que d'une demande de phrase clef
pour l'authentification bidon "ssl" avec "apache2" et ça bloque le
"boot" alors qu'on vient de déclencher a distance un "reboot". Donc
récupérer à distance l'écran du "boot" serait idéal dans la pra tique.
Peut-être est-il idiot de croire qu'une telle solution est possible?
>[...]
Non, je ne parle pas d'utiliser "screen". Ce que je veux c'est savoir si
on peut prendre la main à partir d'un ssh sur une autre session en cours
notamment récupérer la main sur le déroulement du boot par ce que l a
machine est en attente d'une information à valider. La seule chose que
je trouve c'est se connecter en root (mon login habituel étant refusé
pendant le boot), lister les process pour détruire celui qui bloque la
fin d'exécution du boot, relancer le process pour répondre à la que stion
demandée. Dans mon cas il ne s'agit que d'une demande de phrase clef
pour l'authentification bidon "ssl" avec "apache2" et ça bloque le
"boot" alors qu'on vient de déclencher a distance un "reboot". Donc
récupérer à distance l'écran du "boot" serait idéal dans la pra tique.
Peut-être est-il idiot de croire qu'une telle solution est possible?
>[...]
Non, je ne parle pas d'utiliser "screen". Ce que je veux c'est savoir si
on peut prendre la main à partir d'un ssh sur une autre session en cours
notamment récupérer la main sur le déroulement du boot par ce que l a
machine est en attente d'une information à valider. La seule chose que
je trouve c'est se connecter en root (mon login habituel étant refusé
pendant le boot), lister les process pour détruire celui qui bloque la
fin d'exécution du boot, relancer le process pour répondre à la que stion
demandée. Dans mon cas il ne s'agit que d'une demande de phrase clef
pour l'authentification bidon "ssl" avec "apache2" et ça bloque le
"boot" alors qu'on vient de déclencher a distance un "reboot". Donc
récupérer à distance l'écran du "boot" serait idéal dans la pra tique.
Peut-être est-il idiot de croire qu'une telle solution est possible?
Sun, 28 Nov 2004 17:16:33 +0100, hervé t. a écrit :[...]
Non, je ne parle pas d'utiliser "screen". Ce que je veux c'est savoir si
on peut prendre la main à partir d'un ssh sur une autre session en cours
notamment récupérer la main sur le déroulement du boot par ce que la
machine est en attente d'une information à valider. La seule chose que
je trouve c'est se connecter en root (mon login habituel étant refusé
pendant le boot), lister les process pour détruire celui qui bloque la
fin d'exécution du boot, relancer le process pour répondre à la question
demandée. Dans mon cas il ne s'agit que d'une demande de phrase clef
pour l'authentification bidon "ssl" avec "apache2" et ça bloque le
"boot" alors qu'on vient de déclencher a distance un "reboot". Donc
récupérer à distance l'écran du "boot" serait idéal dans la pratique.
Peut-être est-il idiot de croire qu'une telle solution est possible?
Je crois avoir vu passé quelque chose à ce sujet. Je ne sais plus si
c'était dans la Debian Weekly News ou ailleurs (désolé, Aloïs Alzheimer a
encore frappé) mais il doit exister un patch pour le noyau qui permettrait
d'avoir une « console réseau » dès le démarrage, de la même façon que l'on
peut avoir une console série ou parallèle. Reste à retrouver ça et à voir
comment ça fonctionne...
Sun, 28 Nov 2004 17:16:33 +0100, hervé t. a écrit :
[...]
Non, je ne parle pas d'utiliser "screen". Ce que je veux c'est savoir si
on peut prendre la main à partir d'un ssh sur une autre session en cours
notamment récupérer la main sur le déroulement du boot par ce que la
machine est en attente d'une information à valider. La seule chose que
je trouve c'est se connecter en root (mon login habituel étant refusé
pendant le boot), lister les process pour détruire celui qui bloque la
fin d'exécution du boot, relancer le process pour répondre à la question
demandée. Dans mon cas il ne s'agit que d'une demande de phrase clef
pour l'authentification bidon "ssl" avec "apache2" et ça bloque le
"boot" alors qu'on vient de déclencher a distance un "reboot". Donc
récupérer à distance l'écran du "boot" serait idéal dans la pratique.
Peut-être est-il idiot de croire qu'une telle solution est possible?
Je crois avoir vu passé quelque chose à ce sujet. Je ne sais plus si
c'était dans la Debian Weekly News ou ailleurs (désolé, Aloïs Alzheimer a
encore frappé) mais il doit exister un patch pour le noyau qui permettrait
d'avoir une « console réseau » dès le démarrage, de la même façon que l'on
peut avoir une console série ou parallèle. Reste à retrouver ça et à voir
comment ça fonctionne...
Sun, 28 Nov 2004 17:16:33 +0100, hervé t. a écrit :[...]
Non, je ne parle pas d'utiliser "screen". Ce que je veux c'est savoir si
on peut prendre la main à partir d'un ssh sur une autre session en cours
notamment récupérer la main sur le déroulement du boot par ce que la
machine est en attente d'une information à valider. La seule chose que
je trouve c'est se connecter en root (mon login habituel étant refusé
pendant le boot), lister les process pour détruire celui qui bloque la
fin d'exécution du boot, relancer le process pour répondre à la question
demandée. Dans mon cas il ne s'agit que d'une demande de phrase clef
pour l'authentification bidon "ssl" avec "apache2" et ça bloque le
"boot" alors qu'on vient de déclencher a distance un "reboot". Donc
récupérer à distance l'écran du "boot" serait idéal dans la pratique.
Peut-être est-il idiot de croire qu'une telle solution est possible?
Je crois avoir vu passé quelque chose à ce sujet. Je ne sais plus si
c'était dans la Debian Weekly News ou ailleurs (désolé, Aloïs Alzheimer a
encore frappé) mais il doit exister un patch pour le noyau qui permettrait
d'avoir une « console réseau » dès le démarrage, de la même façon que l'on
peut avoir une console série ou parallèle. Reste à retrouver ça et à voir
comment ça fonctionne...
>>demandée. Dans mon cas il ne s'agit que d'une demande de phrase clef
>>pour l'authentification bidon "ssl" avec "apache2"
>>Peut-être est-il idiot de croire qu'une telle solution est possible?
>de la même façon que l'on peut avoir une console série ou
>parallèle.
Quelqu'un a-t-il une idée sur les références d'une telle solution?
>>demandée. Dans mon cas il ne s'agit que d'une demande de phrase clef
>>pour l'authentification bidon "ssl" avec "apache2"
>>Peut-être est-il idiot de croire qu'une telle solution est possible?
>de la même façon que l'on peut avoir une console série ou
>parallèle.
Quelqu'un a-t-il une idée sur les références d'une telle solution?
>>demandée. Dans mon cas il ne s'agit que d'une demande de phrase clef
>>pour l'authentification bidon "ssl" avec "apache2"
>>Peut-être est-il idiot de croire qu'une telle solution est possible?
>de la même façon que l'on peut avoir une console série ou
>parallèle.
Quelqu'un a-t-il une idée sur les références d'une telle solution?
On Tue, Nov 30, 2004 at 09:21:04AM +0100, "hervé t." wrote:
> >>demandée. Dans mon cas il ne s'agit que d'une demande de phrase clef
> >>pour l'authentification bidon "ssl" avec "apache2"
La solution évidente serait évidement de réparer le boot
pour que ça ne s'arrète plus? Personellement, je pense
qu'une séquence de boot qui s'arrète sans raison valable
(disque cassé, alim en feu, etc) est un bug.
> >>Peut-être est-il idiot de croire qu'une telle solution est possible?
Non non. J'avais pas compris la question :-)
> >de la même façon que l'on peut avoir une console série ou
> >parallèle.
C'est ce que je fais personellement pour deux machines qui
n'ont pas de consoles: il y a un PC à coté avec des cables
séries, et je fais tourner minicom par ssh (je peux donc
voir un prompt du bootloader de l'autre coté de la planète).
> Quelqu'un a-t-il une idée sur les références d'une telle solution?
Sans patcher le noyau, et en revenant à screen, je viens de
me demander ce qu'il se passerait en changeant la ligne de
paramètres du noyau avec qqch du genre:
init="/usr/bin/screen /sbin/init"
?
Ou bien (peut-être plus raisonnable) dans /etc/inittab,
changer:
l2:2:wait:/etc/init.d/rc 2
en
l2:2:wait:/usr/bin/screen /etc/init.d/rc 2
Je n'ai essayé ni l'un ni l'autre, n'ayant pas de machine à
rebooter sous la main...
Y.
On Tue, Nov 30, 2004 at 09:21:04AM +0100, "hervé t." wrote:
> >>demandée. Dans mon cas il ne s'agit que d'une demande de phrase clef
> >>pour l'authentification bidon "ssl" avec "apache2"
La solution évidente serait évidement de réparer le boot
pour que ça ne s'arrète plus? Personellement, je pense
qu'une séquence de boot qui s'arrète sans raison valable
(disque cassé, alim en feu, etc) est un bug.
> >>Peut-être est-il idiot de croire qu'une telle solution est possible?
Non non. J'avais pas compris la question :-)
> >de la même façon que l'on peut avoir une console série ou
> >parallèle.
C'est ce que je fais personellement pour deux machines qui
n'ont pas de consoles: il y a un PC à coté avec des cables
séries, et je fais tourner minicom par ssh (je peux donc
voir un prompt du bootloader de l'autre coté de la planète).
> Quelqu'un a-t-il une idée sur les références d'une telle solution?
Sans patcher le noyau, et en revenant à screen, je viens de
me demander ce qu'il se passerait en changeant la ligne de
paramètres du noyau avec qqch du genre:
init="/usr/bin/screen /sbin/init"
?
Ou bien (peut-être plus raisonnable) dans /etc/inittab,
changer:
l2:2:wait:/etc/init.d/rc 2
en
l2:2:wait:/usr/bin/screen /etc/init.d/rc 2
Je n'ai essayé ni l'un ni l'autre, n'ayant pas de machine à
rebooter sous la main...
Y.
On Tue, Nov 30, 2004 at 09:21:04AM +0100, "hervé t." wrote:
> >>demandée. Dans mon cas il ne s'agit que d'une demande de phrase clef
> >>pour l'authentification bidon "ssl" avec "apache2"
La solution évidente serait évidement de réparer le boot
pour que ça ne s'arrète plus? Personellement, je pense
qu'une séquence de boot qui s'arrète sans raison valable
(disque cassé, alim en feu, etc) est un bug.
> >>Peut-être est-il idiot de croire qu'une telle solution est possible?
Non non. J'avais pas compris la question :-)
> >de la même façon que l'on peut avoir une console série ou
> >parallèle.
C'est ce que je fais personellement pour deux machines qui
n'ont pas de consoles: il y a un PC à coté avec des cables
séries, et je fais tourner minicom par ssh (je peux donc
voir un prompt du bootloader de l'autre coté de la planète).
> Quelqu'un a-t-il une idée sur les références d'une telle solution?
Sans patcher le noyau, et en revenant à screen, je viens de
me demander ce qu'il se passerait en changeant la ligne de
paramètres du noyau avec qqch du genre:
init="/usr/bin/screen /sbin/init"
?
Ou bien (peut-être plus raisonnable) dans /etc/inittab,
changer:
l2:2:wait:/etc/init.d/rc 2
en
l2:2:wait:/usr/bin/screen /etc/init.d/rc 2
Je n'ai essayé ni l'un ni l'autre, n'ayant pas de machine à
rebooter sous la main...
Y.
[...]
Merci de cette info. J'ai posé la question en ayant beaucoup de doutes
par rapport aux problèmes de sécurité.à surmonter.
Quelqu'un a-t-il une idée sur les références d'une telle solution?
[...]
Merci de cette info. J'ai posé la question en ayant beaucoup de doutes
par rapport aux problèmes de sécurité.à surmonter.
Quelqu'un a-t-il une idée sur les références d'une telle solution?
[...]
Merci de cette info. J'ai posé la question en ayant beaucoup de doutes
par rapport aux problèmes de sécurité.à surmonter.
Quelqu'un a-t-il une idée sur les références d'une telle solution?