Discussion :

[Sandra Coret]

Des chercheurs en sécurité ont découvert CronRAT, un nouveau cheval de Troie d'accès à distance (RAT) furtif conçu pour attaquer les systèmes Linux, se cachant sous la forme d'une tâche planifiée

Des chercheurs en sécurité ont découvert un nouveau cheval de Troie d'accès à distance (RAT) furtif, conçu pour attaquer les systèmes Linux. Baptisé CronRAT, ce malware cible actuellement les boutiques en ligne et permet aux attaquants de voler des données de cartes de crédit en déployant des skimmers de paiement en ligne sur les serveurs Linux.

Les chercheurs de Sansec avertissent que CronRAT "permet le vol de données Magecart côté serveur en contournant les solutions de sécurité basées sur le navigateur". C'est un phénomène particulièrement préoccupant.

CronRAT est décrit comme "une menace sophistiquée, dotée de techniques furtives inédites", et Sansec affirme que son mode de fonctionnement signifie qu'elle ne sera pas reconnue par les autres sociétés de sécurité avant un certain temps.

L'entreprise explique : "Sansec a découvert que CronRAT était présent sur plusieurs magasins en ligne, dont le plus grand magasin du pays. En raison de son exécution inédite, nous avons dû réécrire une partie de notre algorithme eComscan afin de le détecter. CronRAT n'est actuellement pas détecté par les autres fournisseurs de sécurité".

La société de sécurité poursuit :

"La principale prouesse de CronRAT est de se cacher dans le sous-système calendrier des serveurs Linux ("cron") un jour inexistant. De cette façon, il n'attire pas l'attention des administrateurs de serveurs. Et de nombreux produits de sécurité n'analysent pas le système cron de Linux.
CronRAT facilite le contrôle persistant d'un serveur de commerce électronique. Sansec a étudié plusieurs cas où la présence de CronRAT a conduit à l'injection de skimmers de paiement (alias Magecart) dans le code côté serveur."

Le CronRAT ajoute un certain nombre de tâches à la crontab avec une curieuse spécification de date : 52 23 31 2 3. Ces lignes sont syntaxiquement valides, mais génèrent une erreur d'exécution lorsqu'elles sont exécutées. Cependant, cela ne se produira jamais car elles sont programmées pour être exécutées le 31 février. Au lieu de cela, le véritable code du malware est caché dans les noms des tâches et est construit en utilisant plusieurs couches de compression et de décodage base64.

La véritable charge utile de CronRAT est un "programme Bash sophistiqué qui se caractérise par l'autodestruction, la modulation du temps et un protocole binaire personnalisé pour communiquer avec un serveur de contrôle étranger".

De plus, la connexion se fait sur TCP via le port 443 en utilisant une fausse bannière pour le service SSH Dropbear, ce qui permet également au malware de rester sous le radar.

Après avoir contacté le serveur C2, le déguisement tombe, envoie et reçoit plusieurs commandes, et obtient une bibliothèque dynamique malveillante. À la fin de ces échanges, les attaquants derrière CronRAT peuvent exécuter n'importe quelle commande sur le système compromis.

CronRAT a été trouvé sur plusieurs magasins à travers le monde, où il a été utilisé pour injecter sur le serveur des scripts qui volent les données des cartes de paiement - les attaques dites Magecart.

Sansec décrit le nouveau malware comme "une menace sérieuse pour les serveurs de commerce électronique Linux", en raison de ses capacités :

• Exécution sans fichier
• Modulation du temps
• Sommes de contrôle anti-tampering
• Contrôle via un protocole binaire et obscurci
• Lancement d'un RAT en tandem dans un sous-système Linux distinct.
• Serveur de contrôle déguisé en service "Dropbear SSH".
  Charge utile cachée dans les noms de tâches programmées CRON légitimes.

Toutes ces caractéristiques rendent CronRAT pratiquement indétectable. Sur le service d'analyse VirusTotal, 12 moteurs antivirus ont été incapables de traiter le fichier malveillant et 58 d'entre eux ne l'ont pas détecté comme une menace.

Source : Sansec

Et vous ?

Qu'en pensez-vous ?

Voir aussi :

Le ransomware "Hive" chiffre désormais les systèmes Linux et FreeBSD,
Mais cette variante du ransomware est encore boguée et ne fonctionne pas toujours

La NSA et le FBI dévoilent le nouveau malware Drovorub de fabrication russe ciblant Linux, les agences émettent une alerte commune contenant des détails techniques sur ce logiciel malveillant

[defZero]

