Re: Comment remplacer l'utilisateur root pour utiliser le service cron ?
L'utilisateur gestionnaire est créé. Identifier l'utilisateur qui fait tourner le service cron : ps -Af | grep cron root 890 1 0 20:21 ? 00:00:00 /usr/sbin/cron -f -P sudo systemctl stop cron cd /usr/sbin/ ls -la -rwxr-xr-x 1 root root 51792 mars 23 2022 cron sudo bash *chown gestionnaire:gestionnaire cron* cd /usr/sbin/ ls -la -rwxr-xr-x 1 *root gestionnaire* 51792 mars 23 2022 cron sudo systemctl restart cron ps -Af | grep cron *root* 5315 1 0 20:38 ? 00:00:00 /usr/sbin/cron -f -P C'est toujours l'utilisateur *root* qui *fait tourner le service cron*. L'ID de l'utilisateur gestionnaire avec l'option d'*ID utilisateur non unique* est *0 (root)*. Le 20/02/2024 à 12:26, Bernard Bass a écrit : La question initiale : Comment remplacer l'utilisateur root pour utiliser le service cron ? Devrait plutôt être : *Comment lancer le service cron/crontab avec l'utilisateur gestionnaire (root) ?* J'ai créé l'utilisateur gestionnaire de la sorte : Créer un utilisateur gestionnaire pour remplacer les actions de l'utilisateur root, pour lancer toutes les tâches cron. Consulter les groupes de l'utilisateur root : sudo bash id uid=0(root) gid=0(root) groupes=0(root) groups root Créer l'utilisateur gestionnaire : *sudo adduser gestionnaire* Ajouter l'utilisateur gestionnaire au groupe des administrateurs système (root) à l'aide de la commande usermod : # usermod -aG sudo gestionnaire *sudo usermod -aG root gestionnaire* Ajouter les droits root à l'utilisateur gestionnaire avec visudo : *sudo visudo root ALL=(ALL:ALL) ALL gestionnaire ALL=(ALL:ALL) ALL * sudo bash cat /etc/passwd | grep -i gestionnaire gestionnaire:x:1001:1001:,,,:/home/gestionnaire:/bin/bash sudo bash Donner à l'utilisateur gestionnaire les privilèges root sans qu'il n'ait a utiliser sudo : Changer l'ID de l'utilisateur gestionnaire avec l'option d'ID utilisateur non unique : *usermod -o -u 0 gestionnaire* Utiliser su pour s'identifier avec l'utilisateur gestionnaire et devenir root : $ *su gestionnaire* Mot de passe : *root*@system:/home/utilisateur-courant# cat /etc/passwd | grep -i gestionnaire gestionnaire:x:0:1001:,,,:/home/gestionnaire:/bin/bash La ligne peut être réécrite de la façon suivante : sudo nano /etc/passwd gestionnaire:x:0:1001:Gestionnaire:/home/gestionnaire:/bin/bash Je n'ai pas trouvé comment relancer le service cron avec cet autre utilisateur gestionnaire. *La solution fonctionnelle pour désactiver root semble être la suivante :* 1) sudo passwd root # Créer un mot de passe. sudo passwd -d root # Supprimer le mot de passe. 2) * Désactiver l'utilisateur root à partir du shell. Le moyen le plus simple de désactiver la connexion de l'utilisateur root est de changer son shell du répertoire /bin/bash à /sbin/nologin, dans le fichier /etc/passwd. sudo nano /etc/passwd root:x:0:0:root:/root:/sbin/nologin 3) sudo passwd -S root root NP 02/18/2024 0 9 7 -1 # L'utilisateur root utilise no password. 4) su root This account is currently not available. 5) On ne peut donc pas accéder à root directement. Le système cron avec la crontab -e root continue de fonctionner. Le user root semble faire son travail sans erreur. J'aurais préféré créer un utilisateur gestionnaire pour remplacer les actions de l'utilisateur root, capable de lancer toutes les tâches cron. Si quelqu'un sait expliquer la méthode. Merci.
Re: Re : Comment remplacer l'utilisateur root pour utiliser le service cron ?
Le mardi 20 février 2024 à 11:19 +0100, Christophe Maquaire a écrit : > > > Y'a même mieux ou pire, c'est selon: > > https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html Je continue le prosélytisme: In French et illustré par l'exemple:https://wiki.archlinux.org/title/Systemd_(Fran%C3%A7ais)/Timers_(Fran%C3%A7ais) Christophe
Re: Re : Comment remplacer l'utilisateur root pour utiliser le service cron ?
Le mardi 20 février 2024 à 10:00 +0100, NoSpam a écrit : > Bonjour > > Le 20/02/2024 à 05:54, k6dedi...@free.fr a écrit : > > Bonjour, > > Je découvre ce fil de discussion. > > Je ne comprends pas que l'on puisse encore travailler avec CRON. > > Alors que ANACRON est indépendant de la période de fonctionnement > > du PC. > Si on se place d'un point de vue poste de travail. Pour les serveurs, > aucun intérêt ! > Y'a même mieux ou pire, c'est selon: https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html Comme debian est passé à systemd, autant en profiter ou boire le calice jusqu'à la lie, c'est encore selon. Christophe
Re: Comment remplacer l'utilisateur root pour utiliser le service cron ?
La question initiale : Comment remplacer l'utilisateur root pour utiliser le service cron ? Devrait plutôt être : *Comment lancer le service cron/crontab avec l'utilisateur gestionnaire (root) ?* J'ai créé l'utilisateur gestionnaire de la sorte : Créer un utilisateur gestionnaire pour remplacer les actions de l'utilisateur root, pour lancer toutes les tâches cron. Consulter les groupes de l'utilisateur root : sudo bash id uid=0(root) gid=0(root) groupes=0(root) groups root Créer l'utilisateur gestionnaire : *sudo adduser gestionnaire* Ajouter l'utilisateur gestionnaire au groupe des administrateurs système (root) à l'aide de la commande usermod : # usermod -aG sudo gestionnaire *sudo usermod -aG root gestionnaire* Ajouter les droits root à l'utilisateur gestionnaire avec visudo : *sudo visudo root ALL=(ALL:ALL) ALL gestionnaire ALL=(ALL:ALL) ALL * sudo bash cat /etc/passwd | grep -i gestionnaire gestionnaire:x:1001:1001:,,,:/home/gestionnaire:/bin/bash sudo bash Donner à l'utilisateur gestionnaire les privilèges root sans qu'il n'ait a utiliser sudo : Changer l'ID de l'utilisateur gestionnaire avec l'option d'ID utilisateur non unique : *usermod -o -u 0 gestionnaire* Utiliser su pour s'identifier avec l'utilisateur gestionnaire et devenir root : $ *su gestionnaire* Mot de passe : *root*@system:/home/utilisateur-courant# cat /etc/passwd | grep -i gestionnaire gestionnaire:x:0:1001:,,,:/home/gestionnaire:/bin/bash La ligne peut être réécrite de la façon suivante : sudo nano /etc/passwd gestionnaire:x:0:1001:Gestionnaire:/home/gestionnaire:/bin/bash Je n'ai pas trouvé comment relancer le service cron avec cet autre utilisateur gestionnaire. *La solution fonctionnelle pour désactiver root semble être la suivante :* 1) sudo passwd root # Créer un mot de passe. sudo passwd -d root # Supprimer le mot de passe. 2) * Désactiver l'utilisateur root à partir du shell. Le moyen le plus simple de désactiver la connexion de l'utilisateur root est de changer son shell du répertoire /bin/bash à /sbin/nologin, dans le fichier /etc/passwd. sudo nano /etc/passwd root:x:0:0:root:/root:/sbin/nologin 3) sudo passwd -S root root NP 02/18/2024 0 9 7 -1 # L'utilisateur root utilise no password. 4) su root This account is currently not available. 5) On ne peut donc pas accéder à root directement. Le système cron avec la crontab -e root continue de fonctionner. Le user root semble faire son travail sans erreur. J'aurais préféré créer un utilisateur gestionnaire pour remplacer les actions de l'utilisateur root, capable de lancer toutes les tâches cron. Si quelqu'un sait expliquer la méthode. Merci.
Re: Re : Comment remplacer l'utilisateur root pour utiliser le service cron ?
Bonjour Le 20/02/2024 à 05:54, k6dedi...@free.fr a écrit : Bonjour, Je découvre ce fil de discussion. Je ne comprends pas que l'on puisse encore travailler avec CRON. Alors que ANACRON est indépendant de la période de fonctionnement du PC. Si on se place d'un point de vue poste de travail. Pour les serveurs, aucun intérêt !
Re : Comment remplacer l'utilisateur root pour utiliser le service cron ?
Bonjour, Je découvre ce fil de discussion. Je ne comprends pas que l'on puisse encore travailler avec CRON. Alors que ANACRON est indépendant de la période de fonctionnement du PC. Peut-etre que vous pourriez trouver une piste de solution dans l'article de Léa Linux espliquant les fonctionalités de at, cron et anacron. https://lea-linux.org/documentations/Programmation_de_travaux_avec_at_cron_anacron Bon courage Cassis - Mail d'origine - De: Bernard Bass À: Liste Debian Envoyé: Sun, 18 Feb 2024 00:32:25 +0100 (CET) Objet: Comment remplacer l'utilisateur root pour utiliser le service cron ? Bonjour, Voilà ma question : Comment remplacer l'utilisateur root pour utiliser le service cron ? ## ## Utiliser cron et crontab sur Debian 12. Un utilisateur sudoer est créé pour utiliser sudo et administrer le système. *L'utilisateur root a été désactivé sur le système Debian et le mot de passe est forcé pour expirer.* Des erreurs s'affichent dans journalctl, les tâches cron de l'utilisateur root ne sont pas lancées : *SERVEUR cron : Authentication failure Password root of that user should be expried.* Le compte utilisateur root est verrouillé et le mot de passe est forcé pour expirer, il ne peut être utilisé pour lancer des tâches cron. *COMMENT CREER UN UTILISATEUR POUR REMPLACER ROOT ET UTILISER SA CRONTAB ?* Créer un utilisateur pour remplacer root : sudo adduser gestionnaire sudo bash echo "gestionnaire ALL=(ALL) ALL" >> /etc/sudoers echo "gestionnaire ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers Ajouter gestionnaire au groupe cron : gpasswd -a gestionnaire cron Lorsque un utilisateur est ajouté au groupe cron, se déconnecter et se reconnecter pour rendre l'ajout au groupe effectif. *Comment faire comprendre au système qu'il faut utiliser le nouvel utilisateur pour lancer les tâches cron du système ?* *( la crontab de l'utilisateur sudoer, la crontab de l'utilisateur gestionnaire, les tâches cron.daily . , les tâches des services dans le dossier cron.d ) * ## ## La recherche actuelle : *( Les tâches cron.daily . , les tâches des services dans le dossier cron.d ne fonctionnent pas **" cron **: **Authentication failure " **) * ###### Utiliser cron et crontab sur Debian 12. Un utilisateur sudoer est créé pour utiliser sudo et administrer le système. L'utilisateur root a été désactivé sur le système Debian et le mot de passe est forcé pour expirer. Des erreurs s'affichent dans journalctl, les tâches cron de l'utilisateur root ne sont pas lancées. ## sudo journalctl -p err févr. 11 16:25:01 SERVEUR CRON[874565]: pam_unix(cron:account): account root has expired (account expired) *févr. 11 16:25:01 SERVEUR cron[874565]: Authentication failure <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<* sudo[874537]: pam_unix(sudo:session): session closed for user root Le compte utilisateur root est verrouillé et ne peut être utilisé pour lancer des tâches cron. *Password root of that user should be expried. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<* ## *COMMENT CREER UN UTILISATEUR ROOT POUR REMPLACER ROOT ET UTILISER SA CRONTAB ? <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<* Comment exécuter une commande exigeant un plus haut niveau de permission (root ou racine) ? Créer un utilisateur pour remplacer root : sudo adduser gestionnaire sudo bash echo "gestionnaire ALL=(ALL) ALL" >> /etc/sudoers echo "gestionnaire ALL=(ALL) NOPAS
Re: Comment remplacer l'utilisateur root pour utiliser le service cron ?
Bonjour, Franchement je ne comprends pas bien ces « modèles ». Soit avoir un login « super administrateur », root ou non, vous donne des bougons et, dans ce cas bloquez tout login direct acec un « x » dans le champ password du fichier /etc/shadow. Une méthode plus propre : $ sudo usermod -L root Cela ajoute un « ! » devant le mot de passe haché. Cela n’empêche pas un login « root » avec SSH par échange de clé. Mais il faut avoir, au préalable, ajouter ces clés publiques sur le compte root ce qui est difficile sans une connexion sur le serveur. Si vous ne voulez pas de connexion SSH directe possible, interdisez le dans un complément de ssh_config dans /etc/ssh/sshd_config.d/TOTO.conf avec : PermitRootLogin No DenyUsers root@* Par exemple (même si la première ligne devrait suffire…) Pour ce qui est du login, vous en avez besoin pour administrer. Ce n’est donc pas une discussion. À partir de là le seul moyen d’accéder aux droits « root » est de passer par un utilisateur sudoer pour lancer un « sudo commande » sans bloquer le système pour autant. Si vous vous méfiez des éventuels utilisateurs sudoer vous pouvez limiter les commandes possibles pour eux dans la configuration de sudoer. Allez faire un tour à la fin de https://www.malekal.com/exemples-sudoers-configurer-sudo-linux/ > Le 18 févr. 2024 à 22:36, Bernard Bass a écrit > : > > Bonsoir, >>> Puis-je savoir à quoi sert de désactiver le compte root si c'est pour >>> donner les pleins pouvoirs à un autre compte, en le dispensant de saisir >>> son mot de passe lorsqu'il utilise la commande sudo ? >>> echo "gestionnaire ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers >>> >> >> J’ai du louper des épisodes car je ne vois nulle part dans les réponses >> faites une mention laissant entendre qu’il fallait « disposer >> [l’utilisateur] de saisir son mot de passe ». C’est, à mon sens, une très >> mauvaise pratique à moins de limiter drastiquement les commandes laissées à >> cet usage. >> > Effectivement. > Je n'ai pas la méthode pour créer un utilisateur root. > J'ai des notes pour créer un sudoer dans le groupe sudo. > Je ne sais par contre pas s'il est possible de créer un utilisateur semblable > à l'utilisateur root. > On m'avait surement déjà répondu, cela n'est probablement pas possible, ou, > compliqué, puisque c'est root (0) qui administre le système. > > > > J'ai passé root en /sbin/nologin dans /etc/passwd ce qui empêche > l'utilisation de root, tout en permettant au système de fonctionner, sudo > crontab -e fonctionne normalement. > > Je ne sais toujours pas créer un utilisateur gestionnaire capable de prendre > le rôle de root, pour faire fonctionner l'ensemble des services cron, sans > passer par des manipulations complexes. > > Merci d'avoir répondu. > -- Pierre Malard « La vérité ne triomphe jamais, mais ses ennemis finissent toujours par mourir... » Max Placnk (1858-1947) |\ _,,,---,,_ /,`.-'`'-. ;-;;,_ |,4- ) )-,_. ,\ ( `'-' '---''(_/--' `-'\_) πr perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. ,\ ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_): 24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print' - --> Ce message n’engage que son auteur <-- signature.asc Description: Message signed with OpenPGP
Re: Comment remplacer l'utilisateur root pour utiliser le service cron ?
Bonsoir, Puis-je savoir à quoi sert de désactiver le compte root si c'est pour donner les pleins pouvoirs à un autre compte, en le dispensant de saisir son mot de passe lorsqu'il utilise la commande sudo ? echo "gestionnaire ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers J’ai du louper des épisodes car je ne vois nulle part dans les réponses faites une mention laissant entendre qu’il fallait « disposer [l’utilisateur] de saisir son mot de passe ». C’est, à mon sens, une très mauvaise pratique à moins de limiter drastiquement les commandes laissées à cet usage. Effectivement. Je n'ai pas la méthode pour créer un utilisateur root. J'ai des notes pour créer un sudoer dans le groupe sudo. Je ne sais par contre pas s'il est possible de créer un utilisateur semblable à l'utilisateur root. On m'avait surement déjà répondu, cela n'est probablement pas possible, ou, compliqué, puisque c'est root (0) qui administre le système. J'ai passé root en /sbin/nologin dans /etc/passwd ce qui empêche l'utilisation de root, tout en permettant au système de fonctionner, sudo crontab -e fonctionne normalement. Je ne sais toujours pas créer un utilisateur gestionnaire capable de prendre le rôle de root, pour faire fonctionner l'ensemble des services cron, sans passer par des manipulations complexes. Merci d'avoir répondu.
Re: Comment remplacer l'utilisateur root pour utiliser le service cron ?
*La solution fonctionnelle pour désactiver root semble être la suivante :* 1) sudo passwd root # Créer un mot de passe. sudo passwd -d root # Supprimer le mot de passe. 2) * Désactiver l'utilisateur root à partir du shell. Le moyen le plus simple de désactiver la connexion de l'utilisateur root est de changer son shell du répertoire /bin/bash à /sbin/nologin, dans le fichier /etc/passwd. sudo nano /etc/passwd root:x:0:0:root:/root:/sbin/nologin 3) sudo passwd -S root root NP 02/18/2024 0 9 7 -1 # L'utilisateur root utilise no password. 4) su root This account is currently not available. 5) On ne peut donc pas accéder à root directement. Le système cron avec la crontab -e root continue de fonctionner. Le user root semble faire son travail sans erreur. J'aurais préféré créer un utilisateur gestionnaire pour remplacer les actions de l'utilisateur root, capable de lancer toutes les tâches cron. Si quelqu'un sait expliquer la méthode. Merci.
Re: Comment remplacer l'utilisateur root pour utiliser le service cron ?
Pour protéger l'accès au compte root, j'ai bien configuré *sshd* pour *interdire le user root*, *la connexion par mot de passe vide et par mot de passe*, uniquement *autoriser la connexion par clé ssh ed25519*. sudo passwd root # Créer un mot de passe. *passwd --lock root* # Le compte root est alors à nouveau verrouillé ! sudo passwd -S root [sudo] Mot de passe de l'utilisateur sudoers : root*L* 12/23/2019 0 9 7 -1 # Le compte root est verrouillé. sudo passwd root # Créer un mot de passe. *sudo passwd -d root* passwd : informations de validité du mot de passe changées. sudo passwd -S root root*NP* 02/18/2024 0 9 7 -1 # Le compte root est accessible sans mot de passe depuis l'utilisateur sudoers ( Et même d'un simple utilisateur ? Si il a les clés ssh pour se connecter au serveur.). $ su root # Aucun mot de passe n'est demandé pour passer à l'utilisateur root. # Il semble donc nécessaire de définir un mot de passe complexe pour root et de laisser l'utilisateur root activé. *Je ne comprend pas* la méthode pour désactiver l'utilisateur root, ou le mot de passe de l'utilisateur root, en restant dans la bonne pratique de sécurité, tout en lui laissant la possibité d'administrer cron.' */Supprimer le mot de passe de l'utilisateur root pour ne pas conserver le hash du mot de passe en mémoire./* Désactiver l'utilisateur root à partir du shell : Le moyen le plus simple de désactiver la connexion de l'utilisateur root est de changer son shell du répertoire /bin/bash à /sbin/nologin, dans le fichier Par défaut : *root:x:0:0:root:/root:/bin/bash* Si la valeur est changée pour */sbin/nologin* , root sera t'il encore capable d'administrer le système ? ( Tâches cron et autres tâches ? ) sudo nano /etc/passwd *root:x:0:0:root:/root:/sbin/nologin* *su root This account is currently not available.* *sudo bash root@system * sudo crontab -e Ajouter une tâche. Erreurs : Après avoir désactivé root sur le système, *je ne vois pas de solution qui permet aux taches cron root, ou cron.daily de fonctionner sans configurations avancées*. *Aucun répertoire /lib/security sur ma machine :* févr. 18 20:16:02 system sudo[11786]: PAM unable to dlopen(pam_ck_connector.so): */lib/security/pam_ck_connector.so*: Ne peut ouvrir le fichier d'objet partagé: Aucun fichier ou dossier de ce nom févr. 18 20:16:02 system sudo[11786]: PAM adding faulty module: pam_ck_connector.so févr. 18 20:17:01 system CRON[11802]: PAM unable to dlopen(pam_ck_connector.so): /lib/security/pam_ck_connector.so: Ne peut ouvrir le fichier d'objet partagé: Aucun fichier ou dossier de ce nom févr. 18 20:17:01 system CRON[11802]: PAM adding faulty module: pam_ck_connector.so* *
Re: Comment remplacer l'utilisateur root pour utiliser le service cron ?
Bonjour, > Le 18 févr. 2024 à 18:46, Bernard Bass a écrit > : > > Bonjour, > Puis-je savoir à quoi sert de désactiver le compte root si c'est pour donner > les pleins pouvoirs à un autre compte, en le dispensant de saisir son mot de > passe lorsqu'il utilise la commande sudo ? > echo "gestionnaire ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers > > J’ai du louper des épisodes car je ne vois nulle part dans les réponses faites une mention laissant entendre qu’il fallait « disposer [l’utilisateur] de saisir son mot de passe ». C’est, à mon sens, une très mauvaise pratique à moins de limiter drastiquement les commandes laissées à cet usage. > >> Je pense avoir mal compris, je n'aurais pas du désactiver root, mais > >> seulement supprimer le mot de passe pour ne pas conserver le hash du mot > >> de passe root en mémoire. > >> sudo passwd -d root > > > > > > >> Il faudrait alors réactiver l'utilisateur root , pour qu'il puisse gérer > >> les tâches cron du système ( cron.daily ... ) : > >> sudo passwd --unlock root > >> Affiche : > >> passwd : déverrouiller le mot de passe créerait un compte sans mot de > >> passe. > >> Vous devriez définir un mot de passe avec usermod -p pour déverrouiller le > >> mot de passe de ce compte. > > > >> passwd -S root > >> root L 2024-01-03 0 9 7 -1 > >> Le compte reste verrouillé (L) après la commande passwd --unlock root > > > >> Définir un mot de passe avec usermod -p pour déverrouiller le mot de passe > >> de ce compte (root) > >> Il est indiqué dans une documentation d'enlever le mot de passe du compte > >> root pour ne pas laisser le hash en mémoire. :/ > > >> passwd root crérait / recrérait un compte root sans mot de passe ? > >> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > >> Aucun hash de mot de passe ne serait alors conservé en mémoire et le > >> compte root serait utilisable par le système pour utiliser cron. > > > > > > > Même si on interdit la connexion directe sous « root », ce qui peut se > concevoir, > > >>Oui, j'ai désactivé la connexion à root depuis SSH. > >> Il me semble qu'il faille le faire pour le système aussi ? # Sans > >> supprimer le compte root pour autant ? # C'est confus. > > il n’empêche que certaines commande doivent être lancées avec ces droits. > >> Effectivement. > > > du coup, pour modifier le crontab root, rien n’empêche d’utiliser un sudo > pour prendre ponctuellement ces droits pour modifier le crontab root. > > >> Oui il est possible de modifier la crontab root avec sudo crontab -e > >> Les tâches ne seront pas lancées et resteront en erreur "Authentication > >> failure" avec l'utilisateur root désactivé et le mot de passe expiré. > > > > Dans le même sujet si une tâche n’a pas besoin des droits root rien n’empêche > d’utiliser un crontab « utilisateur » ! > > >> Oui, il faut autoriser les scripts depuis "/etc/sudoers.d" mais les tâches > >> systèmes ( cron.daily ... ne sont pas lancées si l'utilisateur root est > >> désactivé. ) > >> sudo nano /etc/sudoers > > >> Préférer le dossier "/etc/sudoers.d" : il sert à stocker des fichiers > >> déclaratifs pour sudoers qui seront lus en complément du fichier sudoers. > >> Attention, tous les fichiers qui contiennent "~" ou "." dans le nom ne > >> seront pas lus ! > >> Organiser les règles par fichier plutôt que de tout centraliser dans le > >> même fichier : le fichier sudoers sera toujours lu, dans tous les cas. > > >> Pour créer un nouveau fichier nommé "amis_sh", on utilisera : > >> sudo visudo /etc/sudoers.d/amis_sh > >> sudo chmod 440 /etc/sudoers.d/amis_sh > > >> Ajouter deux ligne pour le script sudoer à autoriser : > >> amis_sh ALL=(ALL:ALL) ALL # Pas certain qu'il faille utiliser cette ligne. > >> J'ai testé sans, il me semble que cela ne fonctionne pas. > >> amis_sh ALL=(ALL) NOPASSWD:/home/amis_sh/test-crontab-sudo.sh > > >> nano test-crontab-sudo.sh > >> Ajouter les lignes suivantes : > > >> !/bin/sh > >> touch "/home/amis_sh/test-crontab-sudo-ok1&qu
Re: Comment remplacer l'utilisateur root pour utiliser le service cron ?
Bonjour, Puis-je savoir à quoi sert de désactiver le compte root si c'est pour donner les pleins pouvoirs à un autre compte, en le dispensant de saisir son mot de passe lorsqu'il utilise la commande sudo ? echo "gestionnaire ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers *>> Je pense avoir mal compris, je n'aurais pas du désactiver root, mais seulement supprimer le mot de passe **pour ne pas conserver le hash du mot de passe root en mémoire. >> sudo passwd -d root* * * ** * >> Il faudrait alors réactiver l'utilisateur root , pour qu'il puisse gérer les tâches cron du système ( cron.daily ... ) : >> sudo passwd --unlock root* *>> Affiche : >> passwd : déverrouiller le mot de passe créerait un compte sans mot de passe.* >> Vous devriez définir un mot de passe avec usermod -p pour déverrouiller le mot de passe de ce compte. >> passwd -S root >> root L 2024-01-03 0 9 7 -1 *>> Le compte reste verrouillé (L) après la commande passwd --unlock root* >> *Définir un mot de passe avec usermod -p pour déverrouiller* le mot de passe de ce compte (root) *>> Il est indiqué dans une documentation d'enlever le mot de passe du compte root pour ne pas laisser le hash en mémoire. :/ >> passwd root crérait / recrérait un compte root sans mot de passe ? <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >> Aucun hash de mot de passe ne serait alors conservé en mémoire et le compte root serait utilisable par le système pour utiliser cron. * * *** Même si on interdit la connexion directe sous « root », ce qui peut se concevoir, *>>Oui, j'ai désactivé la connexion à root depuis SSH. >> Il me semble qu'il faille le faire pour le système aussi ? # Sans supprimer le compte root pour autant ? # C'est confus.* il n’empêche que certaines commande doivent être lancées avec ces droits. >> Effectivement. du coup, pour modifier le crontab root, rien n’empêche d’utiliser un sudo pour prendre ponctuellement ces droits pour modifier le crontab root. *>> Oui il est possible de modifier la crontab root avec sudo crontab -e >> Les tâches ne seront pas lancées et resteront en erreur "Authentication failure" avec l'utilisateur root désactivé et le mot de passe expiré.* Dans le même sujet si une tâche n’a pas besoin des droits root rien n’empêche d’utiliser un crontab « utilisateur » ! *>> Oui, il faut autoriser les scripts depuis "/etc/sudoers.d" mais les tâches systèmes ( cron.daily ... ne sont pas lancées si l'utilisateur root est désactivé. )* >> sudo nano /etc/sudoers >> Préférer le dossier "/etc/sudoers.d" : il sert à stocker des fichiers déclaratifs pour sudoers qui seront lus en complément du fichier sudoers. >> Attention, tous les fichiers qui contiennent "~" ou "." dans le nom ne seront pas lus ! >> Organiser les règles par fichier plutôt que de tout centraliser dans le même fichier : le fichier sudoers sera toujours lu, dans tous les cas. >> Pour créer un nouveau fichier nommé "amis_sh", on utilisera : >> sudo visudo /etc/sudoers.d/amis_sh >> sudo chmod 440 /etc/sudoers.d/amis_sh *>> Ajouter deux ligne pour le script sudoer à autoriser : >> amis_sh ALL=(ALL:ALL) ALL # Pas certain qu'il faille utiliser cette ligne. J'ai testé sans, il me semble que cela ne fonctionne pas. >> amis_sh ALL=(ALL) NOPASSWD:/home/amis_sh/test-crontab-sudo.sh* >> nano test-crontab-sudo.sh >> Ajouter les lignes suivantes : >> !/bin/sh >> touch "/home/amis_sh/test-crontab-sudo-ok1"; # Un fichier avec droits utilisateur est créé. >> su - amis_sh -c "touch test-crontab-sudo-user-ok"; # Un fichier avec droits root est créé. >> touch "/home/amis_sh/test-crontab-sudo-ok2"; # Un fichier avec droits utilisateur est créé. >> Utiliser la crontab de l'utilisateur : crontab -e >> 55 12 * * * user=$(whoami) sudo /home/amis_sh/test-crontab-sudo.sh >> updates.log 2>&1 Enfin, si on souhaite mieux gérer tout ça on peut utiliser /etc/cron.d où on indique l’utilisateur à utiliser pour lancer la commande souhaitée… mais il faut avoir les droits « root » pour créer cette entrée ;-) *>> Oui, Je suppose que l'on peut utiliser ici un nouvel utilisateur gestionnaire avec les droits root.* >> Le problème reste présent pour lancer les tâches cron.daily si l'utilisateur root est désactivé. Mention du paquet Debian super. https://packages.debian.org/trixie/super paramétrable finement par /etc/super.tab *>> Je n'ai pas regardé cette possibilité.* >> Je lis pour les droits setuid : # Elever les droits setuid sur les scripts exécutés par cron pour ne pas avoir à utiliser sudo : *>>* *Cette méthode pour ne pas utiliser sudo n'est pas recommandée* : # sudo chown root script.sh # sudo chmod 710 script.sh # sudo chmod u+s script.sh
Re: Comment remplacer l'utilisateur root pour utiliser le service cron ?
On 2/18/24 09:26, Pierre Malard wrote: Bonjour, Même question, tout ça sert-il à quoi que ce soit ? Même si on interdit la connexion directe sous « root », ce qui peut se concevoir, il n’empêche que certaines commande doivent être lancées avec ces droits. su coup, pour modifier le crontab root, rien n’empêche d’utiliser un sudo pour prendre ponctuellement ces droits pour modifier le crontab root. Tout à fait d'accord. Dans le même sujet si une tâche n’a pas besoin des droits root rien n’empêche d’utiliser un crontab « utilisateur » ! D'accord aussi. Enfin, si on souhaite mieux gérer tout ça on peut utiliser /etc/cron.d où on indique l’utilisateur à utiliser pour lancer la commande souhaitée… mais il faut avoir les droits « root » pour créer cette entrée ;-) Et j'ajouterais la mention du paquet Debian super. https://packages.debian.org/trixie/super paramétrable finement par /etc/super.tab -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/ See/voir: https://github.com/RefPerSys/RefPerSys
Re: Comment remplacer l'utilisateur root pour utiliser le service cron ?
Bonjour, Même question, tout ça sert-il à quoi que ce soit ? Même si on interdit la connexion directe sous « root », ce qui peut se concevoir, il n’empêche que certaines commande doivent être lancées avec ces droits. su coup, pour modifier le crontab root, rien n’empêche d’utiliser un sudo pour prendre ponctuellement ces droits pour modifier le crontab root. Dans le même sujet si une tâche n’a pas besoin des droits root rien n’empêche d’utiliser un crontab « utilisateur » ! Enfin, si on souhaite mieux gérer tout ça on peut utiliser /etc/cron.d où on indique l’utilisateur à utiliser pour lancer la commande souhaitée… mais il faut avoir les droits « root » pour créer cette entrée ;-) https://doc.ubuntu-fr.org/cron > Le 18 févr. 2024 à 00:09, Sébastien Dinot a écrit : > > Bernard Bass a écrit : >> Voilà ma question : Comment remplacer l'utilisateur root pour utiliser >> le service cron ? > > Puis-je savoir à quoi sert de désactiver le compte root si c'est pour > donner les pleins pouvoirs à un autre compte, en le dispensant de saisir > son mot de passe lorsqu'il utilise la commande sudo ? > >> echo "gestionnaire ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers > > La subtilité de la manœuvre m'échappe. > > Sébastien > > -- > Sébastien Dinot, sebastien.di...@free.fr > http://www.palabritudes.net/ > Ne goutez pas au logiciel libre, vous ne pourriez plus vous en passer ! > -- Pierre Malard Responsable architectures système CDS DINAMIS/THEIA Montpellier IRD - UMR Espace-Dev - UAR CPST - IR Data-Terra Maison de la Télédétection 500 rue Jean-François Breton 34093 Montpellier Cx 5 France Tél : +33 626 89 22 68 «[...]développer la science ? Noble ambition ; mais qu'est-ce que la science ? Une puissance et une joie ; et, si elle ne s'anime pas de l'esprit de justice, [...] de la vie des hommes, [...] elle est un privilège en plus.» Jean Jaures - "L'idéal de justice" - 1889 |\ _,,,---,,_ /,`.-'`'-. ;-;;,_ |,4- ) )-,_. ,\ ( `'-' '---''(_/--' `-'\_) πr perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. ,\ ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_): 24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print' - --> Ce message n’engage que son auteur <-- signature.asc Description: Message signed with OpenPGP
Re: Comment remplacer l'utilisateur root pour utiliser le service cron ?
Bernard Bass a écrit : > Voilà ma question : Comment remplacer l'utilisateur root pour utiliser > le service cron ? Puis-je savoir à quoi sert de désactiver le compte root si c'est pour donner les pleins pouvoirs à un autre compte, en le dispensant de saisir son mot de passe lorsqu'il utilise la commande sudo ? > echo "gestionnaire ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers La subtilité de la manœuvre m'échappe. Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://www.palabritudes.net/ Ne goutez pas au logiciel libre, vous ne pourriez plus vous en passer !
Comment remplacer l'utilisateur root pour utiliser le service cron ?
Bonjour, Voilà ma question : Comment remplacer l'utilisateur root pour utiliser le service cron ? ## ## Utiliser cron et crontab sur Debian 12. Un utilisateur sudoer est créé pour utiliser sudo et administrer le système. *L'utilisateur root a été désactivé sur le système Debian et le mot de passe est forcé pour expirer.* Des erreurs s'affichent dans journalctl, les tâches cron de l'utilisateur root ne sont pas lancées : *SERVEUR cron : Authentication failure Password root of that user should be expried.* Le compte utilisateur root est verrouillé et le mot de passe est forcé pour expirer, il ne peut être utilisé pour lancer des tâches cron. *COMMENT CREER UN UTILISATEUR POUR REMPLACER ROOT ET UTILISER SA CRONTAB ?* Créer un utilisateur pour remplacer root : sudo adduser gestionnaire sudo bash echo "gestionnaire ALL=(ALL) ALL" >> /etc/sudoers echo "gestionnaire ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers Ajouter gestionnaire au groupe cron : gpasswd -a gestionnaire cron Lorsque un utilisateur est ajouté au groupe cron, se déconnecter et se reconnecter pour rendre l'ajout au groupe effectif. *Comment faire comprendre au système qu'il faut utiliser le nouvel utilisateur pour lancer les tâches cron du système ?* *( la crontab de l'utilisateur sudoer, la crontab de l'utilisateur gestionnaire, les tâches cron.daily . , les tâches des services dans le dossier cron.d ) * ## ## La recherche actuelle : *( Les tâches cron.daily . , les tâches des services dans le dossier cron.d ne fonctionnent pas **" cron **: **Authentication failure " **) * ###### Utiliser cron et crontab sur Debian 12. Un utilisateur sudoer est créé pour utiliser sudo et administrer le système. L'utilisateur root a été désactivé sur le système Debian et le mot de passe est forcé pour expirer. Des erreurs s'affichent dans journalctl, les tâches cron de l'utilisateur root ne sont pas lancées. ## sudo journalctl -p err févr. 11 16:25:01 SERVEUR CRON[874565]: pam_unix(cron:account): account root has expired (account expired) *févr. 11 16:25:01 SERVEUR cron[874565]: Authentication failure <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<* sudo[874537]: pam_unix(sudo:session): session closed for user root Le compte utilisateur root est verrouillé et ne peut être utilisé pour lancer des tâches cron. *Password root of that user should be expried. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<* ## *COMMENT CREER UN UTILISATEUR ROOT POUR REMPLACER ROOT ET UTILISER SA CRONTAB ? <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<* Comment exécuter une commande exigeant un plus haut niveau de permission (root ou racine) ? Créer un utilisateur pour remplacer root : sudo adduser gestionnaire sudo bash echo "gestionnaire ALL=(ALL) ALL" >> /etc/sudoers echo "gestionnaire ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers Ajouter gestionnaire au groupe cron : gpasswd -a gestionnaire cron Lorsque un utilisateur est ajouté au groupe cron, se déconnecter et se reconnecter pour rendre l'ajout au groupe effectif. *Comment faire comprendre au système qu'il faut utiliser gestionnaire pour lancer les tâches cron ?* ... ... ## sudo systemctl stop cron sudo systemctl start cron sudo systemctl restart cron # Identifier les processus cron : sudo systemctl status cron # Arrêter un processus
Re: Réduire la verbosité de cron
Le 20-11-2020, à 08:56:50 +0100, Fabrice BAUZAC-STEHLY a écrit : - Remplacer le "@include common-session-noninteractive" par le contenu du fichier Qu'est-ce que ça apporterait ? Le but est de ne modifier que la configuration PAM de cron, pas de modifier d'autres choses comme sudo ou systemd-user. Si tu supprimes la ligne "session required pam_unix.so" du fichier common-session-noninteractive, tu vas impacter tous les programmes qui l'incluent. Remplacer le @include par le contenu du fichier te permet de supprimer la ligne juste pour cron. Ok, merci pour l'explication. - puis supprimer la ligne "session required pam_unix.so" C'est pas un truc à se faire locked out ? A partir du moment ou tu ne modifies que ce qui est specifique a cron, tu ne peux avoir d'impact que sur cron. N'hesite pas a te documenter sur PAM. C'est ce que j'ai fait et j'ai trouvé cet ancienne entrée sur le BTS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293272#36 J'ai appliqué, on va voir ce que ça donne. Merci
Re: Réduire la verbosité de cron
steve writes: > Le 18-11-2020, à 22:13:35 +0100, Fabrice BAUZAC-STEHLY a écrit : >>steve writes: >>> Cron remplit les logs d'information que je considère comme inutile. >>> Nov 18 18:05:01 box CRON[18456]: pam_unix(cron:session): session opened for >>> user _tuptime by (uid=0) >>> Nov 18 18:05:01 box CRON[18456]: pam_unix(cron:session): session closed for >>> user _tuptime >>Ce sont des logs generes par le composant "session" de pam_unix(8). >>Si tu n'en veux pas, je pense qu'il faut que tu modifies la >>configuration PAM de cron. >>Chez moi, j'ai >> /etc/pam.d/cron >>qui inclut: >> @include common-session-noninteractive >>et /etc/pam.d/common-session-noninteractive contient: >> session required pam_unix.so >>Je ne connais pas bien PAM mais je pense qu'il faut modifier >>/etc/pam.d/cron: >>- Remplacer le "@include common-session-noninteractive" par le contenu >>du fichier > Qu'est-ce que ça apporterait ? Le but est de ne modifier que la configuration PAM de cron, pas de modifier d'autres choses comme sudo ou systemd-user. Si tu supprimes la ligne "session required pam_unix.so" du fichier common-session-noninteractive, tu vas impacter tous les programmes qui l'incluent. Remplacer le @include par le contenu du fichier te permet de supprimer la ligne juste pour cron. >>- puis supprimer la ligne "session required pam_unix.so" > C'est pas un truc à se faire locked out ? A partir du moment ou tu ne modifies que ce qui est specifique a cron, tu ne peux avoir d'impact que sur cron. N'hesite pas a te documenter sur PAM. -- Fabrice BAUZAC-STEHLY PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
Re: Réduire la verbosité de cron
Le 18-11-2020, à 22:13:35 +0100, Fabrice BAUZAC-STEHLY a écrit : steve writes: Cron remplit les logs d'information que je considère comme inutile. Nov 18 18:05:01 box CRON[18456]: pam_unix(cron:session): session opened for user _tuptime by (uid=0) Nov 18 18:05:01 box CRON[18456]: pam_unix(cron:session): session closed for user _tuptime Ce sont des logs generes par le composant "session" de pam_unix(8). Merci pour l'info. Je ne suis pas trop PAM non plus ;) Si tu n'en veux pas, je pense qu'il faut que tu modifies la configuration PAM de cron. Chez moi, j'ai /etc/pam.d/cron qui inclut: @include common-session-noninteractive et /etc/pam.d/common-session-noninteractive contient: session required pam_unix.so Je ne connais pas bien PAM mais je pense qu'il faut modifier /etc/pam.d/cron: - Remplacer le "@include common-session-noninteractive" par le contenu du fichier Qu'est-ce que ça apporterait ? - puis supprimer la ligne "session required pam_unix.so" C'est pas un truc à se faire locked out ?
Re: Réduire la verbosité de cron
steve writes: > Cron remplit les logs d'information que je considère comme inutile. > > Nov 18 18:05:01 box CRON[18456]: pam_unix(cron:session): session opened for > user _tuptime by (uid=0) > Nov 18 18:05:01 box CRON[18456]: pam_unix(cron:session): session closed for > user _tuptime Ce sont des logs generes par le composant "session" de pam_unix(8). Si tu n'en veux pas, je pense qu'il faut que tu modifies la configuration PAM de cron. Chez moi, j'ai /etc/pam.d/cron qui inclut: @include common-session-noninteractive et /etc/pam.d/common-session-noninteractive contient: session required pam_unix.so Je ne connais pas bien PAM mais je pense qu'il faut modifier /etc/pam.d/cron: - Remplacer le "@include common-session-noninteractive" par le contenu du fichier - puis supprimer la ligne "session required pam_unix.so" -- Fabrice BAUZAC-STEHLY PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
Réduire la verbosité de cron
Cron remplit les logs d'information que je considère comme inutile. Exemple: Nov 18 18:05:01 box CRON[18456]: pam_unix(cron:session): session opened for user _tuptime by (uid=0) Nov 18 18:05:01 box CRON[18456]: pam_unix(cron:session): session closed for user _tuptime Nov 18 18:10:01 box CRON[18718]: pam_unix(cron:session): session opened for user _tuptime by (uid=0) Nov 18 18:10:01 box CRON[18718]: pam_unix(cron:session): session closed for user _tuptime etc etc. J'ai ajouté ceci dans /etc/default/cron: # For quick reference, the currently available log levels are: # 0 no logging (errors are logged regardless) # 1 log start of jobs # 2 log end of jobs # 4 log jobs with exit status != 0 # 8 log the process identifier of child process (in all logs) # EXTRA_OPTS="-L 0" mais je n'ai pas vu de différence. Y a-t-il un autre moyen pour réduire cette « pollution » ? Merci Steve
Re: Re : Re: Cron toutes les 75 h
k6dedi...@free.fr writes: > En reparcourant rapidement la présentation de "anacron", j'ai vu que > l'on pouvait paramétrer le nombre de jours. > Cela ne permet peut-être pas 75h, mais 3 jours soit 72h. > Il se pourrait que les dernières versions puissent se paramétrer par heures. > De plus anacron me parait plus pratique que cron puisque en cas de > panne, d'interruption diverse, il reprend le travail au point où il en > était. > > https://fr.wikipedia.org/wiki/Anacron > https://docs.gandi.net/fr/simple_hosting/operations_courantes/anacron.html > https://sourceforge.net/projects/anacron/ Ah intéressant, je vais explorer. > > Bonne découverte Cordialement et merci, -- Raphaël www.leclavierquibave.fr
Re : Re: Cron toutes les 75 h
Bonjour, Désolé pour cette intervention tardive. En reparcourant rapidement la présentation de "anacron", j'ai vu que l'on pouvait paramétrer le nombre de jours. Cela ne permet peut-être pas 75h, mais 3 jours soit 72h. Il se pourrait que les dernières versions puissent se paramétrer par heures. De plus anacron me parait plus pratique que cron puisque en cas de panne, d'interruption diverse, il reprend le travail au point où il en était. https://fr.wikipedia.org/wiki/Anacron https://docs.gandi.net/fr/simple_hosting/operations_courantes/anacron.html https://sourceforge.net/projects/anacron/ Bonne découverte assis - Mail d'origine - De: Raphaël POITEVIN À: debian-user-french@lists.debian.org Envoyé: Tue, 19 May 2020 15:20:37 +0200 (CEST) Objet: Re: Cron toutes les 75 h Sébastien NOBILI writes: >> À voir en effet. Espérant qu’on peut exécuter ceci en utilisateur non >> privilégié. > > Oui, on peut. > > Tu décris ton timer dans le dossier > `~/.config/systemd/user/relance.timer` > Tu actives ton timer avec `systemctl --user enable relance.timer` > > J'ai remplacé pas mal de tâches cron utilisateur par ce mécanisme, > plus souple dans > certains cas (possibilité de désactiver/réactiver le timer). Merci, je retiens, ça peut me servir. Bon, pour le moment, je n’ai plus besoin de la tâche, mais ce n’es pas dit que je n’y ai pas recours de nouveau. -- Raphaël www.leclavierquibave.fr
Re: Cron toutes les 75 h
Sébastien NOBILI writes: >> À voir en effet. Espérant qu’on peut exécuter ceci en utilisateur non >> privilégié. > > Oui, on peut. > > Tu décris ton timer dans le dossier > `~/.config/systemd/user/relance.timer` > Tu actives ton timer avec `systemctl --user enable relance.timer` > > J'ai remplacé pas mal de tâches cron utilisateur par ce mécanisme, > plus souple dans > certains cas (possibilité de désactiver/réactiver le timer). Merci, je retiens, ça peut me servir. Bon, pour le moment, je n’ai plus besoin de la tâche, mais ce n’es pas dit que je n’y ai pas recours de nouveau. -- Raphaël www.leclavierquibave.fr
Re: Cron toutes les 75 h
Bonjour, Le 2020-05-12 15:56, raphael.poite...@gmail.com a écrit : Jean-Marc writes: Sinon, voir si systemd.timer peut offrir une solution. Si ton système utilise systemd. À voir en effet. Espérant qu’on peut exécuter ceci en utilisateur non privilégié. Oui, on peut. Tu décris ton timer dans le dossier `~/.config/systemd/user/relance.timer` Tu actives ton timer avec `systemctl --user enable relance.timer` J'ai remplacé pas mal de tâches cron utilisateur par ce mécanisme, plus souple dans certains cas (possibilité de désactiver/réactiver le timer). Sébastien
Re: Cron toutes les 75 h
On Tue, May 12, 2020 at 06:04:00PM +0200, Raphaël POITEVIN wrote: > sleep $(($RANDOM%540)) && commande Bah, j'avais raté qu'il me restait un mail à lire dans le fil. Désolé de la contribution redondante dans mon autre mail -_- Y.
Re: Cron toutes les 75 h
> Je me contenterai de mettre */3 pour le jour et enverrai > toujours à la même heure. Personellement, je ferais un mix entre ta solution et celle de G2PC: */3 pour lancer tous les 3 jours, puis le script commence avec un sleep rand(3*3600) (en pseudo-Perl) Comme ça tu envoie à une heure aléatoire sur une plage de 3 heures. Y.
Re: Cron toutes les 75 h
Finalement : sleep $(($RANDOM%540)) && commande Tous les 3 jours, on verra. Raphaël raphael.poite...@gmail.com (Raphaël POITEVIN) writes: > Bonjour, > > Comment programmer une tâche toutes les 75 h à la minute 12 ? L’objectif > étant d’exécuter la tâche tous les trois jours avec un décalage de 3 h > entre 9h et 18h, du lundi au vendredi. > > Ma ligne : > 12 9-18/75 * * 1-5 commande > Cependant la tâche s’est bien exécutée hier à 9h12 mais s’est réexécutée > ce matin même heure. > > En vous remerciant. > > Cordialement,
Re: Cron toutes les 75 h
l0f...@tuta.io writes: > Je pense que tu devrais t'inspirer de la discussion instructive > suivante > : https://stackoverflow.com/questions/27412483/how-do-cron-steps-work Merci, la piste avec at est intéressante. -- Raphaël www.leclavierquibave.fr
Re: Cron toutes les 75 h
Jean-Marc writes: > Sinon, voir si systemd.timer peut offrir une solution. > Si ton système utilise systemd. À voir en effet. Espérant qu’on peut exécuter ceci en utilisateur non privilégié. -- Raphaël www.leclavierquibave.fr
Re: Cron toutes les 75 h
G2PC writes: > Quel intérêt de faire une tâche tous les 3 jours avec 3h de décalage sur > une plage horaire aussi large ? Si j’ai mis des heures de bornage, c’est pour respecter des heures de bureau. Mon but est d’envoyer des mails de rappel à mon agence de location afin qu’elle n’oublie pas de traiter mon dossier, mais à des heures différentes. > > Peut être faire un script qui s’exécute tous les jours à ce moment la, > voir même, toutes les heures. > > Le script devra écrire un token quelque part, à vérifier. Si le token > existe, y mettre la date et l'heure voulue pour exécuter le script. > > Une fois le script exécuté, supprimer le token. > > Lors de la nouvelle tâche cron, si le token n'existe pas, recréer le > token pour dans 3 jours, avec une création aléatoire en ce qui concerne > l'heure, qui sera saisie dans le token. > > Un truc dans le genre, non ? J’y rélféchirai. Mais bon, un peu trop de boulot pour quelque chose d’aussi mineur. Je me contenterai de mettre */3 pour le jour et enverrai toujours à la même heure. -- Raphaël www.leclavierquibave.fr
Re: Cron toutes les 75 h
Bonjour, Je pense que tu devrais t'inspirer de la discussion instructive suivante : https://stackoverflow.com/questions/27412483/how-do-cron-steps-work Bien cordialement, l0f4r0
Re: Cron toutes les 75 h
Tue, 12 May 2020 11:08:26 +0200 Raphaël POITEVIN écrivait : salut, > Je n’avais pas lu leman car le système n’a pas hurlé quand j’ai essayé > de lui metre des valeurs hors des bornes. > > > > Du coup je ne vois pas bien comment effectuer le décalage de 3 heures > > cherché > > avec le cron. > > J’essaierai avec un sleep ou quelque chose comme ça. Sinon, voir si systemd.timer peut offrir une solution. Si ton système utilise systemd. > Merci, > -- > Raphaël > www.leclavierquibave.fr Jean-Marc https://6jf.be/keys/ED863AD1.txt pgpajLGT111Ik.pgp Description: PGP signature
Re: Cron toutes les 75 h
> J’essaierai avec un sleep ou quelque chose comme ça. Quel intérêt de faire une tâche tous les 3 jours avec 3h de décalage sur une plage horaire aussi large ? Peut être faire un script qui s’exécute tous les jours à ce moment la, voir même, toutes les heures. Le script devra écrire un token quelque part, à vérifier. Si le token existe, y mettre la date et l'heure voulue pour exécuter le script. Une fois le script exécuté, supprimer le token. Lors de la nouvelle tâche cron, si le token n'existe pas, recréer le token pour dans 3 jours, avec une création aléatoire en ce qui concerne l'heure, qui sera saisie dans le token. Un truc dans le genre, non ?
Re: Cron toutes les 75 h
Pierre Malard writes: > Toujours dans le « man », on peut lire dans les exemples : ># Example of job definition: ># . minute (0 - 59) ># | .- hour (0 - 23) ># | | .-- day of month (1 - 31) ># | | | .--- month (1 - 12) OR jan,feb,mar,apr ... ># | | | | . day of week (0 - 6) (Sunday=0 or 7) OR > sun,mon,tue,wed,thu,fri,sat ># | | | | | ># m h dom mon dow usercommand > Ceci me semble clair, non ? Je n’avais pas lu leman car le système n’a pas hurlé quand j’ai essayé de lui metre des valeurs hors des bornes. > > Du coup je ne vois pas bien comment effectuer le décalage de 3 heures cherché > avec le cron. J’essaierai avec un sleep ou quelque chose comme ça. Merci, -- Raphaël www.leclavierquibave.fr
Re: Cron toutes les 75 h
Bonjour,
Ceci me semble normal à la lecture du « man » :
[…]Step values can be used in conjunction with ranges. Following a range
with ``/'' specifies skips of the number's value
through the range. […]
Si mon anglais n’est pas trop rouillé, « through the range » signifie « dans
la plage [de valeurs] ». Or dans ton cas tu lui indique qu’il doit effectuer
la tâche dans le créneau 9h 18h toute les 78 h … dans le créneau ! C’est un
peu étroit non ? ;-)
En plus il me semble que le système comprenant les astérisques et le notion
de date (@daily, @monthly, …) il ne peut qu’y avoir un calcul dans la limite
de temps choisi. C’est-à-dire 60 mn dans l’heure, 24h dans la journée,
{28,29,30,31} jours dans le mois, …
Toujours dans le « man », on peut lire dans les exemples :
# Example of job definition:
# . minute (0 - 59)
# | .- hour (0 - 23)
# | | .-- day of month (1 - 31)
# | | | .--- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | . day of week (0 - 6) (Sunday=0 or 7) OR
sun,mon,tue,wed,thu,fri,sat
# | | | | |
# m h dom mon dow usercommand
Ceci me semble clair, non ?
Du coup je ne vois pas bien comment effectuer le décalage de 3 heures cherché
avec le cron.
Désolé
> Le 12 mai 2020 à 10:25, Raphaël POITEVIN a écrit
> :
>
> Bonjour,
>
> Comment programmer une tâche toutes les 75 h à la minute 12 ? L’objectif
> étant d’exécuter la tâche tous les trois jours avec un décalage de 3 h
> entre 9h et 18h, du lundi au vendredi.
>
> Ma ligne :
> 12 9-18/75 * * 1-5 commande
> Cependant la tâche s’est bien exécutée hier à 9h12 mais s’est réexécutée
> ce matin même heure.
>
> En vous remerciant.
>
> Cordialement,
> --
> Raphaël
> www.leclavierquibave.fr
>
--
Pierre Malard
«Quand un Français dit du mal de lui, ne le croyez pas, Il se vante !»
Édouard Pailleron
|\ _,,,---,,_
/,`.-'`'-. ;-;;,_
|,4- ) )-,_. ,\ ( `'-'
'---''(_/--' `-'\_) πr
perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. ,\
( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_):
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--
signature.asc
Description: Message signed with OpenPGP
Cron toutes les 75 h
Bonjour, Comment programmer une tâche toutes les 75 h à la minute 12 ? L’objectif étant d’exécuter la tâche tous les trois jours avec un décalage de 3 h entre 9h et 18h, du lundi au vendredi. Ma ligne : 12 9-18/75 * * 1-5 commande Cependant la tâche s’est bien exécutée hier à 9h12 mais s’est réexécutée ce matin même heure. En vous remerciant. Cordialement, -- Raphaël www.leclavierquibave.fr
Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?
> Je n'ai pas regardé en détail la différence entre les deux, mais je pense > que tu fais fausse route. Peu importe la façon dont il va être lancé, il > est préférable de n'avoir qu'un seul script (qui pourra éventuellement > s'adapter à son contexte d'exécution). > > Là encore, il arrivera sûrement un jour où tu feras une modification dans > l'un et que tu oublieras de reporter dans l'autre et ce sera le drame. > > Sébastien Oui je me dis la même, faut que je revois ça, sans les nausées et les migraines.
Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?
Le 2020-05-09 15:17, G2PC a écrit : Ce qui nous donne, pour le moment, deux script différents, un que j'utilise manuellement, un second qui serait à lancer via la crontab de root. Je me trompe, ou, ils ne seront pas pareil, du fait de l'approche avec root, qui serait différente que dans le cas d'un utilisateur normal mais en sudoers ? Je n'ai pas regardé en détail la différence entre les deux, mais je pense que tu fais fausse route. Peu importe la façon dont il va être lancé, il est préférable de n'avoir qu'un seul script (qui pourra éventuellement s'adapter à son contexte d'exécution). Là encore, il arrivera sûrement un jour où tu feras une modification dans l'un et que tu oublieras de reporter dans l'autre et ce sera le drame. Sébastien
Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?
> Je privilégierais ça :
>
> sudo cp /etc/hosts.deny /etc/hosts.deny.bak
>
> Tu devrais interrompre ici si wget n'aboutit pas :
>
> wget https://hosts.ubuntu101.co.za/superhosts.deny -P /tmp || exit 1
>
>> cat /tmp/superhosts.deny > /etc/hosts.deny
>
> Chevron simple (">") plutôt non ? tu veux remplacer le contenu plutôt que
> l'ajouter à la suite (si j'ai bien suivi)…
Point 1 et 2 ok. Point 3, effectivement, initialement, je déplaçais le
fichier hosts.deny et il n'existait plus un court instant.
Ce qui nous donne, pour le moment, deux script différents, un que
j'utilise manuellement, un second qui serait à lancer via la crontab de
root.
Je me trompe, ou, ils ne seront pas pareil, du fait de l'approche avec
root, qui serait différente que dans le cas d'un utilisateur normal mais
en sudoers ?
En fait, je pense me tromper, car, même dans le script que je pense
comme " normal ", il est lancé par sudoers, donc, je dois également
définir le moment ou il faut utiliser le simple utilisateur pour
télécharger.
Par contre, j'ai un gros doute sur la fin du deuxième script, j'ai mis
deux fois exit, la première fois pour quitter l'utilisateur sur lequel
j'ai basculé, la deuxième fois pour quitter le script totalement.
# Proposition pour créer manuellement le nouveau fichier hosts.deny depuis un
script lancé par sudo :
# Utiliser le lien direct vers le fichier superhosts.deny (Plus de 15Mo) :
https://hosts.ubuntu101.co.za/superhosts.deny
sudo cp /etc/hosts.deny /etc/hosts.deny.bak
# On peut télécharger le fichier dans le répertoire /tmp en tant que simple
utilisateur.
# Arrêter le script si le fichier ne peut pas être téléchargé.
wget https://hosts.ubuntu101.co.za/superhosts.deny -P /tmp || exit 1
sudo -s
cat /tmp/superhosts.deny > /etc/hosts.deny
exit
rm /tmp/superhosts.deny
# Proposition pour créer le nouveau fichier hosts.deny depuis une tâche cron
lancée avec la crontab de root :
# Utiliser le lien direct vers le fichier superhosts.deny (Plus de 15Mo) :
https://hosts.ubuntu101.co.za/superhosts.deny
cp /etc/hosts.deny /etc/hosts.deny.bak
# On peut télécharger le fichier dans le répertoire /tmp en tant que simple
utilisateur.
# Arrêter le script si le fichier ne peut pas être téléchargé.
sudo - utilisateur_normal
wget https://hosts.ubuntu101.co.za/superhosts.deny -P /tmp || exit 1
# On quitte le simple utilisateur pour copier le contenu du fichier temporaire
vers le fichier appartenant à root:root
exit
cat /tmp/superhosts.deny > /etc/hosts.deny
# On supprime le fichier temporaire avec le simple utilisateur :
sudo - utilisateur_normal
rm /tmp/superhosts.deny
# On quitte, deux fois (?)
exit
exit
Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?
Bonjour,
Le 2020-05-09 12:46, G2PC a écrit :
# Utiliser le lien direct vers le fichier superhosts.deny (Plus de
15Mo) : https://hosts.ubuntu101.co.za/superhosts.deny
cd /etc
sudo cp hosts.deny hosts.deny.bak
J'éviterais ce type de construction (changement de dossier puis copie
avec des
noms relatifs). Il risque d'arriver un jour où tu
ajouteras/modifieras/supprimeras
une ligne qui fera que la copie relative ne se fera plus depuis le bon
endroit.
Je privilégierais ça :
sudo cp /etc/hosts.deny /etc/hosts.deny.bak
# On peut télécharger le fichier dans le répertoire /tmp en tant
que simple utilisateur :
wget https://hosts.ubuntu101.co.za/superhosts.deny -P /tmp
Tu devrais interrompre ici si wget n'aboutit pas :
wget https://hosts.ubuntu101.co.za/superhosts.deny -P /tmp || exit 1
cat /tmp/superhosts.deny >> /etc/hosts.deny
Chevron simple (">") plutôt non ? tu veux remplacer le contenu plutôt
que
l'ajouter à la suite (si j'ai bien suivi)…
Sébastien
Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?
> echo "X" > echo "Y" > echo "Z" > > en : > > cat <<'EOF' > X > Y > Z > EOF J'ai pris note.
Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?
> En fait, si d'aventure il y avait une tentative d'exploiter une > vulnérabilité dans wget(1), alors cela n'affecterait que le > compte qui aura lancé la commande. Pasque wget a des vulnérabilités aussi. Nom d'un gruyère ! >> De plus si on utilise ce script via crontab de root, le sudo ne sera pas >> utilisé, et, éventuellement, on récupèrera le fichier directement via le >> script lancé depuis la crontab de root, donc, en root. > Il est possible de céder ses drois de super utilisateur, avec > su(8) ou sudo(8) depuis un crontab(1) appartenant à root, en se > rabaissant aux droits d'un utilisateur normal, par exemple au > hasard nobody: Je ne sais pas ou tu a copier l'explication mais droits prend un " t " ;) > > su - nobody -c 'wget https://example.org/index.html -P /tmp' > sudo -u nobody wget https://example.org/index.html -P /tmp > > Un détail auquel je n'ai pas pensé précédemment, la commande > mv(1) conserve les utilisateurs et groupes, donc il faudra > penser attribuer le fichier à root et au groupe root avec > chown(1) avant de déplacer le fichier ou bien lancer à nouveau > une commande cp(1). " il faudra penser A attribuer " -> Les traductions ont des failles ;) Vu, Je suis passé de 4 à 7/10 lignes. Si ça me semble correcte pour un lancement à la main, je ne sais plus trop ou j'en suis pour un lancement du même script depuis la crontab de root. Mon script tel que proposé ici utilise sudo cp et par la suite sudo -s Lors d'une tache administrative lancée depuis la crontab de root, puis je laisser le script ainsi, ou, faudrait t'il faire disparaître les sudo et les sudo -s Je pense que cela fonctionnerait avec les sudo comme ci-dessous, mais, par contre, est ce qu'ils ont encore du sens dans un script lancé par root . Noter que j'ai bien lu ton explication, su ou sudo pourraient / devraient être utilisés pour changer d'utilisateur avec su - ou sudo - utilisateur. # Proposition pour une copie manuelle # Utiliser le lien direct vers le fichier superhosts.deny (Plus de 15Mo) : https://hosts.ubuntu101.co.za/superhosts.deny cd /etc *sudo cp* hosts.deny hosts.deny.bak # On peut télécharger le fichier dans le répertoire /tmp en tant que simple utilisateur : wget https://hosts.ubuntu101.co.za/superhosts.deny -P /tmp * sudo -s* cat /tmp/superhosts.deny >> /etc/hosts.deny *exit* rm /tmp/superhosts.deny # Proposition pour un script lancé depuis une tâche cron avec la crontab de root # Utiliser le lien direct vers le fichier superhosts.deny (Plus de 15Mo) : https://hosts.ubuntu101.co.za/superhosts.deny cd /etc cp hosts.deny hosts.deny.bak # On peut télécharger le fichier dans le répertoire /tmp en tant que simple utilisateur : * sudo - utilisateur_normal* wget https://hosts.ubuntu101.co.za/superhosts.deny -P /tmp # On quitte le simple utilisateur pour copier le contenu du fichier temporaire vers le fichier appartenant à root:root *exit* cat /tmp/superhosts.deny >> /etc/hosts.deny # On supprime le fichier temporaire avec le simple utilisateur : sudo utilisateur_normal rm /tmp/superhosts.deny # On quitte, deux fois (?) Une fois pour revenir à root, une seconde pour quitter la fin du script (?) exit exit > Comme quoi, en quatre ligne, il y a tout de même des choses à > dire... :) Effectivement. >>> Tout cela suppose que vous faites confiance au service délivré >>> par hosts.ubuntu101.co.za pour ne pas mettre n'importe quoi dans >>> votre /etc/hosts.deny, cat ils seraient en position de rendre >>> votre machine inaccessible en mettant l'Internet complet dans ce >>> fichier. >> C'est certain et effectivement, il me faut ici faire confiance au >> contenu, ce qui peut être affiné, je suppose avec des contrôles de >> certificats, ou, une politique de controle de /md5sum, ou les deux, et, >> peut être encore d'autres choses./ > md5sum(1) permet de vérifier l'intégrité du fichier, pour > s'assurer qu'il n'y a pas eu de morceaux perdus ou corrompus > pendant le transfert. Mais oui, il y a d'autres possibilités: > j'utilise gpg(1) pour vérifier à la fois l'intégrité et > l'autenticité de certains fichiers, pour m'assurer qu'ils ont > bien été construits par la personne qui a signé l'archive ; > sachant que même avec cette technique, il peut y avoir des > ratés. Lisez plutôt la page suivante pour un cas rencontré dans > la vie réelle : > > https://www.kernel.org/category/signatures.html > > Le gestionnaire de paquets APT utilise d'ailleurs cette méthode > pour s'assurer que le dépôt ou les paquets ont bien été > construits par les développeurs Debian, et pas quelqu'un autre ; > d'où les
Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?
8 mai 2020 à 18:20 de g...@visionduweb.com: > > > https://wiki.visionduweb.fr/index.php?title=Sommaire_S%C3%A9curit%C3%A9#Mettre_.C3.A0_jour_le_fichier_.2Fetc.2Fhosts_automatiquement_tous_les_mois > ...et j'oubliais, également remplacer les : echo "X" echo "Y" echo "Z" en : cat <<'EOF' X Y Z EOF Bien cordialement, l0f4r0
Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?
Bonjour,
8 mai 2020 à 18:20 de g...@visionduweb.com:
> https://wiki.visionduweb.fr/index.php?title=Sommaire_S%C3%A9curit%C3%A9#Mettre_.C3.A0_jour_le_fichier_.2Fetc.2Fhosts_automatiquement_tous_les_mois
>
1) Tu gagnerais en flexibilité/rapidité/lisibilité à modifier tes :
cmd1 >>/etc/hosts
cmd2 >>/etc/hosts
cmdX >>/etc/hosts
en :
{
cmd1
cmd2
cmdX
} >>/etc/hosts
2) C'est pas optimal en effet de se baser sur les numéros de lignes pour ton
sed...
Peut-être le plus simple serait de ne pas ajouter à la base ces lignes doublons
depuis le fichier téléchargé avec un truc du genre :
grep -vf /etc/hosts /tmp/hosts >>/etc/hosts
NB : la commande marche mais je t'invite à vérifier qu'il n'y a pas d'effet de
bord en pratique. Il est possible qu'il faille être un peu plus fin...
Bien cordialement,
l0f4r0
Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?
Bonjour, G2PC, on 2020-05-08 18:06:36 +0200: > J'entends la proposition d'utiliser un utilisateur normal pour récupérer > le fichier. > mais ensuite, on utilise sudo ( manuellement ) pour déplacer le fichier > du /tmp vers /etc En fait, si d'aventure il y avait une tentative d'exploiter une vulnérabilité dans wget(1), alors cela n'affecterait que le compte qui aura lancé la commande. Évidemment, si le contenu du fichier téléchargé peut être affecté par la vulnérabilité en question, alors il y aurait fort à parier que la commande finale qui écrase le fichier système puisse poser problème. > De plus si on utilise ce script via crontab de root, le sudo ne sera pas > utilisé, et, éventuellement, on récupèrera le fichier directement via le > script lancé depuis la crontab de root, donc, en root. Il est possible de céder ses drois de super utilisateur, avec su(8) ou sudo(8) depuis un crontab(1) appartenant à root, en se rabaissant aux droits d'un utilisateur normal, par exemple au hasard nobody: su - nobody -c 'wget https://example.org/index.html -P /tmp' sudo -u nobody wget https://example.org/index.html -P /tmp Un détail auquel je n'ai pas pensé précédemment, la commande mv(1) conserve les utilisateurs et groupes, donc il faudra penser attribuer le fichier à root et au groupe root avec chown(1) avant de déplacer le fichier ou bien lancer à nouveau une commande cp(1). Comme quoi, en quatre ligne, il y a tout de même des choses à dire... :) > > Tout cela suppose que vous faites confiance au service délivré > > par hosts.ubuntu101.co.za pour ne pas mettre n'importe quoi dans > > votre /etc/hosts.deny, cat ils seraient en position de rendre > > votre machine inaccessible en mettant l'Internet complet dans ce > > fichier. > > C'est certain et effectivement, il me faut ici faire confiance au > contenu, ce qui peut être affiné, je suppose avec des contrôles de > certificats, ou, une politique de controle de /md5sum, ou les deux, et, > peut être encore d'autres choses./ md5sum(1) permet de vérifier l'intégrité du fichier, pour s'assurer qu'il n'y a pas eu de morceaux perdus ou corrompus pendant le transfert. Mais oui, il y a d'autres possibilités: j'utilise gpg(1) pour vérifier à la fois l'intégrité et l'autenticité de certains fichiers, pour m'assurer qu'ils ont bien été construits par la personne qui a signé l'archive ; sachant que même avec cette technique, il peut y avoir des ratés. Lisez plutôt la page suivante pour un cas rencontré dans la vie réelle : https://www.kernel.org/category/signatures.html Le gestionnaire de paquets APT utilise d'ailleurs cette méthode pour s'assurer que le dépôt ou les paquets ont bien été construits par les développeurs Debian, et pas quelqu'un autre ; d'où les questions de configuration de GPG apparaissant dans le fil de discussion « reprepro » lancé par Marc Chantreux. Malgré la mise en place de cette technique, ça n'a pas empêché un incident fâcheux avec apt l'an dernier : https://www.debian.org/security/2019/dsa-4371 Amicalement, -- Étienne Mollier Fingerprint: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d Help find cures against the Covid-19 ! Give CPU cycles: * Rosetta@home: https://boinc.bakerlab.org/rosetta/ * Folding@home: https://foldingathome.org/ signature.asc Description: PGP signature
Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?
> Pour revenir au débat initial: *Pourquoi ne pas installer le paquet > Debian **etckeeper **?* Il permet de gérer sous git les fichiers de > configuration sous /etc > C'était pas forcément le débat initial, qui portait d'avantage sur les bonnes pratiques pour les tâches administratives, avec root, ou, un utilisateur aux droits spécifiques. Par contre, c'est une excellente information qui répond totalement à d'autres interrogations que je me posais ! Je conserve précieusement cette référence, je vais voir ce qu'il est possible de faire. Je ne sais pas ou tu es aller chercher tes références, mais, ta dernière réponse est digne d'une synthèse de conférence, avec de nombreuses ressources. Difficile de tout consulter, mais, très instructif.
Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?
>> Concernant le script, ce serait celui la, il n'est pas spécialement >> problématique, bon, tout de même QUATRE lignes. >> Je suppose que je peux de ce faire le lancer directement depuis le >> crontab de root, mais, un script de 4 lignes ce sera mieux. >> >> >> cd /etc >> sudo mv hosts.deny hosts.deny.bak >> sudo wget > https://hosts.ubuntu101.co.za/superhosts.deny> >> sudo mv superhosts.deny hosts.deny > A ma connaissance, si tu pars sur la piste d'un script setuidé root ou d'une > crontab root, tu peux virer les "sudo". > Si tu pars plutôt sur un utilisateur sudoer, alors je pense que sauf > directive "NOPASSWD" dans le fichier /etc/sudoers tu vas perdre toute > possibilité de programmation laissée sans surveillance (type crontab user) à > cause de l'interactivité requise pour sudo (demande du mot de passe). > > Bien cordialement, > l0f4r0 Effectivement, j'ai copié à la va vite le script qui, en ce qui concerne hosts.deny, a été partagé sur mon wiki pour le lancer manuellement. Il faut effectivement, dans le cas d'une crontab sous root, enlever les sudo, ce serait plus propre. Je crois que ça fonctionnerait tout de même sans saisie de mot de passe, sauf si je change d'utilisateur en route. # Utiliser le lien direct vers le fichier host.deny (Moins de 3Mo) : https://hosts.ubuntu101.co.za/hosts.deny cd /etc sudo cp hosts.deny hosts.deny.bak # On peut télécharger le fichier dans le répertoire /tmp en tant que simple utilisateur : wget https://hosts.ubuntu101.co.za/hosts.deny -P /tmp sudo mv /tmp/hosts.deny /etc/hosts.deny # Utiliser le lien direct vers le fichier superhosts.deny (Plus de 15Mo) : https://hosts.ubuntu101.co.za/superhosts.deny cd /etc sudo cp hosts.deny hosts.deny.bak # On peut télécharger le fichier dans le répertoire /tmp en tant que simple utilisateur : wget https://hosts.ubuntu101.co.za/superhosts.deny -P /tmp sudo mv /tmp/superhosts.deny /etc/hosts.deny https://wiki.visionduweb.fr/index.php?title=Sommaire_S%C3%A9curit%C3%A9#T.C3.A9l.C3.A9charger_une_version_.C3.A0_jour_du_fichier_hosts.deny Concernant la réécriture du fichier hosts, par contre, ce script semble prêt à une utilisation dans la crontab de root. Un détail tout de même, j'ai supprimé des lignes en double entre ma propre configuration et la configuration téléchargée, en utilisation sed pour supprimer des lignes en fonction du numéro de ligne. Il serait préférable d'identifier un modèle qui supprimera la zone de texte que je veux supprimer, plutôt que de supprimer un numéro de ligne. Si la configuration de mon hôte change, les lignes à supprimer ne seront plus au même endroit. https://wiki.visionduweb.fr/index.php?title=Sommaire_S%C3%A9curit%C3%A9#Mettre_.C3.A0_jour_le_fichier_.2Fetc.2Fhosts_automatiquement_tous_les_mois
Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?
> Peut-être que ce serait bien de remplacer la commande: >> sudo mv hosts.deny hosts.deny.bak >^^ > par: > > $ sudo cp hosts.deny hosts.deny.bak > ^^ > Sinon le fichier /etc/hosts.deny n'existe plus sur la machine > pendant le temps du téléchargement, ce qui pourrait laisser les > portes ouvertes aux vils pirates de tout poils pendant cet > interval de temps, fut-il juste de quelque millisecondes. Très juste ! Je l'avais fais pour le hosts et effectivement pour le hosts.deny utiliser mv c'est moins bien. Voilà qui est corrigé. Merci. >> sudo wget https://hosts.ubuntu101.co.za/superhosts.deny > Éventuellement, si vous ne faites pas confiance à wget, parce > que cette commande intéragit avec l'extérieur, il est possible > de récupérer le fichier en tant qu'un utilisateur normal, > éventuellement créé spécifiquement pour cette tâche ; ça fait > partie d'un éventuelle stratégie qui consisterait à « affiner > les droits » :) > > $ wget https://hosts.ubuntu101.co.za/superhosts.deny -P /tmp > > Du coup la commande suivante >> sudo mv superhosts.deny hosts.deny > deviendrait : > > $ sudo mv /tmp/superhosts.deny hosts.deny J'entends la proposition d'utiliser un utilisateur normal pour récupérer le fichier. mais ensuite, on utilise sudo ( manuellement ) pour déplacer le fichier du /tmp vers /etc De plus si on utilise ce script via crontab de root, le sudo ne sera pas utilisé, et, éventuellement, on récupèrera le fichier directement via le script lancé depuis la crontab de root, donc, en root. J'entends que au niveau de la politique des droits, on gagne une commande en tant que utilisateur normal, au lieu de root, ce qui à ce niveau semble mieux géré, Par contre, je ne vois pas forcément ce qu'on gagne au niveau de la sécurité, au niveau d'un risque éventuel, puisque au final, le fichier sera chargé dans /etc/hosts.deny > Tout cela suppose que vous faites confiance au service délivré > par hosts.ubuntu101.co.za pour ne pas mettre n'importe quoi dans > votre /etc/hosts.deny, cat ils seraient en position de rendre > votre machine inaccessible en mettant l'Internet complet dans ce > fichier. C'est certain et effectivement, il me faut ici faire confiance au contenu, ce qui peut être affiné, je suppose avec des contrôles de certificats, ou, une politique de controle de /md5sum, ou les deux, et, peut être encore d'autres choses./ > Amicalement, Merci
Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?
On 5/8/20 7:22 AM, G2PC wrote: Je lirais d'abord /Advanced Linux Programming/ <http://www.makelinux.net/alp/>, la section 2 <http://man7.org/linux/man-pages/man2/> des pages de man en commençant par intro(2) <http://man7.org/linux/man-pages/man2/intro.2.html> et syscalls(2) <http://man7.org/linux/man-pages/man2/syscalls.2.html> puis execve(2) <http://man7.org/linux/man-pages/man2/execve.2.html> et aussi credentials(7) <http://man7.org/linux/man-pages/man7/credentials.7.html> La page wikipedia sur Setuid <https://en.wikipedia.org/wiki/Setuid> est très instructive et importante et elle complète utilement les lectures précédentes. Il peut aussi être utile de lire un cours sur les systèmes d'exploitation. Celui-ci <http://pages.cs.wisc.edu/~remzi/OSTEP/> est en ligne, mais en anglais. Je le trouve excellent. Je pourrais le faire en utilisant une tache cron, avec l'utilisateur root. Je ne sais pas si c'est la meilleure façon de faire, utiliser root pour lancer une tache cron, pour télécharger un fichier qui appartiendra à root:root par défaut. Super ta réponse, tu m'aurais dit de lire google.fr, c'était tout aussi pertinent. *Ça veut dire quoi, **/meilleure façon de faire?/* Tu as oublié encore une fois d'expliciter en français le principal: *quels sont tes critères?* Le coût? Le temps que tu y passes? La cybersécurité? (c'est la même critique que sur l'envoi de SMS gratuitement: rien n'est gratuit sur terre, si tu comptes ton temps et tes compétences et ton envie d'apprendre). En particulier, *que se passe-t-il si ça merde d'une manière ou d'une autre?* Une guerre nucléaire? Une pandémie mondiale? Une catastrophe boursière? cent personnes qui perdent leur emploi? Ou juste toi qui perds une demi-heure de ton temps? A combien de kiloeuros estimes tu la perte de ce fichier? Et la perde de sa santé, d'un orteil, ou, d'une jambe, tu l'estimes à combien ? 4 euros ? 4000 euros ? 40 000 euros ? 400 000 euros ? 4 millions d'euros ? La notion pertinente est l'espérance mathématique <https://fr.wikipedia.org/wiki/Esp%C3%A9rance_math%C3%A9matique> (j'ai appris ça en terminale C, 1978) et le concept d'utilité <https://fr.wikipedia.org/wiki/Utilit%C3%A9_(%C3%A9conomie)#Repr%C3%A9sentation_math%C3%A9matique_de_la_fonction_d'utilit%C3%A9> en économie (j'ai appris ça en DEA à Jussieu, 1987) Je ne suis absolument pas expert de ces questions. Mais je renvoie par exemple aux écrits de Tirole <https://fr.wikipedia.org/wiki/Jean_Tirole> comme à ceux de Malinvaud <https://fr.wikipedia.org/wiki/Edmond_Malinvaud> (j'en ai lus quelques uns). Le prix d'un rein est estimé ici <https://priceonomics.com/post/50996688256/the-price-of-a-human-kidney> à 15000US$. Bien sûr, ça varie d'un pays à l'autre. Une remarque préalable: la santé a un coût. Un exemple que tout le monde connaît en France. Ce n'est que récemment (je crois il y a quelques années) que le prix du paquet de cigarettes (environ 10€, essentiellement des taxes) a dépassé le coût induit par les maladies liées au tabagisme. Un cancer coûte cher à la société française (je crois, plusieurs centaines de kiloeuros). J'ai perdu une sœur, elle avait 62 ans, morte de leucémie, il y a quelques années. Un exemple personnel: j'ai eu un lymphome <https://fr.wikipedia.org/wiki/Lymphome> (en 1990). C'est un cancer du sang qui peut être mortel. J'ai été soigné (et plus ou moins guéri). Mais j'ai reçu toutes les factures à la maison (heureusement, j'étais couvert à 100% grâce à la Sécurité Sociale). De mémoire, j'ai coûté à la Sécurité Sociale environ 200kiloFrancs à 300kiloFrancs pour cette année là. J'ai oublié les chiffres exacts. Un autre exemple personnel: mon père -qui a développé l'un des premiers compilateurs en France, le PAF <https://fr.wikipedia.org/wiki/Programmation_automatique_des_formules>- a été opéré en Californie (à l'époque il était chez IBM) en 1968 (j'avais 9 ans). A l'époque, pas d'imagerie médicale numérique (même en Californie pour un ingénieur de recherches chez IBM). Le chirurgien a merdé (tu imagines qu'opérer sans imagerie était complexe). Mon père a perdu un rein par la faute d'un chirurgien. Au départ, il ne voulait pas le poursuivre (avec l'argumentaire /errare humanum est/ <https://fr.wikipedia.org/wiki/Errare_humanum_est,_perseverare_diabolicum>), son chirurgien l'a convaincu du contraire (en expliquant qu'il était assuré). L'indemnité résultante a permis à mon père de s'acheter un appartement parisien - qu'il n'aurait pas pu se payer autrement. Mais je suis certain qu'il y a des barèmes en France comme ailleurs. D'une par
Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?
Bonjour, 8 mai 2020 à 07:35 de g...@visionduweb.com: > Concernant le script, ce serait celui la, il n'est pas spécialement > problématique, bon, tout de même QUATRE lignes. > Je suppose que je peux de ce faire le lancer directement depuis le > crontab de root, mais, un script de 4 lignes ce sera mieux. > > > cd /etc > sudo mv hosts.deny hosts.deny.bak > sudo wget > https://hosts.ubuntu101.co.za/superhosts.deny> > sudo mv superhosts.deny hosts.deny > > > A ma connaissance, si tu pars sur la piste d'un script setuidé root ou d'une crontab root, tu peux virer les "sudo". Si tu pars plutôt sur un utilisateur sudoer, alors je pense que sauf directive "NOPASSWD" dans le fichier /etc/sudoers tu vas perdre toute possibilité de programmation laissée sans surveillance (type crontab user) à cause de l'interactivité requise pour sudo (demande du mot de passe). Bien cordialement, l0f4r0
Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?
Bonjour, J'ai juste quelque remarques à deux sous. G2PC, on 2020-05-08 07:35:17 +0200: > Concernant le script, ce serait celui la, il n'est pas spécialement > problématique, bon, tout de même QUATRE lignes. > Je suppose que je peux de ce faire le lancer directement depuis le > crontab de root, mais, un script de 4 lignes ce sera mieux. Un script de quatre lignes, même s'il est court et peut être tapé à la main, ça fait beaucoup de ligne à taper s'il doit être exécuté fréquemment. Donc cron reste bienvenu. > cd /etc Peut-être que ce serait bien de remplacer la commande: > sudo mv hosts.deny hosts.deny.bak ^^ par: $ sudo cp hosts.deny hosts.deny.bak ^^ Sinon le fichier /etc/hosts.deny n'existe plus sur la machine pendant le temps du téléchargement, ce qui pourrait laisser les portes ouvertes aux vils pirates de tout poils pendant cet interval de temps, fut-il juste de quelque millisecondes. > sudo wget https://hosts.ubuntu101.co.za/superhosts.deny Éventuellement, si vous ne faites pas confiance à wget, parce que cette commande intéragit avec l'extérieur, il est possible de récupérer le fichier en tant qu'un utilisateur normal, éventuellement créé spécifiquement pour cette tâche ; ça fait partie d'un éventuelle stratégie qui consisterait à « affiner les droits » :) $ wget https://hosts.ubuntu101.co.za/superhosts.deny -P /tmp Du coup la commande suivante > sudo mv superhosts.deny hosts.deny deviendrait : $ sudo mv /tmp/superhosts.deny hosts.deny Tout cela suppose que vous faites confiance au service délivré par hosts.ubuntu101.co.za pour ne pas mettre n'importe quoi dans votre /etc/hosts.deny, cat ils seraient en position de rendre votre machine inaccessible en mettant l'Internet complet dans ce fichier. Amicalement, -- Étienne Mollier Fingerprint: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d Help find cures against the Covid-19 ! Give CPU cycles: * Rosetta@home: https://boinc.bakerlab.org/rosetta/ * Folding@home: https://foldingathome.org/ signature.asc Description: PGP signature
Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?
> Effectivement, il y a des questions à se poser quand on utiliser > l’utilisateur « root ». Mais là, dans ce cas, si je comprends bien > tu cherche à modifier un fichier « système » qui appartient > effectivement à … « root » avec un script que tu lanceras de ce même > serveur à partir d’un appel système géré par … « root » (cron) pour > contraindre les accès à ton serveur. > Donc, dans ce cas précis et si ton script est bien écrit et n’ouvre > pas trop les vannes (umask, droits d’exécution, …) je ne vois aucune > contre-indication à le lancer « root ». > Si tu veux mettre ceinture et bretelles, test dans ton script que > c’est bien le processus de gestion des CRON qui appelle ton script… > > Donc, pour résumer, voici ce que je ferais : > - script ayant les droits de root soit par héritage sudo, soit > directement sur l’ID appelant. Vérification que le père d’appel > du script est bien « cron ». > - exécution du script dans le /etc/cron.d avec les droits de root > > Bonne soirée > > -- > Pierre Malard > > « Les utopies ne sont souvent que des vérités prématurées » > Alphonse de > Lamartine >|\ _,,,---,,_ >/,`.-'`'-. ;-;;,_ > |,4- ) )-,_. ,\ ( `'-' > '---''(_/--' `-'\_) πr Merci pour les détails, bon, j'ai un peu de mal à comprendre " soit par héritage sudo, soit directement sur l’ID appelant " Un héritage sudo, je ne connais pas l'expression, mais, si c'est utiliser un sudoers, il me faudra donner le mot de passe, ce qui n'est pas sécure. Si c'est autre chose, il faut que je regarde. Idem pour l'ID appelant, pas forcément à l'aise avec cette formulation, si tu peux reformuler. Pour les droits d’exécution, ça va, je comprend. Pour Umask également, je défriche mais je ne les utilises que très peu pour le moment. Concernant le script, ce serait celui la, il n'est pas spécialement problématique, bon, tout de même QUATRE lignes. Je suppose que je peux de ce faire le lancer directement depuis le crontab de root, mais, un script de 4 lignes ce sera mieux. cd /etc sudo mv hosts.deny hosts.deny.bak sudo wget https://hosts.ubuntu101.co.za/superhosts.deny sudo mv superhosts.deny hosts.deny
Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?
> Bsr, > Si tout appartient à root, je pense que le plus simple est d'utiliser > simplement la crontab root. > Mais ce n'est que mon avis... Mais pourquoi faire simple quand on peut > faire compliqué Ou l'inverse, je ne sais plus trop... ;) > Cdt > Cyrille Vu. Pour le moment c'est la solution retenue.
Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?
> Je lirais d'abord /Advanced Linux Programming/ > <http://www.makelinux.net/alp/>, la section 2 > <http://man7.org/linux/man-pages/man2/> des pages de man en commençant > par intro(2) <http://man7.org/linux/man-pages/man2/intro.2.html> et > syscalls(2) <http://man7.org/linux/man-pages/man2/syscalls.2.html> > puis execve(2) <http://man7.org/linux/man-pages/man2/execve.2.html> et > aussi credentials(7) > <http://man7.org/linux/man-pages/man7/credentials.7.html> > > La page wikipedia sur Setuid <https://en.wikipedia.org/wiki/Setuid> > est très instructive et importante et elle complète utilement les > lectures précédentes. > > Il peut aussi être utile de lire un cours sur les systèmes > d'exploitation. Celui-ci <http://pages.cs.wisc.edu/~remzi/OSTEP/> est > en ligne, mais en anglais. Je le trouve excellent. > >> Je pourrais le faire en utilisant une tache cron, avec l'utilisateur root. >> Je ne sais pas si c'est la meilleure façon de faire, utiliser root pour >> lancer une tache cron, pour télécharger un fichier qui appartiendra à >> root:root par défaut. Super ta réponse, tu m'aurais dit de lire google.fr, c'était tout aussi pertinent. > *Ça veut dire quoi, **/meilleure façon de faire?/* > > Tu as oublié encore une fois d'expliciter en français le principal: > *quels sont tes critères?* Le coût? Le temps que tu y passes? La > cybersécurité? > > (c'est la même critique que sur l'envoi de SMS gratuitement: rien > n'est gratuit sur terre, si tu comptes ton temps et tes compétences et > ton envie d'apprendre). > > En particulier, *que se passe-t-il si ça merde d'une manière ou d'une > autre?* Une guerre nucléaire? Une pandémie mondiale? Une catastrophe > boursière? cent personnes qui perdent leur emploi? Ou juste toi qui > perds une demi-heure de ton temps? > > A combien de kiloeuros estimes tu la perte de ce fichier? > Et la perde de sa santé, d'un orteil, ou, d'une jambe, tu l'estimes à combien ? 4 euros ? 4000 euros ? 40 000 euros ? 400 000 euros ? 4 millions d'euros ? Je pense avoir été très claire, bien suffisamment, et, encore une fois, ta réponse ne m'a réellement rien apportée. J'ai proposé dans ma question, d'utiliser crontab en root. J'ai lu que les tâches administratives peuvent se faire avec la crontab de root. Maintenant, j'ai lu d'autres commentaires de personnes qui disent qu'on peut mieux faire, avec un utilisateur ayant des droits spécifiques, mais, sans jamais donner d'exemples. Je remarque la même chose, sur différentes communautés, plein de personnes disent qu'on peut faire autrement, en affinant les droits mais pas un est capable de l'expliquer. Alors oui, à mon niveau d'études, je peux aussi affirmer, et, passer pour un professionnel incompétent comme d'autres le font, en affirmant qu'on peut >> affiner les droits <<, mais, sans savoir le faire. Si je suis venu poser la question, c'est justement pour qu'une personne qui sait faire puisse partager un exemple, autre que celui de la crontab de root, puis il semble que tant de professionnels proposent de faire autrement et beaucoup mieux, en étant incapables de l'expliquer. Si tu me parles des setuid ok c'est une piste, évidemment, j'y ait déjà pensé, cela répond que peu à ma question. Clairement, on retrouvera dans de nombreuses documentations que l'utilisation de crontab en root est cohérent pour les tâches administratives. Je cherche donc à savoir si il y a une alternative correctement expliquée, dans le cas d'une tâche cron qui devrait mettre à jour un fichier appartenant à root, sans pour autant utiliser la crontab de root ou être sudoers. En sommes, je ne te demandes pas de liens vers une documentation, mais, si tu sais le faire, et, comment tu le ferais. Si tu sais le faire, je pense que tu peux synthétiser 3 phrases. Si tu ne sais pas, ne perd pas de temps à me répondre. Merci.
Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?
Ouahh, que de bonnes questions ! > Le 6 mai 2020 à 17:14, G2PC a écrit : > > Comment mettre à jour un fichier appartenant à l'utilisateur root avec > cron ? > > Bonjour, je cherche à mettre à jour le fichier deny.hosts proposé par > securityinfo, chaque semaine. > > Je pourrais le faire en utilisant une tache cron, avec l'utilisateur root. > Je ne sais pas si c'est la meilleur façon de faire, utiliser root pour > lancer une tache cron, pour télécharger un fichier qui appartiendra à > root:root par défaut. > > Faudrait t'il utiliser un autre utilisateur, sudoers ? > > Ou encore, un simple utilisateur, avec des droits particuliers pouvant > écrire ce fichier deny.hosts (qui appartient à root:root par défaut ? > > > Comment feriez vous ? > > Au plus simple, utiliser une tâche cron avec l'utilisateur root semble > rapide et fonctionnel, mais, est ce le plus adapté en ce qui concerne la > sécurité et les bonnes pratiques ? Effectivement, il y a des questions à se poser quand on utiliser l’utilisateur « root ». Mais là, dans ce cas, si je comprends bien tu cherche à modifier un fichier « système » qui appartient effectivement à … « root » avec un script que tu lanceras de ce même serveur à partir d’un appel système géré par … « root » (cron) pour contraindre les accès à ton serveur. Donc, dans ce cas précis et si ton script est bien écrit et n’ouvre pas trop les vannes (umask, droits d’exécution, …) je ne vois aucune contre-indication à le lancer « root ». Si tu veux mettre ceinture et bretelles, test dans ton script que c’est bien le processus de gestion des CRON qui appelle ton script… Donc, pour résumer, voici ce que je ferais : - script ayant les droits de root soit par héritage sudo, soit directement sur l’ID appelant. Vérification que le père d’appel du script est bien « cron ». - exécution du script dans le /etc/cron.d avec les droits de root Bonne soirée -- Pierre Malard « Les utopies ne sont souvent que des vérités prématurées » Alphonse de Lamartine |\ _,,,---,,_ /,`.-'`'-. ;-;;,_ |,4- ) )-,_. ,\ ( `'-' '---''(_/--' `-'\_) πr perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. ,\ ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_): 24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print' - --> Ce message n’engage que son auteur <-- signature.asc Description: Message signed with OpenPGP
Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?
Bsr, Si tout appartient à root, je pense que le plus simple est d'utiliser simplement la crontab root. Mais ce n'est que mon avis... Mais pourquoi faire simple quand on peut faire compliqué Ou l'inverse, je ne sais plus trop... ;) Cdt Cyrille
Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?
On 5/6/20 5:14 PM, G2PC wrote: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ? Comment feriez vous ? Je lirais d'abord /Advanced Linux Programming/ <http://www.makelinux.net/alp/>, la section 2 <http://man7.org/linux/man-pages/man2/> des pages de man en commençant par intro(2) <http://man7.org/linux/man-pages/man2/intro.2.html> et syscalls(2) <http://man7.org/linux/man-pages/man2/syscalls.2.html> puis execve(2) <http://man7.org/linux/man-pages/man2/execve.2.html> et aussi credentials(7) <http://man7.org/linux/man-pages/man7/credentials.7.html> La page wikipedia sur Setuid <https://en.wikipedia.org/wiki/Setuid> est très instructive et importante et elle complète utilement les lectures précédentes. Il peut aussi être utile de lire un cours sur les systèmes d'exploitation. Celui-ci <http://pages.cs.wisc.edu/~remzi/OSTEP/> est en ligne, mais en anglais. Je le trouve excellent. Je pourrais le faire en utilisant une tache cron, avec l'utilisateur root. Je ne sais pas si c'est la meilleure façon de faire, utiliser root pour lancer une tache cron, pour télécharger un fichier qui appartiendra à root:root par défaut. *Ça veut dire quoi, **/meilleure façon de faire?/* */ /* Tu as oublié encore une fois d'expliciter en français le principal: *quels sont tes critères?* Le coût? Le temps que tu y passes? La cybersécurité? (c'est la même critique que sur l'envoi de SMS gratuitement: rien n'est gratuit sur terre, si tu comptes ton temps et tes compétences et ton envie d'apprendre). En particulier, *que se passe-t-il si ça merde d'une manière ou d'une autre?* Une guerre nucléaire? Une pandémie mondiale? Une catastrophe boursière? cent personnes qui perdent leur emploi? Ou juste toi qui perds une demi-heure de ton temps? A combien de kiloeuros estimes tu la perte de ce fichier? Librement -- Basile STARYNKEVITCH == http://starynkevitch.net/Basile opinions are mine only - les opinions sont seulement miennes Bourg La Reine, France; (mobile phone: cf my web page / voir ma page web...)
Re: Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?
On Wednesday 06 May 2020 17:14:24 G2PC wrote: > Comment mettre à jour un fichier appartenant à l'utilisateur root avec > cron ? ... En créant un crontab sous le compte root. # crontab -e
Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ?
Comment mettre à jour un fichier appartenant à l'utilisateur root avec cron ? Bonjour, je cherche à mettre à jour le fichier deny.hosts proposé par securityinfo, chaque semaine. Je pourrais le faire en utilisant une tache cron, avec l'utilisateur root. Je ne sais pas si c'est la meilleur façon de faire, utiliser root pour lancer une tache cron, pour télécharger un fichier qui appartiendra à root:root par défaut. Faudrait t'il utiliser un autre utilisateur, sudoers ? Ou encore, un simple utilisateur, avec des droits particuliers pouvant écrire ce fichier deny.hosts (qui appartient à root:root par défaut ? Comment feriez vous ? Au plus simple, utiliser une tâche cron avec l'utilisateur root semble rapide et fonctionnel, mais, est ce le plus adapté en ce qui concerne la sécurité et les bonnes pratiques ?
Re: Running a music player via cron
oops mauvais aiguillage, désolé Jean-Philippe MENGUAL Le 25/09/2019 à 17:17, Jean-Philippe MENGUAL a écrit : > Hello, > > Since some Sid update (about 2 weeks), something may have happent in te > audio stack or the terminal because what worked no longer works. > > So I am under Sid, MATE desktop, via lightdm, pulseaudio, > systemd, etc. Ont minor thing is that if I run an audio as a user or > root at boot before login invia lightem, audio does not work, but well... > > Anyway, here I want to run mpv via a cron job under my regular user. The > command works, but via cron, I get an audio access problem. > > The command: > killall mpv;/home/jp/radio 10 100 > > The result: > > > TERM environment variable not set. > setleds: Error reading current flags setting. Maybe you are not on the > console?: ioctl KDGKBLED: Ioctl() inapproprié pour un périphérique > TERM environment variable not set. > CTRL+C to exit > Playing: http://direct.franceinfo.fr/live/franceinfo-midfi.mp3 > (+) Audio --aid=1 (mp3 1ch 44100Hz) > ALSA lib pcm_dmix.c:1108:(snd_pcm_dmix_open) unable to open slave > [ao/alsa] Playback open error: Device or resource busy > [ao/oss] Can't open audio device /dev/dsp: Device or resource busy > Cannot connect to server socket err = No such file or directory > Cannot connect to server request channel > jack server is not running or cannot be started > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, > skipping unlock > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, > skipping unlock > [ao/jack] cannot open server > ALSA lib pcm_dmix.c:1108:(snd_pcm_dmix_open) unable to open slave > couldn't open play stream: Device or resource busy > [ao/sndio] can't open sndio default > [ao] Failed to initialize audio driver 'sndio' > Could not open/initialize audio device -> no sound. > Audio: no audio > : 00:00:00 / 00:00:00 (0%) Cache: 0s > > > Exiting... (Errors when loading file) > TERM environment variable not set. > > > TERM environment variable not set. > > Same with: > killall mpv;env DISPLAY=:0 /home/jp/radio 10 100 > > Here is the script: > https://paste.debian.net/1102308/ > > Thanks for your help > > > Regards > > > > > > > >
Running a music player via cron
Hello, Since some Sid update (about 2 weeks), something may have happent in te audio stack or the terminal because what worked no longer works. So I am under Sid, MATE desktop, via lightdm, pulseaudio, systemd, etc. Ont minor thing is that if I run an audio as a user or root at boot before login invia lightem, audio does not work, but well... Anyway, here I want to run mpv via a cron job under my regular user. The command works, but via cron, I get an audio access problem. The command: killall mpv;/home/jp/radio 10 100 The result: TERM environment variable not set. setleds: Error reading current flags setting. Maybe you are not on the console?: ioctl KDGKBLED: Ioctl() inapproprié pour un périphérique TERM environment variable not set. CTRL+C to exit Playing: http://direct.franceinfo.fr/live/franceinfo-midfi.mp3 (+) Audio --aid=1 (mp3 1ch 44100Hz) ALSA lib pcm_dmix.c:1108:(snd_pcm_dmix_open) unable to open slave [ao/alsa] Playback open error: Device or resource busy [ao/oss] Can't open audio device /dev/dsp: Device or resource busy Cannot connect to server socket err = No such file or directory Cannot connect to server request channel jack server is not running or cannot be started JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock [ao/jack] cannot open server ALSA lib pcm_dmix.c:1108:(snd_pcm_dmix_open) unable to open slave couldn't open play stream: Device or resource busy [ao/sndio] can't open sndio default [ao] Failed to initialize audio driver 'sndio' Could not open/initialize audio device -> no sound. Audio: no audio : 00:00:00 / 00:00:00 (0%) Cache: 0s Exiting... (Errors when loading file) TERM environment variable not set. TERM environment variable not set. Same with: killall mpv;env DISPLAY=:0 /home/jp/radio 10 100 Here is the script: https://paste.debian.net/1102308/ Thanks for your help Regards -- Jean-Philippe MENGUAL
Lancement lecteur de musique via cron
Hello, Depuis une certaine mise à jour de Sid (environ 2 semaines), quelque chose a dû se passer dans les questions de son parce que ce qui fonctionnait ne marche plus. Je suis donc en Sid, bureau MATE, lancé avec lightdm, pulseaudio, systemd, etc. Une chose est que au boot du système, si je lance du son en root par ex, sur un tty à part de la console graphique, ça peut mal se passer. En tout cas là mon but est de lancer mpv via un cron sous mon utilisateur. Alors que la commande marche en exécution manuelle, elle ne se lance pas bien via cron, pour un souci d'accès au son. La commande est: killall mpv;/home/jp/radio 10 100 Le résultat est celui-ci: TERM environment variable not set. setleds: Error reading current flags setting. Maybe you are not on the console?: ioctl KDGKBLED: Ioctl() inapproprié pour un périphérique TERM environment variable not set. CTRL+C to exit Playing: http://direct.franceinfo.fr/live/franceinfo-midfi.mp3 (+) Audio --aid=1 (mp3 1ch 44100Hz) ALSA lib pcm_dmix.c:1108:(snd_pcm_dmix_open) unable to open slave [ao/alsa] Playback open error: Device or resource busy [ao/oss] Can't open audio device /dev/dsp: Device or resource busy Cannot connect to server socket err = No such file or directory Cannot connect to server request channel jack server is not running or cannot be started JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock [ao/jack] cannot open server ALSA lib pcm_dmix.c:1108:(snd_pcm_dmix_open) unable to open slave couldn't open play stream: Device or resource busy [ao/sndio] can't open sndio default [ao] Failed to initialize audio driver 'sndio' Could not open/initialize audio device -> no sound. Audio: no audio : 00:00:00 / 00:00:00 (0%) Cache: 0s Exiting... (Errors when loading file) TERM environment variable not set. setleds: Error reading current flags setting. Maybe you are not on the console?: ioctl KDGKBLED: Ioctl() inapproprié pour un périphérique =-=-=-=-=-=-=-=-= Which station would you like to listen to? =-=-=-=-=-=-=-=-= 1 Radio1 be_nl 2 ckia en_us 3 Europe1 be_nl 4 Frbleu provence 5 Virginradio fr_fr 6 frbleutoulon fr_fr 7 GG fr_fr 8 CheriefmFR fr_fr 9 Nostalgie fr_fr 10 FranceInfo fr_fr 11 CherieFM fr_fr 12 FunRadio fr_fr 13 Ckac en_gb 14 Europe1sport be_fr 15 FrInter fr_fr 16 NRJ fr_fr 17 NostalgieFR be_fr 18 Nostalgie60 be_nl 19 NrjFR be_nl 20 Rireetchanson be_nl 21 Rireetchanson nl_nl 22 Nostalgie70 be_fr 23 Rireetchansons be_nl 24 Rireetchansons be_nl 25 RFI fr_fr 26 RIM fr_fr 27 RireEtChansons fr_fr 28 RMC mc_fr 29 RTL fr_fr 30 100\% live 31 100\% sketch fr_fr 32 Modemradio nl_be 33 100\% nouvo talents en_us 34 StudioBrussel be_nl 35 TopRadio be_nl 36 Vivacit� be_fr -- TERM environment variable not set. TERM environment variable not set. J'ai le même résultat avec: killall mpv;env DISPLAY=:0 /home/jp/radio 10 100 Le script à l'oeuvre est là: https://paste.debian.net/1102308/ Merci de votre aide Cordialement, -- Jean-Philippe MENGUAL
cron : logs sans le nom du script : depuis quand, comment l'avoir de nouveau
Bonjour, En voulant trouver pourquoi un script ne tournait pas je viens de m'apercevoir que la façon dont cron écrivait dans les logs n'est plus très pratique (pour l'humain que je suis) actuellement j'ai un truc de ce genre : Jan 30 12:05:01 MonServeur CRON[32357]: pam_unix(cron:session): session opened for user www-data by (uid=0) Dans mes souvenir j'ai ça Jan 30 12:05:01 MonServeur CRON[32357]: [Monscript /dans/etc/cron.d/]: session opened for user www-data by (uid=0) [éventuellement sur la ligne suivante le code retour si != 0] Suis-je le seul a constater cela (pas de trace sur le script exécuté) Suis-je le seul a me rappeler de cela (que le cron donné dans les logs le script executé) Que faut-il faire pour avoir de nouveau le nom du script exécuté par cron (si dans /etc/cron.*/* évidement ) Je suppose que c'est l'option "-l" dans /etc/default/cron mais comme je ne comprends pas l'explication du man je me rapproche de la communauté ;-)
Re: Serveur bloqué par de multiples CRON -f ?
> Le Fri, Mar 17, 2017 at 08:30:21AM +0100, Daniel Caillibaud a écrit : > > > > Tu peux installer atop sur le host, et le régler avec une mesure par minute > > (10 par défaut, > > dans /etc/default/atop mettre `INTERVAL=60`), ça devrait te permettre après > > coup de voir à > > chaque minute l'état complet du host, par ex atop -r > > /var/log/atop/atop_mmdd -b hh:mm > > pour avoir un top amélioré de cette minute là, que tu peux trier par conso > > RAM, CPU, disque, > > etc. (man atop pour les détails). Le Mon, Sep 04, 2017 at 09:27:52AM +0900, Charles Plessy a écrit :> > > Nouveau plantage, mais cette fois-ci j'avais une fenêtre root ouverte. > Comme d'habitude, de nombreux processus « CRON -f » et impossibilité de > créer de nouvelles sessions (SSH, sudo, ...). Cause ou conséquence, > cette fois-ci un démon gitlab-ci-multi-runner (source: > https://packages.gitlab.com/runner) accumulait des dizaines d'instances > (car il plantait naturellement suite à une différence de compatibilité > avec notre serveur local). Je l'ai désinstallé, j'ai tué tous les > processus cron, j'ai relancé le service cron avec systemctl et j'ai > fini par un « systemctl reset-failed ». Je peux de nouveau me connecter > à la machine sans avoir eu besoin de la redémarrer. Bonjour à tous, nouveau plantage, toujours rien dans les logs ou atop. Cette fois-ci, la machine a re-planté (pas de nouvelles identifications possibles) peu après son redémarrage. Voici ce que je vois avec ssh -vvv: Tout va bien jusque: Authenticated to ([]:22). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug3: send packet: type 90 debug1: Requesting no-more-sessi...@openssh.com debug3: send packet: type 80 debug1: Entering interactive session. debug1: pledge: exec Ensuite, plus rien pendant longtemps, et ensuite, la machine casse son pipe. debug3: send packet: type 1 packet_write_wait: Connection to port 22: Broken pipe Perplexe, Charles -- Charles Plessy Tsurumi, Kanagawa, Japon
Re: Serveur bloqué par de multiples CRON -f ?
> Le 16/03/17 à 11:27, Charles Plessy a écrit : > CP> > CP> (Résumé des épisodes précédents, j'ai une machine virtuelle sur laquelle > il > CP> devient parfois impossible de se connecter. Les sessions existantes > continuent > CP> de fonctionner normalement, une grande partie des logs ne sont plus > écrits, et > CP> un processus cron par heure se lance, semble bloquer et s'accumule.) Le Fri, Mar 17, 2017 at 08:30:21AM +0100, Daniel Caillibaud a écrit : > > Tu peux installer atop sur le host, et le régler avec une mesure par minute > (10 par défaut, > dans /etc/default/atop mettre `INTERVAL=60`), ça devrait te permettre après > coup de voir à > chaque minute l'état complet du host, par ex atop -r > /var/log/atop/atop_mmdd -b hh:mm > pour avoir un top amélioré de cette minute là, que tu peux trier par conso > RAM, CPU, disque, > etc. (man atop pour les détails). Merci beaucoup pour la suggestion (et merci aussi à François pour sa réponse); c'est assez formidable de pouvoir faire un « top » à rebours ! Nouveau plantage, mais cette fois-ci j'avais une fenêtre root ouverte. Comme d'habitude, de nombreux processus « CRON -f » et impossibilité de créer de nouvelles sessions (SSH, sudo, ...). Cause ou conséquence, cette fois-ci un démon gitlab-ci-multi-runner (source: https://packages.gitlab.com/runner) accumulait des dizaines d'instances (car il plantait naturellement suite à une différence de compatibilité avec notre serveur local). Je l'ai désinstallé, j'ai tué tous les processus cron, j'ai relancé le service cron avec systemctl et j'ai fini par un « systemctl reset-failed ». Je peux de nouveau me connecter à la machine sans avoir eu besoin de la redémarrer. Un inspection avec atop de l'état de la machine au moment ou elle a cessé d'enregistrer ses logs (sauf -- MARK --) ne montre rien de spécial... Mais ceci dit merci encore de m'avoir fait apprendre atop. Je ne comprends toujours pas ce qui peut empêcher la machine de créer de nouvelles sessions alors qu'il y a assez de mémoire, d'espace disque et de temps processeur... Bonne journée, Charles -- Charles Plessy Tsurumi, Kanagawa, Japon
Re: Serveur bloqué par de multiples CRON -f ?
Le 16/03/17 à 11:27, Charles Plessy a écrit : CP> (Résumé des épisodes précédents, j'ai une machine virtuelle sur laquelle il CP> devient parfois impossible de se connecter. Les sessions existantes continuent CP> de fonctionner normalement, une grande partie des logs ne sont plus écrits, et CP> un processus cron par heure se lance, semble bloquer et s'accumule.) CP> Il a fallu attendre, mais le plantage nouveau est arrivé. CP> CP> `killall cron` enlève toutes les tâches cron bloquées, mais il est toujours CP> impossible de se connecter. C'est donc un symptôme et pas une cause. CP> CP> Dans kern.log, je note: CP> CP> Mar 14 11:51:56 dgt-med vmunix: [3190021.268633] rsession invoked oom-killer: […] CP> Mar 14 13:17:30 dgt-med vmunix: [3195156.740951] Task in /lxc/dgt-med killed as a result of CP> limit of /lxc/dgt-med À partir du moment où tu as de l'oom kill, ça sent mauvais et c'est pas si étonnant que ça parte en vrille ensuite. J'ai eu des pbs d'oomkill avec lxc + btrfs + kernel 4.9, les tâches btrfs qui suivent des modifs de snapshots déclenchaient de l'oomkill (sur le host) et aboutissaient au plantage total du host (repasser en 4.8 a réglé le pb pour le moment). Tu peux installer atop sur le host, et le régler avec une mesure par minute (10 par défaut, dans /etc/default/atop mettre `INTERVAL=60`), ça devrait te permettre après coup de voir à chaque minute l'état complet du host, par ex atop -r /var/log/atop/atop_mmdd -b hh:mm pour avoir un top amélioré de cette minute là, que tu peux trier par conso RAM, CPU, disque, etc. (man atop pour les détails). La suggestion de François sur le rsyslog distant est aussi une bonne idée pour pister l'origine du pb. Mais regarde quand même la mémoire dispo dans cette VM et les besoins attendus de rstudio, si c'est trop juste y'a p'tet pas vraiment d'autre solution que d'allouer plus de RAM à cette VM. -- Daniel - Aujourd'hui, c'est la chasse à l'ours. Où cours-tu le lapin? Tu ne risques rien! - Eh, t'es con! J'ai pas mes papiers! Coluche
Re: Serveur bloqué par de multiples CRON -f ?
Bonsoir, Je n'ai pas d'idée précise sur ton souci, désolé. En revanche, voici deux pistes pour tenter d'avoir plus d'éléments (enfin, j'espère). 1. Peut-être devrais tu tenter de grapher la machine (par exemple je crois que munin n'est pas très compliqué à mettre en place). Peut-être que les graphes quelques minutes ou quelques heures avant le « crash » t'indiqueront quelque chose. Une petite supervision sur la machine également pour avoir une idée du moment où elle plante pourrait aider. 2. Enfin, peut-être que le plantage entraîne le filesystem en read only et que tu perds du coup des infos précieuses qui ne peuvent être écrites dans les logs. Du coup, ça pourrait être intéressant d'envoyer le syslog de la machine sur le rsyslog d'une machine distante afin d'avoir une chance de disposer des logs même au moment du plantage. Voilà mes 2 centimes, rien d'extraordinaire. Bon courage. :) -- François Lafont
Re: Serveur bloqué par de multiples CRON -f ?
Le Thu, Mar 16, 2017 at 11:27:02AM +0900, Charles Plessy a écrit : > > Il me semble que chaque fois que le problème arrive, la machine a été stressée > sur ses ressources. Se pourrait-il qu'un processus essentiel pour établir des > nouvelles connections soit interrompu ou bloqué dans ces moment, et pas ou mal > relancé ensuite ? > > root@dgt-med:~# ps aux | grep root > root 1 0.0 0.0 28544 3360 ?Ss Feb07 0:30 /sbin/init > root 140 0.0 0.0 32968 2448 ?Ss Feb07 0:05 > /lib/systemd/systemd-journald > root 466 0.0 0.0 37096 168 ?Ss Feb07 0:04 > /sbin/rpcbind -w > root 501 0.0 0.0 27568 0 ?Ss Feb07 0:00 > /usr/sbin/rpc.idmapd > root 536 0.0 0.0 55184 1520 ?Ss Feb07 0:00 > /usr/sbin/sshd -D > root 550 0.2 0.0 65352 13036 ?Ssl Feb07 109:52 > /usr/bin/gitlab-ci-multi-runner run --working-directory > /var/lib/gitlab-runner --config /etc/gitlab-runner/config.toml --service > gitlab-runner --syslog --user gitlab-runner > root 614 0.0 0.0 28324 524 ?Ss Feb07 0:05 > /lib/systemd/systemd-logind > root 700 0.0 0.0 95260 352 ?Ss Feb07 1:07 > /usr/sbin/apache2 -k start > root 807 0.0 0.0 12652 1100 ?SFeb07 0:04 > /usr/sbin/syslogd --no-forward > root 1165 0.0 0.0 1266412 tty1 Ss+ Feb07 0:00 /sbin/agetty > --noclear tty1 linux > root 1173 0.0 0.0 1266412 ?Ss Feb07 0:00 /sbin/agetty > --noclear tty2 linux > root 1181 0.0 0.0 1266412 tty3 Ss+ Feb07 0:00 /sbin/agetty > --noclear tty3 linux > root 1189 0.0 0.0 1266412 tty4 Ss+ Feb07 0:00 /sbin/agetty > --noclear tty4 linux > root 1197 0.0 0.0 1688012 ?Ss Feb07 0:00 /sbin/agetty > --noclear --keep-baud pts/3 115200 38400 9600 vt102 > root 1205 0.0 0.0 1688012 ?Ss Feb07 0:00 /sbin/agetty > --noclear --keep-baud pts/2 115200 38400 9600 vt102 > root 1213 0.0 0.0 1688012 pts/1Ss+ Feb07 0:00 /sbin/agetty > --noclear --keep-baud pts/1 115200 38400 9600 vt102 > root 1221 0.0 0.0 1688012 ?Ss Feb07 0:00 /sbin/agetty > --noclear --keep-baud pts/0 115200 38400 9600 vt102 > root 1229 0.0 0.0 1688012 console Ss+ Feb07 0:00 /sbin/agetty > --noclear --keep-baud console 115200 38400 9600 vt102 > root 1566 0.0 0.0 9535212 ?Ss Feb07 0:00 sshd: plessy > [priv] > root 1607 0.0 0.0 6010812 pts/4SFeb07 0:00 sudo su - > root 1608 0.0 0.0 61592 0 pts/4SFeb07 0:00 su - > root 1609 0.0 0.0 26248 4296 pts/4SFeb07 0:00 -su > root 1646 0.0 0.0 6010812 pts/6SFeb07 0:00 sudo su - > root 1647 0.0 0.0 61592 0 pts/6SFeb07 0:00 su - > root 1648 0.0 0.0 26212 0 pts/6S+ Feb07 0:00 -su > root 2754 0.0 0.0 21716 2504 pts/4R+ 11:23 0:00 ps aux > root 2755 0.0 0.0 15344 1784 pts/4S+ 11:23 0:00 grep root > root 16949 0.0 0.0 9535212 ?Ss Mar06 0:00 sshd: plessy > [priv] > root 18795 0.0 0.0 9535212 ?Ss Mar06 0:00 sshd: plessy > [priv] > root 22802 0.0 0.0 9535220 ?Ss Mar07 0:00 sshd: plessy > [priv] Je me réponds à moi-même: je ne vois rien après le redémarrage (ci-dessous) qui manquerait avant (ci-dessus), si ce n'est cron que j'avais tué. # ps aux | grep root root 1 0.0 0.0 28520 4748 ?Ss Mar16 0:00 /sbin/init root 140 0.0 0.0 32968 6380 ?Ss Mar16 0:00 /lib/systemd/systemd-journald root 469 0.0 0.0 37096 2692 ?Ss Mar16 0:00 /sbin/rpcbind -w root 501 0.0 0.0 27568 224 ?Ss Mar16 0:00 /usr/sbin/rpc.idmapd root 522 0.0 0.0 30120 2764 ?Ss Mar16 0:00 /usr/sbin/cron -f root 536 0.0 0.0 55184 5368 ?Ss Mar16 0:00 /usr/sbin/sshd -D root 550 0.1 0.0 65096 23468 ?Ssl Mar16 2:03 /usr/bin/gitlab-ci-multi-runner run --working-directory /var/lib/gitlab-runner --config /etc/gitlab-runner/config.toml --service gitlab-runner --syslog --user gitlab-runner root 590 0.0 0.0 28268 2856 ?Ss Mar16 0:00 /lib/systemd/systemd-logind root 740 0.0 0.0 12652 2012 ?SMar16 0:00 /usr/sbin/syslogd --no-forward root 1058 0.0 0.0 12664 1872 ?Ss Mar16 0:00 /sbin/agetty --noclear tty1 linux root 1066 0.0 0.0 12664 1876 tty2 Ss+ Mar16 0:00 /sbin/agetty --noclear tty2 linux root 1074 0.0 0.0 12664 1852 tty3 Ss+ Mar16 0:00 /sbin/agetty --n
Re: Serveur bloqué par de multiples CRON -f ?
(Résumé des épisodes précédents, j'ai une machine virtuelle sur laquelle il devient parfois impossible de se connecter. Les sessions existantes continuent de fonctionner normalement, une grande partie des logs ne sont plus écrits, et un processus cron par heure se lance, semble bloquer et s'accumule.) > > Le 29/11/16 à 17:59, Charles Plessy a écrit : > > > > > > Je ne sais pas si les processus CRON sont une cause ou un symptome... > Le Wed, Nov 30, 2016 at 11:09:57AM +0100, Daniel Caillibaud a écrit : > > > > Si tu les kill (depuis une console ouverte avant qui continue de répondre), > > ça donne qqchose ? Le Mon, Dec 26, 2016 at 01:37:10PM +0900, Charles Plessy a écrit : > > Alors là, je suis vraiment désolé, mais j'ai gardé une fenêtre root pendant > quelques jours, et je l'ai ensuite fermée en pensant que le problème était > réglé suite à une fausse piste (Nagios qui harcelait le port SSH). > > Je donnerai des nouvelles au prochain plantage, mais d'ici là, s'il y a de > nouvelles idées... Il a fallu attendre, mais le plantage nouveau est arrivé. `killall cron` enlève toutes les tâches cron bloquées, mais il est toujours impossible de se connecter. C'est donc un symptôme et pas une cause. Dans kern.log, je note: Mar 14 11:51:56 dgt-med vmunix: [3190021.268633] rsession invoked oom-killer: gfp_mask=0x50, order=0, oom_score_adj=0 Mar 14 11:51:57 dgt-med vmunix: [3190021.268637] rsession cpuset=dgt-med mems_allowed=0-1 Mar 14 11:51:57 dgt-med vmunix: [3190021.268644] Hardware name: Dell Inc. C6100 /0D61XP, BIOS 1.71 09/17/2013 Mar 14 11:51:57 dgt-med vmunix: [3190021.268645] 8817baf44c00 880767c53c30 8176534f 88114c2b1460 Mar 14 11:51:57 dgt-med vmunix: [3190021.268648] 880767c53cb8 8175ef1f 0303 880767c53c58 Mar 14 11:51:57 dgt-med vmunix: [3190021.268650] 880767c53c80 81164f07 882fb90fd638 882fb90fd180 Mar 14 11:51:57 dgt-med vmunix: [3190021.268652] Call Trace: Mar 14 11:51:57 dgt-med vmunix: [3190021.268660] [] dump_stack+0x45/0x56 Mar 14 11:51:57 dgt-med vmunix: [3190021.268664] [] dump_header+0x7f/0x1f1 Mar 14 11:51:57 dgt-med vmunix: [3190021.268671] [] oom_kill_process+0x205/0x360 Mar 14 11:51:57 dgt-med vmunix: [3190021.268678] [] ? security_capable_noaudit+0x15/0x20 Mar 14 11:51:57 dgt-med vmunix: [3190021.268684] [] ? mem_cgroup_try_charge_mm+0xa0/0xa0 Mar 14 11:51:57 dgt-med vmunix: [3190021.268689] [] mm_fault_error+0x67/0x140 Mar 14 12:06:25 dgt-med vmunix: [3190890.132369] rsession invoked oom-killer: gfp_mask=0x50, order=0, oom_score_adj=0 Mar 14 12:06:25 dgt-med vmunix: [3190890.132377] CPU: 5 PID: 10550 Comm: rsession Tainted: P OE 3.16.0-38-generic #5 Mar 14 12:06:25 dgt-med vmunix: [3190890.132379] Hardware name: Dell Inc. C6100 /0D61XP, BIOS 1.71 09/17/2013 Mar 14 12:06:25 dgt-med vmunix: [3190890.132380] 8817baf44c00 8816d3f5bc30 8176534f 8818937065e0 Mar 14 12:06:25 dgt-med vmunix: [3190890.132383] 8816d3f5bcb8 8175ef1f 00e1 8816d3f5bc58 Mar 14 12:06:25 dgt-med vmunix: [3190890.132385] 8816d3f5bc80 81164f07 882fb90fd638 882fb90fd180 Mar 14 12:06:25 dgt-med vmunix: [3190890.132387] Call Trace: Mar 14 12:06:25 dgt-med vmunix: [3190890.132395] [] dump_stack+0x45/0x56 Mar 14 12:06:25 dgt-med vmunix: [3190890.132399] [] dump_header+0x7f/0x1f1 Mar 14 12:06:25 dgt-med vmunix: [3190890.132406] [] oom_kill_process+0x205/0x360 Mar 14 12:06:25 dgt-med vmunix: [3190890.132414] [] ? security_capable_noaudit+0x15/0x20 Mar 14 12:06:25 dgt-med vmunix: [3190890.132419] [] ? mem_cgroup_try_charge_mm+0xa0/0xa0 Mar 14 12:06:25 dgt-med vmunix: [3190890.132425] [] mm_fault_error+0x67/0x140 Mar 14 13:17:30 dgt-med vmunix: [3195156.740895] CPU: 1 PID: 6581 Comm: rstudio Tainted: P OE 3.16.0-38-generic #52~ Mar 14 13:17:30 dgt-med vmunix: [3195156.740898] 8817baf44c00 881f48137c30 8176534f 882fb13e28c0 Mar 14 13:17:30 dgt-med vmunix: [3195156.740901] 881f48137c80 81164f07 882c2cfae068 882c2cfadbb0 Mar 14 13:17:30 dgt-med vmunix: [3195156.740910] [] dump_stack+0x45/0x56 Mar 14 13:17:30 dgt-med vmunix: [3195156.740917] [] ? find_lock_task_mm+0x47/0xa0 Mar 14 13:17:30 dgt-med vmunix: [3195156.740923] [] ? mem_cgroup_iter+0x14b/0x320 Mar 14 13:17:30 dgt-med vmunix: [3195156.740927] [] mem_cgroup_oom_synchronize+0x581/0x5e0 Mar 14 13:17:30 dgt-med vmunix: [3195156.740932] [] pagefault_out_of_memory+0x14/0x80 Mar 14 13:17:30 dgt-med vmunix: [3195156.740938] [] __do_page_fault+0x4ec/0x560 Mar 14 13:17:30 dgt-med vmunix: [3195156.740944] [] ? set_next_entity+0x95/0xb0 Mar 14 13:17:30 dgt-med vmunix: [3195156.740948] [] do_page_fault+0x31/0x70 Mar 14 13:17:30 dgt-med vmunix: [3195156.740951] Task in /lxc/dgt-med killed as a re
Re: Serveur bloqué par de multiples CRON -f ?
Merci Daniel et randy11 pour vous réponses, et Joyeux Noël à tous ! Il y a du NFS, mais les systèmes de fichier sont accessibles. NIS est installé. Je ne suis pas certain qu'il soit utilisé (comment le vérifier ?). Le Wed, Nov 30, 2016 at 11:09:57AM +0100, Daniel Caillibaud a écrit : > Le 29/11/16 à 17:59, Charles Plessy a écrit : > CP> - Impossible de se connecter en SSH. > > Est-ce que auth.log dit qqchose lors de ces tentatives échouées ? Rien... À partir du moment ou le problème commence, auth.log ne contient plus aucune nouvelle ligne. $ tail auth.log Dec 19 13:17:01 dgt-med CRON[21322]: pam_unix(cron:session): session opened for user root by (uid=0) Dec 19 13:17:01 dgt-med CRON[21322]: pam_unix(cron:session): session closed for user root Dec 19 14:17:01 dgt-med CRON[2037]: pam_unix(cron:session): session opened for user root by (uid=0) Dec 19 14:17:01 dgt-med CRON[2037]: pam_unix(cron:session): session closed for user root Dec 19 15:17:01 dgt-med CRON[3979]: pam_unix(cron:session): session opened for user root by (uid=0) Dec 19 15:17:01 dgt-med CRON[3979]: pam_unix(cron:session): session closed for user root Dec 19 16:17:01 dgt-med CRON[5722]: pam_unix(cron:session): session opened for user root by (uid=0) Dec 19 16:17:01 dgt-med CRON[5722]: pam_unix(cron:session): session closed for user root Dec 19 17:17:01 dgt-med CRON[7597]: pam_unix(cron:session): session opened for user root by (uid=0) Dec 19 17:17:01 dgt-med CRON[7597]: pam_unix(cron:session): session closed for user root > CP> - Les connections en cours fonctionnent jusqu'à ce qu'on les tue ou les > bloque. > > Et depuis une connexion qui marche, tu vois rien d'intéressant lorsque Tout fonctionne parfaitement sauf que personne ne peut plus s'identifier. > CP> - Impossible de prendre les droits administrateur avec sudo (bloque la > session). > > Le message d'erreur permet pas de t'aiguiller ? Pas de message. Une fois appuyé sur « entrée », le curseur passe à la ligne, rien de nouveau ne s'affiche et la session ne rend pas la main. > CP> - Des processus « CRON -f » qui s'accumulent. > > Bizarre normalement y'en a qu'un(-f c'est foreground), tu sais qui les lance ? $ ps aux | grep CRON | tail root 30652 0.0 0.0 57496 2860 ? SDec22 0:00 /usr/sbin/CRON -f root 30694 0.0 0.0 57496 2860 ? SDec21 0:00 /usr/sbin/CRON -f root 30793 0.0 0.0 57496 2860 ? SDec23 0:00 /usr/sbin/CRON -f root 30925 0.0 0.0 57496 2860 ? SDec24 0:00 /usr/sbin/CRON -f root 31091 0.0 0.0 57496 2860 ? SDec25 0:00 /usr/sbin/CRON -f root 31267 0.0 0.0 57496 2860 ? SDec25 0:00 /usr/sbin/CRON -f root 31661 0.0 0.0 57496 2860 ? SDec20 0:00 /usr/sbin/CRON -f root 32347 0.0 0.0 57496 2860 ? SDec22 0:00 /usr/sbin/CRON -f root 32488 0.0 0.0 57496 2860 ? SDec23 0:00 /usr/sbin/CRON -f root 32621 0.0 0.0 57496 2860 ?SDec24 0:00 /usr/sbin/CRON -f > (je pense à un truc de monitoring qui vérifierait que cron est lancé, croit > qu'il ne l'est pas > et le relance). > Tu sais si ces cron lancent d'autres choses (un ps avec f permet de le voir) ? $ pstree 536 cron───176*[cron] > CP> - Journal systemd qui ne contient plus rien à partir du début du > bloquage. > CP> - systlog et messages pas plus intéressants: un « -- MARK -- » toutes > les 20 > CP>minutes et c'est tout. > > Ça dit déjà que le système peut écrire (le reste pourrait laisser penser à un > disque passé en > read only). > > Pas vraiment d'idée, le kern.log ne dit rien ? Dernier segfault le Dec 15 02:08:53, 4 jours avant que les ennuis ne recommencent. > Si tu n'as pas de kern.log, tu peux installer rsyslog pour qu'il le crée à > partir des messages > de systemd, mais si t'as rien avec journalctl y'aura probablement rien de > plus. $ journalctl -e | tail -n40 Dec 16 17:50:58 dgt-med systemd[24205]: Received SIGRTMIN+24 from PID 16150 (kill). Dec 16 17:50:59 dgt-med systemd[1]: Stopped User Manager for UID X. Dec 16 17:50:59 dgt-med systemd[1]: Stopping user-X.slice. Dec 16 17:50:59 dgt-med systemd[1]: Removed slice user-X.slice. Dec 17 13:51:22 dgt-med systemd[1]: Starting Cleanup of Temporary Directories... Dec 17 13:51:22 dgt-med systemd[1]: Started Cleanup of Temporary Directories. Dec 18 13:51:42 dgt-med systemd[1]: Starting Cleanup of Temporary Directories... Dec 18 13:51:42 dgt-med systemd[1]: Started Cleanup of Temporary Directories. Dec 19 11:56:50 dgt-med systemd[1]: Starting user-X.slice. Dec 19 11:56:50 dgt-med systemd[1]: Created slice user-X.slice. Dec 19 11:56:50 dgt-med systemd[1]: Starting User Manager fo
Re: Serveur bloqué par de multiples CRON -f ?
Le 29/11/16 à 17:59, Charles Plessy a écrit : CP> - Impossible de se connecter en SSH. Est-ce que auth.log dit qqchose lors de ces tentatives échouées ? CP> - Les connections en cours fonctionnent jusqu'à ce qu'on les tue ou les bloque. Et depuis une connexion qui marche, tu vois rien d'intéressant lorsque CP> - Impossible de prendre les droits administrateur avec sudo (bloque la session). Le message d'erreur permet pas de t'aiguiller ? CP> - Des processus « CRON -f » qui s'accumulent. Bizarre normalement y'en a qu'un(-f c'est foreground), tu sais qui les lance ? (je pense à un truc de monitoring qui vérifierait que cron est lancé, croit qu'il ne l'est pas et le relance). Tu sais si ces cron lancent d'autres choses (un ps avec f permet de le voir) ? CP> - Journal systemd qui ne contient plus rien à partir du début du bloquage. CP> - systlog et messages pas plus intéressants: un « -- MARK -- » toutes les 20 CP>minutes et c'est tout. Ça dit déjà que le système peut écrire (le reste pourrait laisser penser à un disque passé en read only). Pas vraiment d'idée, le kern.log ne dit rien ? Si tu n'as pas de kern.log, tu peux installer rsyslog pour qu'il le crée à partir des messages de systemd, mais si t'as rien avec journalctl y'aura probablement rien de plus. CP> Je ne sais pas si les processus CRON sont une cause ou un symptome... Si tu les kill (depuis une console ouverte avant qui continue de répondre), ça donne qqchose ? Tu peux laisser tourner un script qui check le nb de cron et t'envoie un mail dès qu'il y en a plus d'un, par ex #!/bin/bash sent=NO while [ $sent == "NO" ]; do [ $(ps ax|grep -c '[c]ron -f') -gt 1 ] \ && ps auxwf|mail -s "trop de cron" tonm...@domaine.tld \ && sent=YES sleep 10 done Histoire de voir si tu peux te connecter juste après et que ça dégénère plus tard (au moins tu auras tous les processus à ce moment là dans le mail, tu peux ajouter d'autres infos au mail envoyé). -- Daniel Mourir pour des idées, d'accord mais de mort lente. Georges Brassens.
Re: Serveur bloqué par de multiples CRON -f ?
Bonjour à tous, J'ai un serveur (en fait, une machine virtuelle) qui se bloque tous les deux ou trois mois, de la manière suivante: - Impossible de se connecter en SSH. - Les connections en cours fonctionnent jusqu'à ce qu'on les tue ou les bloque. - Impossible de prendre les droits administrateur avec sudo (bloque la session). - Des processus « CRON -f » qui s'accumulent. - Journal systemd qui ne contient plus rien à partir du début du bloquage. - systlog et messages pas plus intéressants: un « -- MARK -- » toutes les 20 minutes et c'est tout. Je ne sais pas si les processus CRON sont une cause ou un symptome... Bonjour, Quels sont les tâches confiées à la crontab ? Toutes les actions "cron" sont-elles lancées par le même utilisateurs ? Cause classique de blocage, un problème réseau : est-ce qu'il y a du NFS ? du LDAP ou NIS ? un automounter (autofs) ? du kerberos ? Désolé, mais je n'ai que des questions. Randy11
Serveur bloqué par de multiples CRON -f ?
Bonjour à tous, J'ai un serveur (en fait, une machine virtuelle) qui se bloque tous les deux ou trois mois, de la manière suivante: - Impossible de se connecter en SSH. - Les connections en cours fonctionnent jusqu'à ce qu'on les tue ou les bloque. - Impossible de prendre les droits administrateur avec sudo (bloque la session). - Des processus « CRON -f » qui s'accumulent. - Journal systemd qui ne contient plus rien à partir du début du bloquage. - systlog et messages pas plus intéressants: un « -- MARK -- » toutes les 20 minutes et c'est tout. Je ne sais pas si les processus CRON sont une cause ou un symptome... Avez vous vu ça ailleurs ? Pour le moment je bloque et Duck Duck Go (avec et sans !g) ne trouve rien non plus avec des mots-clés comme « "CRON -f" debian blocked ». Je vais devoir redémarrer le serveur demain matin, et je n'ai accès que depuis l'ordinateur du bureau, donc avec le décalage horaire, je ne vais probablement pouvoir répondre qu'à une seule série de questions si vous en avez. Ceci dit, vos lumières sont les très bienvenues ! Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan
Re: cron toutes les 25 secondes
Le 10/08/2015 18:46, Daniel Huhardeaux a écrit : Bonjour, Le 10/08/2015 18:41, andre_deb...@numericable.fr a écrit : On Sunday 09 August 2015 11:42:47 you wrote: Ce n'est pas plutôt un cron toutes les 2 minutes? Regardes bien les session opened. Quelle est la syntaxe cron (crontab) toutes les heures à 9 minutes ? : 9 * * * * */9 * * * * commande [...] Pardon, pas tout lu, ma rectification c'est toutes les 9 minutes. Ton exemple est toutes les heures + 9 minutes, oui. -- Daniel -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/55c8d5fb.5010...@tootai.net
Re: cron toutes les 25 secondes
Bonjour à tous les utilisateurs et développeurs de Debian : Le lundi 10 août 2015 à 16:41, andre_deb...@numericable.fr a écrit : > Quelle est la syntaxe cron (crontab) toutes les heures à 9 minutes ? : > 9 * * * * Plus exactement, c'est : 9 * * * * où "" peut être root ou un simple utilisateur (comme andre par exemple...). Cordialement et à bientôt, Stéphane. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/201508101649.18051.stephane.garg...@gmail.com
Re: cron toutes les 25 secondes
Bonjour, Le 10/08/2015 18:41, andre_deb...@numericable.fr a écrit : On Sunday 09 August 2015 11:42:47 you wrote: Ce n'est pas plutôt un cron toutes les 2 minutes? Regardes bien les session opened. Quelle est la syntaxe cron (crontab) toutes les heures à 9 minutes ? : 9 * * * * */9 * * * * commande [...] -- Daniel -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/55c8d580.7020...@tootai.net
Re: cron toutes les 25 secondes
On Sunday 09 August 2015 11:42:47 you wrote: > Ce n'est pas plutôt un cron toutes les 2 minutes? Regardes bien les session > opened. Quelle est la syntaxe cron (crontab) toutes les heures à 9 minutes ? : 9 * * * * C'est bon ci-dessus ? Merci. André -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/201508101841.52285.andre_deb...@numericable.fr
Re: cron toutes les 25 secondes
On Sunday 09 August 2015 00:40:36 Nicolas FRANCOIS wrote: > Le Sat, 8 Aug 2015 22:40:32 +0200, > andre_deb...@numericable.fr a écrit : > > Mon fichier "/var/log/auth.log" indique : > > ===== > > Aug 8 22:25:01 CRON[7327]: pam_unix(cron:session): session > > opened for user root by (uid=0) > > Aug 8 22:25:29 CRON[7301]: pam_unix(cron:session): session > > closed for user root > > Aug 8 22:26:59 CRON[7327]: pam_unix(cron:session): session > > closed for user root > > Aug 8 22:27:02 CRON[7426]: pam_unix(cron:session): session > > opened for user root by (uid=0 > > ===== > > soit un cron toutes les ~25 secondes. > > Deux cron à 22h22, deux cron à 22h26... > > Comment est-ce possible, ayant un cron toutes les 30 minutes minimum > > de programmé ? (#crontab -e) > > Ce sont les jobs du système. Va voir du coté de /etc/cron*, un certain > nombre de programmes ajoutent des tâches (genre recherche de mises à > jour, reconstruction de bases de données...) à leur installation. > Après, on peut gratter pour savoir ce que tout ce petit monde fait :-) > J'ai à peu près la même chose sur mes logs à moi (ce qui n'est pas > forcément une bonne chose ;-) Nicolas FRANCOIS J'ai attentivement regardé dans /etc/cron.d/, et dans les répertoires /etc/cron.daily ... etc... , il n'y a aucune tâche toutes les ~25 secondes. Bon dimanche. André -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/201508091118.19518.andre_deb...@numericable.fr
Re: cron toutes les 25 secondes
Le Sat, 8 Aug 2015 22:40:32 +0200, andre_deb...@numericable.fr a écrit : > Bonsoir, > > Mon fichier "/var/log/auth.log" indique : > = > Aug 8 22:25:01 CRON[7327]: pam_unix(cron:session): session > opened for user root by (uid=0) > Aug 8 22:25:29 CRON[7301]: pam_unix(cron:session): session > closed for user root > Aug 8 22:26:59 CRON[7327]: pam_unix(cron:session): session > closed for user root > Aug 8 22:27:02 CRON[7426]: pam_unix(cron:session): session > opened for user root by (uid=0 > = > soit un cron toutes les ~25 secondes. > Deux cron à 22h22, deux cron à 22h26... > > Comment est-ce possible, ayant un cron toutes les 30 minutes minimum > de programmé ? > (#crontab -e) Ce sont les jobs du système. Va voir du coté de /etc/cron*, un certain nombre de programmes ajoutent des tâches (genre recherche de mises à jour, reconstruction de bases de données...) à leur installation. Après, on peut gratter pour savoir ce que tout ce petit monde fait :-) J'ai à peu près la même chose sur mes logs à moi (ce qui n'est pas forcément une bonne chose ;-) \bye -- Nicolas FRANCOIS | /\ http://nicolas.francois.free.fr | |__| X--/\\ We are the Micro$oft. _\_V Resistance is futile. You will be assimilated. darthvader penguin -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150809004036.28548...@gaston.baronie.vez
cron toutes les 25 secondes
Bonsoir, Mon fichier "/var/log/auth.log" indique : = Aug 8 22:25:01 CRON[7327]: pam_unix(cron:session): session opened for user root by (uid=0) Aug 8 22:25:29 CRON[7301]: pam_unix(cron:session): session closed for user root Aug 8 22:26:59 CRON[7327]: pam_unix(cron:session): session closed for user root Aug 8 22:27:02 CRON[7426]: pam_unix(cron:session): session opened for user root by (uid=0 = soit un cron toutes les ~25 secondes. Deux cron à 22h22, deux cron à 22h26... Comment est-ce possible, ayant un cron toutes les 30 minutes minimum de programmé ? (#crontab -e) Merci. André -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/201508082240.32260.andre_deb...@numericable.fr
Re: Cron
Le 28 avril 2015, maderios a écrit : > Pour Cron, il faut aller dans la boite de dialogue Profile/Schedule/add/ > et là tous est paramétrable à coups de clics: date, reboot, délai, > console mode, vue du crontab, etc... C'est archi-simple. Je comprends mieux le lien avec cron. Merci. -- Alain Rpnpif -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150429082015.43f87500...@chro.home
Re: Cron
On 04/28/2015 03:20 PM, Yannick VOYEAUD wrote: Bonjour, Je cherche un truc pour faire mes sauvegardes avec cron en graphique. Bonjour J'utilise l'interface graphique Luckybackup qui fonctionne avec Rsync. J'ai essayé d'autres programmes tels que Grsync mais Luckybackup offre plus de possibilités. Pour Cron, il faut aller dans la boite de dialogue Profile/Schedule/add/ et là tous est paramétrable à coups de clics: date, reboot, délai, console mode, vue du crontab, etc... C'est archi-simple. -- Maderios -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/553fde27.9090...@gmail.com
Re: Cron
Le 28 avril 2015, Yannick VOYEAUD a écrit : > Bonjour, > > Je cherche un truc pour faire mes sauvegardes avec cron en graphique. > > À moins que l'un d'entre-vous soit sympa pour me proposer les fichiers > qui vont bien. > > Tous les jours sauf le dimanche > Sauvegarde incrémentielle du disque A sur le disque B > Sauvegarde incrémentielle de home sur le disque C > On conserve la semaine précédant la semaine s-2 étant supprimée par le > dimanche > > Tous les dimanches > Sauvegarde complète du disque A sur le disque B avec écrasement de > l'incrémentielle de la semaine S-2 > Sauvegarde complète de home sur le disque C avec écrasement de > l'incrémentielle de la semaine S-2 > > Sur les disques B et C il doit y avoir en permanence les sauvegardes > incrémentielles du lundi au samedi ET la complète du dimanche > On devrait donc avoir une fois tout fait > Dimanche, Lundi à Samedi incrémentiel, Dimanche, semaine en cours > > Pour l'heure on mettra 01:00 la machine étant 24/24 en route. > > En espérant m'être bien fait comprendre. Bonsoir, Je ne comprends pas l'intérêt de lancer des logiciels en graphique avec cron sachant que cron est fait pour fonctionner en arrière-plan sans intervention de l'utilisateur. -- Alain Rpnpif -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150428155808.0cf4e500...@chro.home
Re: Re: GUI backup Cron
Je ne réponds pas à ta question, notamment sur les sauvegardes
incrémentales, car je ne les pratique plus depuis que je connais rsync
et sa famille, je préfère les différentielles.
En fait, entre machines DEBIAN, j'utilise rsync dans le cron et j'ai mis
au point les paramètres d'appels des scripts avec son GUI : grsync qui a
notamment le bouton de "test à vide" sans exécution réelle.
Ma machine perso (Xubuntu) est également sauvegardée en différentielle
(sur DEBIAN), mais à la demande et avec Unison.
J'ai créé des profils ("scripts de sauvegarde") que je peux appeler
directement.
Pierre
Le 28/04/2015 16:26, Johnny B a écrit :
> PS : attention au sujet "Cron" ca n'est pas pertinent, c'est du fourre
> tout
>
> -
>
>
> Oui c'est exactement ce que font ces tools (full snaphots, directory,
> files etc..) sinon ils n'auraient aucun intérêt.
>
> Il faut simplement prendre du temps et se documenter sur les features
> des tools
>
> Pour sa machine perso il faut s'orienter plutôt vers :
>
> *gnome_scheduler
> *grsync
> *backintime
> *timeshift
>
> ou sinon via un moteur de recherche :
> http://www.thegeekstuff.com/2012/05/backup-ubuntu-desktop/
>
>
>> Bonjour,
>>
>> Pas pour moi car ce n'est pas le système que je veux sauvegarder ce sont
>> des documents persos.
>>
>> Sinon il aurait répondu à mon besoin de ce que j'en ai pu voir.
>>
>> Amitiés
>>
>
--
Pro. Signature
Pierre Touzeau
--
Chargé de mission / Préfecture de region Basse-Normandie
SGAR/rue Daniel HUET/14038 CAEN CEDEX/Tel: +33 231 306 306
pierre.touz...@basse-normandie.pref.gouv.fr / Fax: ... 564
--
Re: Cron
c'est pas en graphique mais ca marche super bien (crypté, compressé etc) http://www.yvangodard.me/backup-incremental-avec-duplicity-installation-et-scripts-periodiques/ Jacky Le 28/04/15 15:20, Yannick VOYEAUD a écrit : Bonjour, Je cherche un truc pour faire mes sauvegardes avec cron en graphique. À moins que l'un d'entre-vous soit sympa pour me proposer les fichiers qui vont bien. Tous les jours sauf le dimanche Sauvegarde incrémentielle du disque A sur le disque B Sauvegarde incrémentielle de home sur le disque C On conserve la semaine précédant la semaine s-2 étant supprimée par le dimanche Tous les dimanches Sauvegarde complète du disque A sur le disque B avec écrasement de l'incrémentielle de la semaine S-2 Sauvegarde complète de home sur le disque C avec écrasement de l'incrémentielle de la semaine S-2 Sur les disques B et C il doit y avoir en permanence les sauvegardes incrémentielles du lundi au samedi ET la complète du dimanche On devrait donc avoir une fois tout fait Dimanche, Lundi à Samedi incrémentiel, Dimanche, semaine en cours Pour l'heure on mettra 01:00 la machine étant 24/24 en route. En espérant m'être bien fait comprendre. Amitiés -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/553fa24c.4080...@omega-centauri.net
Re: Cron
grsync semble alors la meilleure option ;) C'est le GUI par défaut de rsync. Plus user-friendly il y a unison-gtk. bon tests :) -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/CAJeHwDZxkPkfDF1Wef+jqNGh46r-wKHY2=fPEo=p4pr2sxp...@mail.gmail.com
Re: GUI backup Cron
PS : attention au sujet "Cron" ca n'est pas pertinent, c'est du fourre tout - Oui c'est exactement ce que font ces tools (full snaphots, directory, files etc..) sinon ils n'auraient aucun intérêt. Il faut simplement prendre du temps et se documenter sur les features des tools Pour sa machine perso il faut s'orienter plutôt vers : *gnome_scheduler *grsync *backintime *timeshift ou sinon via un moteur de recherche : http://www.thegeekstuff.com/2012/05/backup-ubuntu-desktop/ Bonjour, Pas pour moi car ce n'est pas le système que je veux sauvegarder ce sont des documents persos. Sinon il aurait répondu à mon besoin de ce que j'en ai pu voir. Amitiés -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/553f987b.60...@gmail.com
Re: Cron
Oui c'est exactement ce que font ces tools (full snaphots, directory, files etc..) sinon ils n'auraient aucun intérêt. Il faut simplement prendre du temps et se documenter sur les features des tools Pour sa machine perso il faut s'orienter plutôt vers : *gnome_scheduler *grsync *backintime *timeshift ou sinon via un moteur de recherche : http://www.thegeekstuff.com/2012/05/backup-ubuntu-desktop/ Bonjour, Pas pour moi car ce n'est pas le système que je veux sauvegarder ce sont des documents persos. Sinon il aurait répondu à mon besoin de ce que j'en ai pu voir. Amitiés -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/553f9790.9030...@gmail.com
Re: Cron
Le 28/04/2015 15:33, honeyshell a écrit : > http://korben.info/time-machine-linux.html > Bonjour, Pas pour moi car ce n'est pas le système que je veux sauvegarder ce sont des documents persos. Sinon il aurait répondu à mon besoin de ce que j'en ai pu voir. Amitiés -- Yannick VOYEAUD Aidez Ancestris en participant http://fr.ulule.com/ancestrisapoitiers signature.asc Description: OpenPGP digital signature
Re: Cron
Hello Yannick, Je ne veux pas paraitre relou ni lancer un troll mais Qwant ou Google te donneront largement ce que tu cherches sinon comme cité : backuppc Areca Backintime Timeshift etc...etc...etc..voila @+ On 04/28/2015 03:33 PM, honeyshell wrote: http://korben.info/time-machine-linux.html -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/553f9552.5010...@gmail.com
Re: Cron
http://korben.info/time-machine-linux.html -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/cajehwdy0hohqqpkspbbb8yvjgo+_yrng4dal91quar_6kmr...@mail.gmail.com
Re: Cron
backuppc ? Le 28/04/2015 15:20, Yannick VOYEAUD a écrit : > Bonjour, > > Je cherche un truc pour faire mes sauvegardes avec cron en graphique. > > À moins que l'un d'entre-vous soit sympa pour me proposer les fichiers > qui vont bien. > > Tous les jours sauf le dimanche > Sauvegarde incrémentielle du disque A sur le disque B > Sauvegarde incrémentielle de home sur le disque C > On conserve la semaine précédant la semaine s-2 étant supprimée par le > dimanche > > Tous les dimanches > Sauvegarde complète du disque A sur le disque B avec écrasement de > l'incrémentielle de la semaine S-2 > Sauvegarde complète de home sur le disque C avec écrasement de > l'incrémentielle de la semaine S-2 > > Sur les disques B et C il doit y avoir en permanence les sauvegardes > incrémentielles du lundi au samedi ET la complète du dimanche > On devrait donc avoir une fois tout fait > Dimanche, Lundi à Samedi incrémentiel, Dimanche, semaine en cours > > Pour l'heure on mettra 01:00 la machine étant 24/24 en route. > > En espérant m'être bien fait comprendre. > > Amitiés > -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/553f89c5.8060...@univ-orleans.fr
Cron
Bonjour, Je cherche un truc pour faire mes sauvegardes avec cron en graphique. À moins que l'un d'entre-vous soit sympa pour me proposer les fichiers qui vont bien. Tous les jours sauf le dimanche Sauvegarde incrémentielle du disque A sur le disque B Sauvegarde incrémentielle de home sur le disque C On conserve la semaine précédant la semaine s-2 étant supprimée par le dimanche Tous les dimanches Sauvegarde complète du disque A sur le disque B avec écrasement de l'incrémentielle de la semaine S-2 Sauvegarde complète de home sur le disque C avec écrasement de l'incrémentielle de la semaine S-2 Sur les disques B et C il doit y avoir en permanence les sauvegardes incrémentielles du lundi au samedi ET la complète du dimanche On devrait donc avoir une fois tout fait Dimanche, Lundi à Samedi incrémentiel, Dimanche, semaine en cours Pour l'heure on mettra 01:00 la machine étant 24/24 en route. En espérant m'être bien fait comprendre. Amitiés -- Yannick VOYEAUD Aidez Ancestris en participant http://fr.ulule.com/ancestrisapoitiers signature.asc Description: OpenPGP digital signature
Re: redirection des mails cron
Bonjour,
Sinon vous pouvez utiliser le parametre de configuration suivant dans
votre fichier cron ->
MAILTO=une.adresse@mail
Le 07/09/2014 23:07, Guillaume Membré a écrit :
Merci pour votre réponse,
j'ai donc configuré postfix sur la machine1 en "Satellite system", sur
machine2 "Internet with smarthost" et modifié mon /etc/aliases avec :
root: user, root@machine2. Ainsi mes mails sont conservés en local +
transmis à ma 2e machine.
2014-09-06 22:20 GMT+02:00 daniel huhardeaux <mailto:no-s...@tootai.net>>:
Le 06/09/2014 21:52, Guillaume Membré a écrit :
Bonjour,
Bonsoir,
je voudrais rediriger les mails de cron d'une de mes machines
sur une autre. Les 2 machines sont sur le même réseau.
En ce moment, je lis parfaitement les mails de cron via mutt
sur mes 2 machines, je voudrais pouvoir le faire que d'une seule.
Je suis un peu perdu dans la conf à appliquer : sur quelle
machine faut il mettre quel outil ? Connaissez vous un
tutoriel simple dans ce sens ?
Mes 2 machines sont sous debian wheezy.
Merci d'avance pour vos réponses
Les mails de cron sont pour root. Si donc tous les messages de
root sur machine1 doivent être envoyés vers machine2, une simple
règle dans /etc/aliases comme root: root@machine2 fait le travail.
Il faut bien entendu que machine1 soit configurée pour utiliser
machine2 comme smarthost avec postfix par ex.
--
Daniel
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet
"unsubscribe"
vers debian-user-french-requ...@lists.debian.org
<mailto:debian-user-french-requ...@lists.debian.org>
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
<mailto:listmas...@lists.debian.org>
Archive: https://lists.debian.org/540b6c72.8030...@tootai.net
--
Guillaume
Re: redirection des mails cron
Merci pour votre réponse, j'ai donc configuré postfix sur la machine1 en "Satellite system", sur machine2 "Internet with smarthost" et modifié mon /etc/aliases avec : root: user, root@machine2. Ainsi mes mails sont conservés en local + transmis à ma 2e machine. 2014-09-06 22:20 GMT+02:00 daniel huhardeaux : > Le 06/09/2014 21:52, Guillaume Membré a écrit : > >> Bonjour, >> > > Bonsoir, > > > >> je voudrais rediriger les mails de cron d'une de mes machines sur une >> autre. Les 2 machines sont sur le même réseau. >> En ce moment, je lis parfaitement les mails de cron via mutt sur mes 2 >> machines, je voudrais pouvoir le faire que d'une seule. >> Je suis un peu perdu dans la conf à appliquer : sur quelle machine faut >> il mettre quel outil ? Connaissez vous un tutoriel simple dans ce sens ? >> >> Mes 2 machines sont sous debian wheezy. >> >> Merci d'avance pour vos réponses >> > > Les mails de cron sont pour root. Si donc tous les messages de root sur > machine1 doivent être envoyés vers machine2, une simple règle dans > /etc/aliases comme root: root@machine2 fait le travail. Il faut bien > entendu que machine1 soit configurée pour utiliser machine2 comme smarthost > avec postfix par ex. > > -- > Daniel > > -- > Lisez la FAQ de la liste avant de poser une question : > http://wiki.debian.org/fr/FrenchLists > > Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" > vers debian-user-french-requ...@lists.debian.org > En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org > Archive: https://lists.debian.org/540b6c72.8030...@tootai.net > >
Re: redirection des mails cron
Le 06/09/2014 21:52, Guillaume Membré a écrit : Bonjour, Bonsoir, je voudrais rediriger les mails de cron d'une de mes machines sur une autre. Les 2 machines sont sur le même réseau. En ce moment, je lis parfaitement les mails de cron via mutt sur mes 2 machines, je voudrais pouvoir le faire que d'une seule. Je suis un peu perdu dans la conf à appliquer : sur quelle machine faut il mettre quel outil ? Connaissez vous un tutoriel simple dans ce sens ? Mes 2 machines sont sous debian wheezy. Merci d'avance pour vos réponses Les mails de cron sont pour root. Si donc tous les messages de root sur machine1 doivent être envoyés vers machine2, une simple règle dans /etc/aliases comme root: root@machine2 fait le travail. Il faut bien entendu que machine1 soit configurée pour utiliser machine2 comme smarthost avec postfix par ex. -- Daniel -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/540b6c72.8030...@tootai.net
redirection des mails cron
Bonjour, je voudrais rediriger les mails de cron d'une de mes machines sur une autre. Les 2 machines sont sur le même réseau. En ce moment, je lis parfaitement les mails de cron via mutt sur mes 2 machines, je voudrais pouvoir le faire que d'une seule. Je suis un peu perdu dans la conf à appliquer : sur quelle machine faut il mettre quel outil ? Connaissez vous un tutoriel simple dans ce sens ? Mes 2 machines sont sous debian wheezy. Merci d'avance pour vos réponses
Re: [RÉSOLU] Gérer l'envoi des rapports de cron
Le 05/09/2014 08:25, Pierre Malard a écrit : > > Une solution un peu comme le verre d’alcool, il faut se méfier des abus. > C’est un peu comme casser le thermomètre pour résoudre un problème > de température… Personnellement, je préfère la solution proposée par > Jean-Michel. Elle est plus raisonnable. > Tu as raison. Par ailleurs, il s'agit pour la plupart de sauvegardes git. Pour info : les commandes git-pull, git-commit et git-push ont des options --quiet. Mais il faut que l'option soit après la commande git, sinon git tombe en erreur. Par ailleurs, l'option -q / --quiet n'existe pas pour toutes les commandes de git (par exemple, il n'y en a pas pour git-status, ce qui est normal). Bref. Merci ! -- Adrien. signature.asc Description: OpenPGP digital signature
Re: [RÉSOLU] Gérer l'envoi des rapports de cron
Le 4 sept. 2014 à 12:06, Adrien a écrit : > Le 04/09/2014 10:26, Jean-Michel OLTRA a écrit : >> Le jeudi 04 septembre 2014, Pierre Malard a écrit... >> >>> Une solution est donc de s’assurer que les lancements cron soient >>> silencieux. Éventuellement, on peut encapsuler cette commande, si >>> elle est trop bavarde, dans un script d’analyse qui se charge soit >>> d’envoyer lui-même le mail d’alerte, >> Sinon, tu envoies le résultat de la commande à /dev/null, ce qui va la >> rendre silencieuse, pour le meilleur et pour le pire. Éventuellement, >> comme précisé dans le reste du message (que j'ai coupé), ne renvoyer que >> la sortie standard vers /dev/null, et conserver la sortie d'erreur en >> l'état. >> > > Bonjour Jean-Michel et Pierre, > > Merci pour vos réponses. Suite à mon premier message, j'avais > effectivement modifié les commandes pour envoyer toutes les sorties > standard vers le GPSF (Grand Puits Sans Fond, /dev/null). Et > effectivement je n'ai plus qu'un seul Cron qui me rappelle à son bon > souvenir, car il tombe en erreur. Une solution un peu comme le verre d’alcool, il faut se méfier des abus. C’est un peu comme casser le thermomètre pour résoudre un problème de température… Personnellement, je préfère la solution proposée par Jean-Michel. Elle est plus raisonnable. Cordialement -- Pierre Malard « On ne peut pas pousser à fond l'éducation politique et l'éducation tout court de masses sans l'accompagner d'un développement économique, culturel et social parallèle. » Romain Gary - "Les racines du ciel" |\ _,,,---,,_ /,`.-'`'-. ;-;;,_ |,4- ) )-,_. ,\ ( `'-' '---''(_/--' `-'\_) πr perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. ,\ ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_): 24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print' - --> Ce message n’engage que son auteur <-- signature.asc Description: Message signed with OpenPGP using GPGMail
