oracle7

@MilesTEG1 Bonjour, J'essaie juste d'exploiter la nouvelle MIB (SYNOLOGY-PORT-MIB.txt) concernant les ports eth du routeur RT afin d'afficher dans grafana l'état de chaque port ainsi que sa vitesse. Mais manifestement, la déinition dans le telegraf.conf pose problème. Cordialement oracle7😉

@.Shad. Bonjour, NON, j'ai bien pensé créer un répertoire keys/root/ dans /etc/ssh/ et y mettre le fameux fichier "authorized_keys" mais toujours le même problème : cela ne survivra pas à une MàJ de SRM. Donc j'ai oublié l'idée. Cordialement oracle7😉

@Diplo95 Bonjour, Oui tu as raison mais je mettrai juste un bémol : la fenêtre de la console de WinSCP ne supporte pas les commandes dites interactives et plante complètement WinSCP en cas d'usage de ces dernières. C'est pour cela qu'il est préférable de travailler avec une console puTTY ouverte à partir de WinSCP. En plus cette console supporte mieux les C/C que celle de WinSCP. Mais c'est juste mon avis ... Cordialement oracle7😉

@.Shad. Bonjour, Oui, il est en standard identique à ce qu'a dit @MilesTEG1 précédemment : non commenté et positionné à Yes. J'ai par ailleurs comparer les fichiers /etc/ssh/sshd_config du routeur et d'un de mes NAS : Sur le routeur j'ai la ligne active : AuthorizedKeysFile /etc/ssh/keys/%u/authorized_keys Alors que sur le NAS la "même ligne" est commentée et pointe ailleurs : #AuthorizedKeysFile .ssh/authorized_keys Sur le RT et le NAS j'ai la même chose pour : #PubkeyAuthentication yes Etonnant, non ? Cordialement oracle7😉

@MilesTEG1 Bonjour, J'ai simplement suivi le TUTO : Accès SHH et ROOT via DSM6. Je penses que le couple clés privée+publique est plus sécurisant qu'un simple MdP même long. Mais ce n'est que mon avis ... Je ne préfère pas modifier ce type de fichier car à la première MàJ de DSM il est réinitialisé automatiquement et avant de penser qu'il l'a été, on risque fort de chercher longtemps si un dysfonctionnement apparaît à ce niveau avant d'y penser. En tous cas, j'espère que @.Shad. aura une idée à suggérer vis à vis de la clé réfusée par le routeur lors de la connexion WinSCP ou puTTY car il me semble bien que cela fonctionnait correctement les mois précédents. Cordialement oracle7😉

@Diplo95 Bonjour, Absolument, les variables sont crées en mémoire et ne vivent que le temps de ta session SS . Donc si tu fermes/clos ta session SSH même sans quitter WinSCP et a fortiori si tu quittes WinSCP ou puTTY (si ouvert seul), il te faudra réexporter TOUTES les variables depuis le début afin de reprendre le processus acme.sh où tu t'étais arrêté. C'est contraignant mais on ne peux faire autrement et c'est même logique comme comportement. Cordialement oracle7😉

@Diplo95 Bonjour, Pas de soucis mais moi c'est @oracle7 !!! Sinon, je comprends que l'edit du 10/01/2021 t'ai perturbé mais il faut bien voir que c'est un "edit" et sa position n'est peut-être pas très heureuse mais difficile d'insérer ce type de précision sans tout réécrire ... Bonne continuation et n'hésites pas à reposter si tu as besoin d'éclairssissements. Cordialement oracle7😉

@.Shad. Bonjour, Merci de ta réponse. J'ai donc modifier le fichier telegraf.conf tel que ton conseil : # Ethernet Ports SRM [[inputs.snmp.table]] oid = "SYNOLOGY-PORT-MIB::ethPortTable" [[inputs.snmp.table.field]] is_tag = true oid = "SYNOLOGY-PORT-MIB::ethPortIndex" OK : aucune erreur dans le log de telegraf. Mais, AUCUN champ (ethPortStatus ou ethPortSpeed) n'apparaît dans la liste des champs de la table ethPortTable, pas plus que la table ethPortTable n'apparaît sous grafana. C'est confirmé avec un examen de test du fichier telegraf.conf avec la commande : telegraf --test --config /etc/telegraf/telegraf.conf Aucunes données ne remontent. Là je sèche ... Cordialement oracle7😉

