Bonjour,
Sur mon serveur,j’ai créé “/etc/cron.weekly/certbot” pour actualiser mon certificat “Letsencrypt” .
#/bin/bash
/opt/certbot/certbot-auto renew
Le revouvellement ne se fait pas automatiquement. Je passe le script dans “/etc/cron.daily/certbot” ; pas mieux.
Je vais en console lancer le script, ça marche ! Je suis tranquille pour trois mois, pas plus
Je vais voir les autres scripts cron de ma distribution … plusieurs commencent par :
#!/bin/sh
Suffirait il que je corrige ça au début de mon script ?
Pouvez vous m’aider à comprendre mon erreur ?
tail -f /var/log/cron
tail: cannot open '/var/log/cron' for reading: No such file or directory
tail: no files remaining
You have new mail in /var/mail/root
Je dois sortir immédiatement,
je reviens sur cette question demain
Il y a aussi ces courriels que je ne gère pas bien, j’aimerais …
les consulter adéquatement sur la console du serveur et
les faire envoyer automatiquement à mon courriel habituel
Toutes suggestions bienvenues
Cette rapidité, cette présence fait chaud au coeur, merci beaucoup
perso je suis pas trop fan d’utiliser /usr/bin/env . la personne ici explique bien ce que ma mémoire arrive jamais à se souvenir (mais en anglais…)
donc en réumé: pas possible de passer d’argument à la commande après « env », si nécessaire, et aussi un potentiel risque de sécurité si un script nommé « bash » est inséré qqpart dans un répertoire dans ton path.
aussi, sur certains systèmes, c’est possible que la commande « env » se trouve dans /bin/env ou même d’autres endroits, ce qui réduit l’importance de l’argument comme quoi cette utilisation soit plus portable.
dans ton exemple initial, on peut voir qu’il manquait en fait le ! dans la première ligne
Je suis autodidacte, et j’en vois les limites …
J’arrive à faire des choses relativement avancées qui correspondent à ce que je veux utiliser, et je fais des erreurs de débutant qui me bloquent, me bouffent du temps et probablement compromettent ma sécurité. Je cherche fondamentalement des solutions à ça.
A court terme, j’avance tout de même avec vous,
Je n’utilise que Debian ou Ubuntu, si je change, cela restera un dérivé Debian, pas envie dE me rajouter des situations particulières …
Je met le “!” qui manque, et dans trois mois, si je n’ai pas d,avertissement de sécurité, c’est que mon certificat est renouvelé, et que le script passe en cron maintenant. Je ne m’en rendrai compte que si je m’en rappelle encore à ce moment là !
Pourquoi je n’ai pas de “/var/log/cron” moi ?
Je me dis que c’est “/etc/crontab” qui devrait le générer. Je ne vois rien là qui puisse déclencher le log, cela devrait être ailleurs ? voici ce qu’il contient
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# m h dom mon dow user command
53 * * * * root cd / && run-parts --report /etc/cron.hourly
54 2 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
33 4 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
43 1 31 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#
*/15 * * * * www-data php -f /var/www/nextcloud/cron.php
encore quelques questions, complémentaires, en option …
pourquoi le script passait il en ligne de commande si il lui manquait un “!” ?
donc si je teste un script en ligne de commande ça ne suffit pas pour savoir qu’il va fonctionner en cron ?!?
#!/bin/sh ou #!/bin/bash est-ce une difféence significative à laquelle je devrais être attentif ?
pouvez vous me donner une petite ligne de commande à la con, que je pourrais rajouter dans un script maison pour, par exemple, ajouter la date dans un fichier que je placerait dans /var/log, histoire de vérifier que le script tourne bien comme prévu (après, si il tourne et ne donne pas le résultat attendu, je saurai que c’est les commandes du script qui sont en cause).
Le # indique un commentaire, le reste de la ligne ne devrait pas être pris en considération, mais le ! est une astuce pour indiquer dans quel environnement il faut exécuter le script. Alors pourquoi ça fonctionne? Parce qu’à la ligne de commande, tu es déjà dans bash.
/bin/sh est légèrement préférable pour une solution plus portable (sh c’est l’ancêtre de bash) bien que souvent sh est un lien symbolique vers bash.
Comme user normal (non-admin/root), ça peut-être difficile d’écrire dans /var/log. Pour générer un fichier avec la date, il suffit de faire
date > LE-FICHIER
Ou si tu veux un fichier avec la date dans le nom:
J’utilise +"%s" pour afficher le unix timestamp au lieu d’un format de date plus standard, juste pour garder ça simple (sinon, y’a toujours des caractères à escaper.
C’est fort probablement une question de distribution.
