Personnellement, ça me dérangerait qu'Evolution ne soit plus développé. C'est le seul client mail qui fonctionne avec l'Exchange 2012 du boulot
Wahou… Toi tu dois avoir exactement la même config que les développeurs, parce que déjà evolution qui fonctionne c'est rare, mais qui fonctionne simplement avec Exchange c'est carrément du jamais vu.
Evolution-data-server c'est par essence le process qui gonfle en continu jusqu'à exploser.
Ca balance effectivement mais pas vraiment sur systemd en soi mais sur udev et son mainteneur Kay Sievers qui ne fait apparemment pas son boulot.
En fait si j'ai bien suivi les modifs récentes de udev ont été faites pour être "compatible" avec systemd. Lennart veut du tout asynchrone, et donc il s'est dit que d'avoir un chargement de firmware asynchrone plus une méthode de callback de la part du kernel ca permettrait d'aller plus vite au boot.
Sauf que bien sur du coup charge au kernel de
a) comprendre que l'on a chargé un nouveau firmware
b) surveiller les étapes de chargement
c) valider la finalisation du chargement et l'initialisation du device à un moment ou le module driver n'est pas encore chargé
d) prévenir udev pour lui dire "ca y est c'est bon pour le device xxx:yyyy" ou pour les devices xxxx:yyyy et zzzz:aaaa et bbbb:cccc etc. parcequ'un seul device physique peut engendrer plusieurs devices logiques (le tout toujours sans qu'aucun module/driver n'est été chargé)
Tout ça implique donc que le kernel possède une interface pour tout les devices possibles et imaginables qui nécessitent un firmware chargé au boot et bien entendu une autre interface pour dialoguer (en asynchrone bien sur) avec udev (j'imagine que Lennart voudra que l'interface soit DBus pour ne pas avoir à dupliquer du code - après tout DBus dans le kernel, ou est le problème ?).
Linus T. s'ennerve du coup, mais c'est justifié, seul un esprit malade ou une société qui cherche à monopoliser une techno ouverte prendrait des décisions aussi irréfléchies.
Cinnamon est un fork de gnome-shell… même pas de gnome 3, juste gnome-shell. C'est un "non" qui veut dire "oh oui !"
L'approche "Gnome3" de Mint c'est "oh oui" tiede. Je veux dire ils ont quand même changé Gnome-Shell, Nautilus (je me fous de savoir comment il s'apelle aujourd'hui), mutter, Evolution, la refonte vers DBus/SystemD et gdm.
Ca fait quand même une bonne partie qui part à la poubelle. Ils essayent de rester compatibles avec Gnome 3 dans la mesure du possible, mais plus le temps passe moins ca fait lourd.
C'est une technique courante pour éviter l'allocation de /30 pour les interconnexions entre routeurs.
STOP !
Que quand on fasse un traceroute sur toto.tutu.test un des routeurs externe au LAN soit sur une adresse de la RFC1918 c'est pas super propre mais ça passe. Par contre quand on essaye de faire un traceroute directement sur l'adresse elle même ça devrait répondre "no route to host" en IP et partir en timeout en ICMP. Sinon il y a une vraie erreur de routage.
Vu que le changement a été fait en suivant les retours des utilisateurs, j'ai l'impression que ca contredit totalement le debut du commentaire (au lieu de l'illustrer).
Les Utilisateurs : Pourquoi il y a plus de bouton arrêt ?
Les Devs : C'est comme ça !
Les Utilisateurs : Mais on veut un bouton arrêt !
Les Devs : Non !
Les Utilisateurs : Mais on met pas en veille un fix ! Et puis la veille c'est pas encore top sous Linux, il faut un bouton arrêt !
Les Devs : (long silence) Bon OK en appuyant sur alt vous ferez apparaitre un bouton arrêt.
Les Utilisateurs : HEIN ??? C'est quoi cette daube !
Les Devs : Vous voyez qu'on prend en compte les demandes utilisateurs…
J'imagine que la partie en italique, c'est le passage de la prophétie qui ne s'est pas encore réalisé ? Ou alors j'ai raté un épisode et le Nautilus de Jon McCann été abandonné ?
Non en fait tout mon message est ironique.
Pour le projet Gnome2, la plupart de la dev team (et les utilisateurs) voulaient juste une adaptation GTK-2 de Gnome. Ximian et quelques dev voulaient tout passer sous Bonobo en full modulaire d'abord.
La communeauté a été la plus forte, le principe du least astonishment a été retenu et les mainteneur qui avaient le depracte/commit un peu rapide et un peu solitaire se sont fait renvoyer sur les roses.
Aujourd'hui, c'est pas vraiment ce qui se passe… Donc le parallèle me parait douteux à faire. Dans Gnome3 la communauté n'est pas du tout en position de force - ce qui est franchement perturbant vu les racines de gnome.
Une grosse société se croit propriétaire du projet Gnome et se fait rembarrer violemment par la communauté.
Un dev tente de faire passer en force sa vision du projet en décrétant que certaines parties fondamentales du code sont obsolètes et en les réécrivant à sa sauce, et pète un câble parce qu'on lui annule tous ses changements.
Une dev team de mainteneurs qui préfère avancer doucement en minimisant les changements et qui favorise le portage à l'ajout et à la suppression de fonctionnalités.
On devrait d'ailleurs faire la même chose chez nous. non?
Mais on fait la même chose chez nous !
En ce moment même on est en train de bloquer Gandi, OVH et Ikoula en finançant massivement le Cloud National. D'ailleurs ce cloud est presque pret, il ne reste plus aux deux grands acteurs choisis qu'à trouver un lieu ou construire, mettre en place les intercos, acheter les segments IPv4, coder la solution, recruter et former les ingénieurs pour être opérationnel !
On rajoute une ligne de 8 ballons de long sur un ballon de large et un appareil photo/webcam, et on doit avoir un générateur d'entropie d'une qualité démentielle pour un prix somme toute modeste.
Une fois de plus j'ai été obligé de répondre "Obi Wan Kenobi" faute d'option adapté.
En effet je me rend au travail en tobogan (j'habite au 17eme étage et mon entreprise a 4 étage de parking souterrain) C'est un moyen propre, rapide et ecologique de se rendre au travail, et il faudrait vraiment arréter de l'oculter si on veut préserver la planête.
De même j'ai un collègue qui vient au travail en trebuchet - faute de mieux il a répondu "par les moyens aeriens" mais bon ca ne correspond qu'à moitié à son moyen de transport réel.
On peut aussi chier dans une église
Non - Problème de dégradation (certes légère) du lieu, et problème d'hygiene
peindre les chats des vieux en noir
Non - cruauté envers animaux
enfermer un claustrophobe dans un placard
Non - sequestration
ou ligoter un quidam pour le faire passer 50 fois sous une échelle
Non - sequestration.
oui OK, on vit dans un pays libre et laïque et on a le droit de le faire
Même pas si sur. Un des fondements de la laïcité est le respect des opinions religieuses. Me semble-t-il qu'en France il n'est pas autorisé de tourner ou de distribuer un film pornographique impliquant des ordres religieux existant ou des personnages fondamentaux d'une religion (En Francais ca veut dire : pas de film de boules avec Jesus qui se tappe un couvent de benedictine).
Les caricatures de Mahomet sont à la limite du comportement des deux cotés. D'une part parceque la caricature des personnages religieux a fini par passer dans les moeurs mais aussi d'autres part parce que la non représentation de Mahomet est un aspect religieux très important pour les musulmans.
sauf si on veut héberger ses propres serveurs DNS (pour lesquels on ne peut pas faire appel au DNS pour trouver leur adresse).
Non, là on passe par la config du registrar - toujours pas besoin de PI. J'héberge mes propres DNS, je les ai déjà changé plusieurs fois de place et d'hebergeur moyennant 10 secondes de config sur l'interface web de mon registrar.
Le PI devient beaucoup plus intéressant lorsqu'on est multi-homé (plusieurs FAI), ce qui est bien utile pour la résilience.
Je vieux bien l'adresse et le numero des FAI qui font du routage sur des plages modeste (au hasard un /28) - Déjà sur un /24 ils font la gueule et il faut être très bon client chez eux (comprendre que le jour ou tu n'es plus bon client, tu n'as plus de routage).
Je ne pense pas qu'IPv6 améliore ce problème (Et vu les horreurs que nous sort le RFC tous les dix jours, j'aurais plutôt tendance à penser qu'il va empirer).
C'est quoi l'avantage de la VOST pour un film d'animation ?
Voice acting japonais : 3 ans d'études, un sacré paquet d'heures à faire des "petits doublages" avant de passer sur un long métrage, une sélection drastique du casting etc.
Voice acting français : Avec la voix de Elie Semoun dans le rôle de Youplala le lapin.
Avant la projection, les spectateurs sont invités à vérifier à quel public ce flim est destiné.
A la suite d'une bande annonce qui fait référence à un film sur lequel les commités d'évaluation n'ont pas encore donné d'avis. Donc on passe la bande annonce quand même, mais on prévient le spectateur qui pourrait avoir envie de voir le film que l'on ne sait pas encore pour quel catégorie de public le film complet sera autorisé.
Euh tu sais que tu suggeres que ceux qui vont prendre la decision auront la moindre idee technique…
Ouhlà je ne suggère rien. Je signale juste que IBM et HP dans une solution cloud c'est pas si délirant que ça. Et que en France je prendrais pas SuperMicro.
Après je fais un peu de DELL-Bashing parce que je suis un troll (Et que c'est pas trop difficile vu qu'il n'y a pas vraiment de produit "armoire rack" spécialisé cloud chez DELL - Ceci dit apparament pour les redondances multisites (aussi nommé pompeusement "private cloud") il parait que le R210 II est pas mal, mais il consomme trop/est trop gros pour un vrai environnement cloud complet (et il faut vraiment que j'aprenne à me calmer sur les parenthèses moi…)).
Pour sortir d'un troll et rentrer dans un autre, je ne parierai pas que l'on arrive jusqu'au moment ou l'on choisit les serveurs dans les deux magnifiques boites que l'on vient de nous monter.
Pour info monter un noeud cloud de 2 Po/2000vCPU et l'entretenir sur 3 ans ca coute à peu près 10M d'€ (étude faite à la louche à décaper les bières il y a deux mois - mais mon ordre de grandeur semble être le bon vu les chiffres annoncés par le patron de Gandi dans l'article cité plus bas) en comptant la totale (hébergement+liens+electricité+maintenance+hardware+salaires).
Donc pour 150M€ On devrait pouvoir monter 15 noeuds et offrir 10 000vCPU full time (donc en vendre pas loin de 30 000) avec triple sécurité.
A coté de ça on a ce genre de pages : http://www.numergy.com/offres avec la sauvegarde en option et seulement dans l'option la plus chère (qui n'a même pas une fiabilité terrible et seulement 50mb/s de bande passante) la reprise sur site distant ????
Et là je comprend pas.
Reprise sur site distant d'une solution cloud ? Ca ne veut rien dire…
Ou alors il s'agit de la reprise sur site distant des bureaux du client, mais là c'est un tout autre métier quand même - et ca m'ennuierait qu'ils utilisent leur argent à monter ou acheter des bureaux vides en banlieue…
Alors SGI fabrique des machines qui sont éventuellement rentables dans le cadre du montage d'une salle blanche haute densité pour faire du cloud, mais elles sont clairement pas moins cher que les produits équivalents chez HP et IBM (clairement pas moins bonne non plus d'ailleurs).
SuperMicro, moyennement (Ce sont de bonnes machines, mais le rapport puissance/consommation électrique est difficilement acceptable dans le cadre d'un déploiement de ce type). Et puis il y a le problème du support, je ne crois pas qu'il existe quelqu'un capable d'assurer la maintenance de 3000 machines d'un même modèles (OK 1000 machines type A, 2000 machines type B) en France.
Dell, ca a peut être changé - mais la dernière fois que j'ai regardé ils n'étaient même pas capable de fournir 1000 machines identiques (firmware, proc, mémoire, cartes etc.) pendant 1 an.
Mais de toutes les façon dans une install type cloud serveur représente entre 10% et 20% de la facture (plus proche de 10 d'ailleurs). Le reste ca va être la location de l'espace (ou le remboursement en cas de fabrication du datacenter), les interco, le fibrage inter site (en fibre noire c'est démentiel), l'électricité, la maintenance (clim, groupe électrogène, test freon …). Donc payer un serveur même 50% plus cher, ca fait que 3% de plus sur la note finale…
Posté par Kaane .
En réponse au journal udev forké.
Évalué à 2.
Ben tu lances « tructl reload "monfichierdeconf" », au moins tu es sûr de ce que ça fait.
Même pas. Parce que tructl reload peut relancer le processus principal (qui s'occupe juste de créer des sous process qui font le boulot eux-même) et dans ce cas là je ne sais pas comment systemd va réagir. Une fosi de plus je peux changer le comportement de systemd pour lui dire d ene pas surveiller les PID ou de ne pas accorder d'importance au contenu des cgroup, mais dans ce cas là systemctl status renverra des infos erronées.
De la même façon si tructl reload lance de nouveaux processus, je ne vais pas savoir facilement les intégrer dans le bon cgroup, donc systemctl restart risque là aussi de faire n'importe quoi.
Au final si je veux pouvoir utiliser tructl, il faut que je n'utilise QUE tructl. Mais là si j'ai des dépendances dans un sens ou dans l'autre il faut aussi que je les gère à la main. Bref je refais un système d'init parallèle.
Si c'est un gros point de ralage, tu va sans doute pouvoir donner des urls de tout ces gens qui ralent, voir un rapport de bug, qu'on puisse parler de trucs concrets, pas de "j'ai ce problème vague, et à chaque fois qu'un mec file une solution je sort un autre problème vague".
Allez hop zou juste avec OpenVPN qui est une des solutions soutenue par Fedora/RH :
1) On peut pas lancer tout un tas de tunnels en une seule commande (un peu con pour le PPoE+VPN) https://bugzilla.redhat.com/show_bug.cgi?id=744244
En fait on ne peut même pas activer les services dont les fichiers de conf sont basés sur des templates : https://bugzilla.redhat.com/show_bug.cgi?id=752774
Au final il faut créer les liens symboliques à la main si on veut plusieurs VPN/VNC/VSFTPD etc. Toute la lourdeur des vieux sysvInit au service de la rigidité systemd.
Confirmé sur le site officiel de Fedora : http://fedoraproject.org/wiki/Openvpn, à partir de Fedora16 il faut éditer les liens symboliques à la main…
Visiblement "avoir besoin de network", ça veut dire une chose bien précise pour toi, mais pas pour le reste du monde. Donc "avoir besoin de network", ça veut dire quoi pour toi ?
Interfaces actives, possibilité d'envoyer et de recevoir des trames.
Pour systemd ( et j'aurais tendance à dire pour les systéme d'init depuis des années ), ça veut dire que le sous système network est la, genre tu as l'interface lo qui est disponible à minima, et un programme qui peut avoir besoin d'une interface réseau non spécifique va réussir à se lancer, et raisonnablement supposer que le routage marche pour aller sur internet ou le réseau local, si besoin.
Le truc c'est que ca fait beaucoup trop.
J'ai besoin d'activer iptables AVANT tcp/ip (enfin besoin est un bien grand mot - disons que ca m'évite de patienter/tuer dhclient à la main et de relancer les scripts à la main.) Sauf systemd a besoin que tout network remonte d'un bloc (sinon il panique).
Voici ce que je voudrais qu'il se passe :
a) creation du pont ext0 interface réseau publique, int0 interface réseau privée
b) chargement des iptables (dont j'ai besoin pour mes VPN)
c) connection pptp
d) connection VPN
e) chargement IP et initialisation de la couche IP pour int0
Ce qu'il se passe
a) creation du pont ext0 interface réseau publique, int0 interface réseau privée
b) Tout network rapplique avec IP et tout le toutim
c) chargement de iptables
c - en parallèle et je peux rien y changer) La couche IP s'initialise pour int0, dhclient commence à tourner dans le vide
d) connection pptp
e) connection VPN : echec vu que IP et dhclient ont déjà la main sur int0
f) login prompt
g) à la mano on down int0
h) à la mano on relance VPN
i) à la mano on up int0
Alors bien sur on peut tricher en ne créant le bridge et le VPN qu'une fois que tout le reste a démarré, mais ca ralenti le boot, et les config deviennent chiante à lire, surtout qu'il ne faut pas oublier d'effacer/refaire les liens symboliques en cas de changement.
pour la maintenance, non je pige toujours pas. Quand je fait ça, je modifie la config, et je fait un reload.
Et tu fais ca comment en systemd ? Il y a deux reload en systemd
systemctl nomduservice reload -> recharge la config compilée pour nomduservice, ignore complètement le fichier ini
systemctl daemon-reload -> recompile toutes les configs de tous les services activés.
Ben que je suis en maintenance, je ne veux ni l'un ni l'autre et il n'y en a pas de troisième.
ATTENTION : systemctl enable et systemctl disable lancent aussi une recompilation de toutes les configs.
Donc si tu es parti sur "je refait les scripts d'init plutot que de faire un script de maintenance à part"
Et comment je dis à systemd de faire un reload d'un service mais avec un autre fichier de config ? J'ai 0 commande pour le faire, le seul truc que je peux faire c'est créer à la main des liens symboliques, éteindre le service et le relancer avec un autre nom en utilisant la conf du lien symbolique. Mais faire un reload depuis un nouveau fichier de config n'est pas possible en systemd (et vu la gestion des dépendances auto-évaluées ca ne le sera probablement jamais.)
si tu le fait pas et que tu rajoutes exprès des communications entre ton shell sous forme de variable et le script d'init, désolé, mais tu fais les choses de façon porcasse
Sans sytemd je suis propre (un seul fichier coherent avec lui même qui gère tout ce qui a besoin d'être pris en compte du début à la fin) avec systemd je ne sais pas faire. Donc oui je sauvegarde des fichiers temporaires et je les lits dans un autre script et oui c'est crade et oui je voudrais faire autrement, mais je peux pas.
Enfin, pour ton truc qui lance des services super long à démarrer au point de confondre systemd, vu que la suggestion "utilise le fichier pid" semble pas te plaire, je propose plus simplement "sépare ton script en plusieurs unités systemd".
a) C'est pas que la version "utilise le fichier PID" ne me plait pas, au contraire j'adorerai l'utiliser. C'est qu'elle ne marche pas vu que systemd ne relit pas le fichier régulièrement. Il le lit une fois, met les infos en mémoire et c'est fini.
b) Faire plusieurs unit ne fonctionne pas non plus.
En init classique mon premier programme de synchro récupère pleins de paramètres et lance le second programme avec ces paramètres. Hors je ne sais pas passer de paramètres d'une unit à l'autre en systemd. (Et là pourtant j'ai cherché) setenv ne fonctionne que dans l'inti et est accessible à tous les enfants (donc vachement pratique si on veut lancer plusieurs serveurs).
Pour finir j'ai pas besoin d'une unit pour le logiciel de sync, qui va nécessairement s’arrêter et qui n'a jamais besoin d'être lancé seul (limite ca serait même une très mauvaise idée).
Comme je suppose que tu va me dire "j'utilise pas pam"
Si j'utilise pam, mais le problème n'est pas là. C'est très bien que pam déplace les instance sshd d'un cgroup à l'autre. Mais ca me rajoute encore un truc de plus pour que ca fonctionne normalement. Et en plus même si j'ai pam, tout le monde ne se logue pas nécessairement via pam. Si je me logue par certif il se passe quoi ? Et par kerberos ? Et par ldap ? Et si le process d'authentification n'est pas sur la même machine que le ssh ? Et si c'est même pas un linux ?
Est-ce que ca marche si j'oblige tout le monde à passer par pam et que j'utilise les modules pam-* qui vont bien ? Et quand je met à jour il se passe quoi ?
Le truc c'est pas que ce soit impossible, c'est que ca me complique horriblement la vie. Et j'aime pas monter une usine à gaz pour retomber sur exactement le même résultat qu'avant.
Pour tomcat, je suppose (parce que comme d'hab, tu dit rien de précis donc faut deviner),
Ca doit pas être trop difficile à deviner vu que tu t'en sors.
que le souci vient du fait que quand tu relances tomcat, tu veux pas relancer chaque appli qui tourne à l'intérieur mais faire les choses de façon plus fine. Pour ça, pareil, je pense qu'il faut traiter chaque applications comme un service séparé, et trouver le moyen d'intégrer ça à systemd
Oui mais si on reprend les point précédents, à savoir
- systemd ne lance pas automatiquement les fichiers basé sur templates, il faut rajouter les liens symboliques à la main
- chaque serveur peut avoir plusieurs workers, donc plusieurs processus et j'aimerais bien tuer tous les processus d'un serveur sans abimer les autres (par exemple relancer tomcat admin mais pas les applis)
- les fichiers de config ne sont pas raffraichits automatiquement quand on les modifie.
Tu mets tout ça ensemble et tu arrives a des situations sympas avec ta solution :
Par exemple si un dev veut modifier le catalina ou créer un nouveau serveur, il faut qu'il te passe un coup de fil (ou qu'il ait les droits admin - et ça, c'est pas possible).
Comment tomcat admin va-t-il faire pour raccrocher les wagons ? Qu'est-ce qu'il se passe si je relance un site depuis tomcat-admin et pas depuis systemctl ?
Si j'ai un worker qui déconne ? Comment je le tue ? (je veux dire à part avec les droits root et un bon gros SIGKILL dans sa face) ?
j'ai peut-être à tort supposé depuis ton avatar que tu utilisais un *BSD
Ah mais je suis totalement BSDiste, viral et barbu comme l'indique mon avatar, et mon /bin/sh de référence est celui de FreeBSD. Je ne crois pas que ce soit un dash ou un ash.
Mais bon l'idée était surtout trollesque - je m'attendais à ce que mon interlocuteur revienne à la charge en me disant que dans mon sh aussi il pouvait y avoir du segfault. Bon après comparer la probabilité de problème entre une appli complète lié à libdbus et une rikiki sh ca aurait été drole.
Euh… dash c'est sh (c'est un port du sh de NetBSD). Tu pensais à bash j'imagine ?
dash c'est le port de ash si je me souviens bien. C'est vrai qu'il est très léger et très POSIX, ceci dit je n'invoquerais quand même pas dash directement dans mes scripts.
Pour bouger des pid dans le cgroup, c'est écrit dans la doc qui se trouve facilement via "cgroup pid move" sur un moteur de recherche. Exemple de résultat
Sauf que
a - c'est pas si évident que ça de trouver le cgroups qui va bien
b - systemd n'aura pas forcément conscience de ce changement, en fait il est même très fortement déconseillé de forcer une mise à jour ( http://0pointer.de/blog/projects/cgroups-vs-cgroups.html ) extrait :
> systemd will also maintain its own, private, controller-less, named control group hierarchy which is mounted to /sys/fs/cgroup/systemd/. This hierarchy is private property of systemd, and other software should not try to interfere with it. This hierarchy is how systemd makes use of the naming and grouping feature of control groups (A) without actually requiring any kernel controller enabled for that.
Dans la page entière il explique la différence entre les cgroups pour le nommage et les cgroups pour le controle, les seconds étant très impactant en terme de perfs il n'utilise que les premiers. Sauf que derrière vu que c'est privé, que systemd ne veut pas que je l'altère et que je n'ai pas de moyen de savoir quand les altérations des cgroups publics sont prises en compte (ni même si elle le sont) comment je fais pour informer systemd d'un nouveau processus ?
c - dans certains cas (apache, postgresql, postfix etc.) quand le processus maitre se casse la gueule il faut fermer tous les sous process et redémarrer à vide, mais dans d'autres cas (tomcat, sshd par exemple) je ne veux surtout pas tuer les sous process, en cas de redémarrage je veux les garder en vie et les rattacher au cgroup du nouveau processus maitre. Une fois de plus j'ai pas trouvé comment faire.
Pour tes trucs trop compliqués ou spécifiques, je pense qu'il a été dit facile 20 fois "tu peux garder ton script sysv".
Et j'ai dit 20 fois : non je ne peux pas, il ne marche pas dans le cadre de systemd.
Que ce soit parce qu'il lance pleins de processus et que systemd se retrouve à distribuer des watchers partout
Que ce soit parce qu'il met très longtemps à démarrer (gros check/sync au démarrage) et que systemd va mettre son watcher sur le process de synchro au lieu du process maitre (et donc me certifier mordicus que mon service est planté à partir du moment ou celui-ci aura enfin démarré)
Exemple de truc qui serait sans doute digne de la complexité dans laquelle tu aimes baigner :
Euh… Le truc fait 20 lignes et lance une appli même pas démonisé, un script RC standard avec un peu de réseau, un peu de controle par API en fait 200. Donc non c'est pas la complexité que j'aime dont j'ai l'habitude.
Pour ton histoire de maintenance, la solution est pourtant simple, tu peux faire un second service avec juste la config qui diffère.
Et qui va forcer un reload sur le premier service ? Ou bien j'arrête le premier service et je lance le second ? Et si je dois coder un fichier de conf à la va vite pour palier à un gros soucis il faut d'abord que je créé une nouvelle unit et que je la lance à la main ? Et si j'ai 20 services à mettre en maintenance ca me fait 40 scripts à maintenir ?
Non sérieusement j'aimais bien l'option ou en changeant une variable d'environnement et en lançant un script tout se passait comme je voulais.
Ca doit pas être super du de permettre un systemsct $service overload_reload $nouveau_fichier_de_conf.
Ou mieux, tu fait comme avec sysvinit, tu stoppes le service et tu lances à la main, puis tu fais l'inverse.
Je veux pas stopper le service, je veux changer sa conf. J'ai besoin que le service reste actif parce que d'autres éléments non modifiés sont toujours utiles (voire vitaux) à mon système. Par exemple je veux rediriger le DNS du site corporate, pas priver tout le plateau de résolution DNS, je veux ajouter une règle de transformation dans postfix pas arrêter le mail local etc.
Et avec sysvinit j'utilisais les outils de controle de base et ca se passait bien. Avec systemd c'est pas que ca se passe mal, c'est que je n'arrive pas à comprendre tout ce qui se passe et je ne vois pas comment faire pour récupérer/transmettre l'info.
Si tu veux lancer un tunnel gre non ip, ben tu fait un unité qui le fait, et tu t'arrange pour que ça soit fait avant network ( en rajoutant, genre "before" dans l'unité ).
Mais j'ai besoin de network, c'est dans mon script network que je veux que TCP/IP arrive plus tard. Et systemd est incompatible avec ce comportement.
Actuellement, tu as sans doute du écrire ton propre script, et visiblement, ton cas d'usage est assez rare pour que personne ne propose de patch
Mon script est assez courant en fait (Utilisé par pas mal de gens qui ont soit un modem ADSL en usb soit une config réseau sécurisé) et c'est un des gros points de ralage contre systemd. Ca n'est pas bloquant en soit, juste que ca ralenti le boot de façon chiante (vu qu'il n'y a rien sur le réseau hors vpn le systeme va essayer pleins de trucs, attribuer des adresses par défaut etc.)
L'autre gros point de ralage concerne les partitions chiffrées, pas mal de modèles de chiffrement sont incompatibles avec systemd aussi.
En fait, tu peux aussi juste rajouter une unité network qui remplace celle de systemd, et grâce à l'usage judicieux de répertoire
Figure toi que c'est ce que j'ai essayé de faire. Et systemd aime pas du tout la blague - pour lui network ca veut dire pleins de choses et son comportement est étrange quand ça ne se passe pas comme prévu.
Enfin pour l'exemple d'apache avec préservation des sockets ( je suppose que tu veux dire dans ce cas précis port tcp )
Ma phrase n'est pas claire, c'est de ma faute. Je pensais plutôt aux sockets de l'autre coté d'apache (vers les proxy, les caches, les X-cgi bidouillés), mais c'est vrai que si je fais ouvrir par systemd plutôt que par apache lui-même, je n'ai qu'à m'en prendre à moi même. Ca me paraissait pratique de pouvoir bufferiser les requètes le temps qu'apache redémarre, mais c'est juste pas possible. Tant pis.
Posté par Kaane .
En réponse au journal udev forké.
Évalué à 2.
Et c'est toujours possible avec systemd, je ne vois pas le problème.
Si je fais systemsctl reload "monfichier de conf" ca va executer tructl reload "monfichierdeconf" ou ça va me mettre un message d'erreur ?
Parce que la dernière fois que j'ai testé ca me mettait un message d'erreur.
[^] # Re: Exchange 2012
Posté par Kaane . En réponse au journal L'Evolution touche t-il à sa fin ?. Évalué à 3.
Wahou… Toi tu dois avoir exactement la même config que les développeurs, parce que déjà evolution qui fonctionne c'est rare, mais qui fonctionne simplement avec Exchange c'est carrément du jamais vu.
Evolution-data-server c'est par essence le process qui gonfle en continu jusqu'à exploser.
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par Kaane . En réponse au journal Archlinux va passer à systemd : appel à volontaire pour maintenir SysVinit. Évalué à 10.
Ca balance effectivement mais pas vraiment sur systemd en soi mais sur udev et son mainteneur Kay Sievers qui ne fait apparemment pas son boulot.
En fait si j'ai bien suivi les modifs récentes de udev ont été faites pour être "compatible" avec systemd. Lennart veut du tout asynchrone, et donc il s'est dit que d'avoir un chargement de firmware asynchrone plus une méthode de callback de la part du kernel ca permettrait d'aller plus vite au boot.
Sauf que bien sur du coup charge au kernel de
a) comprendre que l'on a chargé un nouveau firmware
b) surveiller les étapes de chargement
c) valider la finalisation du chargement et l'initialisation du device à un moment ou le module driver n'est pas encore chargé
d) prévenir udev pour lui dire "ca y est c'est bon pour le device xxx:yyyy" ou pour les devices xxxx:yyyy et zzzz:aaaa et bbbb:cccc etc. parcequ'un seul device physique peut engendrer plusieurs devices logiques (le tout toujours sans qu'aucun module/driver n'est été chargé)
Tout ça implique donc que le kernel possède une interface pour tout les devices possibles et imaginables qui nécessitent un firmware chargé au boot et bien entendu une autre interface pour dialoguer (en asynchrone bien sur) avec udev (j'imagine que Lennart voudra que l'interface soit DBus pour ne pas avoir à dupliquer du code - après tout DBus dans le kernel, ou est le problème ?).
Linus T. s'ennerve du coup, mais c'est justifié, seul un esprit malade ou une société qui cherche à monopoliser une techno ouverte prendrait des décisions aussi irréfléchies.
[^] # Re: Je ne comprend pas la première phrase
Posté par Kaane . En réponse au journal Enfin une distribution Linux ... (qui me convient). Évalué à 10.
Cinnamon est un fork de gnome-shell… même pas de gnome 3, juste gnome-shell. C'est un "non" qui veut dire "oh oui !"
L'approche "Gnome3" de Mint c'est "oh oui" tiede. Je veux dire ils ont quand même changé Gnome-Shell, Nautilus (je me fous de savoir comment il s'apelle aujourd'hui), mutter, Evolution, la refonte vers DBus/SystemD et gdm.
Ca fait quand même une bonne partie qui part à la poubelle. Ils essayent de rester compatibles avec Gnome 3 dans la mesure du possible, mais plus le temps passe moins ca fait lourd.
[^] # Re: Que je comprenne bien..
Posté par Kaane . En réponse au journal Enfin une distribution Linux ... (qui me convient). Évalué à 10.
T'es passé d'une Ubuntu à une Mint en bidouillant les sources apt? C'est bien ça?
Une debian en fait.
Mais dans l'idée c'est ça.
Parce que ton pavé est marrant à lire, mais pratiquement incompréhensible!
C'est une autre réputation que je me dois de défendre aussi.
[^] # Re: Utiliser moins d'IPv4
Posté par Kaane . En réponse au journal RFC 3251 : 10.0.0.0/24 est désormais routable sur internet. Évalué à 10.
C'est une technique courante pour éviter l'allocation de /30 pour les interconnexions entre routeurs.
STOP !
Que quand on fasse un traceroute sur toto.tutu.test un des routeurs externe au LAN soit sur une adresse de la RFC1918 c'est pas super propre mais ça passe. Par contre quand on essaye de faire un traceroute directement sur l'adresse elle même ça devrait répondre "no route to host" en IP et partir en timeout en ICMP. Sinon il y a une vraie erreur de routage.
[^] # Re: Stratégiquement bancal!
Posté par Kaane . En réponse au journal Interview de Vincent Untz, développeur GNOME. Évalué à 10.
Vu que le changement a été fait en suivant les retours des utilisateurs, j'ai l'impression que ca contredit totalement le debut du commentaire (au lieu de l'illustrer).
Les Utilisateurs : Pourquoi il y a plus de bouton arrêt ?
Les Devs : C'est comme ça !
Les Utilisateurs : Mais on veut un bouton arrêt !
Les Devs : Non !
Les Utilisateurs : Mais on met pas en veille un fix ! Et puis la veille c'est pas encore top sous Linux, il faut un bouton arrêt !
Les Devs : (long silence) Bon OK en appuyant sur alt vous ferez apparaitre un bouton arrêt.
Les Utilisateurs : HEIN ??? C'est quoi cette daube !
Les Devs : Vous voyez qu'on prend en compte les demandes utilisateurs…
[^] # Re: Exactement comme aujourd'hui.
Posté par Kaane . En réponse au journal GNOME : le début de la fin ? le problème avec le projet GNOME. Évalué à 8.
J'imagine que la partie en italique, c'est le passage de la prophétie qui ne s'est pas encore réalisé ? Ou alors j'ai raté un épisode et le Nautilus de Jon McCann été abandonné ?
Non en fait tout mon message est ironique.
Pour le projet Gnome2, la plupart de la dev team (et les utilisateurs) voulaient juste une adaptation GTK-2 de Gnome. Ximian et quelques dev voulaient tout passer sous Bonobo en full modulaire d'abord.
La communeauté a été la plus forte, le principe du least astonishment a été retenu et les mainteneur qui avaient le depracte/commit un peu rapide et un peu solitaire se sont fait renvoyer sur les roses.
Aujourd'hui, c'est pas vraiment ce qui se passe… Donc le parallèle me parait douteux à faire. Dans Gnome3 la communauté n'est pas du tout en position de force - ce qui est franchement perturbant vu les racines de gnome.
# Exactement comme aujourd'hui.
Posté par Kaane . En réponse au journal GNOME : le début de la fin ? le problème avec le projet GNOME. Évalué à 5. Dernière modification le 25 septembre 2012 à 22:00.
Une grosse société se croit propriétaire du projet Gnome et se fait rembarrer violemment par la communauté.
Un dev tente de faire passer en force sa vision du projet en décrétant que certaines parties fondamentales du code sont obsolètes et en les réécrivant à sa sauce, et pète un câble parce qu'on lui annule tous ses changements.
Une dev team de mainteneurs qui préfère avancer doucement en minimisant les changements et qui favorise le portage à l'ajout et à la suppression de fonctionnalités.
L'histoire est un éternel recommencement.
[^] # Re: Très différent de la Chine
Posté par Kaane . En réponse au journal Iran : une longueur d'avance sur la France. Évalué à 6.
On devrait d'ailleurs faire la même chose chez nous. non?
Mais on fait la même chose chez nous !
En ce moment même on est en train de bloquer Gandi, OVH et Ikoula en finançant massivement le Cloud National. D'ailleurs ce cloud est presque pret, il ne reste plus aux deux grands acteurs choisis qu'à trouver un lieu ou construire, mettre en place les intercos, acheter les segments IPv4, coder la solution, recruter et former les ingénieurs pour être opérationnel !
# Le truc interressant de ce journal
Posté par Kaane . En réponse au journal La transparence réseau arrive dans Wayland. Évalué à 3.
une petite nvidéo pour passer le temps.
On rajoute une ligne de 8 ballons de long sur un ballon de large et un appareil photo/webcam, et on doit avoir un générateur d'entropie d'une qualité démentielle pour un prix somme toute modeste.
[^] # Re: Marre de ces sondages qui proposent trop peu d'options
Posté par Kaane . En réponse au sondage Quel moyen de transport utilisez-vous pour vous rendre sur votre lieu de travail ?. Évalué à 3.
Personnelement j'ai opté pour la tiroliéne c'est plus simple à mettre en place.
A oui, mais pour la tir au lienne il faut une ligne droite. Et on mis à jour IOS sur les iphones des architectes.
# Marre de ces sondages qui proposent trop peu d'options
Posté par Kaane . En réponse au sondage Quel moyen de transport utilisez-vous pour vous rendre sur votre lieu de travail ?. Évalué à 10.
Une fois de plus j'ai été obligé de répondre "Obi Wan Kenobi" faute d'option adapté.
En effet je me rend au travail en tobogan (j'habite au 17eme étage et mon entreprise a 4 étage de parking souterrain) C'est un moyen propre, rapide et ecologique de se rendre au travail, et il faudrait vraiment arréter de l'oculter si on veut préserver la planête.
De même j'ai un collègue qui vient au travail en trebuchet - faute de mieux il a répondu "par les moyens aeriens" mais bon ca ne correspond qu'à moitié à son moyen de transport réel.
[^] # Re: Pour!
Posté par Kaane . En réponse au journal Le prophète et la liberté. Évalué à 3.
On peut aussi chier dans une église
Non - Problème de dégradation (certes légère) du lieu, et problème d'hygiene
peindre les chats des vieux en noir
Non - cruauté envers animaux
enfermer un claustrophobe dans un placard
Non - sequestration
ou ligoter un quidam pour le faire passer 50 fois sous une échelle
Non - sequestration.
oui OK, on vit dans un pays libre et laïque et on a le droit de le faire
Même pas si sur. Un des fondements de la laïcité est le respect des opinions religieuses. Me semble-t-il qu'en France il n'est pas autorisé de tourner ou de distribuer un film pornographique impliquant des ordres religieux existant ou des personnages fondamentaux d'une religion (En Francais ca veut dire : pas de film de boules avec Jesus qui se tappe un couvent de benedictine).
Les caricatures de Mahomet sont à la limite du comportement des deux cotés. D'une part parceque la caricature des personnages religieux a fini par passer dans les moeurs mais aussi d'autres part parce que la non représentation de Mahomet est un aspect religieux très important pour les musulmans.
[^] # Re: ipv8
Posté par Kaane . En réponse à la dépêche IPv6 : des poules et des hommes. Évalué à 4.
sauf si on veut héberger ses propres serveurs DNS (pour lesquels on ne peut pas faire appel au DNS pour trouver leur adresse).
Non, là on passe par la config du registrar - toujours pas besoin de PI. J'héberge mes propres DNS, je les ai déjà changé plusieurs fois de place et d'hebergeur moyennant 10 secondes de config sur l'interface web de mon registrar.
Le PI devient beaucoup plus intéressant lorsqu'on est multi-homé (plusieurs FAI), ce qui est bien utile pour la résilience.
Je vieux bien l'adresse et le numero des FAI qui font du routage sur des plages modeste (au hasard un /28) - Déjà sur un /24 ils font la gueule et il faut être très bon client chez eux (comprendre que le jour ou tu n'es plus bon client, tu n'as plus de routage).
Je ne pense pas qu'IPv6 améliore ce problème (Et vu les horreurs que nous sort le RFC tous les dix jours, j'aurais plutôt tendance à penser qu'il va empirer).
[^] # Re: Comment le voir ?
Posté par Kaane . En réponse au journal [Animation] Les Enfants Loups, Ame et Yuki . Évalué à 10.
C'est quoi l'avantage de la VOST pour un film d'animation ?
Voice acting japonais : 3 ans d'études, un sacré paquet d'heures à faire des "petits doublages" avant de passer sur un long métrage, une sélection drastique du casting etc.
Voice acting français : Avec la voix de Elie Semoun dans le rôle de Youplala le lapin.
Il y a vraiment besoin d'en dire plus ?
[^] # Re: Impact
Posté par Kaane . En réponse au journal Enfin l’étape 3 d’HADŒPI. Évalué à 10.
Mais non : les majors pourraient très bien avoir une « Délégation de Service Public », pour promouvoir la culture en France.
Ou alors Universal Music France créé un projet de cloud national. C'est 75M€ facile apparament.
# Euh, normalement c'est pas ça du tout...
Posté par Kaane . En réponse au journal [Cinéma] Meugneu. Évalué à 8.
Généralement on voit l'avertissement
Avant la projection, les spectateurs sont invités à vérifier à quel public ce flim est destiné.
A la suite d'une bande annonce qui fait référence à un film sur lequel les commités d'évaluation n'ont pas encore donné d'avis. Donc on passe la bande annonce quand même, mais on prévient le spectateur qui pourrait avoir envie de voir le film que l'on ne sait pas encore pour quel catégorie de public le film complet sera autorisé.
[^] # Re: Amazon
Posté par Kaane . En réponse au journal Le cloud computing à la française. Évalué à 4.
Euh tu sais que tu suggeres que ceux qui vont prendre la decision auront la moindre idee technique…
Ouhlà je ne suggère rien. Je signale juste que IBM et HP dans une solution cloud c'est pas si délirant que ça. Et que en France je prendrais pas SuperMicro.
Après je fais un peu de DELL-Bashing parce que je suis un troll (Et que c'est pas trop difficile vu qu'il n'y a pas vraiment de produit "armoire rack" spécialisé cloud chez DELL - Ceci dit apparament pour les redondances multisites (aussi nommé pompeusement "private cloud") il parait que le R210 II est pas mal, mais il consomme trop/est trop gros pour un vrai environnement cloud complet (et il faut vraiment que j'aprenne à me calmer sur les parenthèses moi…)).
Pour sortir d'un troll et rentrer dans un autre, je ne parierai pas que l'on arrive jusqu'au moment ou l'on choisit les serveurs dans les deux magnifiques boites que l'on vient de nous monter.
Pour info monter un noeud cloud de 2 Po/2000vCPU et l'entretenir sur 3 ans ca coute à peu près 10M d'€ (étude faite à la louche à décaper les bières il y a deux mois - mais mon ordre de grandeur semble être le bon vu les chiffres annoncés par le patron de Gandi dans l'article cité plus bas) en comptant la totale (hébergement+liens+electricité+maintenance+hardware+salaires).
Donc pour 150M€ On devrait pouvoir monter 15 noeuds et offrir 10 000vCPU full time (donc en vendre pas loin de 30 000) avec triple sécurité.
A coté de ça on a ce genre de pages : http://www.numergy.com/offres avec la sauvegarde en option et seulement dans l'option la plus chère (qui n'a même pas une fiabilité terrible et seulement 50mb/s de bande passante) la reprise sur site distant ????
Et là je comprend pas.
Reprise sur site distant d'une solution cloud ? Ca ne veut rien dire…
Ou alors il s'agit de la reprise sur site distant des bureaux du client, mais là c'est un tout autre métier quand même - et ca m'ennuierait qu'ils utilisent leur argent à monter ou acheter des bureaux vides en banlieue…
[^] # Re: Amazon
Posté par Kaane . En réponse au journal Le cloud computing à la française. Évalué à 7.
Je pense plutôt que DELL, SGI et SuperMicro
Alors SGI fabrique des machines qui sont éventuellement rentables dans le cadre du montage d'une salle blanche haute densité pour faire du cloud, mais elles sont clairement pas moins cher que les produits équivalents chez HP et IBM (clairement pas moins bonne non plus d'ailleurs).
SuperMicro, moyennement (Ce sont de bonnes machines, mais le rapport puissance/consommation électrique est difficilement acceptable dans le cadre d'un déploiement de ce type). Et puis il y a le problème du support, je ne crois pas qu'il existe quelqu'un capable d'assurer la maintenance de 3000 machines d'un même modèles (OK 1000 machines type A, 2000 machines type B) en France.
Dell, ca a peut être changé - mais la dernière fois que j'ai regardé ils n'étaient même pas capable de fournir 1000 machines identiques (firmware, proc, mémoire, cartes etc.) pendant 1 an.
Mais de toutes les façon dans une install type cloud serveur représente entre 10% et 20% de la facture (plus proche de 10 d'ailleurs). Le reste ca va être la location de l'espace (ou le remboursement en cas de fabrication du datacenter), les interco, le fibrage inter site (en fibre noire c'est démentiel), l'électricité, la maintenance (clim, groupe électrogène, test freon …). Donc payer un serveur même 50% plus cher, ca fait que 3% de plus sur la note finale…
[^] # Re: la guerre de s unices
Posté par Kaane . En réponse au journal udev forké. Évalué à 2.
Ben tu lances « tructl reload "monfichierdeconf" », au moins tu es sûr de ce que ça fait.
Même pas. Parce que tructl reload peut relancer le processus principal (qui s'occupe juste de créer des sous process qui font le boulot eux-même) et dans ce cas là je ne sais pas comment systemd va réagir. Une fosi de plus je peux changer le comportement de systemd pour lui dire d ene pas surveiller les PID ou de ne pas accorder d'importance au contenu des cgroup, mais dans ce cas là systemctl status renverra des infos erronées.
De la même façon si tructl reload lance de nouveaux processus, je ne vais pas savoir facilement les intégrer dans le bon cgroup, donc systemctl restart risque là aussi de faire n'importe quoi.
Au final si je veux pouvoir utiliser tructl, il faut que je n'utilise QUE tructl. Mais là si j'ai des dépendances dans un sens ou dans l'autre il faut aussi que je les gère à la main. Bref je refais un système d'init parallèle.
[^] # Re: Questions
Posté par Kaane . En réponse au journal Linux from scratch face à udev. Évalué à 3.
Si c'est un gros point de ralage, tu va sans doute pouvoir donner des urls de tout ces gens qui ralent, voir un rapport de bug, qu'on puisse parler de trucs concrets, pas de "j'ai ce problème vague, et à chaque fois qu'un mec file une solution je sort un autre problème vague".
Allez hop zou juste avec OpenVPN qui est une des solutions soutenue par Fedora/RH :
1) On peut pas lancer tout un tas de tunnels en une seule commande (un peu con pour le PPoE+VPN)
https://bugzilla.redhat.com/show_bug.cgi?id=744244
En fait on ne peut même pas activer les services dont les fichiers de conf sont basés sur des templates :
https://bugzilla.redhat.com/show_bug.cgi?id=752774
Au final il faut créer les liens symboliques à la main si on veut plusieurs VPN/VNC/VSFTPD etc. Toute la lourdeur des vieux sysvInit au service de la rigidité systemd.
Confirmé sur le site officiel de Fedora : http://fedoraproject.org/wiki/Openvpn, à partir de Fedora16 il faut éditer les liens symboliques à la main…
Visiblement "avoir besoin de network", ça veut dire une chose bien précise pour toi, mais pas pour le reste du monde. Donc "avoir besoin de network", ça veut dire quoi pour toi ?
Interfaces actives, possibilité d'envoyer et de recevoir des trames.
Pour systemd ( et j'aurais tendance à dire pour les systéme d'init depuis des années ), ça veut dire que le sous système network est la, genre tu as l'interface lo qui est disponible à minima, et un programme qui peut avoir besoin d'une interface réseau non spécifique va réussir à se lancer, et raisonnablement supposer que le routage marche pour aller sur internet ou le réseau local, si besoin.
Le truc c'est que ca fait beaucoup trop.
J'ai besoin d'activer iptables AVANT tcp/ip (enfin besoin est un bien grand mot - disons que ca m'évite de patienter/tuer dhclient à la main et de relancer les scripts à la main.) Sauf systemd a besoin que tout network remonte d'un bloc (sinon il panique).
Voici ce que je voudrais qu'il se passe :
a) creation du pont ext0 interface réseau publique, int0 interface réseau privée
b) chargement des iptables (dont j'ai besoin pour mes VPN)
c) connection pptp
d) connection VPN
e) chargement IP et initialisation de la couche IP pour int0
Ce qu'il se passe
a) creation du pont ext0 interface réseau publique, int0 interface réseau privée
b) Tout network rapplique avec IP et tout le toutim
c) chargement de iptables
c - en parallèle et je peux rien y changer) La couche IP s'initialise pour int0, dhclient commence à tourner dans le vide
d) connection pptp
e) connection VPN : echec vu que IP et dhclient ont déjà la main sur int0
f) login prompt
g) à la mano on down int0
h) à la mano on relance VPN
i) à la mano on up int0
Alors bien sur on peut tricher en ne créant le bridge et le VPN qu'une fois que tout le reste a démarré, mais ca ralenti le boot, et les config deviennent chiante à lire, surtout qu'il ne faut pas oublier d'effacer/refaire les liens symboliques en cas de changement.
pour la maintenance, non je pige toujours pas. Quand je fait ça, je modifie la config, et je fait un reload.
Et tu fais ca comment en systemd ? Il y a deux reload en systemd
systemctl nomduservice reload -> recharge la config compilée pour nomduservice, ignore complètement le fichier ini
systemctl daemon-reload -> recompile toutes les configs de tous les services activés.
Ben que je suis en maintenance, je ne veux ni l'un ni l'autre et il n'y en a pas de troisième.
ATTENTION : systemctl enable et systemctl disable lancent aussi une recompilation de toutes les configs.
Donc si tu es parti sur "je refait les scripts d'init plutot que de faire un script de maintenance à part"
Et comment je dis à systemd de faire un reload d'un service mais avec un autre fichier de config ? J'ai 0 commande pour le faire, le seul truc que je peux faire c'est créer à la main des liens symboliques, éteindre le service et le relancer avec un autre nom en utilisant la conf du lien symbolique. Mais faire un reload depuis un nouveau fichier de config n'est pas possible en systemd (et vu la gestion des dépendances auto-évaluées ca ne le sera probablement jamais.)
si tu le fait pas et que tu rajoutes exprès des communications entre ton shell sous forme de variable et le script d'init, désolé, mais tu fais les choses de façon porcasse
Sans sytemd je suis propre (un seul fichier coherent avec lui même qui gère tout ce qui a besoin d'être pris en compte du début à la fin) avec systemd je ne sais pas faire. Donc oui je sauvegarde des fichiers temporaires et je les lits dans un autre script et oui c'est crade et oui je voudrais faire autrement, mais je peux pas.
Enfin, pour ton truc qui lance des services super long à démarrer au point de confondre systemd, vu que la suggestion "utilise le fichier pid" semble pas te plaire, je propose plus simplement "sépare ton script en plusieurs unités systemd".
a) C'est pas que la version "utilise le fichier PID" ne me plait pas, au contraire j'adorerai l'utiliser. C'est qu'elle ne marche pas vu que systemd ne relit pas le fichier régulièrement. Il le lit une fois, met les infos en mémoire et c'est fini.
b) Faire plusieurs unit ne fonctionne pas non plus.
En init classique mon premier programme de synchro récupère pleins de paramètres et lance le second programme avec ces paramètres. Hors je ne sais pas passer de paramètres d'une unit à l'autre en systemd. (Et là pourtant j'ai cherché) setenv ne fonctionne que dans l'inti et est accessible à tous les enfants (donc vachement pratique si on veut lancer plusieurs serveurs).
Pour finir j'ai pas besoin d'une unit pour le logiciel de sync, qui va nécessairement s’arrêter et qui n'a jamais besoin d'être lancé seul (limite ca serait même une très mauvaise idée).
Comme je suppose que tu va me dire "j'utilise pas pam"
Si j'utilise pam, mais le problème n'est pas là. C'est très bien que pam déplace les instance sshd d'un cgroup à l'autre. Mais ca me rajoute encore un truc de plus pour que ca fonctionne normalement. Et en plus même si j'ai pam, tout le monde ne se logue pas nécessairement via pam. Si je me logue par certif il se passe quoi ? Et par kerberos ? Et par ldap ? Et si le process d'authentification n'est pas sur la même machine que le ssh ? Et si c'est même pas un linux ?
Est-ce que ca marche si j'oblige tout le monde à passer par pam et que j'utilise les modules pam-* qui vont bien ? Et quand je met à jour il se passe quoi ?
Le truc c'est pas que ce soit impossible, c'est que ca me complique horriblement la vie. Et j'aime pas monter une usine à gaz pour retomber sur exactement le même résultat qu'avant.
Pour tomcat, je suppose (parce que comme d'hab, tu dit rien de précis donc faut deviner),
Ca doit pas être trop difficile à deviner vu que tu t'en sors.
que le souci vient du fait que quand tu relances tomcat, tu veux pas relancer chaque appli qui tourne à l'intérieur mais faire les choses de façon plus fine. Pour ça, pareil, je pense qu'il faut traiter chaque applications comme un service séparé, et trouver le moyen d'intégrer ça à systemd
Oui mais si on reprend les point précédents, à savoir
- systemd ne lance pas automatiquement les fichiers basé sur templates, il faut rajouter les liens symboliques à la main
- chaque serveur peut avoir plusieurs workers, donc plusieurs processus et j'aimerais bien tuer tous les processus d'un serveur sans abimer les autres (par exemple relancer tomcat admin mais pas les applis)
- les fichiers de config ne sont pas raffraichits automatiquement quand on les modifie.
Tu mets tout ça ensemble et tu arrives a des situations sympas avec ta solution :
Par exemple si un dev veut modifier le catalina ou créer un nouveau serveur, il faut qu'il te passe un coup de fil (ou qu'il ait les droits admin - et ça, c'est pas possible).
Comment tomcat admin va-t-il faire pour raccrocher les wagons ? Qu'est-ce qu'il se passe si je relance un site depuis tomcat-admin et pas depuis systemctl ?
Si j'ai un worker qui déconne ? Comment je le tue ? (je veux dire à part avec les droits root et un bon gros SIGKILL dans sa face) ?
etc. etc.
[^] # Re: Questions
Posté par Kaane . En réponse au journal Linux from scratch face à udev. Évalué à 2.
j'ai peut-être à tort supposé depuis ton avatar que tu utilisais un *BSD
Ah mais je suis totalement BSDiste, viral et barbu comme l'indique mon avatar, et mon /bin/sh de référence est celui de FreeBSD. Je ne crois pas que ce soit un dash ou un ash.
Mais bon l'idée était surtout trollesque - je m'attendais à ce que mon interlocuteur revienne à la charge en me disant que dans mon sh aussi il pouvait y avoir du segfault. Bon après comparer la probabilité de problème entre une appli complète lié à libdbus et une rikiki sh ca aurait été drole.
Ca a pas pris - dommage.
[^] # Re: Questions
Posté par Kaane . En réponse au journal Linux from scratch face à udev. Évalué à 2.
Euh… dash c'est sh (c'est un port du sh de NetBSD). Tu pensais à bash j'imagine ?
dash c'est le port de ash si je me souviens bien. C'est vrai qu'il est très léger et très POSIX, ceci dit je n'invoquerais quand même pas dash directement dans mes scripts.
[^] # Re: Questions
Posté par Kaane . En réponse au journal Linux from scratch face à udev. Évalué à 6.
Pour bouger des pid dans le cgroup, c'est écrit dans la doc qui se trouve facilement via "cgroup pid move" sur un moteur de recherche. Exemple de résultat
Sauf que
a - c'est pas si évident que ça de trouver le cgroups qui va bien
b - systemd n'aura pas forcément conscience de ce changement, en fait il est même très fortement déconseillé de forcer une mise à jour ( http://0pointer.de/blog/projects/cgroups-vs-cgroups.html ) extrait :
> systemd will also maintain its own, private, controller-less, named control group hierarchy which is mounted to /sys/fs/cgroup/systemd/. This hierarchy is private property of systemd, and other software should not try to interfere with it. This hierarchy is how systemd makes use of the naming and grouping feature of control groups (A) without actually requiring any kernel controller enabled for that.
Dans la page entière il explique la différence entre les cgroups pour le nommage et les cgroups pour le controle, les seconds étant très impactant en terme de perfs il n'utilise que les premiers. Sauf que derrière vu que c'est privé, que systemd ne veut pas que je l'altère et que je n'ai pas de moyen de savoir quand les altérations des cgroups publics sont prises en compte (ni même si elle le sont) comment je fais pour informer systemd d'un nouveau processus ?
c - dans certains cas (apache, postgresql, postfix etc.) quand le processus maitre se casse la gueule il faut fermer tous les sous process et redémarrer à vide, mais dans d'autres cas (tomcat, sshd par exemple) je ne veux surtout pas tuer les sous process, en cas de redémarrage je veux les garder en vie et les rattacher au cgroup du nouveau processus maitre. Une fois de plus j'ai pas trouvé comment faire.
Pour tes trucs trop compliqués ou spécifiques, je pense qu'il a été dit facile 20 fois "tu peux garder ton script sysv".
Et j'ai dit 20 fois : non je ne peux pas, il ne marche pas dans le cadre de systemd.
Que ce soit parce qu'il lance pleins de processus et que systemd se retrouve à distribuer des watchers partout
Que ce soit parce qu'il met très longtemps à démarrer (gros check/sync au démarrage) et que systemd va mettre son watcher sur le process de synchro au lieu du process maitre (et donc me certifier mordicus que mon service est planté à partir du moment ou celui-ci aura enfin démarré)
Exemple de truc qui serait sans doute digne de la complexité dans laquelle tu aimes baigner :
Euh… Le truc fait 20 lignes et lance une appli même pas démonisé, un script RC standard avec un peu de réseau, un peu de controle par API en fait 200. Donc non c'est pas la complexité
que j'aimedont j'ai l'habitude.Pour ton histoire de maintenance, la solution est pourtant simple, tu peux faire un second service avec juste la config qui diffère.
Et qui va forcer un reload sur le premier service ? Ou bien j'arrête le premier service et je lance le second ? Et si je dois coder un fichier de conf à la va vite pour palier à un gros soucis il faut d'abord que je créé une nouvelle unit et que je la lance à la main ? Et si j'ai 20 services à mettre en maintenance ca me fait 40 scripts à maintenir ?
Non sérieusement j'aimais bien l'option ou en changeant une variable d'environnement et en lançant un script tout se passait comme je voulais.
Ca doit pas être super du de permettre un systemsct $service overload_reload $nouveau_fichier_de_conf.
Ou mieux, tu fait comme avec sysvinit, tu stoppes le service et tu lances à la main, puis tu fais l'inverse.
Je veux pas stopper le service, je veux changer sa conf. J'ai besoin que le service reste actif parce que d'autres éléments non modifiés sont toujours utiles (voire vitaux) à mon système. Par exemple je veux rediriger le DNS du site corporate, pas priver tout le plateau de résolution DNS, je veux ajouter une règle de transformation dans postfix pas arrêter le mail local etc.
Et avec sysvinit j'utilisais les outils de controle de base et ca se passait bien. Avec systemd c'est pas que ca se passe mal, c'est que je n'arrive pas à comprendre tout ce qui se passe et je ne vois pas comment faire pour récupérer/transmettre l'info.
Si tu veux lancer un tunnel gre non ip, ben tu fait un unité qui le fait, et tu t'arrange pour que ça soit fait avant network ( en rajoutant, genre "before" dans l'unité ).
Mais j'ai besoin de network, c'est dans mon script network que je veux que TCP/IP arrive plus tard. Et systemd est incompatible avec ce comportement.
Actuellement, tu as sans doute du écrire ton propre script, et visiblement, ton cas d'usage est assez rare pour que personne ne propose de patch
Mon script est assez courant en fait (Utilisé par pas mal de gens qui ont soit un modem ADSL en usb soit une config réseau sécurisé) et c'est un des gros points de ralage contre systemd. Ca n'est pas bloquant en soit, juste que ca ralenti le boot de façon chiante (vu qu'il n'y a rien sur le réseau hors vpn le systeme va essayer pleins de trucs, attribuer des adresses par défaut etc.)
L'autre gros point de ralage concerne les partitions chiffrées, pas mal de modèles de chiffrement sont incompatibles avec systemd aussi.
En fait, tu peux aussi juste rajouter une unité network qui remplace celle de systemd, et grâce à l'usage judicieux de répertoire
Figure toi que c'est ce que j'ai essayé de faire. Et systemd aime pas du tout la blague - pour lui network ca veut dire pleins de choses et son comportement est étrange quand ça ne se passe pas comme prévu.
Enfin pour l'exemple d'apache avec préservation des sockets ( je suppose que tu veux dire dans ce cas précis port tcp )
Ma phrase n'est pas claire, c'est de ma faute. Je pensais plutôt aux sockets de l'autre coté d'apache (vers les proxy, les caches, les X-cgi bidouillés), mais c'est vrai que si je fais ouvrir par systemd plutôt que par apache lui-même, je n'ai qu'à m'en prendre à moi même. Ca me paraissait pratique de pouvoir bufferiser les requètes le temps qu'apache redémarre, mais c'est juste pas possible. Tant pis.
[^] # Re: la guerre de s unices
Posté par Kaane . En réponse au journal udev forké. Évalué à 2.
Et c'est toujours possible avec systemd, je ne vois pas le problème.
Si je fais systemsctl reload "monfichier de conf" ca va executer tructl reload "monfichierdeconf" ou ça va me mettre un message d'erreur ?
Parce que la dernière fois que j'ai testé ca me mettait un message d'erreur.