.Shad.

Bienvenue parmi nous !

Bienvenue parmi nous !

A ma connaissance, Photo Station (et l'indexation de manière générale) ne fonctionne que sur des dossiers partagés natifs du système.

Alors en effet c'est une fonctionnalité supplémentaire (l'ajout de cadres). Je ne sais pas quelle mouche a piqué les développeurs.

Ok je n'ai jamais utilisé cette fonction (même jamais vu en fait). Ça marche comment ? PS analyse les photos et propose des visages à nommer comme Moments et Synology Photos ?

Non ils parlent de la détection faciale automatique. Pas de l'identification manuelle via des tags. Ça n'a jamais existé dans Photo Station. Je n'ai pas trouvé de solutions, si un visage est non identifié il le restera j'ai l'impression.

Oui, la box belge Proximus ne permet pas de s'en passer, sauf si tu es fibré et sans abonnement TV, ce qui n'est doublement pas mon cas. Sur le pare-feu, sur un port j'ai 3 sous-réseaux différents (trusted, guest et iot) que je sépare en jouant sur les VLAN des switchs. Sur un autre j'ai un sous-réseau avec mes VM. Tout est connecté aux switchs, le principal étant non PoE, et sur le PoE j'ai mis mes 3 bornes. L'UDM est sûrement un bon produit, un peu cher, mais intégré et rackable, c'est pas mal. Tu peux très facilement créer une VM pfSense ou autre pour tester le logiciel dans un premier temps voir si ça te convient. On n'en parle pas assez mais Mikrotik fait aussi de très bons produits routeurs et switchs (particulièrement pour le 10Gbe).

Le meilleur compromis que j'ai trouvé est un pare-feu type pfSense (ça peut être OPNSense, IPFire, DD-WRT, ce que tu veux...) sur lequel tu peux à peu près tout faire (et ce n'est pas une usine à gaz contrairement à la croyance populaire) couplé avec Ubiquity (mais ils ne sont pas le seuls à faire du bon matos wifi) pour la distribution aux réseaux sans fil. Pour les switch j'utilise des D-Link, ils ont un excellent rapport qualité-prix. Alors ils n'ont pas une belle UI comme Ubiquity, mais ils font parfaitement le job et sont increvables.

SWAG et Nginx Proxy Manager sont deux logiciels différents. SWAG n'offre pas d'interface comme NPM, mais embarque tout un lot de fonctionnalités en plus de Nginx. Il y a moyen de faire en sorte que SWAG utilise le certificat d'acme.sh, c'est ce que je fais sur mon VPS. Pour faire cohabiter DNS Server et un autre serveur/résolveur DNS, il faut utiliser le pilote macvlan (le conteneur aura une IP de ton réseau local, dès lors il n'y aura pas de conflit de port avec le NAS car pas de NAT entre le conteneur et l'hôte). Tu trouveras plus d'info sur le pilote macvlan dans mon tutoriel en signature.

Non, c'est juste de la CLI, et Alpine c'est vraiment le minimum du minimum. CentOS c'est déjà un peu plus packagé.

Bienvenue eau sauvage !

CentOS 7 ou Alpine, entre autres.

Pas à ma connaissance. Fouille pour voir. 🙂

Mes fichiers docker-compose sont sur un dépôt privé. Portainer crée les conteneurs à partir de ces fichiers. Il peut poll le dépôt toutes les X minutes pour vérifier s'il y a une modification, et recrée le conteneur si oui. Ou alors tu peux faire en sorte que GitHub avertisse ton instance Portainer qu'un fichier a été modifié et il recrée le conteneur ad hoc. Mais dans ce dernier cas le géo-blocage empêchait GitHub de contacter Portainer. Donc j'ai utilisé la solution du polling.

@MilesTEG1 En effet bien vu. J'éditerai ça prochainement en même temps que l'ajout d'un paragraphe sur l'utilisation conjointe de Portainer et GitHub.

Les jumbo frames sont prises en charge par SMB 3 à ma connaissance.

Bienvenue parmi nous !

Pour l'instant je n'ai fait les tests que via WiFi. Les clients invités se connectent sur une de mes bornes, ces bornes sont reliées aux ports d'un switch administrable, qui sépare mes différents réseaux par tag VLAN. Ce switch est relié au pare-feu, qui fait aussi serveur DHCP et distribue les IP aux clients qui en demandent. Tests que je pourrais conduire : Voir si un client filaire peut contacter un client WiFi. Voir si en passant en adressage statique sur un client et en supprimant la passerelle, j'arrive à contacter d'autres clients invités.

Autrement dit, le trafic local n'ayant pas besoin d'être routé, la passerelle n'est pas utilisée. D'accord avec toi sur le principe, c'est ce que je pensais intuitivement, mais par exemple j'ai configuré les règles qui suivent pour mon réseau filaire/wifi invité : La ligne que j'ai mise en évidence empêche aux clients tout accès local hormis ce qui a été autorisé par avant, et aussi à son propre sous-réseau. Aucun client de mon réseau invité ne peut ping ou accéder à un autre client. Pourtant ils sont sur le même sous-réseau et avec le même masque. Si je mets une règle autorisant cette communication en amont, les invités peuvent se voir.

Je me permets de t'interroger là-dessus. Je ne sais pas ce qu'il en est du RT, mais ça m'interpelle, avec pfSense (défini en passerelle sur chaque périphérique) je peux totalement contrôler, au sein d'un même sous-réseau, qui communique avec qui, comment, etc... Mais j'imagine que c'est parce que le pare-feu est défini comme passerelle si je comprends bien tes propos ? En gros si j'enlevais l'IP du pare-feu en passerelle, chaque appareil pourrait communiquer avec son voisin de sous-réseau (en ne tenant pas compte des éventuels pare-feux logiciels de chaque périphérique) ?

Ok, donc ce n'est pas pertinent dans ce cas. Quand tu résous publiquement, wnt.ndd.com comme ndd.com pointent vers ton IP publique. C'est ton seul point d'entrée en IPv4, c'est normal. Localement, vu que tu as créé une zone DNS locale, il faut que les périphériques qui vont utiliser des noms de domaine pour communiquer entre eux utilisent par défaut ton NAS comme serveur DNS. Il faut donc que le serveur DHCP du réseau 192.168.50.0 envoie à ses client comme DNS primaire l'IP du NAS. A partir de ce moment-là, les périphériques en question interrogeront le NAS, qui aura une réponse à leur apporter pour la résolution de ndd.com, wnt.ndd.com et tes autres domaines. Sans avoir besoin de rediriger ça vers des serveurs publiques. Si tu résous publiquement tes URL, c'est normal de tomber sur le NAS dans tous les cas, car wnt.ndd.com comme ndd.com pointent tous deux vers la même IP publique. De là le NAS regarde quel port est sollicité, et si tu as redirigé le port 8813 vers ton NAS depuis ton routeur ou ta box, tu n'arriveras jamais sur la VM. Si seule la VM est sensée être accessible sur ce port, tu peux rediriger ce port vers la VM plutôt que le NAS, mais seulement si tu es amené à communiquer à distance avec ton broker MQTT. Si pas besoin, il faut carrément supprimer la redirection de port, car ça n'a probablement aucune vocation à sortir de ton réseau local.

Tout dépend comment tu résous les URL, localement ou publiquement ? Si depuis PowerShell (ou autre terminal de ton PC, mac, etc..) tu tapes : nslookup ndd.com Est-ce que le serveur qui répond (les deux premières lignes du retour de la commande) est bien ton NAS ?

Bienvenue !

Bienvenue parmi nous !

Tu peux mettre une impression d'écran de ta zone DNS ?