Qu'en pensez-vous ?

Que ça devrait faire un moment que crond ne devrait plus être sur des serveurs en prod.
SystemD, adopté par toutes les principales distribs, proposant les units "timers", ils devraient faire des maj de leurs serveurs pour passer sur de la distrib contemporaine.
Ce qui devrait également leurs offrir au passage, une meilleur sécurité globale et de meilleurs perfs.

[greg91]

Comment un site web pourrait compromettre crond ?
Je voie pas (si PHP est bien configuré).

[tabouret]

Qu'en pensez-vous ?

Que ça devrait faire un moment que crond ne devrait plus être sur des serveurs en prod.
SystemD, adopté par toutes les principales distribs, proposant les units "timers", ils devraient faire des maj de leurs serveurs pour passer sur de la distrib contemporaine.
Ce qui devrait également leurs offrir au passage, une meilleur sécurité globale et de meilleurs perfs.

Tout à fait d'accord. Surtout qu'entre nous, cron n'arrive pas à la cheville des timers Systemd (pas de randomisation native, impossible de faire concilier day of month et day of week sous Cron sans passer par la commande "test" et j'en passe).

[eomer212]

encore un article fumeux pour foutre les jetons.
mais la seule chose qui serait interressante de savoir, c'est le mode de contamination.
j'aimerais bien savoir par quel moyen ce truc a pu s'implanter sur cron, voir meme etre enregistré sur le serveur et etre executé..
comme d'hab, on nous présente un épouvantail mais ca s'applique à ... personnne.
ils citent que ce cronrat serait présent sur plusieurs magasins en ligne, dont le plus grand magasin du pays" et c'est tout. quel pays, quel magasin??
du vent, rien de plus.

si vous voulez être en sécurité, donnez vous les moyens de pouvoir réinstaller complétement votre serveur et tous ses services. en clair, vos services /serveurs doivent etre des phénix, aptes à renaitre de leurs cendres si besoin.
ca résoudra 2 problématqiues principales.
- plantage matériel.
- contamination par une mauvaise politique de sécurité. reinstaller un serveur est l'equivalent d'une petite revue, l'occasion de se demander. 'mais pourquoi on fait ca.? pourquoi ce code fait ca. ou pourquoi ce code est obscurci? ou inaccessible?'

les plugins ou les services developpés par d'autres, c'est pratique, mais c'est comme de laisser un ouvrier extérieur bosser sur la serrure de votre coffre fort, seul la nuit, sans surveillance, chez vous, sans meme savoir qui c'est. donc, mef...
developper ses propres services ou prendre le temps de controler ce que fait une lib, comprendre ce qu'elle fait et comment avant de l'implanter, c'est le minimum..
maitrisez vos sauvegardes, ayez vos propres serveurs de sauvegarde.. ca aussi c'est important. et ca coute pas un bras..

HA, github, c'est pas la panacée, surtout quand c'est maintenant géré par agrosoft.. qui a toujours bien compris les besoins de la NSA.. laquelle NSA bosse pour l'etat americain qui pratique l'espionnage economique, entre autres.

quand on est developpeur, la méfiance doit devenir une seconde nature.. si on veut assurer la sécurité de ses clients et sa tranquilité..

[becket]

Le 31 février ? Même pas peur !

[MPython Alaplancha]

Bonjour,

Le CronRAT ajoute un certain nombre de tâches à la crontab avec une curieuse spécification de date : 52 23 31 2 3. Ces lignes sont syntaxiquement valides, mais génèrent une erreur d'exécution lorsqu'elles sont exécutées. Cependant, cela ne se produira jamais car elles sont programmées pour être exécutées le 31 février.

Comment un cron qui ne s'exécute pas peut-il lancer un code?

[edrobal]

Qu'en pensez-vous ?

Que ça devrait faire un moment que crond ne devrait plus être sur des serveurs en prod.
SystemD, adopté par toutes les principales distribs, proposant les units "timers", ils devraient faire des maj de leurs serveurs pour passer sur de la distrib contemporaine.
Ce qui devrait également leurs offrir au passage, une meilleur sécurité globale et de meilleurs perfs.

Pour modifier cron, il faut être root.

[Ti-Slackeux]

Pour modifier cron, il faut être root.

Bonjour et tout faux.
N'importe qui sous Linux peut utiliser la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

crontab -e

pour modifier sa propre crontab.

hth,

[Sve@r]

Bonjour

cron n'arrive pas à la cheville des timers Systemd (pas de randomisation native, impossible de faire concilier day of month et day of week sous Cron sans passer par la commande "test" et j'en passe)

