Re: [FRsAG] La question (sérieuse) du Vendredi : pourquoi tant d'utilisateurs d'Ansible ?

2016-12-09 Par sujet Mrjk 
Bah, en ce qui me concerne, c'est Ansible que j'ai eu en premier dans
les mains. Ensuite, et à l’époque, la concurrence n’était peut être
pas aussi mature que ce qu'elle peut être aujourd'hui. D'ailleurs, je
me suis laissé entendre dire que certains collègues avaient essayé
Salt (alors qu'on était sur du Ansible de la première heure), et
qu'ils kiffaient pas mal, mais je pourrais pas en dire plus.

Apres, de ce que je connais d'Ansible, je dirais que c'est pas la
solution à tout, et que le couple Puppet + Ansible me parait tout a
fait recommandé pour géré une infrastructure hétérogène; oui, parceque
dans ma boite, j'ai autant de serveurs que de config :/ D'ailleurs si
y'en a qui veulent philosopher sur le fait que Ansible et Puppet sont
complémentaire, I'm open. Maintenant si Salt propose la combinaison
des deux (en terme de concepts/processus), bah il est tant que j'aille
voir Salt :D .

Dernier point, Ansible est désormais RedHat backed maintenant, ça a
tendance a faire réfléchir les DSI sur le coté corpo de la chose. Je
ne sais pas pour la concurrence qui gère qui.

Sur tes points précis, concernant la vitesse, la réponse de Gilou me
semble toute à fait bonne. Pour la partie scaling, alors là, explique
moi, car je ne vois pas, j'ai jamais été bloqué sur ce point (en même
temps, je déploie rarement de 10K nodes, j'ai tendance à préférer
Puppet pour cette job la).

--
MrJK
GPG: https://jeznet.org/jez.asc


Le 9 décembre 2016 à 09:47, Jonathan Leroy
 a écrit :
> Salut à tous,
>
> J'ai l'impression ces derniers temps qu'il y a de plus en plus
> d'utilisateurs d'Ansible. Pas seulement sur cette liste, mais un peu
> partout sur l'Internet.
> Du coup j'ai une question : qu'est-ce qui vous a fait choisir Ansible
> plutôt que Saltstack, qui est lui aussi basé sur Python et YAML ?
>
> J'ai toujours entendu dire qu'Ansible était (très) lent et ne scalait
> pas. Est-ce seulement le fait qu'il soit agentless ?
>
> Merci :)
>
> --
> Jonathan Leroy.
> ___
> Liste de diffusion du FRsAG
> http://www.frsag.org/
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] La question (sérieuse) du Vendredi : pourquoi tant d'utilisateurs d'Ansible ?

2016-12-09 Par sujet remy.dernat 


Juste je confirme pour les PR dans salt, ayant vu mes codes acceptes puis 
apparaitre dans la version en dev puis dans la derniere release 2016.11 8-). il 
est d ailleurs regrettable qu il n y en ai pas plus finalement :)


 Message d'origine 
De : Nathan delhaye  
Date : 09/12/2016  17:32  (GMT+01:00) 
À : Gilou  
Cc : French SysAdmin Group  
Objet : Re: [FRsAG] La question (sérieuse) du Vendredi : pourquoi tant 
d'utilisateurs d'Ansible ? 

