Sytoka Modon a écrit 4549 commentaires

De toute manière, la MAIF avec son fonctionnement mutualiste, emmerde très certainement un certain nombre de gros de l'assurance qui aimerait bien éliminer les mutuelles sur lesquelles ils ont peu de prise !

-1- Ce n'est pas Apple qui a inventé le premier système pilotée à la souris mais Xerox

-2- Avant Macintosh, il y a eu Lisa qui a été le premier système pilotée à la souris chez Apple.

La MAIF n'est pas une "boite" comme une autre. C'est un assureur mutualiste basé sur les enseignants de l'éducation nationale (au tout débuts des seuls instits). Dans le principe, c'est un peu comme une SCOOP. La MAIF appartient a ses adhérents avec un système d'élections… Il y a donc une longue tradition et dans le cas présent, ce ne serait pas facile de changer certaines choses ;-)

Il y a une ligne à changer pour avoir l'ancien comportement.

Perso, j'utilise mosh pour la connexion distante qui résiste au changement d'IP et de réseau ! Tu lances ton xpra dans une session mosh et tu as au final un truc beau ;-)

Bref, je ne me fais pas trop d'inquiétude, pleins de gens ont ce besoin sur ce genre de serveur (que je ne qualifie pas de HPC) et il y a donc une configuration qui marchera. Peu de gens actuellement font tourner VirtualGL sur leur poste perso (sans l'aide d'un sysadmin) donc adapter le système pour lui ne me semble pas inaccessible.

A partir du moment ou on a commencé à écrire les bureaux en variables globales, à ne pas vouloir relancer le bureau lors de reconfiguration mais où on voulait que tout se propage instantanément (dbus, gconfd…), on a commencé à faire des services au niveau session plutôt que d'utiliser des variables d'environnements pour transmettre des paramètres pères fils…

Cette évolution ayant été suivis pas presque tous les bureaux, il faut bien à la fin nettoyer la "merde" qui traîne un peu partout ;-)

des systemes HPC donc ce comportement est juste … debile

Je ne sais pas ce que tu fais comme HPC mais tous les systèmes que je connais, les scheduleurs dégomment tout lors de la fin du script de soumission (équivalent session) ou lorsqu'on arrive à l'échéance du temps du walltime. Si ton système HPC ne fonctionne pas ainsi, pour moi, ce n'est pas un système HPC car je ne vois pas comment le scheduleur pourrait dans ces conditions allouer correctement les ressources et faire des estimations de temps de passage.

Toutes les machines HPC de PRACE, GENCI ou des centres régionaux marchent sur ce principe.

Quel est le rapport avec la choucroute ?

Je reprends ta phrase sur la sécurité et je la place juste sur le concept de socket réseau ;-) Donc attention aux phrases trop générales… Quand aux DSI, on peut être pour ou contre mais cela ne changera rien. Leur comportement est un fait sociétal !

Ceci dis, cela ne me dérange pas que Debian lance ses services par défaut, au contraire. Une machine fraîchement installé n'est pas ouverte sur le net (DMZ) avant configuration… Un service, cela se configure via cfegnine, puppet… et si un service ne sers à rien, il n'est pas installé. Donc sur mes serveurs, un service installé est un service qui tourne. Je n'aime pas avoir du code dormant sur mes serveurs, je trouve cela plutôt dangereux !

Bref, un service mis sur off devrait être (sauf HA…) un service purgé du système de fichier ;-)

La sécurité ça consiste à bloquer les droits par défaut et à donner les droits le plus ponctuellement possible.

C'est un raisonnement tout à fait raisonnable mais il a eu un effet secondaire suite a son application généralisé par les DSI : la bascule de plein (presque tous) de service sur du https… Cette règle simple a malheureusement aussi des effets secondaires négatifs ;-)

Je le sais bien puisque je l'ai aussi proposé ailleurs ;-) L'idée ici est de garder une session en container qui est nettoyé en fin de session et d'envoyer simplement un processus hors de ce container de session, via at par exemple.

Pas tout vérifier mais sur un poste que je vois à distance, udev tourne, dbus aussi et je ne vois pas pourquoi ce qui marchait avant Jessie ne marcherait plus… Il me semblait que gnome ne dépendait de systemd que par un truc con facile a refaire.

En fait, je pense qu'on prends ici le problème à l'envers. Il faut voir que pour cloisonner les choses, on est entré dans le monde des containers (ou cgroup pour simplifié). Du coup, à l'ouverture de session, du ouvre un nouveau container et à la fermeture, tu le fermes. C'est aussi simple que cela et n'a rien à voir avec systemd ou logind ;-) Comme je l'ai dis, les sessions sur les clusters de calculs sont ainsi depuis des années. On pourrait très bien (on a déjà) avoir la même chose avec sysvinit !

