( cd /etc/
mv cron.weekly/$job cron.monthly/$job)
Du coup je me pose la question de la prochaine mise à jour: il me dis que
le nouveau paquet va déployer une nouvelle version dans le répertoire
par défaut en plus de l'ancienne que j'aurais bougé dans un autre répertoire. me trompe-je et comment les sysops de serveurs gèrent leurs mises à jour dans ce cas ?
Soit l'operation suivante
( cd /etc/
mv cron.weekly/$job cron.monthly/$job)
Conclusions:
* "chez moi ça marche (tm)"
* je n'ai pas trouvé un outils plus propre¹
* je me rassure en téléchargeant les sources de dwww pour constater
que j'y trouve un fichier
debian/dwww.cron.weekly
Du coup je me pose la question de la prochaine mise à jour: il me dis que
le nouveau paquet va déployer une nouvelle version dans le répertoire
par défaut en plus de l'ancienne que j'aurais bougé dans un autre répertoire. me trompe-je et comment les sysops de serveurs gèrent leurs mises à jour dans ce cas ?
En espérant que ça aide
- Tu gères l'install / la mise à jour avec un outil genre Salt ou
Ansible, avec lequel tu peux systématiquement vérifier et changer le
fichier cron déposé par le paquet
- Au lieu de faire un "mv", tu copies le fichier dans monthly, et tu
commentes dans le weekly la/les lignes qui vont bien. Dans ce cas, une
mise à jour te préviendra qu'un fichier de conf a été modifié
localement, et te proposera des choix de mise à jour.
Mes 3 ¢ (inflation oblige)
samper! en te lisant je suis en train de me demander si il compare
les contenus sans verifier le type. si tel est le cas je pourrais
simplement faire un lien symbolique. et quite à faire un lien
symbolique, autant se fendre d'un petit script dash pour proposer le mechanisme que je décrivais comme "ce à quoi je m'attendais" dans mon
mail initial.
Je ne suis pas sûr d'avoir bien compris l'idée avec le lien
symbolique. S'il s'agit d'avoir un lien du script depuis le
cron.weekly vers le cron.monthly, du coup est ce que cron ne va
pas interpréter à la fois le lien dans le weekly et le fichier
d'origine dans le monthly?
Ce que j'ai en tête, ce serait dans /etc/cron.weekly/$job
d'avoir tout au plus ce genre de commentaire :
# WARNING: frequency of the job has been reduced.
# Please refer to /etc/cron.monthly/$job for the real job.
# This file is left on purpose to prevent dpkg from duplicating
# the configuration in /etc/cron.weekly/ upon dwww upgrade.
Le seul souci que je vois avec cette approche est que si le
fichier de configuration du paquet change avec des changements
intéressants (par exemple lors d'une mise à jour majeure du
système), alors les différences avec le fichier d'origine (qui
est désormais dans /etc/cron.monthly/$job) passent à la trappe
dans le diff proposé par dpkg lors de la résolution du conflit
sur le fichier de configuration.
On Thu, Jan 23, 2025 at 10:16:12PM +0100, Étienne Mollier wrote:
Je ne suis pas sûr d'avoir bien compris l'idée avec le lien
symbolique. S'il s'agit d'avoir un lien du script depuis le
cron.weekly vers le cron.monthly, du coup est ce que cron ne va
pas interpréter à la fois le lien dans le weekly et le fichier
d'origine dans le monthly?
comme un bout de code vaut mieux qu'une longue explication, voilÃ
coemment j'aurais tendance à gérer le truc (en tout cas la dernière version que j'avais en tête):
https://git.unistra.fr/mc/demo/-/blob/stable/suckless-debian/system-cron-manager
du coup:
* les auteurs de paquets ne seraient pas impactés
* on peut revenir facilement au comportement précédent
évidement c'est un peu naif: il faudrait pouvoir gérer un lien
symbolique vers un chemin absolu.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 489 |
Nodes: | 16 (2 / 14) |
Uptime: | 36:25:27 |
Calls: | 9,669 |
Files: | 13,716 |
Messages: | 6,169,348 |