Forum Linux.général Samba (Troisième)...

Posté par  .
Étiquettes : aucune
0
17
nov.
2004
Comment faire pour faire fonctionner le tout, de manière harmonieuse ?
Voilà, suite à ce post http://linuxfr.org/forums/10/4958.html(...(...)) (honteusement abrégé par la faute de l'appel du ventre), j'ai commencé à réfléchir, et surtout à vouloir utiliser mon KDE comme les autres utilisent leur ... "tchut, tchut, pas de marque".
Par conséquent, j'ai voulu utiliser smbmount pour monter, dans un sous-répertoire de ma home directory mes partages samba, proposés par une machine du réseau judisieusement appelée samba !
Or donc, dans mon répertoire $HOME/.kde/AutoStart, j'ai créé un script shell qui me lance à tour de bras des
smbmount //samba/nomdushare $HOME/samba/nomdushare
Ca fonctionne plutôt bien, et je suis sûr que vous êtes contents de le savoir.
Ce qui fonctionne plutôt mal, c'est le démontage automatique de ces partages. Comment procéder ? Je voudrais qu'ils se démontent tout seul lorsque je quitte KDE, mais pour l'instant, pas moyen de trouver où coller les "smbumount". Quelqu'un aurait une idée ?
Par ailleurs, cette commande est un peu "con-con". En effet, contrairement à mount, qui attache n'importe quoi à l'arborescence et se casse, smbmount reste en arrière plan. La commande reste visible lors d'un "ps x" lancé depuis une console. C'est affreusement laid, mais ce n'est pas tout : si on kill ces process, pas de soucis, ils n'apparaissent plus, mais les répertoires sont toujours montés ! Trop fort. De même, si on ferme tout ces process avec des kill sauvages, mais qu'on fait dix fois le même appel à smbmount, le partage est monté 10 fois, ce qui signifie qu'il faut faire autant de smbumount qu'il y a eu de smbmount ! C'est trop pour moi !
Pour résumer, voici le fonctionnement que je souhaiterai avoir :
Je démarre KDE, mes unités réseau sont montées.
Je quitte KDE, elles sont démontées, et ce, de manière transparente.
Y'a un moyen ?

Deuxième cas de figure : notre parc est composé à l'heure actuelle d'à peu près 80 machines hétérogènes, fonctionnant sous windows 98 SE/2000 Pro/XP Pro. Ces machines sont sensées utiliser les partages réseaux définis par utilisateur sur notre contrôleur de domaine (samba). Comment faire pour automatiser l'attribution automatique d'une lettre de lecteur à un partage, et ce, de manière automatique ? Pour situer mon problème, voici ce qui a été opéré jusqu'ici :
Je me connecte sur une machine au serveur samba, sur mon compte user1. Une fois connecté, par le biais de l'explorateur, j'attribue les lecteur P: pour \\samba\personnel, S: pour \\samba\service, X: pour \\samba\public, etc.
Si je me déconnecte de ce poste et que je me connecte sous une autre identité, mettons user2, tous les lecteurs réseau ont disparu (ceci est vrai pour 2000, XP). Il faut que je les re-créés systématiquement à chaque nouvel utilisateur de la machine. C'est chiant. Peut-on automatiser ça, d'une quelconque façon ?
Par avance merci pour vos tuyeaux !

