Doug Le Tough a écrit 106 commentaires

des scripts python pour lancer les diffents jeux de tests et archiver ca en DB

Voilà de très bons cas d'utilisation pour Scrippy !
N'hésite pas à faire un retour ou poser des questions.

Pour plus de réactivité, tu peux me contacter via IRC (libera.chat / #tetalab)

Dans ma carrière j'ai pu rencontrer le pire comme le meilleur dans chacun des langages, du shell au C, en passant par Pyhton, Perl et Ruby et d'autres encore.

Malheureusement je ne crois pas que ce soit lié au langage en lui même.

Ce n'est même pas toujours lié à la personne ou à l'équipe et pour ma part je pense que c'est lié au cadre qu'on donne aux personnes en charge du code.

D'où Scrippy, qui n'est un cadre qui facilite pas mal d'aspect de la création, l'exploitation et la maintenance d'un script Python.

que tout vrai sysadmin préfère à python

Que tout vrai sysadmin à la retraite depuis 15 ans, préfère à Python :-p

J'utilise docopt, qui propose, à l'inverse, de construire le "boilerplate" à partir de la doc. Une démarche saine.

Très intéressant, je ne connaissais pas et ça répond en partie au même besoin que Scrippy.

baker par contre à l'air de répondre à un besoin bien différent.

Mais scrippy a l'air encore plus complet. Je testerai pour ma prochaine CLI.

N'hésite pas à revenir avec des questions si besoin, voire présenter ce que tu as fais avec.

Blague à part, personnellement je trouve ton travail très intéressant

Merci :-)

mais je n'ai jamais rencontré le script dont tu te moques à plusieurs reprises.

Tant mieux !

script_final_old_v3_OK_last.py est un nom caricatural mais assez représentatif d'un script d'exploitation développé rapidement pour répondre à un besoin ponctuel qui a été maintenu par de multiples personnes directement sur la prod.

C'est donc surtout une manière de présenter Scrippy car dans les faits rien n'empêche un script qui utilise Scrippy d'avoir un tel nom !

Si vous, car j'ai l'impression que vous êtes plusieurs, n'avez jamais rencontrés ce genre de script, soyez en heureux mais sachez qu'on les trouve dans bon nombre d'entreprises et administrations, qu'ils sont souvent en charge de processus critiques et que leur nom est le moindre de leur défaut.

Merci pour ce partage, je ne connaissais pas FinalFinal, j'ai bien ri et maintenant je doute :-D

Il est évidemment recommandé que ces scripts soient centralisés, versionnés et déployés de manière automatisée. L'un n'empêche pas l'autre, pas plus qu'un CVS et un outil de gestion de configuration n'empêchent script_final_old_v3_OK_last.py d'être déployé en prod (déjà vu).

L'idée est d'apporter plusieurs choses et pour lister les princpales:

