j'ai failli me faire avoir parce que je ne comprenais pas pourquoi mon
serveur continuais d'accepter les mdp,
en fait ça a été résolu avec un redémarrage
dans mes souvenirs, la config était relue Í chaque nouvelle connexion,
est ce qu'il est nécessaire de redémarrer le serveur, pour qu'elle soit
relue, ou est ce qu'il suffit d'attendre un certain délai ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Eric Masson
Thomas writes: 'Lut,
est ce qu'il est nécessaire de redémarrer le serveur, pour qu'elle soit relue, ou est ce qu'il suffit d'attendre un certain délai ?
man sshd /signal sshd can be configured using command-line options or a configuration file (by default sshd_config(5)); command-line options override values specified in the configuration file. 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. Bref, man est ton ami... -- CQ> Pourquoi chercher des ténors derrière les barreaux, CQ> ils ont été libérés, non ? Mais que fait la DDT ? Le DDT, c'est pour éradiquer les moustiques, pas les ténors. -+- ED in : Guide du Neuneu Usenet - J'en perds le ténor -+-
Thomas <fantome.forums.tDeContes@free.fr.invalid> writes:
'Lut,
est ce qu'il est nécessaire de redémarrer le serveur, pour qu'elle
soit relue, ou est ce qu'il suffit d'attendre un certain délai ?
man sshd
/signal
sshd can be configured using command-line options or a
configuration file (by default sshd_config(5)); command-line
options override values specified in the configuration file. 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.
Bref, man est ton ami...
--
CQ> Pourquoi chercher des ténors derrière les barreaux,
CQ> ils ont été libérés, non ? Mais que fait la DDT ?
Le DDT, c'est pour éradiquer les moustiques, pas les ténors.
-+- ED in : Guide du Neuneu Usenet - J'en perds le ténor -+-
est ce qu'il est nécessaire de redémarrer le serveur, pour qu'elle soit relue, ou est ce qu'il suffit d'attendre un certain délai ?
man sshd /signal sshd can be configured using command-line options or a configuration file (by default sshd_config(5)); command-line options override values specified in the configuration file. 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. Bref, man est ton ami... -- CQ> Pourquoi chercher des ténors derrière les barreaux, CQ> ils ont été libérés, non ? Mais que fait la DDT ? Le DDT, c'est pour éradiquer les moustiques, pas les ténors. -+- ED in : Guide du Neuneu Usenet - J'en perds le ténor -+-
Thomas
In article , Eric Masson wrote:
Thomas writes: 'Lut,
est ce qu'il est nécessaire de redémarrer le serveur, pour qu'elle soit relue, ou est ce qu'il suffit d'attendre un certain délai ?
man sshd /signal sshd can be configured using command-line options or a configuration file (by default sshd_config(5)); command-line options override values specified in the configuration file. 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. Bref, man est ton ami...
Í condition de savoir o͹ chercher : je ne suis pas encore au point lÍ dessus, et je fais de mon mieux :-) $ /usr/sbin/sshd Could not load host key: /etc/ssh/ssh_host_rsa_key Could not load host key: /etc/ssh/ssh_host_dsa_key Could not load host key: /etc/ssh/ssh_host_ecdsa_key Could not load host key: /etc/ssh/ssh_host_ed25519_key alors - il accepte d'être lancé sans être root, ouf ! - je suppose que le pb est que je ne lui au pas donné exactement les mêmes options qu'au démarrage, mais dans ce cas, comment les connaitre ? j'ai fait cat /etc/init.d/ssh mais je n'arrive pas Í le déchiffrer : y a t il un moyen de les retrouver simplement, qui nous garantisse de ne pas faire d'erreur ? parallèlement Í ça, j'aimerais comprendre pourquoi sshd ne relis pas la config Í chaque nouvelle connexion, alors que, si je me souviens bien, c'est qqch qu'il faisait avant il me semble que ça n'est pas très couteux, de juste vérifier la date de modification d'un fichier -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
In article <fl0udh-691.ln1@srvbsdfenssv.interne.associated-bears.org>,
Eric Masson <emss@free.fr> wrote:
Thomas <fantome.forums.tDeContes@free.fr.invalid> writes:
'Lut,
> est ce qu'il est nécessaire de redémarrer le serveur, pour qu'elle
> soit relue, ou est ce qu'il suffit d'attendre un certain délai ?
man sshd
/signal
sshd can be configured using command-line options or a
configuration file (by default sshd_config(5)); command-line
options override values specified in the configuration file. 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.
Bref, man est ton ami...
Í condition de savoir o͹ chercher : je ne suis pas encore au point lÍ
dessus, et je fais de mon mieux :-)
$ /usr/sbin/sshd
Could not load host key: /etc/ssh/ssh_host_rsa_key
Could not load host key: /etc/ssh/ssh_host_dsa_key
Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Could not load host key: /etc/ssh/ssh_host_ed25519_key
alors
- il accepte d'être lancé sans être root, ouf !
- je suppose que le pb est que je ne lui au pas donné exactement les
mêmes options qu'au démarrage,
mais dans ce cas, comment les connaitre ?
j'ai fait
cat /etc/init.d/ssh
mais je n'arrive pas Í le déchiffrer :
y a t il un moyen de les retrouver simplement, qui nous garantisse de ne
pas faire d'erreur ?
parallèlement Í ça, j'aimerais comprendre pourquoi sshd ne relis pas la
config Í chaque nouvelle connexion,
alors que, si je me souviens bien, c'est qqch qu'il faisait avant
il me semble que ça n'est pas très couteux, de juste vérifier la date de
modification d'un fichier
est ce qu'il est nécessaire de redémarrer le serveur, pour qu'elle soit relue, ou est ce qu'il suffit d'attendre un certain délai ?
man sshd /signal sshd can be configured using command-line options or a configuration file (by default sshd_config(5)); command-line options override values specified in the configuration file. 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. Bref, man est ton ami...
Í condition de savoir o͹ chercher : je ne suis pas encore au point lÍ dessus, et je fais de mon mieux :-) $ /usr/sbin/sshd Could not load host key: /etc/ssh/ssh_host_rsa_key Could not load host key: /etc/ssh/ssh_host_dsa_key Could not load host key: /etc/ssh/ssh_host_ecdsa_key Could not load host key: /etc/ssh/ssh_host_ed25519_key alors - il accepte d'être lancé sans être root, ouf ! - je suppose que le pb est que je ne lui au pas donné exactement les mêmes options qu'au démarrage, mais dans ce cas, comment les connaitre ? j'ai fait cat /etc/init.d/ssh mais je n'arrive pas Í le déchiffrer : y a t il un moyen de les retrouver simplement, qui nous garantisse de ne pas faire d'erreur ? parallèlement Í ça, j'aimerais comprendre pourquoi sshd ne relis pas la config Í chaque nouvelle connexion, alors que, si je me souviens bien, c'est qqch qu'il faisait avant il me semble que ça n'est pas très couteux, de juste vérifier la date de modification d'un fichier -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
Eric Masson
Thomas writes: 'Re,
Í condition de savoir o͹ chercher : je ne suis pas encore au point lÍ dessus, et je fais de mon mieux :-)
Ça s'apprend, man ${nom_commande} est un bon point de départ. La manpage explique qu'envoyer le signal HUP Í sshd provoque son redémarrage avec les arguments utilisés pour son lancement. man signal donne quelques infos sur ce qu'est un signal (étonnant, non ?) et la section see also donne d'autres références de pages man, parmi lesquelles kill En cas de doute une recherche complémentaire sur signal, kill via un moteur de recherche donne des éléments complémentaires. Dans le cas présent, sudo pkill -sHUP sshd donne le résultat décrit par la page man initiale.
mais dans ce cas, comment les connaitre ?
Dépend de la distribution utilisée, se renseigner sur le système d'init de celle que l'on utilise est un bon début. La commande service est sjmsb présente, quel que soit le système d'init utilisé, donc Í nouveau man service donnera des infos intéressantes. Dans le cas présent, sudo service sshd restart force le redémarrage de sshd en lui passant les arguments requis.
parallèlement Í ça, j'aimerais comprendre pourquoi sshd ne relis pas la config Í chaque nouvelle connexion
Parce que ses développeurs considèrent probablement que cela n'a pas d'intérêt.
alors que, si je me souviens bien, c'est qqch qu'il faisait avant
Non.
il me semble que ça n'est pas très couteux, de juste vérifier la date de modification d'un fichier
Il te semble mal. sshd est un programme complexe dont la sécurité doit être maximale, insérer du code pour forcer la relecture d'un fichier de configuration et donc augmenter la surface d'attaque n'est pas l'idée du siècle. --
Bon, je recherche toujours un mec qui " touche " sous linux sur rochefort
Il m'arrive de toucher, mais dans ces moments la, je pense pas trop a linux. -+- ST in Guide du linuxien pervers : "Linux c'est une affaire de doigté"
Thomas <fantome.forums.tDeContes@free.fr.invalid> writes:
'Re,
Í condition de savoir o͹ chercher : je ne suis pas encore au point lÍ
dessus, et je fais de mon mieux :-)
Ça s'apprend, man ${nom_commande} est un bon point de départ.
La manpage explique qu'envoyer le signal HUP Í sshd provoque son redémarrage
avec les arguments utilisés pour son lancement.
man signal donne quelques infos sur ce qu'est un signal (étonnant, non
?) et la section see also donne d'autres références de pages man, parmi
lesquelles kill
En cas de doute une recherche complémentaire sur signal, kill via un
moteur de recherche donne des éléments complémentaires.
Dans le cas présent, sudo pkill -sHUP sshd donne le résultat décrit par
la page man initiale.
mais dans ce cas, comment les connaitre ?
Dépend de la distribution utilisée, se renseigner sur le système d'init
de celle que l'on utilise est un bon début.
La commande service est sjmsb présente, quel que soit le système d'init
utilisé, donc Í nouveau man service donnera des infos intéressantes.
Dans le cas présent, sudo service sshd restart force le redémarrage de
sshd en lui passant les arguments requis.
parallèlement Í ça, j'aimerais comprendre pourquoi sshd ne relis pas
la config Í chaque nouvelle connexion
Parce que ses développeurs considèrent probablement que cela n'a pas
d'intérêt.
alors que, si je me souviens bien, c'est qqch qu'il faisait avant
Non.
il me semble que ça n'est pas très couteux, de juste vérifier la date de
modification d'un fichier
Il te semble mal. sshd est un programme complexe dont la sécurité doit
être maximale, insérer du code pour forcer la relecture d'un fichier de
configuration et donc augmenter la surface d'attaque n'est pas l'idée du
siècle.
--
Bon, je recherche toujours un mec qui " touche " sous linux sur rochefort
Il m'arrive de toucher, mais dans ces moments la, je pense pas trop a
linux.
-+- ST in Guide du linuxien pervers : "Linux c'est une affaire de doigté"
Í condition de savoir o͹ chercher : je ne suis pas encore au point lÍ dessus, et je fais de mon mieux :-)
Ça s'apprend, man ${nom_commande} est un bon point de départ. La manpage explique qu'envoyer le signal HUP Í sshd provoque son redémarrage avec les arguments utilisés pour son lancement. man signal donne quelques infos sur ce qu'est un signal (étonnant, non ?) et la section see also donne d'autres références de pages man, parmi lesquelles kill En cas de doute une recherche complémentaire sur signal, kill via un moteur de recherche donne des éléments complémentaires. Dans le cas présent, sudo pkill -sHUP sshd donne le résultat décrit par la page man initiale.
mais dans ce cas, comment les connaitre ?
Dépend de la distribution utilisée, se renseigner sur le système d'init de celle que l'on utilise est un bon début. La commande service est sjmsb présente, quel que soit le système d'init utilisé, donc Í nouveau man service donnera des infos intéressantes. Dans le cas présent, sudo service sshd restart force le redémarrage de sshd en lui passant les arguments requis.
parallèlement Í ça, j'aimerais comprendre pourquoi sshd ne relis pas la config Í chaque nouvelle connexion
Parce que ses développeurs considèrent probablement que cela n'a pas d'intérêt.
alors que, si je me souviens bien, c'est qqch qu'il faisait avant
Non.
il me semble que ça n'est pas très couteux, de juste vérifier la date de modification d'un fichier
Il te semble mal. sshd est un programme complexe dont la sécurité doit être maximale, insérer du code pour forcer la relecture d'un fichier de configuration et donc augmenter la surface d'attaque n'est pas l'idée du siècle. --
Bon, je recherche toujours un mec qui " touche " sous linux sur rochefort
Il m'arrive de toucher, mais dans ces moments la, je pense pas trop a linux. -+- ST in Guide du linuxien pervers : "Linux c'est une affaire de doigté"
Christophe PEREZ
Le Sat, 23 Jan 2021 19:14:06 +0100, Eric Masson a écrit :
La commande service est sjmsb présente, quel que soit le système d'init utilisé, donc Í nouveau man service donnera des infos intéressantes.
Je lis tout ça un peu en diagonale, mais lÍ j'avoue que je suis resté perplexe. # man service Aucune entrée de manuel pour service # service -su: service : commande introuvable
Le Sat, 23 Jan 2021 19:14:06 +0100, Eric Masson a écrit :
La commande service est sjmsb présente, quel que soit le système d'init
utilisé, donc Í nouveau man service donnera des infos intéressantes.
Je lis tout ça un peu en diagonale, mais lÍ j'avoue que je suis resté
perplexe.
# man service
Aucune entrée de manuel pour service
Le Sat, 23 Jan 2021 19:14:06 +0100, Eric Masson a écrit :
La commande service est sjmsb présente, quel que soit le système d'init utilisé, donc Í nouveau man service donnera des infos intéressantes.
Je lis tout ça un peu en diagonale, mais lÍ j'avoue que je suis resté perplexe. # man service Aucune entrée de manuel pour service # service -su: service : commande introuvable
Thomas
In article , Eric Masson wrote:
Thomas writes: 'Re,
Í condition de savoir o͹ chercher : je ne suis pas encore au point lÍ dessus, et je fais de mon mieux :-)
Ça s'apprend, man ${nom_commande} est un bon point de départ.
on me l'a déjÍ dit, mais c'est pas tjr suffisant (je n'ai pas la même expérience que toi pour savoir o͹ et comment chercher, comprendre ce que je lis, etc ...)
La manpage explique qu'envoyer le signal HUP Í sshd provoque son redémarrage avec les arguments utilisés pour son lancement.
ah désolé, j'avais compris de travers, je croyais que "executing itself with the name and options it was started with" représentait un moyen d'envoyer le "hangup signal" au sshd original, d'o͹ une question inutile Í la suite, désolé
Dans le cas présent, sudo pkill -sHUP sshd donne le résultat décrit par la page man initiale. Dans le cas présent, sudo service sshd restart force le redémarrage de sshd en lui passant les arguments requis.
merci bcp de me donner les commandes toutes prêtes, ça pourrais servir un jour ou l'autre (ou Í d'autres ?) :-) mais je pense que je ne vais pas aller jusque lÍ pour l'instant : mon métier c'est le développement, pas l'administration, et je souhaite autant que possible en rester Í une utilisation suffisamment simple
parallèlement Í ça, j'aimerais comprendre pourquoi sshd ne relis pas la config Í chaque nouvelle connexion
Parce que ses développeurs considèrent probablement que cela n'a pas d'intérêt.
il me semble que quand /etc/ssh/sshd_config est modifié, il n'y a pas de cas o͹ on souhaiterais que sshd reste avec l'ancienne config un certain temps c'est différent, l'absence d'utilité et le pb de sécurité
alors que, si je me souviens bien, c'est qqch qu'il faisait avant
Non.
ok, alors je confond peut être avec la config par utilisateur
il me semble que ça n'est pas très couteux, de juste vérifier la date de modification d'un fichier
(je pensais surtout au cout en ressources pour un serveur tres sollicité)
Il te semble mal. sshd est un programme complexe dont la sécurité doit être maximale, insérer du code pour forcer la relecture d'un fichier de configuration et donc augmenter la surface d'attaque n'est pas l'idée du siècle.
dis moi si je dis une bêtise, il me semble que - si un pirate arrive Í faire fonctionner sudo, il a les moyens de redémarrer sshd de toutes les manières possibles, - si non, il n'existe aucune possibilité pour lui de modifier /etc/ssh/sshd_config donc, quel genre de faille pourrais se glisser entre les 2 ? -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
In article <fk5udh-hot2.ln1@srvbsdfenssv.interne.associated-bears.org>,
Eric Masson <emss@free.fr> wrote:
Thomas <fantome.forums.tDeContes@free.fr.invalid> writes:
'Re,
> Í condition de savoir o͹ chercher : je ne suis pas encore au point lÍ
> dessus, et je fais de mon mieux :-)
Ça s'apprend, man ${nom_commande} est un bon point de départ.
on me l'a déjÍ dit, mais c'est pas tjr suffisant
(je n'ai pas la même expérience que toi pour savoir o͹ et comment
chercher, comprendre ce que je lis, etc ...)
La manpage explique qu'envoyer le signal HUP Í sshd provoque son redémarrage
avec les arguments utilisés pour son lancement.
ah désolé, j'avais compris de travers,
je croyais que "executing itself with the name and options it was
started with" représentait un moyen d'envoyer le "hangup signal" au sshd
original,
d'o͹ une question inutile Í la suite, désolé
Dans le cas présent, sudo pkill -sHUP sshd donne le résultat décrit par
la page man initiale.
Dans le cas présent, sudo service sshd restart force le redémarrage de
sshd en lui passant les arguments requis.
merci bcp de me donner les commandes toutes prêtes, ça pourrais servir
un jour ou l'autre (ou Í d'autres ?) :-)
mais je pense que je ne vais pas aller jusque lÍ pour l'instant :
mon métier c'est le développement, pas l'administration, et je souhaite
autant que possible en rester Í une utilisation suffisamment simple
> parallèlement Í ça, j'aimerais comprendre pourquoi sshd ne relis pas
> la config Í chaque nouvelle connexion
Parce que ses développeurs considèrent probablement que cela n'a pas
d'intérêt.
il me semble que quand /etc/ssh/sshd_config est modifié, il n'y a pas de
cas o͹ on souhaiterais que sshd reste avec l'ancienne config un certain
temps
c'est différent, l'absence d'utilité et le pb de sécurité
> alors que, si je me souviens bien, c'est qqch qu'il faisait avant
Non.
ok, alors je confond peut être avec la config par utilisateur
> il me semble que ça n'est pas très couteux, de juste vérifier la date de
> modification d'un fichier
(je pensais surtout au cout en ressources pour un serveur tres sollicité)
Il te semble mal. sshd est un programme complexe dont la sécurité doit
être maximale, insérer du code pour forcer la relecture d'un fichier de
configuration et donc augmenter la surface d'attaque n'est pas l'idée du
siècle.
dis moi si je dis une bêtise,
il me semble que
- si un pirate arrive Í faire fonctionner sudo, il a les moyens de
redémarrer sshd de toutes les manières possibles,
- si non, il n'existe aucune possibilité pour lui de modifier
/etc/ssh/sshd_config
donc, quel genre de faille pourrais se glisser entre les 2 ?
Í condition de savoir o͹ chercher : je ne suis pas encore au point lÍ dessus, et je fais de mon mieux :-)
Ça s'apprend, man ${nom_commande} est un bon point de départ.
on me l'a déjÍ dit, mais c'est pas tjr suffisant (je n'ai pas la même expérience que toi pour savoir o͹ et comment chercher, comprendre ce que je lis, etc ...)
La manpage explique qu'envoyer le signal HUP Í sshd provoque son redémarrage avec les arguments utilisés pour son lancement.
ah désolé, j'avais compris de travers, je croyais que "executing itself with the name and options it was started with" représentait un moyen d'envoyer le "hangup signal" au sshd original, d'o͹ une question inutile Í la suite, désolé
Dans le cas présent, sudo pkill -sHUP sshd donne le résultat décrit par la page man initiale. Dans le cas présent, sudo service sshd restart force le redémarrage de sshd en lui passant les arguments requis.
merci bcp de me donner les commandes toutes prêtes, ça pourrais servir un jour ou l'autre (ou Í d'autres ?) :-) mais je pense que je ne vais pas aller jusque lÍ pour l'instant : mon métier c'est le développement, pas l'administration, et je souhaite autant que possible en rester Í une utilisation suffisamment simple
parallèlement Í ça, j'aimerais comprendre pourquoi sshd ne relis pas la config Í chaque nouvelle connexion
Parce que ses développeurs considèrent probablement que cela n'a pas d'intérêt.
il me semble que quand /etc/ssh/sshd_config est modifié, il n'y a pas de cas o͹ on souhaiterais que sshd reste avec l'ancienne config un certain temps c'est différent, l'absence d'utilité et le pb de sécurité
alors que, si je me souviens bien, c'est qqch qu'il faisait avant
Non.
ok, alors je confond peut être avec la config par utilisateur
il me semble que ça n'est pas très couteux, de juste vérifier la date de modification d'un fichier
(je pensais surtout au cout en ressources pour un serveur tres sollicité)
Il te semble mal. sshd est un programme complexe dont la sécurité doit être maximale, insérer du code pour forcer la relecture d'un fichier de configuration et donc augmenter la surface d'attaque n'est pas l'idée du siècle.
dis moi si je dis une bêtise, il me semble que - si un pirate arrive Í faire fonctionner sudo, il a les moyens de redémarrer sshd de toutes les manières possibles, - si non, il n'existe aucune possibilité pour lui de modifier /etc/ssh/sshd_config donc, quel genre de faille pourrais se glisser entre les 2 ? -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
Marc SCHAEFER
Thomas wrote:
est ce qu'il est nécessaire de redémarrer le serveur, pour qu'elle soit relue, ou est ce qu'il suffit d'attendre un certain délai ?
systemctl reload ssh # recommandé et ne pas oublier que dans le monde systemctl, certains fichiers dans /etc/default ne sont relus qu'avec un systemctl daemon-reload ou approchant ...
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
est ce qu'il est nécessaire de redémarrer le serveur, pour qu'elle soit
relue, ou est ce qu'il suffit d'attendre un certain délai ?
systemctl reload ssh # recommandé
et ne pas oublier que dans le monde systemctl, certains fichiers dans
/etc/default ne sont relus qu'avec un systemctl daemon-reload ou
approchant ...
est ce qu'il est nécessaire de redémarrer le serveur, pour qu'elle soit relue, ou est ce qu'il suffit d'attendre un certain délai ?
systemctl reload ssh # recommandé et ne pas oublier que dans le monde systemctl, certains fichiers dans /etc/default ne sont relus qu'avec un systemctl daemon-reload ou approchant ...
Marc SCHAEFER
Christophe PEREZ wrote:
# man service Aucune entrée de manuel pour service # service -su: service : commande introuvable
service est encore disponible sur Debian stable, mais c'est une couche d'émulation Í systemctl
Christophe PEREZ <chris@novazur.fr> wrote:
# man service
Aucune entrée de manuel pour service
# service
-su: service : commande introuvable
service est encore disponible sur Debian stable, mais c'est une couche
d'émulation Í systemctl
# man service Aucune entrée de manuel pour service # service -su: service : commande introuvable
service est encore disponible sur Debian stable, mais c'est une couche d'émulation Í systemctl
Eric Masson
Marc SCHAEFER writes: 'Lut Marc,
service est encore disponible sur Debian stable, mais c'est une couche d'émulation Í systemctl
Les quelques machines linux que j'utilise sont effectivement des Debian et service est juste une couche de compatibilité systemctl, nous sommes d'accord. -- Tout neuneu que je suis en usenautique, je me permets de signaler aux décideurs qu'ils sont en infraction. J'ai entendu parler de black lists Sont-elles déclarées Í la CNIL? Probablement pas. C'est un délit! -+- Simon in <http://www.le-gnu.net> -+- Délit de sale liste -+-
Marc SCHAEFER <schaefer@alphanet.ch> writes:
'Lut Marc,
service est encore disponible sur Debian stable, mais c'est une couche
d'émulation Í systemctl
Les quelques machines linux que j'utilise sont effectivement des Debian
et service est juste une couche de compatibilité systemctl, nous sommes
d'accord.
--
Tout neuneu que je suis en usenautique, je me permets de signaler aux
décideurs qu'ils sont en infraction. J'ai entendu parler de black lists
Sont-elles déclarées Í la CNIL? Probablement pas. C'est un délit!
-+- Simon in <http://www.le-gnu.net> -+- Délit de sale liste -+-
service est encore disponible sur Debian stable, mais c'est une couche d'émulation Í systemctl
Les quelques machines linux que j'utilise sont effectivement des Debian et service est juste une couche de compatibilité systemctl, nous sommes d'accord. -- Tout neuneu que je suis en usenautique, je me permets de signaler aux décideurs qu'ils sont en infraction. J'ai entendu parler de black lists Sont-elles déclarées Í la CNIL? Probablement pas. C'est un délit! -+- Simon in <http://www.le-gnu.net> -+- Délit de sale liste -+-
Thomas
In article <rujo25$dru$, Marc SCHAEFER wrote:
Thomas wrote:
est ce qu'il est nécessaire de redémarrer le serveur, pour qu'elle soit relue, ou est ce qu'il suffit d'attendre un certain délai ?
systemctl reload ssh # recommandé et ne pas oublier que dans le monde systemctl, certains fichiers dans /etc/default ne sont relus qu'avec un systemctl daemon-reload ou approchant ...
In article <rujo25$dru$1@shakotay.alphanet.ch>,
Marc SCHAEFER <schaefer@alphanet.ch> wrote:
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> est ce qu'il est nécessaire de redémarrer le serveur, pour qu'elle soit
> relue, ou est ce qu'il suffit d'attendre un certain délai ?
systemctl reload ssh # recommandé
et ne pas oublier que dans le monde systemctl, certains fichiers dans
/etc/default ne sont relus qu'avec un systemctl daemon-reload ou
approchant ...
est ce qu'il est nécessaire de redémarrer le serveur, pour qu'elle soit relue, ou est ce qu'il suffit d'attendre un certain délai ?
systemctl reload ssh # recommandé et ne pas oublier que dans le monde systemctl, certains fichiers dans /etc/default ne sont relus qu'avec un systemctl daemon-reload ou approchant ...
