CyberFr

C'est bien pour cela que je l'utilise en effet. Suite à ma réflexion sur Swag et Nginx Proxy Manager, j'ai régressé parce que, lorsque il y a plusieurs années, j'ai mis en place DNS Server, les choses étaient claires. Je reçois donc une piqure de rappel qui les clarifie à nouveau. Merci. Mais la question initiale (j'ai modifié le titre en conséquence) reste en suspens. Est-ce que ça vaut la peine de basculer du reverse-proxy intégré de DSM vers Nginx Proxy Manager ? Y gagne-t-on quelque chose ?

Merci pour ce rappel salutaire parce que je ne comprenais pas comment, en aval du serveur DNS, les en-têtes pouvaient être transmis 👍 Ce qui m'a troublé, c'est que les applications dont il est question dans le titre font à la fois serveur DNS et reverse-proxy. Je dis ça parce qu'elles attendent sur le port 443 une requête du type calendar.ndd.fr et qu'elles la redirige correctement. À tel point, si j'ai bien compris, que le port 443 ne doit plus être redirigé par le routeur ou la box internet vers le port local du NAS mais vers leur propre port local. Ce qui veut dire que le serveur DNS de DSM est court-circuité sauf s'il est possible de créer des exceptions au niveau de ces applications.

Certes mais si on crée un site Web c'est pour qu'il soit accessible de l'extérieur et donc consultable par tout le monde, non ?

Errare humanum est, perseverare diabolicum. Tu as sans doute raison mais comment tout cela s'articule ? Quel est le chemin suivi entre la requête initiale et sa résolution qui fait intervenir à la fois la résolution DNS et le proxy inversé ? L'un et l'autre se trouvent où dans le chemin ? J'utilise systématiquement un proxy inversé pour les applications Synology et les autres ce qui m'évite de me compliquer la vie quand la situation évolue parce que j'applique toujours la même démarche.

Je sous-entendais que DNS Server ne servirait plus à rien en cas d'utilisation de Swag ou de Nginx Proxy Manager. Parce que ces derniers écoutent sur le port 443 des requêtes du type https://calendar.ndd.fr qu'ils transforment en http://localhost:port. À quoi servirait alors DNS Server ? Actuellement, chez moi, DNS Server est couplé au portail de connexion. J'utilise les deux. Et je n'utilise pas le portail de connexion uniquement pour les applications intégrées. J'utilise systématiquement un reverse-proxy. J'ai toujours une entrée définie dans le certificat Let's Encrypt, par exemple calendar.ndd.fr. Pour être clair je n'utilise jamais la partie "Applications" du Portail de connexion mais systématiquement la partie "Avancé" dans laquelle je définis les proxys inversés..

C'est ce que je fais en complément de DNS Server. Mais effectivement j'ai mélangé reverse-proxy et serveur DNS parce que je considérais à tort qu'ils étaient imbriqués. Lorsque je crée une nouvelle entrée dans le reverse-proxy (HTTPS calendar.ndd.fr --> localhost:port), celle-ci doit être traitée dans DNS Server (calendar.ndd.fr --> ns.ndd.fr) d'où ma confusion. Je reformule donc la question en tenant compte de mon erreur : des outils comme Swag ou Nginx Proxy Manager apportent-ils un plus par rapport au proxy inversé de DSM ? Le fait que DNS Server ne serve plus à rien est-il un recul ?

Bonjour, J'ai échoué à mettre en œuvre le tuto sur Swag à cause d'un sombre problème de certificats SSL qu'il installe lors du premier lancement mais ne trouve plus par la suite. Je me rabats donc sur Nginx Proxy Manager. La question que je me pose est toute simple. Des solutions comme celles que j'ai citées apportent-elles un vrai plus par rapport à DNS Server que j'utilise par ailleurs ?

@segeorg, je te recommande vivement la lecture du tuto suivant. Mais aussi de passer par le forum PRESENTATION. Cela permet de mieux connaître ton environnement et ton niveau de connaissances et donc de mieux t'aider.

Bonjour @osnetworking en bienvenue sur le forum. Il est vivement recommandé, avant de poser des questions, de passer par le forum PRÉSENTATION. On saura ainsi quelle est ta configuration matérielle et ton niveau de connaissance. À ta place je remplacerais le mot SSL par celui de certificat (ou certificat SSL) pour que tout le monde comprenne la même chose en te lisant. Comment as-tu généré le certificat ? En passant par la gestion des certificats dans DSM ? Tu devrais, dans ton espace client Free, sous la rubrique Ma Freebox, demander une adresse IP v4 full-stack afin de disposer de tous les ports.

Qui sait, il existe peut-être l'équivalent ou mieux. Dans un marché hyper concurrentiel il vaut mieux ne pas s'endormir sur ses lauriers...

Je suis finalement parvenu à supprimer l'API d'OVH que j'avais créée ce qui n'est pas évident car l'URL n'est pas liée au compte chez OVH. J'ai appliqué les instructions figurant dans le tuto et la génération des clés s'est bien passée. J'ai modifié le fichier de config afin de ne pas le compliquer avec les subdomains. # # ╔═══════════════╗ # ║ S W A G ║ # ╚═══════════════╝ # services: swag: image: linuxserver/swag container_name: swag networks: macvlan_net: ipv4_address: 192.168.1.145 cap_add: - NET_ADMIN environment: - PUID=1027 - PGID=101 - TZ=Europe/Paris - URL=attuly.fr - SUBDOMAINS=wildcard - VALIDATION=dns - CERTPROVIDER=ovh - DNSPLUGIN=ovh - DHLEVEL=2048 - EMAIL=attuly@free.fr - ONLY_SUBDOMAINS=false - STAGING=false volumes: - /volume1/docker/swag/config:/config labels: - com.centurylinklabs.watchtower.enable=true restart: unless-stopped networks: macvlan_net: external: true Je signale au passage que lorsque j'ai fait docker-compose up -d j'ai eu droit à un "permisssion denied". Je me suis donc logué en root et le conteneur a été lancé. J'ai par contre un message d'erreur dans les logs. Or j'ai supprimé puis recréé les API d'OVH pour être sûr qu'elles soient correctes. Le fichier de log à /config/log/letsencrypt/letsencrypt.log n'est pas plus explicite. Le tuto indique dans le chapitre 8-D. Création du conteneur « Normalement à ce stade vous disposez d'un certificat fonctionnel dans /volume1/docker/swag/config/keys/letsencrypt. ». Chez moi les certificats cert.crt et cert.key se trouvent dans /volume1/docker/swag/config/keys.

La concurrence ne tarde pas à s’engouffrer dans la brèche ouverte par Synology 😀

Une petite parenthèse juridique. Synology risque d'être confronté au droit européen de la concurrence du fait qu'ils imposent leur marque de disques au détriment d'autres fabricants comme Western Digital ou Seagate. Les juges risquent de ne pas apprécier, d'autant plus que la Commission Européenne est très stricte en matière de respect de la concurrence. La restriction de la compatibilité chez Synology permettrait également à la marque d'augmenter le prix de ses disques à l'avenir s'il n'y a plus de concurrents ce qui, une fois de plus, les exposerait à des jugements antitrust. Et la Commission Européenne ne plaisante pas sur le sujet. À titre d'exemple elle a condamné en novembre 2024 Meta (maison mère de Facebook) à une amende de 800 millions d'euros pour violation des règles antitrust dans l'affaire Facebook Marketplace. Elle a aussi condamné Google à une amende de 2,42 milliards d’euros pour pratique anticoncurrentielle en septembre 2024. Elle a condamné en avril dernier Apple et Meta à respectivement à 500 millions d'euros et 200 millions d'euros d'amende. Synology risque d'être condamné aussi par l'Autorité de la concurrence en France parce que la marque impose une vente subordonnée qui sera alors considérée comme une pratique interdite. Sans compter qu'il pourrait y avoir une condamnation venant des autorités de la concurrence américaine que sont la a Federal Trade Commission et la division antitrust du Department of Justice. Sauf à subir de lourdes amendes et à être attaqué devant les tribunaux par les fabricants de disques concurrents, Synology sera obligé de créer une liste de compatibilité ouverte à d'autres constructeurs et faire disparaître les avertissements et autres limitations qu'ils imposent dans DSM. En attendant ils se comportent comme une PME dépourvue d'avocats. Si on ajoute à cela le mécontentement de leurs clients, on peut dire qu'ils ont créé une situation de crise qui risque de les faire tomber de leur piédestal.

Après la création du container j'ai constaté qu'une erreur apparaissait dans le log de Swag. J'ai donc tenté de recréer les API d'OVH mais j'ai droit à "Error: Application already exists". Puis-je supprimer l'existant ? Ou le modifier ?

Trouvé sur le site LDLC, un argument imparable en faveur des disques de la marque 😀

Apple a commis la même erreur en son temps à savoir vendre cher un écosystème performant mais fermé. À l'époque la marque était bien implantée dans le domaine de la PAO et un titre comme Libération par exemple en était équipé. Résultat, les professionnels ont fui. L'écosystème est certes lucratif, merci à l'iPhone et à l'iPad, mais c'est devenu un créneau de niche.

@.Shad., je suis parvenu à déployer le stack dans Portainer et une fois de plus le problème se situait entre la chaise et le clavier... J'ai créé le réseau macvlan dans Portainer (pourquoi donc s'embêter à suivre les instructions du tuto ? 😀) et j'ai omis de préciser le driver. J'ai donc recréé le réseau en SSH avec un driver macvlan et maintenant ça marche. Le container est déployé et l'état est "Running". Maintenant, la principale question que je me pose est comment faire cohabiter DNS Server et Swag, je vais donc avancer dans le tuto pour trouver une réponse.

