Construire un laboratoire LTSP dans un vserver... afin de mieux gérer! levinux

Réduire le netmask de lo sur la machine physique 127.0.0.1/8 à 127.0.0.1/16 <!> Créer un fichier (distributions de la famille debian... pour les familles redhat et quelques autres, le fichier existe déjà) /etc/modprobe.conf et y ajouter l'instruction suivante options dummy numdummies=5 (on met le chiffre qu'on veut... ici, on en crée 5) On lance le module dummy1 On déclare une interface dummy0 dans /etc/vservers/<vserver>interface/<id> puis on met dummy0 dans dev et 127.1.0.1/24 dans ip On relance le vserver On modifie le fichier /etc/hosts du vserver localhost 127.1.0.1 Référence: mirabellug

Ajouter dans /etc/ssh/sshd_config du vserver l'instruction suivante X11UseLocalHost no Lancer xhost + sur le terminal qui appelle le vserver On s'assure que /etc/hosts contient une ligne définissant notre vserver (son adresse ip et son nom!) Référence: LinuxÉdu-Québec

On ajoute dans le fichier /etc/ssh/sshd_config de chacune des machines (la machine physique et chacun des vservers) l'adresse IP sur laquelle le daemon sshd va écouter ListenAddress n.n.n.n On relance les sshd Référence deb.riseup.net

Pour DHCP, il faut ajouter les options CAP_NET_RAW et CAP_NET_BROADCAST dans /etc/vservers/<vserver>bcapabilities Pour nfs, il y a seulement nfs-user-server qui fonctionne; on oublie nfs-kernel-server... Mais nfs-user offre de bonnes performances pour LTSP Référence: on consultera la FAQ de J. Gélinas et celle de Sladen

Il faut ajouter l'option suivante dans /etc/vservers/<vserver>bcapabilities CAP_SYS_ADMIN afin de permettre au vserver de monter (smbmount) les fichiers partagés sur les terminaux.

La recette à suivre pour ldap sur breezy ou debian est ici. Il faut cependant ajouter un certain nombre de choses. Il manque une commande dans le tutoriel: après avoir créé le fichier Myuser.ldif, il faut ajouter Tout fonctionne à merveille quand les répertoires /home sont existants et qu'on ne passe pas par gdm (ou kdm ou xdm), en particulier sur LTSP; autrement, il faut quelques ajouts: Le syslog indique que gdm se plaint de deux répertoires manquant: on les créee Il faut également ajouter au fichier /etc/pam.d/common-session les deux lignes suivantes Enfin, si l'on souhaite offir un service de courrier, on doit ajouter dans /etc/skel le répertoire Maildir, contenant les répertoires cur new tmp

On oublie cp ou scp. On me dit que tar --preserve fonctionne.... je n'ai pas eu cette veine. Voici trois solutions qui fonctionnent vservser-copy [vserver] {hote:}[vservercopie] Cette commande ne fonctionne que si l'on crée un lien symbolique dans /etc/vservers/[vserver] vers [vserver].conf On ajuste ensuite dans /etc/vservers le répertoire [vsevercopie]; on copie (ici on peut utiliser cp, scp ou tar) /etc/vservers/[vserver] dans /etc/vservers/[vservercopie] et on ajuste les variables (interfaces/n n n... , name, uts/nodename et vdir) dump 0zf {path}[nomdufichier] [vserver] est également très bien. On récupère avec restore -fr {path}[nomdufichier] en se mettant à la racine / de la machine de récupération. On peut également copier à distance avec la commande suivante Référence : on consultera encore l'excellente FAQ de Sladen pour dump et rsync

