Anthony Jaguenaud a écrit 1967 commentaires

En fait, je loue un serveur, et j’ai un copain qui en loue un second. En cas de problème, c’est utile d’avoir ce genre de possibilité. Du multi domain, pouvoir choisir quel est le domaine principal d’une machine. Mais, que ce soit simple à configurer. J’avais essayé Kolab, mais je le trouve trop lourd, et il s’installe avec ses propres logiciels… pas ceux de la distrib.
En ce moment, je teste vhffs qui permet de gérer les mails, mais aussi des dépôts etc. et ce base sur la debian stable, ce qui m’arrange.

Ben justement, personnellement, j’ai une gentoo pour mon PC, et des debian stable sur serveur ovh (perso), machine de ma femme et de mon fils. J’ai plus l’impression que c’est de la paranoïa. En tous cas, je n’ai jamais ressenti ça, et pas sur le commentaire sus-cité. Les usages diffèrent, les attentes aussi.

Je ne sais pas comment c’est implémenté. Mais la lib, défini un comportement et garanti un certain nombre de choses.

struct sembuf prendre_fourchettes[] =
{
   {
    .sem_num = 0,
    .sem_op  = -1,
    .sem_flg = SEM_UNDO
   },
   {
    .sem_num = 1,
    .sem_op  = -1,
    .sem_flg = SEM_UNDO
   }
};

Ici on prend les fourchettes 0 et 1. semop garanti que ces deux opérations seront faites de manière atomique. Mais, il ne réserve pas. Si la fourchette 1 est prise mais pas la 0, il ne prend rien. Aucun risque d’interblocage ici. J’imagine qu’en interne il doit y avoir une file d’attente des opérations non résolu, et que à chaque libération, il vérifie si une opération est devenue possible, dans ce cas il la fait, et repasse le processus à READY.

Oui, je parlais d’un MX secondaire, pouvant temporisé les mails jusqu’à ce que le MX principal remarche. (fonctionnalité 1)
Voir, en cas de panne matérielle, que tous les mails reçus aient été dupliqué sur le second serveur, et qu’on puisse l’utiliser comme serveur IMAP de secours. (fonctionnalité 2).

Ok. Je suis d’accord avec ça. Même s’il faut faire confiance à l’outil plutôt que de connaître parfaitement son produit.

Je ne comprends pas ce que tu veux dire dans ta seconde phrase ?

En fait, c’est une déformation professionnelle. Je suis obligé de prouver par A + B que le code produit ne peut jamais faire autre chose que ce qui est demandé. Mon propos était que systemd permet de démarrer les systèmes à la demande, donc de ne plus s’intéresser à savoir qui à besoin de quoi. Puisque l’outil s’autodémerdera©. Je trouve que c’est une perte de compétence et de connaissance du système. Ça apportera de la flexibilité par contre. Ai-je été plus clair ?

J'ai traduit modestement ce qu'il disait, mais c'est peut être une subtilité que j'ai introduit malencontreusement

Mon anglais n’étant pas meilleur que le tien, à mon avis, ta traduction me va.

Oui, c’est intéressant :

il supporte des configurations mouvante (hot plug) : on branche un disque, il lance fsck et le monte proprement

Ça peut déjà être fait avec udev.

on peut connaître l'état du système : systemd connaît l'état de tout les deamons

On peut également savoir quels sont les services actifs sur les init standard. Que le PID1 le sache apporte quoi au juste ? Une manière différente d’interroger ?

c'est modulaire : on peut remplacer des parties par nos propres scripts (et ces parties sont bien documentées), il dit que c'est plus compliqué avec rc.sysinit car les dépendances sont moins claires

Ok. C’est un problème spécifique à Arch.

on peut plus facilement lancer un service à la demande notamment avec udev

On peut le faire aussi, il suffit d’avoir udev.

les sockets activation et dbus activation permettent de simplifier les dépendances

Ok. Je suis d’accord avec ça. Même s’il faut faire confiance à l’outil plutôt que de connaître parfaitement son produit.

on gagne en sécurité via les cgroup

Mouai, c’est déjà possible aussi.

on peut capitaliser les fichiers de descriptions de services (fini les scripts spécifiques à chaque distribution)

C’est vrai, l’uniformisation du system permet d’uniformiser les configs… mais si c’était un argument, il n’y aurait pas 300 distribution GNU/Linux. Quitte à uniformiser, je préfère openrc. En même temps, je suis gentooiste.

c'est plus simple pour eux d'être plus proche de l'upstream

Je ne vois pas en quoi tu es plus proche de l’upstream. Cela veut dire que c’est les développeurs qui vont faire les fichiers de config de systemd ? Ça rejoint l’argument de l’uniformisation.

