gaaaaaAab a écrit 1431 commentaires

tu n'es pas obligé de piper tes sed dans des sed. Tu peux traiter des cibles différentes avec un seule invocation de sed. Exemple:

$ echo '1234\n5678' | sed -e '/1/{s/1/2/}
> /5/{s/5/6/}'
2234\n6678

Mais il faut des retours à la ligne pour séparer les différentes parties du script. Du coup, je te conseille de regrouper tous tes traitements sed dans fichier de script sed, que tu peux invoquer avec l'option -f de sed.

il est en vente chez gog. Je suis assez certain que la version windows qu'ils distribuent tourne sous un windows récent. Si je me souviens bien, ils le font tourner dans un dosbox. Du coup, je crois que j'ai réussi à le faire tourner avec dosbox sous Linux, mais il fallait que je modifie la résolution à la main (ou que je lance un second serveur X). Je ne souviens plus trop, c'était il y a un bon paquet de mois.

j'ai l'impression que dans ce fil, il y a confusion entre racisme et discrimination.

dans le contexte américain, le slogan "all lives matter" est une réponse à "black lives matter". Ça fait semblant de croire que "black lives matter" veut dire "only black lives matter" et que, les noirs n'ayant pas la vie plus dur que le reste de la population, il n'y a pas de raisons de les singulariser. Sauf que quand on regarde les statistiques, c'est très faux, surtout au regards des bavures policières. Alors évidemment, quand tu demandes aux gens, et qu'ils ne sont pas noirs, ils sont tous d'accord pour dire que toutes les vies comptes, et que dire que les noirs comptent, ça fait un peu communautaire. Mais au final, c'est encore une façon d'oppresser les noirs en niant la réalité du racisme structurel de la société américaine (je dis américaine parce que c'est le contexte, mais je crois qu'on peut élargir à un bon nombre de société européenne).

un petit bout de full frontal (en anglais). C'est une émission politiquement engagée, mais les micro trottoirs avec les participants à une convention américaine illustrent bien ça.

apparemment, il vaut mieux s'abstenir de tenter Overwatch avec Wine pour l'instant: https://tech.slashdot.org/story/18/09/14/2055209/some-linux-gamers-using-winedxvk-to-play-blizzards-overwatch-banned

l'article précise que ce n'est pas un choix de Blizzard, mais leur système anti-triche qui fait du zèle.

l’esclavage n’existe plus là bas

ça s'appelle système carcéral maintenant …

ou il y a peut-être une solution à base d'ACL, mais je ne m'en suis jamais servi. Je ne sais pas bien ce que ça peut faire. à creuser

je pense que c'est le code de zone minder. En tout cas, j'ai récupéré le code source de la branche master de leur version libre. Dans src/zm_event.cpp, il y a plusieurs :

    if ( mkdir(path, 0755) ) {

Donc, à moins que je n'ai pas localisé le bon endroit dans le code source, ce n'est pas un paramétrage de l'utilisateur, c'est le code qui force directement ces permissions.

Plusieurs options possibles :
- faire une remontée de bug et espérer que le dév en tiennent compte assez vite
- proposer un patch (mais ça nécessite probablement de discuter avec eux pour voir comment ils veulent le gérer. Perso, je leur suggérerais de laisser le umask à la discrétion de l'utilisateur en utilisant 0777, ou de le mettre en paramètre de l'appli)
- recompiler une version à toi locale avec un patch
- utiliser des trucs genre inotify pour aller changer les permissions à la volée (ce qui devraient bien marcher tant qu'il n'y a pas trop de trafic mais qui, dans l'absolu, n'est pas 100% fiable)
- avoir un seul utilisateur plutôt que trois
- … si quelqu'un a une bonne idée, c'est le moment ! :)

hmmm … tu parlais là d'un souci potentiel avec fuse. On en est peut-être arrivé là. À tout hasard, est-ce que les gid pour le groupe www-data sont les même sur toutes les machines ?

Par rapport à ton test là, qu'est-ce que ça donne si tu fais:

sudo -u www-data -c "umask 0007; touch /media/storage_SSHFS/from_sshfs_by_www-data_user.test"

non ! je disais juste qu'à partir du moment ou umask est de la configuration, le terme "forçage" est discutable :)

Normalement, des umask bien réglés partout, ça devrait fonctionner.

