.Shad.

Nouvelle fonctionnalité sympathique du côté de Bitwarden => Bitwarden Send, pour envoyer de manière sécurisée du texte ou des fichiers, avec expiration ou non, protection par mot de passe, etc... Bien foutu 🙂

On va dire tant mieux. 😄

Dans la documentation ils mettent des quotes pour les variables de l'adresse du serveur et le token, ainsi que le / à la fin de l'adresse : https://containrrr.dev/watchtower/notifications/

Je ne suis pas sûr que ces messages aient un rapport avec Gotify, je l'utilise et rien n'apparaît dans les logs du conteneur à ce sujet. Je pense qu'il y a une erreur dans les variables d'environnement que tu as ajoutées pour Gotify, tu peux c/c ton docker-compose ?

Salut et bienvenue parmi nous ! C'est bien de voir que tu as déjà anticipé ton besoin, ça va permettre d'aller droit au but. La première chose c'est qu'actuellement sache que sur la gestion de photothèque personne n'approche la sophistication de Google Photos en terme d'intégration et d'efficacité. La bonne nouvelle c'est que la solution Synology est une des meilleures solutions auto-hébergées, si ce n'est la meilleure (j'en ai testé pléthore) actuellement. Donc si effectivement le rapatriement des données est un point important pour toi, tu fais le bon choix. Concernant les modèles que tu envisages, il n'y aura aucun problème pour la synchronisation des calendriers et l'accès aux photos, le processeur n'est quasiment pas sollicité pour ce genre de choses, c'est la bande passante qui aura éventuellement une importance pour la consultation distante de votre bibliothèque photos. Pour Synology Drive, même remarque, ça roulera. En revanche, avec ces modèles, tu n'auras pas la reconnaissance faciale disponible sur Moments, ce qui peut être une vraie lacune si on a précédemment eu sa bibliothèque chez Google. Elle n'est pas aussi aboutie que celle du GAFA mais elle reste solide et efficace. La liste des modèles compatibles : https://www.synology.com/en-global/knowledgebase/DSM/tutorial/Multimedia/Which_Synology_NAS_models_support_the_image_recognition_feature_on_Moments Comme tu le vois ce sont les modèles "haut-de-gamme" qui la prennent en charge, ou modèle "+". A titre personnel, je te conseille, quitte à économiser encore un peu, de partir vers un modèle comme le DS218+ ou DS220+, ce sont de très belles machines qui permettent la conteneurisation et la virtualisation, tu pourrais très bien à terme prendre conscience de tout ce qu'un serveur personnel a à offrir, et la frustration sera grande si tu n'as pas un modèle +. Et bon réflexe pour la sauvegarde, à toi de voir si tu veux de la redondance (continuité de services) ou pas ? Si oui, il te faudra 2 * 2To, pour 2 To utilisables. Sinon un seul disque dur de 2 To dans un premier temps pourra suffira. Attention que 2 To ça se remplit très vite. 😉

Ton certificat s'est renouvelé, R3 c'est normal, c'est le nouveau nom de l'autorité qui délivre les certificats. Essaie de réexporter le certificat depuis le panneau d'administration d'OpenVPN dans VPN Server, et sers-t-en pour te connecter depuis ton client, pour vérifier que ça fonctionne.

Est-ce que si tu connectes un PC en direct sur le NAS, avec son serveur DHCP activé, tu obtiens bien une IP (ton PC étant en configuration automatique) ?

C'est exactement ce que j'avais et ça n'a pas empêché les plantages de mon côté. Après vu la masse de personnes utilisant le cache et n'ayant pas de problèmes, c'était peut-être un problème avec mon NAS, je ne sais pas. Je suis arrivé à cette conclusion il y a quelques temps. En me faisant mon serveur en aparté, j'ai supprimé bon nombre de limitations que j'avais autrefois avec tout sur le NAS. Et ca ne consomme pas forcément beaucoup. J'ai mon pare-feu + modem + DS118 + DS918 + Serveur Debian => en idle je suis à 60W sur l'ensemble, 80-90W si stream sur Emby avec transcodage.

