MilesTEG1

Bonjour à tous 👋🏻 @lenoob22 Mintre voir ton docker-compose.yml ? ou si tu n’en as pas , décris ta méthode utilisée. car il y a trop d’inconnues dans ton cas et trop de sources de problème de mail.

Ce sont peut-être les deux caméras qui font ces pics d'utilisation CPU...

@StéphanH Tu as quoi qui tourne sur ton HA ? Sur mon instance proxmox, en VM, j'ai ça pour la semaine : Et pour la journée : Bon après, je n'ai pas beaucoup de choses qui tournent dessus. Studio Code Server (5.15.0), Advanced SSH & Web Terminal (17.1.0), Silicon Labs Flasher (0.2.0), Zigbee2MQTT (1.35.3-1), Mosquitto broker (6.4.0), Samba Backup (5.2.0), tiko / Mon Pilotage Elec (1.3.1), File editor (5.8.0), Silicon Labs Multiprotocol (2.4.4), Samba share (12.3.0), Crowdsec (1.6.0), Crowdsec Firewall Bouncer (v0.0.28) Taille estimée de la base de données (en Mio): 157.72 MiB

Perso, j'ai déplacé ma VM HAOS sur un NUC, c'est bien plus fluide, et j'ai moins de soucis au redémarrage de la machine hôte comme c'était le cas avec le Syno et VMM (je n'ai que 12 Go de RAM sur le 920+)

Ca peut être contraignant si le nombre de ports à router est conséquent. mais si tu n’as qu’un seul port 443 et que tu as un reverse proxy derrière ça peut le faire 😊 mais il faut garder en tête que ça peut toujours être une source de problème.

Hello 👋🏻 je ne te conseille pas une installation sous docker sur ton nas car comme l’a dit @firlinça va être complexe surtout parce qu’il te faudra trouver le pilote pour ton adaptateur usb Zigbee si tu passes par une clé usb sonof ou SkyConnect ou autre . et ensuite faudra le faire passer à ton conteneur docker . ca n’est pas insurmontable mais c’est chronophage . Il y a aussi que via docker tout devra être installé sous forme de conteneur docker notamment les addons, Mqtt etc… ça ajoute de la maintenance donc tu temps . passer par une VM te permettra d’installer HAIS qui permet de tout intégrer dedans : addons inclus. Moins de maintenance. mais il faudra avoir de la ram sur ton nas, et allouer au moins 2-4 Go pour la VM HAOS. et pense que dsm lui aussi en a besoin et pas qu’un peu : il est gourmand ! j’ai du déplacer ma vm de mon 920+ sur un NUC dans Proxmox car avec tout ce qui tourne sur mon nas en applications Synology et tout ce qui tourne en docker , et avec une autre VM Proxmox Backup, la VM HAOS ne pouvait avoir que 1Go de ram et ça n’était pas suffisant, et ça ne laissait que 80-90% de libre dixit dsm. Ça le faisait ramer un peu.

@.Shad.Hmmm, j'ai trouvé ce qui faisait foirer mon fail2ban... C'étaient des commentaires dans la liste d'IP à ignorer... pffff... Va savoir pourquoi ces commentaires bien mis avec # devant n'étaient pas pris en compte correctement... Maintenant qu'ils sont supprimés, tout va bien 😅

@.Shad. Salut 👋 Je pense que je vais repartir sur cette idée, placer dans le Home Assistant une instance de Crowdsec. Sinon, j'ai un petit souci avec Fail2Ban intégré de SWAG... Impossible de lancer la commande habituelle : sudo docker exec -it swag fail2ban-client status ALors que la même commande pour Crowdsec fonctionne bien : sudo docker exec -t crowdsec cscli Je ne comprends pas, car quand je vais dans le conteneur avec : sudo docker exec -t swag /bin/bash je peux lancer la commande fail2ban-client sans soucis... As-tu une idée ? bon en fait ça chie aussi dans le conteneur : root@Swag--DS920Plus:/# fail2ban-client restart 2024-01-24 08:36:23,444 fail2ban [3615]: ERROR Failed to access socket path: /var/run/fail2ban/fail2ban.sock. Is fail2ban running? 2024-01-24 08:36:23,543 fail2ban [3615]: ERROR Fail2ban seems to be in unexpected state (not running but the socket exists) root@Swag--DS920Plus:/# root@Swag--DS920Plus:/# fail2ban-client reload 2024-01-24 08:38:25,419 fail2ban [3891]: ERROR Could not find server La commande fail2ban-client fonctionne, mais pas quand je mets un argument derrière. Je vais relancer le conteneur, mais je n'y crois pas, j'ai déjà fait ça tout à l'heure...

Salut 👋🏻 je ne connais pas vraiment le cpu du ds923+, mais j’ai peur qu’il soit limité pour la virtualization d’un Windows 11 et accès à distance pour plusieurs personnes. surtout si tu veux du fluide. J’ai un Win11 Pro virtualisé dans un NUC sous Proxmox, c’est assez fluide mais le cpu est un i9-13900H avec 33Go de ram, le tout sur ssd . Il faudrait des avis sur le cpu du 923+ pour être sûr qu’il soit bien dimensionné. Mais mon conseil si tu dois impertinemment faire du télétravail via une Windows en Remote Desktop : prends une machine très puissante pour ça , mais juste pour le Windows. Et ensuite tu prends le bas comme stockage réseau. et ça surtout si tu as de gros logiciels à faire tourner.

Oh my ! Mais oui ! Merci bien 😉 Va me falloir un peu potasser le truc, mais oui ^^

@.Shad.F2B et Crowdsec ne sont pas exclusifs ^^ J'ai les 2 en fonctionnement. Mais oui, j'ai parfois l'impression qu'il y a des faux positifs via les logs nginx pour Crowdsec. Il faut préférer passer les logs des applications directement avec une collection dédiée pour être à peu près tranquille. Mais ce n'est pas toujours possible : par exemple, j'ai un serveur Home Assistant dans une VM, et je ne peux pas partager comme ça ses logs dans SWAG (pour F2B ou Crowdsec).

J'ai bien un docker-compose, mais il est avec l'image LinuxServer que je déconseillerais fortement en raison de leur politique de mise à jour. Récemment j'ai appris qu'ils ne feraient plus de MAJ de la branche 27.x au profit de la 28.x. Donc ceux qui n'ont pas d'app compatible 28.x peuvent se brosser pour les correctifs de sécurité qu'apportent les MAJ de la 27.x Je te conseille d'utiliser l'image officielle nextcloud:aio ou celle maintenue par la communauté docker nextcloud:fpm. Je n'ai pas de docker-compose pour celles là.

Ça n’est pas bête , j’ai bien de vieux ssd dans ma tour qui ne servent pas vraiment depuis quelques mois… mais j’en ai pas de boîtier usb 😅

En ce qui me concerne c’est sur une clé usb 3.

C’est en effet mon principal moyen d’accès au LAN en dehors de chez moi. J’ai configuré le L2TP et OpenVPN et enfin SSL VPN. le L2TP fonctionne bien que je suis en partage de connexion 4G. Mais récemment c’est le ssl vpn que j’ai pu configurer sur un port exotique qui est l’un des rares autorisés sur le wifi eduroam de mon lycée. Car ni le l2tp ni le OpenVPN ne passent. Seul SSL VPN sur un port particulier (pas le 443 ni le 80) fonctionne bien.

C’est de plus en’ onus ce que je le dis. mais il intercepte quand même pas mal de saloperies… peut être que ça pourrait être remplacé par une MV Pfsense ou un truc du genre (je m’avance beaucoup là car je n’y connais rien 😅🤣) sinon en effet je reboot le routeur rt2600ac toutes les nuits, depuis trop longtemps pour le rappeler exactement ce qui le merdouillait 😅

Mon RT et son wifi deviennent instable au bout de quelques jours. La cause est probablement Threat Prevention que je ne souhaite pas désactiver. Depuis que je le reboot toutes les nuits, il ne semble plus y avoir les soucis de wifi.

Bonjour, J'ai constaté un souci assez étrange avec mes 2 VMs, et trop concomitant avec la MAJ de SWAG (mon reverse proxy) pour ne pas être liés. Tout d'abord le contexte. J'ai deux VM depuis peu dans VMM : Home Assistant OS Promox Backup server Les deux sont en temps normal accessible via leur IP, mais aussi via le nom de domaine que j'ai paramétré dans le reverse proxy SWAG (installé en macvlan, avec interface virtuelle en supplément, merci @.Shad. pour le super tuto 👋🏻). Ce matin, watchtower m'a mis à jour SWAG vers 5h. En me levant je constate que Home Assistant n'est plus accessible via son adresse IP, alors qu'à minuit ça l'était. Je vois que SWAG a été mis à jour, et je tente de trouver pourquoi ça ne fonctionne plus... Sans vrai succès. Je relance les VM, et après un autre reboot pour HA, tout redevient accessible. Entre temps, j'ai relancé mon script de création de l'interface virtuelle, qui n'a pas renvoyé d'erreur, donc mon interface virtuelle avait sauté elle aussi. En temps normal, ça ne devrait avoir d'impact que sur le reverse proxy, et donc les noms de domaines. Donc mon hypothèse est qu'il y a quelque chose qui a fait foirer la connexion LAN du NAS. Ce qui est confirmé par les log dans le centre des journaux : Mon LAN3 est mon interface réseau principale, via un adaptateur USB 2,5GbE connecté sur un swtich 2,5GbE. Le LAN1 est connecté à un autre switch Gb, mais l'interface est désactivée quand LAN3 est fonctionnelle. J'ai un script lancé toutes les 30 minutes par le planificateur de tâche qui s'occupe de vérifier que LAN3 est fonctionnel et désactive les autres interfaces quand c'est le cas, et réactive LAN1 si LAN3 est KO. Et en rédigeant ces lignes, j'ai fait quelques recherches dans les logs de DSM et c'est en réalité vers 2h du matin que ça foiré. Voilà la sortie de mon script lancé vers 2h00:01 : (1) already root => As VMM is installed and Open vSwitch is activated, all physical interfaces will be managed with the virtual one (ovs_ethX). => So when we'll see ethX, ovs_ethX will be managed as well. => eth0, eth1 : will be deactivated if 'eth2' is up and running. Try n°1 package r8152 is turned on , version is 2.17.1-1 pkgctl-r8152 active_status = active pkgctl-r8152 load_status = loaded pkgctl-r8152 enable_status = enabled The driver status is OK ! No need to do something more. gateway is = 192.168.2.1 Gateway 192.168.2.1 IS NOT accessible ! The driver need to be restarted or reloaded ! [pkgctl-r8152] done reload-or-restart. Try n°2 package r8152 is turned on , version is 2.17.1-1 pkgctl-r8152 active_status = active pkgctl-r8152 load_status = loaded pkgctl-r8152 enable_status = enabled The driver status is OK ! No need to do something more. The driver is still not OK on the 2nd try ! That's not good... It means the eth2 isn't working... So let's reactivate the eth0 interface. Reactivation of eth0. Done. Ipv6 on interface ovs_eth0 is already deactivated. Reactivation of eth0 because of Open vSwitch installed with VMM. -> ovs_ should be up now. You can connect the NAS on 192.168.2.200 in order to sort things out... Reactivation of eth1. Done. Ipv6 on interface ovs_eth1 is already deactivated. Reactivation of eth1 because of Open vSwitch installed with VMM. -> ovs_ should be up now. You can connect the NAS on 169.254.26.251 in order to sort things out... => Exiting script now. Sending Gotify Notification... On voit que le script à bien détecté un souci et à réactivé l'interface eth0 (LAN1). 30 min plus tard, le script réactive mon interface LAN3 (eth2) et désactive LAN1 et tout refonctionne (enfin pas les VMs) (Note : je pense qu'il faut que ce script relance la création de l'interface virtuelle si jamais eth2 a été down... sinon mon SWAG ne fonctionnera plus correctement, et ça c'est un autre souci... que je devrais résoudre avec quelques lignes de code supplémentaires) : (1) already root => As VMM is installed and Open vSwitch is activated, all physical interfaces will be managed with the virtual one (ovs_ethX). => So when we'll see ethX, ovs_ethX will be managed as well. => eth0, eth1 : will be deactivated if 'eth2' is up and running. Try n°1 package r8152 is turned on , version is 2.17.1-1 pkgctl-r8152 active_status = active pkgctl-r8152 load_status = loaded pkgctl-r8152 enable_status = enabled The driver status is OK ! No need to do something more. gateway is = 192.168.2.1 gateway 192.168.2.1 is accessible ! No need to do something more. Deactivation of ipv6 on interface ovs_eth2 in 5s... ovs_eth0 is still up and running. Shutting down now. eth0 is still up and running. Shutting down now. ovs_eth1 is still up and running. Shutting down now. eth1 is still up and running. Shutting down now. Le souci est donc localisé entre 2h00:01 et 2h30 ce matin. En fait loin de la MAJ de SWAG comme initialement pensé... L'investigation continue : pourquoi diable ma connexion a sauté ?! Le switch 2,5GbE, récemment mis ? Ça me parait étonnant, car mon autre NAS ne m'a pas rapporté de déconnexion... ni le NUC branché lui aussi dessus... Hmmm... un autre switch du réseau... peu probable... mais le tout abouti donc au routeur. Il n'y a que lui qui peut avoir merdé, et fait que mon interface du NAS récupère une adresse APIPA, donc pas de serveur DHCP... Regardons les logs du routeur. Diantre, mais il a rebooté ce #@$... Et là, je me souviens que j'ai programmé un reboot 😅 Bon bah voilà, fautif trouvé... 🤣 le routeur qui reboot 🫣🙄 Me reste à décaler un peu le reboot entre deux exécutions de mon script de vérification d'interface, et à coder un peu sur le lancement de la recréation de l'interface virtuelle du NAS en cas de réactivation de eth2. Voilà pour ma petite histoire 😆