Normal puisqu'il n'a pas été fait pour ça !!! Ah ben ma voiture n'arrive pas à la cheville des avions (pas de ADI, pas de pilotage automatique, impossible de la faire voler sans lui rajouter des ailes et j'en passe)

cron contient 3 paramètres de datation

• la datation horaire (à quelle heure dans la journée)
• la datation mensuelle (quel jour du mois et quel mois de l'année)
• la datation hebdomadaire (quel jour de la semaine)

avec possibilité souple dans l'expression des datations (ex 0-60/2 signifiant "toutes les 2 unités de temps entre 0 et 60) mais surtout avec cette spécification que si une datation mensuelle et hebdomadaire sont explicitement spécifiées (donc avec autre chose que l'étoile), il s'exécutera alors si l'une ou l'autre des dates se présente. Autrement dit je programme un truc le 31/12 le dimanche, le truc s'exécutera tous les 31/12 et aussi tous les dimanches. C'est comme ça que les concepteurs l'ont voulu et c'est comme ça que les concepteurs l'expliquent. Fatalement si ce n'est pas comme ça que toi tu veux l'utiliser, à toi de coder ce qu'il faut pour combler. Mais ce n'est pas parce que tu ne veux pas l'utiliser de la façon dont il a été conçu que ça doit être sa faute à lui !!! Justement Linux se veut assez souple et ouvert pour permettre l'utilisation d'autres outils plus adaptés (anacron, at, etc). Tu ne l'aimes pas ok, ce n'est pas une raison pour affirmer "qu'il n'arrive pas à la cheville d'autres trucs que tu aimes". Et puis ce n'est pas parce qu'un truc est plus récent, plus "moderne" qu'un autre qu'il sera forcément mieux tout le temps. Tout le monde se fout de la tronche des russes qui ont encore des ordinateurs à lampe en activité alors que nous on a des crays. Sauf que le jour où on se prend une IEM dans la tronche, les ordinateurs russes continueront à fonctionner tandis que nous, on sera dans le noir. Donc peut-être que dans d'autres situations que toi tu n'as pas mais que d'autres peuvent avoir c'est cron qui aura l'avantage.

tout faux.
N'importe qui sous Linux peut utiliser la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

crontab -e

pour modifier sa propre crontab.

Je pense que tu n'as pas bien réfléchi à tout ça.

N'importe qui peut utiliser la commande crontab -e à condition de ne pas se trouver dans cron.deny (première barrière qui liste les utilisateurs interdits et qui donc autorise tous les autres) ou d'être dans cron.allow (seconde barrière qui, si elle est présente, supplante la première et qui liste les utilisateurs autorisés et qui donc interdit tous les autres).

Et même si cela reste possible, tu présentes ça comme très simple, comme un simple user qui peut faire un crontab -e ("utiliser la commande" as-tu dit). Mais pour "utiliser une commande" il faut déjà être dans le système !!!
Donc déjà il faut que le "virus" qui s'exécute sur le serveur linux (on parle donc déjà là d'un truc qui va forcer un serveur style apache à faire des trucs pour lui) fasse lui-même le crontab -e (qui n'est pas un éditeur de cron mais qui se contente juste de lancer l'éditeur standard, peut-être "ed", peut-être "vi", peut-être "emacs", ou même peut-être rien du tout si l'admin de apache a bien configuré le compte associé au serveur donc dans ce cas là, pas d'éditeur !!!). Donc déjà c'est bien bien chaud. Mais allez, admettons. Mais ensuite quoi? Le processus lancé par ledit cron reste un processus utilisateur et pas root (l'utilisateur étant donc apache et qui n'a donc accès qu'à ses propres fichiers). Question droits d'accès au système, il devrait pouvoir gérer ça facilement le serveur Linux...

Et enfin comme d'autres l'ont si bien dit, je ne vois pas comment crond pourrait détecter qu'on est le 31 février pour enfin lancer le processus. A la limite convertir un "31 février" en "3 mars" certains outils savent le faire (exemple datetime de Python) mais penser qu'un outil (système en plus) ait été programmé pour faire l'inverse...

Donc non, pas "tout faux"...

[tabouret]

Bonjour

Normal puisqu'il n'a pas été fait pour ça !!! Ah ben ma voiture n'arrive pas à la cheville des avions (pas de ADI, pas de pilotage automatique, impossible de la faire voler sans lui rajouter des ailes et j'en passe)

cron contient 3 paramètres de datation