Côté serveur, le bon umask fait que tes droits ne seront pas tronqués lors du transfert par ssh (dans ton montage sshfs).
Et côté clients, l'umask s'applique lors de la création des fichiers pour éventuellement retirer certaines permissions des permissions par défaut du système pour les fichiers et répertoires.

Là, c'est perturbant parce qu'on utilise umask côté serveur dans un rôle étendu par rapport à son rôle initial. Au départ, umask servait juste à définir les permissions par défaut pour un utilisateur en appliquant un XOR entre les permissions par défaut du système et le umask de l'utilisateur. (Les permissions par défaut du système étant rwxxrwxrwx pour les répertoires, et rw.rw.rw. pour les fichiers)

Ca avance grâce a toi, merci :)

cool :)

Elle semble donc falloir aussi forcer le umask de www-data sur le client (j'ai déjà tenté vainement sur le serveur).

oui, mais je n'appellerais pas ça du forçage, c'est modifier les permissions par défaut pour les nouveaux fichiers. Il y a toujours un umask.

C'est fort contre-intuitif.

c'est parce que tu continues de penser à umask comme un équivalent à chmod, alors que ce n'est pas ça. Tu as du voir sur le net que le système applique un XOR entre les permissions du fichier et l'umask. L'application de umask ne peut aboutir, au maximum, qu'à un retrait de permissions, jamais à un ajout. C'est un masque (il peut masquer certaines permissions).

Quand tu changes l'umask en 0002 (resp. 0007), tu dis simplement que tu acceptes les droits rwxrwxr.x (resp. rwxrwx…), pas que tu les imposes. Donc si ton fichier n'a pas le droit gw quand il est créé, aucune configuration de umask ne va jamais le rajouter.

ok. Si je comprends bien ce que je vois, sshfs transfert correctement les permissions à partir de ClusterOne ver le serveur. Pour les fichiers créés sur la partition sshfs de ClusterOne, les fichiers sont listés avec les droits 770, mais c'est peut-être trompeur.

J'ai l'impression que ton utilisateur local ne crée pas les fichiers avec les bons droits sur ClusterOne.

Si tu as assez d'espace disque sur ClusterOne, tu peux tenter démonter la partition sshfs et vérifier avec quels droits ton utilisateur créé les fichiers.

sur ClusterOne, d'après les droits sur from_sshfs.test créé dans /tmp, le umask de root sur ClusterOne ne donne pas le droit gw. Qu'est ce que ça donne si tu changes le umask de root avant de faire le touch sur la partition sshfs ?

j'ai peut-être répondu à côté. J'ai vu passer sftp, j'ai répondu sftp :)

Mais sur le fond, c'est la même question. Est-ce que tes fichiers sont bien créés avec le droit w pour le groupe, et sshfs, pour une raison encore à trouver, le zappe au moment du transfert, ou est-ce que sshfs n'y est pour rien ?

(c'est facile à tester. un fichier local avec les bons droits et une copie sur le montage en sshfs)

je viens de faire quelques tests avec sftp, et, en dehors du fait qu'il faut redémarrer le serveur ssh après la modif de la config, j'attire ton attention sur le fait que sftp ne rajoute pas le droit w sur le groupe. Il applique juste le umask. Donc si le droit w n'est pas présent pour le groupe sur le fichier avant le transfert par sftp, il n'y sera toujours pas après.

Plus globalement, vu que tu as trois sources potentielles de nouveaux fichiers dans tes répertoires, ça sera plus simple si tu découpes ton problème en trois questions distinctes, et que tu debug ta config en les prenant une par une.

je pensais plus aux langages qui produisent du code natif. Pour les langages interprétés ou ayant une VM, c'est plus beaucoup facile.

Je ne connaissais pas graalvm. Ça pourrait être intéressant. Dommage qu'Oracle ait ses sales pattes dedans …

quasiment tous les autres peuvent appeler une fonction C alors que l'inverse est très souvent faux.

ça, c'est juste de l'interface. On peut imaginer un monde dans lequel tous les langages comprennent et sont capables de fabriquer un truc compatible C, sans qu'il n'y ait une seule ligne de C nul part.

C a un écosystème énorme comparé à Go ou Rust.

oui, mais comme tu viens de le rappeler, (quasi) tous les langages sont capables d'appeler du C. Ils peuvent hériter (sous certaines conditions) d'une grande partie de l'écosystème du C.

Bref, vouloir prendre la place de C, c'est un doux rêve.

Je ne pense pas qu'un seul langage puisse venir remplacer le C sur tous ses domaines d'usage. Par contre, j'arrive à imaginer que le C soit remplacé au fil de l'eau par des langages spécialisés sur de nombreux domaines, et dans d'étranges éons, sur tous.

Ça se comporte comme les variables d'environnement (même si ça n'en est pas). Si tu modifies le umask dans un processus, tous les processus fils hériteront de cet umask, mais pas les autres processus.

Pour tes utilisateurs qui sont des serveurs web, ça vaut le coup de regarder dans la doc ce qui est préconisé pour la config de l'umask.

non, ce n'est pas la même chose. umask définit le masque de permission qui va être appliqué pour tous les nouveaux fichiers. Tant que tu ne crées pas de nouveaux fichiers, l'effet d'umask est nul. D'autre part, quand tu modifies ton umask, ça n'a aucune incidence sur les fichiers déjà créés. Je pense que pour toi, c'est intéressant de combiner les deux. umask pour que les nouveaux fichiers soient créés avec le droit en écriture pour le groupe, et chmod pour que les fichiers déjà existants obtiennent ce droit.

Soit-dit en passant, chmod 770, c'est un peu violent. Tu peux faire plus fin. C'est possible de ne rajouter que le droit en écriture pour le groupe sans toucher aux autres permissions (avec chmod g+w)

$ umask 
0022
$ touch fichier1
$ ls -l fichier1 
-rw-r--r-- 1 gab gab 0 Sep  8 22:39 fichier1
$ umask 0002
$ touch fichier2
$ ls -l fichier*
-rw-r--r-- 1 gab gab 0 Sep  8 22:39 fichier1
-rw-rw-r-- 1 gab gab 0 Sep  8 22:40 fichier2
$ chmod g+w fichier1 
$ ls -l fichier*
-rw-rw-r-- 1 gab gab 0 Sep  8 22:39 fichier1
-rw-rw-r-- 1 gab gab 0 Sep  8 22:40 fichier2

Note qu'après la modif du umask, les droits de fichier1 n'ont pas été modifié.

La configuration d'umask se fait souvent dans le .profile.

tu peux configurer le umask (masque de permission pour la création de fichiers)

$ umask
0022
$ touch tst_umask
$ umask 0002
$ touch tst_umask_1
$ ls -l tst_umask*
-rw-r--r-- 1 gab gab 0 Sep  8 20:01 tst_umask
-rw-rw-r-- 1 gab gab 0 Sep  8 20:01 tst_umask_1

ouais, faut que je remette à gnome et que j'apprenne LaTeX ! :D

Question annexe:

D'après ce que je vois sur le net, il y a des alternatives similaires sous Windows. Dans ta recommandation, qu'est-ce qui te fait préférer présenter WinSCP plutôt que sshfs ?

À partir du moment ou j'ai écris que je commence à faire partie des vieux grincheux, j'en prends également bonne note.

Quand j'ai fait ma formation Linux en 1999, mon formateur nous avait donné ce sens au mot Linux.

je ne dis pas que ce n'est pas un sens possible, simplement que le fait que ce soit le sens du nom Linux depuis les origines me paraît incorrect. En tout cas, entre un formateur Linux random de 1999 et wikipedia, je sais auquel j'accorde le plus de confiance.

NB Tu n'étais peut-être pas né en 1991 ?

c'est un peu hors sujet, mais si

Tu t'es spécialisé dans le tuning de vim ? ;+)

Dans l'exemple que j'ai donné, il y a 3 caractères qui sont du vim, le reste, c'est du shell. ':' pour le mode commande, c'est pas du tuning, c'est le b.a.-ba de vim. '%' sélection de tout le fichier (c'est l'équivalent de Ctrl-a, ne viens pas me dire que c'est une fonctionnalité avancée), ! permet d'invoquer le shell. Je veux bien considérer que '!' fait partie d'un usage un peu avancé de vim (mais c'est franchement pas du tuning). Quand tu dois apprendre que tu as des fonctionnalités en appuyant sur F4 ou sur F7 de ton éditeur, c'est la même chose, c'est de la connaissance de base des fonctionnalités du logiciel que tu utilises.

je colle ici mon .vimrc, je pense que les utilisateurs de vim te confirmeront que c'est super basique:

~$ cat ~/.vimrc 
syntax on
set background=dark
set tabstop=8
set hlsearch

je te laisse tuner ton mc ;-)