darkneo

Je vais aller poser la question, mais j'ai la notification dans l'interface DSM, c'est ça qui me surprend aussi.... 🤔

Hello et merci pour le retour. Voilà le mail. Apparemment ça vient de surveillance station (certainement aussi pour ça que je le vois pas ban l'ip)

Bonjour à tous! Cela fait un moment que je n'étais pas passé; et je viens encore pour une "inquiétude". Cela fait 2j que je reçois un mail m'indiquant que mon compte admin est protégé... Alors que je l'ai désactivé dans DSM! Est ce que je dois m'inquiéter de ce genre de notification ou sont elles 'normales' et le compte est effectivement bien désactivé?

Suite au message de @Mic13710 sur un autre thread, j'ai finalement abandonné l'idée de remettre mon OpenVPN d'équerre avec mon certificat LE. J'ai donc : - Désactivé OpenVPN sur DSM - Généré un nouveau certificat autosigné avec Easy RSA - copié les fichier dans /volume1/... et modifié le .ovpn serveur pour lui indiquer les chemins des fichiers (je sais clairement pas si ca a servi a qqc) - Importé dans les certificat DSM (ca.crt, private key server et crt serveur) puis configurer VPN server pour utiliser ce nouveau certificat - Réactivé OpenVPN dans DSM Et hop, tout refonctionne (en ayant bien sur updaté la partie cliente pour utiliser les crt et key configuré pour le client). Je vous poste un lien qui m'a beaucoup orienté (car j'ai adapté quelques trucs mais les grandes lignes sont OK): https://tavenier.org/synology-nas-with-openvpn-with-client-certificate/

