.Shad.

Je ne sais pas pourquoi tu m'as cité je n'ai rien dit concernant l'emplacement de la discussion 😉 Dans mon utilisation de particulier, je ne vois pas l'intérêt de faire un cluster comme ça peut l'être en entreprise. De plus je suis assez regardant sur la consommation énergétique. D'où le NUC à la base qui montre quand même certaines limites (pas de RAID possible). Mon serveur sera assez peu énergivore une fois en production. On ne peut pas dire la même chose d'un cluster de plusieurs machines, qui plus est avec des VM. Et honnêtement le labporn c'est pas mon truc. 😛

Problème identifié, c'était lié à des champs encore commentés dans le fichier de configuration de telegraf.

Je ne sais pas vraiment si c'est utile, à partir du moment où tu peux renouveler le certificat sur le NAS, tu l'associes à ton proxy inversé qui garantit une connexion sécurisée à tes services, en l'occurrence ça peut être l'interface d'administration de ton RT ? Après si c'est "pour la science", SRM est je trouve bien moins au point que DSM, pas sûr que ta tâche soit facilitée pour trouver ce genre de fichiers ;).

Il faut ajouter la partie allant de [[inputs.snmp]] compris à oid = "SYNOLOGY-UPS-MIB::upsBatteryChargeWarning" compris. Et respecter l'indentation, par exemple : [[inputs.snmp]] agents = ... interval = ... [[inputs.snmp.table.field]] name = "usersTELNET" oid = "SYNOLOGY-SERVICES-MIB::serviceUsers" oid_index_suffix = "7" Bien décaler les éléments de la sorte (le nombre d'espaces n'est pas important, ce qui compte c'est l'alignement).

C'est un tutoriel qui a 6 ans je sais même pas si la section existait 😄

Erreur 401 c'est accès non autorisé, ça peut être des identifiants qui ne correspondent pas entre ce que tu as mis dans l'authentification http dans telegraf.conf et les variables d'environnement de création du conteneur influxdb.

Ton log t'indique justement une erreur 401 (stderr => standard error). La bonne nouvelle c'est que telegraf arrive bien à communiquer avec influxdb, car influxdb voit bien les requêtes, certes qui n'aboutissent pas. De plus dans ta deuxième impression d'écran de telegraf.conf, on voit que tu as mis : agents = [ "172.19.0.1"1" ] Les caractères en rouge sont en trop 😛 Par contre ça n'y est pas dans la première ? Autre chose, est-ce que le pare-feu du NAS a bien son port 161 ouvert vers les adresses 172.16.0.0/255.240.0.0 (par défaut si tu as suivi la sécurisation du NAS de Fenrir) ? C'est le port utilisé par telegraf pour "poll" (sonder) le NAS.

J'ai monté un serveur perso sous Debian Buster pour en faire une sandbox et m'amuser un peu avec du btrfs et des VM, domaines que je ne connais vraiment pas assez encore. Je garde mon DS918+ pour la gestion des photos par Moments et toute la partie Gestion des disques qui, comme le confirme ta présentation, est quand même bien pensée sur DSM. 🙂 Pour l'instant la haute disponibilité n'est pas dans le tableau des objectifs à court terme 😉

Quand tu as ce message, il y a deux possibilités : - La plus probable c'est que tu t'es trompé dans l'adresse de l'instance influxdb, si tu as suivi le tutoriel à la lettre c'est http://influxdb:8086, sinon il faut adapter à ce que tu as fait, si tu donnes plus de détail là-dessus on peut t'aider. - La seconde c'est que le conteneur influxdb ne fonctionne pas, et que donc telegraf ne trouve nulle part où envoyer ses données. Regarde toujours les logs d'influxdb si tu vois quelque chose d'anormal.

Le mien était silencieux, concrètement fallait être à moins d'un mètre pour l'entendre (et je ne suis pas sourd 😛) Est-ce que tu arrives à identifier si c'est un bruit cyclique, typiquement peut-être un balourd dans l'axe pivot du ventilateur qui pourrait le faire vibrer, ou si c'est le bruit est homogène ?

Salut et bienvenue, Attention, le RAID/SHR n'est pas une sauvegarde, c'est une continuité de service. Si un disque lâche, l'autre prend le relai de manière transparente. Si par contre ton NAS subit une chute, ou que la foudre grille tes disques, si les disques sont morts les données son perdues. Donc RAID si besoin d'assurer une continuité de services, et sauvegarde obligatoire des données importantes sensibles, idéalement à la fois sur un périphérique externe (disque dur externe par exemple), et un à distance (NAS distant ou solution cloud). Ce NAS est un excellent modèle, et permet tout un tas de choses que tu ne soupçonnes peut-être pas encore, je t'invite à consulter les différents tutoriels du forum pour te faire une idée, en commençant par :

Oui je voulais dire que je n'utilisais pas de connexion VPN en tant que client sur mon NAS, j'avais bien compris ton utilisation. Je ne peux pas te renseigner plus que ça malheureusement. 😕 D'autres seront plus à même que moi de t'aider, je l'espère.

Tu as cette solution qui pourrait t'intéresser :

Il faudrait surtout voir dans un premier temps quels logs détiennent des informations concernant la connexion VPN en tant que client, n'utilisant pas le serveur VPN de DSM je ne peux pas plus t'aider... Tu pourras toujours essayer de voir ce que tu trouves d'intéressant dans le fichier /var/log/messages (une fois l'outil SSH pris en main).