logind fait le boulot que consolekit devrait faire (suivre les sessions utilisateurs, donner des droits, etc)

À bon. Consolekit ne répond pas aux exigences. Quand je lis devrait je comprends que consolekit ne répond pas au besoin de cette personne d’Arch, mais en quoi c’est-il ce que consolekit _devrait faire_ ? Les dév de consolekit doivent le savoir également, et donc faire la correction, non ?

il est rapide ou pas, mais il s'en fout

La rapidité n’est pas un argument, on est d’accord.

J’avoue que je n’avais lu que les 3 premières raisons. La seule bonne raison, à mes yeux, c’est l’uniformisation. Hélas, j’aurais préféré un truc du genre freedesktop, qui définisse une norme, plutôt que systemd.

Bientôt, ce sera Lennart/Linux qu’il faudra écrire ;-). Je ne suis toujours pas convaincu par les arguments, même si je comprends que beaucoup le soit. La suite sera intéressante.

Si tu relis le post initial, il ne parle pas de debian… ça a été ajouté ensuite. Mais si debian fait l’effort d’avoir des packages : apache2-php… ce n’est pas le cas de toutes les distributions binaires.

En regardant la page des fonctionnalités, je ne vois pas l’utilisation possible d’un second serveur en backup. Pouvant attendre que le serveur principal remonte en temporisant les mail, partager les mails entre les deux serveurs…

Un rajout là dessus, un (ou plusieurs) sémaphore peut aussi être utilisé conjointement à un mutex dans le cadre de synchronisations complexes, où on l'utilise pour gérer un nombre de processus en attente d'un état particulier.

Les sémaphores sysV, rendent justement ce service. Il suffit de déclarer un seul ensemble de sémaphores, et on peut faire diverses opérations conjointes. L’avantage par rapport à une implémentation avec mutex, c’est de limité les cas d’inter blocage. Si on prend le cas des philosophes, en un seul appel à semop, je peux prendre les deux fourchettes, ou attendre que les deux soient disponibles. Là où, avec un mutex, il faut prendre le mutex, essayer de prendre les deux fourchettes :

• cas 1 : on peut les prendre ;
• cas 2 : on ne prend pas la première, donc on essaye pas de prendre la seconde ;
• cas 3 : on prend la première, mais pas la seconde, il faut re-libérer la première ;

Ensuite on rend le mutex. Si on est pas dans le cas 1, il faut réessayer de reprendre les fourchettes. Ce qui complique l’algorithme, mais et plus formateur pour un TP ;-).

Réf : Dîner des philosophes.

Oui et non.
La doc est excellente, et j’ai un ami qui l’a installé alors qu’il n’est pas informaticien. Il est quand Docteur en mécanique des fluides. En suivant la doc, ça s’installe assez facilement. Ensuite, il faut prendre son temps au début, comme expliqué plus haut, mettre des use flag par paquet et pas globalement (sauf pour ipv6 par exemple). Ne mettre aucun paquet qui ne soit pas dans la branche stable. Ensuite, les forums ou la mailing liste fonctionnent, même si la mailing liste est un peu morte… mais je crois que c’est surtout que les gens n’ont pas trop de problèmes.
Si tu es développeur, les symptômes peuvent orienter plus rapidement. Mais ce n’est, à mon avis, pas nécessaire.

Espérant avoir répondu à tes interrogations.

S'il y a une quantité de ressources à allouer qui peut varier, alors ce n'est plus un sémaphore,

Pourquoi ? Les opérations sur les sémaphores ne sont pas uniquement des +1, -1. Donc, pour une quantité de ressource je trouve ça adapté. Après, s’il s’agit d’allocation de slot… oui, ce n’est pas adapté.

Si on a besoin d'un mutex, on utilise un mutex, pas un sémaphore.

Mon propos est justement, qu’un mutex est un sémaphore, mais un sémaphore avec une seule ressource et donc un sous ensemble des possibilité d’usage d’un sémaphore. Le mutex est un peu comme un bâton de parole. Je le prends, je peux lire ou/et écrire une variable (ou un ensemble de variable), puis je le rend.

Un mutex assure l'acquisition/libération par le même processus d'une ressource unique.

Pas forcément dans un seul processus. On peut utiliser un mutex pour protéger une mémoire partagée entre deux processus.

Un sémaphore au contraire cible des fonctionnements producteur / consommateur,

On produit quoi et on consomme quoi ? Dans le cas de mon exemple, on produit une ressource qui est : « Je suis initialisé », et le chef d’orchestre, consomme ces ressources, pour être sûr que tout le monde à bien fini. Je ne vois pas en quoi ça ne respecte pas le principe ? Sauf, l’usage de l’opération de synchro qui est possible grâce aux sémaphores sysV.

