CoolRaoul

Je ne vois rien de choquant dans leurs arguments. Fermer le port 80 alors que le 443 est ouvert et que ce sont les mêmes services derrière ne me donne pas l'impression d'une meilleure sécurité. Il est exact que les connexions vers le serveur HTTP en TCP/80 ne sont pas chiffrées, mais si un pirate tente une attaque sur le port 80 c'est le traffic de *sa* session qui sera en clair. Mon approche perso est d'avoir un index.html bidon servi à la racine du serveur web. Ey pour toute les autres services disponibles sur mon NAS c'est le reverse proxy qui en gère les connexions, *uniquement* en https : Quant aux services natifs DSM que j'utilise (filestation, drivestation, videostation, etc ...), je les ai configurés dans le portail de connexion uniquement via un alias dédié pour chacun et aucun port pour accès direct. J'ai quand même activé la redirection automatique https=> http pour les ces services (même si pour la même raison que mentionnée au début de mon post je ne pense pas que ca crée la moindre faille de sécurité supplémentaire). Comme cette dernière ne s'applique pas au serveur WEB avec sa config de portail par défaut, Let's Encrypt n'a pas de problème pour renouveler les certificats

en effet j'avais bloqué l'acces au port 80 un moment ce qui bloque les renouvellements LE. Je vais tenter le renouvellement manuel je prefere. En cas de besoin de chercher des explications à un message ou un libellé sur internet ça me ramène beaucoup plus de réponses

Bonjour, Je m'aperçois que le certificat associé au domaine DDNS fourni par Synology a sa date d'expiration de couleur orange: Qui saurait me dire ce que cela signifie ? (peut-être aussi que c'était déjà le cas que je n'avais pas remarqué ? )

Je croyais le problème résolu et encore un fichier géré par Drive à 0 ce matin (encore un pdf)! Il me semble (sans en être sur à 100%) que c'est un fichier que j'avais marqué pour accès hors ligne dans l'application Android Drive Pas trouvé d'autres fichiers dans ce cas à priori après recherche en profondeur Selon l'historique HyperBackup ca c'est passé récemment (29/03/2024)

Voila alors c'est ca. Ca fait tellement longtemps que je n'avais pas touché à ca que j'avais oublié.

J'avance ... je parviens à me connecter depuis mon PC comme ceci mysql -u freshrss -h --password="" -P 3307 avec un tcpdump actif en ssh sur le NAS ("tcpdump -i any port 3307") je visualise bien le traffic dans ce cas Par contre en relançant la procédure de setup FreshRSS en docker, je ne vois rien passer, et même avec le Firewall désactivé!!! On dirait un problème de routage du container vers l'extérieur *** VICTOIRE *** [emoji324][emoji898][emoji898][emoji898] Pour une raison que je ne m'explique pas, MariaDB sur mon NAS était configuré pur utiliser le port 3307 au lieu du défaut (3306) Et le setup de FreshRSS en docker ne permet pas de le spécifier

Alors je découvre ceci https://docs.rackspace.com/docs/mysql-connect-to-your-database-remotely Avec cette remrque qui me laisse dubitatif Dans tous les systèmes que j'ai pratiqué dans la vie, un user c'est un user avec des droits de connexion un point c'est tout Vraiment de plus en plus bizarre Il existe depuis des lustres le compte "freshrss" et mon service web local marche depuis aussi longtemps mais c'est un fait que le serveur web se connecte à la DB en localhost, pas à distance

J'ai trouvé ça https://easyengine.io/tutorials/mysql/remote-access/ Déja je ne comprends pas pourquoi il faudrait modifier le mot de passe du compte cible ("IDENTIFIED BY 'PASSWORD'") juste pour lui donner le droit de se connecter depuis une IP donnée 🤔 En plus ça ne marche toujours pas

Celui ci : https://www.it-connect.fr/veille-technologique-installer-freshrss-sur-son-nas-synology Mais pour la partie DB il propose SQlite alors que je veux conserver ma database freshrss existante sous mariadb

réponse : ERROR 1133 (28000): Can't find any matching row in the user table le compte se nome 'freshrss' pas 'freshrss@machinbidule' C'est vraiment bizarre la syntaxe de mysql pour modifier les droits d'acces des comptes

En grattant un peu j'ai trouvé ceci : MariaDB [(none)]> GRANT ALL PRIVILEGES ON freshrss.* TO 'freshrss' HOST='n.p.q.r'; connexté "root" à mariadb en ligne de commande, où n.p.q.r est l'IP du container. Mais ça échoue avec l'erreur : ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'HOST='n.p.q.r'' at line 1 (Comme je l'ai précisé, je ne touche pas une bille en bases de données, ça ne m'aide pas)

J'ai tout repris à zero en utilisant une autre tuto (mais c'est pas fondalement différent) et toujours la même erreur : "Access to database is denied for `freshrss`: SQLSTATE[HY000] [2002] Connection refused" 🤬 Personne ne connait la commande pour autoriser les connexions à utilisateur mysql donné partir d'une IP spécifique ? @lordtaki semblait maitriser ça

et on s'y prend comment pour modifier les autorisations d'un compte dans MySQL ? (j(utilise phpMyAdmin pour l'administration) Evidemment puisque mon instance FreshRSS hébergée en direct sur le NAS fonctionne Ah je vais tester ça de suite je n'ai utilisé que des connexion locale jusqu'ici **** EDIT **** Ah non c'était déjà coché. A la réflexion le socket était en écoute sinon je ne pouvais pas me connecter même en localhost. La preuve : ~> sudo lsof -i :3307 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME mariadbd 18603 mysql 26u IPv4 131189062 0t0 TCP *:3307 (LISTEN) Et j'ai bien pensé à ajouter une règle dans le firewall pour autoriser les connexions entrantes en provenance de l'IP du container Docker

Bonjour Essayant de dépatouiller des problèmes sur mon service FreshRSS je tente d'en installer la version dockerisée en parallèle Je bute lors de la configuration initiale sur l'erreur : Access to database is denied for `freshrss`: SQLSTATE[HY000] [2002] Connection refused Pourtant je n'ai aucun doute sur le mot de passe mysql du le compte "freshhrss" (testé en ligne de commande avec mysql -u freshrss --password='<pass>') Je précise que je suis une vraie quiche en bases de données et MariaDB en particulier. Merci d'avance

ST4000VN006-3CW104 🫤 En effet. C'est plus le boulot pour restaurer qui me gonflerait si je me retrouve dans une situation similaire.