PiwiLAbruti

Je confirme @Jeff777, c'est pour ça que je conseille aussi de le configurer dès que l'adresse IPv4 full-stack est opérationnelle.

@MilesTEG1 Le reverse DNS n'est pas un service de DNS dynamique. Il sert à renvoyer un nom de domaine de ton choix (ou Free en *.hd.free.fr) à partir de ton adresse IPv4 (enregistrement DNS de type PTR).

Et n'oublie pas de modifier ton reverse DNS (si tu en as un) dès que la connexion est opérationnelle.

Ah zut, désolé. Il y a peut-être un tutoriel pour ce que tu souhaites faire sur ce même site ?

Pourquoi ne pas configurer la caméra (et l'enregistrement) directement dans Surveillance Station ? Les fichiers vidéo enregistrés se trouvent dans /var/services/surveillance/{nomDeLaCamera}/{date}/*.mp4

Je crois qu'il est question de Pi-hole dans un conteneur Docker @Jeff777.

Est-ce que la commande nano existe ? $ which nano Sinon essaye avec vi : $ which vi $ sudo vi /etc/hosts

Ok, on part de loin 😅 Commence déjà par appliquer ce tutoriel car ton NAS est totalement exposé sur Internet :

C'est impossible à déterminer car ça dépend de trop de facteurs (caractéristiques des disques, nombre de disques, rapidité du processeur du NAS, utilisation du NAS pendant la reconstruction, ...).

Un disque de plus petite taille ne pourra pas être intégré au RAID.

Est-ce que le nom de domaine utilisé se résout en IPv4 et/ou IPv6 ? Quelles sources externes sont autorisées dans le pare-feu du NAS ? Récupère les adresse IPv4 et IPv6 du téléphone lorsqu'il est connecté au réseau mobile pour comparer avec les règles de pare-feu.

Bonjour @Zebulon777, Si ce n'est déjà fait, faire une sauvegarde des données (ou au moins des données importantes s'il y en a), Remplacer le disque par un disque de même taille ou plus grand (l'espace supplémentaire ne sera pas utilisé), Reconstruire le RAID (peut être très long). J'insiste sur la sauvegarde car si un autre disque devient défaillant au cours de la réparation (qui est une opération sollicitant beaucoup les disques), l'intégralité des données sera perdue.

Concernant le DS923+, il y a quelques points à préciser par rapport au DS920+ : Le processeur passe d'un Intel 4C/4T@2GHz à un AMD 2C/4T@2,6GHz (on retrouve donc le même nombre de vCPU pour la virtualisation), Ce processeur de la série R1000 (AMD Ryzen R1600) est dépourvu d'iGPU (processeur graphique intégré), il n'y a donc plus de transcodage matériel des flux vidéo 🙁, Deux slots mémoire sont disponibles pour augmenter la quantité de RAM 🙂 pour un total pouvant aller jusqu'à 32Go 😀 (1 seul dans le DS920+, théoriquement limité à 8Go au total), Enfin compatible 10GbE 🙂 mais pas nativement 🙁 (180€ la carte propriétaire avec un seul port 10GbE 💀), Les 2 slots M.2 sont maintenant utilisables pour créer un groupe de stockage 🙂 (uniquement dédiés au cache auparavant) mais seulement avec les modèles de SSD M.2 de Synology série SNV3400 🙁 (180€ le SSD M.2 de 400Go, et 300€ le 800Go 💀) : Ce DS923+ ne brille pas par ses qualités environnementales. Comparé au DS920+, il consomme plus, chauffe plus, et fait plus de bruit. Bref, à part le retour en arrière sur les slots de RAM (qui était une régression du DS920+ face au DS918+), il n'y a pas grand chose d'intéressant.

Il y a un tutoriel dédié à SFR sur LaFibre.info @flywall : https://lafibre.info/remplacer-sfr/bypass-nb6-avec-routeur-synology-rt1900ac-acces-ssh-ok/

IKEv2 va clairement devenir majoritaire, Mais je trouve prématuré d'avoir retiré L2TP/IPsec surtout qu'il y a encore beaucoup de constructeurs qui ne sont pas prêts (comme Synology).

Il y a pourtant un tutoriel assez touffu à ce sujet. Pour commencer simplement, privilégie L2TP/IPsec car ce type de VPN est natif à tous les systèmes (Windows, Mac, Linux, Android, iOS, ...) et ne nécessite donc l'installation d'un client VPN. Tu peux donc suivre le début de ce tutoriel (tronc commun), et uniquement les sections concernant L2TP/IPsec. Si tu ne t'en sors pas, explique où ça coince et/ou ce que tu ne comprends pas (car personne ici ne te fera un cours sur le VPN).

C'est étrange. Lorsque j'émets un paquet WoL depuis un script dédié, tcpdump m'affiche bien le paquet envoyé (mais rien avec synonet). 12:36:06.867817 IP 192.168.1.16.51543 > 255.255.255.255.9: UDP, length 102

Et tcpdump affichait bien l'envoi des paquets ? Quel modèle de NAS utilises-tu, et avec quelle version de DSM ?

Oui, l'option est bien visible dans l'aide de la commande. Pourtant elle ne fonctionne sur aucun NAS que j'utilise, aussi bien sous DSM 6 que 7. Pour ceux chez qui ça marche, vous pouvez faire une capture du paquet envoyé par le NAS ? (avec la commande tcpdump donnée un peu plus haut) Vous pouvez utiliser la commande suivante pour générer un fichier lisible par WireShark : sudo tcpdump -s 0 -i any 'udp port (0 or 7 or 9)' -w wol.pcap

En fouillant dans la documentation officielle, il semblerait que l'option --wake ne soit plus disponible pour la commande synonet. En tout cas, elle n'est plus documentée.

J'ai testé sur 3 NAS différents (DSM 6 et 7), aucun d'entre eux n'émet de paquet WoL avec la commande : sudo synonet --wake xx:xx:xx:xx:xx:xx ethX Pour voir les paquets WoL émis par le NAS, ouvrez une 2ème session SSH et exécutez : sudo tcpdump -Anqi any 'udp port (0 or 7 or 9)' Ça affichera n'importe quel paquet WoL entrant ou sortant (udp/9 est le plus utilisé, mais on trouve parfois udp/0 ou udp/7).

La tâche planifiée est exécutée avec quel compte utilisateur ? (il faut utiliser root)

Ça reviendrait à pouvoir créer des liens symboliques (commande ln) directement dans File Station. Je ne crois pas que ce soit possible dans File Station, mais je te conseille fortement de faire une demande d'évolution à Synology : https://www.synology.com/fr-fr/form/inquiry/feature

D'ailleurs, je viens de retrouver le sujet où il en était question :

Si tu peux, l'adresse IP définie dans le bail ne changera jamais.