J'ai besoin d'un petit renseignement sur le serveur ssh de Mac OS X: je
me connecte =E0 distance sur mon Mac et je voudrais savoir comment
red=E9marrer sshd en mode console.
En effet, si je modifie sshd_config, je voudrais pouvoir red=E9marrer le
serveur ssh sans forc=E9ment rebooter le Mac :-)
J'ai besoin d'un petit renseignement sur le serveur ssh de Mac OS X: je me connecte à distance sur mon Mac et je voudrais savoir comment redémarrer sshd en mode console.
En effet, si je modifie sshd config, je voudrais pouvoir redémarrer le serveur ssh sans forcément rebooter le Mac :-)
sur MacOS X c'est inutile. sshd est lancé "on demand" par launchd, donc si tu attends que le sshd quitte tout seul (en te déconnectant et en attendant un peu), le sshd_config sera lu à la prochaine connexion.
D'ailleurs je me demande même si c'est utile d'attendre avant de se reconnecter, mais dans le doute...
patpro
-- http://www.patpro.net/
In article <1165912782.854432.44510@j72g2000cwa.googlegroups.com>,
"ctobini" <ctemp2@free.fr> wrote:
Bonjour,
J'ai besoin d'un petit renseignement sur le serveur ssh de Mac OS X: je
me connecte à distance sur mon Mac et je voudrais savoir comment
redémarrer sshd en mode console.
En effet, si je modifie sshd config, je voudrais pouvoir redémarrer le
serveur ssh sans forcément rebooter le Mac :-)
sur MacOS X c'est inutile. sshd est lancé "on demand" par launchd, donc
si tu attends que le sshd quitte tout seul (en te déconnectant et en
attendant un peu), le sshd_config sera lu à la prochaine connexion.
D'ailleurs je me demande même si c'est utile d'attendre avant de se
reconnecter, mais dans le doute...
J'ai besoin d'un petit renseignement sur le serveur ssh de Mac OS X: je me connecte à distance sur mon Mac et je voudrais savoir comment redémarrer sshd en mode console.
En effet, si je modifie sshd config, je voudrais pouvoir redémarrer le serveur ssh sans forcément rebooter le Mac :-)
sur MacOS X c'est inutile. sshd est lancé "on demand" par launchd, donc si tu attends que le sshd quitte tout seul (en te déconnectant et en attendant un peu), le sshd_config sera lu à la prochaine connexion.
D'ailleurs je me demande même si c'est utile d'attendre avant de se reconnecter, mais dans le doute...
patpro
-- http://www.patpro.net/
Nicolas.MICHEL
ctobini wrote:
Bonjour,
J'ai besoin d'un petit renseignement sur le serveur ssh de Mac OS X: je me connecte à distance sur mon Mac et je voudrais savoir comment redémarrer sshd en mode console.
En effet, si je modifie sshd_config, je voudrais pouvoir redémarrer le serveur ssh sans forcément rebooter le Mac :-)
en plus de ce qu'a dit patpro :
~> sudo launchctl list |grep sshd com.openssh.sshd
~> man launchctl |grep -A1 -B1 restart stop joblabels ... Stop the specified jobs by label. Jobs may restart automatically if demand driven.
Donc un truc de ce genre devrait relancer le service (et non le daemon, lequel se lance sur demande)
~> sudo launchctl stop com.openssh.sshd (a tester)
-- Nicolas
ctobini <ctemp2@free.fr> wrote:
Bonjour,
J'ai besoin d'un petit renseignement sur le serveur ssh de Mac OS X: je
me connecte à distance sur mon Mac et je voudrais savoir comment
redémarrer sshd en mode console.
En effet, si je modifie sshd_config, je voudrais pouvoir redémarrer le
serveur ssh sans forcément rebooter le Mac :-)
en plus de ce qu'a dit patpro :
~> sudo launchctl list |grep sshd
com.openssh.sshd
~> man launchctl |grep -A1 -B1 restart
stop joblabels ...
Stop the specified jobs by label. Jobs may restart automatically
if demand driven.
Donc un truc de ce genre devrait relancer le service (et non le daemon,
lequel se lance sur demande)
~> sudo launchctl stop com.openssh.sshd
(a tester)
J'ai besoin d'un petit renseignement sur le serveur ssh de Mac OS X: je me connecte à distance sur mon Mac et je voudrais savoir comment redémarrer sshd en mode console.
En effet, si je modifie sshd_config, je voudrais pouvoir redémarrer le serveur ssh sans forcément rebooter le Mac :-)
en plus de ce qu'a dit patpro :
~> sudo launchctl list |grep sshd com.openssh.sshd
~> man launchctl |grep -A1 -B1 restart stop joblabels ... Stop the specified jobs by label. Jobs may restart automatically if demand driven.
Donc un truc de ce genre devrait relancer le service (et non le daemon, lequel se lance sur demande)
~> sudo launchctl stop com.openssh.sshd (a tester)
-- Nicolas
Vincent Lefevre
Dans l'article , patpro ~ Patrick Proniewski écrit:
In article , "ctobini" wrote: [...]
En effet, si je modifie sshd config, je voudrais pouvoir redémarrer le serveur ssh sans forcément rebooter le Mac :-)
sur MacOS X c'est inutile. sshd est lancé "on demand" par launchd, donc si tu attends que le sshd quitte tout seul (en te déconnectant et en attendant un peu), le sshd_config sera lu à la prochaine connexion.
Au cas où l'utilisateur aurait installé un autre sshd qui n'est pas lancé "on demand" (c'est mon cas, pour avoir un OpenSSH plus récent), "man sshd" dit:
sshd rereads its configuration file when it receives a hangup signal, SIGHUP, by executing itself with the name and options it was started with, e.g., /usr/sbin/sshd.
Note: cette fonctionnalité de relire son fichier de config quand on reçoit tel signal n'est pas propre à sshd, d'autres serveurs, comme Apache (httpd) et Exim, ont une fonctionnalité similaire (mais ce n'est pas toujours le signal HUP, j'ai aussi vu USR1).
Dans l'article <patpro-C012CA.09525712122006@localhost>,
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> écrit:
In article <1165912782.854432.44510@j72g2000cwa.googlegroups.com>,
"ctobini" <ctemp2@free.fr> wrote:
[...]
En effet, si je modifie sshd config, je voudrais pouvoir redémarrer le
serveur ssh sans forcément rebooter le Mac :-)
sur MacOS X c'est inutile. sshd est lancé "on demand" par launchd, donc
si tu attends que le sshd quitte tout seul (en te déconnectant et en
attendant un peu), le sshd_config sera lu à la prochaine connexion.
Au cas où l'utilisateur aurait installé un autre sshd qui n'est pas
lancé "on demand" (c'est mon cas, pour avoir un OpenSSH plus récent),
"man sshd" dit:
sshd rereads its configuration file when it receives a hangup
signal, SIGHUP, by executing itself with the name and options
it was started with, e.g., /usr/sbin/sshd.
Note: cette fonctionnalité de relire son fichier de config quand
on reçoit tel signal n'est pas propre à sshd, d'autres serveurs,
comme Apache (httpd) et Exim, ont une fonctionnalité similaire
(mais ce n'est pas toujours le signal HUP, j'ai aussi vu USR1).
Dans l'article , patpro ~ Patrick Proniewski écrit:
In article , "ctobini" wrote: [...]
En effet, si je modifie sshd config, je voudrais pouvoir redémarrer le serveur ssh sans forcément rebooter le Mac :-)
sur MacOS X c'est inutile. sshd est lancé "on demand" par launchd, donc si tu attends que le sshd quitte tout seul (en te déconnectant et en attendant un peu), le sshd_config sera lu à la prochaine connexion.
Au cas où l'utilisateur aurait installé un autre sshd qui n'est pas lancé "on demand" (c'est mon cas, pour avoir un OpenSSH plus récent), "man sshd" dit:
sshd rereads its configuration file when it receives a hangup signal, SIGHUP, by executing itself with the name and options it was started with, e.g., /usr/sbin/sshd.
Note: cette fonctionnalité de relire son fichier de config quand on reçoit tel signal n'est pas propre à sshd, d'autres serveurs, comme Apache (httpd) et Exim, ont une fonctionnalité similaire (mais ce n'est pas toujours le signal HUP, j'ai aussi vu USR1).
Au cas où l'utilisateur aurait installé un autre sshd qui n'est pas lancé "on demand" (c'est mon cas, pour avoir un OpenSSH plus récent), "man sshd" dit:
sshd rereads its configuration file when it receives a hangup signal, SIGHUP, by executing itself with the name and options it was started with, e.g., /usr/sbin/sshd.
Et pour envoyer un tel signal au processus sshd, déterminer son n° (de process=PID) et faire la commande kill -HUP n°deprocess
JPaul. -- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
Vincent Lefevre <vincent+news@vinc17.org> wrote:
Au cas où l'utilisateur aurait installé un autre sshd qui n'est pas
lancé "on demand" (c'est mon cas, pour avoir un OpenSSH plus récent),
"man sshd" dit:
sshd rereads its configuration file when it receives a hangup
signal, SIGHUP, by executing itself with the name and options
it was started with, e.g., /usr/sbin/sshd.
Et pour envoyer un tel signal au processus sshd, déterminer son n° (de
process=PID) et faire la commande kill -HUP n°deprocess
JPaul.
--
/==/==\- Jean-Paul BLANC
/ /--/--//\ quelque-part (somewhere)
|/| L |\ en (in)
/|| = |||\ FRANCE
Au cas où l'utilisateur aurait installé un autre sshd qui n'est pas lancé "on demand" (c'est mon cas, pour avoir un OpenSSH plus récent), "man sshd" dit:
sshd rereads its configuration file when it receives a hangup signal, SIGHUP, by executing itself with the name and options it was started with, e.g., /usr/sbin/sshd.
Et pour envoyer un tel signal au processus sshd, déterminer son n° (de process=PID) et faire la commande kill -HUP n°deprocess
JPaul. -- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
laurent.pertois
JPaul wrote:
Et pour envoyer un tel signal au processus sshd, déterminer son n° (de process=PID) et faire la commande kill -HUP n°deprocess
sudo killall -HUP nom_de_process
doit faire l'affaire, il me semble.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
JPaul <blanc@empty.org> wrote:
Et pour envoyer un tel signal au processus sshd, déterminer son n° (de
process=PID) et faire la commande kill -HUP n°deprocess
sudo killall -HUP nom_de_process
doit faire l'affaire, il me semble.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Et pour envoyer un tel signal au processus sshd, déterminer son n° (de process=PID) et faire la commande kill -HUP n°deprocess
sudo killall -HUP nom_de_process
doit faire l'affaire, il me semble.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
blanc
Laurent Pertois wrote:
sudo killall -HUP nom_de_process
doit faire l'affaire, il me semble.
Oui, également. Mais je n'ai pas l'habitude de mentionner killall que je considère plus dangereux.
JPaul. -- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
Oui, également. Mais je n'ai pas l'habitude de mentionner killall que je considère plus dangereux.
JPaul. -- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
ctobini
Bonjour et merci de ta réponse,
Ca a l'air pratique dans l'absolu mais c'est un peu frustrant de ne pas commander le service directement (genre /etc/init.d) ce que je reproche un peu à Mac OS X.
C. Tobini
sur MacOS X c'est inutile. sshd est lancé "on demand" par launchd, donc si tu attends que le sshd quitte tout seul (en te déconnectant et en attendant un peu), le sshd_config sera lu à la prochaine connexion.
D'ailleurs je me demande même si c'est utile d'attendre avant de se reconnecter, mais dans le doute...
patpro
-- http://www.patpro.net/
Bonjour et merci de ta réponse,
Ca a l'air pratique dans l'absolu mais c'est un peu frustrant de ne pas
commander le service directement (genre /etc/init.d) ce que je reproche
un peu à Mac OS X.
C. Tobini
sur MacOS X c'est inutile. sshd est lancé "on demand" par launchd, donc
si tu attends que le sshd quitte tout seul (en te déconnectant et en
attendant un peu), le sshd_config sera lu à la prochaine connexion.
D'ailleurs je me demande même si c'est utile d'attendre avant de se
reconnecter, mais dans le doute...
Ca a l'air pratique dans l'absolu mais c'est un peu frustrant de ne pas commander le service directement (genre /etc/init.d) ce que je reproche un peu à Mac OS X.
C. Tobini
sur MacOS X c'est inutile. sshd est lancé "on demand" par launchd, donc si tu attends que le sshd quitte tout seul (en te déconnectant et en attendant un peu), le sshd_config sera lu à la prochaine connexion.
D'ailleurs je me demande même si c'est utile d'attendre avant de se reconnecter, mais dans le doute...
patpro
-- http://www.patpro.net/
Nicolas.MICHEL
ctobini wrote:
Bonjour et merci de ta réponse,
Ca a l'air pratique dans l'absolu mais c'est un peu frustrant de ne pas commander le service directement (genre /etc/init.d) ce que je reproche un peu à Mac OS X.
Il y a à peut près l'équivalent : C'est soit des StartupItems soit des LaunchDeamon.
Ceci dit on est bien d'accord sur la clarté de /etc/init.d J'aurais perso préféré que Apple utilise ce système en créant un système de gestion de ces init.d, du genre "services et chkconfig" de redhat mais en mieux.
-- Nicolas
ctobini <ctemp2@free.fr> wrote:
Bonjour et merci de ta réponse,
Ca a l'air pratique dans l'absolu mais c'est un peu frustrant de ne pas
commander le service directement (genre /etc/init.d) ce que je reproche
un peu à Mac OS X.
Il y a à peut près l'équivalent :
C'est soit des StartupItems soit des LaunchDeamon.
Ceci dit on est bien d'accord sur la clarté de /etc/init.d
J'aurais perso préféré que Apple utilise ce système en créant un système
de gestion de ces init.d, du genre "services et chkconfig" de redhat
mais en mieux.
Ca a l'air pratique dans l'absolu mais c'est un peu frustrant de ne pas commander le service directement (genre /etc/init.d) ce que je reproche un peu à Mac OS X.
Il y a à peut près l'équivalent : C'est soit des StartupItems soit des LaunchDeamon.
Ceci dit on est bien d'accord sur la clarté de /etc/init.d J'aurais perso préféré que Apple utilise ce système en créant un système de gestion de ces init.d, du genre "services et chkconfig" de redhat mais en mieux.
-- Nicolas
Erwan David
(Nicolas MICHEL) écrivait :
Ceci dit on est bien d'accord sur la clarté de /etc/init.d J'aurais perso préféré que Apple utilise ce système en créant un système de gestion de ces init.d, du genre "services et chkconfig" de redhat mais en mieux.
Idem, mais la séparation totale de la mécanique et de la carosserie qu'implique ce système d'un GUI pilotant un stystème non graphique ne semble pas être complètemenet entré dans la culture Apple.
Ceci dit on est bien d'accord sur la clarté de /etc/init.d
J'aurais perso préféré que Apple utilise ce système en créant un système
de gestion de ces init.d, du genre "services et chkconfig" de redhat
mais en mieux.
Idem, mais la séparation totale de la mécanique et de la carosserie
qu'implique ce système d'un GUI pilotant un stystème non graphique
ne semble pas être complètemenet entré dans la culture Apple.
Ceci dit on est bien d'accord sur la clarté de /etc/init.d J'aurais perso préféré que Apple utilise ce système en créant un système de gestion de ces init.d, du genre "services et chkconfig" de redhat mais en mieux.
Idem, mais la séparation totale de la mécanique et de la carosserie qu'implique ce système d'un GUI pilotant un stystème non graphique ne semble pas être complètemenet entré dans la culture Apple.
-- Erwan
laurent.pertois
ctobini wrote:
Ca a l'air pratique dans l'absolu mais c'est un peu frustrant de ne pas commander le service directement (genre /etc/init.d) ce que je reproche un peu à Mac OS X.
Cela dit, le ssh est lancé par launchd 'on demand', on doit pouvoir l'avoir en permanence et après le relancer au besoin après changements.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
ctobini <ctemp2@free.fr> wrote:
Ca a l'air pratique dans l'absolu mais c'est un peu frustrant de ne pas
commander le service directement (genre /etc/init.d) ce que je reproche
un peu à Mac OS X.
Cela dit, le ssh est lancé par launchd 'on demand', on doit pouvoir
l'avoir en permanence et après le relancer au besoin après changements.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Ca a l'air pratique dans l'absolu mais c'est un peu frustrant de ne pas commander le service directement (genre /etc/init.d) ce que je reproche un peu à Mac OS X.
Cela dit, le ssh est lancé par launchd 'on demand', on doit pouvoir l'avoir en permanence et après le relancer au besoin après changements.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