• la datation horaire (à quelle heure dans la journée)
• la datation mensuelle (quel jour du mois et quel mois de l'année)
• la datation hebdomadaire (quel jour de la semaine)

avec cette spécification que si une datation mensuelle et hebdomadaire sont explicitement spécifiées (donc avec autre chose que l'étoile), il s'exécutera alors si l'une ou l'autre des dates se présente. Autrement dit je programme un truc le 31/12 le dimanche, le truc s'exécutera tous les 31/12 et aussi tous les dimanches. C'est comme ça que les concepteurs l'ont voulu et c'est comme ça que les concepteurs l'expliquent. Fatalement si ce n'est pas comme ça que toi tu veux l'utiliser, à toi de coder ce qu'il faut pour combler. Mais ce n'est pas parce que tu ne veux pas l'utiliser de la façon dont il a été conçu que ça doit être sa faute à lui !!! Justement Linux se veut assez souple et ouvert pour permettre l'utilisation d'autres outils plus adaptés (anacron, at, etc). Tu ne l'aimes pas ok, ce n'est pas une raison pour affirmer "qu'il n'arrive pas à la cheville d'autres trucs que tu aimes". Et puis ce n'est pas parce qu'un truc est plus récent, plus "moderne" qu'un autre qu'il sera forcément mieux tout le temps. Tout le monde se fout de la tronche des russes qui ont encore des ordinateurs à lampe en activité alors que nous on a des crays. Sauf que le jour où on se prend une IEM dans la tronche, les ordinateurs russes continueront à fonctionner tandis que nous, on sera dans le noir. Donc peut-être que dans d'autres situations que toi tu n'as pas mais que d'autres peuvent avoir c'est cron qui aura l'avantage.


Je pense que tu n'as pas bien réfléchi à tout ça.

Je pense que tu n'as pas vraiment réfléchi au problème.
Cron a été crée pour faire des tâches planifiés, tout comme les timers Systemd. ils ont exactement le même but.
Définir un OU logique entre day of month et day of week est une erreur de conception que Systemd (agissant comme un ET logique), bien plus souple, à corriger.

La preuve, pour corriger ce défaut de conception de Cron, tu es obligé de rajouter la commande "test" si tu veux imiter le comportement de Systemd. Bref du bricolage degueula....Rajouter une commande dans la commande finale, tu y perds en lisibilité.

Idem pour la randomisation de démarrage, Cron en est tout à fait incapable. Et ce ne sont que des choses parmi d'autres qui font que les timers Systemd sont bien au dessus de Cron. Je ne crache pas sur Cron mais il faut savoir voir quand une chose est meilleur qu'une autre.

J'ajouterai que Cron ne fait strictement rien de mieux que ce que ne font déjà les timers Systemd et des cas d'utilisation j'en ai vu à la pelle sinon je t'en pris donne moi un seul exemple.

[Sve@r]

Je pense que tu n'as pas vraiment réfléchi au problème.

Tu veux jouer au comique de répétition?

Cron a été crée pour faire des tâches planifiés, tout comme les timers Systemd. ils ont exactement le même but.

Oui, tout comme "anacron" ou "at". Même but mais pas dans les mêmes conditions. Et ce sont ces conditions qui te feront choisir l'outil qui s'y adapte le mieux. Même "timer" sera utile dans des conditions qui lui sont adaptées.

Définir un OU logique entre day of month et day of week est une erreur de conception

Ah? Et d'où tu sors que c'est une erreur? Sans déconner, des types ont voulu faire un truc agissant selon une certaine logique qu'ils ont définie et toi tu arrives et tu leur dis "non non les gars, c'est pas comme ça que vous devez penser votre truc". M'étonnerait pas qu'ils te répondent d'aller te faire...
Tout choix aura toujours des avantages et des inconvénients. Mais choisir A plutôt que B n'est certainement pas une erreur de conception. Ou bien ce sera une erreur dans le cas où tu veux faire B mais eux ont voulu faire A.

que Systemd (agissant comme un ET logique), bien plus souple, à corriger.

"à corriger" et "a corrigé" n'ont pas la même signification. Sauf que j'ai l'impression que tu voulais exprimer l'autre (sinon ça veut dire que systemd est un truc pas fini "à finir"). Si tu ne sais pas quand employer l'infinitif ou le participe passé, tu remplaces par "vendre" comme ça tu verras de suite s'il faut dire "à vendre" ou "a vendu".

La preuve, pour corriger ce défaut de conception de Cron, tu es obligé de rajouter la commande "test" si tu veux imiter le comportement de Systemd.

Alors déjà ce n'est pas moi qui ai besoin de faire quoi que ce soit (je n'ai jamais dit avoir besoin moi de faire en sorte qu'une chose se lance tel jour de tel mois à condition que ce soit aussi tel jour de la semaine, c'est toi, et déjà j'ai du mal à voir le but d'un tel truc) et ce n'est pas une preuve de défaut de conception, c'est juste la preuve que tu utilises un outil dans des conditions pour lesquelles il n'a pas été conçu. Ok tu as le droit d'avoir des besoins spécifiques mais ce n'est pas la faute de l'outil si tes besoins t'obligent à rajouter les contrôles qui manquent, et même si un autre outil le permet, ce n'est pas pour cela que le premier doit être foutu au trou. Et à l'inverse si cron était codé pour lancer la tâche au jour et au mois qui correspond pile poil au jour de la semaine, je me demande bien comment tu ferais pour lui demander l'inverse, c'est à dire de lancer un truc au jour et au mois et aussi au jour de la semaine. Un "ou" (qui contient trois "uns" et un seul "zéro") peut parfaitement être réduit à un "et" (suffit de rajouter les tests manquants pour éliminer les "uns" en trop) tandis que pour transformer un "et" en "ou" (c'est à dire faire revenir l'information qui a été détruite)...

Bref du bricolage degueula....Rajouter une commande dans la commande finale, tu y perds en lisibilité.

Bah non, j'utiliserais timer (je n'ai jamais dit non plus qu'il n'était pas à utiliser !!!). Et dans le pire des cas, rien ne m'interdit de faire un lanceur intermédiaire un peu universel que je viendrai intercaler entre le cron et ma commande finale. De suite ça devient moins "bricolage degeu"...

