Psychofox a écrit 10742 commentaires

PsychoFox, il faudrait que tu penses à être cohérent :)

dans le cas d'Ansible il n'y a justement même pas de client à installer. Il faut juste avoir ssh et pousser une clé.

Je ne peux pas parler pour Ansible ne l'utilisant pas mais dans le cas de puppet c'est utilisable en local sans avoir à mettre en place une infra client/serveur.

D'abord tu me dis qu'il n'y a pas besoin de client et qu'il suffit d'avoir SSH et pousser une clé (donc avoir un Ansible ailleurs), ensuite tu me dis d'installer Ansible (ou Puppet, ou autre, je m'en fous de la techno) pour lire le playbook (ou l'équivalent) localement.

Je suis cohérent mais tu mélanges 2 posts qui ne répondent pas aux même questions.

Ansible ne nécessite pas de client si tu l'utilises en mode serveur/client.

Si tu l'utilises en standalone tu as forcément besoin d'avoir quelque part un ansible qui va appliquer le playbook.

qui te prendra peut-être un dixième de tes 900 lignes
Alors là, carrément pas. Ce que j'ai appelé "helpers" dans mon script, donc l'équivalent des ça prend 175 lignes (tout compris). […] À vue de nez, un playbook Ansible équivalent ferait 150% à 200% de la taille de mon script.

Peut-être que Ansible n'est pas le bon example (je ne le connais pas assez) mais je n'y crois pas du tout. Exemple dans puppet que j'utilise tu as la directive de base qui tiens dans une ligne.

Exemple dans puppet :

package { 'vim' }

Par contre tu as effectivement pleins de trucs optionnels qui peuvent t'être utiles mais qui ne sont pas indispensables:

package { 'resource title':
name => # (namevar) The package name. This is the name that the...
provider => # (namevar) The specific backend to use for this `package...
ensure => # What state the package should be in. On...
adminfile => # A file containing package defaults for...
allow_virtual => # Specifies if virtual package names are allowed...
allowcdrom => # Tells apt to allow cdrom sources in the...
category => # A read-only parameter set by the...
configfiles => # Whether to keep or replace modified config files
description => # A read-only parameter set by the...
flavor => # OpenBSD supports 'flavors', which are further...
install_options => # An array of additional options to pass when...
instance => # A read-only parameter set by the...
package_settings => # Settings that can change the contents or...
platform => # A read-only parameter set by the...
reinstall_on_refresh => # Whether this resource should respond to refresh...
responsefile => # A file containing any necessary answers to...
root => # A read-only parameter set by the...
source => # Where to find the package file. This is only...
status => # A read-only parameter set by the...
uninstall_options => # An array of additional options to pass when...
vendor => # A read-only parameter set by the...
# ...plus any applicable metaparameters.
}
Et si tu n'as besoin que d'une ou deux ça peut toujours tenir en 1 ligne :

package { 'vim': ensure => 'latest' }

Et si tu veux installer de multiples packages avec les mêmes options :

$mon_panier_garni_habituel = = [ 'vim', 'bash-completion', 'tmux', 'ssh', 'sshfs', 'keychain', 'sysstat', 'git' ]
package { $mon_panier_garni_habituel: ensure => 'latest' }
Idem pour tout ce qui peut exister comme ressources (users, fichiers, services, etc).

Tu crois que tu peux gérer tout ça en moins de lignes avec ton script ? Bravo tu as réinventé et maintiens un énième outil de gestion de configuration. C'est tout à ton hônneur mais tu t'es forcément bien plus pris la tête qu'un utilisateur simple d'un de ces outils et au final je ne vois pas comment ton code peut être plus court en implémentant à la fois la mécanique derrière et la déclaration des ressources que tu gères, même si le language de ansible est plus verbeux (en terme de lignes) que celui de puppet pour des trucs basiques.

Et dès que tu as des trucs un peu gruik pas prévus d'origine par ton script, c'est à nouveau tout ça à recoder, retester, casser, etc.

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).

