Forum Linux.debian/ubuntu lubuntu dans un AD windows 2016

Posté par  . Licence CC By‑SA.
Étiquettes :
6
13
sept.
2025

Bonjour,

Contexte : je ne suis pas du tout informaticien, mais prof de collège, bidouilleur certes mais essentiellement autodidacte (donc avec des lacunes probablement invraisemblables pour le public habituel de linuxfr) Je m'occupe du parc info du collège, mais une partie de la maintenance est prise en charge par la collectivité. J'ai donc une marge de manoeuvre un peu limitée mais je m'insère dans les brèches…

Je ne cherche pas, pour le moment, de solution précise (ça viendra) aux problèmes qui suivent mais plus des conseils généraux sur les orientations à prendre et, éventuellement, des piègesàk qui pourraient m'attendre.

J'ai une série de DELL 3060 destinés à la poubelle pour cause de migration W11. L'idée est donc de les passer sous GNU/linux pour continuer à les utiliser. Bel alignement de planètes : actuellement une MàJ foireuse de W10 en bloque un certain nombre, les collègues accepteront plus volontiers un linux qui marche plutôt que le windows habituel qui marche pas ;-)

Le contrôleur de domaine est un W2016 sur lequel je ne peux faire que peu de choses et je ne souhaite pas trop y toucher, pour que l'assistance continue à y intervenir si nécessaire.

Je suis arrivé à installer un lubuntu 24.04 LTS et à l'intégrer au domaine, je peux m'y logger avec un compte d'utilisateur de domaine, ça marche super bien.

Mais c'est UN poste et j'ai un lot d'une trentaine de machines à récupérer.

Il me reste deux trois choses (au moins) à faire avant de les mettre en "production" :
1 - arriver à monter les partages que l'on a sur les clients windows
2 - arriver à faire quelques réglages par défaut (configuration du bureau, du menu, etc) pour les futurs utilisateurs.

et pour la suite

3 - prévoir la maintenance, les mises à jours, des évolutions demandées par les collègues, etc.

Pour le point 1 je reconnais ne pas encore avoir lu la doc kivabien mais si quelqu'un connais un site tuto ou je ne sais quoi facile d'accès, je prends avec plaisir

Point 2 : si j'ai bien compris, je peux jouer sur le répertoire /set/skel mais comment éviter de refaire ça sur tous les postes ? peut-on centraliser ou automatiser ça facilement ?

Point 3 : y a-t-il une solution de « supervision » (je ne sais pas si le terme est correct) simple à prendre en main et à installer ?

