Je poste ici en désespoir de cause, ça fait une heure que je m'arrache
les cheveux la dessus et pour ne rien arranger, sur groups.google, les
archives de fcolc sont indisponibles.
J'ai écrit un fichier dans /etc/cron.d pour rebooter chaque nuit ma
CI-box qui merdouille gaiement.
Pour tester je l'ai mis en exécution toutes les minutes. Bin ça veut pô !
J'ai regardé dans les logs : que dalle (et pourtant je vois bien la
trace de l'exécution de deux scripts php qui s'exécutent toutes les
minutes, la preuve :
8<-----------8<---------8<----------8<----------8<----------8<----------8<
Jul 17 17:09:01 deborah /USR/SBIN/CRON[10296]: (root) CMD (test -x
/var/www/server-stats/load-stats.php &&
/var/www/server-stats/load-stats.php >/dev/null )
Jul 17 17:09:01 deborah /USR/SBIN/CRON[10297]: (root) CMD (test -x
/var/www/server-stats/net-stats.php &&
/var/www/server-stats/net-stats.php >/dev/null )
8<-----------8<---------8<----------8<----------8<----------8<----------8<
et mon script marche très bien quand je le lance depuis bash.
La tâche /etc/cron.d/CI-Box_Reboot.cron :
8<-----------8<---------8<----------8<----------8<----------8<----------8<
# crontab entrie to reboot the CI-Box
--
> On a déjà une idée du nom du futur fork pour Debian ?
Debian fera un fork pour la prochaine version stable. On a donc quatre
ou cinq ans pour trouver un nom.
Hugo (né il y a 1 363 915 312 secondes)
On 17 Jul 2007 18:34:20 GMT, Nicolas George <nicolas$:
Mais d'un point de vue utilitaire, il y a une différence considérable entre les tâches remplies pour le compte d'un utilisateur, et les tâches remplies pour le compte du système.
Sur le principe, je suis d'accord. Toutefois...
D'une part, j'ai du mal à cerner la frontière entre les deux. La gestion de qmail, par exemple, c'est du ressort de l'utilisateur "qmail-quelquechose", ou de celui du système ?
D'autre part, si une tâche, même concernant le système, peut être lancée avec un compte utilisateur autre que root, elle doit l'être. Mais AMHA, la mise en place de cette tâche cron doit aussi être exécutée par cet utilisateur, suivant le principe du "Ne deviens root que si tu n'as pas d'autre choix". Du coup, le crontab me paraît la solution la plus pratique. Mais je peux me gourer ; j'ai peu d'expérience dans le maniement de /etc/cron*.
On 17 Jul 2007 18:34:20 GMT, Nicolas George
<nicolas$george@salle-s.org>:
Mais d'un point de vue utilitaire, il y a une
différence considérable entre les tâches remplies pour le compte d'un
utilisateur, et les tâches remplies pour le compte du système.
Sur le principe, je suis d'accord. Toutefois...
D'une part, j'ai du mal à cerner la frontière entre les deux. La
gestion de qmail, par exemple, c'est du ressort de l'utilisateur
"qmail-quelquechose", ou de celui du système ?
D'autre part, si une tâche, même concernant le système, peut être
lancée avec un compte utilisateur autre que root, elle doit l'être.
Mais AMHA, la mise en place de cette tâche cron doit aussi être
exécutée par cet utilisateur, suivant le principe du "Ne deviens root
que si tu n'as pas d'autre choix". Du coup, le crontab me paraît la
solution la plus pratique. Mais je peux me gourer ; j'ai peu
d'expérience dans le maniement de /etc/cron*.
On 17 Jul 2007 18:34:20 GMT, Nicolas George <nicolas$:
Mais d'un point de vue utilitaire, il y a une différence considérable entre les tâches remplies pour le compte d'un utilisateur, et les tâches remplies pour le compte du système.
Sur le principe, je suis d'accord. Toutefois...
D'une part, j'ai du mal à cerner la frontière entre les deux. La gestion de qmail, par exemple, c'est du ressort de l'utilisateur "qmail-quelquechose", ou de celui du système ?
D'autre part, si une tâche, même concernant le système, peut être lancée avec un compte utilisateur autre que root, elle doit l'être. Mais AMHA, la mise en place de cette tâche cron doit aussi être exécutée par cet utilisateur, suivant le principe du "Ne deviens root que si tu n'as pas d'autre choix". Du coup, le crontab me paraît la solution la plus pratique. Mais je peux me gourer ; j'ai peu d'expérience dans le maniement de /etc/cron*.
Nicolas George
Fabien LE LEZ wrote in message :
D'une part, j'ai du mal à cerner la frontière entre les deux. La gestion de qmail, par exemple, c'est du ressort de l'utilisateur "qmail-quelquechose", ou de celui du système ?
Je n'ai jamais rencontré de personne nommée « Qmail-Quelquechose », donc c'est du ressort du système.
D'autre part, si une tâche, même concernant le système, peut être lancée avec un compte utilisateur autre que root, elle doit l'être.
Je suis d'accord, sauf sur le terme « compte utilisateur », qui doit à mon avis être réservé au cas des vrais utilisateurs humains. Les utilisateurs système ne correspondent pas à des « comptes ».
Mais AMHA, la mise en place de cette tâche cron doit aussi être exécutée par cet utilisateur, suivant le principe du "Ne deviens root que si tu n'as pas d'autre choix". Du coup, le crontab me paraît la solution la plus pratique.
Là, je ne suis plus d'accord. Le principe des utilisateurs système dédiés à certaines tâches, c'est justement de restreindre leurs droits au maximum. Et le fait d'avoir une crontab est un droit très élevé, parce qu'il permet de faire revenir des choses après un reboot ou un kill. Donc au contraire, ces utilisateurs ne devraient en aucun cas avoir le droit d'avoir une crontab personnelle.
Fabien LE LEZ wrote in message
<ubdq93hlsqfbe0o3it6are15rujqvlb1rh@4ax.com>:
D'une part, j'ai du mal à cerner la frontière entre les deux. La
gestion de qmail, par exemple, c'est du ressort de l'utilisateur
"qmail-quelquechose", ou de celui du système ?
Je n'ai jamais rencontré de personne nommée « Qmail-Quelquechose », donc
c'est du ressort du système.
D'autre part, si une tâche, même concernant le système, peut être
lancée avec un compte utilisateur autre que root, elle doit l'être.
Je suis d'accord, sauf sur le terme « compte utilisateur », qui doit à mon
avis être réservé au cas des vrais utilisateurs humains. Les utilisateurs
système ne correspondent pas à des « comptes ».
Mais AMHA, la mise en place de cette tâche cron doit aussi être
exécutée par cet utilisateur, suivant le principe du "Ne deviens root
que si tu n'as pas d'autre choix". Du coup, le crontab me paraît la
solution la plus pratique.
Là, je ne suis plus d'accord. Le principe des utilisateurs système dédiés à
certaines tâches, c'est justement de restreindre leurs droits au maximum. Et
le fait d'avoir une crontab est un droit très élevé, parce qu'il permet de
faire revenir des choses après un reboot ou un kill. Donc au contraire, ces
utilisateurs ne devraient en aucun cas avoir le droit d'avoir une crontab
personnelle.
D'une part, j'ai du mal à cerner la frontière entre les deux. La gestion de qmail, par exemple, c'est du ressort de l'utilisateur "qmail-quelquechose", ou de celui du système ?
Je n'ai jamais rencontré de personne nommée « Qmail-Quelquechose », donc c'est du ressort du système.
D'autre part, si une tâche, même concernant le système, peut être lancée avec un compte utilisateur autre que root, elle doit l'être.
Je suis d'accord, sauf sur le terme « compte utilisateur », qui doit à mon avis être réservé au cas des vrais utilisateurs humains. Les utilisateurs système ne correspondent pas à des « comptes ».
Mais AMHA, la mise en place de cette tâche cron doit aussi être exécutée par cet utilisateur, suivant le principe du "Ne deviens root que si tu n'as pas d'autre choix". Du coup, le crontab me paraît la solution la plus pratique.
Là, je ne suis plus d'accord. Le principe des utilisateurs système dédiés à certaines tâches, c'est justement de restreindre leurs droits au maximum. Et le fait d'avoir une crontab est un droit très élevé, parce qu'il permet de faire revenir des choses après un reboot ou un kill. Donc au contraire, ces utilisateurs ne devraient en aucun cas avoir le droit d'avoir une crontab personnelle.
Fabien LE LEZ
On 17 Jul 2007 21:59:39 GMT, Nicolas George :
D'une part, j'ai du mal à cerner la frontière entre les deux. La gestion de qmail, par exemple, c'est du ressort de l'utilisateur "qmail-quelquechose", ou de celui du système ?
Je n'ai jamais rencontré de personne nommée « Qmail-Quelquechose », donc c'est du ressort du système.
Pour le coup, je ne suis pas d'accord. Pour moi, "le système", c'est le minimum : le noyau, init, la couche TCP/IP, et pas grand-chose d'autre. Qmail (ou Apache, ou autre service du même style) est un truc séparé. Un deuxième système, si tu veux, mais le plus indépendant possible de l'OS. Dans l'idéal, il serait dans un chroot ou autre machin visant à l'isoler.
D'autre part, si une tâche, même concernant le système, peut être lancée avec un compte utilisateur autre que root, elle doit l'être.
Je suis d'accord, sauf sur le terme « compte utilisateur », qui doit à mon avis être réservé au cas des vrais utilisateurs humains. Les utilisateurs système ne correspondent pas à des « comptes ».
Admettons. Que proposes-tu comme mot ou expression pour désigner une entrée dans /etc/passwd ?
Par ailleurs, il n'y a pas forcément de correspondance entre "humain" et "utilisateur au sens de /etc/passwd". Un humain peut avoir plusieurs comptes, et un compte peut servir à plusieurs humains.
Mais AMHA, la mise en place de cette tâche cron doit aussi être exécutée par cet utilisateur, suivant le principe du "Ne deviens root que si tu n'as pas d'autre choix". Du coup, le crontab me paraît la solution la plus pratique.
Là, je ne suis plus d'accord. Le principe des utilisateurs système dédiés à certaines tâches, c'est justement de restreindre leurs droits au maximum. Et le fait d'avoir une crontab est un droit très élevé, parce qu'il permet de faire revenir des choses après un reboot ou un kill. Donc au contraire, ces utilisateurs ne devraient en aucun cas avoir le droit d'avoir une crontab personnelle.
On peut éventuellement créer un utilisateur (dans le sens "entrée dans /etc/passwd") par service, rien que pour ça. Mais mon argument était plutôt que ce n'est pas à root de s'en charger.
Par ailleurs, j'ai des doutes sur la dangerosité d'un crontab. Tu écris :
le fait d'avoir une crontab est un droit très élevé, parce qu'il permet de faire revenir des choses après un reboot ou un kill.
et j'ai du mal à comprendre dans quel(s) cas ça peut être un problème.
En usage normal, tu peux redémarrer ta machine, ou tuer et redémarrer un processus. Dans les deux cas, s'il est corrompu, il va continuer à faire des conneries, sans avoir besoin de crontab.
Et si tu tues un processus parce que tu penses qu'il est corrompu, tu vas de toutes façons vérifier son crontab, voire réinstaller Linux.
On 17 Jul 2007 21:59:39 GMT, Nicolas George :
D'une part, j'ai du mal à cerner la frontière entre les deux. La
gestion de qmail, par exemple, c'est du ressort de l'utilisateur
"qmail-quelquechose", ou de celui du système ?
Je n'ai jamais rencontré de personne nommée « Qmail-Quelquechose », donc
c'est du ressort du système.
Pour le coup, je ne suis pas d'accord.
Pour moi, "le système", c'est le minimum : le noyau, init, la couche
TCP/IP, et pas grand-chose d'autre.
Qmail (ou Apache, ou autre service du même style) est un truc séparé.
Un deuxième système, si tu veux, mais le plus indépendant possible de
l'OS. Dans l'idéal, il serait dans un chroot ou autre machin visant à
l'isoler.
D'autre part, si une tâche, même concernant le système, peut être
lancée avec un compte utilisateur autre que root, elle doit l'être.
Je suis d'accord, sauf sur le terme « compte utilisateur », qui doit à mon
avis être réservé au cas des vrais utilisateurs humains. Les utilisateurs
système ne correspondent pas à des « comptes ».
Admettons. Que proposes-tu comme mot ou expression pour désigner une
entrée dans /etc/passwd ?
Par ailleurs, il n'y a pas forcément de correspondance entre "humain"
et "utilisateur au sens de /etc/passwd". Un humain peut avoir
plusieurs comptes, et un compte peut servir à plusieurs humains.
Mais AMHA, la mise en place de cette tâche cron doit aussi être
exécutée par cet utilisateur, suivant le principe du "Ne deviens root
que si tu n'as pas d'autre choix". Du coup, le crontab me paraît la
solution la plus pratique.
Là, je ne suis plus d'accord. Le principe des utilisateurs système dédiés à
certaines tâches, c'est justement de restreindre leurs droits au maximum. Et
le fait d'avoir une crontab est un droit très élevé, parce qu'il permet de
faire revenir des choses après un reboot ou un kill. Donc au contraire, ces
utilisateurs ne devraient en aucun cas avoir le droit d'avoir une crontab
personnelle.
On peut éventuellement créer un utilisateur (dans le sens "entrée dans
/etc/passwd") par service, rien que pour ça.
Mais mon argument était plutôt que ce n'est pas à root de s'en
charger.
Par ailleurs, j'ai des doutes sur la dangerosité d'un crontab.
Tu écris :
le fait d'avoir une crontab est un droit très élevé, parce qu'il permet de
faire revenir des choses après un reboot ou un kill.
et j'ai du mal à comprendre dans quel(s) cas ça peut être un problème.
En usage normal, tu peux redémarrer ta machine, ou tuer et redémarrer
un processus. Dans les deux cas, s'il est corrompu, il va continuer à
faire des conneries, sans avoir besoin de crontab.
Et si tu tues un processus parce que tu penses qu'il est corrompu, tu
vas de toutes façons vérifier son crontab, voire réinstaller Linux.
D'une part, j'ai du mal à cerner la frontière entre les deux. La gestion de qmail, par exemple, c'est du ressort de l'utilisateur "qmail-quelquechose", ou de celui du système ?
Je n'ai jamais rencontré de personne nommée « Qmail-Quelquechose », donc c'est du ressort du système.
Pour le coup, je ne suis pas d'accord. Pour moi, "le système", c'est le minimum : le noyau, init, la couche TCP/IP, et pas grand-chose d'autre. Qmail (ou Apache, ou autre service du même style) est un truc séparé. Un deuxième système, si tu veux, mais le plus indépendant possible de l'OS. Dans l'idéal, il serait dans un chroot ou autre machin visant à l'isoler.
D'autre part, si une tâche, même concernant le système, peut être lancée avec un compte utilisateur autre que root, elle doit l'être.
Je suis d'accord, sauf sur le terme « compte utilisateur », qui doit à mon avis être réservé au cas des vrais utilisateurs humains. Les utilisateurs système ne correspondent pas à des « comptes ».
Admettons. Que proposes-tu comme mot ou expression pour désigner une entrée dans /etc/passwd ?
Par ailleurs, il n'y a pas forcément de correspondance entre "humain" et "utilisateur au sens de /etc/passwd". Un humain peut avoir plusieurs comptes, et un compte peut servir à plusieurs humains.
Mais AMHA, la mise en place de cette tâche cron doit aussi être exécutée par cet utilisateur, suivant le principe du "Ne deviens root que si tu n'as pas d'autre choix". Du coup, le crontab me paraît la solution la plus pratique.
Là, je ne suis plus d'accord. Le principe des utilisateurs système dédiés à certaines tâches, c'est justement de restreindre leurs droits au maximum. Et le fait d'avoir une crontab est un droit très élevé, parce qu'il permet de faire revenir des choses après un reboot ou un kill. Donc au contraire, ces utilisateurs ne devraient en aucun cas avoir le droit d'avoir une crontab personnelle.
On peut éventuellement créer un utilisateur (dans le sens "entrée dans /etc/passwd") par service, rien que pour ça. Mais mon argument était plutôt que ce n'est pas à root de s'en charger.
Par ailleurs, j'ai des doutes sur la dangerosité d'un crontab. Tu écris :
le fait d'avoir une crontab est un droit très élevé, parce qu'il permet de faire revenir des choses après un reboot ou un kill.
et j'ai du mal à comprendre dans quel(s) cas ça peut être un problème.
En usage normal, tu peux redémarrer ta machine, ou tuer et redémarrer un processus. Dans les deux cas, s'il est corrompu, il va continuer à faire des conneries, sans avoir besoin de crontab.
Et si tu tues un processus parce que tu penses qu'il est corrompu, tu vas de toutes façons vérifier son crontab, voire réinstaller Linux.
Nicolas George
Erwan David wrote in message :
Le système n'a aucune notion d'utilisateurs humains ou pas humains, il a des comptes et c'est tout.
Techniquement, c'est vrai. Mais d'un point de vue utilitaire, il y a une différence considérable.
(bis)
Erwan David wrote in message <m2ps2qhep7.fsf@rail.eu.org>:
Le système n'a aucune notion d'utilisateurs humains ou pas humains, il a
des comptes et c'est tout.
Techniquement, c'est vrai. Mais d'un point de vue utilitaire, il y a une
différence considérable.
Le système n'a aucune notion d'utilisateurs humains ou pas humains, il a des comptes et c'est tout.
Techniquement, c'est vrai. Mais d'un point de vue utilitaire, il y a une différence considérable.
(bis)
Nicolas George
Fabien LE LEZ wrote in message :
Pour moi, "le système", c'est le minimum : le noyau, init, la couche TCP/IP, et pas grand-chose d'autre.
Eh bien on ne désigne pas la même chose par ce mot, c'est tout.
Admettons. Que proposes-tu comme mot ou expression pour désigner une entrée dans /etc/passwd ?
Je n'en vois pas, mais ce n'est pas grave, puisqu'en général il n'y pas ambiguïté.
On peut éventuellement créer un utilisateur (dans le sens "entrée dans /etc/passwd") par service, rien que pour ça.
On a déjà fait ça, ce n'est pas ça le problème.
et j'ai du mal à comprendre dans quel(s) cas ça peut être un problème.
En usage normal, tu peux redémarrer ta machine, ou tuer et redémarrer un processus. Dans les deux cas, s'il est corrompu, il va continuer à faire des conneries, sans avoir besoin de crontab.
Et si tu tues un processus parce que tu penses qu'il est corrompu, tu vas de toutes façons vérifier son crontab, voire réinstaller Linux.
Plus la vérification est complexe, et plus il y a de risque de se tromper. Que faut-il regarder, si on soupçonne qu'un UID est compromis ? La crontab. Les at-jobs. Le .forward, le .procmailrc, le .ssh/authorized_keys, le .ssh/environment, le .pforile, j'en passe.
À chaque fois qu'un UID est autorisé à avoir un de ces éléments, ça génère du bruit dans la vérification de l'intégrité de la configuration, bruit qui peut masquer une compromission.
Dit autrement : l'UID qmail-machin, il sert à faire machin pour qmail, et pas un pouillème de plus. En particulier, cet UID ne doit pas avoir le droit de configurer quoi que ce soit qui sorte de machin, et en particulier à quelle heure machin doit être fait.
Fabien LE LEZ wrote in message
<c9gq93lapp0mp5h8sv3l4kre5ut6gsrjfh@4ax.com>:
Pour moi, "le système", c'est le minimum : le noyau, init, la couche
TCP/IP, et pas grand-chose d'autre.
Eh bien on ne désigne pas la même chose par ce mot, c'est tout.
Admettons. Que proposes-tu comme mot ou expression pour désigner une
entrée dans /etc/passwd ?
Je n'en vois pas, mais ce n'est pas grave, puisqu'en général il n'y pas
ambiguïté.
On peut éventuellement créer un utilisateur (dans le sens "entrée dans
/etc/passwd") par service, rien que pour ça.
On a déjà fait ça, ce n'est pas ça le problème.
et j'ai du mal à comprendre dans quel(s) cas ça peut être un problème.
En usage normal, tu peux redémarrer ta machine, ou tuer et redémarrer
un processus. Dans les deux cas, s'il est corrompu, il va continuer à
faire des conneries, sans avoir besoin de crontab.
Et si tu tues un processus parce que tu penses qu'il est corrompu, tu
vas de toutes façons vérifier son crontab, voire réinstaller Linux.
Plus la vérification est complexe, et plus il y a de risque de se tromper.
Que faut-il regarder, si on soupçonne qu'un UID est compromis ? La crontab.
Les at-jobs. Le .forward, le .procmailrc, le .ssh/authorized_keys, le
.ssh/environment, le .pforile, j'en passe.
À chaque fois qu'un UID est autorisé à avoir un de ces éléments, ça génère
du bruit dans la vérification de l'intégrité de la configuration, bruit qui
peut masquer une compromission.
Dit autrement : l'UID qmail-machin, il sert à faire machin pour qmail, et
pas un pouillème de plus. En particulier, cet UID ne doit pas avoir le droit
de configurer quoi que ce soit qui sorte de machin, et en particulier à
quelle heure machin doit être fait.
Pour moi, "le système", c'est le minimum : le noyau, init, la couche TCP/IP, et pas grand-chose d'autre.
Eh bien on ne désigne pas la même chose par ce mot, c'est tout.
Admettons. Que proposes-tu comme mot ou expression pour désigner une entrée dans /etc/passwd ?
Je n'en vois pas, mais ce n'est pas grave, puisqu'en général il n'y pas ambiguïté.
On peut éventuellement créer un utilisateur (dans le sens "entrée dans /etc/passwd") par service, rien que pour ça.
On a déjà fait ça, ce n'est pas ça le problème.
et j'ai du mal à comprendre dans quel(s) cas ça peut être un problème.
En usage normal, tu peux redémarrer ta machine, ou tuer et redémarrer un processus. Dans les deux cas, s'il est corrompu, il va continuer à faire des conneries, sans avoir besoin de crontab.
Et si tu tues un processus parce que tu penses qu'il est corrompu, tu vas de toutes façons vérifier son crontab, voire réinstaller Linux.
Plus la vérification est complexe, et plus il y a de risque de se tromper. Que faut-il regarder, si on soupçonne qu'un UID est compromis ? La crontab. Les at-jobs. Le .forward, le .procmailrc, le .ssh/authorized_keys, le .ssh/environment, le .pforile, j'en passe.
À chaque fois qu'un UID est autorisé à avoir un de ces éléments, ça génère du bruit dans la vérification de l'intégrité de la configuration, bruit qui peut masquer une compromission.
Dit autrement : l'UID qmail-machin, il sert à faire machin pour qmail, et pas un pouillème de plus. En particulier, cet UID ne doit pas avoir le droit de configurer quoi que ce soit qui sorte de machin, et en particulier à quelle heure machin doit être fait.