Hello,
De mon côté j'ai remplacé Puppet par Salt il y a un an environs. Le choix s'est 
fait entre Chef, Puppet, Ansible et Salt lorsque nous avons du refaire notre 
infra. Puppet et Chef ont été éliminés bien vite parce que je Déteste le ruby 
(non mais sérieux "(var ||= []) << var" comment on peut trouver ça simple a 
lire?? )
Le choix final s'est porté sur Salt pour 4 raisons principales a l'époque :  - 
La possibilité de travailler en mode minion/master ET en mode ssh : permet 
d'avoir une infra complexe et des scripts de bootstrap simples  - La mine 
intégrée, qui remplace très efficacement etcd  - Le système de reactor, 
pratique pour faire du monitoring réactif ou de la coordination de cluster  - 
La scalabilité et rapidité d'éxécution des states.
Concernant la scalabilité/rapidité d'éxécution, je m'explique : lorsque j'ai un 
grand nombre d'états (users, fichiers, archives, certificats, etc...) sur un 
serveur, le cache de Salt permet d'accélérer grandement les choses. Sur un test 
sur un serveur un peu lourd, type Wordpress du marketing/SEO 
(http://bit.ly/2hdbhxN) avec une pétachiée de vhost, je passe de 2 minutes 
d'éxécution avec le script ansible à 10-15 secondes avec Salt lorsqu'il y as 
peu de modif a faire (exemple, créer un nouveau vhost).
Pour moi c'est le cas le plus important a benchmark dans la mesure ou le temp 
d’exécution lors du setup initial va être sensiblement le même parce que les 
deux systèmes vont devoir exécuter le package manager, installer des trucs, 
créer des users, générer des certificats, etc, etc ce qui prend généralement 
plus de temps que le calcul des diff par le système d'industrialisation.
Cela dit, le ticket d'entrée sur Salt est bien plus élevé que sur Ansible. On 
se rapproche plus de Chef que de la philosophie Ansible proche du "rsync 
script.sh server: && ssh server script.sh"
Après un peu de recul, en plus des 4 points qui ont motivé le choix de la 
techno voila mon avis sur Salt:  - Systèmes Modules/States/Formulas/Grains qui 
sépare bien les différents composants d'un système d'industrialisation 
absolument jouissif a utiliser.  - Modules/States/formules faciles a développer 
 - Possibilité de faire du quick & dirty dans les formules avec du pur 
Yaml/Json, mais aussi des trucs bien complexes en Python  - Les gars de Salt 
sont réactifs au merge de PR sur leur git
A+
Le 9 décembre 2016 à 15:59, Gilou  a écrit :
Le 09/12/2016 à 15:47, Jonathan Leroy a écrit :

> Salut à tous,

>

> J'ai l'impression ces derniers temps qu'il y a de plus en plus

> d'utilisateurs d'Ansible. Pas seulement sur cette liste, mais un peu

> partout sur l'Internet.

> Du coup j'ai une question : qu'est-ce qui vous a fait choisir Ansible

> plutôt que Saltstack, qui est lui aussi basé sur Python et YAML ?



Pas plutôt, je ne les utilise pas pour la même chose. Pourquoi l'adoption ?

Parce que :

- 0 infrastructure pour commencer

        => (SSH / DNS + inventaire, le pré-requis est très bas)

- Accès ultra-simple

        => (ad-hoc = 0 apprentissage, 1er playbook en 5 minutes)

- Passer d'un shell script à un playbook (salement) : 5 minutes

- Industrialiser et comprendre l'idempotence, easy

- Se plugger sur un inventaire (cloud ou pas) existant (amazon,

openstack, ...) easy.



Et parce que.. ça répond au besoin de mise en conformité en passant par

le code, propre d'une mise ne place DevOps, et facilite grandement

l'idempotence et l'orchestration à grande échelle.



Pourquoi ça ne remplace pas Salt, Puppet ou autre (du moins, sans

Tower). Les outils basés sur un agent sont plus faciles à manipuler à

plusieurs, pour définir des gestions de privilèges ou dépendre d'un CMDB

bien violent, et gérer les accès simultanés. Ils sont aussi plus lourds.





>

> J'ai toujours entendu dire qu'Ansible était (très) lent et ne scalait

> pas. Est-ce seulement le fait qu'il soit agentless ?



Il est aussi lent que SSH l'est, malgré les optimisations diverses

(notamment très ressenties en 2 puis en 2.2). Pour ce qui est du

comparatif, je ne crois pas que Puppet ou Salt puisse la ramener sur la

vitesse d'exécution, mais je pense aussi que c'est un critère assez

secondaire.



Ne "scale" pas, j'aimerais bien une élaboration. Il ne gère pas

facilement les accès simultanés et la gestion de privilèges, par nature,

mais il scale très bien, et les callbacks sont très facile d'accès pour

les besoins (ou bien, on achète

Re: [FRsAG] La question (sérieuse) du Vendredi : pourquoi tant d'utilisateurs d'Ansible ?

2016-12-09 Par sujet Nathan delhaye 
Hello,

De mon côté j'ai remplacé Puppet par Salt il y a un an environs. Le choix
s'est fait entre Chef, Puppet, Ansible et Salt lorsque nous avons du
refaire notre infra. Puppet et Chef ont été éliminés bien vite parce que je
Déteste le ruby (non mais sérieux "(var ||= []) << var" comment on peut
trouver ça simple a lire?? )

Le choix final s'est porté sur Salt pour 4 raisons principales a l'époque :
  - La possibilité de travailler en mode minion/master ET en mode ssh :
permet d'avoir une infra complexe et des scripts de bootstrap simples
  - La mine intégrée, qui remplace très efficacement etcd
  - Le système de reactor, pratique pour faire du monitoring réactif ou de
la coordination de cluster
  - La scalabilité et rapidité d'éxécution des states.

Concernant la scalabilité/rapidité d'éxécution, je m'explique : lorsque
j'ai un grand nombre d'états (users, fichiers, archives, certificats,
etc...) sur un serveur, le cache de Salt permet d'accélérer grandement les
choses. Sur un test sur un serveur un peu lourd, type Wordpress du
marketing/SEO (http://bit.ly/2hdbhxN) avec une pétachiée de vhost, je passe
de 2 minutes d'éxécution avec le script ansible à 10-15 secondes avec Salt
lorsqu'il y as peu de modif a faire (exemple, créer un nouveau vhost).

Pour moi c'est le cas le plus important a benchmark dans la mesure ou le
temp d’exécution lors du setup initial va être sensiblement le même parce
que les deux systèmes vont devoir exécuter le package manager, installer
des trucs, créer des users, générer des certificats, etc, etc ce qui prend
généralement plus de temps que le calcul des diff par le système
d'industrialisation.

Cela dit, le ticket d'entrée sur Salt est bien plus élevé que sur Ansible.
On se rapproche plus de Chef que de la philosophie Ansible proche du "rsync
script.sh server: && ssh server script.sh"

Après un peu de recul, en plus des 4 points qui ont motivé le choix de la
techno voila mon avis sur Salt:
  - Systèmes Modules/States/Formulas/Grains qui sépare bien les différents
composants d'un système d'industrialisation absolument jouissif a utiliser.
  - Modules/States/formules faciles a développer
  - Possibilité de faire du quick & dirty dans les formules avec du pur
Yaml/Json, mais aussi des trucs bien complexes en Python
  - Les gars de Salt sont réactifs au merge de PR sur leur git

A+

Le 9 décembre 2016 à 15:59, Gilou  a écrit :

> Le 09/12/2016 à 15:47, Jonathan Leroy a écrit :
> > Salut à tous,
> >
> > J'ai l'impression ces derniers temps qu'il y a de plus en plus
> > d'utilisateurs d'Ansible. Pas seulement sur cette liste, mais un peu
> > partout sur l'Internet.
> > Du coup j'ai une question : qu'est-ce qui vous a fait choisir Ansible
> > plutôt que Saltstack, qui est lui aussi basé sur Python et YAML ?
>
> Pas plutôt, je ne les utilise pas pour la même chose. Pourquoi l'adoption ?
> Parce que :
> - 0 infrastructure pour commencer
> => (SSH / DNS + inventaire, le pré-requis est très bas)
> - Accès ultra-simple
> => (ad-hoc = 0 apprentissage, 1er playbook en 5 minutes)
> - Passer d'un shell script à un playbook (salement) : 5 minutes
> - Industrialiser et comprendre l'idempotence, easy
> - Se plugger sur un inventaire (cloud ou pas) existant (amazon,
> openstack, ...) easy.
>
> Et parce que.. ça répond au besoin de mise en conformité en passant par
> le code, propre d'une mise ne place DevOps, et facilite grandement
> l'idempotence et l'orchestration à grande échelle.
>
> Pourquoi ça ne remplace pas Salt, Puppet ou autre (du moins, sans
> Tower). Les outils basés sur un agent sont plus faciles à manipuler à
> plusieurs, pour définir des gestions de privilèges ou dépendre d'un CMDB
> bien violent, et gérer les accès simultanés. Ils sont aussi plus lourds.
>
>
> >
> > J'ai toujours entendu dire qu'Ansible était (très) lent et ne scalait
> > pas. Est-ce seulement le fait qu'il soit agentless ?
>
> Il est aussi lent que SSH l'est, malgré les optimisations diverses
> (notamment très ressenties en 2 puis en 2.2). Pour ce qui est du
> comparatif, je ne crois pas que Puppet ou Salt puisse la ramener sur la
> vitesse d'exécution, mais je pense aussi que c'est un critère assez
> secondaire.
>
> Ne "scale" pas, j'aimerais bien une élaboration. Il ne gère pas
> facilement les accès simultanés et la gestion de privilèges, par nature,
> mais il scale très bien, et les callbacks sont très facile d'accès pour
> les besoins (ou bien, on achète Tower).
>
> Bref, Ansible, ça rox, ça demande rien, et ça claque.
>
> @+
> Gilou
>
> ___
> Liste de diffusion du FRsAG
> http://www.frsag.org/
>



-- 
Nathan Delhaye
06 69 27 64 25
0805 696 494
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] La question (sérieuse) du Vendredi : pourquoi tant d'utilisateurs d'Ansible ?

2016-12-09 Par sujet frsag 
Et les mêmes inconvénients, donc, lorsque tu as une architecture système
un peu moins simpliste :) (anycast, lb etc, et sans avoir les moyens
d'avoir X ip globalement adressable par machine)


On 09/12/2016 16:29, Dominique Rousseau wrote:
> Le Fri, Dec 09, 2016 at 03:47:56PM +0100, Jonathan Leroy 
> [jonat...@unsigned.inikup.com] a écrit:
>> Salut à tous,
>>
>> J'ai l'impression ces derniers temps qu'il y a de plus en plus
>> d'utilisateurs d'Ansible. Pas seulement sur cette liste, mais un peu
>> partout sur l'Internet.
>> Du coup j'ai une question : qu'est-ce qui vous a fait choisir Ansible
>> plutôt que Saltstack, qui est lui aussi basé sur Python et YAML ?
> 
> Comme Gilou, je dirais qu'une raison du succes d'Ansible, c'est qu'on
> demarre avec en 5 minutes, il suffit de ssh et python, rien a installer
> sur la cible.
> (et c'est la raison pour laquelle j'aime bien Fabric aussi, qui a les
> memes avantages, de ce point de vue)
> 


___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] La question (sérieuse) du Vendredi : pourquoi tant d'utilisateurs d'Ansible ?

2016-12-09 Par sujet Dominique Rousseau 
Le Fri, Dec 09, 2016 at 03:47:56PM +0100, Jonathan Leroy 
[jonat...@unsigned.inikup.com] a écrit:
> Salut à tous,
> 
> J'ai l'impression ces derniers temps qu'il y a de plus en plus
> d'utilisateurs d'Ansible. Pas seulement sur cette liste, mais un peu
> partout sur l'Internet.
> Du coup j'ai une question : qu'est-ce qui vous a fait choisir Ansible
> plutôt que Saltstack, qui est lui aussi basé sur Python et YAML ?

Comme Gilou, je dirais qu'une raison du succes d'Ansible, c'est qu'on
demarre avec en 5 minutes, il suffit de ssh et python, rien a installer
sur la cible.
(et c'est la raison pour laquelle j'aime bien Fabric aussi, qui a les
memes avantages, de ce point de vue)

-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
21 rue Frédéric Petit - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] La question (sérieuse) du Vendredi : pourquoi tant d'utilisateurs d'Ansible ?