Quand j'avais mon cache SSD (2 * 250 Go Samsung 970), j'ai eu par deux fois ce type de plantage, mais il me proposait systématiquement de reconstruire le RAID. Et niveau RAM j'avais 2 * 4 Go de la marque Synology, donc on pouvait mettre l'incompatibilité ou la sur-capacité de mémoire de côté. J'ai arrêté les frais en enlevant les SSD et en les utilisant plus tard dans mon serveur Debian. Ils fonctionnent H24 depuis 8 mois pour l'instant, aucun problème à signaler, aucune erreur. Donc a priori les disques n'étaient pas en cause. Vu que de toute façon le NAS ne me sert quasi que de stockage, le SSD n'a pas grande utilité pour moi.

Perso je fais mes câbles mâle en 568B ça marche bien !

Perso si j'attendais qu'une application ait nativement f2b + 2fa avant de l'exposer, je ne pourrais pas me servir de grand chose hors de chez moi, et c'est surtout là que je trouve un intérêt à avoir un serveur à la maison. Ou alors je devrais demander à toute ma famille d'avoir un VPN 😄 Difficile d'expliquer ça à mes parents. 🤔 Quoiqu'il en soit je t'ai dit je pense que DSM intègre un proxy inversé très satisfaisant out-of-the-box, si tu souhaites étendre les fonctionnalités disponibles pour les applications natives de DSM à d'autres applications via Docker ou VMM, tu es vite limité, d'où l'intérêt de SWAG. Le tutoriel est là, les gens l'appliquent ou pas peu me chaut, je sais très bien qu'il répond à un besoin très spécifique (que DSM ne permet pas) et en conséquence j'aide @MilesTEG1

Et si vraiment on veut se servir de l'oauth de Synology, c'est ultra pas intuitif, voir ici : https://medium.com/@4c.dmnk/take-control-over-synologys-oauth-service-f96114be3707 Tu oublies les notifications Push ou SMS, et personnellement utiliser mon compte Synology pour me log ailleurs, ça me ferait peur.

Que dit l'erreur exactement ?

Oui sans problème. La copie ça va être dans l'optique où tu n'as pas de proxy inversé et un certificat dont tu souhaites absolument te servir pour accéder à Bitwarden.

@Einsteinium Tout ce que tu cites là est déjà intégré à DSM 6, rien de nouveau sous le soleil et de toute évidence il donne entière satisfaction pour l'ultra majorité des utilisations. Nulle part j'ai décrié son fonctionnement, il est relativement complet et très stable/fiable. Le seul reproche que je fais au proxy inversé de DSM c'est la difficulté de modifier la configuration d'Nginx, par exemple pour y intégrer la redirection HTTP vers HTTPS. Devoir passer par un script via Apache pour le faire est vraiment dommage. Tu évoques le paquet oauth 2.0, as-tu pris le temps de lire ce que ça permettait de faire ? Ça n'a strictement rien à voir avec ce que propose Authelia. Oauth sur DSM permet d'utiliser son compte Synology pour accéder à certaines ressources comme Amazon Echo. Authelia permet d'activer la 2FA ou des notifications push sur smartphone pour te connecter sur n'importe quelle application que tu hébergerais. Tu peux ajouter et ajuster les couches de sécurité pour ton homelab à l'envi. Et tu ne parles pas du fail2ban, disponible sur DSM que pour les applications natives. Il n'y a aucun souci à préférer une autre solution, j'en propose juste une qui, après en avoir testé plusieurs autres (Haproxy, DSM, Traefik), me semble de loin la plus efficace et facile de configuration.

La lecture des tutoriels devrait déjà te permettre de mettre le pied à l'étrier. Bienvenue !!

