Bonjour à tous , voilà je commence avec les tache planifiée mais j'ai une question j'ai ajouter via crontab -e des taches planifiée pour update mon systeme voici l'extrait
40 16 * * * sudo apt update &> Update-`date +%Y-%m-%d-%H-%M-%S`.log
45 16 * * * mv ./Update-* /home/unknownsec/logCronUpdate/
45 16 * * * sudo apt upgrade -y &> Upgrade-`date +%Y-%m-%d-%H-%M-%S`.log
50 16 * * * mv ./Upgrade-* /home/unknownsec/logCronUpdate/
55 16 * * * sudo apt dist-upgrade -y &> DistUpgrade-`date +%Y-%m-%d-%H-%M-%S`.log
00 17 * * * mv ./DistUpgrade-* /home/unknownsec/logCronUpdate/
05 17 * * * sudo apt autoremove -y &> AutoRemove-`date +%Y-%m-%d-%H-%M-%S`.log
10 17 * * * mv ./AutoRemove-* /home/unknownsec/logCronUpdate/
15 17 * * * sudo apt autoclean -y &> AutoClean-`date +%Y-%m-%d-%H-%M-%S`.log
20 17 * * * mv ./AutoClean-* /home/unknownsec/logCronUpdate/Je voudrais faire en sorte d'avoir un suivi sur les mise a jours savoir s'il s'effectue ou pas
malheuresement cela ne marche pas par le mv je ne sais pas ou sont stocké mes flux donc j'essaie de le mv par le dossier courant ./ mais cela ne marche pas, j'aimerai pouvoir les déplace dans un dossier en fin de flux directement un idée ? merci
# Jamais -e
Posté par Sytoka Modon (site web personnel) . Évalué à -2.
Ne JAMAIS éditer la crontab avec crontab -e, c'est impossible à suivre dans le temps par soi même ou une autre personne. Bref, il n'y a aucun historique ni moyen de savoir les actions lancé par ce moyen. C'est la porte ouverte au plat de spaghetti en quelques mois…
Faire un beau fichier propre et le déposer sous /etc/cron.d
Cela reviens au même… Il faut juste ajouter l'utilisateur lambda car ici je suppose que cela ne tourne pas sous root.
[^] # Re: Jamais -e
Posté par LaBienPensanceMaTuer . Évalué à 4.
Ca répond pas à ça question, et crontab -e, pour une utilisation "amateur" reste tout à fait adapté.
Sans compter qu'il n'est pas gagné que le /etc/cron.d soit implémenté sur toutes les distris et, surtout, sur les Unix.
Mauvais conseil, désolé…
[^] # Re: Jamais -e
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
Ou est-ce marqué que c'est une utilisation "amateur" ? La personne s'annonce avec l'identifiant AdminSec et dit elle même "je commence avec les tache planifiée".
J'ai tellement vu de "crontab -e" dans le monde pro que je persiste à penser que mon conseil de ne pas en faire est bon et non mauvais comme tu dis ;-)
[^] # Re: Jamais -e
Posté par voxdemonix . Évalué à 1.
Ptite question en passant : où sont situés les commandes que l'on a entré via contrab -e ? (j'ai du ré-installer une machine: j'avais accès aux fichiers du précédent système mais impossible de le démarrer, j'ai du retaper de mémoire tout les crontab -e)
N'hésites pas a faire un article (ou une page wiki) sur l'utilisation de cron de manière propre, perso je te lirai ;)
[^] # Re: Jamais -e
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Dans /var/spool/cron/crontabs
[^] # Re: Jamais -e
Posté par voxdemonix . Évalué à 1. Dernière modification le 16 octobre 2018 à 15:03.
Merci 😉
[^] # Re: Jamais -e
Posté par LaBienPensanceMaTuer . Évalué à 4.
Demain j'ouvre un compte "ManuMacron" et je suis le président? ;-)
Et d'ailleurs, il l'écrit et tu le cites: "il commence avec les tâches planifiées".
Il le redit d'ailleurs dans un commentaire un peu plus bas:
Et excuse moi, il me parait plus logique d'apprendre d'abord la méthode qui marche partout (aka crontab -e) avant de s'orienter vers les évolutions introduites par Linux et les *bsd, aka /etc/cron.{d,daily,weekly,monthly}
Pour finir sur le sujet cron, AdminSec est étudiant … à mon époque (pas si lointaine), on avait pas l'accès root au serveur utilisé pour les TP … tu fais comment sans crontab -e dans ce contexte, quand tu es un simple user ?
C'est comme les bashismes: perso, je conseillerai à un étudiant d'apprendre à correctement se servir de /bin/sh "de base" avant de s'envoyer sur les bashismes…
Pour continuer sur ton commentaire, dans un monde pro:
Tu versionnes correctement ces fichiers via git ou autre outil.
Tu commentes abondamment les modifications pour que tes co-admins aient l'historique.
Partant de ces deux "bonnes pratiques de base", je ne vois pas ce que ça change d'avoir 1 fichier par "tâche" VS 1 fichier pour toutes les tâches.
En outre, et toujours dans le monde pro:
N'oublie pas qu'avant d'être un pro, il faut connaitre "les bases".
[^] # Re: Jamais -e
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
Ah ah, tu enseignes l'informatique en repartant de la base ;-) Je me rappelle avoir du faire du ed pour dépanner un système SGI une fois au boot ! Qui apprends ed en introduction ?
Sinon, oui je versionne et oui je commente les commit et oui j'utilise un outil pour distribuer les fichiers de configurations.
Effectivement, le /etc/con.d n'est pas modifiable par tous ce qui pourrait poser soucis mais en regardant le script, il était clair :
la personne a des sudo évolué puisqu'il s'agit de mise à jour de la machine
les actions proposées étaient clairement des actions d'administrateur système
Donc, pour l'administration système, on peut je pense en 2018 commencer par les bonnes pratiques puis seulement ensuite, faire une parenthèse sur les systèmes plus exotiques…
Je dis cela car perso, devoir aller sur tous les comptes, voire ce qui traîne dans les crontab pour comprendre comment la machine marche et ses interactions avec les autres, c'est d'un autre temps.
Je ne dis pas que le crontab -e est mauvais (quoique), il doit juste être limité à mon sens à un usage personnel.
[^] # Re: Jamais -e
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 1. Dernière modification le 17 octobre 2018 à 23:57.
sérieux, c'est vraiment ça qui te choque le plus dans le post initial ??
le fait qu'il utilise cron comme un script en enchainant des commandes à des timestamp différents pour s'assurer de leur execution dans l'ordre me semble plus prioritaire..
[^] # Re: Jamais -e
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
C'est clair qu'il faut tout reprendre depuis la base ;-)
# Merci
Posté par AdminSec . Évalué à 1.
Très bien merci à vous, dans mon cours il me disait de passer par cette commande, les fichier de log de mes commande seront donc mis dans /etc/cron.d?
Qu'entendez vous par ajouté un utilisateur ? Le cron.d lance t'il les commande en root ? Merci de vos réponses
[^] # Re: Merci
Posté par LaBienPensanceMaTuer . Évalué à 2.
Jeune padawan, je t'invite à taper "man cron" dans un terminal et tu auras les réponses à toutes ces questions :-)
Ce qui distingue un bon admin d'un mauvais, c'est sa capacité à se documenter … soit un bon admin ;-)
# Utilise des chemins absolus
Posté par LaBienPensanceMaTuer . Évalué à 3.
Salut,
Tes commandes sont executés dans le working directory de cron ce qui n'est pas l'effet souhaité.
Il faut plutôt utiliser des chemins absolus: plutôt que
./DistUpgradetu peux plutôt utiliser/home/<ton user>/<le rep de ton choix>/DistUpgradeet ce pour tout tes commandes.Si tu souhaites ne pas répéter ce chemin (et faire des erreurs au passage), tu peux déclarer une variable,
TARGET_DIR=/home/<ton user>/<le rep de ton choix>/DistUpgradepuis ensuite utiliser${TARGET_DIR}/DistUpgrade.# simplifies toi la vie
Posté par NeoX . Évalué à 3. Dernière modification le 17 octobre 2018 à 10:01.
dans ton cron tu crees le fichier de log, puis tu le deplaces
pourquoi ne pas l'ecrire directement au bon endroit ?
avant :
apres :
# pb d'usage...
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 4.
Avant même de penser à utiliser /etc/cron.d, a directement loguer au bon endroit ou autre blagues de chemin, il y a un truc important à comprendre: avec un fichier cron tu planifie UNE tache.
Si cette tache est complexe comme "mettre a jour le système" on va créer un script, exemple un fichier
"unattended-upgrades.sh"qui va contenir les commandes à exécuter pour réaliser cette tâche.Ce fichier/script va permettre d'enchainer des commandes, de réagir en fonction du résultat etc. et une fois le fichier testé et validé alors on va rajouter une ligne cron pour en planifier l'exécution.
Attention lors de l'exécution d'un programme via CRON on ne bénéficie pas forcement de tous les paramétrages de notre shell personnel, il est recommandé de ne pas faire confiance au PATH aveuglement (override du PATH ou utilisation de commande via full-path '/bin/rm', …)
Autre remarque "sudo" est une commande qui permet temporairement (ou pas tant que ça avec sudo -i) d'obtenir des droits différents (en général les droits root mais ça ne s'y limite pas). C'est une commande qui n'a d'intérêt que dans une session utilisateur et qui peut nécessiter une interactivité (demande de mot de passe): pour un script de mise a jour du système on va plutôt faire en sorte que le programme soit directement lancé par l'utilisateur root directement via la crontab de root ou via /etc/crontab,/etc/cron.d en spécifiant une exécution par root.
Dernière remarque … le nom du script n'était pas innocent, il existe un programme "unattended-upgrade" qui fait le taf bien mieux que tout ce que tu pourras mettre en place ^
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.