krzyzstof

ok merci. Oui tout ce qui a des composants électronique a fortement augmenté avec la pénurie de composants (liés sans doute à la forte demande depuis le COVID).

@niklos0merci pour ton retour 😉 Tu aurais un retour aussi sur ton onduleur (+/-) ? Thanks

@Mic13710 @niklos0 merci pour vos réponses. Oui, j'ai vu que les APC Back UPS pro avaient du Gigabit après coup. Cependant, j'ai lu que les commentaires d'utilisateurs sur Amazon étaient assez critiques sur les errements du micrologiciel et sur le SAV. Avez-vous cependant, une réponse à la 2ème partie de ma question à savoir si l'utilisation des ports rj45 en Gigabits avaient des incidences sur les taux de transferts ? Ce qui m'intéresse pour le coup ce sont des retours objectifs, c'est-à-dire mesuré par exemple avec des outils comme iperf3 ou autre 😉

Bonsoir, Je souhaite faire l'acquisition d'un onduleur pour protéger en priorité mon NAS414 des (trop) fréquentes coupures de courant dans ma nouvelle région. En faisant certaines recherches j'ai vu que beaucoup d'onduleurs avaient une prise in et out RJ45 (comme par exemple le Eaton UPS Ellipse PRO 1200 USB FR). Est-ce que le fait de relier mon routeur internet à l'entrée RJ45 d'un onduleur puis de relier mon switch à la sortie RJ45 de l'onduleur (pour arroser mon réseau) fait perdre du débit ? En outre, je m'interroge sur hardware rj45 des onduleurs : sont-ils gigabit ? Car si je reprends la fiche descriptive sur Amazon de Eaton UPS Ellipse PRO 1200 USB FR, il est indiqué réseau 10/100 ! J'ai trouvé la doc de Eaton, mais pas de mention à ce sujet. Si vous pouviez éclairer mon tunnel d'ignorance avec vos lumières d'expériences sur le sujet, je suis preneur 😉 Merci Kzf