Ça fait peur ! Je parie que les tests SMART seront à nouveau présents sur les disques propriétaires compatibles.

Pas vraiment. Merci @.Shad. pour ton aide. J'ai créé le réseau en suivant les instructions du tuto mais je n'ai pas eu l'occasion de tester s'il fonctionne correctement. Je n'ai pas reçu d'e-mail d'avertissement pour le script.

Erreurs de débutant quoi 👎 Le PUID est en effet 1027 et le PGID 101. Ce sont les miens sur le NAS. J'ai un domaine en ndd.fr et un autre en access.cyberfr.fr, le dernier étant défini lors du renouvellement du certificat comme un autre nom de l'objet au niveau de DSM, il ne fait pas partie du domaine racine. J'avais ajouté CERTPROVIDER mais je ne trouve pas de trace de PROPAGATION dans le lien que tu donnes. services: swag: image: linuxserver/swag container_name: swag cap_add: # en prévision d'une utilisation de fail2ban - NET_ADMIN networks: macvlan_net: ipv4_address: 192.168.1.145 volumes: - /volume1/docker/swag/config:/config environment: - PUID=1027 - PGID=101 - TZ=Europe/Paris - URL=ndd.fr - SUBDOMAINS=www,calendar,homepage,etc - VALIDATION=dns - CERTPROVIDER=ovh # par défaut - DNSPLUGIN=ovh - EMAIL=cyberfr@free.fr #facultatif pour OVH - ONLY_SUBDOMAINS=false # optional - EXTRA_DOMAINS=access.cyberfr.fr - STAGING=false # optional restart: unless-stopped networks: macvlan_net: external: true Ce fichier de config provoque l'erreur : Je dois être chat noir !

