C'est juste que sqlite est un exemple particulièrement mal choisi, tu aurais pu parler directement des mbox :p
Oui. Mauvais exemple. J'ai changé d'exemple. Mail Dir - Dovecot est un meilleur set pour se placer dans une situation similaire (nombreux fichiers, sous répertoires, "logueur" centralisé) et avec des performances assez bluffantes.
Ben ça dépend ton index il est en binaire ou pas ? S'il est en binaire pourquoi diantre l'est-il ?
Ok on va replacer les choses dans le contexte.
On me dit que l'on ne peut pas indexer ou rajouter des métas à un fichier sans placer le fichier lui même au format binaire (et donc non lisible humainement). Je répond que si on peut.
Maintenant effectivement l'index lui même n'a aucun intérêt à être lisible humainement. A partir de là le mettre au format texte serait un pur gaspillage de place. Ce qui ne change rien au fait que l'on peut avoir à la fois des gigas et des gigas de données au format texte ET un index et des métas très performantes sur ces données.
SQLite étant un mauvais exemple je vous présente mes excuses pour l'avoir utilisé - et je vous propose comme exemple de rechange un systèmes de fichiers qui contient des boites au format maildir et avec dans le role de l'indexeur/placeur de meta le serveur dovecot.
Vous avez des giga de données texte, un système d'index et de cache performant, un systême qui peut être accédé par plusieurs clients simultanément en lecture/écriture sans trop de soucis et qui tourne en prod de façon nickel chez suffisament de personnes pour que l'on ait du mal à dire qu'il s'agit d'un exemple ultra-spécifique que moi seul ait vu dans un monde imaginaire à venir.
Es-ce que ça vous va comme exemple pour comprendre ce que je veux dire ?
Il y en a qui s'y mettent 2 ans après la sortie d'une version (le plus classique)
Au risque de me répéter : C'est l'init.
C'est pas programme dans un coin que je peux utiliser ou pas, upgrader ou pas. En RHEL 6 il y a pleins de trucs que je n'utilise pas, comme networkd, SELinux, les outils graphiques etc. mais il y a des trucs très récents que j'utilise (typiquement on a la dernière version de kvm/libvirt).
La question n'est donc pas "est-ce qu'on prend ou est-ce qu'on ne prend pas ?" mais "est-ce qu'on se repositionne par rapport à RHEL ou pas ?".
Même si on décide de ne pas passer en RHEL 7 (pour cette raison, ou pour d'autres) on a au minimum 3 ans pour changer. Après on rentre en "production 2" et ça peut poser des soucis. Mais trois ans pour faire les tests, choisir un remplaçant, valider la nouvelle archi et la faire certifier c'est pas non plus la fête. On est confortable, mais pas trop.
Là pendant à peu près un an (jusqu'à la première beta) on va être dans le noir. Donc on peut dire qu'on aura deux ans de marge. Sans être tendu ça va commencer à être un peu serré.
Donc oui, j'aimerai avoir les infos maintenant. Ne serait-ce que pour préparer la direction à accepter que le budget 2014 soit plus conséquent que les années précédentes (que l'on reste avec RHEL ou pas d'ailleurs).
L'index binaire est stocké dans le même fichier que le "texte" (qui au final est juste un ensemble de strings C dumpées telles quelles dans un fichier binaire), c'est donc de facto un fichier binaire.
Donc si je résume on ne peut pas indexer ou rajouter des metas à un fichier texte, parce que si on le fait il devient de facto un fichier binaire ?
C'est impossible, mais on va le faire et quand on aura fini ça ne sera plus un fichier texte qu'on aura indexé ?
Et si on met l'index à coté (genre un index séparé sur une base de données type mbox, le container mail) ca compte ou pas ?
Et si il y a des pièces jointes en base64, le fichier il est binaire ou pas ?
Non sérieusement les gars. Si je fais un less de mon fichier de données SQLite, j'ai du charabia qui s'affiche ou je peux voir mes données ?
Ca tombe bien, systemd a un mode de compatibilité sysvinit
Qui a de grosses lacunes, on en a déjà discutés plusieurs fois.
Cool, ben il va falloir que ces boites pensent à les foutre à la porte alors, parce que bon, les vieux croutons qui refusent d'apprendre parce qu'ils ont toujours fait comme cela, en informatique, on sait ce que ca donne…
Elles ont plutôt tendances à foutre à la porte les jeunots qui savent mieux et qui installent la dernière version sans réfléchir (parce que c'est forcément mieux). Ce sont eux qui font des dégats que les vieux croutons doivent réparer.
Alors pour quoi tu nous prends pour des truffes en disant :
_"il me semble que les distributions serveurs (comme Suse Entreprise ou Red Hat) envisagent très sérieusement de ne PAS passer à systemd" _
C'est dans leur distribs betas, c'est dans le code des paquets mais ça n'est officiel nul part. Comment tu interprètes toi qu'un papier qui dit que Suse Entreprise Server utilisera systemd soit retiré ?
Le truc c'est que soit ils ont décidé de mettre systemd quoi qu'il arrive, mais qu'ils tiennent absolument à nous faire la surprise (ce que tu as l'air de penser), soit ils ne sont pas sur de mettre systemd.
Le support ne parle jamais des produits en cours de développement, et c'est pareil dans toutes les boites que j'ai fait,
Et dans la plupart des cas j'en ai rien à faire. Mais dans le cas présent si il faut porter tous les scripts d'init custom j'aimerai pouvoir commencer en avance. Maintenant je ne suis pas categoriste, si le support n'a pas le droit de répondre, je prend la réponse de n'importe qui d'officiel à la place. Seulement cette réponse (à l'heure actuelle) je ne l'ai pas.
Le fait que Solaris soit passé à smf est la preuve qu'on peut survivre à un changement de système d'init.
J'ai aucun problème avec un changement d'init. J'ai un problème majeur avec systemd. SMF est une réussite et si on pouvait avoir un truc pareil sous Linux je ferais des bonds de joie. Les points forts de SMF sont :
- Tout un système basé quasi exclusivement sur les templates : tous les services sont des templates, et on peut facilement créer et détruire des instances à la volée en changeant les paramètres de configuration ou en dupliquant une instance existante.
- Des dépendances ultra-réduites. Pas besoin de ramener une pléthore d'outils pour que ca marche.
- Un grand respect de l'existant : les scripts de rc.d/* continuent d'être executés. inittab est toujours parsé etc.
- Un système turing complet avec des vrais outils pour manipuler l'environnement d’exécution des services aussi bien avant le démarrage que pendant l’exécution.
Et pléthore d'autres trucs qui font cruellement défaut à systemd.
Si on se logue trop tôt et qu'on utilise NIS. Et comme tu dit, c'est corrigé dans une nouvelle version systemd.
Le problème n'est pas là. Le problème est comment une interaction de ce type peut-elle tromper l'init et le faire se comporter de façon nocive pour le système ? Un getty crashe (ca peut arriver), ben on le relance.
Ce qui est le comportement standard de sysvinit et de tout les autres. Et d'après le bug, c'est plymouthd qui bloque.
Une fois de plus le problème n'est pas la. Que /var ne se démonte pas parcequ'il est locké OK, mais pourquoi au reboot systemd devient-il incapable de monter /var ? Je n'ai jamais eu d'erreur de type 'ah non, il y a un fichier de lock alors j'interdis le montage' sur sysinit ou sur bsdinit. Comment un fichier à la con peut-il empêcher /var de monter ?
Que le fichier vienne de plymouth on s'en fout.
Un boot pas à pas dans un système prévu pour lancer les choses en même temps est ma foi un concept des plus intéressant.
Au hasard parce que justement comme le système n'est pas prédictif, j'aimerais bien pouvoir lancer B avant A pour voir ce qui se passe. Par exemple si j'ai un bug qui se produit une fois sur 5 ou 6 et que je pense que c'est la fois ou le service TUTU se lance avant le service TOTO qui est normalement toujours premier à s'executer. Là pour faire ce genre de tests il faut que je fasse dépendre artificiellement TOTO de TUTU (et bien entendu que je remette les trucs dans le bon ordre si c'est pas ça). Si j'ai trois ou quatre hypothèses je vais me marrer.
C'est pas un souci de systemd, c'est un souci de nfs sur Suse, et Fedora 18 propose les unités pour nfs.
Non. C'est bien un manque de systemd (pas un problème à proprement parlé, mais un comportement inattendu) que l'on peut contourner. Les sockets virtuels foutent la grouille entre les différents process de NFS et comme automount part très vite on est obligé de broder un peu pour que ypbind et autofs soient actifs et en forme pour de vrai au moment ou automount vient les chercher.
Comme dit dans le bug report, tu t'attends à quoi ?
Tu es en train d'insinuer que c'est un comportement normal de tuer l'init quand un disque ram est plein ? Comme dit le bug report une ligne plus bas, je m'attends plutôt à ce que l'on arrive sur un refus genre "disque plein" avec des retry et des purges (enfin comme sur n'importe quel autre fs quoi).
Donc je compte 2 bugs déjà corrigés, 2 bug à corriger ailleurs ( nfs, plymouthd ), et 1 "why did you expect".
Donc bien 5 bugs, des trucs qui peuvent se produire et qui explosent l'init.
Et les corrections ne sont pas coté systemd (genre ah oui, dans ce cas dégénéré là ca empêche l'init - c'est embêtant quand même) mais coté des outils. Genre ok le logiciel de haut niveau TOTO a planté l'init, mais c'est de sa faute il a pas fait les appels comme il faut et c'est corrigé dans la version 4.2 du logiciel TOTO.)
Le problème est que le logiciel de haut niveau TOTO ne devrait pas pouvoir planter l'init. Pas du tout. Bordel c'est l'init ! Ca doit être bétonné.
Comme avec chaque version majeur. Est ce qu'ils ont eu des tonnes de boulot avec upstart sur les RHEL 6 ?
Grosso modo upstart ca a foutu la grouille dans les configs TTY à la con et les runlevels custom, mais c'était pas bien méchant au final. Ne serait-ce que parce qu'on avait toujours les scripts et l'environnement.
Sinon, quand tu payes la souscription RHEL ou SLES, c'est aussi pour que le distributeur fasse les tests
Le distributeur il t'aide en cas de pépin et il peut débugguer des trucs pas évident. Mais il n'a pas un clone de ton install chez lui. Donc pour faire les tests…
Le mot de passe à l'init, une riche idée quand le systéme est sequentielle car ton serveur se bloque en attendant de rentrer le mot de passe, c'est pas du tout fragile au possible.
Les trucs qui dépendent du mot de passe sont nécessairement bloqués (en fait c'est même le but d'un mot de passe) - Les trucs qui ne dépendent pas du mot de passe continuent. Quand il y a plusieurs mots de passe, pour s'y retrouver on affiche un texte explicatif (Genre veuillez rentrer le mot de passe pour le certificat truc de l'instance apache www.example.com )
Je pense au passage que c'était pas possible non plus avec upstart qui dans mon souvenir lance les trucs en parallèle.
Si si, ça marche très bien. Parce que upstart execute des scripts et sait mettre les demande d'interaction utilisateur à la queue leu leu.
Quand aux templates, j'ai deja du dire que ç'est prévu par systemd, et la dernière fois, tu as sorti un exemple super compliqué
Un truc super compliqué : une variable d'environnement dont le contenu n'est pas fixe.
Un autre truc super compliqué : le résultat de l’exécution d'un autre service.
Heureusement ça arrive rarement les service qui donne des résultats ou les variables d'environnement qui changent.
Formidable ça. Parce que upstart ou l'init classique sysinit, c'était normalisé ?
Non mais c'était turing complet. Donc on pouvait TOUJOURS trouver une solution ou un contournement.
Bie sur, tu va trouver sans doute des cas de scripts hors lsb qui ne marche pas, et dire "bah ça marche pas".
Il y a des scripts d'init full LSB qui ne marchent pas. Pour les partitions chiffrées notamment.
Sqlite utilise un arbre binaire ( b-tree ) pour accéder à des enregistrements ( records ).
Oui.
Ca s'appelle un index.
Ca permet de savoir à quel endroit de quel fichier se trouve l'information.
Donc ils ont indexés des fichiers majoritairement texte.
Et ils ont mis des métas aussi.
C'est ce dont on parle.
Enfin je crois…
Mais apparament je parle le klingon.
Et encore, peut-être qu'en klingon je me ferais mieux comprendre.
car "Red Hat Enterprise Linux Roadmap: Part 1", ça ne se traduit pas vraiment pas "truc qu'on envisage". Si c'était "stuff that we are looking at", ou une expression similaire,
Et si par exemple c'était dans la partie "Development Topics" slides 31 à 37 qui liste les limitations, les améliorations et les éléments qui sont en cours d'études et de développement, il se passerait quoi ?
Je pourrais sans doute continuer pendant des heures, mais je vais pas m'acharner sur le sujet
Surtout que tout ton argumentaire repose sur le fait qu'il fasse leurs études et tests sur Fedora, chose que j'ai signalé dans mon post au fait. Et que donc il va leur être difficile de na pas mettre systemd dans RH 7 (ce que j'ai dit aussi).
je suis sur que tu as des tas d'arguments et de témoignage de gens qui sont super proche du pdg de RH
Ben justement non j'en ai aucun. Que ce soit chez Suse ou chez Red Hat ca joue à ni oui ni non. Même le support (payant) RH est pas foutu de répondre à la question "dans RH7 ca sera systemd ou sysinit ou les deux".
Or le truc c'est que dans le milieu professionnel les "c'est évident" et les "ca se voit" on a tendance à s'en méfier pas mal. (Surtout avec RH à qui ca ne fait pas peur de faire passer à la trappe une techno du jour au lendemain).
_ et que même si Arch et Mageia ont fait la migration avec 3 bouts de ficelle sans soucis majeurs, c'est impossible que des boites avec plus de moyens fassent de même_
OK. Donc tu n'as juste pas compris le problème en fait.
En dehors des utilisateurs qui utilisent Linux pour s'amuser et s'instruire, il y a des sociétés (parfois même des grosses sociétés) qui utilisent Linux pour traiter des données sensibles, des fois vitales à la boite, dans leur activité de tous les jours. Ces sociétés ne représentent pas une portion très importante des utilisateurs de Linux, par contre elles représentent 100% des clients payant de boites comme RH ou Suse.
Or ces sociétés ont souvent des scripts, des outils, des programmes même codés maison et qui utilisent la puissance de l'init traditionnel pour fonctionner (processing turing complet, prise en charge des variables d'environnement, init prévisible, logs dans des fichiers plats etc.)
Je n'ai pas vraiment de vision sur ces sociétés, je n'en connais que trois. Mais les trois que je connais (en l’occurrence leurs sysadmin) ne veulent pas de systemd. Et ils n'en veulent pas parce que :
a) Il y a beaucoup de boulot et de tests à faire pour s'assurer que tout fonctionne.
b) Certaines choses (certains fs chiffrés, demande de mot de passe à l'init par service, templates etc.) ne sont pas possible avec systemd.
c) Systemd n'est pas fini/normalisé et du coup même si ils trouvent des parades aujourd'hui rien ne prouve qu'elles seront encore valables dans dix jours (spéciale dédicace udev)
Le fait que ArchLinux et Mageia ait fait le pas en tant que distrib ne prouve rien au niveau de l'utilisabitlité du bigniou par des sysadmins.
Ah, on me dit dans l'oreille que c'est pas parce qu'il y a marqué systemd dans un rapport de bug que c'est un bug sur systemd et que ta liste est utilisé juste pour du FUD. Dommage, presque crédible.
Ah oui, je donne la liste mais j'ai oublié de dire qu'il fallait lire :
Bug 774126 : si on se logue trop tôt sur une interface série le getty crashe définitivement. Il existe une solution mais elle est trop complexe pour être backportée
Bug 779434 : pas de splash dans le boot kernel, pas de /var. Systemd refuse de monter le /var si plymouthd a un fichier de lock qui traine dessus. COOOL
Bug 780006 : Un boot pas à pas dans systemd ? Vous plaisantez bien sur. De..bug ? Jamais entendu parlé.
Bug 780441 : L'automount NFS ne marche pas (pas chez Fedora non plus) - mais on a presque fini d'avoir une bonne idée sur comment contourner le problème. (N.B : ce bug a une priorité P5 - none. Autmount NFS ? Ca interresse quelqu'un ? )
Bug 767394 : Un disque plein ? C'est un scandale ! Je me casse… (signé systemd).
Après tu fais comme tu veux, mais moi ce genre de bugs sur des trucs que j'utilise couramment (pas comme le timer du device machin sur une architecture ARM spécifique que l'on ne retrouve que sur des téléphones portables hackés) ca me fait peur.
L'init doit être le process le plus robuste qui soit. C'est lui le centre névralgique du système. Si il bugue on ne peut plus rien faire. L'init est presque plus importante que le kernel au niveau debug (une bonne init peut permettre de comprendre ce qui a chié dans le kernel, la réciproque n'est pas vraie).
SQLLite ? Par exemple hein, il y en a un paquet d'autres (Pas mal de backends LDAP par exemple)
De façon générale il existe une palanquée de "flat file database" dans lequel le bianire est l'exception plutôt que la règle.
PS : jamais compris pourquoi des gens arrivent à se braquer sur un format "binaire" pour défendre un autre format binaire
Oui en vrai tous les formats sont binaires. Surprise il n'y a pas de petits caractères en fonte dans les processeurs. Et pourtant on fait le distinguo.
Un indice : Lisible facilement par un être humain et éditable facilement avec des outils standards.
Pourquoi c'est pas fait?
Sur les systèmes qui en ont besoin, c'est fait.
Mes logs DNS/Apaches sont indexés par exemple.
Pourquoi rajouter encore plus de volume de données pour faire la même chose? chez vous les disques durs sont gratos?
Parce qu'un meta en INT LE 64 bits ça ne prend pas de place ?
Le format ASCII prend de la place mais le format binaire c'est gratuit ?
Au risque de te surprendre, le fait que les disques durs ne soient pas gratuit est une excellente raison de ne pas mettre :
- 12 000 métas sur des entrées ou ca n'apporte pas grand chose
- Une nouvelle palanquée d'outils pour lire et trier ces métas
- D'autres outils pour gérer la corruption des données (oui en ascii la corruption d'un octet ca peut faire chier mais pas plus que ça, alors qu'en binaire)
- Et bien sur toute la clique de convertisseurs pour les programmes qui ne parlent pas encore le journald couramment (et dont même en cherchant bien on ne voit pas pourquoi ils apprendraient à le faire)
_ Il y a des gens qui ont des Go de log (surtout sur 1 an, minimum légal), et remercie journald et son format "binaire avant c'était pas binaire" _
1) Personnellement j'ai des Go de logs par jour. Avec des scripts baysiens pour foutre à la poubelle ce qui n'a pas d’intérêt et ne stocker que le nécessaire.
2) Je ne connais personne qui a des Go de logs à maintenir et qui dise merci au format binaire. Pourtant du sysadmin j'en connais - mais même ceux qui sont éventuellement intéressés par journald sont rebutés par le fait qu'il faille rameuter systemd et toute la clique pour que ça marche.
sans supprimer un seul avantage du avant
A part la non lisibilité par un humain, le surplus de maintenance, le coté non standard/non fini, la non intégration dans l'existant, les dépendances, la fragilité à la corruption etc.
_ En attendant, il y en a un qui se bouge le cul, lui, et il a l'air de bien répondre à un besoin de beaucoup de monde…_
Tant mieux pour eux. Bon je ne connais pas ce "beaucoup de monde" là. Le beaucoup de monde que je connais est plutôt contre systemd - mais bon il en faut pour tous les gouts. Je ne suis pas développeur système, ni mainteneur de packages. Je suis architecte et sysadmin - et pour l'instant je ne vois que des inconvénients à systemd et les avantages de journald (qui existent c'est clair) ne sont pas suffisant loin s'en faut pour que je reconsidère systemd comme une possibilité.
Avec journald, les recherches sont rapides et c'est pour cela que le format binaire est intéressant.
Aucun rapport.
On peut parfaitement normer et indexer un fichier texte.
La raison pour laquelle une recherche dans les logs prend du temps est l'absence de format prédéfini et l'absence d'index. Si tu en mets un des deux (ou encore mieux les deux) tu peux avoir d'excellentes performances.
C'est bien connu, aucune distribution (comme Suse ou Red Hat) qui tourne sur un serveur n'envisage de passer à systemd.
Je pars du principe que ton commentaire est ironique mais cependant si on regarde les deux grosses distribs payantes (Red Hat et Suse Entreprise LInux) on a pas grand chose.
Il y a vaguement une slide de juin pour RH7 dans la section "truc qu'on envisage". Et depuis plus rien du tout la dessus. (Mais alors rien de chez rien)
OpenSuse est passé à systemd, mais leur page officielle de status sur systemd fait un peu peur, la page bugzilla aussi ( https://bugzilla.novell.com/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=openSUSE+12.2&content=systemd ) et du coup la page disant que Suse Entreprise Server allait passer sur systemd a carrément été retiré du net (publié le 15 octobre, encore présente sur toolinux dans le cache google mais introuvable).
Quand à Debian qui reste quand même l'OS non payant le plus populaire pour des installations professionnelles, il ne semble pas super pressé de changer.
Donc pour l'instant les grosses distribs serveurs envisagent, mais de loin. Apparemment les clients payants sont tous des réactionnaires effrayés par le changement. (En tout cas une partie suffisamment importante d'entre eux le sont, au point que les grosses distribs payantes ne communiquent plus sur Systemd).
Au final c'est pas bien connu, mais il me semble que les distributions serveurs (comme Suse Entreprise ou Red Hat) envisagent très sérieusement de ne PAS passer à systemd. En tout cas pas tout de suite.
Après la prochaine fournée devrait arriver en 2013 (début pour Suse, milieu pour RH) et il peut se passer pas mal de chose entre temps. Ceci dit il y a quand même un problème à ne pas passer en systemd : les distro de "test" que sont Fedora et OpenSuse, elles, ont franchit le pas. Donc ca va pas simplifier le freeze/debug tout ça.
Sérieux, il faut arrêter avec ces horreurs que sont les "billions" et les "trillons".
Ce en sont pas des horreurs, ce sont des termes tout à fait logique, que tous les mathématicien du monde ont parfaitement compris SAUF nos amis les amero-britaniques. Vous savez ceux qui n'ont toujours pas compris l'interet du système métrique et tout ça.
Pour le reste du monde un trillion c'est un million x un million x un million.
Euh, le reproche qui est fait à systemd est que le pid 1 a des dépendances dans tous les sens
C'est un des reproches fait à systemd.
Un autre reproche est que pour avoir un systemd complet et fonctionnel il faut se frapper une chaine de bootstrapping monstrueuse. Une lib de plus (même une petite lib) n'est pas anodine.
Encore un autre reproche est que les versions minimales des distribs (ie utilisées pour déboguer une fonctionnalité ciblée) commencent à être impactées assez négativement par cette pléthore de libs qu'on se ramasse dès l'init.
journal-gateway est un démon à part donc il n'est pas dans systemd.
Euh… Si tu vas par là rien n'est systemd. journal-gateway est dans l'arbre systemd direct, n'est utilisé que par systemd, n'a aucun intéret hors de systemd etc.
Sinon on peut dire que systemctl n'est pas sytemd parce que c'est un programme à part.
systemd est un ensemble d'outils, certains obligatoires, d'autres optionnels, mais je vois pas à quel titre on pourrait séparer journal-gateway du reste de systemd.
Non, il y a bien eu libmicrohttpd ajouté à systemd. Dans le but de faciliter certains dialogue avec journald d'accord, mais les lignes de codes vont bien dans systemd (la partie journal-gateway). Lennart semble même penser à ajouter une gestion des certificats avec TLS et tout le toutim.
Ceci étant c'est désactivé par défaut, donc à moins de vouloir journal-gateway SANS http, ça ne pose pas vraiment de problème.
Quasi à poil en rentrée atmosphérique, meurt-on crâmé, ou meurt-on à cause de la faible pression ?
La seule question est de savoir si ton sang va avoir le temps de geler avant de commencer à bouillir (Température glaciale + très faible pression ça fait des trucs rigolo). Ceci étant tu n'auras pas le temps de prendre assez de vitesse pour que la question de la chaleur généré par les frottements soit un problème avant un moment après ta mort.
Mon pari perso est que le sang (et divers autres liquides) doivent bouillir avant de geler (et ce en l'espace de quelques millisecondes, avant même que tu prennes la moindre vitesse), à 50km de "hauteur" l'eau ne peut plus exister à l'état liquide de toute façon, et dans tous les cas tu es perdant.
En fait ça fait pas chier le monde. Si un mec soulève un problème que tu n'avais pas vu ou t'aide à comprendre un aspect que tu avais manqué ça peut faire économiser du temps et de l'argent. Ca peut aussi éviter que ton programme soit rejeté par des personnes que tu aimerais avoir de ton coté (par exemple si tu essayes de vendre des OS professionnels et qu'il y a pas mal d'admins systèmes, autant chez tes clients qu'en dehors, qui font la gueule - c'est peut être qu'il faut revoir ta copie).
Aussi tout le travail qui est fait par la communauté, n'est plus à faire. Donc tout ce qui est doc/how-to/explications qui se retrouvent sur les blogs ou les sites spécialisés sont une garantie de visibilité et d'acceptation de ta techno. De la même façon si toute personne qui cherche à faire un truc un poil complexe avec ta techno et qui en faisant une recherche sur internet tombe sur des horreurs (soit des pages qui descendent ta techno en flamme, soit des pages qui donnent des méthodes bien gruik avec pleins d'intervention manuelle à faire et aucune garantie que ça survivra à une mise à jour) ben là aussi tu te vides un chargeur dans le pied.
Les utilisateurs clients de Red Hat ont payé pour avoir le droit d'ouvrir leur gueule, pas l'utilisateur lambda.
a) La communauté (même ceux qui ne développent pas, qui ne traduisent pas etc.) a toujours le droit d'ouvrir sa gueule du moment qu'elle utilise. Les admins sys sont la raison d'exister de Red Hat.
b) Les clients Red Hat (dont je suis bien malgré moi, saloperie de certif Oracle) ouvre suffisament sa gueule pour que Red Hat n'ait pas encore choisi aujourd'hui si oui ou non ils allaient utiliser systemd (). Personellement et en l'état systemd est juste inutilisable pour tout un tas de choses (cf mes nombreux commentaires dans les journaux pour ceux qui ont du temps à perdre). Si Red Hat passe à systemd, et si systemd ne fait pas des progrès majeurs (boot predictible, gestion des templates, prise en compte de l'environnement, gestion des fs chiffrés en dehors des deux pseudo-fs pris en charge actuellement) je ne peux pas passer en 7.0.
De toute manière, les systèmes BSD rechigeraient à porter systemd dans leur base, vu que c'est GPL.
Ca n'a jamais empêché les *BSD de rajouter des programmes dans les ports. Seulement si on fait le bilan des trucs portés par BSD ces derniers temps :
- HAL : mort
- DBus : toujours pas de gestion de la sécurité, déborde de plus en plus sur le système alors qu'il est encore bancal au niveau desktop (notamment quand il y a plusieurs opérations en attente)
- UDev : en cours de massacre actif pour être rendu compatible systemd, au point que Linus et Greg KH se demandent sérieusement si ils ne vont pas le reprendre dans les outils kernel
Donc on fait un bilan rapide et on se dit que systemd (qui est loin d'être fini et complet et qui se veut linux only depuis le début) c'est même pas la peine d'essayer de le porter.
Si toutes les options sont identiques oui, on peut se démerder pour faire uen seule unit en effet.
Maintenant supposons que sur une des cartes je veuille utiliser l'option -H (demande à dhcpcd de changer le nom d'hote) par exemple (option dont bien entendu je ne veux surtout pas sur les autres cartes). Ben faut faire une deuxième unit.
Sur une autre carte je veux l'option -K (conserve la liste resolv.conf) et sur encore une autre (qui n'est activé qu'en cas de soucis majeur) je veux les deux options.
Bien sur les cartes qui sont de la forme /dev/vethX ont des parametrages différents de celles qui sont en /dev/ethx, certaines cartes utilisent un autre fichier de conf (configuré via -L), elles ne loguent pas toute au même endroit donc en systemd ce sont des units différentes. etc. etc.
Bon je te rassure dans le cas de dhcpcd (et pour quelques autres dont ifup/ifdown) on peut tricher en mettant un script bash en pre exec qui va se charger de mettre à jour les variables d'environnements sur lesquelles s'appuie systemd. mais pour d'autres systèmes ca n'est tout simplement pas possible.
Si on veut, parce que je vois pas comment ça peut être fonctionnel ton truc, depuis quand sysvrc passe autre chose que start/stop comme argument au boot
Au hasard parce que les fichiers shells lancés par sysvrc peuvent prendre en compte l'environnement, faire des tests, valider des conditions etc.
En fait je crois même que c'est une des choses principales que leur reproche Lennart.
En gros, tu viens de démontrer qu'avant c'était pourri et que maintenant c'est générique. Bravo…
Alors déjà le jour ou ça marche avec autre chose que certaines fonction réseau tu me fais signe (N.B : systemd ne sait toujours pas gérer les templates)
Ensuite mon script réseau il lance dhcpcd sur eth0 seulement si il y en a besoin (et donc il n'essaye pas de le lancer si il n'y en a pas besoin) sans que j'ai besoin de l'activer ou de le désactiver en fonction de comment je pense rebooter.
De plus mon script ne fais pas croire à tous les autres services qu'il y a une interface active et configurée avant de leur dire que c'était pour rire 30 secondes plus tard.
Et pour finir j'ai pas besoin de créer un fichier de service/unit quand je rajoute une interface en cours de route (bonjour les VM) je fais /etc/init.d/monscriptRéseau.sh eth42 et hop.
Donc je ne sais pas ce que j'ai réussi à démontrer, mais toi j'ai une petite idée.
Tu peux m'expliquer ce que tu racontes ? C'est à mourir de rire! Tu critiques les autres parce qu'ils ne savent pas ce dont ils parlent et toi tu racontes absolument n'importe quoi.
Et allez on commence par une attaque. Tu es sur de toi là ? Non parce que supposons que j'arrive à démontrer que ce que je dis se tient tu fais quoi ?
Tes 40 dépendances, dedans y'a des variables et des démons pour la plupart facultatifs qui offrent des interfaces dbus qui pour l'instant sont utilisés par personne.
C'est juste des variables et des interfaces DBus ? Ouf tout va bien alors - ca devrait donc être possible à implémenter sous tous les systèmes qui ont un portage de DBus alors. Ah ben sauf que non, dans la liste que j'ai donné (et que je redonne http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart ) il n'y a quasiment que des "no" dans systemd Implementation portable to other OSes or non-systemd distributions et le reset c'est partially.
Une variable non portable c'est quoi ? C'est un caractère qui n'existe que sous Linux ? Une interface DBus non portable c'est un acte de divination que fait Linux mais que les autres implémentations n'ont pas ?
Si ces variables et ces interfaces sont non portables c'est qu'elles dépendent à leur tour d'autres éléments du système qui eux n'existent que sous Linux. Ce sont bien des dépendances au sens fort du terme. C'est à dire qu'il faut des éléments système actifs supplémentaires pour que la fonctionnalité soit présente.
Pour l'instant… Genre, tu vas nous pointer une erreur architectural qui fait que ce sera toujours le cas ?
On parle du systemd de maintenant que les distribs sont en train de nous déployer en prod en masse (sauf Red Hat qui se tate encore pour la 7, ce qui en soit devrait mettre la puce à l'oreille), ou du systemd qui existera peut être dans 5 ans ?
Non parce que le systemd d'aujourd'hui il a plein de chose qui sont gênantes pour pas mal de systèmes de chiffrement
a) Déjà le /usr doit être accessible - donc lui si il est chiffré il ne peut l'être que par une des deux méthodes compatibles aujourd'hui
b) Les virtual sockets foutent pas mal la grouille dans tous les chiffrements qui requièrent une synchro précise avec une base de temps extérieure. Ca peut se contourner en rajoutant des dépendances dans tous les sens (ie en ayant tout un pan du processus de boot qui s’exécute de façon séquentielle, donc systemd n'apporte plus rien à ce niveau là) mais systemd va mettre des batons dans les roues pour debugguer (si on oublie une dépendance, l'authentification va foirer, mais on aura aucun message permettant de comprendre pourquoi vu que le socket virtuel aura avalé l'erreur)
c) Je ne vois pas avec l'architecture actuelle comment systemd pourra gérer le chiffrement des partitions liés à un device interactif extérieur (par exemple un lecteur carte à puce dans lequel l'utilisateur doit insérer sa carte puis composer un code au bon moment pour que la partition se débloque). Vu les récentes discussions au sujet de udev et le point de vue du mainteneur actuel ca me semble mal parti pour être corrigé dans un délai court.
d) Dans la même veine, et même sans interaction avec la console je vois mal comment l'automount de systemd va gérer une clef usb (ou équivalent) insérée pendant le boot et qui contient un certificat nécessaire à la poursuite du boot.
Ca c'est pour les exemples qui me viennent en tête là maintenant. Mais honnêtement même un bête déchiffrement via auth kerberos externe pose des problèmes en ce moment.
En gros, c'est utilitaire qui pour l'instant ne répond pas à ton besoin ce qui est logique vu que pour l'instant, dans son état actuel, il n'est pas fait pour.
Et que donc ça ne marche pas, mais c'est pour autant que l'on ne va pas le mettre en prod au détriment d'un système qui lui fonctionne. Ben voyons.
C'est tellement mieux un script bash avec un case à ralonge…
Pas de case à rallonge, juste un script qui parse un fichier de conf et attribue des variables. C'est assez courant en fait.
Ben, pour un mec qui parle de shell, t'as pas l'air de bien savoir comment ca fonctionne si tu penses vraiment avoir besoin de faire 10 actions pour lancer tes 10 configs ou les rendre actives.
Donc
a) J'ai toujours dix services à maintenir (N.B : sur un système que je maintiens en ce moment les config sont auto-générées et stockées en base, je dois en avoir un peu plus de 3000 là - et non ca n'est pas une mauvaise utilisation du produit)
b) J'ai aussi un script de plus à maintenir pour lancer et enregistrer mes configs (sauf que je ne veux pas toutes les enregistrer, je ne lancerais jamais les 10 VPN en même temps sur ma machine, la plupart n'ouvriront que deux ou trois VPN différents maximum au cours de leur vie, mais je ne peux pas savoir d'avance lesquelles)
c) Au moment de mettre à jour les configs il faut que je me ramasse en plus des tests pour savoir dans quel état est systemd, et si le #@!$ de lien symbolique est en cours d'utilisation ou pas.
d) Il ne faut pas oublier de lancer le script de mise à jour après chaque modif des fichiers de conf, comme au bon vieux temps des premiers lilo. COOL
Par ce qu'un systeme d'init a besoin d'etre turing complet ?
Je sais pas… Tu penses que l'informatique va évoluer ou pas ? Si tu penses que ca va encore évoluer ben il vaut mieux avoir un système turing compler, parceque sinon si on se retrouve sur un cas que l'on ne sait pas gérer on risque de devoir encore changer de système d'init.
Par cotnre si tu penses que l'informatique c'est un produit fini et stable, alors ca ne pose pas de problème.
Faudrait choisir. Systemd c'est nul par ce que : - c'est pas KISS, ca fait trop de choses - c'est pas turing complet, ca fait pas assez de choses
C'est clair qu'il faut faire un choix, mais tu as l'air de considérer que si je considère le produit à la fois comme incomplet ET surchargé c'est parce que je ne sais pas ce que je veux.
Et pourtant le produit est à la fois bloated (40 dépendances pour les units - et qu'on ne vienne pas me dire qu'on peut désactiver des units, il y a tellement de dépendances croisées et de d'assomptions que c'est un cauchemar) et incomplet (pas moyen de faire des templates par exemple - dans un monde ou on créé dynamiquement des VM à la demande c'est quand même dommage)
Le systeme de fichier chiffré que j'utilise ne ferait donc pas partie de la plupart des systemes de fichiers chiffrés ?
Grosso modo systemd fonctionne avec deux méthode de chiffrement, et recommande fortement d'utiliser luks. Egalement systemd ne fonctionne pas avec tous les systemes de fichiers à clef distante (ie il faut s'authentifier sur un serveur pour récupérer les infos sur la clef). Tu as un des deux systemes qui marche et ca te convient, tant mieux pour toi. Mais systemd continue quand même à ne pas fonctionner avec la plupart des systèmes de chiffrement existant.
On peut choisir si il faut tuer tous les process, uniquement le principal, ou aucun mais executer une commande particulière
Je sais je l'ai dit : On peut mettre un mode dégradé en place pour dire à systemd de ne surtout toucher à rien, mais du coup on est moins bien qu'avec SystemV init
Seulement si on choisit de ne rien tuer (la seule option valable dans ce cas) on ne peut plus rien piloter avec systemctl, il faut donc créer d'autres scripts (donc travail double et maintenance en parallèle) pour les opérations standard du daemon (restart/stop/reload etc.)
Il suffit que le service soit configuré pour utiliser systemd-ask-password pour demander le mot de passe.
Petit extrait : The purpose of this tool is to query system-wide passwords—that is passwords not attached to a specific user account.
Petit problème le mot de passe d'un certificat (apache par exemple) est à la fois non global au système ET lié à un utilisateur ET plusieurs instance du serveur peuvent avoir besoin de mots de passe différents (le proxy n'utilise pas forcément le même certificat que le serveur frontal). Donc pour débloquer des certificats systemd-ask-password ne marche pas.
Tout comme le reste c'est faux. http://0pointer.de/blog/projects/instances.html
Et blam en plein dedans, tout le but de cet article est d'expliquer comment se passer des templates en créant un service par fichier de config (et en éditant à la suite les liens symboliques à la main pour que ca marche).
Donc le but de cet article tout entier est d'expliquer comment contourner le problème des templates qui ne fonctionnent pas sous systemd.
Au final au lieu d'un script toto.sh que l'on peut appeler comme on veut (par exemple /etc/init.d/toto.sh config1) on se retrouve avec une horreur immonde. Si on a dix fichiers de config il faut créer 10 services
systemctl start toto@config0
systemctl start toto@config1
systemctl start toto@config2
…
systemctl start toto@config9
Puis ensuite bien sur aller éditer 10 liens symboliques à la main
Y a il un seul truc exact dans cette liste ? La quantité de mensonges par ligne dans ce message est assez impressionante !
Je suis supposé dire quoi là ? Te renvoyer ton commentaire insultant au visage en t'indiquant qu'il ne suffit pas de lire trois mots d'un article en anglais qui semble aller dans ton sens (de loin et dans le brouillard) mais qu'il faut aussi lire les specs et les comprendre.
Il n'y a pas de couche réseau dans systemd. Ce n'est qu'une unité comme un autre.
Non, mais il y a trois couches communicantes en dépendance (2 IPC et les sockets). Ca laisse pas mal de place pour des failles réseau. Et puis les virtual sockets c'est pas techniquement dans systemd, mais c'est vraiment pas loin à coté.
En fait, systemd est très KISS : il ne fait qu'une chose, il gère des unités.
Pas vairment non, il fait appel à plusieurs dépendances pour gérer des unités (qui elle mêmes on des sous dépendances pour pouvoir fonctionner, la liste complète est là : http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart ) en comptant bien il y en a juste 40 dont deux IPC (DBus et treaty) plusieurs FS et les mounters qui vont avec etc. Donc dire que systemd est KISS c'est juste une blague.
Et tout ce qu'on lui reproche de faire en trop ne sont que des unités qu'il se contente de gérer
On lui reproche d'avoir d'ennormes dépendances pour au final en faire moins que SystemV init. On dira ce qu'on voudra mais systemd n'est pas turing complet, les shells si.
Comme SysV, sauf qu'il est plus modulaire
Non il est nettement moins modulaires que SystemV init. Il ne supporte pas les sous scripts d'init, pas les templates, il faut recompiler toute la chaine de boot à chaque modif etc. La ils sont en train de massacrer udev pour le rendre plus compatible avec systemd et ils demandent au kernel de faire des modifs aussi pour corriger les bugs qu'ils ont introduits dans udev.
Egalement l'init systemd ne fonctionne pas avec
- La plupart des systemes de fichiers chiffrés
- le /usr distant (au revoir les terminaux léger)
- le multiboot du même service (service qui se clone et qui se ferme mais ou il ne faut pas fermer les clones) - on peut mettre un mode dégradé en place pour dire à systemd de ne surtout toucher à rien, mais du coup on est moins bien qu'avec SystemV init. Bon c'est un peu con en période d'explosion du cloud, mais on peut pas penser à tout.
- le pxe "à rebond" (le initram charge deux environnement le premier pour authentifier l'utilisateur/la machine - le second qui est le "vrai" environement de travail) mais bon c'était déjà foutu pour les terminaux léger.
- la gestion des mots de passe au boot. Merci de donner les clefs de tout vos certificats à systemd ou de lancer vos services à la main si vous devez taper un mot de passe à un moment. le parallélisme ca ne va pas avec l'interactif.
- la gestion des templates. Vous devez démarrer 6 ou 7 VPN ? Ben ca fera 6 ou 7 services à configurer indépendamment les uns des autres mon bon monsieur.
On notera aussi pèle-mèle :
La complexité de la maintenance du truc : si un jour vous cassez votre boot process au niveau de systemd, vous avez interet à avoir une machine très similaire avec un environnement très très proche pour réparer systemd. Sur une machine un peu custom, réparer systemd depuis un LiveCD c'est juste un massacre.
Le coté (LSB/Fedora style)/Linux only. Systemd n'est pas compatible avec tous les systèmes même si ce sont des Linux récents. Encore faut-il avoir un processeur et un environnement qui peuvent s'y préter.
A part la vitesse de boot (dont personnellement je me fous royalement) Systemd est loin derrière SystemV init à tous les points de vues. Que se soit la compatibilité, la flexibilité, la maintenance (et même la capacité à fermer des processus et/ou à logguer leur comportement). Il ne faut pas oublier que l'on peut parfaitement utiliser cgroups avec SystemV init (95% des gens qui défendent systemd défendent en fait l'utilisation de cgroups dans les scripts d'init - ca marche très bien avec SystemV init, même mieux qu'avec systemd vu que la plupart des shells sont turing complets).
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 2.
C'est juste que sqlite est un exemple particulièrement mal choisi, tu aurais pu parler directement des mbox :p
Oui. Mauvais exemple. J'ai changé d'exemple. Mail Dir - Dovecot est un meilleur set pour se placer dans une situation similaire (nombreux fichiers, sous répertoires, "logueur" centralisé) et avec des performances assez bluffantes.
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 1.
Ben ça dépend ton index il est en binaire ou pas ? S'il est en binaire pourquoi diantre l'est-il ?
Ok on va replacer les choses dans le contexte.
On me dit que l'on ne peut pas indexer ou rajouter des métas à un fichier sans placer le fichier lui même au format binaire (et donc non lisible humainement). Je répond que si on peut.
Maintenant effectivement l'index lui même n'a aucun intérêt à être lisible humainement. A partir de là le mettre au format texte serait un pur gaspillage de place. Ce qui ne change rien au fait que l'on peut avoir à la fois des gigas et des gigas de données au format texte ET un index et des métas très performantes sur ces données.
SQLite étant un mauvais exemple je vous présente mes excuses pour l'avoir utilisé - et je vous propose comme exemple de rechange un systèmes de fichiers qui contient des boites au format maildir et avec dans le role de l'indexeur/placeur de meta le serveur dovecot.
Vous avez des giga de données texte, un système d'index et de cache performant, un systême qui peut être accédé par plusieurs clients simultanément en lecture/écriture sans trop de soucis et qui tourne en prod de façon nickel chez suffisament de personnes pour que l'on ait du mal à dire qu'il s'agit d'un exemple ultra-spécifique que moi seul ait vu dans un monde imaginaire à venir.
Es-ce que ça vous va comme exemple pour comprendre ce que je veux dire ?
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 10.
Il y en a qui s'y mettent 2 ans après la sortie d'une version (le plus classique)
Au risque de me répéter : C'est l'init.
C'est pas programme dans un coin que je peux utiliser ou pas, upgrader ou pas. En RHEL 6 il y a pleins de trucs que je n'utilise pas, comme networkd, SELinux, les outils graphiques etc. mais il y a des trucs très récents que j'utilise (typiquement on a la dernière version de kvm/libvirt).
La question n'est donc pas "est-ce qu'on prend ou est-ce qu'on ne prend pas ?" mais "est-ce qu'on se repositionne par rapport à RHEL ou pas ?".
Même si on décide de ne pas passer en RHEL 7 (pour cette raison, ou pour d'autres) on a au minimum 3 ans pour changer. Après on rentre en "production 2" et ça peut poser des soucis. Mais trois ans pour faire les tests, choisir un remplaçant, valider la nouvelle archi et la faire certifier c'est pas non plus la fête. On est confortable, mais pas trop.
Là pendant à peu près un an (jusqu'à la première beta) on va être dans le noir. Donc on peut dire qu'on aura deux ans de marge. Sans être tendu ça va commencer à être un peu serré.
Donc oui, j'aimerai avoir les infos maintenant. Ne serait-ce que pour préparer la direction à accepter que le budget 2014 soit plus conséquent que les années précédentes (que l'on reste avec RHEL ou pas d'ailleurs).
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 3.
L'index binaire est stocké dans le même fichier que le "texte" (qui au final est juste un ensemble de strings C dumpées telles quelles dans un fichier binaire), c'est donc de facto un fichier binaire.
Donc si je résume on ne peut pas indexer ou rajouter des metas à un fichier texte, parce que si on le fait il devient de facto un fichier binaire ?
C'est impossible, mais on va le faire et quand on aura fini ça ne sera plus un fichier texte qu'on aura indexé ?
Et si on met l'index à coté (genre un index séparé sur une base de données type mbox, le container mail) ca compte ou pas ?
Et si il y a des pièces jointes en base64, le fichier il est binaire ou pas ?
Non sérieusement les gars. Si je fais un less de mon fichier de données SQLite, j'ai du charabia qui s'affiche ou je peux voir mes données ?
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 10.
Ca tombe bien, systemd a un mode de compatibilité sysvinit
Qui a de grosses lacunes, on en a déjà discutés plusieurs fois.
Cool, ben il va falloir que ces boites pensent à les foutre à la porte alors, parce que bon, les vieux croutons qui refusent d'apprendre parce qu'ils ont toujours fait comme cela, en informatique, on sait ce que ca donne…
Elles ont plutôt tendances à foutre à la porte les jeunots qui savent mieux et qui installent la dernière version sans réfléchir (parce que c'est forcément mieux). Ce sont eux qui font des dégats que les vieux croutons doivent réparer.
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 4.
Alors pour quoi tu nous prends pour des truffes en disant :
_"il me semble que les distributions serveurs (comme Suse Entreprise ou Red Hat) envisagent très sérieusement de ne PAS passer à systemd" _
C'est dans leur distribs betas, c'est dans le code des paquets mais ça n'est officiel nul part. Comment tu interprètes toi qu'un papier qui dit que Suse Entreprise Server utilisera systemd soit retiré ?
Le truc c'est que soit ils ont décidé de mettre systemd quoi qu'il arrive, mais qu'ils tiennent absolument à nous faire la surprise (ce que tu as l'air de penser), soit ils ne sont pas sur de mettre systemd.
Le support ne parle jamais des produits en cours de développement, et c'est pareil dans toutes les boites que j'ai fait,
Et dans la plupart des cas j'en ai rien à faire. Mais dans le cas présent si il faut porter tous les scripts d'init custom j'aimerai pouvoir commencer en avance. Maintenant je ne suis pas categoriste, si le support n'a pas le droit de répondre, je prend la réponse de n'importe qui d'officiel à la place. Seulement cette réponse (à l'heure actuelle) je ne l'ai pas.
Le fait que Solaris soit passé à smf est la preuve qu'on peut survivre à un changement de système d'init.
J'ai aucun problème avec un changement d'init. J'ai un problème majeur avec systemd. SMF est une réussite et si on pouvait avoir un truc pareil sous Linux je ferais des bonds de joie. Les points forts de SMF sont :
- Tout un système basé quasi exclusivement sur les templates : tous les services sont des templates, et on peut facilement créer et détruire des instances à la volée en changeant les paramètres de configuration ou en dupliquant une instance existante.
- Des dépendances ultra-réduites. Pas besoin de ramener une pléthore d'outils pour que ca marche.
- Un grand respect de l'existant : les scripts de rc.d/* continuent d'être executés. inittab est toujours parsé etc.
- Un système turing complet avec des vrais outils pour manipuler l'environnement d’exécution des services aussi bien avant le démarrage que pendant l’exécution.
Et pléthore d'autres trucs qui font cruellement défaut à systemd.
Si on se logue trop tôt et qu'on utilise NIS. Et comme tu dit, c'est corrigé dans une nouvelle version systemd.
Le problème n'est pas là. Le problème est comment une interaction de ce type peut-elle tromper l'init et le faire se comporter de façon nocive pour le système ? Un getty crashe (ca peut arriver), ben on le relance.
Ce qui est le comportement standard de sysvinit et de tout les autres. Et d'après le bug, c'est plymouthd qui bloque.
Une fois de plus le problème n'est pas la. Que /var ne se démonte pas parcequ'il est locké OK, mais pourquoi au reboot systemd devient-il incapable de monter /var ? Je n'ai jamais eu d'erreur de type 'ah non, il y a un fichier de lock alors j'interdis le montage' sur sysinit ou sur bsdinit. Comment un fichier à la con peut-il empêcher /var de monter ?
Que le fichier vienne de plymouth on s'en fout.
Un boot pas à pas dans un système prévu pour lancer les choses en même temps est ma foi un concept des plus intéressant.
Au hasard parce que justement comme le système n'est pas prédictif, j'aimerais bien pouvoir lancer B avant A pour voir ce qui se passe. Par exemple si j'ai un bug qui se produit une fois sur 5 ou 6 et que je pense que c'est la fois ou le service TUTU se lance avant le service TOTO qui est normalement toujours premier à s'executer. Là pour faire ce genre de tests il faut que je fasse dépendre artificiellement TOTO de TUTU (et bien entendu que je remette les trucs dans le bon ordre si c'est pas ça). Si j'ai trois ou quatre hypothèses je vais me marrer.
C'est pas un souci de systemd, c'est un souci de nfs sur Suse, et Fedora 18 propose les unités pour nfs.
Non. C'est bien un manque de systemd (pas un problème à proprement parlé, mais un comportement inattendu) que l'on peut contourner. Les sockets virtuels foutent la grouille entre les différents process de NFS et comme automount part très vite on est obligé de broder un peu pour que ypbind et autofs soient actifs et en forme pour de vrai au moment ou automount vient les chercher.
Comme dit dans le bug report, tu t'attends à quoi ?
Tu es en train d'insinuer que c'est un comportement normal de tuer l'init quand un disque ram est plein ? Comme dit le bug report une ligne plus bas, je m'attends plutôt à ce que l'on arrive sur un refus genre "disque plein" avec des retry et des purges (enfin comme sur n'importe quel autre fs quoi).
Donc je compte 2 bugs déjà corrigés, 2 bug à corriger ailleurs ( nfs, plymouthd ), et 1 "why did you expect".
Donc bien 5 bugs, des trucs qui peuvent se produire et qui explosent l'init.
Et les corrections ne sont pas coté systemd (genre ah oui, dans ce cas dégénéré là ca empêche l'init - c'est embêtant quand même) mais coté des outils. Genre ok le logiciel de haut niveau TOTO a planté l'init, mais c'est de sa faute il a pas fait les appels comme il faut et c'est corrigé dans la version 4.2 du logiciel TOTO.)
Le problème est que le logiciel de haut niveau TOTO ne devrait pas pouvoir planter l'init. Pas du tout. Bordel c'est l'init ! Ca doit être bétonné.
Comme avec chaque version majeur. Est ce qu'ils ont eu des tonnes de boulot avec upstart sur les RHEL 6 ?
Grosso modo upstart ca a foutu la grouille dans les configs TTY à la con et les runlevels custom, mais c'était pas bien méchant au final. Ne serait-ce que parce qu'on avait toujours les scripts et l'environnement.
Sinon, quand tu payes la souscription RHEL ou SLES, c'est aussi pour que le distributeur fasse les tests
Le distributeur il t'aide en cas de pépin et il peut débugguer des trucs pas évident. Mais il n'a pas un clone de ton install chez lui. Donc pour faire les tests…
Le mot de passe à l'init, une riche idée quand le systéme est sequentielle car ton serveur se bloque en attendant de rentrer le mot de passe, c'est pas du tout fragile au possible.
Les trucs qui dépendent du mot de passe sont nécessairement bloqués (en fait c'est même le but d'un mot de passe) - Les trucs qui ne dépendent pas du mot de passe continuent. Quand il y a plusieurs mots de passe, pour s'y retrouver on affiche un texte explicatif (Genre veuillez rentrer le mot de passe pour le certificat truc de l'instance apache www.example.com )
Je pense au passage que c'était pas possible non plus avec upstart qui dans mon souvenir lance les trucs en parallèle.
Si si, ça marche très bien. Parce que upstart execute des scripts et sait mettre les demande d'interaction utilisateur à la queue leu leu.
Quand aux templates, j'ai deja du dire que ç'est prévu par systemd, et la dernière fois, tu as sorti un exemple super compliqué
Un truc super compliqué : une variable d'environnement dont le contenu n'est pas fixe.
Un autre truc super compliqué : le résultat de l’exécution d'un autre service.
Heureusement ça arrive rarement les service qui donne des résultats ou les variables d'environnement qui changent.
Formidable ça. Parce que upstart ou l'init classique sysinit, c'était normalisé ?
Non mais c'était turing complet. Donc on pouvait TOUJOURS trouver une solution ou un contournement.
Bie sur, tu va trouver sans doute des cas de scripts hors lsb qui ne marche pas, et dire "bah ça marche pas".
Il y a des scripts d'init full LSB qui ne marchent pas. Pour les partitions chiffrées notamment.
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 1.
Sqlite utilise un arbre binaire ( b-tree ) pour accéder à des enregistrements ( records ).
Oui.
Ca s'appelle un index.
Ca permet de savoir à quel endroit de quel fichier se trouve l'information.
Donc ils ont indexés des fichiers majoritairement texte.
Et ils ont mis des métas aussi.
C'est ce dont on parle.
Enfin je crois…
Mais apparament je parle le klingon.
Et encore, peut-être qu'en klingon je me ferais mieux comprendre.
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 2.
SQLite utilise un fichier binaire, merci de confirmer ce que les autres disaient.
Le header et la numérotation des lignes est en binaire. Le contenu est en flat - c'est entre autre ce qui permet le typage dynamique des colonnes.
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 10.
car "Red Hat Enterprise Linux Roadmap: Part 1", ça ne se traduit pas vraiment pas "truc qu'on envisage". Si c'était "stuff that we are looking at", ou une expression similaire,
Et si par exemple c'était dans la partie "Development Topics" slides 31 à 37 qui liste les limitations, les améliorations et les éléments qui sont en cours d'études et de développement, il se passerait quoi ?
Je pourrais sans doute continuer pendant des heures, mais je vais pas m'acharner sur le sujet
Surtout que tout ton argumentaire repose sur le fait qu'il fasse leurs études et tests sur Fedora, chose que j'ai signalé dans mon post au fait. Et que donc il va leur être difficile de na pas mettre systemd dans RH 7 (ce que j'ai dit aussi).
je suis sur que tu as des tas d'arguments et de témoignage de gens qui sont super proche du pdg de RH
Ben justement non j'en ai aucun. Que ce soit chez Suse ou chez Red Hat ca joue à ni oui ni non. Même le support (payant) RH est pas foutu de répondre à la question "dans RH7 ca sera systemd ou sysinit ou les deux".
Or le truc c'est que dans le milieu professionnel les "c'est évident" et les "ca se voit" on a tendance à s'en méfier pas mal. (Surtout avec RH à qui ca ne fait pas peur de faire passer à la trappe une techno du jour au lendemain).
_ et que même si Arch et Mageia ont fait la migration avec 3 bouts de ficelle sans soucis majeurs, c'est impossible que des boites avec plus de moyens fassent de même_
OK. Donc tu n'as juste pas compris le problème en fait.
En dehors des utilisateurs qui utilisent Linux pour s'amuser et s'instruire, il y a des sociétés (parfois même des grosses sociétés) qui utilisent Linux pour traiter des données sensibles, des fois vitales à la boite, dans leur activité de tous les jours. Ces sociétés ne représentent pas une portion très importante des utilisateurs de Linux, par contre elles représentent 100% des clients payant de boites comme RH ou Suse.
Or ces sociétés ont souvent des scripts, des outils, des programmes même codés maison et qui utilisent la puissance de l'init traditionnel pour fonctionner (processing turing complet, prise en charge des variables d'environnement, init prévisible, logs dans des fichiers plats etc.)
Je n'ai pas vraiment de vision sur ces sociétés, je n'en connais que trois. Mais les trois que je connais (en l’occurrence leurs sysadmin) ne veulent pas de systemd. Et ils n'en veulent pas parce que :
a) Il y a beaucoup de boulot et de tests à faire pour s'assurer que tout fonctionne.
b) Certaines choses (certains fs chiffrés, demande de mot de passe à l'init par service, templates etc.) ne sont pas possible avec systemd.
c) Systemd n'est pas fini/normalisé et du coup même si ils trouvent des parades aujourd'hui rien ne prouve qu'elles seront encore valables dans dix jours (spéciale dédicace udev)
Le fait que ArchLinux et Mageia ait fait le pas en tant que distrib ne prouve rien au niveau de l'utilisabitlité du bigniou par des sysadmins.
Ah, on me dit dans l'oreille que c'est pas parce qu'il y a marqué systemd dans un rapport de bug que c'est un bug sur systemd et que ta liste est utilisé juste pour du FUD. Dommage, presque crédible.
Ah oui, je donne la liste mais j'ai oublié de dire qu'il fallait lire :
Bug 774126 : si on se logue trop tôt sur une interface série le getty crashe définitivement. Il existe une solution mais elle est trop complexe pour être backportée
Bug 779434 : pas de splash dans le boot kernel, pas de /var. Systemd refuse de monter le /var si plymouthd a un fichier de lock qui traine dessus. COOOL
Bug 780006 : Un boot pas à pas dans systemd ? Vous plaisantez bien sur. De..bug ? Jamais entendu parlé.
Bug 780441 : L'automount NFS ne marche pas (pas chez Fedora non plus) - mais on a presque fini d'avoir une bonne idée sur comment contourner le problème. (N.B : ce bug a une priorité P5 - none. Autmount NFS ? Ca interresse quelqu'un ? )
Bug 767394 : Un disque plein ? C'est un scandale ! Je me casse… (signé systemd).
Après tu fais comme tu veux, mais moi ce genre de bugs sur des trucs que j'utilise couramment (pas comme le timer du device machin sur une architecture ARM spécifique que l'on ne retrouve que sur des téléphones portables hackés) ca me fait peur.
L'init doit être le process le plus robuste qui soit. C'est lui le centre névralgique du système. Si il bugue on ne peut plus rien faire. L'init est presque plus importante que le kernel au niveau debug (une bonne init peut permettre de comprendre ce qui a chié dans le kernel, la réciproque n'est pas vraie).
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 9.
Mais alors, pourquoi personne ne l'a donc fait?
SQLLite ? Par exemple hein, il y en a un paquet d'autres (Pas mal de backends LDAP par exemple)
De façon générale il existe une palanquée de "flat file database" dans lequel le bianire est l'exception plutôt que la règle.
PS : jamais compris pourquoi des gens arrivent à se braquer sur un format "binaire" pour défendre un autre format binaire
Oui en vrai tous les formats sont binaires. Surprise il n'y a pas de petits caractères en fonte dans les processeurs. Et pourtant on fait le distinguo.
Un indice : Lisible facilement par un être humain et éditable facilement avec des outils standards.
Pourquoi c'est pas fait?
Sur les systèmes qui en ont besoin, c'est fait.
Mes logs DNS/Apaches sont indexés par exemple.
Pourquoi rajouter encore plus de volume de données pour faire la même chose?
chez vous les disques durs sont gratos?
Parce qu'un meta en INT LE 64 bits ça ne prend pas de place ?
Le format ASCII prend de la place mais le format binaire c'est gratuit ?
Au risque de te surprendre, le fait que les disques durs ne soient pas gratuit est une excellente raison de ne pas mettre :
- 12 000 métas sur des entrées ou ca n'apporte pas grand chose
- Une nouvelle palanquée d'outils pour lire et trier ces métas
- D'autres outils pour gérer la corruption des données (oui en ascii la corruption d'un octet ca peut faire chier mais pas plus que ça, alors qu'en binaire)
- Et bien sur toute la clique de convertisseurs pour les programmes qui ne parlent pas encore le journald couramment (et dont même en cherchant bien on ne voit pas pourquoi ils apprendraient à le faire)
_ Il y a des gens qui ont des Go de log (surtout sur 1 an, minimum légal), et remercie journald et son format "binaire avant c'était pas binaire" _
1) Personnellement j'ai des Go de logs par jour. Avec des scripts baysiens pour foutre à la poubelle ce qui n'a pas d’intérêt et ne stocker que le nécessaire.
2) Je ne connais personne qui a des Go de logs à maintenir et qui dise merci au format binaire. Pourtant du sysadmin j'en connais - mais même ceux qui sont éventuellement intéressés par journald sont rebutés par le fait qu'il faille rameuter systemd et toute la clique pour que ça marche.
sans supprimer un seul avantage du avant
A part la non lisibilité par un humain, le surplus de maintenance, le coté non standard/non fini, la non intégration dans l'existant, les dépendances, la fragilité à la corruption etc.
_ En attendant, il y en a un qui se bouge le cul, lui, et il a l'air de bien répondre à un besoin de beaucoup de monde…_
Tant mieux pour eux. Bon je ne connais pas ce "beaucoup de monde" là. Le beaucoup de monde que je connais est plutôt contre systemd - mais bon il en faut pour tous les gouts. Je ne suis pas développeur système, ni mainteneur de packages. Je suis architecte et sysadmin - et pour l'instant je ne vois que des inconvénients à systemd et les avantages de journald (qui existent c'est clair) ne sont pas suffisant loin s'en faut pour que je reconsidère systemd comme une possibilité.
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 7.
Avec journald, les recherches sont rapides et c'est pour cela que le format binaire est intéressant.
Aucun rapport.
On peut parfaitement normer et indexer un fichier texte.
La raison pour laquelle une recherche dans les logs prend du temps est l'absence de format prédéfini et l'absence d'index. Si tu en mets un des deux (ou encore mieux les deux) tu peux avoir d'excellentes performances.
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 7.
C'est bien connu, aucune distribution (comme Suse ou Red Hat) qui tourne sur un serveur n'envisage de passer à systemd.
Je pars du principe que ton commentaire est ironique mais cependant si on regarde les deux grosses distribs payantes (Red Hat et Suse Entreprise LInux) on a pas grand chose.
Il y a vaguement une slide de juin pour RH7 dans la section "truc qu'on envisage". Et depuis plus rien du tout la dessus. (Mais alors rien de chez rien)
OpenSuse est passé à systemd, mais leur page officielle de status sur systemd fait un peu peur, la page bugzilla aussi ( https://bugzilla.novell.com/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=openSUSE+12.2&content=systemd ) et du coup la page disant que Suse Entreprise Server allait passer sur systemd a carrément été retiré du net (publié le 15 octobre, encore présente sur toolinux dans le cache google mais introuvable).
Quand à Debian qui reste quand même l'OS non payant le plus populaire pour des installations professionnelles, il ne semble pas super pressé de changer.
Donc pour l'instant les grosses distribs serveurs envisagent, mais de loin. Apparemment les clients payants sont tous des réactionnaires effrayés par le changement. (En tout cas une partie suffisamment importante d'entre eux le sont, au point que les grosses distribs payantes ne communiquent plus sur Systemd).
Au final c'est pas bien connu, mais il me semble que les distributions serveurs (comme Suse Entreprise ou Red Hat) envisagent très sérieusement de ne PAS passer à systemd. En tout cas pas tout de suite.
Après la prochaine fournée devrait arriver en 2013 (début pour Suse, milieu pour RH) et il peut se passer pas mal de chose entre temps. Ceci dit il y a quand même un problème à ne pas passer en systemd : les distro de "test" que sont Fedora et OpenSuse, elles, ont franchit le pas. Donc ca va pas simplifier le freeze/debug tout ça.
[^] # Re: ARgh, trillons pourris
Posté par Kaane . En réponse au journal Ramesh Raskar et l’imagerie à un trillion d’images par seconde.. Évalué à 7.
Sérieux, il faut arrêter avec ces horreurs que sont les "billions" et les "trillons".
Ce en sont pas des horreurs, ce sont des termes tout à fait logique, que tous les mathématicien du monde ont parfaitement compris SAUF nos amis les amero-britaniques. Vous savez ceux qui n'ont toujours pas compris l'interet du système métrique et tout ça.
Pour le reste du monde un trillion c'est un million x un million x un million.
[^] # Re: Parallèle avec dragonfly
Posté par Kaane . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 4.
Euh, le reproche qui est fait à systemd est que le pid 1 a des dépendances dans tous les sens
C'est un des reproches fait à systemd.
Un autre reproche est que pour avoir un systemd complet et fonctionnel il faut se frapper une chaine de bootstrapping monstrueuse. Une lib de plus (même une petite lib) n'est pas anodine.
Encore un autre reproche est que les versions minimales des distribs (ie utilisées pour déboguer une fonctionnalité ciblée) commencent à être impactées assez négativement par cette pléthore de libs qu'on se ramasse dès l'init.
# L'afrique !
Posté par Kaane . En réponse au sondage Votre nationalité...?. Évalué à 1.
Né à Nairobi (Obi-wan)
[^] # Re: Parallèle avec dragonfly
Posté par Kaane . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 7.
journal-gateway est un démon à part donc il n'est pas dans systemd.
Euh… Si tu vas par là rien n'est systemd. journal-gateway est dans l'arbre systemd direct, n'est utilisé que par systemd, n'a aucun intéret hors de systemd etc.
Sinon on peut dire que systemctl n'est pas sytemd parce que c'est un programme à part.
systemd est un ensemble d'outils, certains obligatoires, d'autres optionnels, mais je vois pas à quel titre on pourrait séparer journal-gateway du reste de systemd.
[^] # Re: Parallèle avec dragonfly
Posté par Kaane . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 4.
Faux, c'est journald, un processus à part.
Non, il y a bien eu libmicrohttpd ajouté à systemd. Dans le but de faciliter certains dialogue avec journald d'accord, mais les lignes de codes vont bien dans systemd (la partie journal-gateway). Lennart semble même penser à ajouter une gestion des certificats avec TLS et tout le toutim.
Ceci étant c'est désactivé par défaut, donc à moins de vouloir journal-gateway SANS http, ça ne pose pas vraiment de problème.
[^] # Re: Meilleure qualité
Posté par Kaane . En réponse au journal Opération Red Bull Stratos . Évalué à 6.
Quasi à poil en rentrée atmosphérique, meurt-on crâmé, ou meurt-on à cause de la faible pression ?
La seule question est de savoir si ton sang va avoir le temps de geler avant de commencer à bouillir (Température glaciale + très faible pression ça fait des trucs rigolo). Ceci étant tu n'auras pas le temps de prendre assez de vitesse pour que la question de la chaleur généré par les frottements soit un problème avant un moment après ta mort.
Mon pari perso est que le sang (et divers autres liquides) doivent bouillir avant de geler (et ce en l'espace de quelques millisecondes, avant même que tu prennes la moindre vitesse), à 50km de "hauteur" l'eau ne peut plus exister à l'état liquide de toute façon, et dans tous les cas tu es perdant.
[^] # Re: Parallèle avec dragonfly
Posté par Kaane . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 10.
Et ça sert à quoi à part faire chier le monde ?
En fait ça fait pas chier le monde. Si un mec soulève un problème que tu n'avais pas vu ou t'aide à comprendre un aspect que tu avais manqué ça peut faire économiser du temps et de l'argent. Ca peut aussi éviter que ton programme soit rejeté par des personnes que tu aimerais avoir de ton coté (par exemple si tu essayes de vendre des OS professionnels et qu'il y a pas mal d'admins systèmes, autant chez tes clients qu'en dehors, qui font la gueule - c'est peut être qu'il faut revoir ta copie).
Aussi tout le travail qui est fait par la communauté, n'est plus à faire. Donc tout ce qui est doc/how-to/explications qui se retrouvent sur les blogs ou les sites spécialisés sont une garantie de visibilité et d'acceptation de ta techno. De la même façon si toute personne qui cherche à faire un truc un poil complexe avec ta techno et qui en faisant une recherche sur internet tombe sur des horreurs (soit des pages qui descendent ta techno en flamme, soit des pages qui donnent des méthodes bien gruik avec pleins d'intervention manuelle à faire et aucune garantie que ça survivra à une mise à jour) ben là aussi tu te vides un chargeur dans le pied.
[^] # Re: Parallèle avec dragonfly
Posté par Kaane . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 10.
Les utilisateurs clients de Red Hat ont payé pour avoir le droit d'ouvrir leur gueule, pas l'utilisateur lambda.
a) La communauté (même ceux qui ne développent pas, qui ne traduisent pas etc.) a toujours le droit d'ouvrir sa gueule du moment qu'elle utilise. Les admins sys sont la raison d'exister de Red Hat.
b) Les clients Red Hat (dont je suis bien malgré moi, saloperie de certif Oracle) ouvre suffisament sa gueule pour que Red Hat n'ait pas encore choisi aujourd'hui si oui ou non ils allaient utiliser systemd (). Personellement et en l'état systemd est juste inutilisable pour tout un tas de choses (cf mes nombreux commentaires dans les journaux pour ceux qui ont du temps à perdre). Si Red Hat passe à systemd, et si systemd ne fait pas des progrès majeurs (boot predictible, gestion des templates, prise en compte de l'environnement, gestion des fs chiffrés en dehors des deux pseudo-fs pris en charge actuellement) je ne peux pas passer en 7.0.
De toute manière, les systèmes BSD rechigeraient à porter systemd dans leur base, vu que c'est GPL.
Ca n'a jamais empêché les *BSD de rajouter des programmes dans les ports. Seulement si on fait le bilan des trucs portés par BSD ces derniers temps :
- HAL : mort
- DBus : toujours pas de gestion de la sécurité, déborde de plus en plus sur le système alors qu'il est encore bancal au niveau desktop (notamment quand il y a plusieurs opérations en attente)
- UDev : en cours de massacre actif pour être rendu compatible systemd, au point que Linus et Greg KH se demandent sérieusement si ils ne vont pas le reprendre dans les outils kernel
Donc on fait un bilan rapide et on se dit que systemd (qui est loin d'être fini et complet et qui se veut linux only depuis le début) c'est même pas la peine d'essayer de le porter.
[^] # Re: Tu portes vraiment bien ton pseudonyme
Posté par Kaane . En réponse au journal Archlinux est morte…. Évalué à 4.
dhcpcd\@.service C'EST UNE SEUL UNIT!
Si toutes les options sont identiques oui, on peut se démerder pour faire uen seule unit en effet.
Maintenant supposons que sur une des cartes je veuille utiliser l'option -H (demande à dhcpcd de changer le nom d'hote) par exemple (option dont bien entendu je ne veux surtout pas sur les autres cartes). Ben faut faire une deuxième unit.
Sur une autre carte je veux l'option -K (conserve la liste resolv.conf) et sur encore une autre (qui n'est activé qu'en cas de soucis majeur) je veux les deux options.
Bien sur les cartes qui sont de la forme /dev/vethX ont des parametrages différents de celles qui sont en /dev/ethx, certaines cartes utilisent un autre fichier de conf (configuré via -L), elles ne loguent pas toute au même endroit donc en systemd ce sont des units différentes. etc. etc.
Bon je te rassure dans le cas de dhcpcd (et pour quelques autres dont ifup/ifdown) on peut tricher en mettant un script bash en pre exec qui va se charger de mettre à jour les variables d'environnements sur lesquelles s'appuie systemd. mais pour d'autres systèmes ca n'est tout simplement pas possible.
[^] # Re: Tu portes vraiment bien ton pseudonyme
Posté par Kaane . En réponse au journal Archlinux est morte…. Évalué à 2.
Si on veut, parce que je vois pas comment ça peut être fonctionnel ton truc, depuis quand sysvrc passe autre chose que start/stop comme argument au boot
Au hasard parce que les fichiers shells lancés par sysvrc peuvent prendre en compte l'environnement, faire des tests, valider des conditions etc.
En fait je crois même que c'est une des choses principales que leur reproche Lennart.
En gros, tu viens de démontrer qu'avant c'était pourri et que maintenant c'est générique. Bravo…
Alors déjà le jour ou ça marche avec autre chose que certaines fonction réseau tu me fais signe (N.B : systemd ne sait toujours pas gérer les templates)
Ensuite mon script réseau il lance dhcpcd sur eth0 seulement si il y en a besoin (et donc il n'essaye pas de le lancer si il n'y en a pas besoin) sans que j'ai besoin de l'activer ou de le désactiver en fonction de comment je pense rebooter.
De plus mon script ne fais pas croire à tous les autres services qu'il y a une interface active et configurée avant de leur dire que c'était pour rire 30 secondes plus tard.
Et pour finir j'ai pas besoin de créer un fichier de service/unit quand je rajoute une interface en cours de route (bonjour les VM) je fais /etc/init.d/monscriptRéseau.sh eth42 et hop.
Donc je ne sais pas ce que j'ai réussi à démontrer, mais toi j'ai une petite idée.
[^] # Re: Tu portes vraiment bien ton pseudonyme
Posté par Kaane . En réponse au journal Archlinux est morte…. Évalué à 10.
Tu peux m'expliquer ce que tu racontes ? C'est à mourir de rire! Tu critiques les autres parce qu'ils ne savent pas ce dont ils parlent et toi tu racontes absolument n'importe quoi.
Et allez on commence par une attaque. Tu es sur de toi là ? Non parce que supposons que j'arrive à démontrer que ce que je dis se tient tu fais quoi ?
Tes 40 dépendances, dedans y'a des variables et des démons pour la plupart facultatifs qui offrent des interfaces dbus qui pour l'instant sont utilisés par personne.
C'est juste des variables et des interfaces DBus ? Ouf tout va bien alors - ca devrait donc être possible à implémenter sous tous les systèmes qui ont un portage de DBus alors. Ah ben sauf que non, dans la liste que j'ai donné (et que je redonne http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart ) il n'y a quasiment que des "no" dans systemd Implementation portable to other OSes or non-systemd distributions et le reset c'est partially.
Une variable non portable c'est quoi ? C'est un caractère qui n'existe que sous Linux ? Une interface DBus non portable c'est un acte de divination que fait Linux mais que les autres implémentations n'ont pas ?
Si ces variables et ces interfaces sont non portables c'est qu'elles dépendent à leur tour d'autres éléments du système qui eux n'existent que sous Linux. Ce sont bien des dépendances au sens fort du terme. C'est à dire qu'il faut des éléments système actifs supplémentaires pour que la fonctionnalité soit présente.
Pour l'instant… Genre, tu vas nous pointer une erreur architectural qui fait que ce sera toujours le cas ?
On parle du systemd de maintenant que les distribs sont en train de nous déployer en prod en masse (sauf Red Hat qui se tate encore pour la 7, ce qui en soit devrait mettre la puce à l'oreille), ou du systemd qui existera peut être dans 5 ans ?
Non parce que le systemd d'aujourd'hui il a plein de chose qui sont gênantes pour pas mal de systèmes de chiffrement
a) Déjà le /usr doit être accessible - donc lui si il est chiffré il ne peut l'être que par une des deux méthodes compatibles aujourd'hui
b) Les virtual sockets foutent pas mal la grouille dans tous les chiffrements qui requièrent une synchro précise avec une base de temps extérieure. Ca peut se contourner en rajoutant des dépendances dans tous les sens (ie en ayant tout un pan du processus de boot qui s’exécute de façon séquentielle, donc systemd n'apporte plus rien à ce niveau là) mais systemd va mettre des batons dans les roues pour debugguer (si on oublie une dépendance, l'authentification va foirer, mais on aura aucun message permettant de comprendre pourquoi vu que le socket virtuel aura avalé l'erreur)
c) Je ne vois pas avec l'architecture actuelle comment systemd pourra gérer le chiffrement des partitions liés à un device interactif extérieur (par exemple un lecteur carte à puce dans lequel l'utilisateur doit insérer sa carte puis composer un code au bon moment pour que la partition se débloque). Vu les récentes discussions au sujet de udev et le point de vue du mainteneur actuel ca me semble mal parti pour être corrigé dans un délai court.
d) Dans la même veine, et même sans interaction avec la console je vois mal comment l'automount de systemd va gérer une clef usb (ou équivalent) insérée pendant le boot et qui contient un certificat nécessaire à la poursuite du boot.
Ca c'est pour les exemples qui me viennent en tête là maintenant. Mais honnêtement même un bête déchiffrement via auth kerberos externe pose des problèmes en ce moment.
En gros, c'est utilitaire qui pour l'instant ne répond pas à ton besoin ce qui est logique vu que pour l'instant, dans son état actuel, il n'est pas fait pour.
Et que donc ça ne marche pas, mais c'est pour autant que l'on ne va pas le mettre en prod au détriment d'un système qui lui fonctionne. Ben voyons.
C'est tellement mieux un script bash avec un case à ralonge…
Pas de case à rallonge, juste un script qui parse un fichier de conf et attribue des variables. C'est assez courant en fait.
Ben, pour un mec qui parle de shell, t'as pas l'air de bien savoir comment ca fonctionne si tu penses vraiment avoir besoin de faire 10 actions pour lancer tes 10 configs ou les rendre actives.
Donc
a) J'ai toujours dix services à maintenir (N.B : sur un système que je maintiens en ce moment les config sont auto-générées et stockées en base, je dois en avoir un peu plus de 3000 là - et non ca n'est pas une mauvaise utilisation du produit)
b) J'ai aussi un script de plus à maintenir pour lancer et enregistrer mes configs (sauf que je ne veux pas toutes les enregistrer, je ne lancerais jamais les 10 VPN en même temps sur ma machine, la plupart n'ouvriront que deux ou trois VPN différents maximum au cours de leur vie, mais je ne peux pas savoir d'avance lesquelles)
c) Au moment de mettre à jour les configs il faut que je me ramasse en plus des tests pour savoir dans quel état est systemd, et si le #@!$ de lien symbolique est en cours d'utilisation ou pas.
d) Il ne faut pas oublier de lancer le script de mise à jour après chaque modif des fichiers de conf, comme au bon vieux temps des premiers lilo. COOL
[^] # Re: Tu portes vraiment bien ton pseudonyme
Posté par Kaane . En réponse au journal Archlinux est morte…. Évalué à 10.
Par ce qu'un systeme d'init a besoin d'etre turing complet ?
Je sais pas… Tu penses que l'informatique va évoluer ou pas ? Si tu penses que ca va encore évoluer ben il vaut mieux avoir un système turing compler, parceque sinon si on se retrouve sur un cas que l'on ne sait pas gérer on risque de devoir encore changer de système d'init.
Par cotnre si tu penses que l'informatique c'est un produit fini et stable, alors ca ne pose pas de problème.
Faudrait choisir. Systemd c'est nul par ce que :
- c'est pas KISS, ca fait trop de choses
- c'est pas turing complet, ca fait pas assez de choses
C'est clair qu'il faut faire un choix, mais tu as l'air de considérer que si je considère le produit à la fois comme incomplet ET surchargé c'est parce que je ne sais pas ce que je veux.
Et pourtant le produit est à la fois bloated (40 dépendances pour les units - et qu'on ne vienne pas me dire qu'on peut désactiver des units, il y a tellement de dépendances croisées et de d'assomptions que c'est un cauchemar) et incomplet (pas moyen de faire des templates par exemple - dans un monde ou on créé dynamiquement des VM à la demande c'est quand même dommage)
Le systeme de fichier chiffré que j'utilise ne ferait donc pas partie de la plupart des systemes de fichiers chiffrés ?
Grosso modo systemd fonctionne avec deux méthode de chiffrement, et recommande fortement d'utiliser luks. Egalement systemd ne fonctionne pas avec tous les systemes de fichiers à clef distante (ie il faut s'authentifier sur un serveur pour récupérer les infos sur la clef). Tu as un des deux systemes qui marche et ca te convient, tant mieux pour toi. Mais systemd continue quand même à ne pas fonctionner avec la plupart des systèmes de chiffrement existant.
On peut choisir si il faut tuer tous les process, uniquement le principal, ou aucun mais executer une commande particulière
Je sais je l'ai dit : On peut mettre un mode dégradé en place pour dire à systemd de ne surtout toucher à rien, mais du coup on est moins bien qu'avec SystemV init
Seulement si on choisit de ne rien tuer (la seule option valable dans ce cas) on ne peut plus rien piloter avec systemctl, il faut donc créer d'autres scripts (donc travail double et maintenance en parallèle) pour les opérations standard du daemon (restart/stop/reload etc.)
Il suffit que le service soit configuré pour utiliser systemd-ask-password pour demander le mot de passe.
Petit extrait :
The purpose of this tool is to query system-wide passwords—that is passwords not attached to a specific user account.
Petit problème le mot de passe d'un certificat (apache par exemple) est à la fois non global au système ET lié à un utilisateur ET plusieurs instance du serveur peuvent avoir besoin de mots de passe différents (le proxy n'utilise pas forcément le même certificat que le serveur frontal). Donc pour débloquer des certificats systemd-ask-password ne marche pas.
Tout comme le reste c'est faux.
http://0pointer.de/blog/projects/instances.html
Et blam en plein dedans, tout le but de cet article est d'expliquer comment se passer des templates en créant un service par fichier de config (et en éditant à la suite les liens symboliques à la main pour que ca marche).
Donc le but de cet article tout entier est d'expliquer comment contourner le problème des templates qui ne fonctionnent pas sous systemd.
Au final au lieu d'un script toto.sh que l'on peut appeler comme on veut (par exemple /etc/init.d/toto.sh config1) on se retrouve avec une horreur immonde. Si on a dix fichiers de config il faut créer 10 services
systemctl start toto@config0
systemctl start toto@config1
systemctl start toto@config2
…
systemctl start toto@config9
Puis ensuite bien sur aller éditer 10 liens symboliques à la main
Y a il un seul truc exact dans cette liste ?
La quantité de mensonges par ligne dans ce message est assez impressionante !
Je suis supposé dire quoi là ? Te renvoyer ton commentaire insultant au visage en t'indiquant qu'il ne suffit pas de lire trois mots d'un article en anglais qui semble aller dans ton sens (de loin et dans le brouillard) mais qu'il faut aussi lire les specs et les comprendre.
[^] # Re: Tu portes vraiment bien ton pseudonyme
Posté par Kaane . En réponse au journal Archlinux est morte…. Évalué à 10.
Il n'y a pas de couche réseau dans systemd. Ce n'est qu'une unité comme un autre.
Non, mais il y a trois couches communicantes en dépendance (2 IPC et les sockets). Ca laisse pas mal de place pour des failles réseau. Et puis les virtual sockets c'est pas techniquement dans systemd, mais c'est vraiment pas loin à coté.
En fait, systemd est très KISS : il ne fait qu'une chose, il gère des unités.
Pas vairment non, il fait appel à plusieurs dépendances pour gérer des unités (qui elle mêmes on des sous dépendances pour pouvoir fonctionner, la liste complète est là : http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart ) en comptant bien il y en a juste 40 dont deux IPC (DBus et treaty) plusieurs FS et les mounters qui vont avec etc. Donc dire que systemd est KISS c'est juste une blague.
Et tout ce qu'on lui reproche de faire en trop ne sont que des unités qu'il se contente de gérer
On lui reproche d'avoir d'ennormes dépendances pour au final en faire moins que SystemV init. On dira ce qu'on voudra mais systemd n'est pas turing complet, les shells si.
Comme SysV, sauf qu'il est plus modulaire
Non il est nettement moins modulaires que SystemV init. Il ne supporte pas les sous scripts d'init, pas les templates, il faut recompiler toute la chaine de boot à chaque modif etc. La ils sont en train de massacrer udev pour le rendre plus compatible avec systemd et ils demandent au kernel de faire des modifs aussi pour corriger les bugs qu'ils ont introduits dans udev.
Egalement l'init systemd ne fonctionne pas avec
- La plupart des systemes de fichiers chiffrés
- le /usr distant (au revoir les terminaux léger)
- le multiboot du même service (service qui se clone et qui se ferme mais ou il ne faut pas fermer les clones) - on peut mettre un mode dégradé en place pour dire à systemd de ne surtout toucher à rien, mais du coup on est moins bien qu'avec SystemV init. Bon c'est un peu con en période d'explosion du cloud, mais on peut pas penser à tout.
- le pxe "à rebond" (le initram charge deux environnement le premier pour authentifier l'utilisateur/la machine - le second qui est le "vrai" environement de travail) mais bon c'était déjà foutu pour les terminaux léger.
- la gestion des mots de passe au boot. Merci de donner les clefs de tout vos certificats à systemd ou de lancer vos services à la main si vous devez taper un mot de passe à un moment. le parallélisme ca ne va pas avec l'interactif.
- la gestion des templates. Vous devez démarrer 6 ou 7 VPN ? Ben ca fera 6 ou 7 services à configurer indépendamment les uns des autres mon bon monsieur.
On notera aussi pèle-mèle :
La complexité de la maintenance du truc : si un jour vous cassez votre boot process au niveau de systemd, vous avez interet à avoir une machine très similaire avec un environnement très très proche pour réparer systemd. Sur une machine un peu custom, réparer systemd depuis un LiveCD c'est juste un massacre.
Le coté (LSB/Fedora style)/Linux only. Systemd n'est pas compatible avec tous les systèmes même si ce sont des Linux récents. Encore faut-il avoir un processeur et un environnement qui peuvent s'y préter.
A part la vitesse de boot (dont personnellement je me fous royalement) Systemd est loin derrière SystemV init à tous les points de vues. Que se soit la compatibilité, la flexibilité, la maintenance (et même la capacité à fermer des processus et/ou à logguer leur comportement). Il ne faut pas oublier que l'on peut parfaitement utiliser cgroups avec SystemV init (95% des gens qui défendent systemd défendent en fait l'utilisation de cgroups dans les scripts d'init - ca marche très bien avec SystemV init, même mieux qu'avec systemd vu que la plupart des shells sont turing complets).