Oups, j’ai fait ça vite. J’ai copier/coller la barre d’adresse de firefox. Mais je n’ai pas revérifié sur le journal.

Merci pour la correction.

Ok, des sémaphores, on faisait ça en IUT

Très bien, puisque tu maîtrises le sujet, ce journal ne t’est pas destiné.

Tu as raison. Je n’ai pas bien expliqué pourquoi je fais ce post.

Ça fait quelques temps que je voulais écrire un petit journal sur les sémaphores, pour plusieurs raisons. 90% si ce n’est plus de l’usage d’un sémaphore se fait via des mutex, qui ne sont qu’un cas particulier. J’ai l’impression que certains confondent sémaphore et mutex. Donc je voulais faire un post dessus.
Il y a un mois à peu près, quelqu’un a proposé une implémentation de fifo. Ça m’a donné l’idée de faire un journal en utilisant les ipc standard en utilisant un sémaphore comme compteur de place disponible. Mais le temps m’a manqué. Suite à la discussion sur le démarrage des démons, je me suis dis, que c’était un bon exemple de sémaphore non mutex.
Mon journal est peut-être un peu rapide, mais le code est disponible, et est, je crois un bon exemple assez compréhensible. Je ne voulais pas poster tout le code sur le journal car ça l’aurait rendu long et indigeste.

J’ai peut-être eu tort.

Sauf qu’avec la vieillesse vient la sagesse.

À combien évalue-t-on l’espérance de vie d’une distribution ?

En plus du package.use, il y a le package.keyword qui permet de sélectionner des versions instables de certains paquets seulement. Attention néanmoins, il faut parfois ajouter certaine dépendance, mais portage vous le dira. Il y a aussi package.mask pour masquer un paquet ou une version.

Pour chaque ligne on peut écrire :
=app-editors/vim-2.35
>app-editors/vim-2.35
…

Ce qui en fonction du fichier imposera ou interdira l’utilisation de vim en version 2.35. Ou les versions strictement supérieure…

Il faut passer du temps au début, mais après, c’est que du bonheur. Enfin au coup de gueule près.

J’ai a peu prêt le même ressenti.

J’ajouterai, un exemple sur wine. À un moment, il y avait un bug pour jouer à DIII. Et il fallait patcher le source avant installation. La solution est d’une simplicité effrayante, il suffit de copier les patchs dans :
/etc/portage/patches/app-emulation/wine/ et emerge se débrouille. Quand les patch sont appliqué dans l’appli, il suffit d’effacer ces fichiers.
Tout fonctionne ainsi de manière simple.

Dans tous les journaux sur des distributions tu trouvais des commentaires pour dire qu'Arch c'est mieux.

[vendredi]
Ça c’est parce que nous, on sait que gentoo c’est mieux. Pas besoin de le dire pour s’en convaincre… ;-)
[/vendredi]

Je conseillerais plutôt testing.

J’avais lu, il y a quelques années, que sid si elle cassait ce n’était jamais pour longtemps. Alors que testing, si un bug est introduit, il faut que la correction passe par sid ce qui peut prendre du temps.

Et sinon, avec des vrais arguments, ca donne quoi ?

N’est-on pas vendredi ?

C'est que par rapport à plusieurs années en arrières, je trouve qu'on entend beaucoup parler de Arch et bien moins de Gentoo.

Il n’y a plus de nouveauté, il n’y a pas de version tout les 6 mois, donc peu de news, peu de problème. On entend surtout parler de Arch en ce moment à cause de systemd, sinon, c’est une distrib avec une base installé d’utilisateur qui évolue peu. Ce genre de coup de gueule, ça m’arrive tous les 2 ans, suite à un problème sur xorg… Un flag que je suis le seul à mettre en même temps qu’un autre sur un autre paquet. Il est impossible de tester toute les combinaisons de flag, arch vu le nombre de possibilité. Et c’est d’ailleurs très rare.

J'ai l'impression que la première a séduit pas mal d'adeptes de la seconde, et il faut dire qu'elles partagent une certaine philosophie.

C’est possible qu’une partie soit parti. À l’époque, j’avais voulu tester Arch, et ce n’est pas aussi simple d’être souple. Après il y a ma connaissance de gentoo et ma découverte d’Arch, toujours est-il que je ne peux pas simplement avoir kdevelop avec le support cvs, git mais pas svn sous Arch en utilisant normalement le système de paquet.

Pour les utilisateurs qui cherchent une rolling release, je les oriente plutôt vers debian/sid, qui est pas mal, à part en période de freeze où là, ça bouge plus en rolling ;-)

En cherchant à retrouver le dernier CD d’install je m’aperçois qu’il date du 19 septembre 2012… le précédent c’était 2010 je crois. Pas eu de news.