Je pense que c'est ce que je vais faire, car je trouve en plus pas mal de forum (en anglais) qui semblent dire que les certificats LE sont incompatibles avec certaines fonctionnalités d'OpenVPN (j'ai pas tout bien compris...). Concernant l'édit du fichier de conf, le "problème" c'est que je n'ai pas les fichiers CRT, PEM, et KEY... Donc il faudrait que je les génère... Donc autant tout refaire au propre avec un autosigné via easy RSA, ce qui me permettra en plus de pouvoir faire des clés pour chaque client que je veux utiliser! Merci pour l'info 👍

Hello à tous! Je viens poster ici car je pense qu'être passé sur la version Docker depuis l'ancien script basique a mis la pagaille dans ma config OpenVPN. J'ai posté un thread dédié ici: Pour faire court, j'ai l'impression qu'OpenVPN utilise encore l'ancienne version de mon certificat (qui a expiré) et j'aimerai m'assurer de pouvoir demander l'utilisation du nouveau certificat (mais du coup quels fichier utiliser?). Merci d'avance pour votre aide EDIT: A priori c'est confirmé, même en changeant le certificat dans l'interface Admin, le paquet VPN Server ne semble pas se mettre a jour correctement: https://serverfault.com/questions/1117955/how-to-use-public-certificates-with-openvpn-on-synology-dsm Du coup, obligé de passer par un easy RSA? ou de complètement désinstaller VPN Server pour le remettre?

Hello! Personne n'aurait une idée? Car je continue d'essayer de résoudre le problème et je tiens peut etre une piste... Ce soucis est apparu quand j'utilisais l'ancien script de renouvellement ACME (en local sur le syno). Suite aux différentes évolutions de Let's Encrypt, je suis passé sur la version docker d'Acme pour le renouvellement du certificat. Et je me dis que le soucis vient très certaintement de là! Dans la config serveur l'openvpn, il utilise les fihciers suivants: dh /var/packages/VPNCenter/target/etc/openvpn/keys/dh3072.pem ca /var/packages/VPNCenter/target/etc/openvpn/keys/ca.crt cert /var/packages/VPNCenter/target/etc/openvpn/keys/server.crt key /var/packages/VPNCenter/target/etc/openvpn/keys/server.key dh /var/packages/VPNCenter/target/etc/openvpn/keys/dh3072.pem ca /var/packages/VPNCenter/target/etc/openvpn/keys/ca.crt cert /var/packages/VPNCenter/target/etc/openvpn/keys/server.crt key /var/packages/VPNCenter/target/etc/openvpn/keys/server.key Sauf que je pense que ces fichiers sont ceux de l'ancien script Acme. Avec la version docker, les fichiers se trouvent dans /volume1/docker/Acme/DOMAIN Je suis pas sur de mon coup, et je vois pas du tout comment avancer maintenant... Car dans ce dossier (/volume1/docker/Acme/DOMAIN), je n'ai ni fichier crt, ni fichier key, je n'ai que des csr: Une idée de commencer remplacer les certificat sur le serveur par ceux du docker Acme?

Hello à tous, Pour bien commencer l'année, je me prends la tête avec ma configuration VPN qui ne fonctionne plus... 😞 J'ai eu des soucis (voir sur un autre post) avec les certificats Let's Encrypt, donc j'ai tout refait, et tout reconfiguré (d'ailleurs pour info, ma demande de merge a été acceptée, donc le soucis LE pour le deploiement auto devrait être corrigé sous peu). Sauf que, depuis que j'ai mon nouveau certificat... Mon client VPN ne fonctionne plus 🤪 J'ai l'erreur suivante: Ce que j'ai tenté: - de base: export de la config VPN Server dans le zip, extraction, modification du fichier .ovpn pour y mettre mon DNS, même erreur - ajout des balises <cert> et <key> dans le fichier .ovpn, toujours la même erreur - comparaison du contenu de la balise <ca> avec mon chain.pem: il y a un bloc de plus dans le fichier .ovpn, mais si je le supprime, l'erreur change en me disant qu'il n'arrive pas à identifier le signataire du certificat Ce que j'ai vérifié: - le port est correctement ouvert dans le routeur. - J'ai vérifié le numéro de série du ca.cert, ce n'est pas le même que celui de l'erreur🤨 l'erreur me dit serial=1234567890 alors que dans le certificat j'ai un format hex (je pense, ca ressemble à un truc du genre 00912b09ef2394c) J'ai aussi essayé de récupérer directement les certificats depuis le dossier de mon docker via file station, même erreur... Autre point etrange: dans l'application VPN serveur, les connections sont bien affichées dans "Liste de connexion" avec mon ip, mais j'ai autant de session que mon paramètre max (5 en l'occurence) avec utilisateur à UNDEF Une idée de l'origine de ce blocage (je pense problème de certificat, mais pourquoi? et comment le changer?!) Merci d'avance pour votre aide! EDIT: J'ai oublié de préciser que les certificats téléchargés depuis l'app VPN server sont valides jusqu'en Sept 2025 (ca.crt et ca_bundle.crt) Par contre j'ai aussi l'impression que ce n'est pas le bon certificat qu'OpenVPN utilise, vu qu'il m'affiche ISRG Root X1 dans le certificat, alors que dans les logs il semble parler de DST Root CA X3.... c'est normal?

Pas tout à fait... Le Device ID (dans la version actuelle) est récupéré dans une réponse HTML (ligne 138 du code actuel) response=$(_get "$_base_url/webapi/$api_path?api=SYNO.API.Auth&version=$api_version&method=login&format=sid&account=$encoded_username&passwd=$encoded_password&otp_code=$otp_code&enable_syno_token=yes&enable_device_token=yes&device_name=$SYNO_Device_Name") Or, dans ma réponse, je n'ai pas de champ 'did' ou 'device_id', donc la variable reste systématiquement vide... (soit dit en passant, en plus, elle est totalement inutile car elle n'est pas nécessaire dans les HTML suivantes!) id_property='device_id' [ "${api_version}" -gt '6' ] || id_property='did' SYNO_Device_ID=$(echo "$response" | grep "$id_property" | sed -n 's/.*"'$id_property'" *: *"\([^"]*\).*/\1/p') _secure_debug2 SYNO_Device_ID "$SYNO_Device_ID"

