Sytoka Modon a écrit 4565 commentaires

Sur une machine de calcul, on utilise les CPUSET et les CGROUP pour tuer tout ce qui reste d'un job après que le walltime soit terminé. La problématique ici est la même donc comme dis ci-dessus, les CGROUP permettent de faire le boulot.

Sinon, le CACHE de socket, cela ne permet pas de mettre en cache les données pour le serveur syslog en attendant qu'il se lance ;-)

J'ai pas regarder systemd de près mais si c'est bien le processus PID=1 qui fait tout cela, ça craint ! J'espère qu'il se fork ou qu'il envoie des petits...

sysvinit sous debian gère le lancement parallèle des services. D'ailleurs, je crois que c'est une version qui provient à la base de Suse.

Sinon, comme dis dans un autre post, il y aussi la voie très intéressante qui avait été lancé avec runit (et socklog) sur des idées d'ailleurs à la base de D. J. Bernstein (daemontools)

http://smarden.org/runit/

L'idée de base semble dans le même esprit mais découpé en plein de petit programme faisant une et une seule chose... L'idée fondamentale est d'avoir un programme initial "/sbin/init" (PID=1) le plus petit possible ce qui me semble dans la logique même...

Je ne vois pas pourquoi les programmes "modernes" s'évertuent à vouloir par défaut être en mode serveur et à tout regrouper dans une seule instance ce qui est problématique en cas de plantage (iceweasel, geany...).

Les IHM qui écrivent les fichiers perdent souvent les commentaires, l'indentation... Je sais qu'il y en a qui y arrive mais c'est pas le plus courant. Le dernier exemple qui me passe par la tête est backuppc qui fait un dump de l'objet config et donc perds tous tes commentaires (d'ailleurs, c'est pas nickel nickel d'avoir fait un dump mais bon).

Ceci dis, l'exemple que tu prends n'est pas le plus facile. J'ai quelques fichiers /etc/network/interfaces qui définissent plus de 20 interfaces réseaux et peut être qu'un interface.d aurait été pas mal. D'ailleurs, le fichier qui me pose le plus de soucis à gérer automatiquement pour le moment est /etc/ssh/sshd_config. Dommage qu'on ne puisse inclure les fichiers d'un dossier dedans car comme c'est un fichier TRES sensible, c'est toujours délicat de faire des grosses modifications dedans !

Et que dire des autres architecture que debian supportent ... qui souvent d'ailleurs bloque la sortie de la distribution.

L'aspect multi-arch et multi-OS permet d'être plus robuste avec des API claire, stable et identifié pour la plupart. Cela donne aussi du temps au temps. C'est parfois énervant mais c'est aussi important. Ceci dis, il ne faut pas non plus s'ankyloser, il y a un temps pour tout !

Ce que j'aime bien dans un système UNIX, c'est qu'il y a plein de bout en script au coeur du système, c'est donc assez facile d'intervenir dessus et de l'adapter. C'est aussi une grande force anti-virale... J'aimerais bien que PAM par exemple soit plus facilement scriptable qu'actuellement.

J'ai déjà pris l'exemple du serveur SMTP Qpsmtpd programmé en langage de script. Très facile d'aller y modifier un truc ou deux alors que c'est quasiment impossible à un admin système de base comme moi si c'était un Postfix ou un Exim.

Il est vrai qu'un coeur en script, c'est pas forcément la joie pour les GUI ;-) Sinon, il y a un outil assez sympa, Config::Model, qui pars sur l'idée que plutôt que de vouloir tout uniformiser, tout normaliser, la diversité peux avoir du bien donc c'est à la surcouche de s'adapter. Personnellement, je ne l'utilise pas car vi me suffit dans 99% des cas.

Un système binaire peut à mon avis être intéressant dans le cas de forte charge mais avec un nombre d'entrée pré-définit. une base de type RRD à rotation automatique permet alors un accès direct en écriture. Cela pourrait aussi être un backend à syslog et pourrait servir par exemple pour des log de firewall...

Sinon, les GUI pour lire les log sont tout sauf pratique. C'est bon pour les petits dépannage du genre un installateur d'un soft Windows qui au premier click téléphone déjà a sa hotline ;-) Jamais pu utilisé les journaux Windows tellement c'est peu pratique...