2016-12-09 Par sujet Olivier Duquesne (DaffyDuke) 
Bonjour, juste pour mettre mon grain de sel , salt est nativement intégré
dans les dernières versions de Suse Manager, le pendant Suse de RedHat
Satellite (spacewalk).

Le ven. 9 déc. 2016 16:01, Gilou  a écrit :

> Le 09/12/2016 à 15:47, Jonathan Leroy a écrit :
> > Salut à tous,
> >
> > J'ai l'impression ces derniers temps qu'il y a de plus en plus
> > d'utilisateurs d'Ansible. Pas seulement sur cette liste, mais un peu
> > partout sur l'Internet.
> > Du coup j'ai une question : qu'est-ce qui vous a fait choisir Ansible
> > plutôt que Saltstack, qui est lui aussi basé sur Python et YAML ?
>
> Pas plutôt, je ne les utilise pas pour la même chose. Pourquoi l'adoption ?
> Parce que :
> - 0 infrastructure pour commencer
> => (SSH / DNS + inventaire, le pré-requis est très bas)
> - Accès ultra-simple
> => (ad-hoc = 0 apprentissage, 1er playbook en 5 minutes)
> - Passer d'un shell script à un playbook (salement) : 5 minutes
> - Industrialiser et comprendre l'idempotence, easy
> - Se plugger sur un inventaire (cloud ou pas) existant (amazon,
> openstack, ...) easy.
>
> Et parce que.. ça répond au besoin de mise en conformité en passant par
> le code, propre d'une mise ne place DevOps, et facilite grandement
> l'idempotence et l'orchestration à grande échelle.
>
> Pourquoi ça ne remplace pas Salt, Puppet ou autre (du moins, sans
> Tower). Les outils basés sur un agent sont plus faciles à manipuler à
> plusieurs, pour définir des gestions de privilèges ou dépendre d'un CMDB
> bien violent, et gérer les accès simultanés. Ils sont aussi plus lourds.
>
>
> >
> > J'ai toujours entendu dire qu'Ansible était (très) lent et ne scalait
> > pas. Est-ce seulement le fait qu'il soit agentless ?
>
> Il est aussi lent que SSH l'est, malgré les optimisations diverses
> (notamment très ressenties en 2 puis en 2.2). Pour ce qui est du
> comparatif, je ne crois pas que Puppet ou Salt puisse la ramener sur la
> vitesse d'exécution, mais je pense aussi que c'est un critère assez
> secondaire.
>
> Ne "scale" pas, j'aimerais bien une élaboration. Il ne gère pas
> facilement les accès simultanés et la gestion de privilèges, par nature,
> mais il scale très bien, et les callbacks sont très facile d'accès pour
> les besoins (ou bien, on achète Tower).
>
> Bref, Ansible, ça rox, ça demande rien, et ça claque.
>
> @+
> Gilou
>
> ___
> Liste de diffusion du FRsAG
> http://www.frsag.org/
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] La question (sérieuse) du Vendredi : pourquoi tant d'utilisateurs d'Ansible ?

2016-12-09 Par sujet Gilou 
Le 09/12/2016 à 15:47, Jonathan Leroy a écrit :
> Salut à tous,
> 
> J'ai l'impression ces derniers temps qu'il y a de plus en plus
> d'utilisateurs d'Ansible. Pas seulement sur cette liste, mais un peu
> partout sur l'Internet.
> Du coup j'ai une question : qu'est-ce qui vous a fait choisir Ansible
> plutôt que Saltstack, qui est lui aussi basé sur Python et YAML ?

Pas plutôt, je ne les utilise pas pour la même chose. Pourquoi l'adoption ?
Parce que :
- 0 infrastructure pour commencer
=> (SSH / DNS + inventaire, le pré-requis est très bas)
- Accès ultra-simple
=> (ad-hoc = 0 apprentissage, 1er playbook en 5 minutes)
- Passer d'un shell script à un playbook (salement) : 5 minutes
- Industrialiser et comprendre l'idempotence, easy
- Se plugger sur un inventaire (cloud ou pas) existant (amazon,
openstack, ...) easy.

Et parce que.. ça répond au besoin de mise en conformité en passant par
le code, propre d'une mise ne place DevOps, et facilite grandement
l'idempotence et l'orchestration à grande échelle.

Pourquoi ça ne remplace pas Salt, Puppet ou autre (du moins, sans
Tower). Les outils basés sur un agent sont plus faciles à manipuler à
plusieurs, pour définir des gestions de privilèges ou dépendre d'un CMDB
bien violent, et gérer les accès simultanés. Ils sont aussi plus lourds.


> 
> J'ai toujours entendu dire qu'Ansible était (très) lent et ne scalait
> pas. Est-ce seulement le fait qu'il soit agentless ?

Il est aussi lent que SSH l'est, malgré les optimisations diverses
(notamment très ressenties en 2 puis en 2.2). Pour ce qui est du
comparatif, je ne crois pas que Puppet ou Salt puisse la ramener sur la
vitesse d'exécution, mais je pense aussi que c'est un critère assez
secondaire.

Ne "scale" pas, j'aimerais bien une élaboration. Il ne gère pas
facilement les accès simultanés et la gestion de privilèges, par nature,
mais il scale très bien, et les callbacks sont très facile d'accès pour
les besoins (ou bien, on achète Tower).

Bref, Ansible, ça rox, ça demande rien, et ça claque.

@+
Gilou

___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] La question (sérieuse) du Vendredi : pourquoi tant d'utilisateurs d'Ansible ?

2016-12-09 Par sujet Boris Tassou via FRsAG 

Bonjour,

Salt peut l'être aussi via salt-ssh il me semble.

Le 2016-12-09 15:47, Jonathan Leroy a écrit :

Salut à tous,

J'ai l'impression ces derniers temps qu'il y a de plus en plus
d'utilisateurs d'Ansible. Pas seulement sur cette liste, mais un peu
partout sur l'Internet.
Du coup j'ai une question : qu'est-ce qui vous a fait choisir Ansible
plutôt que Saltstack, qui est lui aussi basé sur Python et YAML ?

J'ai toujours entendu dire qu'Ansible était (très) lent et ne scalait
pas. Est-ce seulement le fait qu'il soit agentless ?

Merci :)

___
Liste de diffusion du FRsAG
http://www.frsag.org/

[FRsAG] La question (sérieuse) du Vendredi : pourquoi tant d'utilisateurs d'Ansible ?

2016-12-09 Par sujet Jonathan Leroy 
Salut à tous,

J'ai l'impression ces derniers temps qu'il y a de plus en plus
d'utilisateurs d'Ansible. Pas seulement sur cette liste, mais un peu
partout sur l'Internet.
Du coup j'ai une question : qu'est-ce qui vous a fait choisir Ansible
plutôt que Saltstack, qui est lui aussi basé sur Python et YAML ?

J'ai toujours entendu dire qu'Ansible était (très) lent et ne scalait
pas. Est-ce seulement le fait qu'il soit agentless ?

Merci :)

-- 
Jonathan Leroy.
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Un installer lamp automatique pour Debian 8

2016-12-09 Par sujet Pierre-Olivier Grangaud 
Hello 
C'est vendredi 
c'est kdo : 
http://linuxfr.org/news/systemd-l-init-martyrise-l-init-bafoue-mais-l-init-libere
et je ne vous dis pas que j'aime salt mais l'idée de contrôler des minions me 
fascinent.

/po