Sans problème. Ca fait l'inverse. Authelia te permet de différencier l'accès à une ressource en fonction du chemin après le domaine. Chez moi, j'accède à phpMyAdmin par ds918-services.ndd.ovh/phpMyAdmin, et Authelia sait qu'il doit me demander une authentification 2FA pour l'autoriser, même en local (parce que je l'ai configuré ainsi), tandis que ds918-services.ndd.ovh/photo est accessible depuis n'importe quelle source, locale ou distante. Sans rentrer dans les détails, si je faisais un rewrite de l'URL il serait plus difficile de différencier le comportement d'un service par rapport à l'autre. Ca je crois que tu devras essayer, c'est trop vague. SWAG est un proxy inversé comme un autre, pourquoi ça ne marcherait pas ? 😉 SWAG ne vient en rien corriger des problèmes avec le proxy inversé de DSM, qui est très bien comme ça et pour 99% des utilisateurs, mais limité si on veut pousser un peu plus loin. SWAG est une solution complète autonome qui intègre la prise en charge de la 2FA à la demande pour les applications qu'on héberge, le fail2ban, et le redirection HTTP -> HTTPS via Nginx au lieu d'Apache (mais ça tu le sais déjà).

Je crois que les développeurs cobol s'arrachent à prix d'or dans pas mal d'entreprises. 😛 Bienvenue parmi nous !

Si tu accèdes à l'interface Drive, pas de problème évidemment tu passes par le proxy inversé de SWAG. Pour la synchronisation des données via le client PC par exemple, il faudra utiliser un nom de domaine dont le certificat est dans DSM. Je vois pas comment être plus clair, je ne sais plus comment le tourner. 😛 Le "Synology Drive Server" que tu vois dans mon impression d'écran correspond au service de synchronisation de données, pas l'interface de Drive. Les quatres sont "reverse proxiables", donc ça ne pose aucun problème... J'ai cherché cinq minutes sur Google : https://www.digitalocean.com/community/questions/nginx-seamless-redirect-subdomain-subfolder Après si tu comptes utiliser Authelia, ta redirection t'embêtera plus qu'autre chose, mais tu fais comme tu veux.

Bah euhhh... d'où l'utilisation du ndd Synology pour être tranquille. Au passage tu confonds synchronisation des données de Drive et interface de Drive. C'est comme confondre le port par lequel Download Station ferait du partage BitTorrent et l'interface de Download Station. Plex et DSM sont reverse proxiables donc pris en charge par SWAG. Voir l'impression d'écran de mon certificat Synology pour les services intrinsèques à DSM pour lequel il faut un certificat dans DSM directement. Sûrement, faudra que tu cherches un peu, je laisse le /photos derrière personnellement car je m'en sers dans Authelia pour différencier l'accès à phpMyAdmin et Photo Station, tous les deux sur les ports 80/443 du NAS.