Je confirme les dire de @CyberFr Il s'agit bien du fichier collector.yml qui fait tout ^^ J'ai mis ça en device dans mon docker-compose.yml devices: # List devices with : ls /dev/ | grep '/dev/[sh]d[a-z]\|sata[0-9]\|usb[0-9]\|nvme[0-9]' - /dev/sata1:/dev/sata1 - /dev/sata2:/dev/sata2 - /dev/sata3:/dev/sata3 - /dev/sata4:/dev/sata4 # - /dev/nvme0:/dev/nvme0 # - /dev/nvme1:/dev/nvme1 - /dev/nvme0n1:/dev/nvme0n1 - /dev/nvme1n1:/dev/nvme1n1 Et mon collector.yml est quasi identique au tien : version: 1 host: id: "Syno-DS920+" devices: - device: /dev/nvme0n1 type: 'nvme' - device: /dev/nvme1n1 type: 'nvme' - device: /dev/sata1 type: 'sat' - device: /dev/sata2 type: 'sat' - device: /dev/sata3 type: 'sat' - device: /dev/sata4 type: 'sat' # - device: /dev/sata5 # type: 'sat' # - device: /dev/sata6 # type: 'sat' # - device: /dev/sata7 # type: 'sat' # - device: /dev/sata8 # type: 'sat'