Merci de vos conseils

  • # classique interopérabilité windows

    Posté par  (site web personnel) . Évalué à 7 (+5/-0). Dernière modification le 13 septembre 2025 à 14:38.

    pour le 1. la solution la plus pérenne est avec systemd

    https://doc.ubuntu-fr.org/tutoriel/monterpartagewindows#eme_methodesystemd en prenant en compte l'authent à ton AD.

    le 2. reste très manuel, tu peux scripter (apt update && apt install [liste_de_paquets]) mais il restera la config'.

    ton 3 : un GLPI te permettrait de gérer les demandes et liste des logiciels installés mais sans doute overkill pour 4-5 machines, pour une trentaine ça peut valoir le coup… éventuellement possibilité d'automatisation des déploiements (mais c'est quasi aussi rapide d'intervenir sur chaque poste si dans la même salle, ça peut gérer ton point 2 pour la post-install').

    les Dell 3060 viennent avec 8 Go de RAM et 2 emplacements, facile à booster à 16 Go pour faire un "petit" serveur (32 Go max, mais il te faudra 2 barrettes de 16 Go…)

    c'est plus pour une utilisation bureautique ? quels logiciels spécifiques ? firefox + ublock, un chromium à côté, libreoffice avec extension grammalecte, et c'est déjà bien.

    • [^] # Re: classique interopérabilité windows

      Posté par  . Évalué à 2 (+0/-0).

      Merci pour cette réponse !

      point 1 : je vais lire ça…

      point 2 : je pensais plutôt au fait que la configuration de base du bureau lxQt ne me satisfait pas tout à fait, qu'il faut rajouter quelques raccourcis sur le bureau pour tout le monde, le proxy pour FF, etc. Des réglages à faire à l'installation mais qui devront s'appliquer à tous.
      C'est pour ça que je parlais de /etc/skel (que je n'ai jamais utilisé sur mes ordis perso qui sont … mono-utilisateur ;-) )

      point 3 : pour traiter les demandes, GLPI sera excessif : c'est plus un mail de temps à autre pour ceux qui savent que j'ai une mémoire de piaf ou une discussion impromptue pour les autres.
      Ces postes vont probablement être répartis un peu partout, dans des salles occupées 30 h sur 40 et pas forcément libres en même temps que moi :-/ Le travail à distance ou automatique c'est bien pour ça aussi.

      Utilisation bureautique, firefox pour l'ENT moodle etc. rien de foufou même sir les DELL en questions n'ont que 4 Go, pas 8. Quelques uns sont vraiment HS et je ferais du cannibalisme, mais je ne peux pas tous les passer à 8Go

    • [^] # Re: classique interopérabilité windows

      Posté par  . Évalué à 2 (+0/-0).

      Autre question pour essayer d'y voir plus clair

      pour le 1. la solution la plus pérenne est avec systemd

      Est-ce que ces montages avec systemd peuvent se faire en fonction de l'utilisateur et de ses groupes ?

      Chaque utilisateur à un partage perso sur le serveur que je voudrais monter dans le /home/identifiant@nomdomaine créé à la connexion

      Il y a en plus un partage d'échange pour tous, un pour les seuls membres du groupe profs, un partage par classe

      C'est plutôt l'utilisation de la librairie libpam-mount qui semble utiliser des variables pour le nom ou les groupes de l'utilisateur, non ?

      • [^] # Re: classique interopérabilité windows

        Posté par  (site web personnel) . Évalué à 3 (+1/-0).

        Est-ce que ces montages avec systemd peuvent se faire en fonction de l'utilisateur et de ses groupes ?

        oui

        justement, tu as pam_systemd ;-)

        https://www.linux.org/docs/man8/pam_systemd.html

        que je voudrais monter dans le /home/identifiant@nomdomaine créé à la connexion

        ce sera /run/user/$USER mais c'est pareil.

        C'est plutôt l'utilisation de la librairie libpam-mount qui semble utiliser des variables pour le nom ou les groupes de l'utilisateur, non ?

        mouais, ça doit exister avec systemd aussi, à creuser (je n'ai pas directement trouvé de doc' :/)

        • [^] # Re: classique interopérabilité windows

          Posté par  . Évalué à 2 (+0/-0). Dernière modification le 16 septembre 2025 à 22:04.

          Des nouvelles (avant de poser une autre question d'ici quelques minutes)

          Je suis arrivé après bien des bidouillages et des erreurs à monter les partages avec des commandes du style

          mount -o user=toto, rw //SERVEUR/nomdupartage$ /mnt/pointdemontage

          Ouf, j'avance ! (pas vite ok)

          Je refais une entrée de forum pour la suite pour ne pas tout mélanger

  • # ssh et scripts

    Posté par  . Évalué à 4 (+2/-0).

    Pour ton besoin, un accès SSH et ca roule, tu peux scripter le déploiement (icones, etc…) et effectuer la maintenance à distance.

    • [^] # Re: ssh et scripts

      Posté par  . Évalué à 2 (+0/-0).

      Merci

      Je pensais à cette solution qui a l'avantage de la simplicité (de mise en œuvre, pas forcément d’utilisation, les scripts et moi ce n'est pas toujours ça)

      En posant la question j'imaginais plus un clicodrome mais je sais aussi que ce genre de truc vire assez vite à l'usine à gaz qui fait aussi le café.

      • [^] # Re: ssh et scripts

        Posté par  (site web personnel) . Évalué à 2 (+0/-0).

        En posant la question j'imaginais plus un clicodrome

        c'est ce que propose GLPI : un serveur pilotant le déploiement d'applis, chaque client remonte des infos au serveur et le serveur peut dialoguer avec chaque client pour déploiement centralisé (ça déploie des paquets, pour de la conf' c'est à creuser).

        mais je sais aussi que ce genre de truc vire assez vite à l'usine à gaz qui fait aussi le café.

        oui, bah ça… Dans notre fablab, je n'utilise pas le déploiement car j'ai un parc hétérogène (pas les mêmes distros, pas les mêmes paquets, pas les mêmes utilisations) et multi-sites gérés localement et je ne veux pas gérer les windows ; c'est — pour mon cas — principalement l'inventaire qui est intéressant (même si les rapports demanderaient à être adaptés).

        Pour ton cas, où il y a apparemment homogénéité et une 30aine de postes, ça peut te permettre de gérer de manière centralisée et d'avoir un suivi centralisé de l'état. Pas forcément besoin d'utiliser toutes les fonctionnalités non plus et ça ne fera pas le café à ta place.

  • # et le clonage ?

    Posté par  . Évalué à 2 (+1/-0).

    Une solution serait déjà d’effectuer tous les réglages adéquats sur la première installation, puis de cloner celle-ci sur tous les postes. (via un logiciel comme Clonezilla)

    Ensuite, il ne restera qu’à effectuer les réglages spécifiques à chaque machine. (comme modifier le nom d’hôte)

    • [^] # Re: et le clonage ?

      Posté par  . Évalué à 3 (+1/-0).

      Pourquoi pas, mais il faudrait que je me remette au clonage que j'ai laissé de côté depuis un bon moment alors que pour les postes windows, on a une solution de "masterisation"

  • # Rudder

    Posté par  . Évalué à 1 (+0/-0). Dernière modification le 29 septembre 2025 à 11:56.

    Bonjour, Rudder permet de déployer des configurations, d'installer des programmes et ce de manière graphique. Il est possible de faire des groupes (manuellement ou dynamiquement) pour déployer.

    La version communautaire suffit amplement et est très puissante :
    Rudder
    Çà fonctionne très bien : un agent est installé sur chaque machine et va vérifier les règles sur le serveur, c'est ensuite l'agent qui fait les modifications (installation de paquets, réglages SSH, DNS, scripts, fichiers, etc) et ce toutes les 5 minutes de manière très légère.

    Il faut juste faire attention au serveur qui doit être assez costaud et ne pas logguer tout sinon la DB peut être imposante, mis à part ça c'est très efficace, bien suivi et documenté et très actif comme projet.

Envoyer un commentaire

Suivre le flux des commentaires

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