Très certainement... Car en Septembre mon renew c'était fait sans soucis, et celui de Décembre était fail (et évidemment j'avais désactivé les notifications, donc je m'en suis aperçu car plus aucune service VPN, remote DSM etc ne fonctionnait). J'ai fait les propositions de modif dans le Github, on verra si elles sont acceptées, car pour le logout sur DSM 6, il faut utiliser auth.cgi (et non entry.cgi), et j'ai aussi rajouté le SID pour ne tuer que la connection initiée pour le renouvellement du certificat, ce qui me donne: [Fri Dec 22 13:57:37 UTC 2023] url='http://1.1.1.1:5000/webapi/auth.cgi?api=SYNO.API.Auth&version=6&method=logout&_sid=4oM5l6ohX206YB3J4N01003' [Fri Dec 22 13:57:37 UTC 2023] timeout= [Fri Dec 22 13:57:37 UTC 2023] curl exists=0 [Fri Dec 22 13:57:37 UTC 2023] mktemp exists=0 [Fri Dec 22 13:57:38 UTC 2023] wget exists=0 [Fri Dec 22 13:57:38 UTC 2023] _CURL='curl --silent --dump-header /acme.sh/http.header -L --trace-ascii /tmp/tmp.iuYADzae9v -g ' [Fri Dec 22 13:57:38 UTC 2023] ret='0' [Fri Dec 22 13:57:38 UTC 2023] response='{"success":true}' [Fri Dec 22 13:57:38 UTC 2023] Success En attendant, j'ai aussi passé l'autoupdate à 0 pour éviter toute prochaine déconvenue tant que la modification n'est pas acceptée/commitée. Et pour info, sans forcément passer par un SSH distant, depuis DSM, on peut aller dans l'interface du container pour lancer une commande custom, taper /bin/sh, ce qui ouvre un terminal directement dans le container (/bin/bash ne fonctionne pas car non installé dans le container).