Oui Oui, après faut pas croire que ça apporte de la sécurité, personne ne t'attaquerait avec un nom de domaine. C'est l'IP qui intéresse les bots. Avec un certificat wildcard, tu valides ndd.tld et *.ndd.tld, donc si tu ajoutes un nouveau service pour lequel tu veux un accès par nom de domaine publique, tu n'as pas à recréer de certificats, il est déjà pris en charge par *.ndd.tld C'est un choix personnel, SWAG te permet d'obtenir un certificat que tu peux très bien exporter dans ton NAS et importer via l'interface DSM. Ce n'est pas comme acme.sh qui permet de faire le déploiement. Vu que certains services sont liés à DSM et ne peuvent pas passer par le proxy inversé (Synchro données port 6690 pour Drive, même chose pour Hyper Backup et Active Backup for Business), si je veux utiliser le même certificat que celui utilisé dans SWAG, je dois importer dans DSM ce certificat et configurer les services sus mentionnés pour qu'ils l'utilisent. C'est fastidieux. Du coup, j'utilise l'interface DSM pour générer un certificat wildcard pour mon domaine gratuit Synology (DSM ne le permet que pour ses noms de domaine, d'où les tutos acme.sh pour les autres ndd), et je m'assure que les services Synology non déportables utilisent ce certificat : Tu peux aussi utiliser acme.sh pour utiliser un certificat pour le même domaine et le déployer automatiquement dans DSM. C'est juste que ce seront deux certificats distincts, ça ne gêne en rien. 😉 Quand tu crées un certificat wildcard Synology, donc identifiant.synology.me et *.identifiant.synology.me, la validation passe par la zone DNS de ton domaine hébergée par Synology, tu n'as besoin d'ouvrir aucun port, tu es juste le demandeur, tu n'es pas dans la boucle de vérification. Quand tu valides les domaines manuellement (ta méthode actuellement), LE vient vérifier un fichier à la racine de ton serveur web pour vérifier l'authenticité de la demande, il le fait par le port 80. Si par exemple tu as juste une adresse associée à un domaine, pour un site web par exemple (donc généralement ndd.tld et www.ndd.tld), je ne vois pas spécialement l'intérêt d'avoir une validation par DNS. Le wildcard est intéressant si tu as plusieurs sous-domaines. Pour que la validation DNS soit possible, il faut que l'hébergeur de ta zone DNS mette une API à disposition d'acme.sh (ou certbot par exemple dans le cas de SWAG), tous les hébergeurs ne le font pas, dans ce cas-là il faut soit ajouter les enregistrements acme-challenge manuellement, soit passer par une validation HTTP. Tu peux l'enlever, je mettrai à jour le tutoriel. Note que ça n'empêchera pas le bon fonctionnement, ce sera justement sûrement plus pris en compte lors de la création du conteneur. Tu ne t'en serviras plus, c'est Nginx dans SWAG qui gèrera ça (par défaut c'est activé, il y a moyen de le désactiver, mais pas vraiment de bonne raison de le faire). Merci de te lancer en tout cas, ça va permettre de voir où les explications sont insuffisantes (je note le manque de numérotation des paragraphes 😛).

@MilesTEG1 Moi je l'ai laissé, mais tu peux sûrement réduire, c'est histoire d'être sûr que l'interface physique est opérationnelle. Tu n'as qu'à faire l'essai sans la temporisation voir si ça pose problème ou non.

Pas de souci, voir ce post pour le lien avec ton erreur je pense : https://github.com/larsks/blog.oddbit.com/issues/3#issuecomment-612187561

@MilesTEG1 Pour ton problème concernant l'erreur RTLINK, essaie justement comme tu le proposes avec 192.168.2.208/28, ça te donnera une range de 209 à ... Chez moi, j'utilise la plage 192.168.100.160, ça commence aussi à 161 jusqu'à ... Et du coup tu mettras 209 pour SWAG par exemple, pour ne pas laisser d'IP non utilisée en début de pool du sous-réseau macvlan.

Si tu as autorisé qu'une seule IP dans ton sous-réseau macvlan, c'est normal que tu ne puisses pas y ajouter un nouveau conteneur. Tu peux essayer de supprimer ton réseau macvlan, et retenter de créer avec un /30 au lieu de /28 pour l'ip-range, voir si ça change quelque chose. Une interface physique ne peut avoir qu'un seul réseau macvlan qui lui est rattaché. Ou alors tu utilises un autre port RJ45 de ton NAS. Tu n'as pas une interface virtuelle par conteneur, tous les conteneurs macvlan utilisent la même IP virtuelle pour communiquer avec le NAS. Pour ça je te conseille de chercher sur Google, c'est pas spécialement ce qu'il y a de plus fun. C'est du calcul, et les calculateurs sont là pour ça. Fais-leur confiance. Pour le broadcasting, pas sûr que ça t'aide, c'est l'adresse de diffusion réservée sur un sous-réseau. Dans ton réseau local, c'est 192.168.2.255 https://en.wikipedia.org/wiki/Broadcast_address