Je ne vois pas les difficultés. Dans les outils de gestions de versions tu gères des dépendances. Genre dans puppet avec les directives before ou require voir de simples flèches tu peux gérer les dépendances, avec notify tu mentionnes le nom du service qui doit être redémarré à chaque modification d'un fichier de conf. Je ne trouve pas ça hyper propre dès que la conf est grande mais il est possible d'avoir tout ou partie du contenu d'un fichier dans le code puppet. On peut même le faire avec des templates (inline_template) :

file { "/etc/bidule.conf":
  ensure  => present,
  content => inline_template($header, $content, $footer),
  notify  => Service['bidule'],
}

Dans lequel par exemple $header et $footer sont de simples variables et $content est un hash avec des clés/valeurs que tu paramètre avant. Ici à la place du Service qui est "notifié" tu peux utiliser une ressource Exec qui lancera une commande déclarée avant.

J'ai été sceptique aussi à une époque, puisqu'il y'a une petite courbe d'apprentissage du language utilisé et des ressources disponible et que j'avais aussi mes petits scripts maisons à une époque. Mais on y gagne finalement même à très court terme et ça scale très bien le jour où tu dois gérer des centaines voire milliers de serveurs/containers ce qui est mon cas maintenant.

Personne ne te demande de réécrire quoique ce soit ni de passer à ansible ou puppet. On t'explique juste que l'argument ça tient dans un script n'est pas valable.

On explique juste qu'à choisir si tu commençais maintenant tu aurais meilleur temps de partir sur un outil de gestion de conf qui te prendra peut-être un dixième de tes 900 lignes parce que toute la mécanique qui assure la gestion des erreurs, mais surtout d'idempotence, etc sont inclus dedans et partagés et testés par des millions de gens. Et que la lecture d'un playbook salt ou d'une recette puppet ou chief est bien plus lisible et compréhensible (et donc maintenable) que de naviguer dans un trilliards de fonctions, de structures de controles if/else et compagnie, etc.

il y'a aussi salt, cfengine et quelques autres encore je crois dans le monde du libre.

Les WSL sont des outils pour développeurs ou sysadmins, ils n'ont pas la prétention d'être utilisés "en production" ni d'être utilisé pour offrir des services via le réseau.

ah ouais, pas eu accès à la creator update sur le pc du boulot pour l'instant.

L'accès au filesystem tu l'as dans un sens tout de même (wsl --> windows). Du coup c'est pas vraiment un problème.

Pour exécuter des exe windows c'est possible mais de façon indirecte (d'aucuns diraient un peu alambiquée) :
-powershell via ssh server installé sur le windows
-powershell via l'api rest
-interface winRM via openwsman
-outil de management comme salt, ansible, puppet

Gné ? Quand je viens d'installer mon PC, il n'y a pas de serveur SSH, pas de clé à pousser et aucun moyen d'accéder à un serveur Ansible à partir duquel je déploierais la conf de mon PC, vu que j'utilise mon PC pour ces choses-là… J'ai besoin de pouvoir le post-installer où que je sois.

Je ne peux pas parler pour Ansible ne l'utilisant pas mais dans le cas de puppet c'est utilisable en local sans avoir à mettre en place une infra client/serveur.

Du coup ça peut être aussi simple qu'un apt install puppet && puppet apply monfichierinit.pp

Du coup je ne vois pas vraiment le rationnel pour tout garder dans un script ou t'auras tendance à être obligé de faire usine à gaz pour assurer la gestion des erreurs/conflits/dépendances au lieu d'utiliser un truc bien plus déclaratif. La "recette" puppet peut très bien être self contained si elle n'utilise pas de module particulier, ça tombe bien par défaut il y'a tout ce qu'il faut pour déclarer des ressources packages, user, fichiers, templates pour faire tout ce que tu as besoin. Les modules accessibles depuis la forge sont très bien mais pas essentiels pour qui ne gère pas un nombre élevé de machines / configs différentes.

