Pour celui qui n'a pas compris : quelqu'un qui vient poser un problème aussi vieux sans apporter d'arguments nouveau et qui alimente le débat stérile c'est la définition d'un troll. D'autres exemples possibles :
la même chose qu'ici mais pour RHEL
expliquer qu'Arch n'est pas stable quand on en parle
affirmer que Slackware est désuet
s'offusquer du graveleux du projet weboob
mettre une nimage à la fin de ses journaux
…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Et le plus petit dénominateur c’est Debian stable.
Il y a des RHEL toujours maintenues largement plus vielle.
Mais C++17 à changer d'ABI ? Je pensais que ces langages sans runtime avait justement pas ce genre de problème (modulo la disponibilité des bibliothèques dynamiques que tu utilise).
Après on le dit à chaque fois Debian Stable est fait pour les serveurs. C'est prévu pour être véritablement stable au détriment des mises à jour (hors sécurité). Un serveur est géré par admin qui lui saura sans difficulté installer une application dans un environnement précis.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Tu fais de la rhétorique (d'autres ici aussi). Backup, sauvegarde, bon/mauvais,…
Je me fous de savoir le nom qu'il faut donner aux choses, ça n'est pas très intéressant. Ce qu'il faut savoir c'est quelle sécurité, tu as pour tes données. Pour cela il faut que tu évalue d'une part les risques et d'autre part l'importance de tes données.
Ta copie locale te donne une sécurité très faible. Elle protège des erreurs de manipulation, mais d'aucun problème technique (fs corrompu, disque qui meurt,…), d'aucun problème extérieur (vol du matériel) ni d'aucune attaque (ransomeware).
Si tu es le seul à pouvoir évaluer l'importance de tes données, ce que je vois généralement c'est une grosse différence de comportement entre ceux qui ont confiance en leur disque (souvent ils n'ont jamais eu de problème avec) et ceux qui ne leur font pas confiance (généralement ils t'expliquent comment ils ont déjà perdu des données).
Bref l'importance c'est de comprendre ce que protège ta méthode et d'évaluer la réalité des risques (est-ce que tu risque le vol ? est-ce que ton disque va mourir ?…).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
J'avais l'idée de déterminer des niveaux de troll à partir de la forme des commentaires. Sans même en étudier le contenu, en prenant comme paramètres :
le nombre de commentaire
la profondeur de l'arbre
la fréquence des commentaires
la variance pertinent/inutile
On doit pouvoir faire un détecteur de troll. Aujourd'hui l'image informant que tu es entrain de répondre à un troll vient d'une heuristique uniquement basée sur la profondeur (alors que des fois ça n'est pas du tout du troll).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
C'est marrant parce que c'est typiquement un cas où utiliser un message broker (AMQP, MQTT, Redis au pire) est hyper pertinent. Ils ne s'y sont pas mis ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
et ceux des disque wt non pas ce fameux -A, question au fabricant du SSD puis sa réponse qui est pas mal je trouve :
oui c'est normal, nous testons les puces standard nous même et si elle ne passe pas le test wt nous les écartons, pas besoin de prendre la bonne réf du fabricant de puce.
Particulièrement quand on sait que ce genre de qualification est faite par le fabriquant. Ce qui distingue une puce « -A » de la même sans, c'est que la seconde a échouée aux tests de température.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Choisir une distrib' pour son gestionnaire de fenêtre lorsque l'on a besoin de temps réel ça surprend tout de même :)
Tu as des distributions qui sont là pour faire du temps réel avec un noyau compilé pour, les paquets compilés pour quand c'est nécessaires et s'ajouter, etc. Partir sur ce genre de truc ou, pour les plus poilus, sur une distribution source et compiler les logiciels comme on le souhaite, me paraît amplement plus pertinent.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
n'oublions pas les robots et autres spiders qui viennent apporter une plus-value démesurée à la distribution du contenu
Quelle plus-value ? Le référencement ? Le HTML est fait pour présenter le contenu pour des humains (handicapés ou pas). C’est au concepteur du robot de s’adapter au format, pas au concepteur du site de s’en faire une contrainte.
C'est pourtant ce que portent les microfotmats.
Le développement JavaScript pour l'accessibilité, doit ainsi se comprendre dans le respect des standards, par l'agglomération de codes réutilisables, API ou briques de développement, mais de façon systématiquement détachée du contenu auquel il s'applique, pour qu'il ne devienne pas un carcan dont on serait fier.
À la lecture de tous tes commentaires et en particulier celui-là, j’ai l’impression que tu confonds contenu « documentaire », c’est à dire statique (ou à peine dynamique, jore un peu de JS pour trier les tableaux ou autre truc simple dans le genre) et contenu « applicatif », c’est à dire fortement dynamique, où le contenu envoyé par le serveur dépend fortement du contenu (formulaires typiquement) envoyé par le client.
Le code JS est exécuté par le client (on peut faire du code serveur en JS aussi mais je mettons ça de côté pour l’instant), donc visible de celui-ci, donc modifiable par celui-ci !
Le code serveur, lui, est au contraire connu seulement du « maître d’œuvre » comme tu dis… Même si ce code est libre et donc disponible pour tout un chacun, du point de vu du client on peut s’attendre à ce que n’importe quoi tourne…
Je suis pas certain de ce que vous voulais dire, mais vous êtes entrain de discuter de choses sans les formaliser : vous avez un paquet d'architectures qui sont là pour décrire des façon d'organiser tout cela (MVC, MVVM, MVP, PAC, Flux,…). Penser qu'il y a une bonne façon de faire et que c'est quelque chose de dépendant du langage me surprend. Ils ont tous des avantages et des inconvénients et (mise à par PAC) sont tous activement utilisé aujourd'hui.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Je me suis récemment mis aux timers systemd pour remplacer cron et j'en suis super content. La principale raison c'est d'avoir la commande systemctl list-timers qui m'indique l'heure du dernier et du prochain lancement de chaque tâches.
Ça n'est pas parfaitement équivalent (si tu n'est pas administrateur de la machine, tu ne pourra pas t'en servir), mais pour moi ça rempli totalement son rôle.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Mais s'agit d'il d'une véritable garantie ou est-ce que c'est une vérification opportuniste ?
Que fait il s'il y est impossible de déterminer la valeur du décalage à la compilation ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Donc au lieu d'un seul script, j'aurais plus de 50 petits fichiers…
C'est quoi cet intérêt pour n'avoir qu'un seul fichier ? Il n'y a aucune raison de n'avoir qu'un seul fichier. Je ne dis pas que ce n'est pas grave d'avoir plusieurs fichiers, je dis que c'est bénéfiques. Il n'y a pas l'ombre d'un problème à utiliser une arborescence de fichiers.
Je peux alors lancer ./postinstall.sh vim pour exécuter ces 7 actions. Je ne connais pas de manière, avec Ansible, pour appeler 7 plays en une seule commande aussi simple, sauf à faire un playbook pour chaque programme, puis utiliser les rôles, etc etc.
Ça n'est pas comme ça que fonctionne ansible (et les logiciels du genre). Dans ansible tu défini des rôles qui peuvent avoir des fichiers, des templates, un playbook, des variables,… et tu va agréger et paramétrer ces rôles pour chaque cible ou groupe de machines. Donc tu aura un rôle vim que tu applique à ta machine. Comme tout est idempotent, tu ne devrais pas lancer ansible par rôle mais par machine, si tu fais une modification tu ré-applique tout. Les tags peuvent servir, mais je ne les utilise pas pour ça.
Tu utilises le pluriel, là c'est déjà mal parti pour qu'on se comprenne.
On à tous pleins de machines. Celle(s) de chez toi, celle du travail,…
Ensuite je le lance occasionnellement (et partiellement, comme dans l'exemple de vim ci-dessus) pour rétablir des conf que j'ai un peu trop tripatouillées à la main.
C'est là où l'idempotence d'ansible prend tout son sens. Tu ne te pose pas la question tu peux tout relancer continuellement.
Et vu que je ne me rappellerais jamais de cette commande en entier, utilisée une fois tous les 6 mois sur une machine vierge, il faudrait la mettre dans un script :)
C'est de la mauvaise fois… Tu ne peux pas te coller un README.md à la racine de ton dépôt git ?
Comme tu le dis, chacun fait comme il veut. Pour ma part et pour cet usage, je ne vois pas d'intérêt à utiliser Ansible : un script shell est bien plus flexible et facile à utiliser in fine pour cet usage à mon sens.
Je sais parfaitement écrire des scripts shells/bash/zsh, mais justement parce que je sais ce qu'il en retourne la piètre qualité des scripts généralement (mauvaise gestion des inputs par exemple) et, même en zsh, la quantité de code que ça prends de faire les choses bien, je préférerais toujours partir sur une solution, qui ne me fais pas réinventer là roue (fabric par exemple peut faire l'affaire pour ça, mais il n'est pas idempotent).
Regarde tes confs fichiers tout statiques : Les écrire en jinja (c'est le moteur de templates d'ansible) te permet de les rendre plus courts.
L'utilisation d'outils de plus haut niveau te retire le plaisir d'utiliser ce que tu connais parfaitement et te sors de ta zone de confort, mais :
te permet d'avoir une configuration descriptive de ta machine
te permet d'appliquer ta configuration sur toutes les machines auxquels tu as accès
te donne accès à des action de plus haut niveau
te donne de l'idempotence en standard
te pousse aux bonnes pratiques
Le tout pour un coût faible ;) (ne me dis pas que cloner un dépôt, trouver une commande ou le wrapper dans un script, etc sont hors de ta portée)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Par ailleurs, je ne vois pas du tout comment, avec Ansible et en un seul fichier, je peux demander de déployer "tout ce qui concerne vim" (c'est à dire installer vim, vim-gnome, puis copier mon ancienne conf, puis mettre gvim comme éditeur par défaut par le biais de xdg-mime).
Tes fichiers sont bien quelque part il peut aller les chercher en https, ftp, git,… C'est des documents en ligne ? Ansible sait faire aussi. Tu as des choses à modifier dedans ? Tu fais un template.
Mais voyons le autrement. Tu as tes machines qui sont bien installé et finalement, tu veux changer quelque chose :
tu refais une installation fraîche ?
ton script passe à peu près sur lui même sans trop de problème ?
tu as une vrai gestion de l’idempotence ce qui te permet de jouer autant de fois que tu veux ton script sans avoir à croiser les doigts ?
Ansible est plus compliqué à installer c'est un fait, mais :
n'est probablement pas un frein à quelqu'un qui maîtrise le shell tel que toi. Tu utilise du coup git pour versionner et mettre à jour ton ensemble autant que tu le souhaite, tu peux découper tes fichiers autant que tu veux pour les gérer comme tu sens ça ne changera pas ton déploiement, tu accède à des options de haut niveau (les templates, la gestion des comptes utilisateurs, etc). Tu peux aussi spécialisé ton environnement en fonction de la machine et te servir des même scripts pour ta machine de bureau, ton dédié OVH et ton rPi (sauf que tu aura vim-gnome, sur certain et vim-nox sur d'autres, même le même .vimrc). Tu ne peux pas avoir d'injection dans ansible.
Bref tu fais bien ce que tu veux (moi même j'utilise dpkg pour le moment), mais ansible t'offre beaucoup de choses en plus pour une marche qui n'est pas bien plus grande.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
C'est bien moins critique que le management. Andin le n'a rien de devops. C'est un outil d'administration système. Donc oui c'est un outil qui peut servir en devops au même titre que ssh. Ce n'est pas un sacrum boyard qui rend une équipe agile.
Je fais la remarque parce que c'est important amha de voir que ce n'est pas une question d'outils, mais d'organisation.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
AUR est bien un dépôt (Arch User Repository ça veut bien dire ce que ça veut dire). Certes non-officiel mais s'en priver, c'est se priver d'une grosse partie de l'intérêt de Arch. C'est tout de même 43139 paquets supplémentaires.
Je ne connais pas, mais j'ai souvent lu des gens expliquer qu'il ne fallait pas se plaindre d'avoir des problèmes s'ils utilisent AUR ou que les paquets sont à l'abandon.
103 434 paquets dans les repos officiels de Debian Sid.
Ce sont des paquets que l'on sait à jour et qui respectent toutes les règles de qualité Debian (il y a une liste de paquets en souffrance, mais justement pour les retirer si personne ne s'en occupe (pour info il y en a environ 1 100 actuellement https://www.debian.org/devel/wnpp/index.fr.html)).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Vivement la suivante
Posté par barmic . En réponse à la dépêche Debian 9 : Stretch déploie ses tentacules. Évalué à 10.
Une petite trentaine de commentaires… Ça doit être violent quand tu t'intéresse à quelque chose :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Très mauvaise version ESR
Posté par barmic . En réponse à la dépêche Printemps 2017 de Mozilla : Firefox 52 à 54 et Thunderbird 52. Évalué à 1.
Pourquoi est-ce qu'ils font un navigateur du coup ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Vivement la suivante
Posté par barmic . En réponse à la dépêche Debian 9 : Stretch déploie ses tentacules. Évalué à 3.
Pour celui qui n'a pas compris : quelqu'un qui vient poser un problème aussi vieux sans apporter d'arguments nouveau et qui alimente le débat stérile c'est la définition d'un troll. D'autres exemples possibles :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Vivement la suivante
Posté par barmic . En réponse à la dépêche Debian 9 : Stretch déploie ses tentacules. Évalué à 2.
Joli troll ;)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Vivement la suivante
Posté par barmic . En réponse à la dépêche Debian 9 : Stretch déploie ses tentacules. Évalué à 9.
Il y a des RHEL toujours maintenues largement plus vielle.
Mais C++17 à changer d'ABI ? Je pensais que ces langages sans runtime avait justement pas ce genre de problème (modulo la disponibilité des bibliothèques dynamiques que tu utilise).
Après on le dit à chaque fois Debian Stable est fait pour les serveurs. C'est prévu pour être véritablement stable au détriment des mises à jour (hors sécurité). Un serveur est géré par admin qui lui saura sans difficulté installer une application dans un environnement précis.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Rhétorique
Posté par barmic . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 7.
Tu fais de la rhétorique (d'autres ici aussi). Backup, sauvegarde, bon/mauvais,…
Je me fous de savoir le nom qu'il faut donner aux choses, ça n'est pas très intéressant. Ce qu'il faut savoir c'est quelle sécurité, tu as pour tes données. Pour cela il faut que tu évalue d'une part les risques et d'autre part l'importance de tes données.
Ta copie locale te donne une sécurité très faible. Elle protège des erreurs de manipulation, mais d'aucun problème technique (fs corrompu, disque qui meurt,…), d'aucun problème extérieur (vol du matériel) ni d'aucune attaque (ransomeware).
Si tu es le seul à pouvoir évaluer l'importance de tes données, ce que je vois généralement c'est une grosse différence de comportement entre ceux qui ont confiance en leur disque (souvent ils n'ont jamais eu de problème avec) et ceux qui ne leur font pas confiance (généralement ils t'expliquent comment ils ont déjà perdu des données).
Bref l'importance c'est de comprendre ce que protège ta méthode et d'évaluer la réalité des risques (est-ce que tu risque le vol ? est-ce que ton disque va mourir ?…).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Super !
Posté par barmic . En réponse à la dépêche Prédire la note d’un journal sur LinuxFr.org. Évalué à 3. Dernière modification le 09 juin 2017 à 17:53.
Hé ! J'ai perdu mon avatar !
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Super !
Posté par barmic . En réponse à la dépêche Prédire la note d’un journal sur LinuxFr.org. Évalué à 5.
Bravo !
J'avais l'idée de déterminer des niveaux de troll à partir de la forme des commentaires. Sans même en étudier le contenu, en prenant comme paramètres :
On doit pouvoir faire un détecteur de troll. Aujourd'hui l'image informant que tu es entrain de répondre à un troll vient d'une heuristique uniquement basée sur la profondeur (alors que des fois ça n'est pas du tout du troll).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: pourquoi ne pas faire conviance au daemon ?
Posté par barmic . En réponse au journal Puppet [2] : run puppet et cron. Évalué à 3.
C'est marrant parce que c'est typiquement un cas où utiliser un message broker (AMQP, MQTT, Redis au pire) est hyper pertinent. Ils ne s'y sont pas mis ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: une expérience
Posté par barmic . En réponse au journal Endurance des SSD. Évalué à 5.
Particulièrement quand on sait que ce genre de qualification est faite par le fabriquant. Ce qui distingue une puce « -A » de la même sans, c'est que la seconde a échouée aux tests de température.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Peut-être en est-il [MVC] qui fournissent d'excellentes recettes de spaghettis
Posté par barmic . En réponse au journal #spaghettis xhtml standard, sauce javascript. Évalué à 3.
Tu pose des hypothèses sans les démontrer et c'est là dessus que tu t'appuie (mais ton interlocuteur fais pareil, hein ?).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ah non ! ça suffit !
Posté par barmic . En réponse à la dépêche Sortie de Devuan Jessie 1.0. Évalué à 8.
Choisir une distrib' pour son gestionnaire de fenêtre lorsque l'on a besoin de temps réel ça surprend tout de même :)
Tu as des distributions qui sont là pour faire du temps réel avec un noyau compilé pour, les paquets compilés pour quand c'est nécessaires et s'ajouter, etc. Partir sur ce genre de truc ou, pour les plus poilus, sur une distribution source et compiler les logiciels comme on le souhaite, me paraît amplement plus pertinent.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: KISS : faire simple, faire accessible
Posté par barmic . En réponse au journal #spaghettis xhtml standard, sauce javascript. Évalué à 5.
Il y a près de 40 ans de recherche sur le sujet, tu devrais t'y intéresser avant de poser tes propres axiomes dont on ne sait pas d'où ils viennent.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: KISS : faire simple, faire accessible
Posté par barmic . En réponse au journal #spaghettis xhtml standard, sauce javascript. Évalué à 3.
C'est pourtant ce que portent les microfotmats.
Je suis pas certain de ce que vous voulais dire, mais vous êtes entrain de discuter de choses sans les formaliser : vous avez un paquet d'architectures qui sont là pour décrire des façon d'organiser tout cela (MVC, MVVM, MVP, PAC, Flux,…). Penser qu'il y a une bonne façon de faire et que c'est quelque chose de dépendant du langage me surprend. Ils ont tous des avantages et des inconvénients et (mise à par PAC) sont tous activement utilisé aujourd'hui.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Algorithme de Shor
Posté par barmic . En réponse au journal [Quantique] La ligne des 49 qubits. Évalué à 8.
Je crois que c'est la fiabilité qui est super aléatoire
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Cron ou timer
Posté par barmic . En réponse au journal Puppet [2] : run puppet et cron. Évalué à 4.
Je me suis récemment mis aux timers systemd pour remplacer cron et j'en suis super content. La principale raison c'est d'avoir la commande
systemctl list-timersqui m'indique l'heure du dernier et du prochain lancement de chaque tâches.Ça n'est pas parfaitement équivalent (si tu n'est pas administrateur de la machine, tu ne pourra pas t'en servir), mais pour moi ça rempli totalement son rôle.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Explications
Posté par barmic . En réponse au journal Puppet [2] : run puppet et cron. Évalué à 3.
Je ne comprends pas très bien. Que fais :
C'est un cron géré au sein de puppet ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rust
Posté par barmic . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 3.
Mais s'agit d'il d'une véritable garantie ou est-ce que c'est une vérification opportuniste ?
Que fait il s'il y est impossible de déterminer la valeur du décalage à la compilation ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Devops
Posté par barmic . En réponse au journal Kickstart et Ansible pour automatiser des installations/configurations de systèmes Linux. Évalué à 3.
C'est quoi cet intérêt pour n'avoir qu'un seul fichier ? Il n'y a aucune raison de n'avoir qu'un seul fichier. Je ne dis pas que ce n'est pas grave d'avoir plusieurs fichiers, je dis que c'est bénéfiques. Il n'y a pas l'ombre d'un problème à utiliser une arborescence de fichiers.
Ça n'est pas comme ça que fonctionne ansible (et les logiciels du genre). Dans ansible tu défini des rôles qui peuvent avoir des fichiers, des templates, un playbook, des variables,… et tu va agréger et paramétrer ces rôles pour chaque cible ou groupe de machines. Donc tu aura un rôle vim que tu applique à ta machine. Comme tout est idempotent, tu ne devrais pas lancer ansible par rôle mais par machine, si tu fais une modification tu ré-applique tout. Les tags peuvent servir, mais je ne les utilise pas pour ça.
On à tous pleins de machines. Celle(s) de chez toi, celle du travail,…
C'est là où l'idempotence d'ansible prend tout son sens. Tu ne te pose pas la question tu peux tout relancer continuellement.
C'est de la mauvaise fois… Tu ne peux pas te coller un README.md à la racine de ton dépôt git ?
Je sais parfaitement écrire des scripts shells/bash/zsh, mais justement parce que je sais ce qu'il en retourne la piètre qualité des scripts généralement (mauvaise gestion des inputs par exemple) et, même en zsh, la quantité de code que ça prends de faire les choses bien, je préférerais toujours partir sur une solution, qui ne me fais pas réinventer là roue (fabric par exemple peut faire l'affaire pour ça, mais il n'est pas idempotent).
Regarde tes confs fichiers tout statiques : Les écrire en jinja (c'est le moteur de templates d'ansible) te permet de les rendre plus courts.
L'utilisation d'outils de plus haut niveau te retire le plaisir d'utiliser ce que tu connais parfaitement et te sors de ta zone de confort, mais :
Le tout pour un coût faible ;) (ne me dis pas que cloner un dépôt, trouver une commande ou le wrapper dans un script, etc sont hors de ta portée)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Devops
Posté par barmic . En réponse au journal Kickstart et Ansible pour automatiser des installations/configurations de systèmes Linux. Évalué à 3.
ou :
Tes fichiers sont bien quelque part il peut aller les chercher en https, ftp, git,… C'est des documents en ligne ? Ansible sait faire aussi. Tu as des choses à modifier dedans ? Tu fais un template.
Mais voyons le autrement. Tu as tes machines qui sont bien installé et finalement, tu veux changer quelque chose :
Ansible est plus compliqué à installer c'est un fait, mais :
n'est probablement pas un frein à quelqu'un qui maîtrise le shell tel que toi. Tu utilise du coup git pour versionner et mettre à jour ton ensemble autant que tu le souhaite, tu peux découper tes fichiers autant que tu veux pour les gérer comme tu sens ça ne changera pas ton déploiement, tu accède à des options de haut niveau (les templates, la gestion des comptes utilisateurs, etc). Tu peux aussi spécialisé ton environnement en fonction de la machine et te servir des même scripts pour ta machine de bureau, ton dédié OVH et ton rPi (sauf que tu aura vim-gnome, sur certain et vim-nox sur d'autres, même le même
.vimrc). Tu ne peux pas avoir d'injection dans ansible.Bref tu fais bien ce que tu veux (moi même j'utilise dpkg pour le moment), mais ansible t'offre beaucoup de choses en plus pour une marche qui n'est pas bien plus grande.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Devops
Posté par barmic . En réponse au journal Kickstart et Ansible pour automatiser des installations/configurations de systèmes Linux. Évalué à 5.
C'est ce qui me paraît donner le plus de valeur ajoutée les templates.
Sinon oui ansible marche très bien localement, mais pour configurer ma machine moi c'est :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Devops
Posté par barmic . En réponse au journal Kickstart et Ansible pour automatiser des installations/configurations de systèmes Linux. Évalué à 3.
C'est bien moins critique que le management. Andin le n'a rien de devops. C'est un outil d'administration système. Donc oui c'est un outil qui peut servir en devops au même titre que ssh. Ce n'est pas un sacrum boyard qui rend une équipe agile.
Je fais la remarque parce que c'est important amha de voir que ce n'est pas une question d'outils, mais d'organisation.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Preseed
Posté par barmic . En réponse au journal Kickstart et Ansible pour automatiser des installations/configurations de systèmes Linux. Évalué à 9.
Pour Debian ça s'appelle Preseed.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Devops
Posté par barmic . En réponse au journal Kickstart et Ansible pour automatiser des installations/configurations de systèmes Linux. Évalué à 5.
Oula… Le devops c'est une méthodologie pas des outils. C'est comme si tu disais bienvenu dans l'agilité à quelqu'un qui utilise un bug tracker.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi ?
Posté par barmic . En réponse au journal Comment je suis passé d'Ubuntu à Debian Sid. Évalué à 7. Dernière modification le 12 mai 2017 à 18:29.
Je ne connais pas, mais j'ai souvent lu des gens expliquer qu'il ne fallait pas se plaindre d'avoir des problèmes s'ils utilisent AUR ou que les paquets sont à l'abandon.
Ce sont des paquets que l'on sait à jour et qui respectent toutes les règles de qualité Debian (il y a une liste de paquets en souffrance, mais justement pour les retirer si personne ne s'en occupe (pour info il y en a environ 1 100 actuellement https://www.debian.org/devel/wnpp/index.fr.html)).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)