> -Message d'origine-
> De : FRsAG [mailto:frsag-boun...@frsag.org] De la part de Francois Lafont
> Envoyé : vendredi 9 décembre 2016 15:04
> À : French SysAdmin Group 
> Objet : Re: [FRsAG] Un installer lamp automatique pour Debian 8
> 
> Bonjour à tous,
> 
> On 12/09/2016 02:03 PM, Jonathan Leroy wrote:
> 
> > Pareil, moi je n'ai rien contre bien Systemd, mais cht :)
> 
> Ben oui, moi c'est pareil.
> Et, tant que j'y suis, confidence pour confidence, je « surkiffe » carrément 
> Puppet 4.
> 
> Voilà, je me sens un peu soulagé maintenant. :p
> 
> --
> François Lafont
> ___
> Liste de diffusion du FRsAG
> http://www.frsag.org/
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] systemd vs les adminsys

2016-12-09 Par sujet Jonathan Leroy 
Le 9 décembre 2016 à 14:59, Dominique Rousseau  a écrit :
> C'est ça le vrai probleme de systemd sur des serveurs, c'est que ça a un
> coté bulldozer, qui remplace les outils de configuration reseau, le
> collecteur de logs, etc. Systemd arrive avec tout un ecosysteme qui fait
> qu'on a plus "un Unix" (un peu comme MacosX), avec des fichiers plats
> editables et lisibles par un humain adminsys, des fichiers logs qu'on
> peut grep/awk/..., des noms d'interface reseau deterministes, etc.

Mais la plupart de ces fonctionnalités sont désactivables, voire
désactivées par défaut.
C'est le cas par défaut sous Debian, qui n'utilise que la partie
"init" de Systemd.

-- 
Jonathan Leroy.
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Un installer lamp automatique pour Debian 8

2016-12-09 Par sujet Francois Lafont 
Bonjour à tous,

On 12/09/2016 02:03 PM, Jonathan Leroy wrote:

> Pareil, moi je n'ai rien contre bien Systemd, mais cht :)

Ben oui, moi c'est pareil.
Et, tant que j'y suis, confidence pour confidence, je « surkiffe » carrément 
Puppet 4.

Voilà, je me sens un peu soulagé maintenant. :p

--
François Lafont
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] [Systemd] Un installer lamp automatique pour Debian 8

2016-12-09 Par sujet Frédéric VANNIÈRE 

Le 09/12/2016 à 09:34, Remy Dernat a écrit :

On va éviter de lancer le troll, même si c'est 'dredi, mais personnellement, 
même si je trouve que la couche de gestion apportées par systemd est pratique, 
on se retrouve souvent à démêler des problèmes qu'on avait pas avant, et 
surtout, souvent plus complexes (ça me rappelle d'ailleurs un peu le passage de 
LILO à GRUB à l'époque (*)). Bref, notre ami Lennart Poettering a juste oublié 
que sous Linux, il fallait faire KISS


J'aime systemd, il nécessite un temps d'adaptation comme tous les nouveaux 
systèmes mais il apporte de la modernité à l'init poussiéreux.

Modifier le démarrage d'un démon avec un fichier .ini, superviser certains 
services, gérer proprement les groupes de processus c'est un gain appréciable. 
J'attends Debian 9 et l'intégration de systemd-nspawn plus récent pour vraiment 
exploiter toutes les fonctionnalités.

J'ai systemd sur quelques centaines de serveurs web sous Debian 8. Les seuls 
soucis rencontrés viennent d'une mauvaise intégration dans Debian (systemd + 
vieux scripts init), il est aussi moins tolérants aux erreurs de configuration 
(programme qui plante, filesystem qui n'exite pas).

Systemd est l'aboutissement de l'évolution de l'init linux. Ça reste un 
logiciel récent, complexe et en plein développement. On tape sur Lennart mais 
beaucoup de monde travaille sur systemd depuis que c'est intégré aux 
distributions linux.

Frédéric.
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] systemd vs les adminsys

2016-12-09 Par sujet Dominique Rousseau 
Le Fri, Dec 09, 2016 at 02:09:35PM +0100, Luc Didry [l...@didry.org] a écrit:
[...]
> Perso, je n'ai pas eu d'embrouille avec systemd qui mériterait de
> perdre du temps à l'enlever. En fait, je n'ai pas eu d'embrouille du
> tout??? sur mes serveurs. C'est vrai que parfois, mon laptop est long
> à éteindre, mais comme je le mets en veille généralement et que je ne
> l'éteint qu'une fois tous les 36 du mois, ça passe.

Sur un portable/ordinateur de bureau, à usage "poste de travail" (ou
facebook, ou jeux, ou ...), ça a pourquoi pas sa place, l'init Unix
classique (et les services que ca lance) ne convient plus forcement aux
usages modernes.

> Et au contraire, systemd m'a simplifié la vie avec les .service
> simples à écrire, sans oublier les .service génériques, ceux avec @
> dans leur nom : ça c'est top, j'écris un modèle de service, et poum,
> je peux lancer autant d'instances différentes que je veux.
> 
> Ce qui m'embête avec systemd, c'est qu'il grossit beaucoup et veut
> tout faire,

C'est ça le vrai probleme de systemd sur des serveurs, c'est que ça a un
coté bulldozer, qui remplace les outils de configuration reseau, le
collecteur de logs, etc. Systemd arrive avec tout un ecosysteme qui fait
qu'on a plus "un Unix" (un peu comme MacosX), avec des fichiers plats
editables et lisibles par un humain adminsys, des fichiers logs qu'on
peut grep/awk/..., des noms d'interface reseau deterministes, etc.


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
21 rue Frédéric Petit - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Un installer lamp automatique pour Debian 8

2016-12-09 Par sujet Colin J. Brigato 
On est en 2016, la question ‘est plus du tout de savoir si tu es un vrai 
sysadmin, mais si tu es un vrai devops mec, le sysadmin, c’est sys-has-been.

Et un vrai devops ca utilise une technologie convergente idempotente qui 
prefère largement le rhinocéros, ca utilise des buzzword, c’est fataliste que 
par respect irraisonné pour un type qui est défini comme “plus agile que les 
autres” (surement un vieux truc de ninja),
et en effet y’a rien de tout ça dans ton mail.

Je propose qu’on te rase la tête et qu’on te mette un Tshirt qui mentionne bien 
ton insalubrité vis à vis de l’année 2016, pire encore vis à vis de 2017 qui 
s’en vient.

Et tu partira travailler pour la SNCF, pour aller avec ton retard.

-- 
__- Colin J. βrigato -_
¥ngénieur Σystème & Δirecteur de Projet
  ✆ 06 43 19 33 49
___-_-_-_-_-_-_-_-_-_-_-_-_-

> On 9 Dec 2016, at 13:30, VAILLEAU Olivier  
> wrote:
> 
> Dans la série "c'est mon choix"...
> 
> Systemd me semble plus simple/robuste à utiliser (oui, c'est pas KISS, mais à 
> l'utilisation basique que j'en fait, ça me convient bien). De là à dire que 
> je préfère l'un plus que l'autre, non..
> 
> Je suis un "petit" consommateur de linux, non habitué à chef / puppet, etc.. 
> ça doit expliquer ma satisfaction fataliste de ce que je vais trouver sur les 
> distribs.
> 
> 
> Voilà,un commentaire qui sert à rien, sinon juste à infirmer "que nul part ou 
> systemd passe l’adminsys ne trouve ça classe". Moi, j'ai laissé systemd 
> (aussi parce que je sais pas le remplacer).
> Je vois le troll arriver en hurlant que du coup, je dois pas être un vrai 
> sysadmin. ;-)
> 
> 
> Olivier.
> 
> Et sinon, vous préférez quoi : le rhinocéros ou une petite cuillère ?
> (astuce : la petite cuillère, elle brille... )
> 
> 
> -Message d'origine-
> De : FRsAG [mailto:frsag-boun...@frsag.org] De la part de Colin J. Brigato
> Envoyé : vendredi 9 décembre 2016 13:09
> À : Alexandre Legrix
> Cc : French SysAdmin Group
> Objet : Re: [FRsAG] Un installer lamp automatique pour Debian 8
> 
> Confirmant donc que nul part ou systemd passe l’adminsys ne trouve ça classe.
> Clairement, OpenRC + ansible pour du perso et on est bien.
> 
> -- 
> __- Colin J. βrigato -_
> ¥ngénieur Σystème & Δirecteur de Projet
>  ✆ 06 43 19 33 49
> ___-_-_-_-_-_-_-_-_-_-_-_-_-
> 
>> On 9 Dec 2016, at 13:07, Alexandre Legrix  wrote:
>> 
>> Pour  le coup je parlais de machines perso en dehors du cadre professionnel. 
> 
> ___
> Liste de diffusion du FRsAG
> http://www.frsag.org/