Nan mais tu sais bien que les articles accessibles en publiques sur les sites des grands medias papiers sont usuellement torchés vite faits par des jeunes sortie d'école de journalisme et que le "contrôle qualité" est au niveau du service minimum (en gros si la correction ortho de word gueule pas, c'est bon). C'est du niveau blog standard.

Pour ma part, j'ai gardé un shellscript simple pour la post-installation de mon PC.
… pour deux raisons toutes simples :

je veux pouvoir l'exécuter immédiatement après installation du PC, sans avoir à installer d'abord Ansible ou autre chose ;
je veux qu'il soit "self-contained", pour pouvoir le copier-coller facilement.
À titre pro, je gère quelques dizaines de serveurs et tout ça est géré avec SaltStack.

C'est une remarque que j'aurais pu comprendre pour son concurrent puppet mais dans le cas d'Ansible il n'y a justement même pas de client à installer. Il faut juste avoir ssh et pousser une clé.

Du reste on parle d'installer des serveurs avec kickstart. Du coup même avec puppet c'est un non-problème. Dans mon environnement pro on installe justement notre client puppet dans le postinstall du kickstart du coup tout est prêt dès la fin de l'installation de base.

J'sais pas, c'est juste un blog.

Que pensez-vous de ce notebook, connaisez vous d'autre alternative si possible opensource sympa ?

J'ai l'impression qu'à peu près n'importe quel chromebook arm est une alternative. Le pinebook n'est pas plus opensource.

C'est le genre de truc que normalement tu n'utilises qu'à l'occasion de migrations.

J'utilisait souvent clusterssh par exemple pour lancer des upgrades en créant des groupes (clusters dans leur nomenclature) de type:
- srv_test_rh_single_node avec toutes les machines redhat d'un environnement test pour des serveurs qui ne sont pas en cluster
- srv_test_rh_node1 avec tous les rh noeuds 1 des clusters
- srv_test_rh_node2 avec tous les rh noeuds 2 des clusters
etc etc avec plusieurs environnements, plusieurs os/distribs, etc.

C'est le genre de truc que tu n'utiliseras jamais avec l'entier de ton parc, ou alors faut être très joueur.