Oui pas faux, mais entre mon NDD, les login/pwd et les ip parfois publiques... Bref.... Et non, je n'ai pas activé l'OTP sur mon NAS, mais a force de debug (et de recontruction d'URL), c'est la requpete qui est censée me retourner le Device ID qui ne le fait pas (dans la réponse, il n'y a pas le champ attendu). Certainement car je suis encore sur la version 6 de DSM (pour raison purement domotique, la version 7 et + ayant supprimer des drivers USB pour le RFXCom par exemple). EDIT: Je vais essayer de tester de plusieurs façon... Mais est ce que je peux techniquement changer un fichier dans un container sans passer par SSH... Car j'avoue ne jamais l'avoir fait (et je n'i qu'un accès remote à mon NAS, le remote SSH n'étant pas activé). EDIT2: Mon premier test a finalement été le bon.. Et le plus simple! J'ai rajouté un paramètre SAVED_SYNO_Device_ID dans le fichier de conf, et tout s'est déroulé... Presque sans encombre! A la fin, j'ai la fonction de logout qui ne fonctionne pas et me retourne un code 102... Je suppose que ce n'est pas aussi simple en DSM 6, il va falloir que je creuse

J'ai mis localhost pour obfusquer les logs (c'est vrai que j'aurai pu mettre autre chose...) mais en vrai j'ai bien la bonne ip... Pour preuve le SessionID et le Syno Token sont bien renseignés (avec localhost, ils auraient été vides 😉 ) J'ai report sur Github le soucis qui, je pense, est du à un mauvais if: if [ -z "$SYNO_DID" ] && [ -z "$SYNO_Device_ID" ] || [ -z "$sid" ] || [ -z "$token" ]; then Dans mon cas SYNO_DID et SYNO_Device_ID sont tous les 2 vides, vu que je n'utilise pas le 2 authentication factor, donc je rentre toujours dans cette loop.... car la requete ligne 138 ne me retourne jamais de Device ID.... 😞

Hello a tous, Ayant (encore) des problèmes avec mon renewal, j'ai décidé de franchir le pas de la version docker.. Mais je me retrouve avec exactement le même soucis: Impossible de se logguer pour enregistrer les certificats dans la dernière étape... Quand je lance la commande j'ai l'erreur: Le user n'a pas de Two factor authentication.... Et j'ai exactement la même erreur avec mon ancien script acme-renew.py.... Des hooks ont été changés pour le prendre que le two factor authent? Edit: En regardant un peu plus les logs... C'est étrange car il me trouve pourtant bien les sessionID & Compagnie, mais me dit qu'il n'arrive pas d'authentifier..... :0

Hello et merci pour le retour, Je viens de vérifier et cette option n'est pas activée... Donc ce n'est pas ça. malheureusement... Pour un peu plus de détail, dans la fenêtre du panneau de configuration, c'est les infos de mises à jour de DSM qui sont affichées (si jamais...)

Bonjour à tous, J'espère que vous allez tous bien depuis le temps? Une fois n'est pas coutume, je viens encore pour une question certainement très stupide: j'aimerai savoir comment désactiver l'ouverture de la fenêtre du panneau de configuration a chaque connexion? Car je me connecte souvent depuis des tablettes, etc et cette fenêtre, en plus de ne me servir a rien, n'est jamais correctement framé et ca me soule a chaque fois de devoir la fermer 😅 Merci d'avance pour votre aide!

Hello, Etrange ton soucis, car personnellement je n'ai pas eu ce message d'erreur... Et j'ai bien les date au form avec le Z a la fin... Par contre je suis confronté à un blocage un peu différent... J'ai mon réseau internet qui était down (alors que la boucle locale était OK). le script de rnew a donc certainement été lancé et a du tomber en échec car impossible de joindre LE (car évidemment depuis le temps je ne garde plus les logs). Sauf que le script a mis à jour les date de renouvellement de certificat, et que maintenant je me retrouve avec: - Un certificat expiré - un script de renew qui me dit qu'il n'est pas nécessaire de renouveller le certificat... J'ai essayé de changer la date dans le fichier conf, mais cela ne fonctionne pas. J'ai essayé de forcer le renouvellement via -f dans le script de renew, mais ca ne fonctionne pas non plus... De mon côté cela plutôt etre l'url de renouvellement des certificat du synology qui ne fonctionne plus: Quand je tape l'url, j'ai un page JSON qui m'affiche juste EDIT: Je ne sais pas comment tu as démarré tes investigations, mais dans mon cas le soucis a déjà été identifié: https://github.com/acmesh-official/acme.sh/issues/4721 La question c'est maintenant... Comment je reviens à la version 3.0.6 et comment je desactive l'autoupdate... 🙂 EDIT2: Pour ceux qui auraient le soucis, il faut passer le autoupdate dans account.conf à 0

Pohhh... Ben heureusement que tu me l'as dit... Clairement je n'étais pas du tout parti sur un package a arréter.. Un coup de stop, et effectivement, plus rien n'est visible! Merci beaucoup!!

Hello à tous! Requête un peu particulière, vu que d'habitude on cherche plutôt à faire l'inverse... Mais je viens de brancher ma BOX TV et je me suis aperçu que le media center voyait tous les contenus de Music/Photos/Videos de mon DSM vu qu'ils sont tous deux connectés à mon réseaux local. Ca me plait moyen que ces fichiers (perso) trainent aussi facilement sur mon réseau local sans aucune demande d'authentification.. Du coup j'aimerai savoir comment les bloquer. J'ai testé de : - desactiver SMB, mais toujours présent. - désactiver NFS, mais toujours présent. - rajouter 2 options sur les dossiers partagés visibles (genre sur video), mais toujours présent... Je sais pas trop sur quelle autre option je pourrais faire la modif... Donc toute aide serait la bienvenue. Merci d'avance pour votre aide.

OMFG... Dans le doute, reboot.... Le seul truc que je n'avais pas reboot dans toute cette histoire, c'est DSM... Je vien de le faire... Tout est revenu dans l'ordre.... 😤

Je l'ai fait directement en interface Docker... en téléchargeant l'image depuis le registre et en l'initiant..... Mais ce qui est bizarre, c'est que quand je le débranche, il me sort bien une erreur "com" en me disant que le device n'est plus branché.... Error: RFXCOM: Error opening serial port! Status: RFXCOM: retrying in 30 seconds... Et pour info, je viens de faire un test en installant un Domoticz from scratch sur un raspberry et en restorant ma BD... Je n'ai pas le problème... Donc je pense qu'il se situe bien quelque part sur le syno/docker....

Je réponds à moi même pour apporter quelques précisions: Quand je lance un lsusb en root sur le syno, le RFXCom est reconnu (à priori - je vous copie la commande en -v): Bus 002 Device 013: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO) Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0403 Future Technology Devices International, Ltd idProduct 0x6015 Bridge(I2C/SPI/UART/FIFO) bcdDevice 10.00 iManufacturer 1 RFXCOM iProduct 2 RFXtrx433XL iSerial 3 DO44D8ZO bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 90mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 2 RFXtrx433XL Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x0000 (Bus Powered) Donc à priori ca ne semble pas être un problème de drivers... Pourtant quand je lance les commandes trouvées ca et là concernant les drivers usbserial.ko via modeprobe, voici le retour: Sur le container: root@domoticz-domoticz1:/dev# /sbin/modprobe usbserial modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/3.10.102/modules.d ep.bin' modprobe: FATAL: Module usbserial not found in directory /lib/modules/3.10.102 Sur le syno en direct, cela ne m'affiche aucun resultat... Du coup, je me dis que c'est peut etre des drivers manquant dans le container Domoticz, nan? Ou on peut trouver les fichiers usbserial.ko, etc? Ou est ce que je fais fausse route?