Si j'ai bien compris une partie des débats, un des problèmes majeurs est que syslog n'est pas lancé en premier donc que faire en attendant que syslog soit opérationnel ? systemd ne pourrait pas ouvrir le port le syslog, écouter et tamponner en RAM (ou ailleurs) en attenant que syslog démarre et reprenne le tout ? J'ai cru comprendre que systemd était capable de maintenir les descripteurs de fichier lors d'un redémarrage de service ?

Sans boucle et en monoligne... Je suis juste passé par ldd. Pourquoi utilises tu objdump ?

 ldd /bin/bash | awk '{print $1}' | xargs -r dpkg -S 2>/dev/null | cut -f 1 -d ':' | sort -u | xargs -r dpkg -l | grep ^ii | awk '{print $2,$3}'

Solution simple

./depends.sh /bin/bash | sort -u

En https, de plus en plus les navigateurs mettent le nom de domaine ou plus précisément la fin du nom de domaine. Je n'aime pas cela car cela revient à simplifier l'arbre DNS avec un seul sous domaine.

Exemple virtuel :

https://www.linuxfr.org -> linuxfr.org

Sous domaine

https://www.machin.linuxfr.org -> linuxfr.org

Sauf que en pratique, je gère le domaine "machin.linuxfr.org" de manière autonome et que je n'ai, au final, que peu à voir avec "linuxfr.org". Que le www saute car il représente le nom de la machine, pourquoi pas, mais pourquoi faire sauter une partie du nom DNS de domaine ?

Exact, à part un ingénieur en instrumentation qui ne supportais pas LabView, tous les autres expérimentateurs ont fait ce choix là. Du coup, le marché est captif pour National Instrument. En interne, la gestion des versions des différents programmes de pilotage est du coup ... folkorique. Si quelqu'un sais comment gérer de manière simple dans le temps et de manière collaborative les programmes LabView, je suis preneur.

De plus en plus de chercheur utilisent Python à la place de Matlab (ou Octave ou Scilab...). On se retrouve cependant avec le même problème que la suite MS Office, c'est jamais compatible à 100%. Si c'est la suite elle-même (ou Matlab), la non compatibilité d'une version à une autre passe mieux...

Ne pas avoir confiance totale dans une boite ne signifie que tout ce qu'elle fait est de la merde ;-) Pourquoi de suite prendre une position extrême ?

Par ailleurs, dans les exemples que tu donnes, il y a une différence entre aider à maintenir un système et développer un nouveau système... Par exemple, les débuts de network-manager ont été très difficile, l'outil était beaucoup trop lié au fait d'avoir une IHM graphique.

Avec le temps et tous les contributeurs, les outils se bonifient ou trouvent des remplaçant, c'est tant mieux ;-)

Je parle de mon labo car c'est plus intéressant que chez moi, il y a un peu plus de poste à gérer... C'est pas juste un truc avec 10 machines. L'informatique personnelle, un PC = une IP = une personne ne m'intéresse pas particulièrement.

Sinon, j'aime effectivement bien le Perl (et le CPAN), plus que Python par exemple mais je déploie aussi des trucs en Python, PHP... Quand au dev, je n'en fais plus beaucoup mais je préfère poser des questions parfois candides puis changer d'avis ensuite s'il le faut.

Tiens, ca m'intéresse de savoir quelques grosses conneries que j'aurais dites car je ne doute pas d'en avoir dis quelques unes ;-) Au moins, je pourrais me faire un coup d'auto-dérision lundi à la pause café !

Ca parait simple mais cela met tout sur un seul processus... Via la séparation, le démon de relance pourrait être dans un cgroup différent par exemple. L'idée en soi est assez séduisante je trouve.

Et puis, depuis quand l'utilisateur final s'intéresse à la tripotée de démon qui tourne ? L'architecture du processus numéro 1 ne me semble pas avoir une quelconque interaction directe avec l'utilisateur.

J'ai jamais dis que c'était facile.

Si c'est un bête SIGCHLD, pourquoi ne pas le rajouter au processus init actuel ? Il fait comment en cas de fork ?

Qu'est ce qui empêcherait monit ou mon d'être notifier directement ?

C'est sur que sur tous mes serveurs, je passe mon temps à accéder à la ligne 100000 des fichiers de log !

Perl est capable de trouver cette ligne très rapidement et c'est pas une action vraiment utile en temps réel sur un OS standard... Que sur un serveur central de log, cela soit utile, OK, mais on peux alors utiliser un backend SQL spécialisé...