Non.
Arch, j’ai l’impression d’une distribution bricolée, là ou gentoo à l’air propre. Pour une rolling binaire autant prendre debian/sid.

Salut,
j’ai eu ce constat après 10 ans ensemble, et deux ou trois gros coup de gueule. Mais finalement, est-ce mieux ailleurs ? Et c’est là, que finalement je reste. C’est ça la passion, de temps en temps tu exploses, mais sans ta dose tu es perdu. Et je suis sûr de ne pas retrouver mieux ailleurs. À chaque tentative d’infidélité, je me rends compte que c’était mieux, alors je reviens et elle m’accueille toujours les bras ouverts sans ressentiment.

Pour le mariage, je parle bien sûr de mon mariage avec gentoo, mon autre mariage fonctionne un peu différemment.

Merci, c’est gentil.

Je te prie de m’excuser si je me suis emporté. Je réagissais à cette phrase :

Ce à quoi il va répondre que ce n'est pas parce qu'il écoute la socket qu'il est prêt.

Qui sous entend, de la connivence entre deux personnes qui ont compris et quelqu’un a qui ce n’est même pas la peine d’expliquer. Ce n’était sans doute pas ton propos. Donc je réitère mes excuses pour ma petite phrase mesquine.

Je suis incapable de coder une BD, mais synchroniser un démarrage me semble plus simple. Peut-être une question de cœur de métier.

Avec des remarques comme ca on serait tous en train de coder en assembleur …

Je te parle de conception logiciel tu me parles langage et implémentation… pas tout à fait la même chose.

Pour illustrer mon propos, je me suis fendu d’une implémentation simple de la bonne façon de faire à mes yeux. Qui ne me semble pas très compliquée.

main.c :

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

void demon()
  {
   sleep(60);
  }

void fils()
  {
   pid_t l_pid;

   printf("Debut du fils\n");
   /* Initialisation */

   /* Bricolage */
   printf("Debut du bricolage\n");
   sleep(10);
   printf("Fin du bricolage\n");

   /* Pret */
   printf("Fils %d\n",getpid());
   l_pid = setsid(); /* A partir de la, le process n'est plus associe a un terminal */
   printf("setsid() = %d\n",l_pid); /* Les printf fonctionnent puisque herite du premier fork */
   sleep(10);
   printf("Enfin pret.\n");


   /* Ferme les flux standard */
   close(0);
   close(1);
   close(2);

   l_pid = fork();

   switch (l_pid)
     {
      case -1:
         /* Soyons bourrin */
         exit(1);
      case 0:
         demon();
         exit(0);
      default:
         /* Synchronise le pere */
         exit(0);
     }
  }

void pere(pid_t p_pid)
  {
   /* Attente du fils */
   printf("Attente du fils\n");
   wait(p_pid);
   printf("Fin de l'attente\n");
  }

int main()
  {
   pid_t l_pid;

   l_pid = fork();
   switch (l_pid)
     {
      case -1:
         printf("Fork fail\n");
         return 1;
      case 0:
         fils();
         printf("Fin du deamon\n");
         return 0;
      default:
         pere(l_pid);
     }
   printf("Fils en demon\n");

   return 0;
  }

On va utiliser 2 terminaux. Un avec un watch, et l’autre pour avec la commande lancée et la compilation.

Dans le terminal 1, on compile :

$ gcc main.c -o dem
$ 

Sur le 2 on surveille les processus :

$ watch "(ps -u user | grep dem)"

On démarre le démon sur le terminal 1 :

$ ./dem
Debut du fils
Debut du bricolage
Attente du fils

Pendant ce temps sur le terminal 2 :

 5597 pts/7    00:00:00 dem
 5598 pts/7    00:00:00 dem

Au bout de 10s :
Term 1

$ ./dem
Debut du fils
Debut du bricolage
Attente du fils
Fin du bricolage
Fils 5598
setsid() = 5598

Term 2

 5597 pts/7    00:00:00 dem
 5598 ?        00:00:00 dem

Enfin, la dernière étape :
Term 1

$ ./dem
Debut du fils
Debut du bricolage
Attente du fils
Fin du bricolage
Fils 5598
setsid() = 5598
Enfin pret.
Fin de l'attente
Fils en demon
$ 

Term 2

5661 ?        00:00:00 dem

Pour résumer, on a un fork, le père attend sont fils. Le fils créé son groupe de session setsid, puis fork. Le nouveau fils est détaché, il ne se terminera pas avec son père. Le premier fils se termine, rendant la main au père initial. On voit ici, que si l’initialisation est faite au bricolage, le dernier fils héritant du contexte de son père. On peut rendre la main quand on a fini de s’initialiser, d’ouvrir ses socket…

Édition: correction mise en page.