Je ne crache pas sur Cron

Ah ben si, quand tu réponds "tout à fait d'accord" à la phrase de defZero disant que cron ne doit plus être utilisé. Si ça ce n'est pas "cracher dessus"...

mais il faut savoir voir quand une chose est meilleur qu'une autre.

Meilleur !!! En voilà un jugement bien péremptoire!!! Encore une fois tout dépend du besoin (cf mon exemple entre voiture et avion). Qu'est-ce qui est meilleur? Une pêche ou une poire? Même les plus grands dans leur discipline l'ont dit, il n'y a pas d'absolu. Bruce Lee disait "il n'y a pas de meilleur combattant qu'un autre, seulement des combattants qui maitrisent mieux une discipline qu'une autre". Herbert Mayer lui a dit "Aucun langage de programmation n'est parfait. Il n'existe même pas un langage meilleur que d'autres ; il n'y a que des langages en adéquation ou peu conseillés pour des buts particuliers.". Et toi tu arrives "oui il faut savoir quand une chose est meilleure qu'une autre" tu te sens plus inspiré que ces deux références? Pour planter un clou, un marteau est bien meilleur qu'un tournevis. Mais pour visser... Et même pour un besoin équivalent, par exemple pour transformer de la data entrante je choisirai tantôt awk (super complet mais super lourd) ou tantôt sed (super léger mais très réduit en possibilités par rapport au premier) pourtant tous deux pouvant faire le job.

J'ajouterai que Cron ne fait strictement rien de mieux que ce que ne font déjà les timers Systemd et des cas d'utilisation j'en ai vu à la pelle sinon je t'en prie (du verbe "prier", qui est un verbe du premier groupe) donne moi un seul exemple.

Je n'ai pas d'exemple en tête. Mais le manque de preuve n'est pas la preuve d'un manque.

[tabouret]

Ah? Et d'où tu sors que c'est une erreur? Sans déconner, des types ont voulu faire un truc agissant selon une certaine logique qu'ils ont définie et toi tu arrives et tu leur dis "non non les gars, c'est pas comme ça que vous devez penser votre truc". M'étonnerait pas qu'ils te répondent d'aller te faire...

Si je remets en cause leur logique avec des arguments où est le problème? j'ai tout à fait le droit de dire que leur logique est à chier et que le rendement final est médiocre