Peut-être fusionner les deux sujets serait une bonne idée ^^

Hello 👋🏻 Dîtes, avez vous des soucis avec le bouncer de Crowdsec qui ne veut pas être télécharger dans l’image swag ?! chez moi ça me fait une erreur (je n’ai plus le terme exact et je suis sûr mobile…) « … mismatch … », et nginx redémarre sans avoir fini son démarrage. Dès lors que j’enlève le mod Crowdsec du docker compose , nginx fini son démarrage. je posterais plus de précision quand j’aurais le pc sous la main.

Il est à noter que mon tuto est devenu obsolète avec les scripts de 007revad : https://github.com/007revad https://www.forum-nas.fr/threads/utilisation-dun-ssd-nvmem2-en-tant-que-volume-de-stockage-dans-un-synology-ds920.18926/post-139394 vu que je n'ai pas créé mon volume avec un de ses scripts, je n'utilise que celui-là : https://github.com/007revad/Synology_HDD_db Mais pour créer un volume sur NVMe, il faut utiliser : https://github.com/007revad/Synology_M2_volume ou bien avec https://github.com/007revad/Synology_enable_M2_volume Tout dépend de si on veut que tout se fasse presque entièrement automatiquement, ou bien si on veut juste tout faire depuis DSM (après l'exécution du script).

