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.
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 !
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)…
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 !
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é ;-)
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.
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 5. Dernière modification le 06 juin 2016 à 21:49.
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.
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 2.
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 ;-)
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 7.
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.
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 1.
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 ;-)
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 4.
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 ;-)
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 4.
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.
[^] # Re: Bug fermé chez tmux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 1.
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.
[^] # Re: systemd, le nouveau Multics
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 10.
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…
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 2.
Idée au pif (pas testé)
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 !echo screen | at now +1s
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 2.
Yep, mosh charge un peu trop (tmux surtout il me semble).
Redirection -> pouvoir glisser via mosh un retour graphique xpra par exemple ;-)
[^] # Re: systemd, le nouveau Multics
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 8.
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)…
[^] # Re: Depuis NEWS
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 2.
Elle est documentée partout. Arrêtons la mauvaise foi et essayons d'être optimiste ;-)
[^] # Re: Bug ferme chez tmux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 2.
Yep, mosh + tmux (byobu) marche d'enfer et la charge réseau est TRES TRES faible (on attend juste la redirection de port).
[^] # Re: Bug fermé chez tmux
Posté par Sytoka Modon (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 1.
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-
[^] # Re: Intérêt de ne pas faire la mise à jour ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Vague d’intérêt pour GNU/Linux vs Windows 10 « imposé » ?. Évalué à 4.
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 !
# SOS Bonheur
Posté par Sytoka Modon (site web personnel) . En réponse au journal La Suède abandonne les paiements en espèce — ne devrait-on pas s'en inquiéter?. Évalué à 10.
Je ne peux que conseiller cette super BD - https://fr.wikipedia.org/wiki/SOS_Bonheur
# Changement d'ordre
Posté par Sytoka Modon (site web personnel) . En réponse au message Migrer NIS vers LDAP sur un poste de travail sans fermer la session utilisateur. Évalué à 4.
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.
# Attention
Posté par Sytoka Modon (site web personnel) . En réponse au journal Vague d’intérêt pour GNU/Linux vs Windows 10 « imposé » ?. Évalué à 8.
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é ;-)
[^] # Re: [HS] Quel saut
Posté par Sytoka Modon (site web personnel) . En réponse au journal Pourquoi une petite société a intérêt à contribuer et produire du libre... mais pas que. Évalué à 10.
Tu passes trop de temps du DLFP ;-)
# Wayland
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche La nouvelle API graphique Vulkan. Évalué à -3.
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…
# spideroak
Posté par Sytoka Modon (site web personnel) . En réponse au journal Du stockage en ligne (encore). Évalué à 4.
C'est tout chiffré sur ton poste donc normalement, la NSA n'a rien : https://spideroak.com
[^] # Re: Perl
Posté par Sytoka Modon (site web personnel) . En réponse au message Problème avec les antislash et sed. Évalué à 3.
Pas de soucis. Dès que sed atteint ses limites, il faut penser à Perl qui en modifiant pas grand chose marche souvent (pas toujours).
# Perl
Posté par Sytoka Modon (site web personnel) . En réponse au message Problème avec les antislash et sed. Évalué à 5.
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"
[^] # Re: Il n'y a pas de solution ultime
Posté par Sytoka Modon (site web personnel) . En réponse au journal Tesla, pas un poisson d'avril. Évalué à 4.
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.
[^] # Re: Il n'y a pas de solution ultime
Posté par Sytoka Modon (site web personnel) . En réponse au journal Tesla, pas un poisson d'avril. Évalué à 10.
Tiens, je me suis amusé. Je travaille sur deux sites
Site I :
Site II :
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.