• Un cadre aux scripts d'exploitation, de manière à gagner en temps de développement et de maintenance (gestion déclarative des paramètres de configuration, des options, configuration du logger, etc.). Cette étape représente généralement la plus grande partie du développement d'un script d'exploitation, alors que c'est peu ou prou toujours la même chose (i.e. valider la configuration du script, jouer avec les arcanes d'argparse pour gérer les options, configurer un logger, gérer les informations sensibles dans les sorties).

• Un historique d'exécution des scripts qui indique l'heure de début, l'heure de fin, la durée d'exécution, l'utilisateur qui a exécuté le script, si le script a été exécuté via sudo (et, le cas échéant, qui a exécuté le sudo), le code retour du script, et, si le script s'est terminé sur une erreur, quelle a été cette erreur, etc. Et je parle d'un historique configurable : par défaut, tu peux consulter les 50 dernières exécutions, mais tu peux décider de conserver les 200 dernières. Le genre de truc qui permet de vérifier rapidement pourquoi le script mon_script.py a planté il y a 15 jours sans que personne ne s'en aperçoive.

• Des logs standardisés, la possibilité de gérer les exécutions parallèles, d'éviter la fuite d'informations sensibles dans les logs, etc., mais également de consulter les logs des dernières exécutions. Parce que lorsque le script critique, exécuté par un ordonnanceur toutes les 5 minutes, a planté un dimanche à 3 heures du matin, tu veux savoir pourquoi, même s'il t'a fallu 30 minutes pour te réveiller. Et dans ces moments-là, tu ne veux pas avoir à réfléchir (où est le log ? Comment y accéder ? Comment identifier le bon log parmi les gazillions de logs conservés ?). Avec Scrippy, c'est simplement mon_script.py --hist pour visualiser l'historique d'exécution et identifier l'exécution qui a planté, puis mon_script.py --log <SESSION_ID> pour visualiser le log qui contient la raison du plantage.

• Bien d'autres choses choses que je vous laisse découvrir grâce au tutoriel :-)

Évidemment, Scrippy n'est pas magique. Comme indiqué dans la dépêche à propos de l'IA, le meilleur outil donné à un mauvais ouvrier n'en fera pas un bon ouvrier.

bash <(curl -fsSL https://raw.githubusercontent.com/woofix/visio_display/main/server-install.sh)

Il serait temps d'arrêter de diffuser cette très mauvaise pratique.
En fait, il aurait été mieux de ne pas commencer.

J'ai simplement besoin d'un client qui récupère des flux et affiche les articles à l'écran.

Thunderbird fera ça très bien.

Le lecteur de flux RSS est intégré à Thunderbird qui, me semble t-il, est géré par Mozilla.

Et donc on a le droit de tomber dans la diffamation publique…

Ce n'est pas très joli !

Même si je suis favorable à l’utilisation du français dans le langage technique, je pense qu’on peut trouver une meilleure traduction de « mediated devices » que « dispositifs médiés », qui semble être une traduction littérale peu claire qui n'aide pas à la compréhension.

« Périphérique virtualisé partagé », par exemple, est certes plus long, mais il a le mérite d’être plus clair. D'autres formulations sont possibles et probablement plus adéquates.

Mais quand tu te mets au volant d'une voiture la première fois, tu procèdes à quelques réglages : distance du siège et rétroviseurs. Ben pour un logiciel c'est souvent pareil. Tu fais l'outil à ta main

Oui, avec les commandes "ergonomiques et inuitives" fournies par le constructeur.

Je ne suis pas obligé de fouiller un mode d'emploi de 400 pages pour finalement m'apercevoir qu'il faudra que je commence par fabriquer moi même le comodo de réglages du rétroviseur ou installer un obscur greffon téléchargé au hasard sur Github pour arriver à mes fins.

Merci pour le point Jacky©.

Chic, une liste (cTMr) !

Not enough space left on device: You wouldn't want to boil all the water on Earth for such a task

Merci, je gère des infrastructures de plusieurs centaines de VM et différents orchestrateurs de conteneurs. Je pense savoir de quoi je parle et dans ce contexte professionel je n'ai pas de problème avec systemd.

Cependant cela ne m'empêche pas de rester objectif.

systemd n'a jamais apporté le moindre bénéfice aux nombreux cas d'usages que j'ai pu rencontré et s'il ne m'a jamais posé de problème, je ne peux pas en dire autant d'un grand nombre d'admins que j'ai croisés qui luttent régulièrement pour différentes raisons.

Vouloir une solution unique à tous les cas possibles y compris ceux qui n'existent pas encore ne peut que conduire à une solution insatisfaisante dans la plupart des cas et à une solution d'une complexité inutile à tous les cas traités (exception, configuration inutile dans tel contexte, etc).

Un frigo qui fait grille pain, c'est à la fois un mauvais frigo et un mauvais grille-pain. Même si le module grille-pain est démontable et optionnel. Et un poste de travail ou une VM qui fait du BGP… Soyons sérieux.

Ce que je note, c'est que les personnes qui ont répondu à mon commentaire sont restées accrochées aux exemples que j'ai choisis mais personne n'a discuté le fond qui était, entre autre, la gestion du changement liée aux breaking changes réguliers, aux bugs en pagaille, la taille de la surface d'attaque de systemd, l'incompatibilité avec les autres Unixes qui obligent les mainteneurs de FreeBSD, NetBSD et OpenBSD à s'arracher les cheveux pour intégrer certains logiciels.

De mon point de vue, ce ne sont pas vraiment des sujets qu'on peut glisser sous le tapis.

Sans compter qu'aujourd'hui les principaux contributeurs à systemd sont IBM (via Red Hat) et Microsoft. Deux entreprises des plus louables, connues pour la qualité et la sécurité de leurs produits ainsi que leur amour du logiciel libre (surtout lorsqu'il est possible de s'accaparer le travail d'une communauté pour quelques cacahuètes). #MicrosoftLovesLinux (franchement vous y avez cru ?).

systemd a été poussé de force au fond de la gorge des utilisateurs, la preuve en est que 14 ans (quatorze ans !) après il reste encore une opposition forte à ce projet.

systemd a été adopté par les utilisateurs uniquement parce qu'ils n'ont pas eu le choix. Typiquement lorsque Debian est passé à systemd. Lorsque systemd n'était disponible que sur Red Hat et ses dérivés, on n'a pas vu des masses d'utilisateurs se ruer sur CentOS et consorts. C'était plutôt le contraire.

Quand on est en connexions multiples, par exemple en 4G + Ethernet, on peut avoir des résolveurs différents en fonction de l'opérateur, et plusieurs clients DHCP qui vont réécrire le resolv.conf. Idem pour networkmanager, il se met à gérer le fichier. > Et resolvconf, géré par resolvconf.conf… Si en plus tu as un client VPN, il peut aussi écraser ta conf, qui va se refaire modifier par networkmanager, etc… Tout ceci créé des conflits sur la propriété du fichier.

Sur un serveur qui dispose d'une IP statique ?

Soyons honnêtes, Linux #1 sur le desktop aura lieu après la mort d'Usenet et aujourd'hui l'usage de Linux est essentiellement sur les serveurs.

Je comprends bien l'usage sur un ordinateur portable mais de là à généraliser au point de l'imposer aux autres usages qui sont nettement plus fréquents, il y a un pas que je voudrais qu'on ne m'oblige pas à franchir.

C'est bien enterieur à systemd. Si tu veux utiliser du dhcp, il va bien falloir que > ton client dhcp applique la configuration qu'il reçoit. Que tu gère ce changement
avec le composant de systemd, avec network manager, via wpa suplicant ou un script
que tu as as écrit toi, si tu veux pouvoir appliquer la configuration dhcp tu te
retrouve à écraser ce fichier

Le problème existe même sans DHCP activé et le problème ne concerne pas que /etc/resolv.conf.

Les composants de systemd, à quelques exceptions près, peuvent se limiter au boot et
au lancement de services. Tu peux garder /etc/fstab, le /etc/network/interfaces ou
netplan ou networkmanager, ton client DHCP, un resolv.conf manuel, un /etc/hosts,
ton client ntp, syslog, cron, etc…

Sauf que dans la réalité la plupart des utilisateurs sont piégés par les choix faits par les mainteneurs de leurs distributions préférées.

Ex. Debian a remplacé rsyslog par journald. Certes on peut toujours installer rsyslog mais c'est une étape de plus, de la conf en plus et il faudra serrer les fesses à la prochaines mise à jour.

Et rien n'est plus déconcertant que de voir en commentaire en haut d'un fichier de conf aussi simple que /etc/resolv.conf ou autre, une ligne du style "ce fichier n'est plus géré directement par tel programme, veuillez d'abord vous fader la doc absconse de tel sous-composant à systemd qui vous renverra sur Internet alors que vous n'avez pas d'accès réseau et que vous êtes dans une situation d'urgence sur une machine de production". Je caricature à peine mais c'est du déjà vu.

Donc, oui systemd est modulaire, non, il n'est pas si simple d'outrepasser les choix faits par les mainteneurs et non ces choix ne sont pas toujours judicieux et surtout les utilisateurs n'y sont pas toujours préparés. Il n'y a qu'à voir la longueur de cette dépèche pour ce rendre compte du travail que devra représenter l'analyse du changelog ainsi que la formation des équipes avant une intégration en environnement de production.

À titre pro j'utilise beaucoup Debian et les dérivés de RedHat sans soucis mais pour rien au monde je n'en voudrais sur mes machines perso qui roulent Slackware sans sourciller depuis… bientôt 25 ans !

Le symbole "a" est une lettre de l'alphabet latin. Sans contexte spécifique, il peut représenter différentes choses en fonction du domaine ou du contexte dans lequel il est utilisé. Voici quelques exemples de ce que "a" pourrait représenter :

En mathématiques :
"a" peut être une variable utilisée pour représenter un nombre réel, un coefficient, ou une inconnue dans une équation.
Dans la notation d'intervalle, "[a, b]" peut représenter un intervalle fermé où "a" est la borne inférieure et "b" est la borne supérieure.
En physique :
"a" peut représenter une accélération, une vitesse, ou une aire, selon le contexte.

En informatique :
"a" peut être utilisé comme une variable ou un symbole dans la programmation pour stocker des données ou effectuer des opérations.
En linguistique :
"a" peut être une lettre dans un alphabet utilisé pour écrire une langue spécifique.

En musique :
"A" peut représenter une note musicale, la note la plus basse du système de notation en lettres.
En statistiques :
"a" peut être un paramètre ou une constante dans des équations statistiques.

Dans un contexte linguistique plus général, "a" peut être simplement une lettre dans un mot ou une phrase, sans signification particulière jusqu'à ce qu'elle soit combinée avec d'autres lettres pour former des mots.
Le sens de "a" dépend donc du contexte dans lequel il est utilisé, et il peut avoir de nombreuses interprétations différentes en fonction de ce contexte.

Mon commentaire n'apporte rien mais il faut bien quelqu'un pour contrebalancer l'intérêt porté à Alma Linux.

Pour ma part j'ai opté pour Rocky pour les VM de mon lab comme pour celle de ma prod et je ne vois pas de raisons pour passer à Alma.

Les quelques jours/semaines de d'écart pour une release ou un patch me semble totalement sans importance puisque comme beaucoup je n'applique les mise à jour que quand j'ai le temps de tester que la mise à jour n'apporte pas plus d'ennui qu'elle n'en corrige.

Rocky Rocks !

| curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash

"Piper" un shell directement depuis curl vers sudo ?

Ça ne semble pas une démarche très sécurisante.
C'est même tout à fait effrayant !

Pas aussi "mains dans le cambouis qu'une LFS", mais bien plus qu'une Gentoo dès qu'on sort des quelques centaines de paquets fournis avec la distribution serait plus proche de la vérité.

Cela fait 20 ans que je roule du Linux, j'ai du essayer toutes les grandes distrib' de Debian à RHEL en passant par LFS et bien entendu Gentoo. Aucune distribution ne donne autant de liberté que Slackware. Rien ni personne ne m'oblige a utiliser utiliser tel ou tel système d'initialisation. Rien ni personne ne m'empêche non plus de le faire. Je choisis !

Slackware c'est avant tout un état d'esprit, bien plus proche du véritable esprit DIY que la plupart des grandes distributions, y compris Debian.

Avec Slackware il ne s'agit pas de simplement installer une distribution en suivant un tutoriel et croire qu'on maitrise parce qu'on sait faire un apt-get.

Non, Il faut la peaufiner, la "fine tuner" à son goût dans les détails, lui recompiler le noyau aux petits oignons, supprimer les dépendances qui vous sont inutiles, écrire ses propres scripts pour compiler en masse les paquets supplémentaires dont vous aurez besoin et faire la chasse au dépendances…

Alors, oui, elle sort que quand elle est prête et non vous ne pourrez pas participer à son développement (et c'est tant mieux).
Oui vous pouvez contribuer en proposant des Slackbuilds sur slackbuilds.org.
Non elle ne gère pas les dépendances entre paquets pour vous,
Oui l'installeur n'est qu'en mode TUI.

Mais quoi qu'il en soit, vous apprendrez à vous sortir de toutes les situations que vous pourrez rencontrer avec n'importe quel Linux.

Tu t'es fait la main sur une Debian, une Fedora ou une Arch ? Tu crois connaître Linux ? Prouve le en passant un niveau de plus et viens goûter Slackware…

L'outil semble intéressant mais il mériterait d'être "database agnostique" ou tout au moins de supporter d'autres types de base (typiquement et a minima, Postgres).

Le couplage avec MySQL me semble clairement un frein à l'adoption,y compris si le logiciel est fourni sous forme d'image Docker.

Mes deux centimes.

ni renoncer au fait que je sois valide.

Ça, ça peut s'arranger !

Hormis circonstances exceptionnelles, il est peu probable que ce soit par un acte volontaire ;-)

C'est un privilège que n'ont pas les non-blancs

Ce qui serait bien c'est de ne pas confondre privilège et chance.

Oui les personnes non-stygmatisées ont de la chance. Non ce n'est pas un privilège.

Je peux renoncer à un privilège. Je peux ni renoncer à la couleur de ma peau, ni renoncer à mon genre, ni renoncer à mon orientation sexuelle, ni renoncer au fait que je sois valide.

Je suis toujours choqué de voir trop souvent le mot privilège utilisé pour reprocher à un groupe de personnes un fait qu'ils n'ont pas choisis et auquel ils ne peuvent renoncer.

Pour autant mon indignation n'est unique, je suis également indigné de voir des individus discriminés, qu'elle qu'en soit la raison.

Ce n'est pas parce qu'un combat est légitime qu'on doit en accepter tous les travers, dérives et biais.

Utiliser le mot privilège à mauvais escient ne rend pas service au combat égalitariste.