Forum Linux.général Serveur de fichiers maison

Posté par (page perso) . Licence CC by-sa
Tags : aucun
6
24
fév.
2016

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 . É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 (page perso) . Évalué à 4.

      Oui, je connais ltsp de loin (j'ai visité son site), mais ne l'utiliserai vraisemblablement pas:

      • il n'est pas disponible dans ma distribution (arch),
      • je ne veux pas lancer les programmes sur le serveur, mais sur les clients (pas de ssh-x donc),
      • j'aimerais éviter le «mini chroot environment» qu'utilise ltsp, et synchroniser la racine des clients directement avec celle du serveur.
      • à la limite, je n'ai pas besoin du boot pxe: les clients ont leur disque dur et leur racine, synchronisée avec celle du serveur à la demande.
      • ltsp me semble donc être une surcouche peu utile—du moins, j'ai été plus convaincu par les tutoriels sur les briques qu'utilise ltsp que par la documentation de ltsp.

      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 . Évalué à 2.

        il n'est pas disponible dans ma distribution (arch)
        Faut être ouvert, et ne pas rester bloquer dans une distribution en particulier.

        je ne veux pas lancer les programmes sur le serveur, mais sur les clients (pas de ssh-x donc),
        Tu peux choisir si tel ou tel logiciel sera exécuté sur le serveur ou sur le client lui même afin de ne pas trop charger le serveur.

        j'aimerais éviter le «mini chroot environment» qu'utilise ltsp, et synchroniser la racine des clients directement avec celle du serveur.
        Le chroot de LTSP est quand même plus propre que de répliquer la racine du serveur sur les clients. Un serveur n'a pas le même environnement qu'un client. Car si je comprends bien ton idée, pour avoir LibreOffice par exemple sur un client tu vas l'installer sur le serveur ? Bizarre…

        à la limite, je n'ai pas besoin du boot pxe: les clients ont leur disque dur et leur racine, synchronisée avec celle du serveur à la demande.
        Le boot PXE est nécessaire dans le cadre de LTSP et non dans ton idée.

        ltsp me semble donc être une surcouche peu utile—du moins, j'ai été plus convaincu par les tutoriels sur les briques qu'utilise ltsp que par la documentation de ltsp.
        Si tout fois tu utilises LTSP, utilise NFS et non NBD pour de meilleures performances.

        As tu un lien vers une documentation concernant le boot PXE via le wifi?
        Tu as gPXE ou iPXE par exemple, et certainement d'autres encore.

        • [^] # Re: LTSP ?

          Posté par (page perso) . Évalué à 3.

          Faut être ouvert, et ne pas rester bloquer dans une distribution en particulier.

          Oui mais bon…

          Car si je comprends bien ton idée, pour avoir LibreOffice par exemple sur un client tu vas l'installer sur le serveur ? Bizarre…

          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?

          Le boot PXE est nécessaire dans le cadre de LTSP et non dans ton idée.

          C'est ce que je voulais dire, effectivement.

          Si tout fois tu utilises LTSP, utilise NFS et non NBD pour de meilleures performances.

          merci du conseil.

          Tu as gPXE ou iPXE

          Encore merci!

  • # de l'interet du lecteur DVD partagé

    Posté par . Évalué à 4.

    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?

    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 (page perso) . É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 (page perso) . Évalué à 4.

      ta question me fait penser à la question du scanner reseau dans une entreprise.
      […]
      mais mettre le document dans le scanner, retourner devant le PC, pour ensuite lancer le logiciel de scan pour recuperer une partie du document.

      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 . É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 (page perso) . É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:

          • pour les feuilles volantes, on peut acheter un scanner avec chargeur (pas seulement avec vitre et pose à plat). Le notre le fait, et fait même le scan recto-verso en chargeur!
          • pour les livres, ou feuilles agrafés, etc. les scanners ont souvent des options pour envoyer sur l'ordi depuis le scanner. Donc pas besoin d'AR. Je n'ai jamais essayé et je ne suis pas sûr du niveau de support de fonctionnalité pour Linux. J'aimerais bien tester un jour.
          • Enfin il reste la possibilité de scanner sur une clé USB puis de ramener la clé. Tous les scanners ont cette fonctionnalité de nos jours. Bon cette dernière solution est pas idéale, je trouve, mais bien mieux que d'acheter un scanner par personne. :P

          Pour le lecteur de cd/Dvd, je serais aussi de l'avis de le partagé

          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.

          on a de moins en moins l'utilité de ce support.

          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 ]

  • # Qu'entends-tu par ...

    Posté par . Évalué à 3. Dernière modification le 24/02/16 à 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 (page perso) . Évalué à 2. Dernière modification le 24/02/16 à 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:

      • J'ai fini par abandonner l'idée des clients diskless, du boot pxe, et de '/' monté sur le réseau parce que je ne suis pas certain que ce soit confortable via le wifi. Cela permet aussi de sortir un ordinateur du réseau si besoin (un portable par exemple).
      • Pour la synchronisation, il est possible d'utiliser Rsync. Il y a d'autres possibilités qui semblent amusantes: Csync2 et Btrfs send/receive. Je pensais lancer la synchronisation durant l'extinction du client.
      • J'aimerais vraiment éviter d'avoir à mettre à jour et le serveur et une arborescence dans un chroot. Àmha, le serveur peut contenir toute l'arborescence dont ont besoin les clients (avec X, OpenOffice, etc.), il a juste besoin de sa propre configuration pour ne lancer que les services dont il a besoin. Non?

      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 . Évalué à 3.

        J'ai fini par abandonner l'idée des clients diskless, du boot pxe, et de '/' monté sur le réseau parce que je ne suis pas certain que ce soit confortable via le wifi. Cela permet aussi de sortir un ordinateur du réseau si besoin (un portable par exemple).

        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 (page perso) . É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 . É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 (page perso) . É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 (page perso) . Évalué à 2.

      Merci pour SystemImager, que je ne connaissais pas.

      NFS paraît bien si le wifi est rapide.

      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 (page perso) . É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 . É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 . Évalué à 2.

      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,

      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

      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)

      c'est à ca que sert l'option users dans fstab pour permettre à l'utilisateur de (de)monter un disque.

  • # owncloud

    Posté par . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.