Initialisera 1 à partir d'une session ssh distante (via VPN) tuera ma connexion ssh

Solution 1 :

Oui, oui. La plupart des services ne s'exécutent pas au niveau d'exécution 1.

Solution 2 :

Ça devrait aller. Alors que le démon d'écoute SSH est arrêté au niveau d'exécution 1 sur la plupart des distributions, les connexions existantes doivent rester actives et le réseau ne doit pas être affecté. Je ne le ferais pas sans avoir une sorte de console distante connectée, cependant - vous ne savez jamais quand une éruption solaire malveillante va arriver et interrompre vos connexions réseau juste assez longtemps pour tuer votre session SSH.

MODIFIER :Certains tests indiquent que, sur les systèmes Debian au moins, /etc/rc1.d/S30killprocs supprimera les connexions SSH existantes (car cela tue tout). Je serais enclin à manipuler temporairement ce script et à faire son travail à la main (en évitant les connexions SSH) si j'essayais de faire ce que vous voulez faire. Je préférerais quand même utiliser une console distante.

Solution 3 :

Désolé de revenir après si longtemps.J'avais besoin d'une réponse à cette même question.Les réponses actuelles ne correspondent pas à ma boîte.Mes résultats concernent l'installation basée sur Centos 5.11.

1. La raison pour laquelle le client ssh est déconnecté est que init 1 fait quelque chose comme service network stop .Ce que j'observe, c'est que toutes les interfaces réseau tombent en panne et ne sont pas configurées.ip a et ifconfig -a confirmez ceci.

2. init 1 arrête sshd processus d'écoute.Il n'arrête pas sshd processus enfant qui détient la session pour le client connecté. La session ssh finit par être abandonnée en raison du délai d'attente TCP car le réseau tombe en panne, la session ssh n'est pas tuée. Si je rétablis le réseau service network start à la console assez rapidement alors mes clients restent connectés même si la box est au niveau d'exécution 1.

3. La question mentionne le VPN. Si le serveur VPN auquel vous vous dirigez est sur la boîte où vous faites init 1 alors oui, vous serez normalement déconnecté car le serveur VPN par défaut ne fonctionnera PAS au niveau d'exécution 1.

Mon travail pour faire passer le système au niveau d'exécution 1 sans perdre les sessions ssh, consiste à configurer temporairement les services requis pour continuer à fonctionner au niveau d'exécution 1. Tous basés sur Centos 5.11.YMMV.Avertissement : Je ne voudrais pas compter sur cela pour travailler.

    # keep network interfaces up
    chkconfig --level 1 network on
    # if you are connecting though VPN e.g. OpenVPN running on same server
    chkconfig --level 1 openvpn on
    # While at it, might as well keep SSHD running, so you can reconnect
    chkconfig --level 1 sshd on

    init 1
    # look for messages that indicate that run level has been reached
    tail -F /var/log/messages
    # Aug 31 14:21:19 pabx-demo kernel: Kernel logging (proc) stopped.
    # Aug 31 14:21:19 pabx-demo kernel: Kernel log daemon terminating.
    # Aug 31 14:21:20 pabx-demo exiting on signal 15

C'est tout. Cela me permet d'amener la box à init 1 à distance tout en gardant le contrôle.

Une fois que vous avez terminé, n'oubliez pas d'annuler les modifications :

chkconfig --level 1 network off
chkconfig --level 1 openvpn off
chkconfig --level 1 sshd off