Bonjour à tous : pour ceux que ça intéresse, j'ai mis à disposition un installer automatique apache, php, mysql pour Debian 8. C'est du shell,facile à personnaliser.
Il est fondé sur des bases très simples qui lui permettent de s'installer un peu n'importe où, il est en constante évolution et bien entendu gratuit. N'hésitez pas à m'envoyer vos feedbacks, bugs rencontrés, etc. !
Pour avoir la liste des features en cours et le tester : https://www.bit.ly/brainpali
amicalement,
Le 07/12/2016 à 19:39, Christophe Casalegno (DN) a écrit :
Bonjour à tous : pour ceux que ça intéresse, j'ai mis à disposition un installer automatique apache, php, mysql pour Debian 8. C'est du shell,facile à personnaliser.
Il est fondé sur des bases très simples qui lui permettent de s'installer un peu n'importe où, il est en constante évolution et bien entendu gratuit. N'hésitez pas à m'envoyer vos feedbacks, bugs rencontrés, etc. !
Pour avoir la liste des features en cours et le tester : https://www.bit.ly/brainpali
amicalement,
Hello,
Pour ce genre de chose désormais j'utilise des outils qui permettent de faire ce genre de chose à grande échelle... au taff, j'utilise "ansible" Il y a même un repo (Ansible Galaxy) avec plein de gens qui écrivent des rôles dont on peut s'inspirer...
Néanmoins quelques remarques, au passage à propos de ton script : - Ton script fonctionne-t-il quelque soit la LANG positionnée ? - Pourquoi modifier ds ta conf ssh à PermitRootLogin à yes ? J'espère que ton mot de passe est béton et que ton serveur n'est pas sur internet... - Pourquoi utiliser ntpdate ds un cron pour ta mise à l'heure ? Utilise plutôt ntpdate au démarrage + le démon ntpd, c'est mieux - pure-ftpd sur un serveur ? C'est pas tip-top sur un serveur surtout depuis que l'on peut chrooter sftp (mais au taff je me bas aussi contre ça) - attention si tu rebootes ton serveur, les produits ne démarreront pas automatiquement... il faut probablement que tu ajoutes des update-rc.d à ton script (ou des systemctl enable xxx) - pourquoi forcer la sortie d'exécution de ton script à 0 ? D'ailleurs tu ne trappes pas bcp les codes retours de tes commandes...
JYL
Pour ce genre de chose désormais j'utilise des outils qui permettent de faire ce genre de chose à grande échelle... au taff, j'utilise "ansible" Il y a même un repo (Ansible Galaxy) avec plein de gens qui écrivent des rôles dont on peut s'inspirer...
Hello, pas les mêmes objectifs, pour ça on utilise puppet, aucun intérêt pour un quidam qui veut déployer son vps chez ovh ou online.
- Ton script fonctionne-t-il quelque soit la LANG positionnée ?
D'après l'absence de retour que j'ai malgré de nombreuses exécution aux usa, je dirais "sans doute", je vais cependant vérifier ce point. Cependant, tout l'intérêt d'un script est justement de l'adapter à ses propres besoins... ou envies
- Pourquoi modifier ds ta conf ssh à PermitRootLogin à yes ? J'espère
que ton mot de passe est béton et que ton serveur n'est pas sur internet...
Le mot de passe est généré automatiquement par le script, tu peux toujours essayer de le bruteforcer par internet : il va te falloir longtemps (quelques siècles), beaucoup d'ips (à cause de Fail2ban entre autre), et que la personne n'est pas changé le port par défaut (ce que permet le script en standard via ex : -s 44232 installera ssh sur ce port).
Ce n'est donc clairement pas la même fréquence de test qu'avec un John the reaper entre de s'amuser avec une Geforce 1080 via openCL
J'administre plusieurs milliers de serveurs bastions sur internet avec un ssh (et précedemment telnet) ouvert en mode password sans incident sécurité lié au pass. Il faut juste respecter quelques règles comme http://www.christophe-casalegno.fr/2007/01/30/petit-point-sur-les-strategies... mais il y en a d'autres.
- Pourquoi utiliser ntpdate ds un cron pour ta mise à l'heure ?
Utilise plutôt ntpdate au démarrage + le démon ntpd, c'est mieux
En parlant de sécurité, disons que le démon ntpd a eu sa phase d'utilisation pour faire du ddos udp, même s'il est toujours possible de positionner des filtres adéquats, l'objectif est de rester simple.
- pure-ftpd sur un serveur ? C'est pas tip-top sur un serveur surtout
depuis que l'on peut chrooter sftp (mais au taff je me bas aussi contre ça)
Le protocole ftp reste le plus utilisé pour publier un site aujourd'hui, rien en effet ne t'empêche d'utiliser sftp (faut bidouiller un minimum pour le chrooter correctement et surtout qu'il ne puisse pas servir à créer des tunnels ssh), ou ftps (il est supporté par pure-ftpd d'ailleurs).
J'ai fais le choix de pure-ftpd car c'est un soft qu'on a eu à auditer en pentest plusieurs fois, je trouve sa conception robuste (comme pour vsftpd) et dans ma "philo".
- attention si tu rebootes ton serveur, les produits ne démarreront
pas automatiquement... il faut probablement que tu ajoutes des update-rc.d à ton script (ou des systemctl enable xxx)
Quels produits ?
- pourquoi forcer la sortie d'exécution de ton script à 0 ? D'ailleurs
tu ne trappes pas bcp les codes retours de tes commandes...
Les tests, ça vient(dra) après, bien bien après, même si j'en ai mis 2 ou 3 de base. L'objectif est seulement de permettre à un quidam de prendre un serveur chez l'hébergeur de son choix, même si ce n'est pas chez moi, et avoir une stack lamp relativement propre sans rien connaître. Si tu sais déjà installer ton stack, tu as probablement déjà tes scripts
amicalement,
-- Christophe Casalegno http://www.christophe-casalegno.com
Bonsoir,
On 07/12/2016 20:34, Christophe Casalegno (DN) wrote:
- Pourquoi utiliser ntpdate ds un cron pour ta mise à l'heure ?
Utilise plutôt ntpdate au démarrage + le démon ntpd, c'est mieux
En parlant de sécurité, disons que le démon ntpd a eu sa phase d'utilisation pour faire du ddos udp, même s'il est toujours possible de positionner des filtres adéquats, l'objectif est de rester simple.
ntpdate en cron, c'est quand même un peu violent. Certains daemons n'apprécient pas du tout les sautes de temps : Dovecot par exemple, qui se suicide :) quand il voit qu'il y a soudainement une trop grosse différence de temps en cours de fonctionnement (essaie, le log avant le kill est assez amusant).
Fabien
ntpdate en cron, c'est quand même un peu violent. Certains daemons n'apprécient pas du tout les sautes de temps : Dovecot par exemple, qui se suicide :) quand il voit qu'il y a soudainement une trop grosse différence de temps en cours de fonctionnement (essaie, le log avant le kill est assez amusant).
Voilà pourquoi j'utilise encore courrier :-D. D'ailleurs tu viens de me donner une idée sur une nouvelle approche pentest pour le coup. Il fait quoi, il ne coupe que la connexion en cours, ou il segfaulte carrément ?
Pour le temps, avant je jouais avec clockspeed, avec une satisfaction mitigée. Je trouve qu'un ntpdate récurrent pour du lamp, ça fait le taf, d'autant plus que les corrections sont pour le coup, ultra minimes.
amicalement,
On 07/12/2016 21:34, Christophe Casalegno (DN) wrote:
ntpdate en cron, c'est quand même un peu violent. Certains daemons n'apprécient pas du tout les sautes de temps : Dovecot par exemple, qui se suicide :) quand il voit qu'il y a soudainement une trop grosse différence de temps en cours de fonctionnement (essaie, le log avant le kill est assez amusant).
Voilà pourquoi j'utilise encore courrier :-D. D'ailleurs tu viens de me donner une idée sur une nouvelle approche pentest pour le coup. Il fait quoi, il ne coupe que la connexion en cours, ou il segfaulte carrément ?
Il s'arrête complètement : http://dovecot.dovecot.narkive.com/ud92gPCI/time-just-moved-backwards
Fabien
Il s'arrête complètement : http://dovecot.dovecot.narkive.com/ud92gPCI/time-just-moved-backwards
Fabien
Proprement avec un -TERM, ou autrement ? Si t'as un lien vers un trace qqpart, je suis preneur :)
amicalement,
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,
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
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 bruno.pagani@ens-lyon.org 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/
Le 08/12/2016 à 07:16, Guillaume Tournat a écrit :
Mais ça va mieux depuis que j'ai trouvé un howto pour remettre sysvinit sur debian8 ;-)
'tégriste !
Fais-voir ce HOWTO ?
J.
Bonjour chez toi.
Bonjour
Le 08/12/2016 17:52, Jacques Lav!gnotte. a écrit :
Le 08/12/2016 à 07:16, Guillaume Tournat a écrit :
Mais ça va mieux depuis que j'ai trouvé un howto pour remettre sysvinit sur debian8 ;-)
'tégriste !
Fais-voir ce HOWTO ?
C'est dans la doc officielle ;-) https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.en... https://wiki.debian.org/fr/systemd#Installation_sans_systemd
salut Jacques
http://without-systemd.org/wiki/index.php/How_to_remove_systemd_from_a_Debia...
A+
Le 8 déc. 2016 à 17:52, Jacques Lav!gnotte. jacques@lavignotte.org a écrit :
Le 08/12/2016 à 07:16, Guillaume Tournat a écrit :
Mais ça va mieux depuis que j'ai trouvé un howto pour remettre sysvinit sur debian8 ;-)
'tégriste !
Fais-voir ce HOWTO ?
J.
Bonjour chez toi.
-- GnuPg : C8F5B1E3 WeUsePGP Because privacy matters http://weusepgp.info/ _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
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 guillaume@ironie.org 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 bruno.pagani@ens-lyon.org 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/
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 guillaume@ironie.org 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 bruno.pagani@ens-lyon.org 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/
Pour contribuer au débat, je suis entierement d'accord avec le constat de Remy Dernat. Je rajouterai qu'une partie du probleme a mon sens est l'espece de monstre a mi chemin entre sysvinit et systemd qui a été pondu par Debian/Ubuntu... Ca ne ressemble a rien, c'est encore plus compliqué a gerer... Autant un Archlinux se gere "plus" facilement en pure systemd, alors qu'une débian avec des scripts d'init et du systemd va etre l'enfer entre ce qui est executé quand tu run a la mano ou quand tu reboot ton serveur...
Cordialement
Le 9 décembre 2016 à 09:34, Remy Dernat remy.dernat@univ-montp2.fr a écrit :
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 guillaume@ironie.org 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 bruno.pagani@ens-lyon.org 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/
Très simple à gérer de mon côté, il suffit de purge systemd :)
On 09/12/2016 10:39, Sébastien FOUTREL wrote:
Je rajouterai qu'une partie du probleme a mon sens est l'espece de monstre a mi chemin entre sysvinit et systemd qui a été pondu par Debian/Ubuntu... Ca ne ressemble a rien, c'est encore plus compliqué a gerer...
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.
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
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 benjamin+frsag@boudoir.name 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 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/
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 alex@bragonux.net 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 benjamin+frsag@boudoir.name 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 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/
-- Alexandre
Liste de diffusion du FRsAG http://www.frsag.org/
Pour le coup je parlais de machines perso en dehors du cadre professionnel.
Le 9 déc. 2016 12:57, "Colin Brigato" colin@brigato.fr 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 http://www.typeapp.com/r Le 9 déc. 2016, à 11:53, Alexandre Legrix alex@bragonux.net 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 <benjamin+frsag@boudoir.name
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 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/
Liste de diffusion du FRsAG http://www.frsag.org/
Confirmant donc que nul part ou systemd passe l’adminsys ne trouve ça classe. Clairement, OpenRC + ansible pour du perso et on est bien.
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-bounces@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.
Le 9 décembre 2016 à 13:30, VAILLEAU Olivier Olivier.VAILLEAU@ch-sevrey.fr a écrit :
Dans la série "c'est mon choix"...
Pareil, moi je n'ai rien contre bien Systemd, mais chuuuut :)
Bonjour à tous,
On 12/09/2016 02:03 PM, Jonathan Leroy wrote:
Pareil, moi je n'ai rien contre bien Systemd, mais chuuuut :)
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
Hello C'est vendredi c'est kdo : http://linuxfr.org/news/systemd-l-init-martyrise-l-init-bafoue-mais-l-init-l... 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-bounces@frsag.org] De la part de Francois Lafont Envoyé : vendredi 9 décembre 2016 15:04 À : French SysAdmin Group frsag@frsag.org 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 chuuuut :)
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/
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.
Le Fri, Dec 09, 2016 at 02:09:35PM +0100, Luc Didry [luc@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.
Le 9 décembre 2016 à 14:59, Dominique Rousseau d.rousseau@nnx.com 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.
Aahhaha. Et la gestion des logs, et la gestion des montages et surement d'autres choses :D Regarde aussi ce qui se passe quand tu veux demarrer un service et que systemd ouvre une socket reseau avant meme que le demon soit lancé :D Essaye de faire un swapoff -a et regarde ce qu'il se passe au bout de quelques secondes ou minutes en fonction de ce que va trapper systemd. Malheureusement comme dit plus tot, systemd c'est parti d'un bon sentiment mais si on avait voulu bosser sur macosX on aurait fait ce choix. Dorenavant on a plus vraiment le choix...
Le 9 décembre 2016 à 15:27, Jonathan Leroy jonathan@unsigned.inikup.com a écrit :
Le 9 décembre 2016 à 14:59, Dominique Rousseau d.rousseau@nnx.com 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/
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.
Hello,
Le 09/12/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)
https://www.debian-fr.org/t/pb-demarrage-suite-maj-wheezy-jessie-a-cause-reg... pour une solution
- 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)
Semble être ça, non ? Effectivement il semble qu'il y ait un pb, mais il y a des pistes de solution https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798314
- 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)
Est-ce obligatoire ? Des faits, des liens ?
- systemd casse des features du kernel (chroot, LXC, terminaux
virtuels, ...) et ses développeurs refusent de corriger leur code
Je ne sais pas quel problème tu rencontres exactement, mais pour le chroot, tu peux faire des chroot assez facilement avec systemd directement : http://0pointer.de/blog/projects/changing-roots.html
Tu dois parler de ça pour LXC ? https://wiki.debian.org/fr/LXC#Incompatibilit.2BAOk-s_avec_systemd
C'est quoi le pb des terminaux virtuels ?
- 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.)
echo $? te donne un return code normalement, non ?
- 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ù.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753830
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.
Read the sources, Luke ;-) OK elle est facile et c'est clair qu'un script shell c'est plus simple à écrire... mais faire des scripts shells merdiques par rapport à script init de qq lignes, il y a matière à débat
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
Ah quand même un peu d'objectivité ;-)
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.
Je me demande si tes pbs ne seraient pas plus du au fait que chez Debian, ils ne sont pas partis tous dans la même direction par rapport à systemd, au contraire de RedHat (après le dev principal de systemd bosse chez RH si j'ai bien suivi)... Si je pousse un peu ton raisonnement tu devrais aussi rester sous un kernel 2.4 parce que le kernel 2.6.9 était bien pourri, pour autant désormais j'entends plus bcp de personnes critiquer les versions plus récentes.
Cdlt,
JYL
Le 10/12/2016 23:27, Jean-Yves LENHOF a écrit :
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)
https://www.debian-fr.org/t/pb-demarrage-suite-maj-wheezy-jessie-a-cause-reg... pour une solution
La solution la plus simple est quand même d'utiliser un init qui sait démarrer :-) Une fois que ton desktop démarre plus, t'as plus tellement accès à ce genre de ressources.
- 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)
Semble être ça, non ? Effectivement il semble qu'il y ait un pb, mais il y a des pistes de solution https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798314
Effectivement, c'est un des bugs rencontré.
- systemd casse des features du kernel (chroot, LXC, terminaux
virtuels, ...) et ses développeurs refusent de corriger leur code
Je ne sais pas quel problème tu rencontres exactement, mais pour le chroot, tu peux faire des chroot assez facilement avec systemd directement : http://0pointer.de/blog/projects/changing-roots.html
Je t'avoue que j'ai pas tellement envie de lire ça, donc j'ai juste cherché ce que je voulais : systemd-nspawn c'est le trashfix de systemd parce qu'ils ont cassé chroot. J'ai plus les détails de ce qui était
Tu dois parler de ça pour LXC ? https://wiki.debian.org/fr/LXC#Incompatibilit.2BAOk-s_avec_systemd
Tiens, oui, y'a aussi. Non, je parle du fait que si tu as dbus dans un conteneur LXC sur un hôte avec systemd, tu peux balancer des commandes à ton PID 1 depuis ton conteneur. J'ai eu plusieurs conteur qui ont éteint électriquement leur hôte parce qu'un shutdown avait été fait dessus :-)
C'est quoi le pb des terminaux virtuels ?
https://bugzilla.redhat.com/show_bug.cgi?id=817186
- 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.)
echo $? te donne un return code normalement, non ?
Oui, toujours 0. Bon, là j'avoue que j'ai appris plus tard que ça dépend du type de service (mais j'ai pas retrouvé mon lien). En tout cas, sous Debian j'ai eu plusieurs scripts qui cassaient après une utilisation de type "service service reload && faituntruc" parce que le service n'avait pas reload / restart / stop / start.
Exemple : http://serverfault.com/questions/751030/systemd-ignores-return-code-while-st...
- 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ù.
L'avis qu'on a de si oui ou non c'est un comportement intelligent ou pas ne doit pas entrer en ligne de compte. A partir du moment ou des tas de softs reposent dessus, tu peux pas juste changer silencieusement le comportement d'un binaire. C'est quoi déjà un des arguments des pro-systemd ? Ah oui, c'est une API unique pour toutes les distribs.... Mouais.
Surtout que bon, c'est pas comme si systemd trashait pas ses API régulièrement (genre systemd-sysv ou systemd-fstab). D'ailleurs, une unit de type mount c'est pas beaucoup plus chiant à écrire qu'une ligne de fstab, sérieusement ?
Je suis d'avis que l'init devrait être indépendant de l'API pour les couches hautes.
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.
Read the sources, Luke ;-) OK elle est facile et c'est clair qu'un script shell c'est plus simple à écrire... mais faire des scripts shells merdiques par rapport à script init de qq lignes, il y a matière à débat
Bah "read the sources" dans un script d'init en shell c'est vachement plus simple que dans un ensemble de binaires bloatés que tu peux pas toujours mettre à jour ;-)
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.
Je me demande si tes pbs ne seraient pas plus du au fait que chez Debian, ils ne sont pas partis tous dans la même direction par rapport à systemd, au contraire de RedHat (après le dev principal de systemd bosse chez RH si j'ai bien suivi)...
C'est rigolo parce que plus tôt :
- 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)
Est-ce obligatoire ? Des faits, des liens ?
Si je pousse un peu ton raisonnement tu devrais aussi rester sous un kernel 2.4 parce que le kernel 2.6.9 était bien pourri,
Rien à voir. Entre une upgrade et un changement complet d'un système pour un nouveau qui n'améliore pas l'existant. Aussi, la branche 2.4 a continuée d'être maintenue un bon moment alors que systemd ne maintient que sa master et ne supporte pas les vieux kernels... D'ailleurs, ils vont faire comment RHEL / CentOS alors qu'ils sont sensés supporter leurs distibs pendant 10+ ans ? ( https://access.redhat.com/support/policy/updates/errata/ )
pour autant désormais j'entends plus bcp de personnes critiquer les versions plus récentes.
Normal, on est retourné utiliser des inits capables de faire démarrer nos machines et les éteindre sans bugs ;-)
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 :-)
Le Wed, Dec 07, 2016 at 08:56:34PM +0100, Fabien Germain [fabien@klipz.fr] a écrit:
ntpdate en cron, c'est quand même un peu violent. Certains daemons n'apprécient pas du tout les sautes de temps : Dovecot par exemple, qui se suicide :) quand il voit qu'il y a soudainement une trop grosse différence de temps en cours de fonctionnement (essaie, le log avant le kill est assez amusant).
Ce que dovecot n'aime pas et le pousse a se suicider, c'est lorsqu'il remonte le temps. Et c'est meme dans leur wiki : http://wiki.dovecot.org/TimeMovedBackwards
-
Alexandre Legrix -
Benjamin Boudoir -
Bruno Pagani -
Christophe Casalegno (DN) -
Colin Brigato -
Colin J. Brigato
-
Dominique Rousseau -
Fabien Germain -
Francois Lafont -
frsag＠jack.fr.eu.org -
Frédéric VANNIÈRE -
Guillaume Tournat -
Jacques Lav!gnotte. -
Jean-Yves LENHOF -
Jonathan Leroy -
Luc Didry -
Mrjk -
Pierre-Olivier Grangaud -
Remy Dernat -
Sébastien FOUTREL -
VAILLEAU Olivier