Bonjour, je mets actuellement en place des postes sans disque dur, bootant sur PXE. Leur système d'exploitation, chargé en mémoire vive via NFS (en read only), fonctionne très bien.
Hélas, lorsque j'essaye d'ouvrir une session avec le serveur X, le système refuse puisque le /home est en read only, et que gnome doit écrire dedans.
Je souhaiterais savoir s'il était possible de monter au démarrage dans la fstab, et en mémoire vive, un répertoire /home/utlisateur , ou gnome pourrait écrire à sa guise.
j'ai bien essayé "none /home/utilisateur tmpfs defaults 0 0", mais vraisemblablement cela ne marche pas.
Des idées ? Merci !
Forum Linux.debian/ubuntu Probleme PC diskless
3
mai
2007
# oui
Posté par NeoX . Évalué à 2.
il suffit d'exporter /home en RW
pour le /tmp il doit etre possible de faire pareil.
sur le client, il suffit d'importer aux bons endroits.
# Deux petits doutes...
Posté par Steve Azriel . Évalué à 1.
Voilà le 1er doute: ne faut-il pas que tu fixes les droits d'accès (chown user:group + chmod 0700) au répertoire '/home/utilisateur' pour que ce dernier puisse y écrire.
Voilà le 2nd doute: En supposant que /home/utilisateur n'existe pas sur le serveur de fichier, si /home est en Read-Only, est-ce qu'il n'y a pas un problème lors du montage du /home/utilisateur de type TMPFS ?!?
Si tel est le cas, je te conseillerais bien de créer le répertoire /chemin_dexport/home/utilisateur sur le serveur d'exports (NFS ?) si possible avec les bons droits d'accès et de vérifier qu'après le montage côté client, tu ais bien conservé les bons droits (au besoin, les réappliquer).
Bon courage !
Cdlt,
PS: Je préfère nettement la solution de 'John Doe' (export RW du /home, /tmp). C'est simple, et ça fonctionne ^__^ => +1
[^] # Re: Deux petits doutes...
Posté par Ido_ . Évalué à 1.
La solution de John Doe me plait, mais marche-t-elle lorsque 10 clients vont écrire en même temps sur le /home/utilisateur du serveur ?
Si oui, aucun problème, je me rabats la dessus !
[^] # Re: Deux petits doutes...
Posté par Steve Azriel . Évalué à 2.
Tout d'abord, il faut préciser que NFS fournit un certain nombre de services pour l'accès à distance au fichiers.
=> Il ne faut pas oublier que ce sont les applications qui doivent savoir fonctionner avec NFS (verrous & co).
Concernant ta demande, je ne peux que te proposer d'expérimenter et surtout de monitorer les indicateurs sur ton serveur NFS (cpu, ram, load average, io, interfaces réseaux, ...).
Voici quelques points d'attention:
1) Les accès mutuels à une même ressource (un même fichier puisque sous Un*x tout est fichier :P) depuis plusieurs utilisateurs/postes différents.
=> Valider que les applications sont NFS-Friendly (par exemple, l'éditeur VI, ...)
2) La "tendance" ie le comportement des postes vis-à-vis du serveur NFS: horaire de travail 9h-18h [accès très importants au début et à la fin de la journée !], type d'accès [compilation de source, bureautique, ...]
=> Cela permet de "tuner" le serveur et les clients :-)
Bon courage !
Cdlt,
PS: Il y a de nombreux pointeurs sur le net pour s'inspirer de leur expériences:
¤ [http://www.ltsp.org/] Le Projet LTSP qui me parait le plus "frais"
¤ [http://tldp.org/HOWTO/Diskless-root-NFS-HOWTO.html] Root over nfs clients & server HOWTO
¤ [http://tldp.org/HOWTO/Diskless-root-NFS-other-HOWTO.html] Root over NFS - Another Approach
PS2: Ah oui, truc vraiment sioux: compresser les binaires avec un outil type gzexe. Sur des clients ayant pas mal de mémoire, cela permet de réduire (plus ou moins) le trafic réseaux avec un petit effet sur le serveur NFS (notamment le cache mémoire des fichiers qui sont compressés :D)
[^] # Re: Deux petits doutes...
Posté par Ido_ . Évalué à 1.
La solution de John Doe me plait, mais marche-t-elle lorsque 10 clients vont écrire en même temps sur le /home/utilisateur du serveur ?
Si oui, aucun problème, je me rabats la dessus !
# mettre /home dans un ramdisk
Posté par gilles renault (site web personnel, Mastodon) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.