P.S. J'ai fait exactement le même post dans général.hors-sujet suite à une fausse manip', merci de ne pas trop m'en vouloir.... A la rigueur, si un modérateur passe par là et supprime le post en trop dans général.hors-sujet (l'autre, donc), je ne lui en voudrait pas !
  • # pour ton deuxieme cas de figure...

    Posté par  . Évalué à 3.

    tu peux créer tout simplement sur tes machines sous win un fichier *.BAT a placer dans le dossier DEMARRAGE de Windows pour tous les utilisateurs. Voici son chemin type sous win a noyau NT:

    C:\Documents and Settings\All Users\Menu Démarrer\Programmes\Démarrage

    Ce fichier comporterait la commande "net use"

    NET USE [driveletter:] \\ComputerName\ShareName

    en option "/persistent: yes" ou "no"

    Si tu veux plus d'infos sur la commande NET va ici :
    http://www.ss64.com/nt/net_share.html(...)
    • [^] # Re: pour ton deuxieme cas de figure...

      Posté par  (Mastodon) . Évalué à 1.

      Ce script peut même être diffusé par le serveur d'autentification (comme les PDC NT4)
      il est en général placé dans un share \\PDC\NETLOGON.
      Si tu utilise des utilisateur "samba" base tdb, tu peux attacher ce script à tes utilisateurs avec la commande pdbedit -u user -S script.
    • [^] # Re: pour ton deuxieme cas de figure...

      Posté par  . Évalué à 1.

      Oui, je pourrais...
      Mais cette solution ne me convient pas : je suis un [décideur pressé]/[administrateur feignant]/[fonctionnaire] (1) et j'ai pas trop envie de passer sur l'ensemble des micros du parc... Y'en a 80, c'est pas irréalisable, mais c'est non-maintenable...
      Par contre, coller ça dans un script lancé automatiquement depuis le répertoire netlogon du serveur samba, j'y avait déjà pensé.
      Seule ombre au tableau : le répertoire en question n'est pas le même selon la version de windows considérée, et la commande net ne s'utilise pas le la même manière sous 98 que sous 2000 que sous XP, pour autant que je sache (mais je n'ai pas la prétention de tout connaitre de ces systèmes, loin s'en faut). Ce qu'il faudrait, c'est détecter la version de windows utilisée, et "envoyer" le script approprié, mais ça, je ne sais pas faire.

      La finalité de tout ça est la suivante :
      Pour l'instant, seul le serveur est sous Linux. Il sert les adresses IP (dhcp) et les fichiers (samba). Il fait office de PDC, évidement.
      Les postes utilisateurs sont sous windows. Les plus vieux sont sous 98 SE, les plus récents sous XP Pro. Nous en avons aussi sous 2000 Pro.
      Ces utilisateurs travaillent donc sur le samba, ce qui est pratique pour les sauvegardes et pour partager des informations.
      Pour naviguer sur le waibe et pour la messagerie, nous avons déployé mozilla partout, mais le profile de chaque utilisateur est stocké sur le serveur.

      L'idéal pour nous et pour eux serait que lorsque nous leur remplaçons leur micro, suite à l'achat de nouveau matériels, à une panne (prêt d'un ordinateur de dépanage), ou lors de tests de Linux (cf mes autres posts), que ces utilisateurs retrouvent leur environnement de travail sans que nous ayons de gros efforts à fournir. Par feignantise, oui, faut pas se voiler la face, mais aussi pour leur plus grand confort : si il nous faut systématiquement plusieurs heures pour leur préter un PC de remplacement, nous n'y gagnons rien (ni eux, ni nous).

      Par conséquent, il faudrait que les partages réseau se montent automatiquement, que le profile mozilla soit reconnu systématiquement (pour ça, j'ai trouvé comment faire, grâce à linux et un peu de jugeote), et que les imprimantes se déplacent avec le profile. Pour les applis, il est normal qu'elles soient installées systématiquement par nos soins, car les besoins ne sont pas les mêmes selon les cas.

      Voilà une description un peu plus détaillée de la problématique.
      A noter au passage que tout ça, avec Linux, c'est un boulot de 5 min pour un admin (installer/configurer pam_smb et pam_mount, d'après ce que j'ai compris), après, ça roule (presque) tout seul.

      Pour le reste, je ne sais pas "programmer" les montages réseaux depuis le samba, ni faire suivre les imprimantes. A noter que ces dernières sont des imprimantes réseaux et sont installées directement sur les postes clients. Nous ne voyons aucun intérêt à faire passer ça par le samba.

      (1) rayer la mention inutile/débile/inintéressante/? (2)
      (2) Pas pire !
      • [^] # Re: pour ton deuxieme cas de figure...

        Posté par  (Mastodon) . Évalué à 3.

        Pour le test d'os, if "%OS%" == fait au moins la différence entre les NT et les autres (ça devrait suffire, enfin chez nous ça suffit).

        Pour que les utilisateurs gardent leur conf, en changeant de poste, là il faut des profils itinérants (ça doit se faire assez simplement en déclarant la variable home avec pbedit -h, -d et -p)
  • # Montage et démontages automatiques sous KDE

    Posté par  (Mastodon) . Évalué à 3.

    Va voir du coté de smb4k.
    Il sait monter des partages lorsqu'il se lance et les démonter en quittant.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.