Combien de service démarre avant rsyslogd ? C'est le problème de la poule et de l'oeuf... Ni a t'il pas un moyen de gérer cela d'une autre manière. Par exemple, ces applications enverraient leur log au noyau donc klogd tant que syslogd n'est pas actif. Tout remettre en cause et rendre les choses incompatible pour quelques secondes me semble excessif.

J'utilise monit pour relancer les services qui crash. Ca marche... On aurait pu améliorer monit !

Monit permet de dissocier le démarrage de la supervision des services eux-mêmes.

Un des principes d'UNIX, faire une chose et le faire bien. Je trouve personnellement que systemd en fait trop et j'aime pas trop son connecteur DBUS. Pour un processus aussi sensible, cela fera la joie du vers un jour...

Aller au 100 message -> ligne 100

Format libre = souplesse au cours du temps. Des outils comme Perl parse cela sans problème...

Date -> bordel -> timestamp

Base données mysql -> bof. Je verrais plutôt une base de taille fixe à la RRD s'il fallait changer ou plutôt donner le choix !

Non compatibilité avec syslog -> débile

Problème au démarrage -> je croyais qu'il y a avait klogd pour ca.

...

Syslogd n'est pas parfait. Plutôt que de faire des améliorations, on change tout ! Ca va être un produit conçu à la mode du moment. Red-Hat a déjà foutu des fichiers XML de config à droite et à gauche, c'est bien pour les IHM payante de gestion de parc mais c'est loin, très loin d'être parfait. Bref, j'ai pas une confiance à 100% dans tout ce que fait Red-Hat (d'ailleurs, j'ai quitter les distributions Red-Hat il y a plus de 10 ans pour justement des problèmes de conception).

Idem, je ne sais pas vraiment comment marche le son sur mon PC mais je ne vois aucun truc en puseaudio. Je précise qu'il y a toujours 2 sessions en // par deux utilisateurs différents. J'ai rien modifié, tout marche tout seul (Debian Squeeze).

Je ne crois pas trop au tout espace utilisateur pour les drivers...

Par contre, avec la virtualisation qui s'invite de plus en plus partout, le "nettoyage" par le noyau d'un driver foireux sera de plus en plus facile à faire en restant en mode noyau. Xen par exemple explore cette piste en mettant certain driver dans des dom0 prime (cela reste pour le moment de l'ordre de la recherche je crois).

J'ai pas compris son problème avec la sécurité. Tu envois tes log sur un serveur central qui est blindé...

Si effectivement, toute ton architecture est une passoire, les log ne serviront à rien.

Sinon, la souplesse d'UNIX est de faire des choses simples, souples et orthogonales. A force de trop vouloir normalisé, il va finir par trop contraindre l'ensemble qui n'arrivera pas à évoluer au cours du temps et devra être remplacer un jour par autre chose car il aura oublié de traiter un cas particulier.

A l'université, on utilise bien plus de 1000 Windows, jamais entendus parlé des sources...

Je pense que c'est quand même un peu plus compliqué pour avoir les sources !

Les "Stores" ont aussi un avantage (ou un inconvénient) comparé au dépôt des distributions, la personne dépose elle même son application et en gère elle même les évolutions. Je suis sur qu'un paquet d'application que l'on trouve dans l'AppleStore aurait un mal fou à intégrer les dépôts debian par exemple ;-)

On ne paye pas le prix des industriels mais depuis quelques années, le tarifs montent bien plus vite que l'inflation. Par exemple, Comsol a été multiplié par 5. La palme du pire a été un module Ansys qui a pris un facteur 7 en 2 ans... Heureusement que nous n'en avons pas une utilisation intensive !

Bien sur, les solver d'Ansys sont natifs ! C'est le workbench qui m'a l'air d'être une daube de première.

Sinon, nous utilisons en pratique Soliworks dans mon labo (c'est aussi Dasasult mais beaucoup plus abordable) mais a petite dose par les expérimentateurs afin de dessiner les futurs manip. Rien de crucial de ce coté là. Je vais regarder du coté de NX mais à vrai dire, c'est une activité tellement annexe chez nous que mon point est assez faible dans les décisions ;-)

Sur debian squeeze, j'ai basculé tous mes serveurs sous sssd. C'est sssd qui est connecté au LDAP. La configuration est au final bien plus simple et le tout est robuste au petit problème réseau. Bref, même sans réseau, cela fonctionne tout seul en autonomie...