Bonjour dlfp !
Je cherche à simplifier l'administration des ordinateurs de la maison et la sauvegarde de nos fichiers. Les enjeux sont les suivants:
- N'avoir qu'une machine à administrer,
- Que le /home de chaque utilisateur soit accessible depuis n'importe quel ordinateur de la maison,
- Que les sauvegardes soient automatisées.
- Que ça fonctionne aussi via le wifi.
Je pense donc mettre en place un serveur de fichiers qui aura pour tâche de:
- servir /home via NFS,
- archiver chaque jour les données de /home sur un second disque dur (vraisemblablement en utilisant btrfs et ses snapshots)
- Synchroniser la racine des clients avec celle du serveur pour n'avoir à administrer que le serveur.
Avant de me lancer dans l'aventure, j'ai quelques questions:
- Est-ce que cette architecture semble cohérente, efficace, utile, simple, ou bête et source d'ennuis?
- Pour synchroniser la racine des clients avec celle du serveur, j'ai pensé utiliser btrfs send/receive. Y-a-t-il mieux ou plus simple?
- Y-a-t-il un moyen simple de gérer les nuances de configurations de chaque machine (par exemple, le /etc/fstab du serveur ne sera pas le même que celui des clients, certains clients peuvent avoir besoin d'un module particulier du noyau, etc…)
- Enfin, je me pose la question bête de savoir où mettre le lecteur optique (dvd): les clients pourront-ils accéder à celui du serveur? Est-ce que le lecteur optique branché en permanence sur le serveur augmentera visiblement sa consommation électrique?
Bref, j'aimerais recevoir vos avis expérimentés. Merci d'avance !
# LTSP ?
Posté par ptit_poulet . Évalué à 4.
Connais-tu LTSP ? Je te conseille de regarder car avec un tel système tu auras un serveur à administrer ainsi qu'une (ou plusieurs) image pour tes clients. Et aucune installation à faire sur les clients. Sauf pour les clients en Wifi sur lesquels tu devras juste installer un utilitaire de boot afin de faire du boot PXE via le wifi.
[^] # Re: LTSP ?
Posté par Sygne (site web personnel) . Évalué à 4.
Oui, je connais ltsp de loin (j'ai visité son site), mais ne l'utiliserai vraisemblablement pas:
As tu un lien vers une documentation concernant le boot PXE via le wifi? J'imagine que ça utilise une mini distribution pour le boot, pour finir par faire un chroot vers la racine du système complet servie par NFS, non?
[^] # Re: LTSP ?
Posté par ptit_poulet . Évalué à 2.
[^] # Re: LTSP ?
Posté par Sygne (site web personnel) . Évalué à 3.
Oui mais bon…
Pourquoi bizarre? En quoi la présence de cet exécutable dans la hiérarchie du serveur l'empêche d'être un bon serveur? Il ne le lance pas, c'est tout. Il en va de même pour X. Non?
C'est ce que je voulais dire, effectivement.
merci du conseil.
Encore merci!
# de l'interet du lecteur DVD partagé
Posté par NeoX . Évalué à 4.
ta question me fait penser à la question du scanner reseau dans une entreprise.
scanner vers un fichier (image ou pdf) ca a du sens, tu es devant la machine, tu cliques, et ca envoie le fichier à l'utilisateur ou dans un dossier,
mais mettre le document dans le scanner, retourner devant le PC, pour ensuite lancer le logiciel de scan pour recuperer une partie du document.
quid si quelqu'un va sur le scanner pendant que tu retournes à ton bureau.
meme question pour un lecteur de CD/DVD en reseau, il se passe quoi si tu met le disque dans le lecteur dans la cave (c'est un serveur), que tu vas dans ton bureau pour lancer la lecture du DVD, et pendant ce temps ta fille rentre du college et regarderait bien le dernier DVD que les copines lui ont preté…
perso j'en vois plus trop l'interet,
à la limite tu as un lecteur DVD USB qui tourne d'une machine à l'autre.
sinon comme le collegue plus haut, LTSP parait une bonne solution de centralisation.
[^] # Re: de l'interet du lecteur DVD partagé
Posté par Sygne (site web personnel) . Évalué à 2.
Mon hésitation est donc levée, j'opte pour le lecteur dvd usb.
Merci!
[^] # Re: de l'interet du lecteur DVD partagé
Posté par Jehan (site web personnel, Mastodon) . Évalué à 4.
Bon ça dépend du nombre de personnes pour un scanner. Alors certes un scanner pour 500 personnes, ça va vite poser problème. Mais un scanner pour 10, même 30 personnes, c'est franchement suffisant. Pour la fois sur 100 où y a un problème (quelqu'un qui veut utiliser le scanner au moment où tu en as besoin), ça reste un deal raisonnable. Bon à part peut-être si c'est une entreprise où plein de gens ont besoin du scanner tout le temps… Au final tout dépend du cas par cas.
Donc dans une utilisation familiale comme là, même si c'est peut-être une grand famille, on va quand même pas acheter un scanner par membre!
Pour le lecteur USB, je suis probablement plus d'accord, mais surtout car c'est petit et léger. Donc c'est plus pratique de le trimballer en USB. Mais notre scanner A3, je me vois certainement pas l'utiliser en USB, se faire chier avec des cables, et le trimballer sur les divers ordis! Il est très bien en réseau!
Disons que je suis pas d'accord avec la comparaison quoi. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: de l'interet du lecteur DVD partagé
Posté par snurpsss . Évalué à 1.
Je plussois l'idée du scanner partagé pour une utilisation familialle (c'est ce que je fais): une petite page web permettant de piloter le scan a distance et le tour est joué. Ca permet d'avoir un historique des documents scannés. Dans mon cas j'utilise une vieille imprimante / scanner multifonction.
Pour le lecteur de cd/Dvd, je serais aussi de l'avis de le partagé: les PC fixes se font de plus en plus rare, et les laptop étant de plus en plus légé, on a de moins en moins l'utilité de ce support.
[^] # Re: de l'interet du lecteur DVD partagé
Posté par Jehan (site web personnel, Mastodon) . Évalué à 2.
Au sujet du scanner, un petit ajout: le seul cas chiant pourrait être si on veut scanner plusieurs pages. Faire des AR serait alors chiant si c'est une autre pièce par exemple. Mais y a plusieurs solutions:
Oui en fait, c'est vrai que même le lecteur DVD, c'est pas mal de partager en fixe sur un serveur (c'est possible?). Ça lui donne une place fixe et évite de le chercher des heures si un membre de la famille/l'entreprise l'utilise. En plus le lecteur portable qui se balade entre tous les membres d'une famille, c'est un coup à le faire tomber et le péter.
Oui j'en ai plus sur mon portable. Et je crois que ça m'ait arrivé qu'une seule fois dans l'année passée d'en avoir eu besoin (on m'a prêté un DVD et j'ai pas pu le lire).
D'ailleurs c'est possible de partager un lecteur DVD en réseau? Si quelqu'un a des infos là-dessus, je suis preneur. Un jour peut-être si l'utilité m'en venait…
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: de l'interet du lecteur DVD partagé
Posté par _kaos_ . Évalué à 1. Dernière modification le 28 février 2016 à 11:38.
snip Hors sujet
Matricule 23415
# Qu'entends-tu par ...
Posté par totof2000 . Évalué à 3. Dernière modification le 24 février 2016 à 20:26.
"Synchroniser la racine des clients avec celle du serveur pour n'avoir à administrer que le serveur" ?
Tu comptes faire ue sorte de rsunc de / du serveur vers les clients ?
Ca me parait pas génial …. A la imite un truc du style FS monté via le réseau, pourquoi pas … mais il te faut de la bande passante.
Sinon, un truc qui me vient à l'esprit (mais pas testé ..) : une arborescence sur ton indépendante de l'arborescence / de ton serveur, que tu administres via chroot par exemple, et que tu dépoie vers les clients. Après, reste à voir le meilleur moyen de synchroniser les clients avec le serveur : un mécanisme du genre test de la présence d'une nouvelle version de fichiers sur l'arborescence chrootée au boot, et synchronisation avant le démarrage (ou à l'extinction, ou même les deux)
[^] # Re: Qu'entends-tu par ...
Posté par Sygne (site web personnel) . Évalué à 2. Dernière modification le 24 février 2016 à 22:01.
Manifestement, la question de l'arborescence de la racine est un problème soulevé par plusieurs commentaires. Je vais donc préciser un peu:
Ceci étant dit, si vraiment le diskless shared root cluster est la solution pertinente, je vais m'orienter vers ça…
[^] # Re: Qu'entends-tu par ...
Posté par NeoX . Évalué à 3.
LTSP te permet de faire du 'FAT client'
tu bootes sur le reseau, tu charges une image systeme, elle s'execute en local au poste client avec les performances locales et non celles du serveur.
et c'est sur le serveur que tu manage cette image systeme
[^] # Re: Qu'entends-tu par ...
Posté par Sygne (site web personnel) . Évalué à 2.
Je ne sais pas comment ltsp sert cette image système, mais cela semble revenir au même qu'une racine servie par NFS: le client exécute les programmes localement, mais a besoin d'accéder à l'exécutable au préalable via le réseau.
Si c'est tout à fait fluide lorsque la connection se fait par wifi, il n'y a probablement pas de raison de persévérer dans mon idée de clients ayant chacun leur système de fichier à synchroniser avec le serveur.
[^] # Re: Qu'entends-tu par ...
Posté par ptit_poulet . Évalué à 1.
Tout dépend de ton réseau wifi. Quelles normes prend en charge ton routeur et tes clients ?
Concernant l'image client que tu vas créer sous LTSP, si tu utilises un environnement de bureau léger, l'image sera légère et vice versa ;)
# Systemimager
Posté par nono14 (site web personnel) . Évalué à 3.
Pour le clonage, on peut ajouter des exclusions.
NFS paraît bien si le wifi est rapide.
Système - Réseau - Sécurité Open Source
[^] # Re: Systemimager
Posté par Sygne (site web personnel) . Évalué à 2.
Merci pour SystemImager, que je ne connaissais pas.
Tu veux dire pour partager '/'? ou seulement pour '/home'? Quoi qu'il en soit, je crois que le seul moyen de savoir si mon wifi est rapide, c'est d'essayer…
[^] # Re: Systemimager
Posté par nono14 (site web personnel) . Évalué à 2.
Juste le home
Même pas en rêve en wifi pour le /
Système - Réseau - Sécurité Open Source
# nfs v3 vs nfs v4
Posté par moi1392 . Évalué à 1.
je n'ai jamais utilisé nfs v4, mais la façon dont nfs v3 fonctionne peut être limitante dans certaines configurations :
il utilise les id des utilisateurs sur les systèmes de fichier (car il a été conçu pour partager un disque sur des terminaux léger) ce qui veut dire qu'il est "préférable" d'avoir les même id d'utilisateurs sur toutes tes machines (ou de centraliser cela aussi)
Le second point qui peut être gênant, est qu'il font qu'il soit monté dans ton système de fichier. ça n'est pas grave pour des PC fixes toujours sur ton réseau, mais pour un portable, tu ne peux pas l'avoir en dur dans ton fstab, et les utilisateur "non-avancés" de ton domicile n'ont peut-être pas les connaissances pour faire le montage quand ils en on besoin (ça doit pouvoir se régler avec des scripts post-up de ton interface réseau, mais cela ajoute de la maintenance et des contraintes)
À priori (mais à vérifier donc, car jamais utilisé moi même) nfs v4 impose moins de contraintes sur ces points
[^] # Re: nfs v3 vs nfs v4
Posté par NeoX . Évalué à 2.
c'est à cela que servent les options _netdev dans fstab pour ne pas bloquer le demarrage de la machine si le lecteur n'est pas disponible
c'est à ca que sert l'option users dans fstab pour permettre à l'utilisateur de (de)monter un disque.
# owncloud
Posté par steph1978 . Évalué à 2.
intérêt (versus NFS):
- données accessibles même quand tu es déconnecté
- retrouve tes données sur plusieurs périphériques : ordinateur, tablette, mobile ; en sélectionnant ce qui est synchronisé
- gère les versions des documents en cas d'erreur ou d'effacement impromptu
- possibilité de partager des documents entre membres de la famille
- accès en mode web, qui dépanne
- possibilité d'extension des fonctionnalités : contacts, calendriers, édition en ligne, etc.
- possibilité d'héberger chez un hébergeur professionnel pour plus de fiabilité.
Les sauvegardes sont à mettre en place sur le serveur, si souhaité ; sachant que tu as déjà deux copies (sur le pc et sur le serveur) il ne reste plus qu'à en trouver une dernière pour être tranquille.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.