On veut récupérer un vserver de terminaux; quels sont les fichiers à adapter au nouvel environnement ? (tous les chemins sont donnés à partir d'une distribution de type debian) pour la config du vserver (si la configuration du réseau est différente...) /etc/vserver/[vserver]/interfaces/[n]/ip (et peut-être dev) voir plus haut [un localhost] pour une interface "dummy", s'il y a lieu pour ldap /etc/ldap/ldap.conf /etc/ldap.secret /etc/pam_ldap.conf /etc/libnss-ldap.conf pour ssh On ajuste le "listen" dans /etc/ssh/sshd_config, à la fois sur le vserver et sur la machine host pour le dhcp (cela va de soi si le nouvel environnement propose un jeu d'adresses ip différent. Et ce, qu'il soit dans le vserver de terminaux ou à l'extérieur) /etc/dhcpd3/dhcpd.conf sur la machine (virtuelle ou physique) qui héberge le dhcp On adapte le jeu d'adresses ip à distribuer à son environnement et on s'assure que "option root-path" pointe vers l'adresse du serveur ltsp. pour ltsp (même remarque que pour le dhcp) /opt/ltsp/i386/lts.conf On donne les bonnes adresses pour le serveur ltsp et le xdm pour cups /etc/cups/cupsd.conf, si on est serveur /etc/client.conf, si on est client REMARQUE : on ne peut lancer cups à la fois sur la machine hôte et sur un vserver... à moins de trouver un "wrapper" qui fonctionne... je n'ai pas encore eu cette chance... pour gdm On s'assure que le nombre de connexions simultanées est adapté à son nouvel environnement pour /tmp On s'assure que l'espace est suffisant. Voir la rubrique nfs dans un vserver et modifier le /tmp ci-dessous Si on change de nom... Les fichiers /etc/vservers/[nouveaunom] ../name, ../uts/nodenane, le lien symbolique ../vdir à ajuster avec le nouveau nom dans [path_des_vservers]/vservers/[nouveaunom]

On aimerait pouvoir gérer l'impression directement dans un vserver et on aimerait également graver des cd depuis le vserver. On doit pourvoir définir les dev manquant: Ajouter CAP_MKNOD dans le fichier /etc/vservers/<vserver>bcapabilities Créer les dev nécessaires (cdrom, graveur CD et imprimante parallèle, par exemples) Changer les groupes S'assurer que les utilisateurs à qui l'on donne des privilèges sur l'utilisation des périphériques (user1, user2, etc. et cupsys) aient accès aux ressources dans le fichier /etc/group. Par exemple, l'entrée cdrom devrait ressembler à cela On pourrait également ajouter scanner et autres périphériques....

* Il m'a fallu pas mal de temps avant de comprendre qu'il ne FAUT PAS utiliser les options listen dans le fichier de config. Voici une configuration de base (très minimale) qui fonctionne parfaitement Order Deny,Allow Deny From All Allow From @LOCAL Allow From 192.168.0.0/16 AuthType Basic AuthClass System Order Deny,Allow Deny From All Allow From 192.168.0.0/24 # Or # Allow From @LOCAL ]]>Cette configuration permet également à des clients externes au vserver (dans le même sous-reseau) d'utiliser les ressources d'impression. On configure le script client.conf en conséquence Référence : j'ai trouvé la solution ici

Ouf! Cette opération-là m'a donné beaucoup de sueurs froides... Voici le scénario Une machine host (anaconda) sur laquelle roule un vserver de terminaux (vs01) et une machine de type nas (marmotte) sur laquelle se trouve les home de même qu'un serveur nfs (pas de vservers). On monte facilement marmotte/home sur anaconda/home; on peut également faire un "mount --bind" anaconda/home ...vs01/home Si vs01 n'était pas contraint d'utiliser à son tour le portmap et nfs, ça roulerait sans problemes (c'est d'ailleurs le cas avec /equinux/vs02 qui roule apache, mysql, postfix, imap, etc. Mais voilà : vs01 doit lancer portmap et nfs-user-server pour faire fonctionner les terminaux; il ne peut y avoir à la fois un portmap sur anaconda et sur anaconda/vs01. Que faire ? La réponse paraît simple : ne pas monter marmotte/home sur anaconda/home, mais directement dans ..vs01/home (et faire un mount --bind depuis ..vs01/home vers anaconda/home, si nécessaire). Ça ne monte pas sans options... (ou plutôt, ça monte, mais c'est hyper-hyper lent et pas utilisable avec les terminaux.!) Après avoir fouillé le web, j'ai enfin trouvé une solution: on monte avec les options hard,intr,nolock. On peut même mettre le montage dans /etc/vservers/vs01/fstab. Voici ce que ça donne. Référence: j'ai trouvé la solution ici On remarquera que le /tmp est maintenant à 100 megs... Par défaut, il était seulement à 16... pas suffisant pour 25 terminaux. J'ai présumé (ça reste à vérifier) qu'il fallait compter de 3 à 4 megs par terminal, quand on utilise kde et openoffice. testtesttest1 Voici une note de bas de page