Alors déjà ce n'est pas moi qui ai besoin de faire quoi que ce soit (je n'ai jamais dit avoir besoin moi de faire en sorte qu'une chose se lance tel jour de tel mois à condition que ce soit aussi tel jour de la semaine, c'est toi, et déjà j'ai du mal à voir le but d'un tel truc) et ce n'est pas une preuve de défaut de conception, c'est juste la preuve que tu utilises un outil dans des conditions pour lesquelles il n'a pas été conçu. Ok tu as le droit d'avoir des besoins spécifiques mais ce n'est pas la faute de l'outil si tes besoins t'obligent à rajouter les contrôles qui manquent, et même si un autre outil le permet, ce n'est pas pour cela que le premier doit être foutu au trou. Et à l'inverse si cron était codé pour lancer la tâche au jour et au mois qui correspond pile poil au jour de la semaine, je me demande bien comment tu ferais pour lui demander l'inverse, c'est à dire de lancer un truc au jour et au mois et aussi au jour de la semaine. Un "ou" (qui contient trois "uns" et un seul "zéro") peut parfaitement être réduit à un "et" (suffit de rajouter les tests manquants pour éliminer les "uns" en trop) tandis que pour transformer un "et" en "ou" (c'est à dire faire revenir l'information qui a été détruite)...

Le but d'un tel truc? Pourtant évident..Lancer une commande (de mise à jour automatique via unattended-upgrade par exemple) uniquement le 3ème lundi du mois. Et je suis désolé mais Cron aurait du être conçu pour ce cas d'utilisation. Systemd ne fait que pallier les manquements de Cron.
Faire une tâche planifiée une fois par mois tel jour, c'est normalement dans la roadmap d'un planificateur de tâche. Cron n'est pas à la hauteur, Systemd l'est. Transformer un OU en ET te demande de rajouter une commande dans ta commande finale, la lisibilité devient à chier.
Transformer un ET en OU via Systemd est un jeu d'enfant, il suffit de rajouter des directives OnCalendar.

Ah ben si, quand tu réponds "tout à fait d'accord" à la phrase de defZero disant que cron ne doit plus être utilisé. Si ça ce n'est pas "cracher dessus"...

Je ne crache pas dessus, je dis que Cron n'arrive pas à la cheville des timers Systemd.

Meilleur !!! En voilà un jugement bien absolu !!! Encore une fois tout dépend du besoin (cf mon exemple entre voiture et avion). Qu'est-ce qui est meilleur? Une pêche ou une poire? Même les plus grands dans leur discipline l'ont dit, il n'y a pas d'absolu. Bruce Lee disait "il n'y a pas de meilleur combattant qu'un autre, seulement des combattants qui maitrisent mieux une discipline qu'une autre". Herbert Mayer lui a dit "Aucun langage de programmation n'est parfait. Il n'existe même pas un langage meilleur que d'autres ; il n'y a que des langages en adéquation ou peu conseillés pour des buts particuliers.". Et toi tu arrives "oui il faut savoir quand une chose est meilleure qu'une autre" tu te sens plus inspiré que ces deux références? Pour planter un clou, un marteau est bien meilleur qu'un tournevis. Mais pour visser... Et même pour un besoin équivalent, par exemple pour transformer de la data entrante je choisirai tantôt awk (super complet mais super lourd) ou tantôt sed (super léger mais très réduit en possibilités par rapport au premier) pourtant tous deux pouvant faire le job.

Tes comparaisons sont ridicules. Comparer un avion à une voiture n'a aucun sens, pas plus que de comparer un marteau à un tournevis, ils n'ont pas le même cas d'utilisation. Les timers Systemd et Cron jouent dans la même cour.

D'autre part tu m'expliques comment tu randomises le délai de départ via Cron sans encore une fois overrider la commande pour la rendre illisible?
Tu me parles aussi d'anacron et at qui n'ont rien à voir avec cron, je te parle de tâches régulières sur serveur.
Même si les timers Systemd font aussi ce que font anacron et at.

Je n'ai pas d'exemple en tête. Mais le manque de preuve n'est pas la preuve d'un manque.

Et tu n'en auras jamais aucun.

[Sve@r]

Le but d'un tel truc? Pourtant évident..Lancer une commande (de mise à jour automatique via unattended-upgrade par exemple) uniquement le 3ème lundi du mois.

Une mise à jour de sécurité à faire tous les 3° lundi de chaque mois? Effectivement c'est évident Perso je l'aurais mise par exemple tous les lundi à 2h du matin (une date que cron sait faire et qui me semble peu impactante sur la disponibilité du système tout en offrant un bon référentiel en matière de périodicité) mais bon, je ne suis pas ingénieur en sécurité...

Et je suis désolé mais Cron aurait du être conçu pour ce cas d'utilisation. Systemd ne fait que pallier les manquements de Cron.