J’utilise rustdesk po contrôler une machine Linux à distance. j’ai créé un serveur rustdesk via docker sur un nas chez moi et il sert de relai pour accéder à la MV Linux. je n’ai pas trouvé mieux. il y a bien Nomachine qui marche pas trop mal aussi.

Ok 👍🏻 merci pour l’indication. Comment tu rediriges les données sur l’api du nas qui centralise les données ?

Normalement non, pas besoin de spécifier un PGID/PUID. Je ne crois pas que l'image en tienne compte si tu en mettais un. De toute manière, les droits sont donnés par cap_add: - SYS_RAWIO - SYS_ADMIN Dernière précision : il n'est pas utile de publier le port de la base de données. Je laisse commenté le port de InfluxDB. # ╔══════════════════════════════════════════════════════════════════════════╗ # ║ Fichier docker-compose.yml pour Scrutiny ║ # ║ sur NAS Synology ║ # ╚══════════════════════════════════════════════════════════════════════════╝ # # https://github.com/AnalogJ/scrutiny # # Création des dossiers # mkdir -p /volume4/docker/scrutiny/{config,influxdb} # version: '3.5' services: scrutiny: container_name: scrutiny image: ghcr.io/analogj/scrutiny:master-omnibus cap_add: - SYS_RAWIO - SYS_ADMIN ports: - "8800:8080" # webapp # - "8801:8086" # influxDB admin volumes: - /run/udev:/run/udev:ro - /volume4/docker/scrutiny/config:/opt/scrutiny/config - /volume4/docker/scrutiny/influxdb:/opt/scrutiny/influxdb devices: # List devices with : ls /dev/ | grep '/dev/[sh]d[a-z]\|sata[0-9]\|usb[0-9]\|nvme[0-9]' - /dev/sata1:/dev/sata1 - /dev/sata2:/dev/sata2 - /dev/sata3:/dev/sata3 - /dev/sata4:/dev/sata4 # - /dev/nvme0:/dev/nvme0 # - /dev/nvme1:/dev/nvme1 - /dev/nvme0n1:/dev/nvme0n1 - /dev/nvme1n1:/dev/nvme1n1 environment: - SCRUTINY_WEB_INFLUXDB_TOKEN=UnAutreGrosMotDePassEavecChiffres0124579684123210 - SCRUTINY_WEB_INFLUXDB_INIT_USERNAME=BDD-Syno - SCRUTINY_WEB_INFLUXDB_INIT_PASSWORD=UnAutreGrosMotDePassEavecChiffres0124579684123210 - TIMEZONE=Europe/Paris - COLLECTOR_CRON_SCHEDULE=0 * * * * # https://crontab.guru/#0_6_*_*_* labels: # watchtower label - "com.centurylinklabs.watchtower.enable=true" networks: scrutiny_network: ipv4_address: 172.28.0.2 restart: unless-stopped networks: scrutiny_network: ipam: driver: default config: - subnet: 172.28.0.0/16 ip_range: 172.28.0.0/24 gateway: 172.28.0.1 name: scrutiny_network Et le collector.yml : version: 1 host: id: "Syno-DS920+" devices: - device: /dev/nvme0n1 type: 'nvme' - device: /dev/nvme1n1 type: 'nvme' - device: /dev/sata1 type: 'sat' - device: /dev/sata2 type: 'sat' - device: /dev/sata3 type: 'sat' - device: /dev/sata4 type: 'sat' # - device: /dev/sata5 # type: 'sat' # - device: /dev/sata6 # type: 'sat' # - device: /dev/sata7 # type: 'sat' # - device: /dev/sata8 # type: 'sat'