Bonjour, J'essaye de mettre en place le tuto mais je reste bloqué dans les starting-blocks parce que le fichier compose.yaml n'est pas accepté. Des erreurs sont détectées, aussi bien par Portainer que par Container Manager. Plus étonnant encore, lorsque dans Portainer, je déploie le même stack avec le même fichier compose.yaml deux fois de suite, l'erreur détectée est différente. J'ai soumis le fichier à deux validateurs YAML distincts qui ne détectent aucune erreur. J'ai vérifié le fichier qui ne comporte aucune tabulation ni aucun caractère parasite. J'en viens à me demander s'il ne faudrait pas que je réinstalle Container Manager. C'est pourquoi je vous soumets le fichier, si vous repérez des erreurs de syntaxe n'hésitez-pas à me le dire. Merci par avance. # # ╔═══════════════╗ # ║ S W A G ║ # ╚═══════════════╝ # version: "2.1" services: swag: image: linuxserver/swag container_name: swag cap_add: # en prévision d'une utilisation de fail2ban - NET_ADMIN networks: - macvlan_net: ipv4_address: 192.168.1.145 volumes: - /volume1/docker/swag/config:/config environment: - PUID=100 - PGID=101 - TZ=Europe/Paris - URL=ndd.fr - SUBDOMAINS=www,calendar,homepage,etc - VALIDATION=dns - CERTPROVIDER=ovh # par défaut - DNSPLUGIN=ovh - EMAIL=cyberfr@free.fr #facultatif pour OVH - ONLY_SUBDOMAINS=false # optional - EXTRA_DOMAINS=access.cyberfr.fr - STAGING=false # optional restart: unless-stopped networks: macvlan_net: external: name: macvlan_net

Je n'ai pas constaté cela, j'ai ressenti au contraire que DNS Server accélérait les requêtes. Il est vrai que pour chaque entrée dans DNS Server il existe un enregistrement CNAME correspondant chez mon registar (OVH).

Bienvenue sur le forum @Marie-Antoinette ! Et n'hésite pas à parcourir les tutoriels qui sont une mine d'information.

Oui d'après ce que j'ai lu. Reste à savoir quels sont les modèles équivalents chez le constructeur.

Jusqu'au jour où ils tombent en panne parce qu'après il faut s'équiper de disques Synology.