@Diplo95 Bonjour, Je crains que tu vas un peu trop vite en besogne dans ta réflexion. Tu parles d'opérations réalisées mais pas dans le bon ordre. Je m'explique : Dans un premier temps (et seulement la première fois que le processus est déroulé) pour que le déploiement puisse de faire correctement, il faut exporter les variables d'environnement : SYNO_Scheme, SYNO_Hostname, SYNO_Ports, SYNO_Username, SYNO_Password, SYNO_Certificate et SYNO_DID. Pour cette dernière seulement si on utilise la 2FA et il faut avoir aussi préalablement (avant de recopier proprement sa valeur) vérifié la date d'expiration du cookie DID en ayant pris soin de la repousser "aux calandres grecques". Ensuite on lance la commande de déploiement du certificat. A partir de là SEULEMENT, le script "acme.sh" va sauvegarder (donc écrire) les valeurs des variables d'environnement sus-citées dans le fichier ndd.tld.conf avec le préfixe "SAVED_". Il sauve aussi (avec le même prefixe) les variables OVH_AK, OVH_AS dans le fichier /usr/local/share/acme.sh/account.conf ainsi que la variable OVH_CK mais elle, sans prefixe. Il sauve aussi dans ce fichier la variable SYNO_DID mais cette fois sous le nom SAVED_DID. Voilà en espérant que ce sera plus clair pour toi. Cordialement oracle7😉

@MilesTEG1 Bonjour, Rassures-toi tu n'es pas le seul à avoir des soucis à ce niveau sur le routeur. Depuis quelques jours, si je tente une connexion avec puTTY avec mon compte User-ADMIN dès que je valide la saisie de mon MdP, puTTY quitte violemment sans aucune explication. Maintenant depuis WinSCP, j'arrive à me connecter en SSH avec l'utilisateur root mais je dois renseigner le MdP, la connexion par clé SSH ne fonctionne plus : la clé est refusée par le serveur. J'ai donc refait une pair de clés privées/publique mais rien y fait, clé toujours refusée par le serveur. Ce qui est bizarre c'est que sur les NAS, il n'y a aucun problèmes à ce niveau. Sinon, j'arrive à désactiver sans problème le compte admin par défaut du routeur. Autre constat, il faut impérativement désactiver les plugins du type "uBlock Origin" dans le navigateur (FF) utilisé pour se connecter à SRM sinon, on reçoit des messages comme quoi l'utilisateur courant n'est pas autorisé pour valider par ex une modification dans le pare-feu du routeur. Va comprendre ??? Au final, je me demande si ces problèmes ne font pas suite à la mise à jour du paquet VPN Plus Server qui a eut lieu il y à 3 semaines même si le rapport avec n'est pas évident. En tous cas, c'est bizarre ???? Ton avis STP Cordialement oracle7😉

Bonjour, Juste pour dire deux choses constatées : Dans le fichier "telegraf.conf" la version avec oid "numérique" ne génère pas (plus) de messages d'erreurs dans le log de telegraf, contrairement à la version "littérale" pour les champs de la MIB SYNOLOGY-PORT-MIB.txt. La récente mise à jour 6.2.4 25556 a supprimé la MIB SYNOLOGY-PORT-MIB.txt que j'avais ajoutée à la main. Votre avis SVP Cordialement oracle7😉

@CyberFr Bonjour, Je persiste et signe : sûrement pas d'or. Il m'arrive aussi de dire des c...ies 🤪 (voire parfois plus grosses que moi) et j'admets aisément alors d'être corrigé par un "sachant" et ainsi d'être remis sur les bons rails de la connaissance. Cordialement oracle7😉

@PiwiLAbruti Bonjour, En premier lieu, je n'ai jamais procédé aux mises à jour manuelles illico après la sortie de la dite mise à jour tel le geek moyen. J'attends en général une quinzaine de jour et je ne la fais seulement après observation des retours effectués sur différents forums. Chance ou pas, en procédant ainsi je n'ai jamais constaté de problèmes (je croise les doigts pour l'avenir ...). @CyberFr Comme tu y vas ! ma parole n'est en aucun cas d'or ! C'est juste mon RETEX personnel et je suis tout autant prudent que toi 🙂. Cordialement oracle7😉