Bonsoir, Après avoir pas mal galéré pendant plus de 4 jours à temps pleins dans la lecture de différents tutos en français et anglais pour synchroniser en local mon PC linux avec mon NAS DS414 avec la commande rsync et avec un cryptage clés public/privé, je livre ici mon tuto qui pourra peut-être en aider certains dans ce cheminement. Je précise que certains tutos existent (biblio m'ayant aidé à formuler mon propre guide en fin de tuto) mais certains ne sont plus compatibles avec les versions récentes de DSM, et enfin une grande majorité est orientée W$ et non Linux. Bien évidemment, ce tuto n'est pas parfait et peut-être amendé en fonction de vos connaissances respectives. Dernier point, j'ai opté pour la commande rsync car les applicatifs de Syno (principalement Drive) m'ont généré soit beaucoup de ralentissements, soit des lourdeurs de mise en oeuvre ou soit enfin des bugs...😬 Configuration Serveur NAS Synology DS414 (x volumes) DSM v.6.2.3 Client Linux Kubuntu 18.04 LAN RJ45 cat.7 / Wifi désactivé Préparation du NAS (serveur ssh et rsync) Compte « Admin » désactivé Compte utilisateur « Moi » activé en mode administrateur Activer le service SSH : Accéder à la page des paramètres du terminal sur votre périphérique Synology : DSM > Panneau de configuration > Terminal & SNMP > Terminal. Cocher la case Activer le service SSH. Spécifier un numéro de port pour les connexions SSH et enregistrer les paramètres. Certains préconisent (d'autres non) de remplacer le port 22 par défaut par un autre (ici 22222 pour l’exemple) afin de garantir une meilleure sécurité du système. Activer le service rsync : Accéder à la page des paramètres Services de fichier sur votre périphérique Synology : DSM > Panneau de configuration > Services de fichiers > rsync > Activer le service rsync Dans la case « Port de chiffrement SSH », mettre le port spécifique que vous avez choisi précédemment. Attention, lorsque l’on clique sur « Activer le service rsync » et que le firewall du DSM est actif, ce dernier va créer des règles. Une fenêtre de notification apparaîtra à cet effet si vous avez validé l’option des notifications. Vérifier que l’utilisateur a les permissions rsync : DSM > Panneau de configuration > Utilisateur > Le_nom_de_l’utilisateur (ici Moi) > Modifier > Applications> rsync (doit être coché) Vérifier l’activation des ports dans le pare-feu du NAS : Les ports rsync et « service terminal chiffré » (SSH) doivent être activés et le port SSH doit correspondre à celui choisi (par défaut 22, dans notre exemple 22222) Attention comme indiqué précédemment, l’activation du service rsync a normalement créée automatiquement des règles pour autoriser rsync. Dans mon cas, j’avais au préalable autorisé les règles pour rsync et ssh dans le firewall dans un profil personnalisé. Aussi, l’ajout automatique des règles lors de l’activation du service rsync ne me semblait pas utile puisque en doublon avec ceux existant déjà dans mon profil. Bien que les règles rsync et ssh soient exactement les mêmes que les miennes (même port, même protocole), la suppression des règles automatiques rend impossible (« denied ») la communication entre le client et le serveur. Soit c’est un bug DSM, soit je merdoume de mon côté mais impossible de trouver ce qui cloche dans mon profil firewall... Créer un dossier partagé de sauvegarde : DSM > Panneau de configuration > Dossier partagé > Créer Donner un nom (ici « Synchronisation »), choisir un volume (ici "volume 1"), activer la corbeille Donner les permissions « Lecture/Ecriture » pour votre profil (ici « Moi ») et interdire à tous les autres utilisateurs (« Pas d’accès ») Préparation du PC linux (client ssh, rsync et clés de cryptage) Le nom d'utilisateur du PC linux : krzyzstof Par défaut rsync est installé sur tous les postes linux. Si tel n’était pas taper dans le terminal la commande : sudo apt-get install rsync Par défaut ssh client est installé sur tous les postes linux. Si tel n’était pas taper dans le terminal la commande : sudo apt-get install openssh-client Création des clés de cryptage Taper dans le terminal : ssh-keygen -t rsa -b 4096 -C "Clé ssh Moi" où « rsa » correspond à l’algorithme de cryptage ; « 4096 » la force du cryptage ; « -C » permet d’insérer un commentaire (cet attribut et le commentaire sont optionnels, on peut donc écrire la ligne de commande sans cette partie). Le terminal vous renseigne sur la création des clés public et privée. Il vous demande alors : le dossier de destination où enregistrer les clés. Il vous propose un dossier par défaut (qu’il est conseillé de valider) du type : /home/moi/.ssh/id_rsa une phrase de passe (équivalent d’un mot de passe) afin de chiffrer la clé privée. Il est conseillé d’en donner une pour une meilleure sécurité même en local. Si vous ne voulez pas en inscrire une alors validez la question par « ENTREE », sinon renseignez votre clé (et ne l’oubliez pas, elle vous sera redemandé pour les connexions). Dans ce tuto, les instructions qui suivent prennent en considération l’existence d’une phrase de passe. La clé publique (id_rsa.pub) et la clé privée (id_rsa) se trouve donc dans le dossier dit caché : /home/votre_profil/.ssh Envoi de la clé publique sur le NAS (serveur ssh) Ouvrir le terminal dans le dossier contenant la clé public et privée, soit dans /home/votre_profil/.ssh/ Taper dans le terminal la commande de type : ssh-copy-id -i id_rsa.pub votre_utilisateur_NAS@IP_local_NAS -p port_spécifique_ssh soit dans notre exemple fictif : ssh-copy-id -i id_rsa.pub Moi@192.168.1.100 -p 22222 A la demande de mot de passe, donner le mot de passe de votre compte utilisateur NAS (et non de la phrase de passe de la clé de cryptage privée). Avec son navigateur internet, se connecter au DSM et vérifier que dans le dossier du compte utilisateur (ici Moi), le dossier « .ssh/ » et le fichier « authorized_keys » ont été créés. Vérifier le contenu du ficher « .ssh/authorized_keys » Revenir sur le Terminal Linux et faire un test de connexions en ssh crypté en tapant la commande de type : ssh votre_utilisateur_NAS@IP_local_NAS -p port_spécifique_ssh soit dans notre exemple fictif : ssh Moi@192.168.1.100 -p 22222 Donner cette fois la phrase de passe de votre clé de cryptage privée. Vous êtes connecté si vous n’avez pas de message d’erreur* et que vous avez l’invite commande de type : votre_utilisateur_NAS@Nom_du_NAS:~$ soit dans notre exemple : Moi@DS414:~$ * si vous avez le message : « Connection closed by 192.168.1.100 port 22222 », c’est qu'il y a de fortes chances que vous avez été trop long à rentrer votre phrase de passe 😜 Pour se déloguer taper dans le terminal : exit Processus de synchronisation modèle théorique en mode ssh : rsync "-e ssh -p numéro_port_ssh" choix_des_attributs /home/mondossier_source user@ip_du_serveur:/dossier/destination/ # ATTRIBUTS (en vert ceux retenus dans notre cas) # -a : archive ⇒ préserve les dates, permissions, etc … des fichiers. Inclus l'option récursivité. Option à utiliser quand on veut transférer des répertoires entiers avec leurs sous-répertoires en préservant toutes les caractéristiques des fichiers. Equivalent aux attributs groupés de -rlptgoD # -D : préserve les périphériques # -e ssh -p numéro_port_ssh : utilise le protocole SSH avec un port ssh spécifique (si le port par défaut 22 a été configuré dans le serveur ssh, alors "-p numéro_port_ssh" est inutile. Si un port spécifique a été choisi, il faut alors mettre l'attribut -e ssh -p numéro_port_ssh entre guillemet, soit : "-e ssh -p numéro_port_ssh". Je suppose que cela doit être pour ne pas confondre avec l'attribut -p ci-dessous) # -g : préserve le groupe # -h : les chiffres produits sont dans un format de lecture lisible par les humains. # -l : copie les liens symboliques comme liens symboliques. Est inclus dans l'option -a # -L : remplace les liens symboliques par les fichiers référencés. # -n : simule la sauvegarde mais n'effectue aucune opération concrète de sauvegarde. Très intéressant pour simuler et vérifier les éventuelles erreurs. # -o : mettre le propriétaire du fichier de destination identique à celui du fichier source # -p : provoque la mise à jour des permissions sur la destination pour qu'elles soient identiques aux permissions sur la source # -q : n'affiche que les lignes d'erreur lors du transfert. Ainsi si notre synchronisation nous retourne des erreurs de transfert à la fin du processus, le fait de rajouter -q et de relancer le backup permet d'afficher les seuls lignes de contrôle concernant les erreurs # -r : la synchro est récursive (elle prend les sous-répertoires). Est inclus dans l'option -a # -t : préserve les dates # -v : verbeux (affichage de ce que fait la commande pendant qu'elle le fait). # -z : compresse les fichiers (Limite la bande passante mais augmente l'utilisation processeur et le temps de transfert : inutile en réseau local ou avec très bon débit) # --del : permet de supprimer les fichiers sur "destination" qui n'existent plus sur "source" # --delete : --delete : efface avant le transfert les fichiers qui n'existent pas sur la source. # --delete-after : à la fin du transfert, supprime les fichiers dans le dossier de destination ne se trouvant pas dans le dossier source. # --delete-excluded : si l’on a choisi des fichiers à exclure du transfert et qu’ils sont déjà présents dans le dossier de destination, ils seront effacés de la destination. # --exclude="nom_de_dossier" (exclure des fichiers ou dossiers de la sauvegarde : rsync --exclude="nom_de_dossier" --exclude="- autre_nom_de_dossier" source/ destination/) # --force : force la suppression de répertoires même non-vides # --ignore-errors : efface même s'il y a eu des erreurs E/S (IO error) # --progress : montre l'avancement pendant le transfert à la différence de -v # --stats : affiche quelques statistiques de transfert de fichiers, ce qui permet de vérifier l'efficacité de la sauvegarde Notre synchro en mode simulation : rsync "-e ssh -p 22222" -h --progress --stats -an --update --delete-after --delete-excluded --ignore-errors --exclude=**/*tmp*/ --exclude=**/*cache*/ --exclude=**/*Cache*/ --exclude=**~ --exclude=/mnt/*/** --exclude=/media/*/** --exclude=**/lost+found*/ --exclude=/var/run/** --exclude=/run/** --exclude=/proc/** --exclude=/dev/** --exclude=/sys/** --exclude=**/*Trash*/ --exclude=**/*trash*/ --exclude=/krzyzstof/test/** --exclude=/krzyzstof/.local/share/baloo/** /home/krzyzstof Moi@192.168.1.100:/volume1/Synchronisation Pour info, les attributs et les exclusions correspondent à mes choix et à ma configuration, chacun est libre de modifier les paramètres et les dossiers. Ici par exemple le dossier "baloo" contient l'indexation par Linux KDE de tous mes documents sur mon PC. C'est très très lourd en termes de Go et inutile à synchroniser. Nous avons rajouter l’option « --ignore-errors » car le transfert nous retournait l’erreur « IO error encountered -- skipping file deletion » malgré le fait que les permissions de lecture/écriture était bien accordé à l’utilisateur pour le dossier de destination ainsi que toute son arborescence. Bref, impossible d’effacer les fichiers sur la destination lors de la synchronisation. C’est un problème qui revient souvent dans les sujets de forums. Je n’ai pas très bien compris les raisons mais l’option « --ignore-errors » a été pensé expressément pour pallier ce problème. Notre synchro en mode réel rsync "-e ssh -p 22222" -h --progress --stats -a --update --delete-after --delete-excluded --ignore-errors --exclude=**/*tmp*/ --exclude=**/*cache*/ --exclude=**/*Cache*/ --exclude=**~ --exclude=/mnt/*/** --exclude=/media/*/** --exclude=**/lost+found*/ --exclude=/var/run/** --exclude=/run/** --exclude=/proc/** --exclude=/dev/** --exclude=/sys/** --exclude=**/*Trash*/ --exclude=**/*trash*/ --exclude=/krzyzstof/test/** --exclude=/krzyzstof/.local/share/baloo/** /home/krzyzstof Moi@192.168.1.100:/volume1/Synchronisation Notre synchro en mode réel avec l'affichage des seuls lignes de contrôle comportant des erreurs de transfert rsync "-e ssh -p 22222" -h -q --progress --stats -a --update --delete-after --delete-excluded --ignore-errors --exclude=**/*tmp*/ --exclude=**/*cache*/ --exclude=**/*Cache*/ --exclude=**~ --exclude=/mnt/*/** --exclude=/media/*/** --exclude=**/lost+found*/ --exclude=/var/run/** --exclude=/run/** --exclude=/proc/** --exclude=/dev/** --exclude=/sys/** --exclude=**/*Trash*/ --exclude=**/*trash*/ --exclude=/krzyzstof/NAS_DS414/** --exclude=/krzyzstof/.local/share/baloo/** /home/krzyzstof Moi@192.168.1.100:/volume1/Synchronisation Sources d’information (non exhaustives) ayant aidé à ce tuto : https://openclassrooms.com/fr/courses/43538-reprenez-le-controle-a-laide-de-linux/41773-la-connexion-securisee-a-distance-avec-ssh#ss_part5 https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General_Setup/How_to_login_to_DSM_with_root_permission_via_SSH_Telnet https://doc.ubuntu-fr.org/rsync https://doc.ubuntu-fr.org/tutoriel/sauvegarder_home_avec_rsync https://www.synology.com/en-us/knowledgebase/DSM/tutorial/Backup/How_to_back_up_Linux_computer_to_Synology_NAS https://man.developpez.com/man1/rsync/ https://www.synology.com/fr-fr/knowledgebase/DSM/help/DSM/AdminCenter/file_rsync https://www.youtube.com/watch?v=FZ9-_O9t814 https://www.wundertech.net/how-to-backup-a-linux-pc-to-a-synology-nas-using-rsync/ https://doc.ubuntu-fr.org/ssh#configuration_du_serveur_ssh https://www.nas-forum.com/forum/topic/57289-tuto-accès-ssh-et-root-via-dsm-6/ https://superuser.com/questions/516041/rsync-command-deletion-error-io-error-encountered-skipping-file-deletion

Pas de souci 😊 Alors la commande "sudo smbstatus --share" me retourne juste : Service pid Machine Connected at Encryption Signing --------------------------------------------------------------------------------------------- Je précise qu'avant d'avoir effectué cette commande j'ai fais un test de transfert en mode samba entre le PC --> NAS et inversement

Bon Daffy, j'ai bien regardé et testé (après avoir perdu beaucoup beaucoup de temps sur la signification et la compréhension des différentes options de montage et aussi suite une erreur malencontreuse dans mon chemin de partage lorsque j'ai recommencé à zéro mes montages), mais j'ai toujours les mêmes problèmes concernant 1) le freeze lors de l'upload (PC --> NAS) et un débit mieux que sous SMB mais pas à la hauteur de W$ (en moyenne : smb=34Mo/s ; NFS=75 Mo/s ; W$10=125Mo/s) 2) L'impossibilité d'accéder à un dossier que j'ai moi-même créer et partager. Aucun souci par contre pour les dossiers par défaut (music, vidéo, etc.). Franchement je sèche. Cela ne serait pas une commande pour Mac ??? 🙃 Après une recherche, j'ai cru comprendre que cela correspondait à : "Vérifier l’état de la signature des paquets SMB" (cela ne m'évoque strictement rien 😁) et je n'ai pas trouvé d'équivalence sous ubuntu (mais ne comprenant pas ce que je cherche... 😉) Je n'ai pas encore eu le temps de regarder de ce côté pour l'instant...

Merci Daffy et Shad pour vos réponses 👍 Je regarde dès que possible et je fais un retour ! 😉

Hello, j'ai donc longuement investigué sur ce protocole NFS qui ne m'est pas familier. Et effectivement en passant par NFS, les taux de transferts augmentent significativement. Cependant, je rencontre 2 problèmes. 1) Si le transfert du NAS vers le PC me donne des taux de transfert de 100 Mo/s (au lieu des 34 Mo/s sous SMB linux mais 120 Mo/s sous W$10), le transfert de PC vers NAS semble nettement moins rapide. Alors je dis "semble" car enfin de compte dans ce sens mon pc semble "freezer" : l'icône de notification de transfert en bas à droite du bureau n'apparaît pas et Dolphin ne répond plus jusqu'à la fin du transfert. Montant mes partitions avec autofs, j'ai bien noté une remarque stipulant : N'utilisant pas Nautilus mais Dolphin, je n'ai pas trouvé ce fichier .gtk-bookmarks. J'ai juste trouvé un fichier bookmarks dans le répertoire .config/gtk-3.0/ Dans ce fichier pas de trace de partage nfs. J'ai aussi arrêté le service autofs avec : sudo service autofs stop puis j'ai monté manuellement mon répertoire du type : mount 192.168.1.253:/volume1/video /media je relance le transfert de NAS vers PC (tout est ok et rapide), puis de PC vers NAS, et là rebelotte, freeze et temps de transfert plus long Remarque personnelle : sous le boot W$10 le taux de transfert monte plus haut (120 Mo/s) et reste surtout plus stable sans réelle fluctuation de débit. Avec NFS le débit est un peu moindre (en tout cas de NAS vers PC) mais surtout très fluctuant avec des baisses jusqu'à 50 Mo/s ou moins. Alors soit ce protocole est moins performant, soit (ou les deux à la fois) Synology n'est pas vraiment bien conçu pour ce protocole, non ? 2) Avec tous les dossiers par défaut sous le NAS (video, music...) que je partage, je ne rencontre pas de problème de montage. Par contre, si je crée dans le NAS un nouveau dossier, admettons "Test" et que je lui octroi les mêmes permissions que les dossiers par défaut, je vois bien sur mon pc le montage mais je ne peux y accéder. J'ai bien vérifié j'ai exactement les mêmes paramètres et permissions que les dossiers par défaut. Après plusieurs heures je sèche...

