Oh je viens de comprendre !... Je pensais initialement à un montage de ce type:
//server/homes /home cifs options
Parce que //server/homes, malgré le nom unique, renvoie le homes de toto si toto est identifié, ou celui de tata si tata est identifiée. Le problème dans ce cas c’est évidemment qu’une seul utilisateur peut monter home à la fois ou bien ça écrase les autres.
Mais en fait tu disais de monter statiquement le parent de homes, sauf que le parent de homes n’est pas partagé sur le réseau homes est un partage dynamique qui te montre ce qui correspond à ton utilisateur, accessoirement il est aussi visible sous ton nom d’utilisateur. Donc dans mon cas perso, le serveur samba ne partage pas //server/home/illwieckz mais //server/illwieckz. Alors il serait possible de monter tous les utilisateurs, mais ça veut dire tous les lister etc. ce que ne fait pas Windows. Et il me semble que smbnetfs ne serait d’aucun secours lui non-plus puisque justement ce partage est unique à l’utilisateur, il n’y a pas un partage par utilisateur.
Cela dit ça ne doit pas être coûteux de partager le parent du dossier utilisateur (traditionnellement /home) sous linux. Cela dit je me demande comment smbnetfs s’en sort avec l’option de samba qui cache à l’utilisateur identifié les fichers et dossiers qu’il ne peut pas lire, puisque si j’ai bien compris l’intérêt de smbnetfs est de tout montrer côté client, et une fois que tout est là, seuls ceux qui ont accès parcourent l’arborescence. Hors avec ladite option de Samba, c’est le serveur qui cache des choses de l’arborescence au client... À essayer mais pour le moment j’ai du mal à imaginer comment ça pourrait marcher...
Vraiment, le meilleur serait que le client crée un dossier nu à l’utilisateur et que gvfs monte tout dedans avant de lancer la session gnome (et en s’assurant que le mot de passe est transmis aux composants qui en ont besoin comme seahorse).
Mais là encore, je ne sais pas comment reproduire le drive de Windows, où chaque utilisateur a une racine avec le même nom, donc un raccourci ou un lien symbolique relatif à ce drive aurait exactement le même chemin quelque soit l’utilisateur. Bon ça c’est pas très important et de toute manière c’est une fonctionnalité qui ne fonctionne qu’en domaine donc aucun logiciel le requière.
Bref, il serait cool d’avoir un composant qui s’insérerait entre le gestionnaire de connexion et le bureau, et qui transmette les mots de passe (à cause du trousseau de clé seahorse etc.) :
et ce quelque chose, en plus de recevoir l’identifiant et le mot de passe pour le transférer à gnome pour les composants qui en ont besoin (seahorse), utiliserait l’identifiant et le mot de passe pour, entre autre :
mkdir /home/$user
mount //nas/$user /home/$user
sh //dc/netlogon/logon.sh
Cependant je découvre un souci : le profile utilisateur dans l’active directory a une entrée pour le nom du script (sans le serveur qui est toujours le dc), ce qui signifie que ce script est le même pour windows et linux... Typiquement le champ contient par exemple logon.cmd et le client va chercher //dc/netlogon/logon.cmd. Hum, peut-être qu’on pourrait ajouter un champ optionnel pour le "script pas-windows".
Le script est très utile pour monter d’autre partages (typiquement les dossiers partagés pour les groupes de travaux) ou pour configurer certaines options de session (avec des clés de registre sous windows ou avec des requêtes dconf sous linux par exemple).
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: automatisation de la session utilisateur
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Intégration d'un poste GNU/Linux dans un domaine Windows. Évalué à 2.
Oh je viens de comprendre !... Je pensais initialement à un montage de ce type:
//server/homes /home cifs optionsParce que
//server/homes, malgré le nom unique, renvoie lehomesde toto si toto est identifié, ou celui de tata si tata est identifiée. Le problème dans ce cas c’est évidemment qu’une seul utilisateur peut monterhomeà la fois ou bien ça écrase les autres.Mais en fait tu disais de monter statiquement le parent de
homes, sauf que le parent dehomesn’est pas partagé sur le réseauhomesest un partage dynamique qui te montre ce qui correspond à ton utilisateur, accessoirement il est aussi visible sous ton nom d’utilisateur. Donc dans mon cas perso, le serveur samba ne partage pas//server/home/illwieckzmais//server/illwieckz. Alors il serait possible de monter tous les utilisateurs, mais ça veut dire tous les lister etc. ce que ne fait pas Windows. Et il me semble que smbnetfs ne serait d’aucun secours lui non-plus puisque justement ce partage est unique à l’utilisateur, il n’y a pas un partage par utilisateur.Cela dit ça ne doit pas être coûteux de partager le parent du dossier utilisateur (traditionnellement
/home) sous linux. Cela dit je me demande comment smbnetfs s’en sort avec l’option de samba qui cache à l’utilisateur identifié les fichers et dossiers qu’il ne peut pas lire, puisque si j’ai bien compris l’intérêt de smbnetfs est de tout montrer côté client, et une fois que tout est là, seuls ceux qui ont accès parcourent l’arborescence. Hors avec ladite option de Samba, c’est le serveur qui cache des choses de l’arborescence au client... À essayer mais pour le moment j’ai du mal à imaginer comment ça pourrait marcher...Vraiment, le meilleur serait que le client crée un dossier nu à l’utilisateur et que gvfs monte tout dedans avant de lancer la session gnome (et en s’assurant que le mot de passe est transmis aux composants qui en ont besoin comme seahorse).
Mais là encore, je ne sais pas comment reproduire le drive de Windows, où chaque utilisateur a une racine avec le même nom, donc un raccourci ou un lien symbolique relatif à ce drive aurait exactement le même chemin quelque soit l’utilisateur. Bon ça c’est pas très important et de toute manière c’est une fonctionnalité qui ne fonctionne qu’en domaine donc aucun logiciel le requière.
Bref, il serait cool d’avoir un composant qui s’insérerait entre le gestionnaire de connexion et le bureau, et qui transmette les mots de passe (à cause du trousseau de clé seahorse etc.) :
et ce
quelque chose, en plus de recevoir l’identifiant et le mot de passe pour le transférer à gnome pour les composants qui en ont besoin (seahorse), utiliserait l’identifiant et le mot de passe pour, entre autre :Cependant je découvre un souci : le profile utilisateur dans l’active directory a une entrée pour le nom du script (sans le serveur qui est toujours le dc), ce qui signifie que ce script est le même pour windows et linux... Typiquement le champ contient par exemple
logon.cmdet le client va chercher//dc/netlogon/logon.cmd. Hum, peut-être qu’on pourrait ajouter un champ optionnel pour le "script pas-windows".Le script est très utile pour monter d’autre partages (typiquement les dossiers partagés pour les groupes de travaux) ou pour configurer certaines options de session (avec des clés de registre sous windows ou avec des requêtes dconf sous linux par exemple).
ce commentaire est sous licence cc by 4 et précédentes