Est-ce que tu as essayé d'activer les passerelles multiples ? Ça se trouve dans les options réseau normalement. Sinon en faisant une recherche sur le forum tu tomberas rapidement dessus.

Bienvenue ! Conteneur ne signifie pas nécessairement faille de sécurité, le tout étant d'être vigilant aux utilisateurs qui exécutent le processus et les volumes qu'on monte dans nos conteneurs. Si je devais faire une VM pour chacun de mes services ça me ferait mal aux ressources 😛 Beau pedigree sinon 😉

Je ne suis pas sûr d'avoir bien compris ce que tu as fait, les commandes que tu tapes, etc... Tu peux faire des impressions d'écran de ton entrée de proxy inversé, que je vois ce que tu veux dire par là :

Sinon tu passes par un proxy inversé en lieu et place du certificat SSL directement monté dans le conteneur Bitwarden. Il y a un tutoriel à ce sujet sur le forum.

Salut, Oui en effet pyouroboros n'est plus en développement, en revanche comme le disent ses devs dans leur message sur la page Github il fait le job, et perso je l'utilise toujours sans la moindre erreurs sur 3 machines différentes. Mais tu peux aussi tout à fait t'orienter vers watchtower dont le développement a récemment repris (attention par contre j'avais lu sur un forum qu'il y avait a contrario de pyouroboros pas mal de petits bugs). J'ajouterai que ce guide te sera quand même utile parce que tu peux transposer la logique de l'un à l'autre, pyouroboros étant à la base un fork de watchtower il en a repris la structure, et le nouveau watchtower reprend cette même logique.

Il faut utiliser les VLAN et des switchs administrables pour ça.

@bruno78 Sinon, la solution n'est pas des plus directes, mais vu qu'on doit toujours trouver des solutions pour contourner les limitations imposées par DSM, il y aurait celle-ci : https://github.com/linuxserver/docker-openssh-server Si tu souhaites utilises ton protocole SFTP dans des dossiers bien définis, ça pourrait tout à fait convenir. En revanche si tu es amené à aller dans n'importe quel endroit de l'arborescence, je n'irais personnellement jamais monter "/" du NAS dans un conteneur Docker, trop dangereux.

Je pense juste que dans la config du daemon de SSH les clés sont refusées pour les utilisateurs lambda. J'ai cru comprendre que seuls les utilisateurs admin (au sens Synology) peuvent se connecter par clé en SFTP.

Bienvenue !

J'ai trouvé plusieurs sources qui disent que le compte root n'est pas accessible en SFTP, par exemple : http://blogmotion.fr/systeme/enable-sftp-serveur-synology-8702 Depuis DSM 6 apparemment.

Accès externe tu y définis l'adresse qui apparaîtra lorsque tu partageras un fichier. Dans mon cas ça donne https://dsm.ndd.ovh(:443) C'était la redirection qui posait problème dans ton cas. 😉