Après dans les cas des upgrades il existe aussi des outils plus spécialisés comme apt-dater (qui je crois ne fonctionne pas que avec apt mais aussi avec yum, zypper & co mais je n'ai jamais essayé hors-contexte debian.

J'ai eu la même chose. La fois où ils avaient déplacés les binaire de /bin à /usr/bin (ou le contraire je ne sais plus).

Mais bon pour moi c'est justement pas admissible dans une optique pc de bureau d'avoir un système en rolling release mais qui peut potentiellement être cassé par pacman -syu parce que t'as pas suivi l'actualité dans les mailings lists. Soit tu t'assures que tout se passe automatiquement, soit tu t'assures que l'outil d'upgrade ait une fonction "drapeau noir" pour avertir l'utilisateur que s'il ne fait pas çi et ça son système va être cassé.

Tu peux aussi très bien utiliser la stable et avoir une utilisation très tranquille. C'est ce que je fais.

Est-ce que j'ai les toutes dernières fonctionnalités de chaque logiciel ? Souvent non. Est-ce que j'en souffre ? Pas vraiment. Pour différentes raisons :

[1] C'est pas parce qu'on n'a pas la dernière version d'un logiciel qu'on est au courant de ce qu'apporte les nouvelles. Du coup on n'en ressentira pas le besoin.

[2] Les dernières versions d'un logiciel n'apportent pas forcément des fonctionnalités qui nous intéressent.

[3] Un certain nombre de projets upstream proposent leurs propres dépôts dans les cas où l'on veut la toute
dernière version.

[4] Il existe le repo backports permettant d'installer des versions plus récentes d'un certain nombre de paquets. Exemple à l'heure où j'écris ces lignes le kernel 4.9 est dispo pour stable.

et enfin pour les plus technards d'entre nous

[5] Il est toujours possible de deboostraper la testing ou la sid voire même installer une autre distribution dans un chroot et d'utiliser quelques applis plus récentes par ce biais.

[6] Docker !

Pour ma part dans le cadre d'une utilisation personnelle à la maison il m'est très rarement arrivé d'utiliser les backports, j'ai souvent eu quelque dépots upstream. C'est essentiellement dans le cadre professionnel que j'ai eu éventuellement recours aux options 4 à 6.

Je ne crois pas avoir à t'expliquer quoique ce soit vu que t'as l'air d'accord.

Ce que je veux dire c'est que voter pour quelqu'un n'est pas un moyen d'expression. C'est un choix qui peut être le choix du meilleur candidat à ses yeux ou du moins pire mais dans tous les cas tout ce qu'on fait c'est lui permettre d'accéder ou pas au pouvoir et/ou de lui permettre de se servir de ton vote comme poids. On ne peut véhiculer autre chose que les idées des candidats.

la vente d'Alstom aux Américains

Ah bon Alstom a été vendu à tous les américains ?

s/Alstom/la filiale énergie d'Alstom/

s/aux Américains/au groupe General Electric/

Faudrait voir à formuler correctement ses affirmations pour ne pas déformer la réalité.

je finirai peut-être par craquer et en arriver comme d’autres à la conclusion que le vote de protestation, c’est le vote FN (en tout cas quand il ne reste plus que le candidat FN face à celui de l’oligarchie). Ce serait triste d’en arriver là (et ça pourrait avoir des conséquences…), mais je pense que je ne serais pas le premier.

Si tu veux voter FN et te reconnaît dans leurs idées, assume et vote FN mais n'invente pas de faux prétexte.

Voter FN ne serait être un vote de "protestation" puisque tu ne voterais pas contre les idées des autres candidats mais pour celles du FN. Ta voix serait encore moins entendue qu'un vote blanc parce que tu serais juste assimilé à leurs idées.

Le concept du vote protestataire c'est juste se chercher des excuses car on n'assume sa propre xénophobie où le fait qu'on cherche un bouc émissaire pour faire porter le poids de ses propres échecs personnels.

T'as oublié quelques options:

-parce qu'ils sont incapable de choisir
-parce qu'ils font confiance à leur concitoyens pour faire le bon choix pour eux

Parce que l'abstention est un vrai message.

Non.

Il y'a autant de messages possibles que de personnes s'étant abstenues et d'ailleurs c'est souvent un mix de plein de raisons. Pour ma part c'est un gros mélange:
- Je suis un étourdi.
- Je suis un vrai normand.
- Je souffre d'une sorte de phobie administrative.
- Je ne me sens pas hyper concerné par la question.
- Je ne ressens pas beaucoup de légitimité de prendre part au processus de décision.

N'empêche que pendant ce temps là il y'a une tripotée de couillons qui ont continué à tomber dans le piège et à répondre dans le journal précédent. C'est affligeant. Plus c'est gros plus ça marche.

Selon la définition du mot oui nous voyons des candidats.

Par contre si ce sont les deux meilleurs choix pour gouverner la France vous êtes mal barrés. Cela-dit on a les dirigeants qu'on mérite dit le dicton.

Le droit d'écriture à la racine n'est pas forcément gênant d'un point de vue sécurité si tu ne peux pas altérer les fichiers et répertoires existants. Il ne me semble pas que windows ait jamais "chargé" automatiquement des exécutables qui se trouvaient à la racine du disque.

Au pire ça peut juste être le bordel si les utilisateurs installent tout et n'importe quoi à la racine.

…c'est ça :

les motards et leurs passagères

Vu sur le site de l'action. Même si ça correspond à une majorité de cas ça me parait terriblement 14ème siècle comme formulation. Le masculin neutre souvent décrié par certains milieux féministe me paraîtrait pour le coup beaucoup moins sexiste.

Nan mais j'veux dire, microsoft supporte le matos qu'ils veulent hein. Dans l'histoire ils sont quand même bien moins talibans que Apple niveau matos supporté par exemple.

Oh my god je peux pas faire tourner slackware 0.9 sur le dernier processeur Intel, la belle affaire.

Ça ne pourrait pas être plus un non-évènement.