Merci Daffy pour ta réponse :) Pour le protocole smb en maxi j'ai SMB 3 et en mini SMB 2 Concernant le partage en nfs sous linux, je t'avoue que je ne sais pas, ayant toujours eu l'habitude de partager en smb. Je vais regarder ce que je trouve dans cette direction 😉

Bonjour, Après mon 1er post de présentation, je passe directement à mon 1er post technique 😇. J'ai hésité entre la thématique "réseau" et "linux", désolé si je me suis égaré. Voilà mon problème : Je viens de finir le câblage rj 45 de ma maison (câble cat.7 et prise cat.6a) et je rencontre un problème de débit entre mon PC HP (cf. config en signature) et mon NAS (Synology DS414, DSM 6.2) lorsque je suis en boot KDE 18.04. A titre d'exemple un fichier de 1,5 Go passe à 34 Mb/s (du pc vers NAS ou NAS vers PC) alors que lorsque sur le même PC mais en boot W$10 le même fichier transite à 120 Mb/s. Le fichier transite par le partage et le montage d'un dossier du NAS. Avant toute chose j'ai vérifié que mes câbles et mes cartes réseaux de pc étaient ok. J'ai donc installé sur les différents PC linux et W$ de mon habitat le programme iperf3 et lancé un test entre ces PC. Les résultats étaient de l'ordre de près de 1Gb/s sauf sur mon PC HP en boot KDE qui plafonnait à 100 Mb/s (et bien 1G sous le boot W$). Je suis allé donc dans les paramètres de la carte réseau et je me suis aperçu que dans l'onglet "cablé", le champ "vitesse" était plafonné à 100 Mb/s. J'ai donc changé la valeur à 1000 Mb/s et j'ai relancé un test avec iperf3. Là, super, les résultats de débit approchait le Go. Cependant, cela n'a pas changé mon problème de débit entre mon HP sous KDE et mon NAS. Les débits restent toujours aussi faiblards. Je précise que sur la config de la carte réseau, le MTU est sur "automatique". J'ai essayé avec la valeur "1500" mais cela n'a rien changé. Je suis donc revenu sur "automatique". Donc si vous avez des idées... Merci Pour info les lignes de commande linux suivantes donnent : sudo lshw -C network *-network DÉSACTIVÉ description: Ethernet interface produit: Dual Band Wireless-AC 3168NGW [Stone Peak] fabriquant: Intel Corporation identifiant matériel: 0 information bus: pci@0000:02:00.0 nom logique: wlp2s0 version: 10 numéro de série: 30:e3:7a:cf:d1:fe bits: 64 bits horloge: 33MHz fonctionnalités: pm msi pciexpress bus_master cap_list ethernet physical configuration: broadcast=yes driver=iwlwifi driverversion=4.15.0-91-generic firmware=29.3e3b4de5.0 latency=0 link=no multicast=yes ressources: irq:133 mémoire:dea00000-dea01fff *-network description: Ethernet interface produit: Ethernet Connection (4) I219-LM fabriquant: Intel Corporation identifiant matériel: 1f.6 information bus: pci@0000:00:1f.6 nom logique: enp0s31f6 version: 21 numéro de série: 40:b0:34:12:76:af taille: 1Gbit/s capacité: 1Gbit/s bits: 32 bits horloge: 33MHz fonctionnalités: pm msi bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation configuration: autonegotiation=off broadcast=yes driver=e1000e driverversion=3.2.6-k duplex=full firmware=0.1-4 ip=192.168.1.113 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s sudo ifconfig enp0s31f6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.113 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fdd0:ff98:d6ef:3300:b375:9ba:42af:bdb prefixlen 64 scopeid 0x0<global> inet6 fe80::42e3:ae40:d299:777d prefixlen 64 scopeid 0x20<link> inet6 fdd0:ff98:d6ef:3300:695a:676:bf22:f12c prefixlen 64 scopeid 0x0<global> ether 40:b0:34:12:76:af txqueuelen 1000 (Ethernet) RX packets 17317 bytes 20289818 (20.2 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 10516 bytes 1367173 (1.3 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 16 memory 0xdec00000-dec20000 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Boucle locale) RX packets 463 bytes 41847 (41.8 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 463 bytes 41847 (41.8 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 cat /etc/network/interfaces # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback

Hello Déjà 1/2 siècle d'existence, j'ai commencé mon apprentissage de l'informatique avec un ZX81 de Sinclair, puis Commodore 64, Atari 1040ST, puis passe aux PC sous W$ pour enfin passer sous Linux depuis plus de 10 ans maintenant. Mon niveau en informatique de réseau est malheureusement très faible. Je songe à m'auto-formé dès que j'aurais un peu plus de temps à ma disposition (j'espère l'année prochaine). Je viens de finir le cablage en rj45 (cable cat.7, prises cat.6a) de ma maison (reste les dépendances à faire de ma propriété agricole), j'ai viré le wifi. En termes d'équipement : plusieurs pc sous linux (KDE, XCFE) et w$ 10, un routeur Huawei 4G de BT (étant en zone blanche), un switch Gb et enfin un NAS Syno DS414 avec 2 disques de 3 To monté en RAID SHR. Ils sont à 90% pleins, donc future achat en perspective ;) Ce NAS (mon 1er et acheté en 2014) sert principalement à stocker ma musique dématérialisée (1,3 To) et la sauvegarde du contenu des différents pc. Il me servait aussi pour la gestion de mes caméras de vidéo surveillance mais depuis mon récent emménagement les caméras sont encore dans les cartons. Voilà, j'espère avoir été assez synthétique et exhaustif. :)