Sytoka Modon a écrit 4544 commentaires

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).

Il faut utiliser la fonctionnalité quotemeta de Perl, \Q dans une regex ou fonction quotemeta(). Il faut aussi mettre des guillemets et non des apostrophes. Exemple

echo $string1 | perl -pe "s/\Q$string1/$string2/g"


A 45km/h, on n'est plus compatible avec les pistes cyclables en ville, même si ce sont des pistes dédiées. Il y a trop de cycliste dessus et le différentiel de vitesse est trop important. On est donc sur des engins qui utilisent les routes.

Tiens, je me suis amusé. Je travaille sur deux sites

Site I :

• 3.44 km vélo
• 5.54 km voiture

Site II :

• 8.80 km vélo
• 8.68 km voiture

Dans tous les cas, je vais (presque toujours) plus vite en vélo et pourtant, ce n'est pas plat… Une des raisons sont les bouchons et la saturation automobile d'un coté et des pistes correctes et dédiées en partie coté vélo.

A mon sens, une des solution est de moins investir sur la route et de mettre un paquet sur les autoroutes cyclables. D'abord cela fait du bien et le nombre de fois où on fait le trajet sous la pluie n'est pas si grand que cela. Ensuite, faire du vélo dans les odeurs des bagnoles, c'est pas facile et je ne suis pas sur que cela soit bon pour sa santé. Enfin, cela change complètement la ville, voir la campagne (génial les pistes en campagne).

J'ai des amis qui font la même chose en vélo électrique, on retrouve le fait d'être en plein air le matin et le soir, de plus le rapport poids puissance est bien plus correct que la voiture. C'est financièrement raisonnable et le vélo électrique ne prends pas trop de place. Bref, on aurait tout à gagner à développer encore bien plus le vélo.

surtout avec un commentaire aussi peu travaillé, il était assez baclé et fait à la va vite.

…

On ne dit pas que Mac est un BSD, donc pareil pour Android qui n'est pas un Linux.
Android, c'est un ecosysteme maitrisé par une boite, qui a son "repo" en Java. Est-ce vraiment "Linux"?

C'est pas un Linux, est-ce vraiment un Linux… Il y en a un autre qui est fatigué ;-)

Android est un Linux, je ne vois même pas pourquoi on se pose la question. C'est le noyau Linux qui est au cœur et ce noyau est GPL. Certes le noyau est patché mais toutes les distributions patchent aussi.

Pour MacOS, c'est un dérivé BSD mais il tourne déjà sur micro-noyau ce que ne font pas les autres et de par la licence BSD, Apple a tous les pouvoirs pour livrer un OS (Darwin) qui a des bouts non public. Ceci dis, la base de Darwin est clairement un BSD.

Le soucis avec MacOS et avec Android est qu'il ne font pas tourner X11. Une fenêtre native Mac n'est pas visible depuis un GNU/Linux et idem avec Android. Ca casse pas mal l'idée UNIX (même si X11 est plus récent que UNIX). Bref, un système non X11 n'est pas tout à fait dans la grande famille mais est un cousin ;-)

Rien à voir pour moi. Avec Wine, tu as et fait tourner un binaire PE32 (Windows) alors qu'avec Cygwin, tu as aussi un binaire PE32 et non ELF !