.Shad. Posté(e) le 23 mai 2020 Auteur Partager Posté(e) le 23 mai 2020 (modifié) Salut, merci de ton retour 🙂 Concrètement cela signifie que le NAS ne pourra pas joindre le conteneur, et vice-versa. Si tu es en SSH sur le NAS, tu peux ping le conteneur il te répondra destination injoignable. Pareil si tu te connectes au conteneur et que tu ping le NAS sur son IP locale. Donc ton problème vient sûrement de là. Pour contourner ce problème on va créer une nouvelle interface, équivalente à eth0, sur laquelle le NAS pourra être joint, une 2ème porte d'entrée si tu préfères par laquelle les conteneurs en macvlan pourront communiquer avec le NAS. ip link add <nom_interface_macvlan> link <interface_physique> type macvlan mode bridge ip addr add <IP_virtuelle>/32 dev <nom_interface_macvlan> ip link set dev <nom_interface_macvlan> address <adresse_MAC> ip link set <nom_interface_macvlan> up ip route add <Plage_DHCP_réseau_macvlan> dev <nom_interface_macvlan> Il ne te reste plus qu'à adapter les variables à ton utilisation. Tu pourras renseigner <IP_virtuelle>:3000 pour joindre ton NAS. NOTE : pour le nom_interface_macvlan, tu peux choisir choisir ce que tu veux. Pour l'IP_virtuelle, choisir évidemment une IP en dehors de la plage réseau du serveur DHCP de ta box/routeur. Pour l'adresse_MAC, prends-une au hasard, tant qu'elle n'existe pas déjà sur ton réseau. Enfin la plage_DHCP_réseau_macvlan est celle qui a été définie lors de la création de ton réseau. Par exemple : 192.168.132.0/24 Comme dit dans le tutoriel, cette interface disparaît au prochain redémarrage, libre à toi de créer une tâche dans le planificateur pour exécuter ces commandes au démarrage. Modifié le 23 mai 2020 par .Shad. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Phenix21 Posté(e) le 23 mai 2020 Partager Posté(e) le 23 mai 2020 (modifié) Ca marche, je testerai demain en rentrant ! Je te tiens au courant des résultats 😉 , merci Edit suite à tests J'ai voulu configurer une ip "secours" en 192.168.0.220, pour une ip de base du NAS en 192.168.0.20, sur le macvlan_dsm. Par ailleurs j'ai un macvlan_pihole qui héberge le pihole ainsi que quelques autres conteneurs. La procédure se passe correctement, mais j'ai 2 soucis dans le lance le ifconfig : d'une part je ne retrouve nulle part le macvlan_pihole d'autre part le macvlan_dsm se trouve avec l'ip .200 (ou lieu du .220). Est ce que à tout hasard ce serait une mauvaise config de mon macvlan_pihole (cf extrait du docker-compose ci dessous pour zigbee2mqtt, avec un ip figée dans la définition du service) services: zigbee2mqtt: networks: pihole_network: ipv4_address: 192.168.0.206 networks: pihole_network: driver: macvlan driver_opts: parent: ovs_eth0 ipam: config: - subnet: 192.168.0.0/24 C'est con, je pensais galérer pour faire reconnaitre la clé zigbee par zigbee2mqtt, mais c'est le lien zigbee-mqtt que je n'arrive pas à monter ^^ Merci d'avance si tu as quelques minutes pour moi ! Bonne soirée Nota : pour le calculateur je suis passé par ce lien en français, c'était plus clair pour moi 😁 Modifié le 24 mai 2020 par Phenix21 Test mise en place 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
bruno78 Posté(e) le 28 mai 2020 Partager Posté(e) le 28 mai 2020 Bonjour, peux-tu stp donner la définition complète du reseau pihole_network ? (subnet / gateway / ip_range) ? en fait c'est l'ensemble de tes déclarations de reseaux et de services qui pourraient nous aider à trouver où est le bug .... Merci 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
.Shad. Posté(e) le 29 mai 2020 Auteur Partager Posté(e) le 29 mai 2020 (modifié) Salut, J'ai l'impression que tu confonds le réseau macvlan (macvlan_pihole par exemple), pour lequel tu définis un sous-réseau, un gateway et un range IP sur lequel il sera actif. Et l'interface virtuelle que tu crées sur ton NAS pour communiquer avec les conteneurs dans ce réseau macvlan. Pour afficher l'interface tu sais faire vu l'impression d'écran. Pour afficher les données du réseau, tu tapes : docker network inspect macvlan_pihole (ajouter sudo si pas en root) Modifié le 29 mai 2020 par .Shad. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
aware Posté(e) le 30 mai 2020 Partager Posté(e) le 30 mai 2020 (modifié) Hello Merci pour ce tuto (jeedom). Mais j'ai un problème, au lancement à la création du conteneur jeedom-v4. Il redémarre en boucle. Dans le journal, j'ai : /root/init.sh: 2: /root/init.sh: : not found /root/init.sh: 4: /root/init.sh: : not found /root/init.sh: 7: /root/init.sh: Syntax error: Bad fd number (le not found n'apparait pas visuellement, mais en copier/coller) J'ai fait un copier/coller du init.sh, j'ai vérifié c'est identique au tuto. Je l'ai placé dans /volume1/docker/jeedom-v4/install/OS_specific/Docker/init.sh Une idée du problème ? Edit : Bon j'ai repris les dernières étapes et l'install et en cours. J'ai dû faire une boulette quelque part. Modifié le 30 mai 2020 par aware 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Phenix21 Posté(e) le 30 mai 2020 Partager Posté(e) le 30 mai 2020 Le 29/05/2020 à 10:33, .Shad. a dit : Salut, J'ai l'impression que tu confonds le réseau macvlan (macvlan_pihole par exemple), pour lequel tu définis un sous-réseau, un gateway et un range IP sur lequel il sera actif. Et l'interface virtuelle que tu crées sur ton NAS pour communiquer avec les conteneurs dans ce réseau macvlan. Pour afficher l'interface tu sais faire vu l'impression d'écran. Pour afficher les données du réseau, tu tapes : docker network inspect macvlan_pihole (ajouter sudo si pas en root) Le 28/05/2020 à 08:39, bruno78 a dit : Bonjour, peux-tu stp donner la définition complète du reseau pihole_network ? (subnet / gateway / ip_range) ? en fait c'est l'ensemble de tes déclarations de reseaux et de services qui pourraient nous aider à trouver où est le bug .... Merci Bonsoir ! Désolé, je n'avais pas vu vos retours. Je vous envoie les infos demain ou lundi. Entre temps, j'ai contourné le problème en passant tout sous le même macvlan ^^ Bonne soirée ! 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
aware Posté(e) le 30 mai 2020 Partager Posté(e) le 30 mai 2020 Re bonjour Je me permets une question concernant Jeedom sur Docker en réseau macvlan. J'héberge d'autres conteneur, en mode bridge par exemple. Ensuite, je crée un cname sur mon domaine, puis un proxy inversé côté Synology dans le portail des applications, et je termine par un certificat let's encrypt. Du coup j'ai accès à tous mes services de l'extérieur, en sous-domaine, avec certificat, par exemple bitwarden.mondomaine.com Concernant Jeedom en macvlan, je me retrouve avec une autre adresse ip, du coup le proxy inversé ne fonctionne pas côté Synology. une idée comment contourner ça, ou c'est mort à cause du réseau macvlan ? 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
.Shad. Posté(e) le 30 mai 2020 Auteur Partager Posté(e) le 30 mai 2020 (modifié) Tu as essayé de créer une interface virtuelle (comme à la fin du tutoriel) ? EDIT : Après réflexion je ne vois pas pourquoi le fait que le NAS n'arrive pas à communiquer avec le conteneur pourrait poser problème pour le proxy inversé. Et tu devrais pouvoir résoudre le problème avec l'astuce de l'interface virtuelle. Modifié le 30 mai 2020 par .Shad. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
aware Posté(e) le 30 mai 2020 Partager Posté(e) le 30 mai 2020 Je suis parti avec le nouveau tuto, qui ne parlait pas de l'interface virtuelle. Et quand je faisais le proxy inversé, je tombais sur la page Synology : Sorry, the page you are looking for is not found Du coup j'ai regardé le tuto "obsolète", et appliqué le routage IP, ça fonctionne. Merci ! 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Phenix21 Posté(e) le 1 juin 2020 Partager Posté(e) le 1 juin 2020 Bonjour ! De retour pour les infos Le 28/05/2020 à 08:39, bruno78 a dit : Bonjour, peux-tu stp donner la définition complète du reseau pihole_network ? (subnet / gateway / ip_range) ? en fait c'est l'ensemble de tes déclarations de reseaux et de services qui pourraient nous aider à trouver où est le bug .... Merci Ci dessous la définition du réseau pihole_network tel qu'enregistrée dans mes docker-compose : networks: pihole_network: driver: macvlan driver_opts: parent: ovs_eth0 ipam: config: - subnet: 192.168.0.0/24 Je n'y ai pas défini ni passerelle ni ip_range. Chaque conteneur fait ensuite l'objet d'une attribution d'ip fixe avec le paramètre suivant : networks: pihole_network: ipv4_address: 192.168.0.XXX où XXX est un valeur fixée dans une plage que je me suis réservée pour tous les maclan. Le DHCP du réseau est hors de cette plage là pour éviter les conflits d'IP. Ca fonctionne plutôt bien, aujourd'hui j'ai plusieurs conteneurs (pihole, HA, nodered, zigbee2mtt, mosquitto, ...) qui tournent de cette manière et sont accessibles via leurs IP respectives. Ces conteneurs communiquent entre eux sans souci également Le 29/05/2020 à 10:33, .Shad. a dit : Salut, J'ai l'impression que tu confonds le réseau macvlan (macvlan_pihole par exemple), pour lequel tu définis un sous-réseau, un gateway et un range IP sur lequel il sera actif. Et l'interface virtuelle que tu crées sur ton NAS pour communiquer avec les conteneurs dans ce réseau macvlan. Pour afficher l'interface tu sais faire vu l'impression d'écran. Pour afficher les données du réseau, tu tapes : docker network inspect macvlan_pihole (ajouter sudo si pas en root) Je n'ai pas recréé le réseau au reboot. Voilà ce que me donne l'inspect : ash-4.3# docker network inspect docker_pihole_network [ { "Name": "docker_pihole_network", "Id": "09ca946f83e7b991c2fb63678fafa48ba19598dfbe14507a94996e66136c0eb8", "Created": "2019-09-28T16:26:25.638250549+02:00", "Scope": "local", "Driver": "macvlan", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": null, "Config": [ { "Subnet": "192.168.0.0/24", "IPRange": "192.168.1.192/28", "Gateway": "192.168.0.1" } ] }, "Internal": false, "Attachable": false, "Ingress": false, "ConfigFrom": { "Network": "" }, "ConfigOnly": false, "Containers": { "a3d22349f394487fa497997a13560cfd7bbc2e44daa153606a3fef3262965a85": { "Name": "pihole", "EndpointID": "XXX", "MacAddress": "02:42:c0:a8:00:c8", "IPv4Address": "192.168.0.XXX/24", "IPv6Address": "" }, "a638ff6992e28a2bff57a7beb880332de5169e379f645ef9d6eb89afda9efdd2": { "Name": "ha", "EndpointID": "XXX", "MacAddress": "02:42:c0:a8:00:db", "IPv4Address": "192.168.0.XXX/24", "IPv6Address": "" } }, "Options": { "parent": "ovs_eth0" }, "Labels": {} } ] (dites moi s'il faut éditer des infos). L'adresse MAC est générique et s'incrémente petit à petit. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
.Shad. Posté(e) le 1 juin 2020 Auteur Partager Posté(e) le 1 juin 2020 il y a 37 minutes, Phenix21 a dit : Je n'ai pas recréé le réseau au reboot. Ce n'est pas le réseau qui disparaît au redémarrage, mais l'interface virtuelle du NAS par laquelle le NAS peut communiquer avec ses conteneurs en macvlan. Et je ne comprends pas pourquoi tu donnes un ip_range 192.168.1.192/28 à ton réseau macvlan, tu peux très bien le mettre hors de la plage DHCP de ton routeur ou de ta box tout en restant dans le sous-réseau 192.168.0.0/24. Par exemple définir dans ton serveur DHCP une plage de 192.168.0.2 à 192.168.0.99. Dans ce cas-là, utiliser 192.168.0.192/28 sur ton réseau macvlan te donnera une disponibilité d'adresse de 0.193 à 0.206 pour tes conteneurs macvlan (quitte à descendre le CIDR si tu as besoin de plus d'adresses). Pas de chevauchement et tu pares à tout problème éventuel de communication. Et tant que tu ne crées pas d'interface virtuelle sur ton NAS (voir fin du tutoriel), aucun moyen que le NAS communique avec tes conteneurs macvlan, quels qu’ils soient. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Phenix21 Posté(e) le 2 juin 2020 Partager Posté(e) le 2 juin 2020 Bonjour ! Il y a 14 heures, .Shad. a dit : Et je ne comprends pas pourquoi tu donnes un ip_range 192.168.1.192/28 à ton réseau macvlan, tu peux très bien le mettre hors de la plage DHCP de ton routeur ou de ta box tout en restant dans le sous-réseau 192.168.0.0/24. J'avoue moi non plus, je sais plus pq j'avais fait comment, surtout que derrière je fige une IP fixe en 192.168.0.X ! Il y a 14 heures, .Shad. a dit : Ce n'est pas le réseau qui disparaît au redémarrage, mais l'interface virtuelle du NAS par laquelle le NAS peut communiquer avec ses conteneurs en macvlan. Et tant que tu ne crées pas d'interface virtuelle sur ton NAS (voir fin du tutoriel), aucun moyen que le NAS communique avec tes conteneurs macvlan, quels qu’ils soient. Je vais retenter du coup, à voir si je me retrouve avec l'interface virtuelle avec la bonne IP. J'ai contourné le problème en mettant tous les conteneurs qui devaient communiquer entre eux dans le même macvlan. Merci ! 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
.Shad. Posté(e) le 2 juin 2020 Auteur Partager Posté(e) le 2 juin 2020 il y a 2 minutes, Phenix21 a dit : J'ai contourné le problème en mettant tous les conteneurs qui devaient communiquer entre eux dans le même macvlan. Si tu as juste besoin qu'ils communiquent entre eux alors c'est ok, reste qu'ils ne pourront jamais communiquer avec leur hôte. Est-ce que Jeedom n'a pas besoin de communiquer avec le NAS pour tout ce qui est dongle ? (je ne connais pas du tout Jeedom, mais @Didier3L avait l'air de dire qu'il avait ce besoin). Si tu utilises pihole, le NAS doit pouvoir contacter l'IP de ton Pihole pour accéder à Internet s'il est en DHCP. Ou alors il va mouliner pendant x secondes, se rabattre sur le deuxième serveur DNS (s'il y en a un configuré), ou carrément être incapable de résoudre la requête. Un cas où par exemple tu te fiches d'avoir une communication entre ton NAS et son conteneur sur réseau macvlan, c'est unifi-controller, ou la plupart des applications en fait... Vérifie quand même que tout fonctionne comme tu le souhaites. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Phenix21 Posté(e) le 2 juin 2020 Partager Posté(e) le 2 juin 2020 (modifié) Il y a 14 heures, .Shad. a dit : Est-ce que Jeedom n'a pas besoin de communiquer avec le NAS pour tout ce qui est dongle ? (je ne connais pas du tout Jeedom, mais @Didier3L avait l'air de dire qu'il avait ce besoin). HA pas de souci. J'ai également une clé zigbee2mqtt qui fonctionne nickel, sans problème Il y a 14 heures, .Shad. a dit : Si tu utilises pihole, le NAS doit pouvoir contacter l'IP de ton Pihole pour accéder à Internet s'il est en DHCP. Ou alors il va mouliner pendant x secondes, se rabattre sur le deuxième serveur DNS (s'il y en a un configuré), ou carrément être incapable de résoudre la requête. Effectivement ça peut être le souci, je n'ai pas le NAS sur le PiHole. Idem pour pouvoir monitorer le NAS depuis HA Il y a 14 heures, .Shad. a dit : Un cas où par exemple tu te fiches d'avoir une communication entre ton NAS et son conteneur sur réseau macvlan, c'est unifi-controller, ou la plupart des applications en fait... Aujourd'hui ce qui fonctionne c'est l'ensemble chronograp/influxdb/grafana, zigbee2mqtt, mosquitto, nodered Aujourd'hui je galère avec une passerelle homekit, mais c'est le cas pour ma version d'HA en bridge. Edit 2 : ben si je dois avoir un problème de réseau, ma config homekit passe sur le HA bridgé... Edit 3 : je n'arrête pas les edit... Je viens de faire le point, et je n'ai aucun conflit de port pour tous mes containers "domotique". Conclusion : pourquoi tout vouloir passer sur un macvlan ? Conclusion bis : des fois, je ferais mieux de réfléchir un peu plus avant de me lancer dans les bidouilles, surtout quand la doc HA spécifie çà : Citation Note that Docker command line option --net=host or the compose file equivalent network_mode: host must be used to put Home Assistant on the host’s network, otherwise certain functionality - including mDNS and UPnP - will break. Edit : j'en profite pour poser une petite question complémentaire. Sur certains docker-compose on voit des paramètres depends_on. A quoi cela sert-il ? Quel est l'intérêt de déclarer ces dépendances ? Modifié le 2 juin 2020 par Phenix21 Question sup + màj 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
.Shad. Posté(e) le 2 juin 2020 Auteur Partager Posté(e) le 2 juin 2020 Si tu n'as aucun conflit de port, aucune raison de passer en macvlan, quand la documentation HA parle de fonctionnalité cassée c'est parce qu'en bridge le conteneur n'a pas accès au broadcast sur le réseau physique, ce qui en domotique est assez problématique. Donc mode host a priori, ça me semble tout indiqué. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
.Shad. Posté(e) le 4 juin 2020 Auteur Partager Posté(e) le 4 juin 2020 J'ai oublié de répondre à ta dernière question : depends_on permet de demander à ce que le service pour lequel on précise l'option démarre après le service cible. Donc typiquement : services: carddav: ... depends_on: mariadb ... mariadb: ... L'utilisation typique c'est qu'un conteneur attende le démarrage d'une base de données, pour éviter les erreurs de communication parce que la base de données ne serait pas encore initialisée. PS : Cette option ne peut, de mémoire, faire référence qu'à des services définis dans le même fichier compose. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Phenix21 Posté(e) le 4 juin 2020 Partager Posté(e) le 4 juin 2020 Il y a 6 heures, .Shad. a dit : J'ai oublié de répondre à ta dernière question : depends_on permet de demander à ce que le service pour lequel on précise l'option démarre après le service cible. Donc typiquement : services: carddav: ... depends_on: mariadb ... mariadb: ... L'utilisation typique c'est qu'un conteneur attende le démarrage d'une base de données, pour éviter les erreurs de communication parce que la base de données ne serait pas encore initialisée. PS : Cette option ne peut, de mémoire, faire référence qu'à des services définis dans le même fichier compose. Merci ! 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
testadaz Posté(e) le 16 juin 2020 Partager Posté(e) le 16 juin 2020 Bonjour, J'ai une question, depuis quelques temps, je remarque qu’après un redémarrage de mon synology le package docker ne se lance pas tout seul... Est ce que vous avez déjà rencontré ce problème ? Si oui avez vous une solution pour résoudre le pb ? Merci DSM : 6.2.3-25426 docker : 18.09-0.0.513 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
.Shad. Posté(e) le 16 juin 2020 Auteur Partager Posté(e) le 16 juin 2020 Je n'ai jamais eu ce problème personnellement, tu n'as rien trouvé via Google ? 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
bruno78 Posté(e) le 16 juin 2020 Partager Posté(e) le 16 juin 2020 Bonjour, aucun problème de redemarrage constaté non plus .... Des changements de configuration ou des ajouts particuliers qui pourraient être mis en cause ? ou à configuration strictement équivalente ? 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
testadaz Posté(e) le 16 juin 2020 Partager Posté(e) le 16 juin 2020 j'ai du mal à vous répondre factuellement parce que mon nas est resté allumé pdt des mois (donc oui il y a eu des changements, bcp et je ne suis pas capable de les lister) et récemment j'ai changé de fournisseur internet, j'ai du le rebooter plusieurs fois (parce que chg de box et de sous réseau) et à chaque fois qu'il redémarre le package ne se lance pas, il faut que j'aille dans le gestionnaire de package pour cliquer sur "run" bon je vais continuer à essayer de comprendre ce pb 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
.Shad. Posté(e) le 29 juin 2020 Auteur Partager Posté(e) le 29 juin 2020 @testadaz Problème toujours présent ? As-tu testé de désinstaller le paquet et de le réinstaller ? 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
testadaz Posté(e) le 29 juin 2020 Partager Posté(e) le 29 juin 2020 (modifié) oui pb toujours présent. J'ai effectivement désinstallé le paquet et reinstallé plusieurs fois. Rien n'y fait. et c'est de pire en pire, j'arrive meme plus à lancer le paquet. je crois que je vais demande de l'aide au support, parce que je m'en sors plus Car même la commande ci dessous ne marche plus : synoservice --start pkgctl-Docker service [pkgctl-Docker] start failed, synoerr=[0x3900] Par contre synoservice --hard-start pkgctl-Docker a bien voulu lancé le paquet... Modifié le 29 juin 2020 par testadaz 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
.Shad. Posté(e) le 29 juin 2020 Auteur Partager Posté(e) le 29 juin 2020 As-tu regardé ce que dit /var/log/messages à ce sujet ? Tu peux aussi taper dmesg en SSH, tu pourrais y trouver quelques infos. Sinon le support, insiste pour avoir l'équipe technique directement, tu risques d'être baladé entre du support de premier niveau. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Lelolo Posté(e) le 29 juin 2020 Partager Posté(e) le 29 juin 2020 L'erreur que tu rencontres correspond à "ERR REMOVE FAILED 0x3900 Failed to remove file.", mais je ne sais pas si cela va t'aider 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.