@MilesTEG1 Bonjour, Bah, je ne fais rien : je ne me casse pas la tête 😛 j'ai juste configuré avec un "fr.pool.ntp.org" et activé le service NTP sur SRM et DSM. Au final jamais aucun soucis avec la 2FA aussi bien sur les NAS que sur le RT. Cordialement oracle7😉

@CyberFr Bonjour, Pourquoi attendre cette mise à jour alors que tu peux la faire toi même en la téléchargeant ici puis en allant dans DSM "Panneau de configuration / mise à jour du DSM" pur la charger manuellement. Cordialement oracle7😉

@MilesTEG1 Bonjour, Attention le conseiller sécurité de DSM n'aime pas que l'on modifie directement le crontab en SSH, il risque fort de t'envoyer des messages d'insanités ... Il est préférable de mettre ta commande dans un Shell script "xxx.sh" et de programmer une tâche dans le gestionnaire de tâches de DSM qui exécutera ce Shell script à ta convenance. Maintenant ce que j'en dis ... Cordialement oracle7😉

@toutnickel Bonjour, Plus la peine de s'adresser à @fenrir, il ne passe plus ici depuis pas mal de temps déjà (il a dit lors de son dernier passage qu'il n'avait plus le temps ! c'est dommage mais c'est comme cela, il faut donc faire avec ...). Cela dit, si j'étais toi : je supprimerai cette ligne liée au port SSH dans ton pare-feu et je n'activerai le service SSH qu'en cas de besoin tout en ayant bien vérifié que le système de blocage auto pour ton compte est bien configuré et activé. Ceci d'autant plus où si je ne me trompe pas tu adressais directement ta box et ton NAS avec ces @IP 192.168.1.1 & 2. je désactiverai la règle liée au port SSH dans ton conseillé sécurité comme c'est préconisé dans le TUTO de sécurisation des accès au NAS. Pour les règle du pare-feu, elles sont toujours et plus que jamais d'actualité. la 2e ligne : si tu utilises par ex un VPN notamment OpenVPN la 3e ligne : si tu utilises par ex un VPN tel que L2TP/IPSec ou des applications sous docker. la 4e ligne : c'est pour autoriser tout ton réseau local sachant que cela m'étonnerai que tu utilises tous les sous-réseaux 192.168.0.0 à 192.168.255.255 ce qui représente tout de même 65534 @IP/machines. Tu peux raisonnablement réduire cela à 255 machines (et ce sera déjà pas mal !) en appliquant simplement le masque 255.255.255.0 au lieu de 255.255.0.0. Cordialement oracle7😉

@MilesTEG1 Bonjour, Désolé, je n'ai jamais rencontré ce problème. Je croise les doigts ...😛 As-tu aussi bien récupérer sur ton compte Synology ta série de dix codes de secours ? Ca peut être utile ... Cordialement oracle7😉

@.Shad. Bonjour, Merci pour l'info. Au titre des modifications on peut dire aussi que : Le document guide PDF a été aussi pas mal complété. Les quatres MIB : SYNOLOGY-SPACEIO-MIB.txt, SYNOLOGY-STORAGEIO-MIB.txt, SYNOLOGY-SYSTEM-MIB.txt et SYNOLOGY-UPS-MIB.txt ont été aussi modifiées. La MIB : SYNOLOGY-PORT-MIB.txt est nouvelle et concerne les ports Ethernet de SRM / Par ailleurs j'ai essayé de les intégrer dans le fichier telegraf.conf pour les exploiter mais ils ne sont pas reconnus : erreur dans telegraf : # docker logs -f telegraf 2021-04-05T13:03:44Z I! Starting Telegraf 1.17.3 2021-04-05T13:03:44Z I! Using config file: /etc/telegraf/telegraf.conf 2021-04-05T13:03:44Z I! Loaded inputs: cpu disk diskio docker kernel mem processes snmp (2x) swap system 2021-04-05T13:03:44Z I! Loaded aggregators: 2021-04-05T13:03:44Z I! Loaded processors: converter strings 2021-04-05T13:03:44Z I! Loaded outputs: influxdb 2021-04-05T13:03:44Z I! Tags enabled: host=telegraf 2021-04-05T13:03:44Z I! [agent] Config: Interval:30s, Quiet:false, Hostname:"telegraf", Flush Interval:10s 2021-04-05T13:04:01Z E! [inputs.snmp] Error in plugin: initializing field ethPortStatus: translating: SYNOLOGY-PORT-MIB::ethPortStatus.0: Unknown Object Identifier (Index out of range: 0 (ethPortIndex)): exit status 2 (pourtant la MIB correspondante a bien été préalablement recopiée dans "/usr/share/snmp/mibs/"). #---------------------------------------------------------- # Ethernet Ports SRM [[inputs.snmp.field]] name = "ethPortStatus" oid = ".1.3.6.1.4.1.6574.109.2" # oid = "SYNOLOGY-PORT-MIB::ethPortStatus.0" [[inputs.snmp.field]] name = "ethPortSpeed" oid = ".1.3.6.1.4.1.6574.109.3" # oid = "SYNOLOGY-PORT-MIB::ethPortSpeed.0" #---------------------------------------------------------- Aucun de deux types d'oid n'est reconnu 🥴 J'ai du raté quelque chose mais je ne vois pas quoi, une idée peut-être ? Cordialement oracle7😉

