Harry Poetter Lennart vient de publier un billet sur son blog pour démentir l'ensemble des mythes associés à systemd
http://0pointer.de/blog/projects/the-biggest-myths.html
Une argumentation solide, même si parfois on se demande d'où sortent certains mythes (fichiers de configuration binaires ?), parfois contradictoires ("systemd est pas fait pour la rapidité" suivi d'un "un démarrage rapide c'est bien pour les sysadmins").
Un peu de mauvaise foi, avec les *BSD qui reprochent surtout l'intégration poussée de systemd aux environnements de bureaux. Effectivement, ils s'en branlent de la partie démarrage, les variantes de rc.d modernes étant bien plus avancés que les ersatz de init sysV
Il aurait été intéressant de normaliser l'API D-Bus de systemd (voire de la rendre indépendante de celui-ci) et régler ce différend de manière apaisée (étrangement, c'est ce que l'une des parties propose et l'autre demande, un magnifique dialogue de sourds !)
Ça casse pas mal d'idées préconçues comme l'idée que systemd s'éloigne de la philosophie Unix. Le code de systemd que je vous invite à lire est extrêmement modulaire, chaque fonctionnalité (ou presque) est dans un daemon associé à un outil comme la gestion de noms d'hôtes. La gestion des services se fait par des liens symboliques, ceux-ci étant exposés dans un pseudo-FS.
De plus, est-ce que le but de GNU/Linux est de rester scotché à un modèle vieux de 40 ans (y compris, garder les bizarreries ou limitations originales) ou bien le faire évoluer. Le matériel, les utilisations ont évolué, donc il est normal de faire évoluer en conséquence la gestion des services.
# pas de contradictions me semble-t-il
Posté par jbbourgoin (site web personnel) . Évalué à 10.
Je ne crois pas qu'il y ait là contradiction. Le fait est que Systemd est rapide, même s'il n'a pas été conçu pour cela. Un argument consiste à dire que les sysadmins se moquent de la vitesse, et Lennart répond que ça n'est pas vrai, dans certains cas c'est utile. Donc même si Systemd n'a pas été conçu pour être rapide, il répond tout de même à ce besoin existant, puisqu'il l'est !
# rapidité, changement
Posté par WhiteCat . Évalué à 10.
Tu as mal compris. Il dit que systemd est rapide mais c'est un effet de bord lié à la conception de systemd. Et c'est finalement une bonne chose car la rapidité c'est important pour certains. ==> "Yes, systemd is fast […], but that's primarily just a side-effect of doing things right."
systemd n'a pas été fait juste parce que sysvinit est vieux et donc serait "has-been". systemd existe parce que selon eux, systemd améliore plein de choses par rapport aux autres system d'init. => "we eventually came to the conclusion that its design [il parle d'Upstart] was inherently flawed at its core"
[^] # Re: rapidité, changement
Posté par kadalka . Évalué à -8.
J'ai compris comme vous.
De plus, en gros, ce monsieur s'amuse à dire du mal de son concurrent, et il me donne l'impression qu'il se le permet parce que c'est son concurrent et pas autre chose…
UpStart c'est ubuntu et systemd c'est RedHat. Et comme ubuntu est numéro un…
Un manque d'objectivité à mon avis.
D'où ma question bête:
pourquoi une technologie qui existe depuis 2005 dont on dit tant de bien n'est toujours pas implémenté dans les distributions majeures ?
C'est forcément parce qu'il y a quelque chose qui cloche quelque part…
(Ni debian ni slackware ne veulent de ce machin! LOL)
Une des choses qui m'étonne c'est l'intégration de udev.
(ai-je mal lu ?)
Pour ceux qui n'y voient que du bien, j'aimerais qu'ils nous détaillent leur usage de ce truc au quotidien en prod.
(Je n'ai pas vu d'informations pertinentes sur le sujet mais je veux bien qu'on me donne des infos solides)
[^] # Re: rapidité, changement
Posté par Astaoth . Évalué à 7.
http://en.wikipedia.org/wiki/Systemd
On y voit :
Distributions majeures ayant systemd par défaut : Fedora, Mageia/Mandriva, openSUSE, Arch Linux (mine de rien, elle a sa communauté).
Distributions permettant d'installer systemd : Debian GNU/Linux, Gentoo
Distributions devant l'utiliser à l'avenir : Red Hat Enterprise Linux 7
Debian ne l'utilise pas par défaut, à cause de Debian/kFreeBSD, mais sa version Linux est déjà prête pour lui.
Quant à Slackware, c'est expliqué dans cet interview. Je prends le choix de Papat de ne pas intégrer systemd comme son avis personnel, et non comme une parole divine.
Emacs le fait depuis 30 ans.
[^] # Re: rapidité, changement
Posté par kadalka . Évalué à -4.
Oui je l'ai lu. (J'ai déjà vu depuis longtemps systemd sous linux: merci de nous le rappeler)
debian et ubuntu, ne l'implémentent pas, or ils sont les plus utilisés.
Mais Pat est le fondateur de Slackware donc je ne prends pas à la légère ce qu'il dit.
Gentoo est connu comme très solide et très sérieux.
Les comparaisons entre les différents systèmes d'init me démontre que systemd n'est pas forcément le bon choix, loin de là.
Lire ceci pour s'en convaincre : http://wiki.gentoo.org/wiki/Comparison_of_init_systems
Lire mon commentaire en dessous aussi
(je ne vais pas faire du copier coller parce que cela alourdirait)
[^] # Re: rapidité, changement
Posté par Maclag . Évalué à 10.
Debian ne le propose pas par défaut, mais il serait complètement faux de dire que Debian n'en veut pas!
Debian travaille sur un générateur de script init shell à la volée à partir de fichier de configuration systemd! L'idée étant que le script shell sera nécessaire pour les noyaux alternatifs, que la plupart des scripts sont identiques à l'exécutable cible près, sauf quelques exceptions pour lesquelles une maintenance dédiée sera à faire en dehors de systemd.
Bref, Debian s'oriente vers systemd mais plus dans une approche hybride. On s'attend certainement à ce qu'un grand nombre d'utilisateurs du noyau Linux passent à systemd sans pouvoir le mettre par défaut.
Enfin, rappelons que Debian ne se jette que rarement sur les nouvelles technologies, et particulièrement quand un problème de mâturité s'y pointe. Il suffit de voir que la suite kontact est toujours en 4.4 parce que la migration n'était, jusqu'à aujourd'hui au moins, pas totalement au point.
Il n'est pas impossible que Debian encourage à l'avenir la migration vers systemd sur les installations utilisant un noyau Linux.
Pour Ubuntu, qui était à l'origine de upstart (non?), je pourrais tout aussi bien les accuser de refuser systemd pour cause de syndrôme NIH. (c'est tellement facile de dire que "les autres n'en veulent pas parce que c'est pas bien").
[^] # Re: rapidité, changement
Posté par Misc (site web personnel) . Évalué à 3.
Scott explique pourquoi il a pas pris initng, launchd etc dans ce post :
http://netsplit.com/2006/08/26/upstart-in-universe/
Et moi, j'avais le sentiment que upstart a commencé comme projet à part ( au vue du vieux nom de domaine en .at ) avant de passer sous l'aile de Canonical. Mais vu que dans mon souvenir, il y a le fameux CLA, je doit sans doute avoir tout faux.
Il y a aussi eu des discussions pour l'intégration de systemd, voir une page de wiki ( https://wiki.ubuntu.com/systemd ), mais Canonical a choisi de garder Upstart ( http://www.iloveubuntu.net/ubuntu-1210-quantal-quetzal-continue-upstart-systemds-rumors-cleared ). La raison évoqué est les tests ( upstart possède une batterie de 12000 lignes de tests en C ), et le fait que upstart réponde plus à leurs besoins.
Tel que je vois la ou Canonical veux aller, c'est l'embarqué ( smartphone, tv ), et le cloud avec des bécanes jetables ( ie, les guests ). Et je pense que le concept de gestion d'événement s’intègre bien aussi avec le premier ( besoin de mobilité et d'une gestion dynamique ) qu'avec le second ( rajouter un file system en réseau via ceph, etc ).
Upstart a été utilisé pour chromeos ( donc un pc portable mobile ), pour le nokia n9 ( donc aussi un appareil mobile ), et sans doute dans Ubuntu Tv et le reste.
Ensuite, pour la partie cloud, ils sont partie sur juju plutôt que de l'intégrer ça directement dans l'OS via upstart, c'est un peu dommage ( et qu'on me dise pas "ça rends juju portable" car ça continue à utiliser des ppa à tout va ). La transparence réseau de upstart, ça aurait pu faire une sacré killer feature pour le système.
( sinon, upstart dépend de libNIH /o\ )
[^] # Re: rapidité, changement
Posté par zebra3 . Évalué à 7.
Source ?
En entreprise, je vois surtout du RHEL et SUSE.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: rapidité, changement
Posté par Albert_ . Évalué à 8.
Je vois essentiellement du RHEL ou debian pour les serveurs et du ubuntu pour le desktop.
J'ai vu un temps du Fedora pour le desktop mais cela a disparu vu le merdier que c'etait entre chaque version, c'est amusant de bosser sur un truc de test mais sauf pour les utilisateurs qui veulent juste un truc qui marche sans avoir a tout bidouiller a chaque nouvelle version. Et d'apres Alan Cox la dernier version F18 est une grande "reussite"…
[^] # Re: rapidité, changement
Posté par gnumdk (site web personnel) . Évalué à 6.
Dans l'administration, je vois surtout Debian…
[^] # Re: rapidité, changement
Posté par ckyl . Évalué à 5.
Vous avez surtout de super bon yeux pour les utiliser comme base pour en faire une généralité.
[^] # Re: rapidité, changement
Posté par gnumdk (site web personnel) . Évalué à 3.
Je crois pas que ma réponse était une généralité…
Mais bon, il faut savoir que contrairement au privé, la visibilité des serveurs dans l'administration est facile à connaitre… En gros, je peux dire sans me tromper que la majorité des collèges et lycées ont des serveurs sous Ubuntu LTS ;) (Solution EOLE).
[^] # Re: rapidité, changement
Posté par zebra3 . Évalué à 2.
Pareil, j'ai pas dit que c'était une généralité, j'ai juste fait part de ce que j'observe, et surtout la demande de source n'était absolument pas ironique.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: rapidité, changement
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
J'ai des doutes que dans le Cloud, ils n'aient que du RH…
Bref, il y a les statistiques sur les serveurs Web qui indiquent que Debian est pour le moment en tête (sur cette partie là).
[^] # Re: rapidité, changement
Posté par Misc (site web personnel) . Évalué à 3.
Alors d'une part, il y a d'autre fondateurs de distros qui postent parfois ici et la, et tu sembles prendre ça plus à la légère ce qu'ils disent ( enfin pareil, c'est un avis personnel, pas une parole divine ).
Et d'autre part, Patrick a un vision orienté vers son but, à savoir la maintenabilité par lui même de la distribution, et la simplicité extréme que ça requiert, quitte à ce que ça ne réponde pas au besoin de tout le monde.
Son refus de pam est un exemple, et pas grand monde ne va le suivre sur ce point, car même si pam a eu des débuts difficiles, ça reste relativement pratique dés que tu veux avoir un serveur ( comptes en ldap, kerberos ) ou si tu veux essayer de rivaliser avec du windows sur le poste client ( pareil, ldap, etc ). Ou de la sécurité ( authentification à 2 facteurs, lecteur d'empreinte digital ).
D'ailleurs, la gestion des processus par cgroups de systemd ( pour en revenir au sujet ) implique de dire à sshd de se "détacher" des processus utilisateurs pour éviter de les tuer lors d'un restart, et d'avoir son propre cgroups par utilisateur ( ce qui permet d'appliquer des quotas cpu/ram/etc par utilisateur via les cgroups, justement ). Et pour ça, le moyen le plus propre est de passer par pam, qui va voir au login qu'il y a un utilisateur et qui va le changer de cgroups.
Sans ça, tout les utilisateurs sont dans le cgroup de sshd, et se font donc tuer sans pitié en cas de restart du demon. ( il y a une méthode pour faire autrement, mais c'était tirer par les cheveux et j'ai oublié ).
Donc un passage à systemd serait sans doute aller à l'encontre de son objectif de garder pam hors de slackware ( sauf si ce n'est plus d'actualité, bien sur ).
[^] # Re: rapidité, changement
Posté par gouttegd . Évalué à 3.
Euh, moi je fais ça avec les outils de libcgroup (fourni en standard par Slackware), notamment cgrulesengd, ça fonctionne très bien. Si c’est l’autre méthode à laquelle tu pensais, en quoi est-elle « tirée par les cheveux » ?
[^] # Re: rapidité, changement
Posté par Misc (site web personnel) . Évalué à 3.
Bah, voila, une troisième méthode que je connaissait pas, et non, je parle en effet d'une autre façon de faire.
Mon coloc s'était plaint de devoir mettre "UsePAM yes" dans sa config, et j'avais fini par trouver un truc en lançant ssh à la demande via les sockets, ce qui fait 1 cgroup par connexion.
Par exemple, sur ma machine ( ou je fait ça pour économiser 3mo de ram afin de pouvoir continuer à lancer des gros trucs java pour remplir les 8G qui reste ), en lançant 2 connexion ssh, j'ai 2 entrées dans la sortie de systemctl :
Et chacune est dans son propre cgroup, ce qui fait qu'un restart du service ne tue rien.
Mais c'est pour moi un effet de bord du fonctionnement par socket plus qu'autre chose, donc je trouve ma méthode tiré par les cheveux.
[^] # Re: rapidité, changement
Posté par zebra3 . Évalué à 4.
Disons qu'elle est prête pour une installation basique, mais pas encore pour tous les usages que permettent Debian. Exemple tout con : la crypttab de Debian permet d'appeler des scripts pour déverrouiller un disque, mais Systemd ne gère pas encore ces options. Bon, il faut dire que Debian est la seule distribution à étendre la crypttab (avec ses dérivées).
Après, on peut tout de même se débrouiller avec un script en plus dans l'initrd (et c'est pour ce genre de trucs que j'aime Linux) mais c'est pas « juste installer un paquet ».
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# Non, systemd ne doit pas tout faire
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Chaque problème doit avoir une solution adaptée, respectons la philosophie unix!
Pour ça je conseille:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Non, systemd ne doit pas tout faire
Posté par Misc (site web personnel) . Évalué à 10.
Ouf, enfin un peu de bon sens. Le kernel n'est pas fait pour faire du nat, pour ça, il y a des démons en userspace qui existe ( comme natd sur os x ), et je vois vraiment pas pourquoi le code qui gère l’accès au disque est aussi stocké dans le même git que celui qui gère les cartes sons, y a quand même aucune synergie ou raison valable.
Faut arrêter de déconner, on a réussi à faire de la vidéo hors du kernel, on doit bien réussir à faire pareil pour le reste.
À ce rythme la, on va se retrouver à avoir directement des machines virtuelles dedans et trouver ça ultra cool.
( attention, ce post contient des sarcasmes préemptifs en vue de moquer des futures discussions qui vont arriver )
[^] # Re: Non, systemd ne doit pas tout faire
Posté par feth . Évalué à 8.
Hm, je te conseille les cartes son Soundblaster avec port IDE :-)
# Serveurs
Posté par Anonyme . Évalué à 9.
Étant donné que les BIOS des serveurs sont aussi rapide que des poulpes dans une marmite de glue, cet argument est à mon avis mauvais.
Il faut déjà trois heures aux serveurs pour arriver à l’initialisation de la carte RAID, encore trois heures pour démarrer les RAID. Je pense pas que gagner une minute au boot de l’OS soit vraiment quelque chose d’utile (comparé à tout le bordel que SystemD apporte).
[^] # Re: Serveurs
Posté par WhiteCat . Évalué à 3.
Tu aurais pu prendre la peine de lire tout son commentaire :
"And yes, I am aware that often it is the server firmware that costs the most time at boot-up, and the OS anyways fast compared to that, but well, systemd is still supposed to cover the whole bandwith (see above…), and no, not all servers have such bad firmware, and certainly not VMs and containers, which are servers of a kind, too."
Et puis… un bon administrateur utilise du RAID logiciel de toute façon.
[^] # Re: Serveurs
Posté par MTux . Évalué à 7.
Ah, pourquoi ?
Il me semble que le RAID matériel c'est très pratique.
Tu reçois l'alerte, tu visualise le disque en façade qui déconne, tu l'enlève, tu le remet, et ça repart (reconstruction automatique). De plus il y a le cache qui est indispensable si ton serveur doit tenir une grosse charge.
Ce n'est pas un troll c'est une simple question.
[^] # Re: Serveurs
Posté par Spack . Évalué à 10. Dernière modification le 27 janvier 2013 à 18:16.
En logiciel ça marche aussi.
L'un des problèmes du RAID matériel, c'est le vendor lock-in ou encore l'enfermement_propriétaire si ta carte RAID lâche, à moins de trouver la même carte, tu peux dire adieu à tes données. En logiciel, tu as plus de chances de pouvoir les récupérer.
Le cache peut aider tout comme apporter quelques surprises. Le système peut croire avoir écrit des données qui ne le sont pas réellement.
[^] # Re: Serveurs
Posté par ymorin . Évalué à 10.
Pire : même si tu trouves la même carte, encore faut-il que son micro-logiciel (aka
firmware) soit compatible. J'ai eu un cas à peu prés similaire, où, après la mise à jour dufirmware, la carte RAID ne reconnaissait plus les RAID assemblés avec le précédentfirmware, et voulait recréer les RAID (heureusement, j´avais un serveur avec le vieuxfirmware, j'ai pu récupérer et transférer les données).Par ailleurs, les PC grand-public dont le BIOS est censé gérer le RAID, ne sont qu´une vaste fumisterie : le BIOS émule le RAID, en effet, mais en volant des cycles du CPU (un peu comme les interruptions de gestion de l´énergie sur les portables).
Maintenant, je ne jure que par le RAID logiciel.
Hop,
Moi.
[^] # Re: Serveurs
Posté par Anonyme . Évalué à -6.
Taxer les gens de « mauvais admin » et utiliser la perte de données (suite à une défaillance matériel) comme justification c’est assez drôle !
[^] # Re: Serveurs
Posté par claudex . Évalué à 10.
Un admin qui débarque dans le datacenter et qui tire sur les serveurs à la kalachnikov sur les serveurs sous prétexte qu'il y a des backups, je n'appelle pas ça un bon admin, pourtant il y a des backups.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Serveurs
Posté par Misc (site web personnel) . Évalué à 10.
Perso, un mec qui a une kalach en état de marche et qui s'en sert, je suis pas sur que j'aurais vraiment de le contrarier en remettant en cause ses capacités. Je dit ça, je dit rien.
[^] # Re: Serveurs
Posté par Maclag . Évalué à 8.
Moi je l'emmerde, mais avant je mets des autocollants "ce serveur n'a aucune sauvegarde et je suis la seule personne au monde à connaître le mot de passe pour décrypter ses données!"
Mais surtout, moi je cours vite!
----------------> [ ]
[^] # Re: Serveurs
Posté par Misc (site web personnel) . Évalué à 6.
Le souci du raid logiciel, c'est qu'il est logiciel. IE, avant d'avoir grub2, je pense qu'il fallait magouiller pour booter directement sur un raid logiciel sans avoir un /boot séparé. Il y a aussi l’intégration avec la carte de management distante souvent vendu avec les serveurs, ce qui permet d'agir même quand le serveur est dans le pâté complet
L'avantage aussi du raid hardware, c'est que c'est grosso modo "techos pas cher"-friendly. Tu as ton alerte, tu as le disque qui clignote, tu dit au mec de remettre le disque en réserve, et voila. ( et je sais pas si le disque qui clignote est une feature standard des serveurs avec du raid soft ).
Enfin perso, moi, j'étais dans le camp des gens en faveur du raid soft quand on a eu la discussion à mon taf, mais j'irais pas qualifier les gens qui font du raid hard de mauvais admins. Si les cartes raids se vendent, c'est bien parce qu'il y a des gens qui achètent et qu'ils y trouvent leur compte
[^] # Re: Serveurs
Posté par totof2000 . Évalué à 0.
2eme inconvénient du RAID soft : SPOF. Il est toujours bon d'avoir 2 controleurs pour assurer une continuité de service.
[^] # Re: Serveurs
Posté par cellophane . Évalué à 4.
J'aurais dit le contraire.
Avec un RAID soft, il est facile d'avoir plusieurs contrôleurs. Ex, 4 disques en RAID 1+0 : 2 disques sur une carte, 2 disques sur une autre. Comment tu fais en RAID hard?
[^] # Re: Serveurs
Posté par feth . Évalué à 3.
Voire réplication transparente à travers le réseau : avec ZFS, il me semble qu'on peut ajouter des disques distants au pool.
[^] # Re: Serveurs
Posté par Misc (site web personnel) . Évalué à 2.
Ou Ceph, ou glusterfs.
Je suis pas sur que zfs fasse la transparence réseau. ( mais comme tout les ex produits Sun, ça fait sans doute tout y compris le café )
[^] # Re: Serveurs
Posté par totof2000 . Évalué à 3.
Oups, je voulais effectivement dire inconvénient du RAID Hard …
[^] # Re: Serveurs
Posté par zebra3 . Évalué à 2.
Tu le dis toi-même : « avant d'avoir grub2, il fallait… ». Bah voilà, on a grub2, problème réglé :-)
Question suivante ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Serveurs
Posté par oinkoink_daotter . Évalué à 1.
Juste pour le troll : comment je fais pour avoir grub2 sur mes sparc ?
[^] # Re: Serveurs
Posté par Misc (site web personnel) . Évalué à 3.
Visiblement, c'est dispo :
http://robertmh.wordpress.com/2009/07/18/grub-on-sparc/
[^] # Re: Serveurs
Posté par oinkoink_daotter . Évalué à 2.
Sur sparc pour ce genre de trucs, y a une vraie vraie marche entre dispo et "ça marche sur autre chose que la machine du developpeur".
Mais bon, je vais essayer pour remplacer silo.
[^] # Re: Serveurs
Posté par Misc (site web personnel) . Évalué à 1.
D’après ce que je lit ici et la, grub-ieee127 ne serait pas ce que tu veux ? ( la dernière sparc que j'ai vu, c'était à la poubelle y a 1 an, donc je suis plus très au courant de ce qu'il faut faire en dehors de "magouiller avec l'open firmware" ).
Mais si tu arrives à le faire marcher, je suis sur qu'un peu de doc pourrait aider.
[^] # Re: Serveurs
Posté par gnumdk (site web personnel) . Évalué à 2.
Surtout que c'est faux, le boot en raid logiciel fonctionne depuis toujours avec grub1 et syslinux… En tout cas sous Debian et ArchLinux…
[^] # Re: Serveurs
Posté par Misc (site web personnel) . Évalué à 4.
En raid logiciel pur, ie sans /boot séparé hors des partoches en raid ?
Dans mon souvenir, le souci est que grub ne comprenant par le raid, il faut charger le kernel et l'initrd depuis une partoche /boot en dehors du raid, et faire la synchro plus ou moins à la main.
[^] # Re: Serveurs
Posté par gouttegd . Évalué à 4.
Je ne sais pas pour grub 1 ou 2, mais avec LILO,¹ ça marche. Un initrd est toujours nécessaire, mais le noyau et l’initrd en question peuvent être chargés depuis un
/bootà « l’intérieur » de la matrice RAID.¹ Oui, oui, LILO existe encore, y en a même qui l’utilisent.
[^] # Re: Serveurs
Posté par wismerhill . Évalué à 2.
Si, grub1 reconnait le raid logiciel de Linux mais uniquement l'ancien format de méta-données (0.90), donc on peut créer explicitement avec mdadm -e 0.90 un périphérique raid pour /boot qu isera reconnu par grub1.
Il est également possible que les versions actuellement inclues dans les distributions soient patchées pur supporter le nouveau format de méta-données.
[^] # Re: Serveurs
Posté par SidStyler . Évalué à 2.
Dans mes souvenirs, il me semblait que pour Grub1 il fallait faire un raid spécifique pour la partition /boot à cause de LVM surtout.
Ca donnait quelque chose comme :
Raid1 n°1:
/boot
Raid1 n°2:
LVM
-- /root
-- /home
…
Ce qui n'était plus nécessaire avec Grub2, on pouvait tout mettre dans un seul RAID avec LVM.
Enfin ça fait longtemps, je ne suis pas tout à fait sûr de ça.
[^] # Re: Serveurs
Posté par M.Poil (site web personnel) . Évalué à 6. Dernière modification le 27 janvier 2013 à 21:23.
Ton RAID logiciel a-t-il 512Mo de cache dédié? a-t-il une protection contre la perte de données en cas de coupure électrique? Permet-il de faire un volume de plus de 8 disques? …
Is it a Bird? Is it a Plane?? No, it's Super Poil !!!
[^] # Re: Serveurs
Posté par WhiteCat . Évalué à 2.
Non. C'est censé être moins bien ?
Un serveur est généralement branché sur un onduleur.
J'imagine que oui.
[^] # Re: Serveurs
Posté par Anonyme . Évalué à 4.
Et ça se fout de ma gueule quand je parle de backup…
[^] # Re: Serveurs
Posté par ymorin . Évalué à 7.
Il dit qu´il ne voit pas le rapport …
Hop,
Moi.
[^] # Re: Serveurs
Posté par Misc (site web personnel) . Évalué à 3.
Il dit qu'il a plus de genoux
[^] # Re: Serveurs
Posté par Kaane . Évalué à 10.
Un serveur est généralement branché sur un onduleur.
L'alim de ton serveur / son riser / son backplane grille.
Il t'arrive quoi ?
Sur une carte RAID digne de ce nom toute les transactions complètes sont finalisées, toutes les transactions incomplètes sont annulées.
Et on va passer gentillement sur les problèmes d'accès concurrents multiples (genre 5 ou 6 process qui veulent écrire sur le même disque - en RAID soft c'est drôle, en RAID soft SATA c'est carrément hilarant), de pannes multiples (2ème panne pendant la reconstruction du RAID), la conso CPU/IO en cas de reconstruction, l'élection de disque maître (si je mets un disque avec une structure RAID 1 dans une baie soft, lequel est reconstruit ?), les problèmes à mettre la racine en RAID pour de vrai (comprendre bootloader inclus) etc.
Honnêtement le RAID soft a des avantages, principalement il ne coute pas cher et il est très compatible avec lui même. Mais quand on a vraiment besoin de RAID on fait autre chose.
[^] # Re: Serveurs
Posté par ymorin . Évalué à 9.
C´est un point à moitié valide. Certes, cela peut permettre d´améliorer les perfs. Mais sur un système UNIX, il y a déjà le cache en RAM. Et de nos jours, vu le prix de la RAM, benner 2 GiB de plus dans le serveur, c´est franchement moins cher que d´avoir du cache sur le contrôleur RAID.
En plus, cela dépend de l´usage du serveur. Pour un serveur de fichiers, le cache du contrôleur RAID ne sert strictement à rien, vu que la RAM du serveur sert uniquement de cache. Pour un serveur applicatif, il vaut mieux augmenter la RAM pour le cache, ça évite que les données aient besoin de faire le voyage contrôleur -> RAM avant de les utiliser (certes la RAM n´est pas dédiée dans ce cas, mais ça doit être possible avec
tmemetfront-cache). Et du coup, vu le prix de la RAM de nos jours … (oui, je me répète ;-) )Tu veux dire, est-ce que le serveur est branché sur un onduleur ? Ben non, j´ai quelques esclaves qui se relaient sur une bicyclette avec dynamo. Mais rassure-toi, j´ai deux bicyclettes et deux esclaves qui pédalent en permanence en RAID-1 ! :-)
Plus sérieusement, si tu as un contrôleur RAID avec cache et batteries, il faut changer la batterie de temps en temps, sinon, elle finit par ne pas durer assez longtemps pour vider le cache. Au contraire des onduleurs (haut de gamme) qui permettent de changer les batteries à chaud, changer la batterie d´une carte RAID nécessite un arrêt de la machine.
Il n´y a à priori aucune limitation dans l´implémentation RAID de Linux.
[^] # Re: Serveurs
Posté par M.Poil (site web personnel) . Évalué à 0.
La dernière génération de carte Raid n'a plus de batterie mais un module flash plus une capacité qui permet de recopier les informations en cache vers le module flash.
Je ne me vois pas mettre 2000 onduleurs dans mon datacenter, alors oui il y a des batteries et des générateurs, mais la double panne ça existe et quand tu as 2000 serveurs qui se sont pris une coupure dans les dents tu chiales un peu.
Le cache des cartes RAID ne sert par défaut qu'a mettre en cache les écritures, il ne faut jamais utiliser le cache d'une carte RAID pour de la lecture.
Is it a Bird? Is it a Plane?? No, it's Super Poil !!!
[^] # Re: Serveurs
Posté par Psychofox (Mastodon) . Évalué à 8.
Y'a t-il vraiment un sysadmin dans cette discussion ? Quand je vois des phrases pareil j'en tire la conclusion que non.
[^] # Re: Serveurs
Posté par oinkoink_daotter . Évalué à -2.
Pour le raid 5, faut connaître le nombre max de disques (non spare) à l'avance. C'est une putain de limitation !
[^] # Re: Serveurs
Posté par Crazy Diver . Évalué à 2.
Pour l'avoir fait (avec mdadm) je dirais tout simplement que c'est faux.
Par contre attention, c'est violent et ça prend du temps !
Et surtout il ne faut pas oublier :
[^] # Re: Serveurs
Posté par oinkoink_daotter . Évalué à 2.
Ben l'installateur debian mentait il y a deux semaines :(
[^] # Re: Serveurs
Posté par ellyan . Évalué à 1.
Non!
Ça prend un temps fou mais tu peux changer le nombre de disques d'un raid 5 (ou 6) à la volée, avec une grappe qui reste accessible.
Et à ma connaissance c'est pas récent récent, puisque c'est implémenté dans le mdadm de ma debian squeeze.
[^] # Re: Serveurs
Posté par oinkoink_daotter . Évalué à 1.
Ben l'installateur debian n'a pas été mis à jour, puisqu'elle dit "attention de ne pas te rater, tu ne pourras plus changer après".
[^] # Re: Serveurs
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 1.
Avec mdadm (sur noyau 2.6), bizarrement, si, il y en a une : 27. On ne peut pas créer des volumes agglomérant plus de 27 disques physiques.
Bon, cela dit, mdadm n'est pas le seul raid soft qui existe… (ZFS powW… pardon, ça m'a échappé)
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: Serveurs
Posté par WhiteCat . Évalué à 2.
Tu as un lien qu pourrait confirmer ça ?
[^] # Re: Serveurs
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 2.
Toutafé :
http://www.cbp.ens-lyon.fr/publications/doku.php?id=qualificationmateriel:sun_fire_x4500:mdadm_lvm
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: Serveurs
Posté par WhiteCat . Évalué à 3.
En fait le man de mdadm précise que c'est limité à 28 "components" et à 2 To avec l'ancien format de metadata (version 0.90). Mais aujourd'hui le format de metadata par défaut est version 1.x et il n'y a pas de limites.
Par contre je ne sais pas depuis quand ce nouveau format est par défaut dans mdadm.
Source : 3ème page du man mdadm.
[^] # Re: Serveurs
Posté par Grunt . Évalué à 2.
Ok. Pour en revenir au sujet (la comparaison entre RAID soft et RAID hard), je serais curieux de voir un exemple de solution permettant de faire du RAID hard avec 27 disques.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Serveurs
Posté par M.Poil (site web personnel) . Évalué à 4. Dernière modification le 29 janvier 2013 à 07:52.
Chez LSI, une carte MEGARAID SAS 9260-8I (que l'on retrouve chez IBM sous la forme d'une M5015)
Eight-port internal SATA+SAS solution for high-density servers and workstations using up to 128 devices with the flexibility to use both SATA and SAS hard drives and solid state drives (SSDs).
Is it a Bird? Is it a Plane?? No, it's Super Poil !!!
[^] # Re: Serveurs
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 29 janvier 2013 à 09:08.
C'est le nombre max de disques connectés, autant prendre alors la 9285 plutôt (240 disques).
Ca ne veut pas dire qu'on peut tous les mettre dans le même array (déjà qu'elles ont toutes les deux une limitation à 64 TB, donc 16 disques de 4 TB par exemple)
Je n'ai jamais testé, on peut mettre les 128 (petits alors : pas plus de 512 Go par disque, sinon limite de 64 TB dépassée!) disques dans le même array? Et l’intérêt me parait limité (à cause de disques de 512 Go du coup, c'est petit même en format "pro" qui monte à 3 TB aujourd'hui pour des HDD et si tu prend que des SSD le débit RAID serait hyper-faible en comparaison des débits SSD possibles) même si c'est possible…
[^] # Re: Serveurs
Posté par WhiteCat . Évalué à 4.
645 $ la carte quand même.
Et tout qui passe sur le même bus (PCI Express 2 @ 8x = 4 Go/s). Alors OK, avec 27 disques ça te laisse 150 Mo/s par disque. Mais au delà tu deviens limité par le bus. D'ailleurs comment on fait pour connecter plus de 8 disques ? Il faut utiliser des démultiplicateurs ? (c'est une vraie question !)
Je trouve qu'il est plus optimal de faire un RAID soft. Au moins tu peux mettre des disques sur le contrôleur SATA du chipset, d'autres sur une carte additionnelle (voire plusieurs), Linux devrait j'imagine pouvoir répartir le flux de données sur chaque contrôleur.
[^] # Re: Serveurs
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 2.
Tu en a révé, Backblaze l'a (mal) fait : Storage Pod (http://blog.backblaze.com/2009/09/01/petabytes-on-a-budget-how-to-build-cheap-cloud-storage/)
(lvm + jfs me paraissent sous-optimal, ZFS on linux serait mieux, mais faut revoir CPU+RAM à la hausse)
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: Serveurs
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 5.
Ça existe :
On peut aussi jouer avec du HP D6000, du Xtore, etc. Certes, ce n'est pas le genre de configuration que tu laisse tourner dans une chambre ou un bureau…
Proverbe Alien : Sauvez la terre ? Mangez des humains !
# Et pour en remettre une couche
Posté par Misc (site web personnel) . Évalué à 4.
On m'a filé ça :
http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRight
L'auteur détaille une paire de souci avec upstart tout au long de l'article, et explique aussi tout au long des liens le genre de souci subtile qu'il y a avec l'usage de scripts de démarrage ( genre l'environnement pas clean )
[^] # Re: Et pour en remettre une couche
Posté par kadalka . Évalué à -10.
1/ Quelle est la valeur d'une paire de soucis? Peanuts
2/ Ce que l'auteur pense importe peu. Vous avez peur de dire ce que vous en pensez ?
a) Vous êtes proFedora donc vous manquez d'objectivité car vous défendrez forcément systemd
b) upstart c'est de l'ubuntu donc forcément vous ne l'aimerez pas…
Exemple typique de manque d'objectivité:
Le soucis est subtile , donc pas vraiment identifié…
Une affirmation pertinente serait de préciser LE soucis.
Voici le genre d'affirmation [dans le lien] qui m'a fait rire :
it apparently does per-user fair share scheduling by default (but I haven't had a chance to run systemd in a situation where I could really see this in action)
En gros donc, vous nous vantez les mérites de systemd comme étant une révolution, mais même ce monsieur n'arrive pas à réaliser une telle opération qui est théoriquement facile puisque systemd est une révolution.
J'avais déjà vu toute une littérature [sarcasme] sur systemd: une des promesses est de simplifier les choses.
Dans le texte, je lis:
Or, je lis ceci :
Gentoo est connu comme très solide et très sérieux.
Les comparaisons entre les différents systèmes d'init me démontre que systemd n'est pas forcément le bon choix, loin de là.
Lire ceci pour s'en convaincre : http://wiki.gentoo.org/wiki/Comparison_of_init_systems
Tout le monde vous dira que ce qui importe n'est pas de simplifier les choses mais que les choses fonctionnent correctement.
Mieux vaut entendre : " this feature does not exist " plutôt que de lire dans la notice " This is implemented " mais on lit quelque part " FAIL to start ".
Dans ce dernier cas, c'est un manque évident de professionalisme.
Comme vous le dites vous même: qu'il fasse le boulot sans plus.
Tout le monde est d'avis que le système [init] fonctionne correctement depuis 40 ans, donc pour les soucis, il faudra nous détailler un peu.
Faites comme les pros: donnez nous des exemples concrets dans votre vie quotidienne.
N.B.:
C'était bien vous qui m'avez affirmé que j'avais un problème de gravage de CD c'est pour cela que mon fedora avait du soucis, alors que je fais TOUJOURS un check disc dès qu'il s'agit d'installer un OS.
N'est-ce pas ?
Même avec un Live CD je fais un check disc au moins pour le premier usage.
(Une fois que l'ISO est sur un disque sur lequel je boote, pas de check disc utile.)
[^] # Re: Et pour en remettre une couche
Posté par daeldir . Évalué à 6.
Je dois être un peu idiot, mais je ne vois pas sur cette page quoi que ce soit qui me démontre que systemd n'est pas un bon choix. J'apprécie les systèmes simples et ai été déçu du passage d'Archlinux à systemd, pourtant… J'aimerais juste comprendre cet argument que tu utilises deux fois.
[^] # Re: Et pour en remettre une couche
Posté par cedric . Évalué à 4.
Il doit preferrer la couleur rouge a la couleur verte !
[^] # Re: Et pour en remettre une couche
Posté par Misc (site web personnel) . Évalué à 10.
Donc récapitulons. J'ai une opinion donc je manque d'objectivité ( c'est grosso modo la définition, mais bon, passons ). Je donne donc pour éviter de tomber dans ce travers un lien de quelqu'un que je connais pas, mais d'un coup j'aurais peur de dire ce que j'ai déjà dit 15 fois sur linuxfr.
Certes. Et au final, quoi que je dise, je suis pro fedora, donc forcement, je vomis ce que fait Ubuntu. Parce que c'est bien connu, quand on utilise une distribution, ça retire tout sens critique, donc pas besoin de donner d'argument.
Au lieu de m'éterniser sur des arguments stériles et des attaques ad hominem, regardons de plus prêt ce que l'auteur de l'article dit :
Rajoutons donc ce que je sais à savoir que upstart utilise la commande ptrace pour suivre les process, et que curieusement, ça passe pas tout le temps. Comme je ne veux pas donner dans le FUD, il y a 2 liens :
https://bugs.launchpad.net/upstart/+bug/406397
https://bugs.launchpad.net/upstart/+bug/703800
Donc voila 4 problèmes liés à l'architecture d'upstart ( ie, le fait d'avoir un fichier de config qui est en fait un script, et le fait d'utiliser ptrace pour suivre les processus ), corrigé par le design de systemd, à savoir avoir des fichiers au format .ini, ce qui permet de mettre des priorités sur les directives qui découlent d'un ordre de lecture prétabli, et l'usage des cgroups, pour gérer les groupes de processus. Cgroups déjà à la base de lxc, donc relativement étanche.
Quand je dit subtile, je veux dire par la difficilement identifiable. Par exemple, se connecter en ssh, et relancer un serveur web et voir plus tard que tout d'un coup, ton cgi qui appelle la commande 'sort' merdouille parce que la variable LANG n'a pas été nettoyé ( ie, LANG=FR_fr est passé au script, puis à apache, puis à ton cgi, puis à 'sort' qui va trier les caractères diacritiques d'une façon différente en fonction de la locale ). Ou voir qu'en fonction de comment est lancé ton soft, tu as un autre format de date dans les logs, car il reprends LC_ALL et LC_TIME. Bien sur, si on était sur d'avoir toujours le même environnement clean, ça n'arriverais pas ( khof http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRestartEnvironment khof )
J'ai rien contre Gentoo, j'ai un serveur sous Gentoo chez OVh, et je dirais même que je connais des gentooistes ( bien la preuve que je suis pas raciste ). Mais sérieux et solide n'est pas forcément ce qui me vient à l'esprit. J'aurais plutôt dit flexible et adaptatif.
Sérieux, pour moi, ça implique par exemple un suivi des soucis de sécurité et pendant un bon bout de temps, il n'y plus eu d'alertes de sécurité (cf http://www.gentoo.org/security/en/glsa/index.xml entre janvier 2010 et mai 2010 ).
Solide, je dirais que c'est plus la personne qui décide de pas abuser de l'adaptabilité. Il faut bien voir qu'en pratique et en fonction des choix de l'admin, chacun a un système différent. L'utilisateur est le premier, dernier et seul personne à faire la QA de son système. ( bon, pas exactement, mais j'ai toujours voulu caser la formule ). Les paquets passent de masked a unmasked sur la base des retours des gens, ce qui garantit des tests minimums, mais les retours sont se font dans des environnements différents. Et c'est une approche différente d'une debian ou d'une autre distro binaire, ou tout le monde a les mêmes binaires ce qui fait que si ça marche chez X personnes, alors il y a moins de raison que ça foire ailleurs. Alors que gentoo, avec les use flags, etc…
Et comme il y a pas de mises à jours de sécu au sens "mise à jour minimal" avec la QA qui va avec, la solidité n'est pas une chose que j'estime acquise, bien que je n'ai pas eu à me plaindre personnellement si souvent et que c'est suffisant pour ce que j'en fait.
Openrc, qui a quand même eu 10 ans pour se faire adopter, semble faire un revival. Bien sur, personne ne va dire que openrc, il supporte le boot en parallèle avec des bugs compliqué à reproduire ( https://bugs.gentoo.org/show_bug.cgi?id=391945 ).
Je n'ai pas dit "révolution", j'ai laissé mon pull noir à col roulé au placard. Et j'ai du mal à saisir. L'auteur de l'article n'a pas eu de situation ou le "fair share scheduling", traduisons par "partage équitable de l'ordonnanceur" a pu s'appliquer, donc ça rends systemd compliqué ? Si ses serveurs ne sont pas chargé ras la gueule au point d'en avoir besoin, ou est le souci ?
Pour info, ce dont il parle est détaillé la : http://lwn.net/Articles/415740/ , avec la réponse de lennart la : http://lwn.net/Articles/415756/. Si les gens passent pas leur temps à mettre leur bécane sur les genoux à grand coup de compile kernel pour constater si systemd fait un truc, c'est la faute de systemd ?
Pour info, ce que l'auteur a voulu dire, c'est que contrairement à smf, l'init de solaris, systemd n'utilise pas de xml pour sa config donc l'admin n'a pas à interagir avec. Ensuite, la doc est en docbook ( un format de publication en xml ), et en effet, 15% du contenu du tarball, c'est de la doc en xml.
Mais c'était bien tenté.
Pas moi. Ni les gens de chez Sun, vu qu'ils ont refait le système avec SMF. Ni les gens d'Ubuntu ou de Chrome OS, vu qu'ils ont upstart ( ou RHEL 6, ou Maemo ). D'ailleurs pas les gens de Gentoo, vu qu'ils ont fait openrc. En fait, Apple aussi a refait son système d'init il y a 3/4 versions. Donc oui, si on retire tout ça, tout le monde pense que ça marche.
Enfin pas ceux qui ont fait runit ou initng non plus. Ni les gens de FreeBSD qui ont proposé un portage de launchd dans un Google Summer of Code.
Enfin donc, à part tout les gens qui sont tellement d'avis que ça fonctionne correctement qu'ils se sont dit qu'il faut le remplacer, ouais, tout les autres pensent que ça marche.
Enfin si on retire tout ceux qui ont choisi systemd, comme arch, opensuse, mandriva, fedora mageia, ou des boites comme intel ou rackspace ( vu que intel bosse dessus, rackspace bosse sur journald ), oui, tout les autres pensent sans doute que ça marche comme il faut.
Mais bon, je suppose que juste donner des noms, ça ne va convaincre personne, donc je vais détailler. Déjà, quand tu dit "le systeme d'init marche depuis 40 ans", tu veux sans doute parler de sysvinit, et donc depuis 30 ans. Bon, pas grave, 10 ans, c'est presque rien. Le système des premiers unix était sans doute un chouia plus frustre, et je me demande si à l'époque, les gens ont ralés devant la complexité d'avoir gasp, une couche d'indirection de plus.
Alors déjà, si ça marche bien, pourquoi toutes les distros ont rajouté le support des tags LSB pour l'ordre des scripts si le format de base est si bien ? Non, pas la peine de répondre, c'est parce que c'est moisi de devoir choisir à la main l'ordre. Et parce qu'il y a pas vraiment de format, juste des conventions, comme le fait de faire un printf, le fait d'avoir X ordres. Je vais pas parler des codes de retour des initscripts, je risquerais de devenir grossier.
Ensuite, non ça me marche pas bien. Par exemple, bind est le premier exemple que je donne à chaque fois. Bind utilise la commande rdnc pour signaler au processus principal qu'il doit s’arrêter. Sauf que comme c'est une communication unidirectionnel, en fonction de la charge de la machine, tu ne sais pas si bind est coupé ou pas au moment ou la commande rends la main. On pourrait croire naïvement que ça n'a pas d'importance, sauf que si tu fais un stop et un start ( ce qui est quand même la façon la plus universelle de faire restart ), et ben parfois, bind ne se relance pas, car l'autre n'est pas mort. Bien sur, ça dépend de la machine et de sa charge. Et se dire qu'on est passé d'un coup en fonctionnement asynchrone sans le savoir, ça montre bien qu'il y a des soucis.
Les distros gèrent ça de différentes façon. Debian fait une boucle avec un kill -0 ( donc n'envoie pas de signal fatal ) et attends que le process meurt, donc que le kill échoue. Ce qui est moche pour le cas rare ou le PID est recyclé assez vite ( ie, il y a une race condition ), car le script attendrait à l'infini ou presque.
Mandriva fait ça avec un sleep 5, ce qui tout aussi un hack.
Systemd, il gère ça en suivant tout les process du groupe. Ie, quand ils sont morts, il le sait.
Le deuxième exemple, c'est mon ami Sympa. Sympa, c'est vachement bien, plus souple de mailman sauf qu'il y a un léger souci. Quand tu le connectes à postgresql ( ce que l'équipe de sysadmin de Mageia a fait ), si la base de données n'est pas disponible, il attends. Il attends pas en tache de fond. Il attends et le script d'init ( une horreur qui lance 5 services d'un coup ) se bloque. Donc si ta base se lance après par la magie des scripts, ton serveur se bloque au boot. En fait, c'est aussi amusant si postgresql mets du temps à mettre son socket à disposition pour une raison X ou Y, car même en étant lancé avant, sympa bloque le boot. Alors bien sur, une fois que tu as pigé le souci, ç'est facile à corriger. D'ailleurs, ça a été corrigé upstream d’après le packageur debian avec qui j'ai eu le temps d'échanger sur le sujet.
Systemd, il gère ça en lançant tout en même temps, et en s'en foutant d'un process qui bloque.
Alors le 3eme exemple, c'est Apache. Apache, c'est un soft cool, ça gère les processus pour toi. Sauf que voila, parfois, y a des processus qui partent en vrille ( ce qui arrive quand on embarque des saletés dedans comme php, ou des cgis ), et parfois, pareil que bind, ça mets du temps à mourir. Comme le process principal tot ou tard meurt, il reste parfois des orphelins. Et c'est coriace ce genre de bestiole, car faut que l'admin vienne à la main faire le ménage. Bien sur, pareil que bind, ça arrive pas toujours, même rarement. Il faut bien tomber sur des circonstances aggravantes pour que ça se produise.
Mais bon, c'est pareil, c'est entièrement du à sysV. Parce qu'avec les cgroups, tu peux faire du kill(9) à tout va après un temps.
Ensuite, des gens vont te dire que la pauvreté de sysV implique de dupliquer le code pour passer un soft en daemon dans chaque soft, que statistiquement tout le monde ne le fait pas tout ce qu'il faut comme il faut ( à savoir se rattacher à un groupe de process, faire un chdir('/'), fermer tout les descripteurs de fichiers, faire un double fork, et sans doute des trucs que j'oublie ) et que du coup, ça cause des soucis
Avec sans doute une petite biére, ils vont continuer pour expliquer qu'il y a des problématiques à la con entre setuid, setgid ( l'ordre par exemple, ou le fait de fait un initgroup avec setgid ), et que même les meilleurs oublient, ou te parler de cas ou un init script s'est vautré sur un fichier de pid non effacé du à un reboot intempestif de la machine.
D'autres gens vont te répondre que systemd mutualise tout ça et que le code écrit une fois utilisé pour 50 softs est plus sur que le code écrit 50 fois par 50 personnes. Ces autres gens vont aussi te dire que systemd va gérer /var/run sur un tmpfs ( http://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html ), ce qui est "reboot intempestif friendly".
Mais bon, je suppose que tout ces gens, tu va sans doute dire que leur objectivité est impossible, qu'ils ont tort parce que toi, tu as eu aucun problème donc ça prouve bien que ça n'existe pas ?
[^] # Re: Et pour en remettre une couche
Posté par Jux (site web personnel) . Évalué à 10.
Ca c'est un commentaire qui mériterait d'être transformé en journal ou en dépêche :-)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Et pour en remettre une couche
Posté par Guillaume Denry (site web personnel) . Évalué à 10.
Punaise, tu lui as mis sa pâtée, c'en est presque écœurant ;)
[^] # Re: Et pour en remettre une couche
Posté par patrick_g (site web personnel) . Évalué à 10.
Tu prends la première place provisoire dans mon concours du "BEST COMMENT OF THE YEAR" !
[^] # Re: Et pour en remettre une couche
Posté par wolowizard . Évalué à 3.
Il n'est pas à "l'abandon" ce projet? Le portage n'est pas abandonné?
launchd sur Freebsd
Même sur sourceforge, il n'y a plus grand chose qui se passe: http://sourceforge.net/projects/launchd4freebsd/
Il y a même un possible port sur NetBSD , mais on se demande pourquoi chez FreeBSD, ça n'a pas abouti.
http://wiki.netbsd.org/projects/project/launchd-port/…
Et quand on lit certains threads sur la mailing-list, ça me laisse pensif:
http://lists.freebsd.org/pipermail/freebsd-hackers/2012-June/039350.html
En plus pour le contrôle des démons, il y a fscd(8) bien que je ne sais pas où ça en est…
[^] # Re: Et pour en remettre une couche
Posté par Misc (site web personnel) . Évalué à 1.
Si, le projet est à l'abandon. Mais j’étais pas au courant du port pour netbsd, ni du fait que ça dépend fortement de mach ( ceci dit, j'aurais du m'en douter, mais j'aurais penser qu'un soft non portable aurait fait raler tout le monde ). Je suppose que le fait de dépendre des plists ( un format basé sur xml d'os x, qui peut aussi être compilé en binaire ) risque de faire grincer des dents.
D'ailleurs, si des gens ont du temps à perdre, y a la présentation du dev de launchd chez Google en 2007 :
http://www.youtube.com/watch?v=SjrtySM9Dns
Il explique par exemple que le fait de lancer plusieurs choses en même temps permet de tirer parti des machines multi cores, il montre pas mal d'idées qui se sont retrouvés dans systemd ( le lancement activé par un chemin, par socket et dans le désordre ), et il montre aussi le genre de choses qu'on peut faire avec l'activation par socket dans la session user. Son exemple, lancer X ( qui plante quand il teste ) ou ssh-agent à la demande, ce qui permet de décharger la session des trucs qu'on utilise pas vraiment ( avec comme avantage de consommer un peu moins de ressources, d'avoir un session qui démarre un peu plus vite et surtout d'être plus robuste ).
[^] # Re: Et pour en remettre une couche
Posté par flan (site web personnel) . Évalué à 6.
C'est bien dommage que les plist fassent peur comme ça, les plist (property lists) ont pas mal d'avantages.
C'est à la base un format abstrait, qui peut être indifféremment écrit sous forme binaire, XML ou JSON (avec quelques limites sur le format JSON cependant).
- le format est bien documenté (bon, ok, il faut dire qu'il n'est pas franchement compliqué…).
- il y a des utilitaires pour le convertir d'une représentation à l'autre (du binaire à l'XML, par exemple), pour l'éditer à la main
- des libs existent dans différents langages (par exemple Python, ça fait même partie de la lib standard) pour lire et écrire des plist
- un utilitaire en ligne de commande (defaults) permet de modifier certaines valeurs
- il existe des utilitaires graphiques pour éditer plus facilement le contenu (quand le XML ou le JSON est un peu rébarbatif)
Au final, on se retrouve avec des fichiers de configuration super pratiques, vu que :
- pas de problème de syntaxe différente entre deux applications (ah, la joie des différences entre espaces et tab, surtout avec un éditeur configuré pour remplacer l'un par l'autre)
- besoin de lire la configuration d'un autre programme depuis son propre logiciel ? pas de parseur exotique à réécrire !
- besoin de changer une configuration depuis un script ? la commande defaults le permet sans souci.
Il manquerait peut-être un éditeur en ligne de commande, mais ça ne doit pas être très compliqué à coder.
Tous les fichiers de configuration (ou assimilables) sur OS X sont des plist (fichiers de conf, descriptifs d'une application, préférences de l'utilisateur, démons lancés par launchd, …), sauf les applis UNIX pures, naturellement.
Certes, cela ne permet pas les commentaires dans le fichier de configuration (à ma connaissance). J'imagine que l'idée pourrait être améliorée assez facilement.
Je ne dis pas que c'est la solution parfaite, simplement qu'avoir une seule syntaxe et qui soit utilisable via le shell, dans un éditeur ou via n'importe quel langage de prog est vraiment très pratique.
[^] # Re: Et pour en remettre une couche
Posté par barmic . Évalué à 4.
Ça m'a l'air intéressant, tu as un pointeur à ce sujet ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et pour en remettre une couche
Posté par Frank-N-Furter . Évalué à 3.
https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man5/plist.5.html
Depending on the time of day, the French go either way.
[^] # Re: Et pour en remettre une couche
Posté par flan (site web personnel) . Évalué à 1.
Sinon, il y a la doc Python http://docs.python.org/3/library/plistlib.html
Le format n'a vraiment rien de sorcier, on en fait vite le tour avec quelques exemples.
[^] # Re: Et pour en remettre une couche
Posté par zul (site web personnel) . Évalué à 2.
Pour information, NetBSD utilise les plist pour certaines choses, aussi bien dans le noyal que dans l'userland, entre autre pour échanger les données via une méthode standard. Divers outils proposent des sorties plist xml directement, en plus des sorties traditionnelles "line based".
[^] # Re: Et pour en remettre une couche
Posté par diorcety . Évalué à 1.
On parle bien des XML plist? Cette **rde sans nom?
[^] # Re: Et pour en remettre une couche
Posté par flan (site web personnel) . Évalué à 4.
Pourquoi tant de haine ?
Donc pour toi, c'est une merde sans nom parce qu'*une* des représentations ne convient pas au monsieur… il aurait aimé une représentation XML qui est un peu moins verbeuse, mais dont il cache les graves inconvénients :
- impossible de retrouver le fichier d'origine (il suffit de voir qu'on ne peut pas dans son exemple faire la différence entre les différents types d'éléments)
- impossible de valider le fichier en utilisant une DTD
- encore moins possible de garantir que c'est une plist valide
Et accessoirement, il oublie qu'à la rigueur, on s'en fout de la représentation du fichier vu que c'est prévu pour passer par des parseurs de plist, pour obtenir une représentation utilisable.
En Python, j'utilise plistlib et hop, j'ai directement des objets Python que je peux manipuler comme je veux. Ou au contraire, je donne mes objets Python (dictionnaires, listes, entiers, …) et j'ai mon fichier plist directement (sans avoir à connaître la représentation binaire associée).
Avec sa méthode, impossible de faire la même chose.
Bon, il préfère la version binaire du Plist, en disant que c'est plus facile d'écrire un parser… Ça se voit qu'il n'a jamais dû en écrire un. Par exemple, le parseur plist XML de Python est plus simple que celui qui est proposé pour la version binaire.
En fait, il critique alors qu'il n'a absolument pas compris le but des fichiers plist, qui est de justement ne pas avoir à se préoccuper de la représentation physique et de ne manipuler que des objets natifs du langage de programmation.
Bref, dire que c'est une merde sans nom simplement parce que quelqu'un trouve qu'une des représentations possibles est un peu trop verbeuse à son goût, je trouve ça légèrement exagéré :o
[^] # Re: Et pour en remettre une couche
Posté par diorcety . Évalué à 1.
C'est pas parce qu'il donne en contre exemple un schéma bancal que son argumentation est nul.
Je ne dis pas cela en l'air. Je l'utilise tous les jours avec les projets iOS et c'est vraiment l'un des pires format que j'ai pus voir.
On ne doit pas avoir les mêmes usages. Si je suis obligé de passer par un logiciel pour modifier/ajouter/comprendre/ une/des valeur(s) de mon fichier de configuration car c'est illisible avec un éditeur de texte, c'est déjà mal parti…
Après je suis peut être traumatisé par l'utilisation faite par Apple…
[^] # Re: Et pour en remettre une couche
Posté par Bapt (site web personnel) . Évalué à 3.
Le projet a été abandonné parce que a l'époque où le portage a été fait, la licence ne convenait pas, le changement de licence de launchd a eu lieu après, mais voila depuis personne ne s'est repenché sur launchd sérieusement.
[^] # Re: Et pour en remettre une couche
Posté par barmic . Évalué à 4.
Je n'ai pas bien compris ça. Tu peux en dire plus, s'il te plaît ?
Je trouve ça bizarre pourquoi ne pas faire :
L'attente n'est pas active, ne dépend pas de durée arbitraire estimées dans le meilleur ou le pire cas et pas de race condition. Bien sûr c'est moins propre que les cgroup notamment à cause des éventuels fils, mais ça me semble mieux que les solutions dont tu parle.
Oui c'est proposé par Lennard, mais rien de très spécifique à systemd là dedans.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et pour en remettre une couche
Posté par Misc (site web personnel) . Évalué à 5.
en gros, tu prends un job upstart au pif, genre ssh sur mon n9 :
Il y a 2 parties :
* la partie script ( entre script / end script )
* la partie pas script, à savoir le reste
La, si je veux par exemple que ssh ne s’arrête pas quand dbus se coupe ( c'est mon tel, je fais ce que je veux ). Ou imaginons que je veuille changer la directive oom, changer la valeur de nice, etc. Faut que je modifie le fichier.
Sauf que si je modifie le fichier, il se passe quoi à la prochaine mise à jour qui va faire pareil ( exemple, une modif qui change le chmod 0755 en 0700 pour cause d'un souci de sécurité ( exemple inventé )) ?
3 choix :
- le système de paquets écrase ma modification. Donc je doit repasser pour la remettre, si je m'en souvient.
- le système de paquets n'écrase pas la modification. Mais je doit passer pour rajouter sa modif dans mon fichier modifié.
- le système de paquets me demande, donc je doit passer pour fusionner les changements.
Dans tout les cas, ça requiert d'être la pour s'occuper de l'upgrade et tout ça parce qu'il y a des informations du domaine de la distribution (à savoir la partie 'script' ) mélangés avec des choses du domaine de l'admin ( à savoir les dépendances, le choix de l'oom ou pas, du nice, etc ). Et ça, c'est un job simple, il y a pas mal d'option en plus dans upstart.
Systemd gére ça de façon élégante en prenant les informations de 3 fichiers, et en appliquant la config dans un ordre précis. Si j'ai toto.service dans /lib et dans /etc:, les informations en plus de /etc ( genre une valeur de nice ) se rajoute à celle de /lib. Donc quand la distro modifie le fichier dans /lib, j'ai rien à faire de spécial. Il y a même un outil spécifique ( http://www.freedesktop.org/software/systemd/man/systemd-delta.html ) pour trouver ce qui a été modifié dans /etc par rapport à /lib
Les daemons font en général un double fork. Donc ton wait va attendre sur le premier, pas sur le second. Et tu ne peux faire de wait que sur un process fils, sauf erreur de ma part. Donc à partir du moment ou ton script d'init t'a rendu la main, tu peux plus faire de wait sur le pid de bind, donc inapplicable dans le cas exposé, à savoir d'un reboot. D'ou l'usage de ptrace par upstart pour choper le pid ( http://netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/ ).
oui, et sauf erreur de ma part, Ubuntu ( entre autre ) l'a fait avant que Lennart ne pousse ça dans systemd, vu que je me souvient distinctement avoir entendu raler le dev debian qui servait de sysadmin dans mon ancien job contre les devs Ubuntu d'avoir mis /var/run en tmpfs. Il avait du rajouter 2/3 lignes pour le script d'init pour refaire /var/run/nufw/ ou ce genre de choses avant de lancer le démon de notre produit.
[^] # Re: Et pour en remettre une couche
Posté par barmic . Évalué à 4.
Ouai je comprends. Ça me paraît être un mauvais usage de l'initsysv. Je viens de regarder dans ma distrib' (debian stable) ssh ne souffre pas de ce problème mais exim si.
En effet. Mais une autre solution plus vielle que les cgroups consiste à utiliser les namespaces pour créer un nouveau pool de pid, ton script shell deviens le PID=1 et tout les fils reviennent vers toi quoi qu'il arrive. Je ne sais pas s'il y a des effets de bords à cette méthode par contre (mais je ne crois pas que ça ai était utilisé un jour par un système d'init).
(oui je sais que cgroups fais bien plus que ça notamment pour gérer l'ordonnanceur)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et pour en remettre une couche
Posté par Misc (site web personnel) . Évalué à 2.
Alors en lisant la discussion sur lwn, quelqu'un a pointé
et notamment http://upstart.ubuntu.com/cookbook/#override-files
Donc ça peut se faire proprement depuis upstart 1.3 ( soit depuis bientôt 2 ans ).
[^] # Re: Et pour en remettre une couche
Posté par barmic . Évalué à 3.
Ça me fait penser au divert dispo dans dpkg depuis que je le connais (7 ou 8 ans) http://linux.die.net/man/8/dpkg-divert
Mais ça n'a d'intérêt que si tu sépare le coté scripting de la configuration. Par exemple imaginons un script qui lance un service de manière simpliste :
Si une nouvelle version arrive et maintenant pour passer le port on utilise plus l'option --port, mais une variable d'environnement. Si tu as modifié le port, tu es marron.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et pour en remettre une couche
Posté par Misc (site web personnel) . Évalué à 2.
Oui, et visiblement, il y a encore d'autres endroits dans le cookbook d'upstart ( que j'ai commencé à relire ) ou ils reprennent le même système de modifier des fichiers qui sont pas de la configuration.
http://upstart.ubuntu.com/cookbook/#list-all-jobs-with-no-stop-on-condition
Mais c'est un problème compliqué, car parfois, un fichier de configuration n'arrive pas à exprimer toutes les subtilités de ce que tu veux exprimé, et parfois, faut juste essayer de rentrer dans les clous.
dpkg-divert, c'est un moyen de hacker sans trop de dégât immédiat ton système, mais c'est pas tenable. Et tu peux pas rendre tout configurable non plus.
[^] # Re: Et pour en remettre une couche
Posté par barmic . Évalué à 2.
Il faut voir au cas par cas. Dans un certain nombre de cas un système comme apt avec les sources.list.d est très largement suffisant (principe aussi utilisé dans grub2 et dans la gestion des connexions graphiques sous debian). OpenSSH se contente assez bien d'un fichier clef/valeur et /etc/networks/interfaces ne fais au contraire rien dans ce sens.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et pour en remettre une couche
Posté par Batchyx . Évalué à 2.
Pas par défaut. De toute façon, sous Debian, ce fichier doit être intégralement géré par l'administrateur et ne doit jamais être modifié par un script.
Donc si tu n'est pas un script, tu peux te
echo 'source /etc/network/interfaces.d/*' >> /etc/network/interfaceslemkdir /etc/network/interfaces.d[^] # Re: Et pour en remettre une couche
Posté par Batchyx . Évalué à 2.
Tout les systèmes de gestion de version de sources ont le même problème.
Et devine quoi ? Il n'y a pas de solution miracle.
Ton gestionnaire de paquet pourrai très bien merger les modifications tout seul, ou tu pourrai très bien séparer les deux et laisser ton gestionnaire de paquet gérer un des deux fichiers. Mais dans les deux cas la modif de la distribution peut être incompatible avec tes propres paramètres de manière plus ou moins subtile. Et si c'est modifié silencieusement, c'est encore plus drôle.
[^] # Re: Et pour en remettre une couche
Posté par pasBill pasGates . Évalué à 1.
Ca n'a en fait rien a voir avec la gestion de version de sources.
C'est simplement un mauvais design ou les parametres du systeme ne sont pas separes de son code (le script). Ce qui fait que quand tu updates le code, ben que tu le veuilles ou non, tu dois faire un merge/update/ecrasement des parametres.
Si les parametres etaient separes, le probleme ne se poserait tout simplement pas (qui a dit le mot registry ?)
[^] # Re: Et pour en remettre une couche
Posté par barmic . Évalué à 5.
Si, si ça continue. Si le logiciel change de paramètres alors tu doit faire un merge entre les anciens paramètres et les nouveaux. Certains logiciels sont très stables à ce niveau là alors que d'autres non. Je vois pas le besoin de la base de registre pour faire ça : des fichiers ini, xml, yaml, json par logiciel suffisent amplement (je ne trollerais pas plus sur la base de registre ce serais mesquin).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et pour en remettre une couche
Posté par pasBill pasGates . Évalué à -2.
Oh tout a fait, tu peux faire ca autrement qu'avec un truc style base de donnees. La registry n'est qu'un exemple (qui a en plus l'avantage d'etre structure et type et selon certains le desavantage d'etre impossible a lire avec un editeur de texte).
Et bien entendu qu'un changement de parametres demande une adaptation, mais honnetement c'est tres rare, des ajouts/enlevements sont bien plus habituels que des modifications.
[^] # Re: Et pour en remettre une couche
Posté par zebra3 . Évalué à 2.
Mouais, même ça c'est pas un vrai problème. Vim peut éditer des fichiers compressés par gizp ou bzip2, je ne vois pas pourquoi il ne pourrait pas éditer une registry, il suffit de lui donner un connecteur.
Un autre avantage d'une registry, c'est qu'elle pourrait être étendue relativement facilement pour gérer elle-même le versionning.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Et pour en remettre une couche
Posté par barmic . Évalué à 3.
Puisque vous partez là dessus, moi ce qui me gêne le plus c'est l'export de la configuration d'un logiciel (un seul). Je ne crois pas avoir vu ce genre de choses ni dans dconf ni sous windows. Notez que pour configurer le système ça ne pose pas de problème.
Sinon oui comme l'arborescence d'une base de registre pourrais indiquer les versions de logiciel /Apps/MySoft/1.0/* et /Apps/MySoft/2.0/*, mais justement ça n'a rien de problématique pour un système de fichier. Dans un cas comme dans l'autre le logiciel pourrait réimporter lui-même les anciennes configuration dans la nouvelle version.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et pour en remettre une couche
Posté par freem . Évalué à 1.
Je souhaiterais au passage rappeler qu'un dossier et une base de données, c'est assez proche, modulo la méthode pour trouver la donnée (par clé/hash/node…).
Le registre windows, c'est: une structure en arbre, contenant des couples clé/valeur.
Un système de fichier, c'est: une structure en arbre (les dossiers étant les noeuds) contenant des couples clé/valeur (les fichiers sont la valeur, leur nom est la clé).
Dans les deux cas, on peut stoker une valeur texte, ou binaire. Niveau base de registre windows, ce que je n'aime pas, c'est:
1) Pas éditable par éditeur de texte simple (et, non, vim n'est pas simple, même s'il à des points qui font que je l'utilise de plus en plus.)
2) Je ne comprend pas l'intérêt d'ajouter une complexité pour une configuration qui n'est censée n'être lue qu'une fois: au début du lancement d'un logiciel.
3) Le foutoir (selon moi, et c'est de toute façon entièrement lié à ce registre précis)
Ce que j'aime avec mon /etc, c'est:
1) Les commandes du bash sont disponibles, sans adaptation. Ca implique que les scripts ne nécessitent pas d'apprendre un nouveau langage. D'ailleurs, la plupart des langages savent se démerder avec des fichiers et dossiers.
2) Je peux utiliser n'importe quel logiciel de versionning. Git, svn, cp.old…
C'est un peu comme le xml (tant qu'a troller, trollons bien) que tout le monde pense être la panacée: dans énormément de cas, il n'a aucune intérêt si ce n'est d'être à la mode.
[^] # Re: Et pour en remettre une couche
Posté par pasBill pasGates . Évalué à 4.
2) Pourquoi est-ce sense n'etre lu qu'une fois ? Tu peux modifier les valeurs pendant que le logiciel est lance, le logiciel peut en etre notifie et les relire.
1) T'as reg.exe qui s'occupe de modifier les valeurs de la base de registre que tu veux en ligne de commande, powershell te permet de voir la registry comme un systeme de fichier, partant de la, aucune difference…
2) Tu fais de meme a travers un export de la registry qui te donne un fichier texte
[^] # Re: Et pour en remettre une couche
Posté par Batchyx . Évalué à 3.
Le code que tu est censé mettre dans ce fichier, ce n'est pas le code du programme. Si tu veux avoir un script qui garde la compatibilité des paramètres et que tu veux pouvoir mettre à jour séparément, tu le met dans un fichier séparé dans /bin ou /usr/bin, et tu planque l'exécutable réel.
Le code que tu met dans le script upstart sert uniquement à permettre à l'administrateur de modifier comment le programme est lancé, par exemple, en lui spécifiant une configuration générée dynamiquement. Là le script est un peu un mauvais exemple: le système d'init pourrai regarder si l'exécutable existe, /etc/default/ssh est clairement une fainéantise de conversion, et le répertoire de séparation des privileges est spécifié à la compilation, donc aucun intérêt à vouloir modifier ça. Le seul cas véridique, c'est la bidouille du PermitRootLogin. Et étant donné l'importance de l'option, c'est une bonne idée de la laisser là. Tu peux toujours le mettre ailleurs, si tu pense que tu va vouloir mettre ça à jour sans rien casser, et que tu à envie de penser au cas ou l'administrateur ne veut pas de ça.
Le script de démarrage sert à être modifié par l'administrateur, tout comme les paramètres. S'il y a des choses que la distribution veut mettre à jour et qui ne pètent rien, alors ça n'a rien à faire là. Si les modifications de la distribution peut péter des configurations, alors c'est que c'était de la configuration, et il faut l'intervention de l'admin.
Et si upstart n'intégrai pas la possibilité pour l'admin de scripter, ça serait une grande régression par rapport aux scripts d'init BSD.
[^] # Re: Et pour en remettre une couche
Posté par briaeros007 . Évalué à 2.
et comment tu spécifie une option qui a changé de nom/n'existe plus/.. dans la mise à jour ?
Quoi que tu fasses, tu auras un moment ou un autre où il y a un changement qui obligera en une modification de la configuration.
[^] # Re: Et pour en remettre une couche
Posté par Batchyx . Évalué à 2.
Tu demande à l'admin. Si ça se trouve, l'option était primordiale, et sans elle, le logiciel deviens inutile dans ce cas. Ce n'est pas le genre de chose que tu peut mettre à jour automatiquement.
[^] # Re: Et pour en remettre une couche
Posté par Misc (site web personnel) . Évalué à 3.
Le fait est que les gestionnaires de paquets pourraient faire le merge automatiquement. Sauf qu'ils font pas pour la plupart ( et je dit pour la plupart, car de ce que j'ai vu, au mieux, c'est un hook avec etc-update configuré à la mano par l'admin, mais je doute pas que quelqu'un a du faire un truc plus chiadé un jour ).
Par exemple, quelqu'un avait tenté d'intégrer ça dans mandriva :
http://blog.zerodogg.org/2005/09/29/common-configuration-parser-ccp/
Quand au fait d'être incompatible, bien sur. Si la solution miracle aux upgrades existait, je pense bien qu'on l'utiliserais depuis le temps ( exemple le ccp proposé plus haut ).
Maintenant, si tu prends l'exemple d'apache qui fourni un répertoire ou tu mets ta config en plus du fichier de base de la distro, le seul risque, c'est le jour ou apache change radicalement ( passage en 2.4 ), genre une fois tout les 4/5 ans. Pas une fois à chaque upgrade de version de la distro, ou une fois de temps en temps lors d'un souci de sécurité qui va modifier la config pour bloquer l'action TRACE ou changer je ne sais pas quel config par défaut incorrect.
[^] # Re: Et pour en remettre une couche
Posté par freem . Évalué à 3.
Si, il y en a une:
Une branche stable qui ne fait que des fix de sécurité, 0 modifs de "l'API de configuration" (une conf, c'est un peu comme une API si on y pense, non?), et une branche "dev" qui comprend les ajouts/suppressions/modif de features, avec des changelog qui expliquent que telle ou telle option à vu son comportement modifié.
Pour le coup, séparer les données du code à un intérêt: on peu faire autant de MaJ de sécu qu'on veux, ça ne touche pas à la config.
Pour être honnête, cette manie de mêler le code et des constantes, c'est quelque chose qui m'a valu de nombreuses heure de débogage, et maintenant, quand j'ai une donnée initialisée par une constante qui n'a rien a voir avec le fonctionnement interne de mon appli (genre, par 0 ou 1 en fonction des index de tableau, ou un code/message d'erreur que je mets dans le texte décrivant l'erreur), ça dégage dans un fichier de conf (que la configuration aie lieu à la compilation où à l'exécution ne change pas que ça reste de la configuration) , séparé de la logique du code.
L'autre point sympa, outre la maintenance, c'est que ça génère de facto un logiciel plus souple, avec moins de limites codées en dur et pénibles à faire évoluer (je trouve que "%s/…/…/g" c'est long à taper, et encore pire quand ça contiens des /, . ou autres joyeusetés)
[^] # Vraiment ?
Posté par kadalka . Évalué à -10.
---> @daeldir
Je n'appelle pas cela de l'idiotie mais de la nonchalance… :-)
Si on vous dit que c'est une révolution, vous vous attendez à un avantage significatif.
Dans cette page, les systèmes se valent presque.
C'est un peu comme si on vous disait: systemd = 16/20 et init = 12/20
Dans la page çà me dit: systemd = 12/20 …
Et systemd a des défauts qui me dérange.
---> @Misc
Vous m'avez traité de debianeux donc je vous renvoie à vos propres contradictions.
Ben non mon bon monsieur je ne traite pas les gens de proFedora sauf s'ils le cherchent.
Donc, je marque un point.
Le fait même qu'il utilise des fichiers .ini au lieu de json ou XML me fait dire que ce n'est pas une bonne idée.
Le fait de nous faire croire que systemd a résolu le problème grâce à UN fichier de config, cela me fait doucement rire.
Beaucoup de logiciels proposent leur propre répertoire de configuration, et c'est une bonne chose.
Passons. A titre personnel, j'ai mes propres scripts qui fonctionnent sur n'importe quelle distribution et je les veux dans un endroit bien précis qui varie en fonction de la distrib.
Est-ce mal faire ?
Je ne veux pas de [mes] scripts quelque part dans un systemd ou autre, ce qui est de l'avis de beaucoup d'autres constructeurs de logiciels aussi.
Je fais même démarrer un script spécifique pour iptable au démarrage de mon compte [login].
Vous n'êtes même pas certain que c'est étanche ?
Et vous allez me faire croire qu'un admin ne sait pas gérer çà simplement ?
Dans un monde de bisounours ton environnement est clean. Même le mien, que je bichonne, n'est pas clean, mais il est très stable.
(Oui on peut être stable sans être clean lorsque l'on sait gérer son système)
Dès que j'ai lu çà, j'ai eu comme un gros doute.
Par exemple:
En gros, pour vous les Gentooistes sont incapables d'avoir une bonne méthode pour connaître les problèmes de sécurité d'un soft sans la MAJ.
Par exemple, si le OpenSSL nouveau débarque, ils ne sauraient pas ? Vous plaisantez là ?
Bref, c'est n'importe qui qui fait du Gentoo quoi. Vous êtes un peu gonflé non?
Ca prouve qu'il ne sait pas de quoi il parle. J'arrive à faire chauffer mon processeur, donc il doit bien être capable de faire fonctionner ras la gueule un serveur.
Tiens, justement, lorsque je ne fais pas attention, mon linux plante… (sauf debian apparemment)
Moi, non admin de mon état, je fais tourner Google Chrome au max [plusieurs onglets = plusieurs processus] et la probabilité qu'il plante dépasse les 50%,
et notre interlocuteur admin ne saurait pas ?
Donc, forker apache c'est mission impossible ? J'ai bien lu ?
Oui parce que cela signifie que systemd ne fait pas un bon Q&A : pas de test de ce cas.
Merci. Cela confirme qu'il faut s'en méfier car lui il utilise le .ini
Dites vous croyez qu'ils sont stupides chez Nginx, ou dans le kernel.org pour préferer un JSON like ?
Et Google qui a sa variante de JSON, il est assez fou de se passer de .ini ?
La preuve que çà marche, ils ne le suppriment pas.
Beaucoup de personnes aiment les voitures neuves, mais cela n'empêche pas d'admettre que les vieilles voitures sont solides et durent plus longtemps.
Donc, oui on peut autoriser systemd dans son repository, comme debian le fait, cela n'empêche pas de dire que c'est un mauvais soft.
(J'utilise des softs que je n'aime pas, et même parfois des distro que je débecte.)
En France, les gens veulent une voiture au diesel, donc le contructeur fait encore du diesel. Au Japon, c'est strictement interdit pour des raisons de santé publique.
Me diriez vous que nous sommes ici intelligents en voulant toujours du diesel ?
Pour le reste, j'ai lu et je vais survoler les réponses.
Vous parlez de quelque chose qui ne marche pas bien (bind, Sympa, Apache, etc.)
J'ai bien ri: on vous dira sûrement: il suffit d'écrire un script pour régler vos problèmes.
Pour LSB : LSB = Linux Standard Base: Je vois mal une distribution vouloir s'en écarter.
C'est comme si vous me dites que le C99 du language C ne doit pas être suivi…
Même cette phrase m'a surpris:
C'est le travail de l'admin de stabiliser le système pas de monsieur tout le monde…
C'est à lui de s'adapter à monsieur tout le monde est pas l'inverse !
Bien sûr si l'admin n'est pas compétent, il ne s'en sortira pas, je vous l'accorde…
Voici un bug qui m'étonne pour un système de qualité… :
Bug 894590 – MySQL server won't start after install
https://bugzilla.redhat.com/show_bug.cgi?id=894590
Maintenant je vous explique:
1/ je ne suis pas admin. Donc je dois être facile à convaincre. C'est raté.
2/ Si le gars a trop peur pour son système, il pourra toujours faire du git et/ou du svn avec son répertoire /var/* et/ou /etc/*
Avec un peu d'entraînement il va y arriver. Lorsqu'il maîtrise le processus, il automatisera la tâche…
( Last known good avec un git par exemple)
3/ Lorsque j'ai fait la remarque que systemd je ne suis pas d'accord, ce n'est pas le principe qui sous tend systemd que je ne veux pas, sinon je critiquerais durement upstart et autre runit , mais bien la mauvaise réputation de l'auteur de systemd.
Je l'ai dit l'autre fois que lorsque un type a mauvaise réputation et que c'est justifiée, je sais d'expérience qu'il faut éviter d'avoir affaire à lui et donc se passer de ses softs par ricochet.
4/ Vous affirmez que systemd c'est la révolution [non vous n'utilisez pas ce mot, mais c'est le sens de votre prose].
J'ai lu et expliqué plus haut que si c'est 12/20 les deux, on est loin de la révolution. [lire le lien que vous avez vous même donné]
5/ Systemd est refusé par deux distributions majeures et à peine acceptée par d'autres.
En effet, ils savent très bien que linux est tiré par RedHat, parce que RedHat a des sous, les autres moins.
Qui va oser s'en passer du coup ? Seuls les fortes têtes comme Pat, et debian qui tient à avoir un système indépendant peuvent se permettre de dire non.
(Ce n'est pas pour rien que BackTrack est passé chez Ubuntu…)
6/ Justement, tous les projets dont la viabilité seraient trop limitées ne seront jamais intégrés par debian, ce qui n'empêche pas debian d'accepter leur intégration.
systemd est dans le repository non ?
7/ A titre personnel, j'aime l'esprit de systemd: cela correspond à mon état d'esprit:
Bien ordonné, bonne chronologie, respecte les dépendances.
Mais le fait que ce soit d'un homme pas très recommandable et entre autre parce qu'il utilise du .ini, me fait dire que ce n'est pas du travail de pro.
Pourquoi ne pas l'avoir contruit avec un JSON like bon sang de bonsoir ?
Je dirais pour terminer que je souhaiterais que linux ne dépende pas trop de RedHat [freedesktop, xorg, pusleaudio, nouvel init (systemd), etc.].
Il y va du futur de linux.
---> @guid
Où il m'a mis la patée ?
Me mettre la pâtée c'est me démontrer que systemd est l'outil qu'il faut.
Ou avez-vous vu que je lui donne raison ?
[^] # Re: Vraiment ?
Posté par kadalka . Évalué à -10.
Tiens je suis déjà à -3 alors que je viens juste de poster…
(il n'y a pas comme un défaut là ?)
[^] # Re: Vraiment ?
Posté par gnumdk (site web personnel) . Évalué à 4.
Je pense qu'au bout du second paragraphe, je savais que j'allais cliquer sur "inutile" et pourtant j'ai tout lu jusqu'au bout…
Je pense surtout que d'un coté nous avons les gens qui parlent et de l'autre les gens qui participent (et depuis longtemps), bizarrement, les arguments des seconds sont, par défaut, plus crédibles… Surtout versus un compte qui ressemble à un multi…
[^] # Re: Vraiment ?
Posté par kadalka . Évalué à -9.
Ce qui m'aurait intéressé c'est un point de vue qui diffère du mien.
(Avec un minimum d'argumentations)
C'est possible ?
[^] # Re: Vraiment ?
Posté par O'neam Anne . Évalué à 6.
Oh, ne t'en fait pas. Tu aurais fini à -10 même en partant de 10, donc ça ne change pas grand-chose que ta note de départ soit négative.
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
[^] # Les notes n'ont pas de sens en soi, ici
Posté par kadalka . Évalué à -8.
Les notes çà n'a pas de valeur pour moi lorsqu'il s'agit d'un site.
Je sais d'expérience que ce n'est pas honnête.
J'ai souvent lu des commentaires de qualités qui sont mal notées et de mauvais commentaires plébiscités…
Disons qu'un bon site devrait trouver d'autres méthodes…
[^] # Re: Vraiment ?
Posté par briaeros007 . Évalué à 2.
ah ce commentaire est utile par contre ?
Basher sur quelqu'un c'est utile sur linuxfr.
Ben le niveau a bien diminué.
[^] # Re: Vraiment ?
Posté par Misc (site web personnel) . Évalué à 2.
D’après https://linuxfr.org/wiki/karma , tu peux aller jusqu'à -10 par défaut.
Donc, si tu es à -3, ça veut dire que tu as un karma entre -20 et -10, ce qui veut dire que tu as perdu non seulement les 20 points de base, mais aussi ce que tu as pu avoir au fil du temps. Et je pense qu'à ce rythme, tu va juste être à -10 par défaut d'ici 2 semaines au mieux.
[^] # Re: Vraiment ?
Posté par Larry Cow . Évalué à 6.
Mon dieu, j'espère bien! On est entre gens civilisés, tout de même.
[^] # Re: Vraiment ?
Posté par kadalka . Évalué à -10.
Donc traiter les gens de proFedora voire de debianeux c'est un comportement de sauvage ? 8) LOL
[^] # Re: Vraiment ?
Posté par barmic . Évalué à 6.
T'as un environnement qui tiens à peine avec des bouts de ficelles que tu ai le seul à
maitrfaire tomber en marche et tu en es fiers en expliquant qu'un outil qui te pousserais à faire mieux serait mauvais ? La prochaine fois tu nous explique que l'haskel c'est pourri parce que le typage est fort ?Homme de paille ?
Ils font quoi chez kernel.org ?
Tu parle d'absence d'argumentation, mais là tu ne présente aucun argument mis à part un argument d'autorité relativement pourris pour nous dire que ini c'est null.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Vraiment ?
Posté par kadalka . Évalué à -10.
1/ Il faut déjà me prouver que c'est mieux.
Ce n'est pas gagné et Misc ne fait que me convaincre qu'il ne faut pas s'en servir, puisqu'il est un admin qui a des potes admins chez Google…
Pour moi lorsque Misc me sous entend [il n'a pas dit] que systemd = 16/20 et init 12/20 je m'attends à une révolution.
Je constate que systemd = 12/20, comme init.
Donc, logique avec moi même, je ne prends pas…
2/ J'ai l'habitude d'utiliser ce qui me paraît être de qualité donc j'utilise debian…
debian progresse de plus en plus par rapport à fedora par exemple c'est pour cela que Misc prend mal ce que je dis.
Les demandes d'emplois sont debian, ce qui m'a surpris et pas fedora par exemple.
J'ai même lu que les entreprises recherchent du centOS, lorsqu'il s'agit de rpm based…
Qui? Moi non…
null = zero n'est-ce pas ?
Donc, si je vous suis bien, lorsque chez google ils utilisent le format json-like (je me souviens plus du nom du format) ce sont des idiots.
Je ne suis pas toujours d'accord avec les choix de google, mais pour le format json-like, il n'y a rien à redire de sérieux.
C'est une coquille de ma part désolé…
[^] # Re: Vraiment ?
Posté par barmic . Évalué à 3.
Suit un peu. Il te dis que c'est mieux de maitriser l'environnement dans le quels les services sont lancés sous peine d'avoir des bugs difficile à détecter. Pour ce qui est de tes notes, c'est toi qui t'invente des choses.
Tu es un vrai troll et tu amène le débat sur un terrain qui n'a pas lieu. Debian support systemd, il ne le propose pas par défaut c'est tout. C'est comme si tu disais que KDE ou XFCE sont bidons parce que par défaut Debian propose Gnome.
Non Tu me fais dire ce que je n'ai pas dis (c'est ça un homme de paille c'est une habitude chez toi). C'est ton argument qui est idiot. Tu nous explique que parce que je ne sais où Debian utilise du json, il faudrait que l'init utilise du json. Par contre tu es incapable de dire ce que json apporte de concret par rapport à ini.
Ça fait tout de même la moitié de ton argumentation qui tombe à l'eau. Argumentation qui était c'est utilisé chez google et chez kernel.org. Surtout que tu commence ton commentaire en expliquant qu'il ne faut pas écouter les administrateurs système de Google.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Vraiment ?
Posté par Misc (site web personnel) . Évalué à 3.
Donc attends, tu inventes ce que je dit, puis tu dit que ça correspond pas à la réalité. Et ensuite tu dit que tu n'utilises pas d'argument de l'homme de paille, vraiment ?
Vu que visiblement, tes arguments ne s'encombrent pas de précision, je vais compléter pour toi.
Le format que tu cherches, c'est protobuf :
http://code.google.com/p/protobuf/
Bien que tu ne donnes pas de définition de ton neologisme "json-like", je suppose que tu parles de ça à cause des '{' et '}' servant de délimiteurs. Ça n'a rien de json, car l'avantage du json, c'est de se lire directement presque partout. La, il faut un parser spécifique pour le .proto, par exemple.
Encore une fois, la configuration d'un service n'a pas besoin d'une structure complexe, quoi que des années de java ont réussi à faire croire. Tu définit des variables simples pour définir ce que tu veux, et le reste dépend du logiciel. Donc à partir de la, un simple format clé/valeur doit suffire. D'ailleurs, il a suffit pendant des années pour justement la fameuse philosophie unix à base de variable d'environnement ( modulo le besoin d'avoir des tableaux comme $PATH, $LS_COLORS, mais c'est minoritaire )
Donc non, je pense que chaque format a ses avantages, et à partir de la, il faut choisir.
[^] # Re: Vraiment ?
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
Pas exactement ; je me fiche de savoir si vous êtes ou non convaincu par l'explication de Misc, par contre, force est de constater que ses explications sont beaucoup plus limpides, techniques et exhaustives que l'espèce de mélange de propos sans queue ni tête qui constituent votre commentaire. Sérieusement, j'ai buté un nombre incalculable de fois sur vos phrases en me demandant ce que vous aviez bien voulu dire par là. Sans parler des petites tournures de phrase débiles qui n'apportent strictement rien au débat comme : "1/ je ne suis pas admin. Donc je dois être facile à convaincre. C'est raté."
Ho my gosh, je viens de relire le 2/, c'est encore pire que le 1/
En fait, c'est même plus fort que ça, on dirait parfois sur Jean-Claude Van Damme :
Sans parler de cette étrange obsession sur la présupposée inadéquation/médiocrité du format ini pour un fichier de configuration. Qu'est-ce qui vous fait dire cela ? De l'XML, du JSON ou du format INI, ce dernier est bien le plus lisible et est encore utilisé par un nombre infini de projets d'envergure.
[^] # Re: Vraiment ?
Posté par Misc (site web personnel) . Évalué à 3.
Bah, le .ini, c'est pas transcendant non plus.
Par exemple, il est pas formellement spécifié. Si j'ai :
Je suis pas sur que tout les parsers le lisent ( et me donne que toto a 2 valeurs, ou l'ordre ).
Genre python a 3 classe de parsers pour le .ini .
Il permet pas de faire de tableau, et de trucs à plusieurs niveaux imbriqués, n'a pas de schema ( même si ça pourrait se rajouter )
contrairement à du yaml, du xml, ou du json.
Ensuite, la syntaxe est comprise par tout le monde de façon quasiment intuitive, il y a des parsers pour tout
( même si ça peut coincer dans les détails ). C'est pas le format qui va résoudre tout les soucis du monde, mais je doute qu'il existe, et dans le cas de systemd, ça fait l'affaire. On s'en sert déjà pour le reste des projets freedesktop ( genre les menus, etc ), donc il est en plus "standard".
[^] # Re: Vraiment ?
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
Comme tu dis.
Les limites du format INI sont connues depuis longtemps mais lorsqu'il s'agît de stocker des clefs/valeurs avec une faible profondeur hiérarchique et/ou de lire/editer de façon intuitive le fichier, c'est un format de choix.
On peut toujours "bidouiller" pour stocker des tableaux dans un format INI (ajout d'un suffixe d'indexation des clefs).
Même si j'ai une faiblesse pour le JSON qui arrive à allier concision et simplicité de lecture.
Le XML par contre, sa puissance est clairement dans ses systèmes de validations/schémas, mais le reste, erk…
Pour les menus freedesktop, j'ai un peu de mal à comprendre pourquoi il a été choisi par rapport à JSON/XML, on pourrait pré-supposer qu'un menu est une hiérarchie d'entrées.
[^] # Re: Vraiment ?
Posté par Misc (site web personnel) . Évalué à 2.
Parce que le json, c'est pas si vieux que ça ( dans le principe et dans l'usage en temps que tel, car sinon on aurait pu l'avoir plus tôt ).
Et parce qu'on veut avoir 1 fichier par entrée du menu, pour avoir 1 fichier par paquet installé. Ça rends le packaging trivial. ( donc pas besoin de hiérarchie d'objets )
Et parce qu'il y a pas que des menus chez freedesktop.
Enfin, les archives des discussions sont sur le web, tu doit réussir à trouver ça ( et les devs sont encore la, y a leur nom sur les documents )
Mais bon, des choses comme nodejs utilise le json pour les metadatas, donc c'est pas non plus un mauvais choix.
[^] # Re: Vraiment ?
Posté par kadalka . Évalué à -8.
Si vous n'arrivez pas à convaincre un non admin le détenteur du pouvoir de signature refusera votre argumentation.
Vous voulez que le financier de votre entreprise accepte de signer le chèque pour la nouvelle mouture du logiciel de vos rêves ? Convainquez le.
Des admins qui me racontent qu'ils souffrent parce que le DAF n'est pas compétent pour comprendre l'importance de tel ou tel investissement technique, j'en ai souvent entendu parler.
Mon intervention à propos du diesel est si compliqué que cela à comprendre ?
En France tout le monde veut du diesel, au Japon c'est interdit de vente pour des raisons de santé publique.
Vous trouvez pertinent d'acheter du diesel ?
Donc pour systemd:
SI DEUX distributions majeures refusent catégoriquement systemd, je ne devrais pas me poser des questions sachant qu'une bonne majorité ne le prend que parce qu'il n'y a pas d'alternative qui fasse consensus ?
(debian progresse dans le monde.)
Ubuntu veut rester avec UpStart malgré les défauts cités par Misc…
Je ne suis pas d'accord avec misc mais au moins il en a parlé donc je le cite on ne me dira pas que j'ai pris l'avis d'un debianeux.
[^] # Re: Vraiment ?
Posté par briaeros007 . Évalué à 2.
marrant car j'ai vu des trucs bizarres
en attaquant upstart alors que ce sont les scripts qui sont mal fait par exemple.
en oubliant que stop-start-daemon existe, avec des scripts générique et qu'on est pas obligé de tout changer à chaque fois;
en oubliant que /etc/default | /etc/sysconfig existe aussi pour les confs spécifiques.
Bref, il y avait certains trucs qui semblaient très bien, mais qui n'étaient pas si génial visiblement.
[^] # Re: Vraiment ?
Posté par Sam E. (site web personnel) . Évalué à 2. Dernière modification le 29 janvier 2013 à 15:49.
Bizarrement, j'ai pulseaudio et systemd d'installés sur mes machines et je n'ai jamais eu un seul contact avec Lennart.
Après, je vois pas ce que la réputation de quelqu'un vient faire dans la qualité de son travail. (Réputation apparemment universellement acceptée ? Surtout ne nous pas en quoi elle est justifiée.)
[^] # Re: Vraiment ?
Posté par kadalka . Évalué à -8.
Lire plutôt les critiques sur le monsieur…
J'en ai lu quelques unes, je crois même une chez linuxfr.
Et une petition où j'ai lu le résumé des critiques envers ses logiciels m'on suffisamment convaincu.
Dans le passé, j'avais pensé comme vous.
Puis j'ai eu affaires à différentes personnes qui se comportaient mal au boulot.
Ca s'est ressenti au niveau du travail…
Je me suis juste souvenu qu'ils avaient une mauvaise réputation sur un aspect qui ne me plaisait pas.
Donc…
[^] # Re: Vraiment ?
Posté par Sam E. (site web personnel) . Évalué à 2.
Des liens vers tes sources ?
[^] # Re: Vraiment ?
Posté par Misc (site web personnel) . Évalué à 6.
lxc de base utilise le même kernel que le système hote, donc on est pas à l'abri d'un souci. C'est pour ça aussi que des gens ont mis au point des choses comme des containers confinés par selinux. En fait, je devrait même pas avoir à expliquer à quelqu'un qui a fait une formation en sécurité, comme toi.
si tu étais admin, tu travaillerais sans doute avec des admins, et tu comprendrais que non, tout le monde ne le fait pas. Il suffit de voir le nombre de gens qui ne passent pas par la commande service pour ce genre de chose.
Je dit que le projet gentoo n'a pas réussi à trouver de volontaire pour avoir les alertes sécurités par email pendant un temps. Ensuite, ouais, les gens peuvent lire à la main les listes des autres distributions sans problème.
ben, systemd le fait pour moi, donc oui. Je parle d'environnement au sens variable d'environnement.
Je crois pas que le kernel utilise un json like. Mais genre, nulle part.
En fait, nginx non plus. Un json-like, ça implique de se faire charger par un eval ( vu que le json, c'est juste du javascript ) et la config de nginx ne le fait pas. Mais la configuration de nginx a choisi d'exprimer des choses que le .ini ne supporte pas ( genre avoir une hiérarchie de réglage ), donc le .ini n'était pas bon pour eux.
En fait, je crois pas que le fait de faire d'autre choix implique la stupidité en général. Les contraintes sont différentes.
Peut être qu'il veut pas faire planter son serveur en prod. Ou peut être qu'il a mieux à faire que de faire des comparatifs. Mais son email est sur le site, tu devrais directement lui dire de lancer google chrome avec des tas d'onglets sur son serveur, histoire qu'il puisse compléter l'article.
Donc pourquoi personne chez debian n'a écrit de script pour ça ? ( sauf à nier la race condition que j'ai évoqué, et à me dire ce qui ne va pas dans le raisonnement )
ah, la bonne vielle idée de mettre /etc dans git ou svn. J'ai déjà tenté, comme tout le monde. Et comme tout le monde, j'ai vu que c'était une idée à la con.
Déjà, tout ne rentre pas dans git/svn. /etc/localtime, un superbe fichier binaire, n'a rien à faire la. /etc/password, qui va changer aprés chaque installation de demon, c'est pareil. Tout les fichiers avec des mots de passes, c'est pas terrible. Et puis, ça gére pas forcément bien les owner des fichiers. Ou le stockage des liens, ça coince ( ou du moins, c’était pas bon à l'époque ). Ensuite, bah, /etc/ c'est pas tout ce qui sert à ton systéme, vu qu'il manque les paquets, etc. On va me dire "mais y a aussi /var/ dans sa proposition". Oui, parce que c'est bien connu, on peut prendre la base des paquets rpms ou deb et pouf, ç'est bon, ça se mets dans un vcs sans prendre une tonne de place, sans poser des soucis avec les diffs parce que c'est du binaire. Et surtout, ça bouge pas à chaque upgrade.
Et au final, on a quoi ? Ben rien, parce que ton dépôt, tu peux pas l'appliquer à une autre bécane sauf à vouloir un clone imparfait. Tu peux tout juste revenir en arriére d'un coup.
Mais en fait, quand on fait les choses bien, on utilise un outil comme puppet, chef, cfengine, etc. Comme le font toute les grosses distros comme dit à une table ronde au fosdem l'année dernière.
Alors, à peine accepté, c'est ni l'avis des gens de Mageia, ni l'avis des gens d'Opensuse. Ni des devs d'archs.
Et Suse a des sous, ils sont numéro 2 sur le marché, ( voir 1 sur certains marché ssi j'en croit leur plaquette ). Si ils voulaient refuser, ils pourraient. Par exemple, ils ont ni anaconda, ni yum.
Quand à Canonical, ils ont aussi assez de sous pour faire unity ( donc refuser gnome 3 ou kde ), pour faire tourner une boite de 400 ou 500 personnes, pour avoir son propre truc de gestion de cloud ( juju, maas ), voir même pour faire son propre systéme d'init. Donc j'ose supposer à partir de la 2 choses :
- si une boite qui gagne pas assez pour être à l'équilibre ( aka canonical ) a les moyens de pas suivre RH, d'autres ont les moyens. L'argument des sous est donc faux.
- si les distrib totalement communautaire veulent prendre openrc, upstart, init-ng ou juste garder sysvinit ( ce code shell si facile à maintenir, je pige pas que personne n'ai encore fait de fork à la MATE ), elles peuvent aussi. Y a rien qui les force.
Tu semble n'avoir aucune idée de la façon dont une distribution marche ou de la façon dont les décisions sont prises, donc tu te raccroche à un modèle erroné ou l'argent règne.
un bug ou le reporter n'a plus rien posté depuis 10 jours, ce qui nous laisse un peu sur notre faim sur son origine ou le problème réel. A plus forte raison si personne n'arrive à reproduire.
Parce que c'est pourri ?
Soit c'est du json, et c'est pourri pour de la configuration ( exemple, comment on fait un commentaire en json ).
Soit c'est du truc qui ressemble à du json ( cad, dans le cas que tu cites, nginx, un vague format avec des {} ) et c'est chiant à parser ( vu que c'est plus du json, tu oublies les outils classiques), et ça revient à faire ton propre DSL. Ce qui revient à augmenter encore la courbe d'apprentissage pour rien ( car ton histoire de json-like, en d'un péremptoire "c'est pas pro", ça apporte quoi ? ). Et c'est pourri.
Un peu dans tout les commentaires. Dans celui la aussi.
ça va être dur :
http://community.redhat.com/contributions/
Mais en effet, moi, j'aimerais bien aussi que l’origine des contributions soit plus varié.
Et pour ça, y a pas de secret, faut se bouger. Je suis sur qu'un spécialiste du sujet devrait sans souci apporter son expertise à un projet.
Sinon, bah, juste soutenir opensuse ( ah non, la communauté choisit plutôt de ressortir des trucs sans rapport datant d'il y a 5 ans ce qui démotive les rares gens motivés ), soutenir nokia ( ah non trop tard ), filer du pognon à Canonical ( ah non, personne paye ) ou à Mandriva ( ah non, comme Nokia ), enfin bref, injecter de l'argent dans les boites qui contribuent autre que RH.
[^] # Re: Et pour en remettre une couche
Posté par reno . Évalué à 3.
La plupart des avantages de systemd que tu décris me semblent en fait lié à l'utilisation des cgroup, les autres systemes d'init ne les utilisant pas car ils ont été crée avant les cgroup..
[^] # Re: Et pour en remettre une couche
Posté par Anonyme . Évalué à 4.
Non, il y a egalement pleins d'avantages qui n'ont rien à voir avec l'utilisation des cgroups. Par exemple ne plus avoir à se soucier de l'ordre de démarrage des services, ou la possibilité de les demarrer uniquement lors de leur première utilisation, c'est rendu possible grace à la création des sockets par systemd.
[^] # Re: Et pour en remettre une couche
Posté par briaeros007 . Évalué à 2.
dès que tu vas faire mumuse avec ta machine, tu vas vouloir contrôler ça…
Exemple con : un service qui est prévu pour démarrer après les "local_fs", et toi tu décide que le fs sur lequel il va se lancer, il se lance bien après (dépend d'un daemon spécifique, SAN qui met une plombe a se connecter et donc tu le met en background etc…) .
Ben c'est utile de pouvoir dire "euh pour ce service, tu vire cette dépendance et tu prend celle là", plutôt que tout soit géré automagiquement.
(par contre je ne sais pas si systemd le gère facilement ou pas ce cas là)
[^] # Re: Et pour en remettre une couche
Posté par reno . Évalué à 1.
Hum, ça c'est très bien quand ça marche, mais s'il y a un problème ce sera bien plus pénible à débugger qu'avant..
# Effectivement, c'est de la mauvaise foi !
Posté par calandoa . Évalué à 2.
« Un peu de mauvaise foi, avec les *BSD qui reprochent surtout l'intégration poussée de systemd aux environnements de bureaux. »
Systemd intégré aux environnement de bureau ? Ils veulent dire qu'on peut le configurer grâce à une GUI depuis l'interface de contrôle du bureau ? Il n'a pas dû être trop compliqué à détruire ce mythe…
Bon, sur ce,
systemd --user start exit.target# Je ne suis toujours pas convaincu
Posté par Hobgoblins Master (Mastodon) . Évalué à 2.
D’autant que je viens de tomber là dessus : http://www.pappp.net/?p=969. En lisant ça, j’ai la curieuse impression que la prochaine étape vu que c’est pas très user friendly d’éditer des fichiers de configuration ou d’ouvrir un terminal dans Gnome sera de gérer la configuration de systemd via d-conf…
Au fait, il toujours possible d’utiliser les cgroups pour autre chose que séparer les services avec systemd ?
[^] # Re: Je ne suis toujours pas convaincu
Posté par Misc (site web personnel) . Évalué à 5.
Oui lxc marche avec les cgroups et systemd ( même en dehors du framework libvirt-sandbox http://fedoraproject.org/wiki/Features/Securecontainers )
Lennart explique sur un des nombreux blogs posts ce que systemd fait avec les cgroups :
http://0pointer.de/blog/projects/cgroups-vs-cgroups.html
Et il y a une documentation sur comment ne pas se marcher sur les pieds si tu veux utiliser les cgroups aussi :
http://www.freedesktop.org/wiki/Software/systemd/PaxControlGroups
Sinon, le blog que tu as pointé manque de perspective, par exemple, sur l'histoire du /usr merge, il ne pige pas que le role de / est passé à l'initrd, et que dont celui du /usr partagé est passé à tout /usr par le dit merge, ie, que c'est en faisant un système minimaliste à façon qu'on règle le problème du bloat de /.
Il dit que le passage à /run a été d'ignorer le FHS, mais justement, le changement vers /run fait parti du FHS 3.0 justement parce que les distributions se sont mis d'accord ( https://bugs.linuxfoundation.org/show_bug.cgi?id=758 ), et que le passage vers un sous dossier de /run est pour des questions de robustesses ( ie, pour une ressources non partagés sur un système qui lui est partagé , pour éviter les conflits de nom ).
Les divers changements sont pas la pour faire joli, en général, ça vise à tenter de corriger des vrais soucis. Personne ne se rajoute du boulot pour rien, y a déjà assez à faire sur les distributions classiques
[^] # Re: Je ne suis toujours pas convaincu
Posté par Ignatz Ledebur . Évalué à 3.
Le point de blocage 718, dont dépend celui que que tu pointes et qui traite précisément de la question est toujours ouvert.
Le "standard"*, quant à lui, ne mentionne toujours /run que comme un remplacement de /var/run ; nulle-part il est question de placer des points de montages dans ce répertoire, qui est le second reproche de l'auteur du blog.
À l'inverse, le "standard" continue à spécifier une séparation claire entre /bin et /usr/bin, ce qui fonde le premier reproche fait (qui est que ça enfreint le FHS).
* je mets des guillemets, parce que FHS 3.0 n'est visiblement qu'à l'état de (premier) brouillon, ce qui devrait suffire à qualifier la version 2.3 de seule source d'autorité valable. Mais bon, maintenant qu'on a sorti le concept un brin oxymorique de standard rolling release, ne soyons pas bégueules.
[^] # Re: Je ne suis toujours pas convaincu
Posté par Misc (site web personnel) . Évalué à 2.
sauf erreur de ma part, le blocage est de savoir si les admins peuvent ou pas mettre /run sur autre chose qu'un tmpfs.
Et le reste est commité dans le draft.
https://bugs.linuxfoundation.org/show_bug.cgi?id=718#c13
Et je pense que tu as visiblement une idée bien précise sur la façon dont le standard doit évoluer, à savoir d'abord discuter et ensuite coder. Ça, ça s'appelle du design by comitee. Parfois ça marche. Parfois ça marche pas.
Si la FHS fonctionne autrement et se décide à juste documenter le consensus, ça marche aussi. Donc au final, si les distributions y trouvent leur comptes, qui va être emmerdé ?
Malheureusement, le commit ne donne pas des masses de détails.
De ce que je vois, le changement a 2 composantes : passage sur un tmpfs ( donc /run, supposement tmpfs par défaut ) et passage dans un dossier utilisateur ( /run/media/$USER/$DISQUE ).
Mettre /media en tmpfs aurait sans doute été un problème pour les mises à jours ( ie, changement de comportement ).
Donc tu doit prendre /run ou un autre chemin.
Mettre /run/ entier, c'est niet. Donc un sous repertoire. /run/$USER ou /run/$DISQUE, y a des risques de conflits ( surtout /run/$DISQUE ). Donc ajout de /media, nom fixe.
/run/media/$USER, ça permet de monter 1 disque à la fois, ce qui est niet.
/run/media/$DISQUE, ça marche dans les cas simples, mais pas dans le cas d'une station ou plus d'une personne peut se connecter ( le fameux multiseat qu'on a tous deja utilisé via ssh ). On retrouve çavia du thin client, etc. En effet, si tu fait ça, quelqu'un peut mettre une clé du même nom, et toi, au mieux, tu te demandes laquelle c'est, au pire, tu écrit sur la mauvaise. De surcroit, avec des clés en fat32 ( ou en udf, comme Tanguy le propose sur son blog ) en lecture pour tous, il y a une fuite de données évidentes ( ie, tout le monde peut lire ma clé avec mes documents via ssh ). Une solution alternative serait de faire le montage en forcant l'umask et les droits, mais tout les fs ne le supportent pas; et il y a peut être un souci caché que j'ai pas trouvé dans cette façon de faire ( ne serais que parce que sauf erreur de ma part, aucune distro ne le fait ).
donc /run/media/$USER//$DISQUE, avec $USER ayant des acls.
Bien que je n'ai pas pu tester, je pense qu'une solution au problème d'avoir à taper des chemins plus long serait pour l'utilisateur expert de rajouter son device directement dans /etc/fstab. Udisks respecte les réglages et devrait du coup monter la clé la ou c'est demandé.
Le souci, c'est que la FHS dit juste "faut mettre les commandes pour monter les autres fs", en ne spécifiant rien.
Du coup, tu te retrouves à mettre tout ce qui pourrait servir à un moment à monter un disque dans /. Donc par exemple, sur debian, une des rares distros à se donner la peine de le faire proprement ( vu que les autres s'en foutent un peu, dans le sens ou personne ne teste vraiment, et surtout, personne n'ouvre de bug ), tu as tout les fs réseau et toutes les dépendances dans /lib, /bin, et /sbin/. Et j'ai eu du mal à trouver un contre exemple, mais j'ai fini par en trouver 1 ( aprés 4/5 essais ). Si tu veux avoir ton /usr en iscsi, tu peux pas :
http://packages.debian.org/sid/alpha/open-iscsi/filelist car les commandes sont dans /usr/
( et le iscsi est vachement plus courant que l'exemple capilotracté de sshfs que j'aurais pou sortir, ou celui d'avoir ton /usr en afs via kerberos ( http://packages.debian.org/sid/armel/openafs-client/filelist ))
En pratique, le fait d'avoir tout dans /usr, ça permet de faire des containers plus facilement ( ou justement, de monter totalement /usr via le réseau comme avant sans avoir à garder le /bin local en synchro avec le /usr distant ), ça permet de faire des rollbacks plus facilement ( même si personne ne le fait, je pense que snapper devrait réussir à en tirer parti sous peu ). Je comprends que ça dérange, car la migration entraine un risque, parce qu'on a le sentiment de bousculer l'ordre établi ( un comme avoir quelqu'un qui range ton bureau, ça te fait toujours chier ).
Mais en pratique, c'était à la bonne franquette pour savoir quoi était ou, et c'était pas terrible la façon dont les distros l'ont mis en place.
Ensuite, tout le monde n'a pas suivi, et pour l'avoir fait, je doit reconnaitre que si on m'avais pas dit, j'aurais sans doute rien remarqué tellement c'était sans douleur. Il ne reste plus qu'à attendre que quelqu'un en tire parti.
c'est sur un tmpfs pour pouvoir nettoyer tout seul le truc. C'est pas déconnant. Et pour des questions de sécurité, de simplification
[^] # Re: Je ne suis toujours pas convaincu
Posté par Ignatz Ledebur . Évalué à 2.
J'ai surtout une définition assez commune de ce qu'est un standard, à savoir un document public consolidé avec un numéro de version. De sorte qu'on peut ensuite simplement écrire «Bidulle se conforme au standard » sur ce qu'on produit (avec éventuellement une liste d'exceptions motivées) pour que tout le monde sache de quoi on parle.
Si on veut quelque chose de plus souple, on peut recourir à un système de RFCs. Dans tous les cas cependant, on publie des documents identifiables auxquels tout le monde peut se référer par la suite. Un standard qu'il faut aller chercher dans les sources XML, j'appelle ça poliment un (gros) abus de langage.
Note que je ne suis pas particulièrement fan du FHS, simplement je trouve que l'auteur du blog a parfaitement raison lorsqu'il dit que c'est une violation du standard*. On peut tout à fait déclarer (après avoir bien cassé les pieds à tout le monde) que le FHS est mort et que désormais les décisions se prendront en semi-huis-clos entre les équipes des grosses distros, mais on ne dévoie pas la notion de standard pour cela.
* après, si c'est bien ou pas, je n'en sais rien, n'utilisant pas udisks, et n'ayant jamais eu à me servir de /media (je préfère jouer avec les LABELs dans le fstab).
[^] # Re: Je ne suis toujours pas convaincu
Posté par Misc (site web personnel) . Évalué à 3.
Ensuite, on rentre aussi dans la sémantique. par exemple, dire que tout ce qui n'est pas interdit est autorisé. Et c'est pas interdit d'avoir d'autres repertoire haut niveau, et que les liens permettent de garder la compatibilité. Dire que si tu trouves ton soft dans /bin/ alors les executables pour booter y sont.
Enfin, je pense que personne ne suit à la lettre la FHS. Exemple gentoo à /usr/portage ( alors que ça devrait être dans /var ), Debian a du /usr/games, avec des régles en plus, Fedora/RHEL ont longtemps eu /selinux, et ont toujours /usr/libexec ( suivant les gnu coding standards http://www.gnu.org/prep/standards/html_node/Directory-Variables.html ).
Donc au final, c'est aussi pour ça que je trouve l'auteur du blog comme se focalisant sur les détails "visibles", alors qu'il y avait déjà plein de problème. Le fait d'avoir un /usr/libexec pose des soucis pour les outils qui codent en dur les chemins tout comme /usr/games. ( et c'est juste les détails que j'ai en tête un dimanche matin avant le fosdem ).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.