oracle7 Posté(e) le 8 août 2021 Partager Posté(e) le 8 août 2021 @.Shad. Bonjour, j'ai remplacé successivement "localhost" par l'@IP du NAS 192.168.2.10 puis par l'@IP du conteneur 172.21.0.2 dans PHOTOPRISM_SITE_URL . Aucune des deux ne fonctionne. J'ai essayé avec le reverse proxy : https://photovideo.ndd.tld 443 HSTS HTTP/2 --> http://@IPNAS:2342. Marche pas non plus (Synology page introuvable). OUI, les deux fichiers secret sont bien sur le NAS (peut-être pas les bons droits ?) Cordialement oracle7😉 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
.Shad. Posté(e) le 9 août 2021 Partager Posté(e) le 9 août 2021 Il y a 10 heures, oracle7 a dit : time="2021-08-08T22:40:41+02:00" level=fatal msg="dial tcp 192.168.2.10:3307: connect: connection timed out" Tu as toujours ce message ? a priori timed out implique qu'il n'y a pas de problème de pare-feu, sinon tu aurais connection refused. On part plutôt sur une IP inaccessible ou un service qui ne répond pas. Il y a 9 heures, oracle7 a dit : OUI, les deux fichiers secret sont bien sur le NAS (peut-être pas les bons droits ?) Je ne vois pas pourquoi tu as deux propriétaires différents pour les deux fichiers, ça aurait du sens en terme de confidentialité s'il n'y avait pas de permissions de groupe, là on ne les voit pas apparaître. Mais je ne pense pas du tout que ce soit la source du problème. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
oracle7 Posté(e) le 9 août 2021 Partager Posté(e) le 9 août 2021 @.Shad. Bonjour, Oui j'ai toujours le message de "timed out". Dans le pare-feu du NAS j'autorise les @IP 172.16.0.0/255.240.0.0 donc l'@IP du conteneur est bien accessible et en plus elle répond bien au ping. Avec ta remarque sur "un service qui ne répond pas", du coup j'ai arrêté le package Mariadb10 et je l'ai relancé. Là j'ai eu une alerte du pare-feu du NAS me demandant d'ouvrir le port 3307. J'avais effectivement supprimée cette règle il y a quelques temps pour mettre à plat mon pare-feu. Je l'ai donc recréée en la limitant à la France. Mais a priori cela n'a pas eut d'impact. Donc ce ne serait pas ce service qui ne répond pas. Pour les fichiers secret, j'avais effectivement omis un chown. Ils ont maintenant tous les deux "photoprism" comme propriétaire. Mais ne devraient-ils pas avoir plutôt mon utilisateur admin oracle7 comme propriétaire ? Je me demande ... Je tester pour voir. Pour les permissions de groupe, j'ai appliqué un chmod 660 comme dans ton TUTO Authelia. Cordialement oracle7😉 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
.Shad. Posté(e) le 9 août 2021 Partager Posté(e) le 9 août 2021 il y a 30 minutes, oracle7 a dit : Avec ta remarque sur "un service qui ne répond pas", du coup j'ai arrêté le package Mariadb10 et je l'ai relancé. Là j'ai eu une alerte du pare-feu du NAS me demandant d'ouvrir le port 3307. J'avais effectivement supprimée cette règle il y a quelques temps pour mettre à plat mon pare-feu. Je l'ai donc recréée en la limitant à la France. Ca c'est si tu souhaites ouvrir le port 3307 à distance, ce n'est pas ton cas ici. Quand tu installes un paquet DSM, il propose toujours d'ouvrir les ports adéquats dans le pare-feu, à refuser si c'est pour une application locale et que tu as par ailleurs des règles couvrant la communication en local. Je n'ai pas plus d'explication que ça pour justifier le timeout, hormis un problème d'accessibilité. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
oracle7 Posté(e) le 9 août 2021 Partager Posté(e) le 9 août 2021 @.Shad. Bonjour, Pour le pare-feu, c'est vrai que je n'ai pas besoin d'un accès externe à MariaDB. J'ai donc re désactiver la règle. SInon, c'est bien un problème d'accessibilité qui bloque tout. J'ai beau chercher sur la toile, je ne trouve par d'exemples de cas similaires : connexion d'un conteneur docker à une BD mysql externe. Je cherche peut-être mal mais c'est quasiment tout le temps des connexions conteneur docker à une DB déclarée en service dans le même conteneur que l'on trouve. C'est rageant !😟 Dans PHPmyadmin j'ai remarqué que toutes mes BD étaient en interclassement utf8_general_ci et quand je regarde le paramétrage du service MariaDB (dans l'ex initial) lorsque on utilise une image MariaDB directement dans le même conteneur, on a les paramètres suivants : "--character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci". D'après toi cela pourrait-il jouer dans le cas présent ? Si je bascule le serveur MariaDB sur ces paramètres, cela ne risque-t-il pas de perturber mes autres bases ? Cordialement oracle7😉 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
.Shad. Posté(e) le 9 août 2021 Partager Posté(e) le 9 août 2021 il y a 37 minutes, oracle7 a dit : J'ai beau chercher sur la toile, je ne trouve par d'exemples de cas similaires : connexion d'un conteneur docker à une BD mysql externe. Je cherche peut-être mal mais c'est quasiment tout le temps des connexions conteneur docker à une DB déclarée en service dans le même conteneur que l'on trouve. C'est rageant !😟 Ca ne change rien ça, je fais constamment des liaisons conteneur-mysql(NAS) sans problème. Possible que ce soit lié à l'encodage, tu ne peux pas modifier ces paramètres juste pour la base de données photoprism plutôt que pour toutes les bases de données ? Sinon tu passes par un conteneur MariaDB, surtout si c'est juste pour tester dans un premier temps, faut pas s'embêter. 😄 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Rejoindre la conversation
Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.