Bonjour à tous, Ca faisait longtemps que je n'étais pas passer pour un problème que je n'arrive pas à résoudre... En fait, depuis quelques jours (voire semaines), j'ai mon RFXCom qui se crashe dans Domoticz (sans raison apparente, je n'ai rien fait sur mes configurations). Domoticz tourne sous un container Docker, via le paquet DSM qui va bien. J'ai fait pas mal de tests avec d'autres install de Domoticz (sur Windows) et mon RFXCom n'a pas de soucis. Par contre, dès que j'ai une instance sous Docker, j'ai le plantage (Invalid Data Received). En dernier recours, j'ai changé le cable, mais rien n'y fait. Ce qui m'interpelle, c'est que sous Domoticz, je n'ai que 2 connexions USB: /dev/ttyUSB0 et /dev/ttyACM0. Par contre quand je lance un lsusb sur mon container, je n'ai pas du tout ces infos: Dans le doute, j'ai voulu faire le "tricks" concernant les problèmes USB de DSM7 sur mon OS, mais cela ne fonctionne pas (https://mariushosting.com/synology-how-to-add-usb-support-on-dsm-7/ car il manque des binaires dans mon kernel en 6.2). Une idée sur l'origine du soucis, et surtout sur comment fixer ca? Merci d'avance pour votre aide

Celle que j'ai mis dans mon premier post, la linuxserver: https://registry.hub.docker.com/r/linuxserver/domoticz/

Hello, En dernier espoir, j'ai tenté hier dans créer un container avec l'autre image Domoticz en version 2022.2: https://registry.hub.docker.com/r/domoticz/domoticz/ Et ben ca a fonctionné direct, sans aucun soucis... 😅 Donc je pense que mon problème est plus liée à l'image utilisée (même si je ne m'explique pas pourquoi cela ne veut pas tourner alors que tout semble correct). Merci pour les pistes en tout cas, si jamais cela peut servir à d'autres... Même si on n'a pas trouvé la root cause...

Hello à vous deux et merci pour vos retours. Je vous confirme que ce n'est pas le package python de DSM que j'ai installé (enfin si, mais en l'occurrence je pense qu'il n'y est effectivement pour rien comme le dit @Lelolo), mais bien le package sur mon container (en utilisant l'invite de commande dans la GUI Docker de DSM - les commandes que j'ai mis dans le premier post ont été lancées sur mon container via la GUI de Docker). J'ai modifié mon premier post pour respecter le template @.Shad. (désolé... 😕 )