___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Un installer lamp automatique pour Debian 8

2016-12-09 Par sujet Luc Didry 
vendredi 9 décembre 2016, 12:30:16 CET VAILLEAU Olivier wrote:
> Dans la série "c'est mon choix"...
> 
> Systemd me semble plus simple/robuste à utiliser (oui, c'est pas KISS, mais à 
> l'utilisation basique que j'en fait, ça me convient bien). De là à dire que 
> je préfère l'un plus que l'autre, non..
> 
> Je suis un "petit" consommateur de linux, non habitué à chef / puppet, etc.. 
> ça doit expliquer ma satisfaction fataliste de ce que je vais trouver sur les 
> distribs.
> 
> 
> Voilà,un commentaire qui sert à rien, sinon juste à infirmer "que nul part ou 
> systemd passe l’adminsys ne trouve ça classe". Moi, j'ai laissé systemd 
> (aussi parce que je sais pas le remplacer).
> Je vois le troll arriver en hurlant que du coup, je dois pas être un vrai 
> sysadmin. ;-)
> 
> 
> Olivier.
> 
> Et sinon, vous préférez quoi : le rhinocéros ou une petite cuillère ?
> (astuce : la petite cuillère, elle brille... )

Perso, je n'ai pas eu d'embrouille avec systemd qui mériterait de perdre du
temps à l'enlever. En fait, je n'ai pas eu d'embrouille du tout… sur mes
serveurs. C'est vrai que parfois, mon laptop est long à éteindre, mais comme je
le mets en veille généralement et que je ne l'éteint qu'une fois tous les 36 du
mois, ça passe.

Et au contraire, systemd m'a simplifié la vie avec les .service simples à
écrire, sans oublier les .service génériques, ceux avec @ dans leur nom : ça
c'est top, j'écris un modèle de service, et poum, je peux lancer autant
d'instances différentes que je veux.

Ce qui m'embête avec systemd, c'est qu'il grossit beaucoup et veut tout faire,
même le café (quoi, vous n'avez pas encore vu coffeed ? :P). Ça n'est plus juste
un system d'init, et ça me gène un peu.
-- 
Luc
https://fiat-tux.fr/
https://luc.frama.io/
Internet n'est pas compliqué, Internet est ce que vous en faites.

___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Un installer lamp automatique pour Debian 8

2016-12-09 Par sujet Guillaume Tournat 

Le 08/12/2016 à 19:21, Mrjk a écrit :

Salut,

Loin de moi de vouloir relancer un troll qui devient vieux comme le
monde à ce stade, mais que reproche-tu concrètement à sytemd? C'est le
point de vue de l'admin qui fait de la prod qui m’intéresse (je ne
sais pas si tu es dans ce cas).

En ce qui me concerne, et étant sysadmin, je trouve que ça a apporté
un grand confort, surtout quand on utilise des outils du type
Ansible/Puppet sur différentes plateforme. Une interface pour tous les
masteriser. J'ai encore du mal à comprendre ce que l'on peut reprocher
a systemd.


leur manie de tout recoder dans systemd, jusqu'au resolver dns, au 
client dhcp, ...

les logs en binaire, illisible directement, sans les commandes idoines
c'est développé par gnome
je trouve que ça opacifie le boot, à faire trop de trucs
et quand ça bug, du coup, ça fait des trucs moches.

et puis, j'ai du prendre mes petites habitudes aussi :-)
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Un installer lamp automatique pour Debian 8

2016-12-09 Par sujet Jonathan Leroy 
Le 9 décembre 2016 à 13:30, VAILLEAU Olivier
 a écrit :
> Dans la série "c'est mon choix"...

Pareil, moi je n'ai rien contre bien Systemd, mais cht :)

-- 
Jonathan Leroy.
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Un installer lamp automatique pour Debian 8

2016-12-09 Par sujet VAILLEAU Olivier 
Dans la série "c'est mon choix"...

Systemd me semble plus simple/robuste à utiliser (oui, c'est pas KISS, mais à 
l'utilisation basique que j'en fait, ça me convient bien). De là à dire que je 
préfère l'un plus que l'autre, non..

Je suis un "petit" consommateur de linux, non habitué à chef / puppet, etc.. ça 
doit expliquer ma satisfaction fataliste de ce que je vais trouver sur les 
distribs.


Voilà,un commentaire qui sert à rien, sinon juste à infirmer "que nul part ou 
systemd passe l’adminsys ne trouve ça classe". Moi, j'ai laissé systemd (aussi 
parce que je sais pas le remplacer).
Je vois le troll arriver en hurlant que du coup, je dois pas être un vrai 
sysadmin. ;-)


Olivier.

Et sinon, vous préférez quoi : le rhinocéros ou une petite cuillère ?
(astuce : la petite cuillère, elle brille... )


-Message d'origine-
De : FRsAG [mailto:frsag-boun...@frsag.org] De la part de Colin J. Brigato
Envoyé : vendredi 9 décembre 2016 13:09
À : Alexandre Legrix
Cc : French SysAdmin Group
Objet : Re: [FRsAG] Un installer lamp automatique pour Debian 8

Confirmant donc que nul part ou systemd passe l’adminsys ne trouve ça classe.
Clairement, OpenRC + ansible pour du perso et on est bien.

-- 
__- Colin J. βrigato -_
¥ngénieur Σystème & Δirecteur de Projet
  ✆ 06 43 19 33 49
___-_-_-_-_-_-_-_-_-_-_-_-_-

> On 9 Dec 2016, at 13:07, Alexandre Legrix  wrote:
> 
> Pour  le coup je parlais de machines perso en dehors du cadre professionnel. 

___
Liste de diffusion du FRsAG
http://www.frsag.org/
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Un installer lamp automatique pour Debian 8

2016-12-09 Par sujet Colin J. Brigato 
Confirmant donc que nul part ou systemd passe l’adminsys ne trouve ça classe.
Clairement, OpenRC + ansible pour du perso et on est bien.

-- 
__- Colin J. βrigato -_
¥ngénieur Σystème & Δirecteur de Projet
  ✆ 06 43 19 33 49
___-_-_-_-_-_-_-_-_-_-_-_-_-

> On 9 Dec 2016, at 13:07, Alexandre Legrix  wrote:
> 
> Pour  le coup je parlais de machines perso en dehors du cadre professionnel. 

___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Un installer lamp automatique pour Debian 8

2016-12-09 Par sujet Alexandre Legrix 
Pour  le coup je parlais de machines perso en dehors du cadre
professionnel.

Le 9 déc. 2016 12:57, "Colin Brigato"  a écrit :

