Avec le couple systemd/journaltcl je voulais savoir:
-comment logger les jouranux d'un démon dans un fichier précis?
Par exemple, logger le démon /usr/bin/mon_dameon dans
/var/log/mon_daemon.log ?
-comment vider les informations relatives à un daemon particulier?
Par exemple, je veux vider l'intégralité les logs de
mon_daemon?
-comment lire les informations relatives à un daemon? Par
exemple si mon_daemon a loggé une ligne démarrant par "error"
depuis son dernier lancement.
Et sans modif de ce fichier, votre sshd n'écoutera pas sur un autre port que le 22. Systemd sait ce qui est bien pour toi, et tu devras te plier à systemd. il va vraiment falloir renommer linux en linuxd, sshd en sshdd, etc..
Oui mais openssh est écrit par des barbus qui mangent les enfants, c'est sûrement un complot anti systemd
D'un autre côté, les tenants de systemd ont certainement infiltré les barbus pour imposer l'option '-i' dans OpenSSH.
-- Bruno Ducrot
A quoi ca sert que Ducrot hisse des carcasses ?
On 2014-01-29, Patrick Lamaizière wrote:
Kevin Denis :
Et sans modif de ce fichier, votre sshd n'écoutera pas sur un autre
port que le 22. Systemd sait ce qui est bien pour toi, et tu devras te
plier à systemd. il va vraiment falloir renommer linux en linuxd, sshd
en sshdd, etc..
Oui mais openssh est écrit par des barbus qui mangent les enfants,
c'est sûrement un complot anti systemd
D'un autre côté, les tenants de systemd ont certainement infiltré
les barbus pour imposer l'option '-i' dans OpenSSH.
Et sans modif de ce fichier, votre sshd n'écoutera pas sur un autre port que le 22. Systemd sait ce qui est bien pour toi, et tu devras te plier à systemd. il va vraiment falloir renommer linux en linuxd, sshd en sshdd, etc..
Oui mais openssh est écrit par des barbus qui mangent les enfants, c'est sûrement un complot anti systemd
D'un autre côté, les tenants de systemd ont certainement infiltré les barbus pour imposer l'option '-i' dans OpenSSH.
-- Bruno Ducrot
A quoi ca sert que Ducrot hisse des carcasses ?
Loki Harfagr
Wed, 29 Jan 2014 23:18:54 +1100, Doug713705 did cat :
Le 29-01-2014, Kevin Denis nous expliquait dans fr.comp.os.linux.debats () :
Comme vous le voyez, systemd ajoute son fichier de conf à sshd et override tes options:
Ça plus le découpage des fichiers de conf à la Debian et on met 3 années lumières entre la folle réalité et la doc originelle du projet.
n'exagère pas, que ce soit chez Deb et Ian ou ailleurs la "doc originelle" attendra la mise en prod. ce n'est donc pas une distance mais une durée ;-)
Ça va bien nous aider tout ça, 'va y'en avoir de la passoire le temps que tout le monde maitrise le truc, tant est qu'il soit maitrisable.
c'est maîtrisable, les redhaterries de init.d le sont également puisqu'il suffit de les remplacer par des scripts écrits à peu près correctement (c-a-d qui ne cherchent pas à faire du systemd avant l'heure en imposant des suppositions quant à ce que l'admin voulait créer et quant avec quelles valeurs amusantes remplacer les trucs auquels il avait pensé :-) Et je ne plaisante pas, car ai dû remplacer divers scripts /etc/init.d "à la RedHat (mais pas forcément dans une RedHat)" par quelques lignes simples, fonctionnelles, fonctionnant et de bon goût plus qualques autres lignes de commentaire essplikatiff pas complètement de bon goût.
J'avoue n'avoir eu à commettre ces crimes de mise-au-point que sur des babassenprod contrakkktuellement redhattées (ou équivalent local et temporel) puisqu'évidemment aucune Slackware n'aurait pu mener à de telles atrocités ;-)
...
[SNIP tecnhique]
Et sans modif de ce fichier, votre sshd n'écoutera pas sur un autre port que le 22. Systemd sait ce qui est bien pour toi, et tu devras te plier à systemd. il va vraiment falloir renommer linux en linuxd, sshd en sshdd, etc..
J'ai toujours pensé que LP était un agent double à la solde de MS, un saboteur infiltré.
comment cela, il y aurait donc eu à un moment donné un doute sur ce point là ???
C'est rigolo systemd, c'est comme un boite de chocolat. Dans certains, il y a du poivre ou des araignées.
Je sens que dans cette boite il n'y en a pas tant que ça qui contiennent du cacao.
Tu t'égares sur les sentiers de l'entrelacé 819 lignes mais, comme l'a presque scripté Coleridge : "Que n'elle que n'elle et pas une croûte à voir" ;-) Cependant tu subodores avec clairvoyance quant au fondement de syxteemD, il est réellement "conçu" initialement en tant que BàM et les surcouches successives ne permettront pas d'isoler le ventilateur, planquez les singes et préparez les masques-à-gaz...
Wed, 29 Jan 2014 23:18:54 +1100, Doug713705 did cat :
Le 29-01-2014, Kevin Denis nous expliquait dans
fr.comp.os.linux.debats
(<slrnlei3jc.prb.kevin@slackwall.local.tux>) :
Comme vous le voyez, systemd ajoute son fichier de conf à sshd et
override tes options:
Ça plus le découpage des fichiers de conf à la Debian et on met 3 années
lumières entre la folle réalité et la doc originelle du projet.
n'exagère pas, que ce soit chez Deb et Ian ou ailleurs la "doc originelle"
attendra la mise en prod. ce n'est donc pas une distance mais une durée ;-)
Ça va bien nous aider tout ça, 'va y'en avoir de la passoire le temps
que tout le monde maitrise le truc, tant est qu'il soit maitrisable.
c'est maîtrisable, les redhaterries de init.d le sont également puisqu'il
suffit de les remplacer par des scripts écrits à peu près correctement
(c-a-d qui ne cherchent pas à faire du systemd avant l'heure en imposant des
suppositions quant à ce que l'admin voulait créer et quant avec quelles
valeurs amusantes remplacer les trucs auquels il avait pensé :-)
Et je ne plaisante pas, car ai dû remplacer divers scripts /etc/init.d
"à la RedHat (mais pas forcément dans une RedHat)" par quelques lignes
simples, fonctionnelles, fonctionnant et de bon goût plus qualques autres
lignes de commentaire essplikatiff pas complètement de bon goût.
J'avoue n'avoir eu à commettre ces crimes de mise-au-point que sur des
babassenprod contrakkktuellement redhattées (ou équivalent local et temporel)
puisqu'évidemment aucune Slackware n'aurait pu mener à de telles atrocités ;-)
...
[SNIP tecnhique]
Et sans modif de ce fichier, votre sshd n'écoutera pas sur un autre
port que le 22. Systemd sait ce qui est bien pour toi, et tu devras te
plier à systemd. il va vraiment falloir renommer linux en linuxd, sshd
en sshdd, etc..
J'ai toujours pensé que LP était un agent double à la solde de MS, un
saboteur infiltré.
comment cela, il y aurait donc eu à un moment donné un doute sur ce point là ???
C'est rigolo systemd, c'est comme un boite de chocolat. Dans
certains, il y a du poivre ou des araignées.
Je sens que dans cette boite il n'y en a pas tant que ça qui contiennent
du cacao.
Tu t'égares sur les sentiers de l'entrelacé 819 lignes mais, comme l'a presque
scripté Coleridge : "Que n'elle que n'elle et pas une croûte à voir" ;-)
Cependant tu subodores avec clairvoyance quant au fondement de syxteemD, il est
réellement "conçu" initialement en tant que BàM et les surcouches successives ne
permettront pas d'isoler le ventilateur, planquez les singes et préparez les masques-à-gaz...
Wed, 29 Jan 2014 23:18:54 +1100, Doug713705 did cat :
Le 29-01-2014, Kevin Denis nous expliquait dans fr.comp.os.linux.debats () :
Comme vous le voyez, systemd ajoute son fichier de conf à sshd et override tes options:
Ça plus le découpage des fichiers de conf à la Debian et on met 3 années lumières entre la folle réalité et la doc originelle du projet.
n'exagère pas, que ce soit chez Deb et Ian ou ailleurs la "doc originelle" attendra la mise en prod. ce n'est donc pas une distance mais une durée ;-)
Ça va bien nous aider tout ça, 'va y'en avoir de la passoire le temps que tout le monde maitrise le truc, tant est qu'il soit maitrisable.
c'est maîtrisable, les redhaterries de init.d le sont également puisqu'il suffit de les remplacer par des scripts écrits à peu près correctement (c-a-d qui ne cherchent pas à faire du systemd avant l'heure en imposant des suppositions quant à ce que l'admin voulait créer et quant avec quelles valeurs amusantes remplacer les trucs auquels il avait pensé :-) Et je ne plaisante pas, car ai dû remplacer divers scripts /etc/init.d "à la RedHat (mais pas forcément dans une RedHat)" par quelques lignes simples, fonctionnelles, fonctionnant et de bon goût plus qualques autres lignes de commentaire essplikatiff pas complètement de bon goût.
J'avoue n'avoir eu à commettre ces crimes de mise-au-point que sur des babassenprod contrakkktuellement redhattées (ou équivalent local et temporel) puisqu'évidemment aucune Slackware n'aurait pu mener à de telles atrocités ;-)
...
[SNIP tecnhique]
Et sans modif de ce fichier, votre sshd n'écoutera pas sur un autre port que le 22. Systemd sait ce qui est bien pour toi, et tu devras te plier à systemd. il va vraiment falloir renommer linux en linuxd, sshd en sshdd, etc..
J'ai toujours pensé que LP était un agent double à la solde de MS, un saboteur infiltré.
comment cela, il y aurait donc eu à un moment donné un doute sur ce point là ???
C'est rigolo systemd, c'est comme un boite de chocolat. Dans certains, il y a du poivre ou des araignées.
Je sens que dans cette boite il n'y en a pas tant que ça qui contiennent du cacao.
Tu t'égares sur les sentiers de l'entrelacé 819 lignes mais, comme l'a presque scripté Coleridge : "Que n'elle que n'elle et pas une croûte à voir" ;-) Cependant tu subodores avec clairvoyance quant au fondement de syxteemD, il est réellement "conçu" initialement en tant que BàM et les surcouches successives ne permettront pas d'isoler le ventilateur, planquez les singes et préparez les masques-à-gaz...
Doug713705
Le 29-01-2014, Loki Harfagr nous expliquait dans fr.comp.os.linux.debats (<pan$543f3$ad3c86bc$1caae878$) :
Wed, 29 Jan 2014 23:18:54 +1100, Doug713705 did cat :
Le 29-01-2014, Kevin Denis nous expliquait dans fr.comp.os.linux.debats () :
Comme vous le voyez, systemd ajoute son fichier de conf à sshd et override tes options:
Ça plus le découpage des fichiers de conf à la Debian et on met 3 années lumières entre la folle réalité et la doc originelle du projet.
n'exagère pas, que ce soit chez Deb et Ian ou ailleurs la "doc originelle" attendra la mise en prod. ce n'est donc pas une distance mais une durée ;-)
pour éclaircir et prendre un exemple, tu prends la doc 'originelle' d'Apache et tu t'aperçois qu'avec une Slackware, no problemo, tout fonctionne comme dans la doc. Sur une Debian c'est déjà un peu plus funky puisqu'il faut commencer par retouver dans quel sous fichier de conf est tel ou tel paramètre. On s'éloigne donc de cette doc orginelle.
Là dessus tu rajoutes systemd et là, magie, la doc originelle ne sert plus à rien, tu peux la mettre à la poubelle de toute façon elle correspond pas du tout à ce que tu as face à toi.
Et ça, ça a le dont de m'horripiler à un point inimaginable.
On en trouvera pour dire, oui mais les docs spécifiques sont fournies, il faut les lire, RTFM, toussa. Ok, super les mecs, mais si le projet originel s'emmerde à faire une doc ce n'est pas pour que des zozos empaqueteurs aux heures perdues viennent y foutre le bordel de manière à perturber l'admin qui n'a pas QUE du Debian (par exemple, hein, y'en a d'autres dans le même genre) à gérer.
Et maintenant v'la t'y pas que systemd en remet une couche ! Manquerait plus que, pour aller plus loin dans la mise en abime, Debian fasse une adpatation toute debianesque de systemd et la boucle sera bouclée.
Bon, je dis ça mais je ne suis pas un pro, juste un amateur éclairé mais déjà ça me gonfle, alors un pro qui doit jongler entre 4 ou 5 distribs ça doit les lui briser menu toutes ces conneries.
[SNIP]
J'ai toujours pensé que LP était un agent double à la solde de MS, un saboteur infiltré.
comment cela, il y aurait donc eu à un moment donné un doute sur ce point là ???
Je tenais à rappeler ce qui découle du bon sens :-)
C'est rigolo systemd, c'est comme un boite de chocolat. Dans certains, il y a du poivre ou des araignées.
Je sens que dans cette boite il n'y en a pas tant que ça qui contiennent du cacao.
Tu t'égares sur les sentiers de l'entrelacé 819 lignes mais, comme l'a presque scripté Coleridge : "Que n'elle que n'elle et pas une croûte à voir" ;-) Cependant tu subodores avec clairvoyance quant au fondement de syxteemD, il est réellement "conçu" initialement en tant que BàM et les surcouches successives ne permettront pas d'isoler le ventilateur, planquez les singes et préparez les masques-à-gaz...
BàM ? Boite à merde ? Ça collerait bien :-)
-- Les feuilles tombent des cocas Et se répandent sur l'Occident Demain tu verras tous ces petits alchimistes Pulvériser un continent -- H.F. Thiéfaine, Le chant du fou
Le 29-01-2014, Loki Harfagr nous expliquait dans
fr.comp.os.linux.debats
(<pan$543f3$ad3c86bc$1caae878$c2708310@thedarkdesign.free.fr.INVALID>) :
Wed, 29 Jan 2014 23:18:54 +1100, Doug713705 did cat :
Le 29-01-2014, Kevin Denis nous expliquait dans
fr.comp.os.linux.debats
(<slrnlei3jc.prb.kevin@slackwall.local.tux>) :
Comme vous le voyez, systemd ajoute son fichier de conf à sshd et
override tes options:
Ça plus le découpage des fichiers de conf à la Debian et on met 3 années
lumières entre la folle réalité et la doc originelle du projet.
n'exagère pas, que ce soit chez Deb et Ian ou ailleurs la "doc originelle"
attendra la mise en prod. ce n'est donc pas une distance mais une durée ;-)
pour éclaircir et prendre un exemple, tu prends la doc 'originelle'
d'Apache et tu t'aperçois qu'avec une Slackware, no problemo, tout
fonctionne comme dans la doc. Sur une Debian c'est déjà un peu plus
funky puisqu'il faut commencer par retouver dans quel sous fichier de
conf est tel ou tel paramètre. On s'éloigne donc de cette doc orginelle.
Là dessus tu rajoutes systemd et là, magie, la doc originelle ne sert
plus à rien, tu peux la mettre à la poubelle de toute façon elle
correspond pas du tout à ce que tu as face à toi.
Et ça, ça a le dont de m'horripiler à un point inimaginable.
On en trouvera pour dire, oui mais les docs spécifiques sont fournies,
il faut les lire, RTFM, toussa. Ok, super les mecs, mais si le projet
originel s'emmerde à faire une doc ce n'est pas pour que des zozos
empaqueteurs aux heures perdues viennent y foutre le bordel de manière à
perturber l'admin qui n'a pas QUE du Debian (par exemple, hein, y'en a
d'autres dans le même genre) à gérer.
Et maintenant v'la t'y pas que systemd en remet une couche ! Manquerait
plus que, pour aller plus loin dans la mise en abime, Debian fasse une
adpatation toute debianesque de systemd et la boucle sera bouclée.
Bon, je dis ça mais je ne suis pas un pro, juste un amateur éclairé mais
déjà ça me gonfle, alors un pro qui doit jongler entre 4 ou 5 distribs
ça doit les lui briser menu toutes ces conneries.
[SNIP]
J'ai toujours pensé que LP était un agent double à la solde de MS, un
saboteur infiltré.
comment cela, il y aurait donc eu à un moment donné un doute sur ce point là ???
Je tenais à rappeler ce qui découle du bon sens :-)
C'est rigolo systemd, c'est comme un boite de chocolat. Dans
certains, il y a du poivre ou des araignées.
Je sens que dans cette boite il n'y en a pas tant que ça qui contiennent
du cacao.
Tu t'égares sur les sentiers de l'entrelacé 819 lignes mais, comme l'a presque
scripté Coleridge : "Que n'elle que n'elle et pas une croûte à voir" ;-)
Cependant tu subodores avec clairvoyance quant au fondement de syxteemD, il est
réellement "conçu" initialement en tant que BàM et les surcouches successives ne
permettront pas d'isoler le ventilateur, planquez les singes et préparez les masques-à-gaz...
BàM ? Boite à merde ? Ça collerait bien :-)
--
Les feuilles tombent des cocas
Et se répandent sur l'Occident
Demain tu verras tous ces petits alchimistes
Pulvériser un continent
-- H.F. Thiéfaine, Le chant du fou
Le 29-01-2014, Loki Harfagr nous expliquait dans fr.comp.os.linux.debats (<pan$543f3$ad3c86bc$1caae878$) :
Wed, 29 Jan 2014 23:18:54 +1100, Doug713705 did cat :
Le 29-01-2014, Kevin Denis nous expliquait dans fr.comp.os.linux.debats () :
Comme vous le voyez, systemd ajoute son fichier de conf à sshd et override tes options:
Ça plus le découpage des fichiers de conf à la Debian et on met 3 années lumières entre la folle réalité et la doc originelle du projet.
n'exagère pas, que ce soit chez Deb et Ian ou ailleurs la "doc originelle" attendra la mise en prod. ce n'est donc pas une distance mais une durée ;-)
pour éclaircir et prendre un exemple, tu prends la doc 'originelle' d'Apache et tu t'aperçois qu'avec une Slackware, no problemo, tout fonctionne comme dans la doc. Sur une Debian c'est déjà un peu plus funky puisqu'il faut commencer par retouver dans quel sous fichier de conf est tel ou tel paramètre. On s'éloigne donc de cette doc orginelle.
Là dessus tu rajoutes systemd et là, magie, la doc originelle ne sert plus à rien, tu peux la mettre à la poubelle de toute façon elle correspond pas du tout à ce que tu as face à toi.
Et ça, ça a le dont de m'horripiler à un point inimaginable.
On en trouvera pour dire, oui mais les docs spécifiques sont fournies, il faut les lire, RTFM, toussa. Ok, super les mecs, mais si le projet originel s'emmerde à faire une doc ce n'est pas pour que des zozos empaqueteurs aux heures perdues viennent y foutre le bordel de manière à perturber l'admin qui n'a pas QUE du Debian (par exemple, hein, y'en a d'autres dans le même genre) à gérer.
Et maintenant v'la t'y pas que systemd en remet une couche ! Manquerait plus que, pour aller plus loin dans la mise en abime, Debian fasse une adpatation toute debianesque de systemd et la boucle sera bouclée.
Bon, je dis ça mais je ne suis pas un pro, juste un amateur éclairé mais déjà ça me gonfle, alors un pro qui doit jongler entre 4 ou 5 distribs ça doit les lui briser menu toutes ces conneries.
[SNIP]
J'ai toujours pensé que LP était un agent double à la solde de MS, un saboteur infiltré.
comment cela, il y aurait donc eu à un moment donné un doute sur ce point là ???
Je tenais à rappeler ce qui découle du bon sens :-)
C'est rigolo systemd, c'est comme un boite de chocolat. Dans certains, il y a du poivre ou des araignées.
Je sens que dans cette boite il n'y en a pas tant que ça qui contiennent du cacao.
Tu t'égares sur les sentiers de l'entrelacé 819 lignes mais, comme l'a presque scripté Coleridge : "Que n'elle que n'elle et pas une croûte à voir" ;-) Cependant tu subodores avec clairvoyance quant au fondement de syxteemD, il est réellement "conçu" initialement en tant que BàM et les surcouches successives ne permettront pas d'isoler le ventilateur, planquez les singes et préparez les masques-à-gaz...
BàM ? Boite à merde ? Ça collerait bien :-)
-- Les feuilles tombent des cocas Et se répandent sur l'Occident Demain tu verras tous ces petits alchimistes Pulvériser un continent -- H.F. Thiéfaine, Le chant du fou
Nicolas George
Doug713705 , dans le message , a écrit :
pour éclaircir et prendre un exemple, tu prends la doc 'originelle' d'Apache et tu t'aperçois qu'avec une Slackware, no problemo, tout fonctionne comme dans la doc. Sur une Debian c'est déjà un peu plus funky puisqu'il faut commencer par retouver dans quel sous fichier de conf est tel ou tel paramètre. On s'éloigne donc de cette doc orginelle.
Ce que tu racontes est faux. Les packages Debian d'Apache peuvent parfaitement s'utiliser en suivant la doc originale. Il suffit pour ça de virer les fichiers de config fournis par Debian et de repartir de ceux d'exemple. Rien ne t'oblige à utiliser les fichiers de config de Debian.
Si tu décides de les utiliser, en revanche, tu pourras profiter de la valeur ajoutée par Debian : le fait que l'installation d'un paquet de plugin va configurer automatiquement ou semi-automatiquement le serveur en conséquence. C'est incompatible avec l'organisation officielle des fichiers de config, parce qu'ils ne sont pas faits pour être éditables par un programme.
Là dessus tu rajoutes systemd et là, magie, la doc originelle ne sert plus à rien, tu peux la mettre à la poubelle de toute façon elle correspond pas du tout à ce que tu as face à toi.
Systemd m'a tout l'air d'être une bouze, mais ton argument est encore de mauvaise foi : ce n'est pas la faute de systemd si l'administrateur n'est pas fichu de voir que son sshd est lancé avec l'option -i, et cette option est parfaitement documentée.
Doug713705 , dans le message <91jorax7v7.ln2@actarus.bourzy.lan>, a
écrit :
pour éclaircir et prendre un exemple, tu prends la doc 'originelle'
d'Apache et tu t'aperçois qu'avec une Slackware, no problemo, tout
fonctionne comme dans la doc. Sur une Debian c'est déjà un peu plus
funky puisqu'il faut commencer par retouver dans quel sous fichier de
conf est tel ou tel paramètre. On s'éloigne donc de cette doc orginelle.
Ce que tu racontes est faux. Les packages Debian d'Apache peuvent
parfaitement s'utiliser en suivant la doc originale. Il suffit pour ça de
virer les fichiers de config fournis par Debian et de repartir de ceux
d'exemple. Rien ne t'oblige à utiliser les fichiers de config de Debian.
Si tu décides de les utiliser, en revanche, tu pourras profiter de la valeur
ajoutée par Debian : le fait que l'installation d'un paquet de plugin va
configurer automatiquement ou semi-automatiquement le serveur en
conséquence. C'est incompatible avec l'organisation officielle des fichiers
de config, parce qu'ils ne sont pas faits pour être éditables par un
programme.
Là dessus tu rajoutes systemd et là, magie, la doc originelle ne sert
plus à rien, tu peux la mettre à la poubelle de toute façon elle
correspond pas du tout à ce que tu as face à toi.
Systemd m'a tout l'air d'être une bouze, mais ton argument est encore de
mauvaise foi : ce n'est pas la faute de systemd si l'administrateur n'est
pas fichu de voir que son sshd est lancé avec l'option -i, et cette option
est parfaitement documentée.
pour éclaircir et prendre un exemple, tu prends la doc 'originelle' d'Apache et tu t'aperçois qu'avec une Slackware, no problemo, tout fonctionne comme dans la doc. Sur une Debian c'est déjà un peu plus funky puisqu'il faut commencer par retouver dans quel sous fichier de conf est tel ou tel paramètre. On s'éloigne donc de cette doc orginelle.
Ce que tu racontes est faux. Les packages Debian d'Apache peuvent parfaitement s'utiliser en suivant la doc originale. Il suffit pour ça de virer les fichiers de config fournis par Debian et de repartir de ceux d'exemple. Rien ne t'oblige à utiliser les fichiers de config de Debian.
Si tu décides de les utiliser, en revanche, tu pourras profiter de la valeur ajoutée par Debian : le fait que l'installation d'un paquet de plugin va configurer automatiquement ou semi-automatiquement le serveur en conséquence. C'est incompatible avec l'organisation officielle des fichiers de config, parce qu'ils ne sont pas faits pour être éditables par un programme.
Là dessus tu rajoutes systemd et là, magie, la doc originelle ne sert plus à rien, tu peux la mettre à la poubelle de toute façon elle correspond pas du tout à ce que tu as face à toi.
Systemd m'a tout l'air d'être une bouze, mais ton argument est encore de mauvaise foi : ce n'est pas la faute de systemd si l'administrateur n'est pas fichu de voir que son sshd est lancé avec l'option -i, et cette option est parfaitement documentée.
Loki Harfagr
Thu, 30 Jan 2014 15:40:23 +0000, Nicolas George did cat :
Systemd m'a tout l'air d'être une bouze,
je confirme que c'est l'idée que ça m'évoque jusqu'à présent (au cas où quelqu'un aurait eu un doute sur mes précédentes irréflexions sur ce WImP) malheureusement c'est une bouse qui bouge encore...
mais ton argument est encore de mauvaise foi : ce n'est pas la faute de systemd si l'administrateur n'est pas fichu de voir que son sshd est lancé avec l'option -i, et cette option est parfaitement documentée.
là tu m'évoques brusquement la plausibilité de ce que systemd (et peut- être alors tous les autres ``fumets'' de Lynyrd ?) pourrait simplement s'avérer être un plan de "work insurance" ?-)
Thu, 30 Jan 2014 15:40:23 +0000, Nicolas George did cat :
Systemd m'a tout l'air d'être une bouze,
je confirme que c'est l'idée que ça m'évoque jusqu'à présent
(au cas où quelqu'un aurait eu un doute sur mes précédentes
irréflexions sur ce WImP)
malheureusement c'est une bouse qui bouge encore...
mais ton argument est encore de
mauvaise foi : ce n'est pas la faute de systemd si l'administrateur n'est
pas fichu de voir que son sshd est lancé avec l'option -i, et cette option
est parfaitement documentée.
là tu m'évoques brusquement la plausibilité de ce que systemd (et peut-
être alors tous les autres ``fumets'' de Lynyrd ?) pourrait simplement
s'avérer être un plan de "work insurance" ?-)
Thu, 30 Jan 2014 15:40:23 +0000, Nicolas George did cat :
Systemd m'a tout l'air d'être une bouze,
je confirme que c'est l'idée que ça m'évoque jusqu'à présent (au cas où quelqu'un aurait eu un doute sur mes précédentes irréflexions sur ce WImP) malheureusement c'est une bouse qui bouge encore...
mais ton argument est encore de mauvaise foi : ce n'est pas la faute de systemd si l'administrateur n'est pas fichu de voir que son sshd est lancé avec l'option -i, et cette option est parfaitement documentée.
là tu m'évoques brusquement la plausibilité de ce que systemd (et peut- être alors tous les autres ``fumets'' de Lynyrd ?) pourrait simplement s'avérer être un plan de "work insurance" ?-)