Si tu veux lancer un processus qui survive au container, un screen ou un tmux, tu ne dois pas modifier screen ou tmux mais simplement les lancer hors du container. nohup lance hors du shell courant mais pas hors du container. Il faut juste changer cela ;-)

Mais que nohup s'appelle demain outainer ou un autre nom, personnellement, c'est bien pareil. Sur ce coup-ci, cela fait pas mal de temps (plusieurs années) qu'il est dis qu'un jour, la session utilisateur sera certainement par défaut dans un container et qu'il faudra changer quelques habitudes comme nohup… C'est pas un truc que les développeurs de screen ou tmux découvrent aujourd'hui ;-)

Sinon, il faut bien un paramètre admin à changer sur une machine car encore une fois, sur une machine de calcul, on ne peut pas laisser un utilisateur avoir des processus en nohup au delà de sa session (walltime). Bien que je n'aime pas la syntaxe CamelCase des projets gravitant autour de systemd, modifier une ligne, c'est pas la mort. Avec des outils comme cfengine, puppet ou équivalent, c'est déployer sur un parc de plus de 1000 machines en 1h…

Idée au pif (pas testé)

echo screen | at now +1s
Puis dans un autre terminal, tu te connectes à cette session screen qui est normalement pérenne car envoyé par 'at' et non pas ta session !

Yep, mosh charge un peu trop (tmux surtout il me semble).

Redirection -> pouvoir glisser via mosh un retour graphique xpra par exemple ;-)

En fait, le nouveau comportement en question ici, c'est pas tout à fait systemd mais logind. Sur une machine de calcul, lorsque tu lances un job via un scheduleur, il t'ouvre un cgroup ayant un cpuset, un memset… A la fin de ta session (walltime), le cgroup est supprimé avec tout ce qu'il y a avec. Job qui ne finit pas dans les temps ==> nettoyer !

En fait, logind fait exactement la même chose, désormais, il nettoie tout en fin de session via les mêmes mécanismes.

En fait, il faut JUSTE ré-écrire nohup pour qu'il ouvre une nouvelle session indépendante, dans un autre cgroup. Cela me parait tout à fait convenable et peut se faire via une IHM simple ;-) Il a été pris l'exemple de mosh plus haut et couplé à tmux, c'est hyper pratique (et simple)…

tiens, si ça se trouve la modification apportée ne suffira pas…

Elle est documentée partout. Arrêtons la mauvaise foi et essayons d'être optimiste ;-)

Yep, mosh + tmux (byobu) marche d'enfer et la charge réseau est TRES TRES faible (on attend juste la redirection de port).

J'ai des machines sous Jessie qui sont restés sous sysvinit… Cela ne pose aucun soucis !

apt-get install sysvinit-core sysvinit-utils systemd-shim systemd-sysv-


A peu pres tout les HPC que je connais. Ok c'est pas generaliste mais c'est le marche le plus important de linux.

Heu non. Le marché le plus important de Linux est Androïd je pense puis on doit avoir derrière les Box ADSL… Le HPC est à mon avis très très loin derrière. En plus ChromeOS est soi-disant passé devant Apple sur les portables !

Je ne peux que conseiller cette super BD - https://fr.wikipedia.org/wiki/SOS_Bonheur

1. installation SSSD
2. Installation fichiers /etc/sssd/sssd.conf;
3. (Re)Démarrage SSSD
4. Installation fichiers /etc/nsswitch.conf; /etc/auto.master; /etc/pam.d/*;
5. Redémarrage AUTOFS
6. Desinstallation YPBIND

sssd peut tourner sans rien faire, c'est un serveur. Donc on le configure puis après, on se branche dessus en modifiant nsswitch.conf. A ce moment là, on bascule vraiment de NIS à LDAP… Tu peux donc virer NIS en dernier puisqu'il tourne à vide.

Windows Seven pro n'est pas touché par la mise à jour automatique vers Windows 10. Microsoft vise principalement les particuliers… Il ne faut pas donc tout mélanger et croire que les entreprises vont soudainement bougé ;-)

Tu passes trop de temps du DLFP ;-)

Au final, Wayland a t-il encore un intérêt, ne faudrait-il pas faire du natif Vulkan ? Cela avait été envisagé un moment pour X11…

C'est tout chiffré sur ton poste donc normalement, la NSA n'a rien : https://spideroak.com

Pas de soucis. Dès que sed atteint ses limites, il faut penser à Perl qui en modifiant pas grand chose marche souvent (pas toujours).