Aurait dû aurait dû, encore du péremptoire que rien n'étaye (rien d'autre que ton besoin perso je veux dire). Et dans ce cas tu aurais en face de toi tous ceux qui disent "oui et moi j'aimerais bien du ou".

Tes comparaisons sont ridicules. Comparer un avion à une voiture n'a aucun sens, pas plus que de comparer un marteau à un tournevis, ils n'ont pas le même cas d'utilisation. Les timers Systemd et Cron jouent dans la même cour.

Ridicules? Non, exagérées tout au plus. Je pourrais te dire qu'une voiture et un avion jouent tous deux dans la même cour des transports. Ou alors entre avion et train (justement j'ai eu à choisir récemment entre les deux et j'ai pesé les avantages et inconvénients des deux). Mais bon, n'en parlons plus. Mais que fais-tu de la comparaison entre "sed" et "awk" qui jouent tous deux dans la même cour et où le premier n'arrive clairement pas à la cheville du second et où, malgré tout, j'utilise sed chaque fois que je le peux?

Tu me parles aussi d'anacron et at qui n'ont rien à voir avec cron, je te parle de tâches régulières sur serveur.

Euh... déjà c'était juste un exemple pour dire qu'il y a d'autres outils mais anacron est un programme informatique qui permet l'exécution de tâches quotidiennes, hebdomadaires ou mensuelles sur un système Unix. Me semble que cette définition correspond assez à la notion de "tâche régulière". Et en plus, contrairement à cron, il peut même gérer le cas où la machine était éteinte au moment où la tâche était nécessaire et la rattrapper alors au redémarrage. Me semble pas mal aussi comme possibilité. Ca te manque pas ça dans cron ?

Et tu n'en auras jamais aucun.

Mouais. Tu aurais dû t'appeler "Hari Seldon"...

D'autre part tu m'expliques comment tu randomises le délai de départ via Cron sans encore une fois overrider la commande pour la rendre illisible?