> Dans le genre système d'init pour server j'eviterai drastiquement système
> en effet :
> -openRC pour le tout venant
> - l'init de busybox pour le compromis efficacité/simplicité
> - carrément sinit quand on est sur du micro service
> - voir pas d'init du tout, avec le service final qui est codé pour faire
> office d'init
> - voir carrément le service final qui est Codé pour être aussi le
> bootloader, à la bare_metal sur vm x86 (j'aime les Unikernel, chacun ses
> vices)
>
> Mais sinon se passer de systemd semble résoudre pas mal de problème.
>
> En revanche pour Barberousse mon précédent je dirait quand même que mettre
> l'usine a gaz "j'abuse des système convergents" "j'ai découvert
> l'idempotence et j'en ai fait une drogue" à.k.a chef quand on  Parle à cote
> d'éviter systemd, c'est plutôt rigolo comme namedropping (et inconsistant).
>
> "Chef, y'en à qu'on essayé, ils ont eu des problème."
> Du moins on connait pas mal de boîte qui jouent beaucoup de transparence
> sur leur propres erreurs et qui n'ont pas manque de bien expliciter
> pourquoi aujourd'hui ils se mordent les doigt d'avoir parié sur chef.
>
> Envoyé par TypeApp 
> Le 9 déc. 2016, à 11:53, Alexandre Legrix  a écrit:
>>
>> Hello
>>
>> Pour résumer c'etait mieux avant concernant, le système d'init !
>> Par contre je ne vois pas l’intérêt d'installer automatiquement un Lamp
>> avec un script Bash maintenant que tout peut être fait très proprement avec
>> Ansible / puppet / chef !
>>
>> Un fidèle utilisateur qui n'a pas du tout aimé systemd et qui utilise
>> openRC tous les jours, et qui n'aime pas du tout pulseaudio 
>>
>> Amicalement
>> Alexandre
>>
>> Le 9 décembre 2016 à 10:50, Benjamin Boudoir > > a écrit :
>>
>>> Le 08/12/2016 19:21, Mrjk a écrit :
>>>
 Salut,

 Loin de moi de vouloir relancer un troll qui devient vieux comme le
 monde à ce stade, mais que reproche-tu concrètement à sytemd? C'est le
 point de vue de l'admin qui fait de la prod qui m’intéresse (je ne
 sais pas si tu es dans ce cas).

 En ce qui me concerne, et étant sysadmin, je trouve que ça a apporté
 un grand confort, surtout quand on utilise des outils du type
 Ansible/Puppet sur différentes plateforme. Une interface pour tous les
 masteriser. J'ai encore du mal à comprendre ce que l'on peut reprocher
 a systemd.

