CyberFr

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.

Bonjour @marty1944000 et bienvenue sur le forum ! Je cherche encore ta signature, une omission sans doute 😀

Bienvenue sur le forum @Emmanuel Mayer III ! Le III indique que tu fais partie d'une dynastie ? 😀 Ce tutoriel est exactement ce que tu cherches.

Bienvenue sur le forum @Philippe49 ! Depuis que j'ai un NAS je ne sais plus ce que sont les GAFAM et à quoi ils servent 😀

Grace à la remarque de @Jeff777 je suis parvenu à rendre les DNS "dynamiques" de telle sorte qu'un changement de DNS au niveau de la Freebox soit répercuté au niveau du Mac après un redémarrage de celle-ci le cas échéant. Oui c'est possible car on peut définir des exceptions dans Firefox concernant DNS via HTTPS. J'ai donc entré les deux noms de domaine que je gère (sous la forme ndd.fr sans http:// ou https:// devant le nom de domaine) et ça marche, DNS Server sur le NAS est interrogé. En cas de problème je peux accéder à Freebox OS en indiquant une IP locale de type 192.168.1.254 qui ne nécessite pas de résolution DNS.

Hier, j'ai vérifié tous les endroits sur le réseau où l'on pouvait utiliser un serveur DNS de secours. Dans les réglages système du Mac. Dans les réglage réseau du NAS où j'ai supprimé le serveur DNS de remplacement. Dans Firefox où j'ai désactivé DNS via HTTPS. Mais décidément Vaultwarden me disait toujours que je m'étais connecté à partir de l'adresse 192.168.1.254 qui est celle de la Freebox. Sans rien changer j'ai refait le test ce matin et cette fois ci Vaultwarden me dit que je me suis connecté à partir de l'adresse 192.168.1.1 qui est celle du Mac sur le réseau ! La seule différence est que dans l'intervalle j'ai redémarré le Mac et le NAS et relancé Firefox. Il faut croire qu'un redémarrage est nécessaire quelque part dans le réseau pour que les changements soient pris en compte. Merci à @PiwiLAbruti et à @Jeff777 pour votre aide précieuse. Maintenant il me faut définir une alternative au cas où DNS Serveur serait indisponible. Parce que si le NAS tombe en panne il n'y a pas grand chose à faire ! Il suffit je pense de disposer d'une configuration de secours au niveau des DNS du Mac faisant appel à un fournisseur tiers comme quad9 ou autre et de basculer sur celle-ci en cas de problème. Cela fonctionnera même si le NAS tombe en panne. Il me faut désactiver "Configurer manuellement le serveur DNS" dans les réglages réseau du NAS (car j'ai saisi en dur l'adresse IP de DNS Serveur) afin que les DNS utilisés soient ceux définis au niveau du Mac. Dois-je réactiver DNS via HTTPS dans Firefox ? Parce que si on ne sait pas par où tu passes, on sait où tu arrives. Et surtout cela revient à court-circuiter DNS Server qui, pour le coup, perd beaucoup de son intérêt.

Je ne me serais pas attendu à trouver les serveurs DNS dans la rubrique DHCP. Quel rapport avec la choucroute ? 😀 Mais effectivement tu as raison. Lors de l'installation de la Freebox j'ai bien renseigné les DNS. Sur un Mac je n'ai rien trouvé qui permette cela malgré une première recherche sur Internet. Il faudra que j'approfondisse.

Il faut donc que je supprime le DNS de secours au niveau du Mac et éventuellement au niveau du NAS où il est défini comme serveur DNS de remplacement bien que dans ce dernier cas si le NAS tombe en panne ça ne change rien puisque j'envisage le cas ou le NAS est injoignable. Il faut aussi que je supprime le DNS via HTTPS défini dans Firefox puisqu'il pointe sur le serveur quad9. Par contre je n'ai trouvé aucun réglage DNS au niveau de la Freebox, impossible donc de modifier un paramètre par défaut.

C'est embêtant parce que sur mon Mac et sur la Freebox j'ai mis en priorité le serveur DNS du NAS et j'ai entré l'adresse d'un serveur quad9 de secours au cas où le NAS serait injoignable. Mais si arbitrairement le Mac et/ou la box utilisent le serveur de secours il ne me reste plus qu'à le supprimer de la liste.

Apparemment les disques provenant d'un ancien NAS lors d'une migration sont acceptés sans limitation sur les modèles 2025 et postérieurs. À vérifier quand-même.

Bienvenue sur le forum @TAMOLIS !

Un communiqué de presse en Allemagne alors que le siège de la société est à Taipei ? Bizarre, bizarre. Synology teste peut-être la réaction de ses utilisateurs.

Bonjour @Ricov Ricov. Tu n'es pas le seul à habiter en Belgique et il y a plein de participants au forum qui vivent dans l'écosystème Apple. Bienvenue !