Encore une fois je ne le fais pas et encore une fois si j'ai ce besoin je passerai par timer où, encore une fois, je n'ai jamais dit que je ne l'utiliserais pas. La différence entre ton discours et le mien, c'est que toi tu dis "oui tout à fait d'accord, cron doit être poubellisé" (parce que n'oublions pas que ça a quand-même été ta réponse à defZero qui dit que ça devrait faire un moment que crond ne devrait plus être sur des serveurs en prod). Tandis que moi je dis "on a plein d'outils qui s'adapteront tous peu ou prou à des situations diversifiées, c'est super profitons-en". A ton avis, quel discours est le plus correspondant aux valeurs d'ouverture et de liberté (sans pour autant négliger la sécurité) que défendent Unix et Linux ?

[tabouret]

Une mise à jour de sécurité à faire tous les 3° lundi de chaque mois? Effectivement c'est évident Perso je l'aurais mise par exemple tous les lundi à 2h du matin (une date que cron sait faire et qui me semble peu impactante sur la disponibilité du système tout en offrant un bon référentiel en matière de périodicité) mais bon, je ne suis pas ingénieur en sécurité...

Oui sauf qu'un reboot une fois par semaine (possiblement) n'est pas acceptable pour la majorité des clients. Evidemment j'ai proposé une fois par semaine, ça a été refusé. D'où le cas d'utilisation du 3ème lundi du mois.

Ridicules? Non, exagérées tout au plus. Je pourrais te dire qu'une voiture et un avion jouent tous deux dans la même cour des transports. Ou alors entre avion et train (justement j'ai eu à choisir récemment entre les deux et j'ai pesé les avantages et inconvénients des deux). Mais bon, n'en parlons plus. Mais que fais-tu de la comparaison entre "sed" et "awk" qui jouent tous deux dans la même cour et où le premier n'arrive clairement pas à la cheville du second et où, malgré tout, j'utilise sed chaque fois que je le peux?

sed est plus facile à mettre en oeuvre que awk, c'est son seul avantage. Et ne me parles pas de la facilité de cron vis à vis des timers Systemd je te vois venir^^.

Euh... déjà c'était juste un exemple pour dire qu'il y a d'autres outils mais anacron est un programme informatique qui permet l'exécution de tâches quotidiennes, hebdomadaires ou mensuelles sur un système Unix. Me semble que cette définition correspond assez à la notion de "tâche régulière". Et en plus, contrairement à cron, il peut même gérer le cas où la machine était éteinte au moment où la tâche était nécessaire et la rattrapper alors au redémarrage. Me semble pas mal aussi comme possibilité. Ca te manque pas ça dans cron ?

Ça ne me manque en tout cas pas dans les timers Systemd via la directive "Persistent"
Et non cron c'est les tâches régulières sur serveur.
Anacron, les tâches régulières sur PC.

Encore une fois je ne le fais pas et encore une fois si j'ai ce besoin je passerai par timer où, encore une fois, je n'ai jamais dit que je ne l'utiliserais pas. La différence entre ton discours et le mien, c'est que toi tu dis "oui tout à fait d'accord, cron doit être poubellisé" (parce que n'oublions pas que ça a quand-même été ta réponse à defZero qui dit que ça devrait faire un moment que crond ne devrait plus être sur des serveurs en prod). Tandis que moi je dis "on a plein d'outils qui s'adapteront tous peu ou prou à des situations diversifiées, c'est super profitons-en". A ton avis, quel discours est le plus correspondant aux valeurs d'ouverture et de liberté (sans pour autant négliger la sécurité) que défendent Unix et Linux ?

Autant j'utilise sed et awk conjointements, autant cron je ne l'utilise plus parce que les timers sont plus puissants. Mais nous n'avons pas mis cron à la poubelle (d'ailleurs peu de gens savent comment paramétrer des timers Systemd en production).

Mais tu sais c'est exactement le même débat qu'avec policykit vs sudo.
Pour ma part, inutile d'installer sudo sur un système mais qui sait vraiment utiliser polkit? d'où le fait que nous laissons aussi sudo en production.

[Sve@r]

Oui sauf qu'un reboot une fois par semaine (possiblement) n'est pas acceptable pour la majorité des clients. Evidemment j'ai proposé une fois par semaine, ça a été refusé. D'où le cas d'utilisation du 3ème lundi du mois.

Hé voilà. Le souci du besoin. Toi tu as des clients qui comptent sur une HD de tes serveurs et pas moi. D'où le fait que le choix d'un outil plutôt qu'un autre se réfléchit au cas par cas.

sed est plus facile à mettre en oeuvre que awk, c'est son seul avantage.

C'est pas ce que j'avais en tête. Je pensais plutôt à la "lourdeur" de l'un vis à vis de l'autre. Utiliser awk là où sed suffit, c'est utiliser un marteau pilon pour ouvrir une noix.

Et non cron c'est les tâches régulières sur serveur.
Anacron, les tâches régulières sur PC.

Hum... j'ai du mal à voir la différence. Ou alors tu penses au fait qu'un serveur ne s'arrête jamais rendant alors anacron inutile. Perso je te dirai que j'ai jamais utilisé anacron et si mon PC est éteint au moment où la tâche devait se lancer ben tant pis, ça attendra la prochaine fois. Mais c'est pareil, encore une fois parce que j'ai pas ce souci de HD

(d'ailleurs peu de gens savent comment paramétrer des timers Systemd en production).

Bah, ça doit s'apprendre comme le reste.

Mais tu sais c'est exactement le même débat qu'avec policykit vs sudo.
Pour ma part, inutile d'installer sudo sur un système mais qui sait vraiment utiliser polkit? d'où le fait que nous laissons aussi sudo en production.

Pareil, je ne connais même pas cet outil polkit. Mais quelque chose me dit que même le jour où je le connaitrai, je continuerai à dire "ok, maintenant je connais deux outils donc j'ai deux fois plus de choix" et non pas "oh là là polkit est bien mieux que sudo, vite oublions cette erreur de la nature "

[MPython Alaplancha]

Bonjour,
Pour ce qui est de cron et systemd, j'utilise systemd pour créer un service, cron pour demander à mon pc de préparer le café à 5h30 précise(voir juste un jour j/5h30), ou anacron pour qu'il le prépare quand il sera dispo. J'y vois trois outils différant que je choisis selon mes besoins.
Je n'administre pas de serveur, et n'ai aucune connaissance sur le sujet, mais bon il semble évident que ces outils ont chacun leurs approches spécifiques. Pour un serveur, j'imagine que l'on veut des interactions avec le système comme le permet la création de service avec systemd. Ceci dit, ça en fait pas un outil meilleur. Il est juste adapté à cette tache (par contre pour me faire le café de 5h30, c'est cron ).

[tabouret]

Pareil, je ne connais même pas cet outil polkit. Mais quelque chose me dit que même le jour où je le connaitrai, je continuerai à dire "ok, maintenant je connais deux outils donc j'ai deux fois plus de choix" et non pas "oh là là polkit est bien mieux que sudo, vite oublions cette erreur de la nature "

O rassures toi on aura ce débat la en temps voulu