>>>
>>> Je suis sysadmin, j'utilise ansible et je n'ai encore jamais rien vu que
>>> systemd améliorait avec cet outil. J'ai un playbook qui réinstalle sysv au
>>> lieu de systemd sur toutes les machines que l'on gère.
>>>
>>> Les raisons de mon désamour de systemd sont très nombreuses et je vais
>>> la résumer en quelques points :
>>> - systemd est incapable de faire démarrer une machine dans toutes les
>>> conditions (notamment l'utilisation de FS en réseau / tmpfs / RO)
>>> - systemd peut avoir des problèmes pour éteindre certaines machines (je
>>> l'ai déjà retrouver à ne pas réussir à démonter des points montés en réseau
>>> avec un timeout de... 5 minutes. Par point de montage. 2h de down pour une
>>> upgrade de kernel ça fait super mal quand même, ça va que c'était que pour
>>> de l'interne)
>>> - systemd est peut-être plus modulaire que beaucoup d'anti le disent,
>>> dans les faits il l'est beaucoup moins que Lennart Poettring veut bien le
>>> faire croire et beaucoup de distribs se retrouvent presques forcées
>>> d'intégrer des extensions à systemd qui sont au mieux inutiles, au pire
>>> dangereuses (genre systemd-resolvd)
>>> - systemd casse des features du kernel (chroot, LXC, terminaux virtuels,
>>> ...) et ses développeurs refusent de corriger leur code
>>> - systemd rend plus complexe l'écriture de scripts (start / stop /
>>> restart / status ne retournent pas d'état, les commandes retournent leur
>>> résultats dans un pager par défaut, etc.)
>>> - BEAUCOUP de surprises sur des binaires usuels qui changent de
>>> comportement (genre halt qui n'éteint plus électriquement une machine)...
>>> Même si, j'avoue que c'est juste chiant parce que ça casse les habitudes,
>>> en vrai une fois que tu le sais ça va vite a prendre en compte. Et faut
>>> vérifier tes scripts au cas où.
>>>
>>> Je serais moins virtulent avec systemd, si ce n'était qu'un système
>>> d'init. Le problème c'est que ses développeurs veulent le faire grossir en
>>> fonctionnalités avant même de savoir faire booter un système Linux
>>> correctement. C'est fâcheux, vraiment. C'est avant tout une question de
>>> confiance dans le produit fini et en l'état, je suis incapable de prédire
>>> que ma prod tournera correctement (ni même démarrera) avec systemd.
>>> Accessoirement, je préfère les scripts d'init que je peux facilement
>>> débugger alors qu'avec systemd si quelque chose ne démarre pas, je peux me
>>>

Re: [FRsAG] Un installer lamp automatique pour Debian 8

2016-12-09 Par sujet Colin Brigato 
⁣Dans le genre système d'init pour server j'eviterai drastiquement système en 
effet : 
-openRC pour le tout venant 
- l'init de busybox pour le compromis efficacité/simplicité 
- carrément sinit quand on est sur du micro service 
- voir pas d'init du tout, avec le service final qui est codé pour faire office 
d'init 
- voir carrément le service final qui est Codé pour être aussi le bootloader, à 
la bare_metal sur vm x86 (j'aime les Unikernel, chacun ses vices) 

Mais sinon se passer de systemd semble résoudre pas mal de problème. 

En revanche pour Barberousse mon précédent je dirait quand même que mettre 
l'usine a gaz "j'abuse des système convergents" "j'ai découvert l'idempotence 
et j'en ai fait une drogue" à.k.a chef quand on  Parle à cote d'éviter systemd, 
c'est plutôt rigolo comme namedropping (et inconsistant). 

"Chef, y'en à qu'on essayé, ils ont eu des problème." 
Du moins on connait pas mal de boîte qui jouent beaucoup de transparence sur 
leur propres erreurs et qui n'ont pas manque de bien expliciter pourquoi 
aujourd'hui ils se mordent les doigt d'avoir parié sur chef. 

Envoyé par TypeApp ​

Le 9 déc. 2016 11:53, à 11:53, Alexandre Legrix  a écrit:
>Hello
>
>Pour résumer c'etait mieux avant concernant, le système d'init !
>Par contre je ne vois pas l’intérêt d'installer automatiquement un Lamp
>avec un script Bash maintenant que tout peut être fait très proprement
>avec
>Ansible / puppet / chef !
>
>Un fidèle utilisateur qui n'a pas du tout aimé systemd et qui utilise
>openRC tous les jours, et qui n'aime pas du tout pulseaudio 
>
>Amicalement
>Alexandre
>
>Le 9 décembre 2016 à 10:50, Benjamin Boudoir
>
>a écrit :
>
>> Le 08/12/2016 19:21, Mrjk a écrit :
>>
>>> Salut,
>>>
>>> Loin de moi de vouloir relancer un troll qui devient vieux comme le
>>> monde à ce stade, mais que reproche-tu concrètement à sytemd? C'est
>le
>>> point de vue de l'admin qui fait de la prod qui m’intéresse (je ne
>>> sais pas si tu es dans ce cas).
>>>
>>> En ce qui me concerne, et étant sysadmin, je trouve que ça a apporté
>>> un grand confort, surtout quand on utilise des outils du type
>>> Ansible/Puppet sur différentes plateforme. Une interface pour tous
>les
>>> masteriser. J'ai encore du mal à comprendre ce que l'on peut
>reprocher
>>> a systemd.
>>>
>>
>> Je suis sysadmin, j'utilise ansible et je n'ai encore jamais rien vu
>que
>> systemd améliorait avec cet outil. J'ai un playbook qui réinstalle
>sysv au
>> lieu de systemd sur toutes les machines que l'on gère.
>>
>> Les raisons de mon désamour de systemd sont très nombreuses et je
>vais la
>> résumer en quelques points :
>> - systemd est incapable de faire démarrer une machine dans toutes les
>> conditions (notamment l'utilisation de FS en réseau / tmpfs / RO)
>> - systemd peut avoir des problèmes pour éteindre certaines machines
>(je
>> l'ai déjà retrouver à ne pas réussir à démonter des points montés en
>réseau
>> avec un timeout de... 5 minutes. Par point de montage. 2h de down
>pour une
>> upgrade de kernel ça fait super mal quand même, ça va que c'était que
>pour
>> de l'interne)
>> - systemd est peut-être plus modulaire que beaucoup d'anti le disent,
>dans
>> les faits il l'est beaucoup moins que Lennart Poettring veut bien le
>faire
>> croire et beaucoup de distribs se retrouvent presques forcées
>d'intégrer
>> des extensions à systemd qui sont au mieux inutiles, au pire
>dangereuses
>> (genre systemd-resolvd)
>> - systemd casse des features du kernel (chroot, LXC, terminaux
>virtuels,
>> ...) et ses développeurs refusent de corriger leur code
>> - systemd rend plus complexe l'écriture de scripts (start / stop /
>restart
>> / status ne retournent pas d'état, les commandes retournent leur
>résultats
>> dans un pager par défaut, etc.)
>> - BEAUCOUP de surprises sur des binaires usuels qui changent de
>> comportement (genre halt qui n'éteint plus électriquement une
>machine)...
>> Même si, j'avoue que c'est juste chiant parce que ça casse les
>habitudes,
>> en vrai une fois que tu le sais ça va vite a prendre en compte. Et
>faut
>> vérifier tes scripts au cas où.
>>
>> Je serais moins virtulent avec systemd, si ce n'était qu'un système
>> d'init. Le problème c'est que ses développeurs veulent le faire
>grossir en
>> fonctionnalités avant même de savoir faire booter un système Linux
>> correctement. C'est fâcheux, vraiment. C'est avant tout une question
>de
>> confiance dans le produit fini et en l'état, je suis incapable de
>prédire
>> que ma prod tournera correctement (ni même démarrera) avec systemd.
>> Accessoirement, je préfère les scripts d'init que je peux facilement
>> débugger alors qu'avec systemd si quelque chose ne démarre pas, je
>peux me
>> brosser pour avoir les détails qui m'intéressent.
>>
>> Après, je dis pas que y'a des choses pratiques dans systemd,
>notamement :
>> - Les scripts d'init faciles à faire
>> - L'utilisation de cgroups pour chaque daemon lancé
>> - La gestion de

Re: [FRsAG] Un installer lamp automatique pour Debian 8

2016-12-09 Par sujet Alexandre Legrix 
Hello

Pour résumer c'etait mieux avant concernant, le système d'init !
Par contre je ne vois pas l’intérêt d'installer automatiquement un Lamp
avec un script Bash maintenant que tout peut être fait très proprement avec
Ansible / puppet / chef !

Un fidèle utilisateur qui n'a pas du tout aimé systemd et qui utilise
openRC tous les jours, et qui n'aime pas du tout pulseaudio 

Amicalement
Alexandre

Le 9 décembre 2016 à 10:50, Benjamin Boudoir 
a écrit :

> Le 08/12/2016 19:21, Mrjk a écrit :
>
>> Salut,
>>
>> Loin de moi de vouloir relancer un troll qui devient vieux comme le
>> monde à ce stade, mais que reproche-tu concrètement à sytemd? C'est le
>> point de vue de l'admin qui fait de la prod qui m’intéresse (je ne
>> sais pas si tu es dans ce cas).
>>
>> En ce qui me concerne, et étant sysadmin, je trouve que ça a apporté
>> un grand confort, surtout quand on utilise des outils du type
>> Ansible/Puppet sur différentes plateforme. Une interface pour tous les
>> masteriser. J'ai encore du mal à comprendre ce que l'on peut reprocher
>> a systemd.
>>
>
> Je suis sysadmin, j'utilise ansible et je n'ai encore jamais rien vu que
> systemd améliorait avec cet outil. J'ai un playbook qui réinstalle sysv au
> lieu de systemd sur toutes les machines que l'on gère.
>
> Les raisons de mon désamour de systemd sont très nombreuses et je vais la
> résumer en quelques points :
> - systemd est incapable de faire démarrer une machine dans toutes les
> conditions (notamment l'utilisation de FS en réseau / tmpfs / RO)
> - systemd peut avoir des problèmes pour éteindre certaines machines (je
> l'ai déjà retrouver à ne pas réussir à démonter des points montés en réseau
> avec un timeout de... 5 minutes. Par point de montage. 2h de down pour une
> upgrade de kernel ça fait super mal quand même, ça va que c'était que pour
> de l'interne)
> - systemd est peut-être plus modulaire que beaucoup d'anti le disent, dans
> les faits il l'est beaucoup moins que Lennart Poettring veut bien le faire
> croire et beaucoup de distribs se retrouvent presques forcées d'intégrer
> des extensions à systemd qui sont au mieux inutiles, au pire dangereuses
> (genre systemd-resolvd)
> - systemd casse des features du kernel (chroot, LXC, terminaux virtuels,
> ...) et ses développeurs refusent de corriger leur code
> - systemd rend plus complexe l'écriture de scripts (start / stop / restart
> / status ne retournent pas d'état, les commandes retournent leur résultats
> dans un pager par défaut, etc.)
> - BEAUCOUP de surprises sur des binaires usuels qui changent de
> comportement (genre halt qui n'éteint plus électriquement une machine)...
> Même si, j'avoue que c'est juste chiant parce que ça casse les habitudes,
> en vrai une fois que tu le sais ça va vite a prendre en compte. Et faut
> vérifier tes scripts au cas où.
>
> Je serais moins virtulent avec systemd, si ce n'était qu'un système
> d'init. Le problème c'est que ses développeurs veulent le faire grossir en
> fonctionnalités avant même de savoir faire booter un système Linux
> correctement. C'est fâcheux, vraiment. C'est avant tout une question de
> confiance dans le produit fini et en l'état, je suis incapable de prédire
> que ma prod tournera correctement (ni même démarrera) avec systemd.
> Accessoirement, je préfère les scripts d'init que je peux facilement
> débugger alors qu'avec systemd si quelque chose ne démarre pas, je peux me
> brosser pour avoir les détails qui m'intéressent.
>
> Après, je dis pas que y'a des choses pratiques dans systemd, notamement :
> - Les scripts d'init faciles à faire
> - L'utilisation de cgroups pour chaque daemon lancé
> - La gestion de daemons utilisateurs
>
> Cependant, c'est rien qui n'ait pas déjà été fait ailleurs de façon plus
> propre. Partant de là, j'ai du mal à comprendre que systemd ait été autant
> poussé en avant alors qu'il casse plus de choses qu'il n'en corrige tout en
> retirant aux admins la possibilité de contourner les problèmes.
>
> Note; C'est le point de vue qui m’intéresse, je cherche pas à
>> démontrer que systemd est le meilleur.
>>
>
> Pour le coup, je tiens à dire que j'ai vraiment tenté d'utiliser systemd.
> Malgré le fait que je le trouvais dégeulasse par design, je me suis quand
> même dit que ça pouvait pas être si mal que ça si Debian l'intégrait par
> défaut :
> - Sur mes postes persos, 4 machines sur 5 ne démarraient plus, la dernière
> mettait plus de temps à démarrer.
> - En prod, le playbook ansible est assez récent (4 mois d'après git), il
> fait suite aux multiples problèmes qu'on a pu rencontrer au fur et à mesure
> (et quand je dis "multiple", c'est en grande partie parce qu'on a rarement
> eu le même plusieurs fois, rien qu'écrire de la doc sur ce que cassait
> systemd à nécessité un boulot de dingue, vraiment). Au début on repassait
> sous sysv uniquement les machines où systemd nous posait de gros problèmes.
> Puis on s'est rendu compte que c'était plus de la moitié de nos setups

Re: [FRsAG] Un installer lamp automatique pour Debian 8

2016-12-09 Par sujet Benjamin Boudoir 

Le 08/12/2016 19:21, Mrjk a écrit :

Salut,

Loin de moi de vouloir relancer un troll qui devient vieux comme le
monde à ce stade, mais que reproche-tu concrètement à sytemd? C'est le
point de vue de l'admin qui fait de la prod qui m’intéresse (je ne
sais pas si tu es dans ce cas).

En ce qui me concerne, et étant sysadmin, je trouve que ça a apporté
un grand confort, surtout quand on utilise des outils du type
Ansible/Puppet sur différentes plateforme. Une interface pour tous les
masteriser. J'ai encore du mal à comprendre ce que l'on peut reprocher
a systemd.


Je suis sysadmin, j'utilise ansible et je n'ai encore jamais rien vu que 
systemd améliorait avec cet outil. J'ai un playbook qui réinstalle sysv 
au lieu de systemd sur toutes les machines que l'on gère.


Les raisons de mon désamour de systemd sont très nombreuses et je vais 
la résumer en quelques points :
- systemd est incapable de faire démarrer une machine dans toutes les 
conditions (notamment l'utilisation de FS en réseau / tmpfs / RO)
- systemd peut avoir des problèmes pour éteindre certaines machines (je 
l'ai déjà retrouver à ne pas réussir à démonter des points montés en 
réseau avec un timeout de... 5 minutes. Par point de montage. 2h de down 
pour une upgrade de kernel ça fait super mal quand même, ça va que 
c'était que pour de l'interne)
- systemd est peut-être plus modulaire que beaucoup d'anti le disent, 
dans les faits il l'est beaucoup moins que Lennart Poettring veut bien 
le faire croire et beaucoup de distribs se retrouvent presques forcées 
d'intégrer des extensions à systemd qui sont au mieux inutiles, au pire 
dangereuses (genre systemd-resolvd)
- systemd casse des features du kernel (chroot, LXC, terminaux virtuels, 
...) et ses développeurs refusent de corriger leur code
- systemd rend plus complexe l'écriture de scripts (start / stop / 
restart / status ne retournent pas d'état, les commandes retournent leur 
résultats dans un pager par défaut, etc.)
- BEAUCOUP de surprises sur des binaires usuels qui changent de 
comportement (genre halt qui n'éteint plus électriquement une 
machine)... Même si, j'avoue que c'est juste chiant parce que ça casse 
les habitudes, en vrai une fois que tu le sais ça va vite a prendre en 
compte. Et faut vérifier tes scripts au cas où.


Je serais moins virtulent avec systemd, si ce n'était qu'un système 
d'init. Le problème c'est que ses développeurs veulent le faire grossir 
en fonctionnalités avant même de savoir faire booter un système Linux 
correctement. C'est fâcheux, vraiment. C'est avant tout une question de 
confiance dans le produit fini et en l'état, je suis incapable de 
prédire que ma prod tournera correctement (ni même démarrera) avec 
systemd. Accessoirement, je préfère les scripts d'init que je peux 
facilement débugger alors qu'avec systemd si quelque chose ne démarre 
pas, je peux me brosser pour avoir les détails qui m'intéressent.


Après, je dis pas que y'a des choses pratiques dans systemd, notamement 
:

- Les scripts d'init faciles à faire
- L'utilisation de cgroups pour chaque daemon lancé
- La gestion de daemons utilisateurs

Cependant, c'est rien qui n'ait pas déjà été fait ailleurs de façon plus 
propre. Partant de là, j'ai du mal à comprendre que systemd ait été 
autant poussé en avant alors qu'il casse plus de choses qu'il n'en 
corrige tout en retirant aux admins la possibilité de contourner les 
problèmes.



Note; C'est le point de vue qui m’intéresse, je cherche pas à
démontrer que systemd est le meilleur.


Pour le coup, je tiens à dire que j'ai vraiment tenté d'utiliser 
systemd. Malgré le fait que je le trouvais dégeulasse par design, je me 
suis quand même dit que ça pouvait pas être si mal que ça si Debian 
l'intégrait par défaut :
- Sur mes postes persos, 4 machines sur 5 ne démarraient plus, la 
dernière mettait plus de temps à démarrer.
- En prod, le playbook ansible est assez récent (4 mois d'après git), il 
fait suite aux multiples problèmes qu'on a pu rencontrer au fur et à 
mesure (et quand je dis "multiple", c'est en grande partie parce qu'on a 
rarement eu le même plusieurs fois, rien qu'écrire de la doc sur ce que 
cassait systemd à nécessité un boulot de dingue, vraiment). Au début on 
repassait sous sysv uniquement les machines où systemd nous posait de 
gros problèmes. Puis on s'est rendu compte que c'était plus de la moitié 
de nos setups et on a préféré jouer la carte de la sécurité.



--
MrJK
GPG: https://jeznet.org/jez.asc


--
Benjamin Boudoir
___
Liste de diffusion du FRsAG
http://www.frsag.org/

[FRsAG] [Systemd] Un installer lamp automatique pour Debian 8

2016-12-09 Par sujet Remy Dernat 

Bonjour,

On va éviter de lancer le troll, même si c'est 'dredi, mais 
personnellement, même si je trouve que la couche de gestion apportées 
par systemd est pratique, on se retrouve souvent à démêler des problèmes 
qu'on avait pas avant, et surtout, souvent plus complexes (ça me 
rappelle d'ailleurs un peu le passage de LILO à GRUB à l'époque (*)). 
Bref, notre ami Lennart Poettering a juste oublié que sous Linux, il 
fallait faire KISS (https://fr.wikipedia.org/wiki/Principe_KISS). Même 
si du point de vue utilisateur, oui, c'est plus simple...


My 2 cts,

Rémy

(*) plus de capacité, gestion simplifiée, mais du point de vue du cœur 
du système et de son fonctionnement, c'est en réalité bcp plus complexe.


Le 08/12/2016 à 19:21, Mrjk a écrit :

Salut,

Loin de moi de vouloir relancer un troll qui devient vieux comme le
monde à ce stade, mais que reproche-tu concrètement à sytemd? C'est le
point de vue de l'admin qui fait de la prod qui m’intéresse (je ne
sais pas si tu es dans ce cas).

En ce qui me concerne, et étant sysadmin, je trouve que ça a apporté
un grand confort, surtout quand on utilise des outils du type
Ansible/Puppet sur différentes plateforme. Une interface pour tous les
masteriser. J'ai encore du mal à comprendre ce que l'on peut reprocher
a systemd.

Note; C'est le point de vue qui m’intéresse, je cherche pas à
démontrer que systemd est le meilleur.
--
MrJK
GPG: https://jeznet.org/jez.asc


Le 8 décembre 2016 à 01:16, Guillaume Tournat  a écrit :

J'ai développé une allergie à systemd
Mais ça va mieux depuis que j'ai trouvé un howto pour remettre sysvinit sur 
debian8 ;-)



Le 7 déc. 2016 à 23:40, Bruno Pagani  a écrit :


Le 07/12/2016 à 21:40, Christophe Casalegno (DN) a écrit :

Bon pour le coup, on va voir si ça passionne :
https://twitter.com/Brain0verride/status/806598323830456320

une install ntpd est de toute manière plus rapide que taper dans la
cron, ça c'est sur :)

amicalement,

systemd-timesyncd :p

Bruno

___
Liste de diffusion du FRsAG
http://www.frsag.org/

___
Liste de diffusion du FRsAG
http://www.frsag.org/

___
Liste de diffusion du FRsAG
http://www.frsag.org/


--
Rémy Dernat
Ingénieur d'Etudes
MBB/ISE-M

___
Liste de diffusion du FRsAG
http://www.frsag.org/