@forplatina Bonjour, Même si plus tard tu as la fibre, attention : augmenter la qualité d'image va faire "gonfler" démesurément tes flux vidéos et tu vas mettre à mal ton réseau local que tu risques de saturer sans parler de l'énorme volumétrie des fichiers d'enregistrement sur le NAS surtout si tu enregistres en continu. Si j'étais à ta place je resterai sur les résolutions sus-citées. C'est un bon compromis, crois-moi. Maintenant ce que j'en dis, tu restes dans tous les cas, maître de tes choix ... Cordialement oracle7😉

@forplatina Bonjour, Malheureusement NON et il n'y a pas à ma connaissance de fonction d'actualisation. Tout au mieux tu peux consulter la liste des caméra compatibles ici. Essaies à tout hasard en sélectionnant une caméra "approchante" telle que DS-2CD2083G0-I mais sans aucune garantie. Maintenant 2 modes de defifinition/FPS sont à mon humble avis suffisants : Le mode 1920x1080 pour affichage sur PC/Mac et le mode 640x480 pour l'affichage sur téléphone portable (pas la peine de mettre plus dans ce dernier cas, sinon tu n'auras pas assez de bande passante et elle sera vite saturée et donc affichage sacadé au mieux s'il y a affichage). Cordialement oracle7😉

@forplatina Bonjour, Je crains que ce ne soit pas parfois MAIS toujours ... Cordialement oracle7😉

@forplatina Bonjour, Sur la livebox il y a deux modes de visualisation des équipements : Dans le mode liste tu peux donner un nom à chaque équipement et tu retrouves ensuite ce nom dans par ex le popup équipement du bail statique DHCP ce qui est plus simple à l'usage et surtout plus parlant. Sinon quelle Livebox as-tu ? LB4 ou LB5 ? PS : Astuce : Pour avertir un membre de ta réponse, tu tapes dans ton message "@" + les premiers caractères de son pseudo. Dans le popup qui apparaît tu cliques alors sur le pseudo recherché et il s'affiche sur fond bleu dans ton texte. Ainsi ton interlocuteur est informé/notifié de ta réponse sinon il ne voit rien sauf à rebalayer en arrière tous les messages (ce que peu de monde fait). Cordialement oracle7😉

@forplatina Bonjour, J'avais oublié, il te faut aussi mettre à jour le firmware de la caméra en téléchargeant ici. Pour l'@IP : Tu la fixes d'une part avec l'outil SADT v3.0.4.5 disponible ici et tu y définis aussi le mode DHCP et ton MdP administrateur. Ensuite dans la Livebox tu définis un bail statique avec l'@MAC de la caméra sur la même @IP (qui doit être impérativement en dehors de la plage d'attribution automatique du DHCP par ex : 192.168.168.1.151 si la plage DHCP est 192.168.1.2 à 192.168.1.150). Cordialement oracle7😉

@forplatina Bonjour, Il te faut rester cohérent et mettre les mêmes réglages vidéo dans l'interface d'admin de la caméra ET dans Surveillance Station. Avec HIK il est aussi préférable de n'utiliser que les réglages vidéo fait dans l'interface d'admin. Dans SS, par contre tu gères tous le reste (et surtout la partie enregistrement qui est bien plus facile à gérer) sauf la définition des franchissements de lignes ou d'E/S dans une zone précise qui eux restent dans l'admin HIK. Donnes aussi une IP fixe à tes caméras. Cordialement oracle7😉