Table of Contents
Synology DS415+
Le DS415+ est un NAS orienté TPE/PME (malgré la garantie de seulement 2 ans !). C'est un upgrade de son grand frère le DS412+, doté de plus de mémoire et d'un processeur plus puissant (atom 4 cœurs 2.4 Ghz) qui permet le chiffrement matériel.
Packaging
Acheté le 10/10/2014 à ~490 euros. Livré avec son transfo, 2 câbles réseaux et son OS DSM 5.0
Caractéristiques techniques
CPU : Atom Quad-Core C2538(4C/4T) @2.4 GHz (Avoton 64-bits/gravure 22nm/2MB cache/TDP 15W/VT-x et EPT/AES-NI pour le chiffrement matériel AES 256 bits)
Mémoire : 2 GB DDR3 (extensible à 8 GB officieusement et en perdant la garantie)
Emplacements : 4x baies 3.5" hot-swappable ; max 24 TB (4 disques de 6 TB, connexion interne SATA II), tiroirs screwless (sans vis)
Type de RAID : JBOD, RAID {0, 1, 5, 6, 10, SHR (Synology Hybrid RAID)}
Stockage : ext4 pour les disques internes, ext3-4, FAT, NTFS ou HFS+ pour les disques externes
Ventilation : 2x 92 mm en extraction
Bruit : 20.2 dB(A)
Alimentation : 100 W
Consommation : 46.2W (Access), 17.3W (HDD Hibernation)
Taille (hauteur-largeur-profondeur) : 165 x 203 x 233.2 mm
Poids : 2,05 kg
Garantie : 2 ans
Connectique :
2x Gigabit (compatible link aggregation), WoL
1x USB2 (façade), 2x USB 3
1x eSATA
Installation
- on insère les disques
- on branche
- on ouvre la page suivante dans son navigateur : http://find.synology.com
Le NAS, qui doit être connecté sur le même réseau que votre ordinateur, est détecté automatiquement et vous présente l'assistant d'installation. Ce dernier vous demande le mot de passe admin, et vous propose de télécharger seul la dernière version de DSM. 10 minutes après, DSM est lancé et accessible via votre navigateur. La durée de construction du raid (4x 4 To WD red, en une grappe de SHR (Synology Hybrid RAID)) est d'environ 1j, 5h :
ds415> cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md2 : active raid5 sdd5[3] sdc5[2] sdb5[1] sda5[0] 11706850944 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU] [==================>..] resync = 93.7% (3657132392/3902283648) finish=145.4min speed=28092K/sec
Compter ensuite la durée d'installation et de configuration des différents modules (centre de paquets) et services (création des utilisateurs, partages, notifications, …), puis de migration des données et vous avez un NAS pleinement fonctionnel.
Pros & cons
+ excellentes performances mono-tâche, les meilleures pour des données chiffrées + petite taille (mais costaud.. ) + bon rapport qualité/prix + insertion des disques simples + l'OS DSM bien fini et extensible via les extensions - il arrive que les disques fassent vibrer le boitier, ce qui génère du bruit - performances multi-tâches limitées
Sécurisation du NAS
Cette partie traite de la sécurisation (hardening) d'un NAS Synology. Parce qu'il arrive qu'il contienne des données sensibles et qu'il soit connecté à Internet, il faut prendre quelques précautions.
Sources:
- Sécurisation du NAS - pour DSM 7 (sur nas-forum.com)
système
- activer la détection des nouvelles mises à jour de DSM :
Control Panel > Update & Restore > DSM Update > Update Settings : cocher Newest DSM and all updates et Check and download update regularly- les installer en urgence s'il corrige une faille critique
- sinon attendre quelques jours pour laisser les autres utilisateurs essuyer les éventuels plâtres à votre place (oui ça arrive qu'un patch casse tout !)
réseau
- si votre NAS est derrière une box ou un réseau NATté, ne rediriger que les ports utiles sur votre routeur/box (par ex. que le port HTTPS)
- désactiver l'accès HTTP, qui ne chiffre pas les communications, et le remplacer par HTTPS
- changer le port d'écoute par défaut du serveur HTTP(S) (et plus généralement des services accessibles par les réseaux non-sûrs (Internet par exemple))
- installer un certificat SSL/TLS authentifié par une autorité de certification sûre
- activer le firewall intégré et ajouter les règles limitant les accès des IPs non-LAN
- MEP de la géolocalisation (l'accès par pays, dispo à partir de DSM 5)
- sauvegarder la configuration du NAS régulièrement :
Control Panel > Update & Restore > Configuration Backup : Back up configuration - activer l'IP Auto Block qui bloque les IPs qui ont trop d'échecs d'authentification
- activer le NTP (actif par défaut dans DSM 5.0)
utilisateur
- on ne peut pas supprimer le compte de l'utilisateur “admin”, et c'est dangereux de conserver un login connu donc :
- créer un nouveau compte avec les droits d'admin
- mettre un mot de passe fort puis désactiver le compte utilisateur “admin”
- n'utiliser le compte qui a les droits d'admin que pour les taches d'admin ; le reste du temps utiliser un compte “simple utilisateur” nominatif et avec des droits restreints
- mettre en place une stratégie de mot de passe forte (taille du mot de passe > 8 caractères, contenant des minuscules, majuscules, chiffres et caractères spéciaux.
- utiliser une double authentification : bon, c'est un peu la mode en ce moment mais j'avoue que je ne suis pas systématiquement pour, car c'est assez éprouvant quand on se loggue/déloggue régulièrement.
alertes
- configurer les notifications par mail
MIBs/OIDs
Voici un aide-mémoire des OIDs intéressants à pooler en SNMP pour métrologiser le NAS.
// synoSystem
systemStatus .1.3.6.1.4.1.6574.1.1.0 = INTEGER: 1
-> Normal(1), Failed(2)
systemTemperature .1.3.6.1.4.1.6574.1.2.0 = INTEGER: 32
powerStatus .1.3.6.1.4.1.6574.1.3.0 = INTEGER: 1
systemFanStatus .1.3.6.1.4.1.6574.1.4.1.0 = INTEGER: 1
cpuFanStatus .1.3.6.1.4.1.6574.1.4.2.0 = INTEGER: 1
modelName .1.3.6.1.4.1.6574.1.5.1.0 = STRING: "DS415+"
serialNumber .1.3.6.1.4.1.6574.1.5.2.0 = STRING: "xxxxxxxxxx"
version .1.3.6.1.4.1.6574.1.5.3.0 = STRING: "DSM 5.1-5022"
upgradeAvailable .1.3.6.1.4.1.6574.1.5.4.0 = INTEGER: 2
-> Available(1), Unavailable(2), Connecting(3), Disconnected(4), Others(5)
// synoDisk
diskIndex .1.3.6.1.4.1.6574.2.1.1.2.0 = STRING: "Disk 1"
diskID ?
diskModel .1.3.6.1.4.1.6574.2.1.1.3.0 = STRING: "WD40EFRX-68WT0N0 "
diskType .1.3.6.1.4.1.6574.2.1.1.4.0 = STRING: "SATA"
diskStatus .1.3.6.1.4.1.6574.2.1.1.5.0 = INTEGER: 1
-> Normal(1), Initialized(2), NotInitialized(3), SystemPartitionFailed(4), Crashed(5)
diskTemperature .1.3.6.1.4.1.6574.2.1.1.6.0 = INTEGER: 29
// synoRaid
raidIndex ?
raidName .1.3.6.1.4.1.6574.3.1.1.2.0 = STRING: "Volume 1"
raidStatus .1.3.6.1.4.1.6574.3.1.1.3.0 = INTEGER: 1
-> Normal(1), Repairing(2), Migrating(3), Expanding(4), Deleting(5), Creating(6), RaidSyncing(7),
RaidParityChecking(8), RaidAssembling(9), Canceling(10), Degrade(11), Crashed(12)
// synoUPS : .1.3.6.1.4.1.6574.4
pas intéressant
// autres OIDs
Load
.1.3.6.1.4.1.2021.10.1.2.1 = STRING: "Load-1"
.1.3.6.1.4.1.2021.10.1.2.2 = STRING: "Load-5"
.1.3.6.1.4.1.2021.10.1.2.3 = STRING: "Load-15"
.1.3.6.1.4.1.2021.10.1.3.1 = STRING: "1.96"
.1.3.6.1.4.1.2021.10.1.3.2 = STRING: "2.02"
.1.3.6.1.4.1.2021.10.1.3.3 = STRING: "2.04"
Usage CPU
User .1.3.6.1.4.1.2021.11.9.0 = INTEGER: 1
System .1.3.6.1.4.1.2021.11.10.0 = INTEGER: 0
Idle .1.3.6.1.4.1.2021.11.11.0 = INTEGER: 98
Mémoire
memTotalSwap .1.3.6.1.4.1.2021.4.3.0 = INTEGER: 3317676
memAvailSwap .1.3.6.1.4.1.2021.4.4.0 = INTEGER: 3311992
memTotalReal .1.3.6.1.4.1.2021.4.5.0 = INTEGER: 2035652
memAvailReal .1.3.6.1.4.1.2021.4.6.0 = INTEGER: 114792
memTotalFree .1.3.6.1.4.1.2021.4.11.0 = INTEGER: 3426784
? .1.3.6.1.4.1.2021.4.12.0 = INTEGER: 16000
memShared .1.3.6.1.4.1.2021.4.13.0 = INTEGER: 0
memBuffer .1.3.6.1.4.1.2021.4.14.0 = INTEGER: 37300
memCached .1.3.6.1.4.1.2021.4.15.0 = INTEGER: 1585848
Reseau
ifName .1.3.6.1.2.1.31.1.1.1.1
ifHCInOctets .1.3.6.1.2.1.31.1.1.1.6
ifHCOutOctets .1.3.6.1.2.1.31.1.1.1.10
Logiciels
Pour ajouter des fonctionnalités supplémentaires sur le NAS, on peut installer des logiciels. Comme sur les distribs Linux, on les installe depuis des dépôts, que l'on peut personnaliser dans l'interface de l'outil idoine : le Package Center. On dispose par défaut des paquets dans le dépôt officiel Synology, mais on peut en rajouter d'autres dans Settings/Package Sources, par exemple :
- SynoCommunity (Location=http://packages.synocommunity.com/)
- cphub (Location=https://www.cphub.net)
synogear
Certains outils de base des distributions Linux sont installables en CLI avec la commande synogear :
# installation, en root (sudo) synogear install download DiagnosisTool 3.0.1-3008 successfully # lister les composants installés synogear list
On retrouvera par exemple iperf, dig, iostat, tcpdump, tracepath, tmux etc…
Tiny Tiny RSS
C'est un client RSS ; il dépend du paquet MariaDB (dont le mdp root est vide par défaut).
MySQL root password
Depuis la version DSM 6, TT RSS ne se lance plus (avec l'erreur : “incorrect MySQL root password”) ; pour corriger le problème il faut se connecter en SSH (avec un compte ayant les droits d'admin) et saisir :
sudo mkdir -p /usr/syno/mysql/bin sudo ln -s /usr/bin/mysql /usr/syno/mysql/bin/mysql
Flux non MAJ
Toujours en DSM 6, les flux ne se mettent pas à jour. En remplaçant le chemin vers l'exécutable PHP dans la conf du paquet tt-rss, ça fonctionne :
vi /var/services/web/tt-rss/config.php //define('PHP_EXECUTABLE', '/usr/bin/php'); define('PHP_EXECUTABLE', '/usr/local/bin/php56');
Puis redémarrer le paquet tt-rss via l'interface web (dans le “Package center, Tiny tiny RSS, Action: Stop” puis Start).
Audio Station
Audio station permet d'écouter dans un navigateur la musique stockée sur le NAS ; pour cela elle se base sur les dossiers indexés contenant de la musique (par défaut /Music). Pour changer ce répertoire par défaut ou ajouter d'autres dossiers contenant de la musique :
- dans le Panneau de configuration, aller dans “Service d'indexation”
- cliquer sur “Dossier indexé” et ajouter (ou modifier) le dossier contenant votre musique
- valider puis cliquer sur “Ré-indexer”
Pour qu'un utilisateur puisse utiliser Audio Station, aller dans le Panneau de configuration/Utilisateur ; cliquer sur l'utilisateur puis sur l'onglet Applications, et vérifier les droits.
Jellyfin
Logiciel de catalogue et lecteur multimédia en mode web. Dockerisable, Jellyfin existe en paquet SynoCommunity plus simple à installer (à accompagner avec le paquet ffmpeg, qui est proposé par l'assistant).
Avec DSM 7 il faut octroyer les droits d'accès au répertoire multimédia à l'utilisateur interne sc-jellyfin : pour cela aller dans le panneau de configuration> Dossier partagé ; clic droit sur le dossier> Modifier. Dans la fenêtre, choisir l'onglet Permissions, choisir dans la selectbox “Utilisateur du système interne” et donner les droits en Lecture seule l'utilisateur sc-jellyfin.
Virtualisation
A l'heure ou j'écris ces lignes la virtualisation est en version bêta, et non supportée sur les DS415+. Et de toute façon ils n'ont pas suffisamment de RAM (2 Go), comme indiqué dans les prérequis officiels.
En pratique on peut quand même tester le Virtual Machine Manager fraîchement pondu par Synology, moyennant :
- d'avoir un volume formaté en BTRFS
- d'augmenter la RAM (8 Go c'est bien)
- d'activer le “beta channel” dans le gestionnaire de paquets
Upgrade de la RAM
De base le boitier dispose de 2 Go de mémoire vive, ce qui est suffisant pour la grande majorité des utilisations. Cependant si l'on souhaite goûter à la joie de la virtualisation, il faut passer à 8 Go (maximum supporté sur le seul emplacement so-dimm de la carte mère). J'ai personnellement utilisé la barrette suivante : Crucial 8GB Single DDR3/DDR3L 1600 MT/S (PC3-12800) Unbuffered SODIMM 204-Pin Memory - CT102464BF160B, qui est celle la plus recommandée ça et là.
L'augmentation de la capacité mémoire n'est pas supportée par Synology sur ce modèle ; de ce fait on perd la garantie constructeur quand on ouvre le boitier. Ce dernier n'est pas conçu pour être ouvert facilement, mais c'est quand même largement accessible même par Mme Michu : il suffit de se munir d'un tournevis cruciforme.
insérer des images ici
Pour l'ouverture du boitier j'ai suivi ce modop de Charles Hooper.
Une fois la mémoire ajoutée, on pourra vérifier sa bonne prise en compte dans le Centre d'info :
Virtual Machine Manager
Normalement comme tous les paquets en bêta, Virtual Machine Manager n'apparait qu'en ayant coché la case “Oui je veux voir les versions bêta” dans les paramètres du Centre de Paquets. Mais pour les DS415+ il n'y est pas car pas officiellement supporté. Il faut donc installer le fichier .spk en téléchargeant la dernière version ici : https://usdl.synology.com/download/Package/spk/Virtualization/ ; puis cliquer sur “Installation manuelle”, et enfin sélectionner le fichier téléchargé.
Le paquet est ensuite disponible dans le menu principal :
Docker
Pour installer Docker, aller dans Centre de paquets > Docker > Installer
Installer pihole
Une fois Docker, installer, le lancer ;
- dans Registre on peut rechercher une image sur le dockerhub ; rechercher “pihole” et Télécharger l'image pihole/pihole (image officielle de pi-hole.net, ~333 Mo)
- une fois l'image téléchargée, elle apparaît dans le menu Image sous la forme “<image>/latest”, si on n'a pas spécifié de version spécifique. Sélectionner l'image puis cliquer sur Lancer. Cela pour effet d'instancier l'image, qui apparaitra, une fois configurée, sous la forme d'un Conteneur (dans le menu éponyme).
Pour la configuration, procéder comme suit :
- donner un nom au conteneur, par ex “pihole1”
- cliquer sur paramètres avancés
- dans Volume, on va partager des répertoires du Syno avec le conteneur, afin d'avoir certains états sauvegardés d'un lancement sur l'autre ; dans mon cas j'ai créer un dossier “docker”, puis un odssier par conteneur (dans ce cas-ci, “pihole”). Dedans, je créer un dossier pour la configuration du serveur DNS (dnsmasq.d) et un pour la configuration du pihole (pihole) ; ceux-ci seront montés, dans le conteneur, dans le répertoire
/etc:
#Fichier/Dossier Chemin d'accès docker/pihole/dnsmasq.d /etc/dnsmasq.d docker/pihole/pihole /etc/pihole
- dans l'onglet Réseau, sélectionner “Utiliser le même réseau que Docker Host”. Cela aura pour effet d'avoir l'interface du pihole qui répond sur la même adresse que le NAS.
- dans l'onglet Environnement, on va préciser les variables d'environnement pour configurer le conteneur ; on va ajouter celles-ci:
# mot de passe de l'interface web WEBPASSWORD=MDP4cc3sInterfaceWeb # Spécifie au pihole de répondre à tous les clients qui lui demande # Si on n'est pas sûr de ce que l'on veut faire, il vaut mieux préciser "local" # que "all", c'est plus sécure. DNSMASQ_LISTENING=all # port d'écoute de l'interface web du pihole WEB_PORT=8080 # bind le serveur web sur toutes les adresses locales du NAS #ServerIP=0.0.0.0 # si vous avez configuré un DNS pour votre Syno, vous pouvez le préciser ici VIRTUAL_HOST=pihole.local.perso # dans mon cas j'ai déjà un résolveur DNS, donc je le spécifie ici. Sinon, ne pas ajouter cette ligne PIHOLE_DNS_=192.168.1.65 # on peut préciser plusieurs forwarders séparés par un ";", et spécifier le port d'écoute avec #<PORT> PIHOLE_DNS_=192.168.1.65#5353;80.67.169.12;80.67.169.40
On clique sur Action > Démarrer et c'est parti, on peut logiquement accéder à l'interface web du pihole à partir sur http://IP_DU_SYNO:8080
A noter que si on choisit de changer des variables d'environnement après un premier lancement du conteneur, ça risque de planter car il semble qu'elles soient enregistrées dans une base du pihole ; dans mon cas par exemple j'ai voulu ajouter VIRTUAL_HOST à postériori, le conteneur n'a jamais voulu redémarrer en ma crachant le log :
::: Testing lighttpd config: Error: duplicate array-key: VIRTUAL_HOST. Please get rid of the duplicate entry.
Pour contourner cela, sélectionner le conteneur puis : “Paramètres > Paramètre en double”. Cela permettra de modifier les variables d'environnement tout en conservant les données partagées sur les volumes.
Mise à jour du conteneur
Globalement la procédure consiste à arrêter le conteneur, le supprimer, supprimer l'image locale, puis à télécharger la dernière image “latest”, et enfin recréer le conteneur. Pour automatiser la re-création du conteneur, on peut créer le user-script suivant dans le planificateur de tâche du syno (à lancer en root, et en désactivant la répétition pour ne le lancer que manuellement) :
docker run -d --name=pihole-new \ -e WEB_PORT=3443 \ -e WEBPASSWORD=MDP4cc3sInterfaceWeb \ -e DNSMASQ_LISTENING=local \ -e VIRTUAL_HOST=pihole.local.perso \ -e PIHOLE_DNS_=127.0.0.1#1053;192.168.1.65 \ -e TZ=FR \ -v docker/pihole/dnsmasq.d:/etc/dnsmasq.d \ -v docker/pihole/pihole:/etc/pihole \ --net=host \ --restart=unless-stopped \ pihole/pihole
Ressources :
Docs docker
Hyperbackup
Mise en place d'une sauvegarde Hyperbackup sur un NAS Synology vers un serveur rsync “compatible” (pas Synology) via SSH (en l'occurence un NAS OpenMediaVault v5).
Sur le serveur OMV distant : * créer un nouveau partage “bck-syno” dans Access Right Manager> Shared Folder * activer le SSHd et créer un utilisateur “usr-hbkp” ; l'ajouter dans le groupe SSH * activer le service rsyncd : dans Services> Rsync
- onglet Server : “Activer”
- créer un nouveau Module, déclarer le dossier partagé, activer “Authenticate users” et ajouter l'utilisateur usr-hbkp
Sur le NAS Syno source, installer puis lancer “Hyper Backup” ; puis créer une nouvelle sauvegarde : Serveur de fichier/Rsync :
- type : serveur compatible rsync
- chiffrement activé
- saisir l'IP distante, l'utilisateur usr-hbkp et son mot de passe SSH
- choisir le répertoire à sauvegarder
Lancer la sauvegarde. Les fichiers rsyncd.conf et rsyncd.secrets seront créés dans le dossier distant.
Tips
Installer les plugins OMV-extra
Vu ici : https://forum.openmediavault.org/index.php?thread/5549-omv-extras-org-plugin/
wget -O - https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install | bash
Connexion SSH
Pour se connecter en SSH au NAS, il faut activer le service dans le Panneau de configuration > System : Terminal & SNMP. Puis on s'y connecte soit avec le login “admin”, soit “root”. Le mot de passe est toujours celui du compte admin donc choisissez-le judicieusement.
NB : Depuis DSM 6, on ne peut plus se connecter avec le login root, il faut se connecter avec un compte utilisateur ayant les droits d'admin. Puis utiliser sudo.
Certificat SSL/TLS let's encrypt
Pour renouveler son certificat let's encrypt (qui n'est valide que 3 mois) :
- ouvrir le port public tcp/80 vers le port tcp/80 syno
- se logguer en SSH avec un compte admin au syno, puis :
sudo /usr/syno/sbin/syno-letsencrypt renew-all [ -v[v] ]; ex :
sudo /usr/syno/sbin/syno-letsencrypt renew-all -v DEBUG: Issuer name of certificate. [Let''s Encrypt]->[/usr/syno/etc/certificate/_archive/JjujoD/cert.pem] DEBUG: Issuer name of certificate. [Synology Inc.]->[/usr/syno/etc/certificate/_archive/lx0mfJ/cert.pem] DEBUG: certificate is not issued by Let''s encrypt. [/usr/syno/etc/certificate/_archive/lx0mfJ/cert.pem] DEBUG: start to renew [/usr/syno/etc/certificate/_archive/JjujoD]. DEBUG: setup acme url https://acme-v02.api.letsencrypt.org/directory DEBUG: GET Request: https://acme-v02.api.letsencrypt.org/directory DEBUG: GET Request: https://acme-v02.api.letsencrypt.org/acme/new-nonce DEBUG: Post JWS Request: https://acme-v02.api.letsencrypt.org/acme/new-order DEBUG: Post Request: https://acme-v02.api.letsencrypt.org/acme/new-order DEBUG: Failed to port map router detect. [1] DEBUG: failed to open port 80. DEBUG: Post JWS Request: https://acme-v02.api.letsencrypt.org/acme/authz-v3/41127559850 DEBUG: Post Request: https://acme-v02.api.letsencrypt.org/acme/authz-v3/41127559850 DEBUG: dns-01 is not support for toto.fr DEBUG: Setup challenge for toto.fr with type http-01 DEBUG: Post JWS Request: https://acme-v02.api.letsencrypt.org/acme/chall-v3/41127559850/iipDBw DEBUG: Post Request: https://acme-v02.api.letsencrypt.org/acme/chall-v3/41127559850/iipDBw DEBUG: Post JWS Request: https://acme-v02.api.letsencrypt.org/acme/authz-v3/41127559850 DEBUG: Post Request: https://acme-v02.api.letsencrypt.org/acme/authz-v3/41127559850 DEBUG: Post JWS Request: https://acme-v02.api.letsencrypt.org/acme/authz-v3/41127559850 DEBUG: Post Request: https://acme-v02.api.letsencrypt.org/acme/authz-v3/41127559850 DEBUG: ==> start new-cert. DEBUG: generate csr & private key DEBUG: get new-cert DEBUG: Post JWS Request: https://acme-v02.api.letsencrypt.org/acme/finalize/68533444/32870294000 DEBUG: Post Request: https://acme-v02.api.letsencrypt.org/acme/finalize/68533444/32870294000 DEBUG: Post JWS Request: https://acme-v02.api.letsencrypt.org/acme/cert/038012c726f8b4e7d4fa059921e49ffb6546 DEBUG: Post Request: https://acme-v02.api.letsencrypt.org/acme/cert/038012c726f8b4e7d4fa059921e49ffb6546 DEBUG: get issuer-cert DEBUG: save to files DEBUG: renew success. [/usr/syno/etc/certificate/_archive/JjujoD].
(PS : le sudo -i marche aussi)
Et si KO : penser à ouvrir bien grand (permit any any) le firewall Syno, cf anecdote qui suit.
Erreur syno-letsencrypt
TL;DR : Le problème vient d'un filtrage géographique dans le firewall du Syno. Malgré que celui-ci soit désactivé, il bloque quand même les serveurs de letsencrypt. En créant une règle permissive (genre permit any en HTTP) on fait tomber le script en marche !
Je suis récemment tombé sur un os lors du renouvellement de mon certificat letsencrypt : alors que la redirection tcp/80 était bien en place sur mon routeur, le script se vautre en renvoyant l'erreur suivante :
sudo /usr/syno/sbin/syno-letsencrypt renew-all -v [..] DEBUG: DNS challenge failed, reason: {"error":108,"file":"challenge.cpp","msg":"Not synology DDNS."} DEBUG: Normal challenge failed, reason: {"error":200,"file":"client.cpp","msg":"new_authz: unexpect httpcode."}
Sympa l'erreur : “unexpect httpcode”. Bon.
On passe en mode Columbo : on désactive le firewall du Syno et on relance le script avec l'option debug de la dernière chance (syno-letsencrypt -vv) ; on voit que notre Syno génère un fichier de “challenge” et le mettre à disposition des serveurs letsencrypt :
# morceaux choisis du debug : "error": { "type": "urn:acme:error:connection", "detail": "Fetching http://mydomain.com/.well-known/acme-challenge/YuOX1zXw-\ lD20Th6mHJzDNhBDkURHo1ZFBHxh5F-A-0: Timeout during connect (likely firewall problem)", "status": 400 }
Ce challenge permet de valider que :
- c'est bien vous qui avez initié la demande de renouvellement
- c'est bien vous le propriétaire du domaine
Ce fichier est mis à disposition en HTTP par le serveur nginx du Syno :
grep -Ri -A3 "acme-challenge" /etc/nginx/* /etc/nginx/nginx.conf- location ^~ /.well-known/acme-challenge { /etc/nginx/nginx.conf: root /var/lib/letsencrypt; /etc/nginx/nginx.conf- default_type text/plain; /etc/nginx/nginx.conf- }
C'est bourrin mais ça paie : le dossier est bien configuré dans nginx, et il est situé “en vrai” dans /var/lib/letsencrypt/.well-known/acme-challenge/ !
Le dossier existe bel et bien et dispose des bons droits, mais en fouinant dans les logs d'erreur du serveur nginx du Syno, je trouve ceci :
2018/11/02 15:35:20 [error] 6972#6972: *51124 access forbidden by rule, client: 64.78.149.164, server: _, request: \ "GET /.well-known/acme-challenge/56f1J6p6Wf3o-g219MmcZS7tCNufwA1Dj1Dm-ddGy1Y HTTP/1.1", host: "mydomain.com"
J'aime les erreurs “access forbidden by rule”, ça m'aide beaucoup : je n'ai jamais défini de règle de filtrage dans nginx et il n'y en a pas sur ce dossier…
Les fichiers de challenge sont temporaires et supprimés à la fin du script ; aussi on va faire le test avec un autre fichier :
echo "TEST" > /var/lib/letsencrypt/.well-known/acme-challenge/test
Puis, j'appelle le fichier depuis mon navigateur ou un wget :
wget -d http://mydomain.com/.well-known/acme-challenge/test [..] 2018-11-02 16:21:06 (121 KB/s) — « test » sauvegardé [5/5]
Et là ça passe !
C'est donc un filtrage en fonction de l'IP source ; n'ayant rien à perdre, je réactive le pare-feu de mon Syno et supprime le filtrage géographique (le champ “emplacement” dans la conf du firewall) : en mode “permit any any”. Je relance le script…
/usr/syno/sbin/syno-letsencrypt renew-all -v [..] DEBUG: renew success. [/usr/syno/etc/certificate/_archive/OufCaMarche].
… et BIM ça marche !
Aussi saugrenu que ça paraisse^W soit, chez Synology quand on décoche la case “Activer le pare-feu”, ben ça vaut pas dire que ça le désactive (même après reboot du NAS) ! Par ailleurs vu que c'est de l'iptables, c'est étonnant que cela puisse arriver dans les logs nginx…
Mais ma curiosité s'arrête là ; à dans 3 mois !
Erreur find en tâche planifiée
Description du problème : un script utilisant l'outil find, et qui se lance sans problème en CLI, ne s'exécute pas normalement lorsqu'il est lancé en tant que tâche planifiée (pourtant sous le même utilisateur) ; le message d'erreur est :
find: cannot get current directory: Permission denied
D'après ce thread sur stackoverflow, cela viendrait de l'implémentation du find sur ce système ; quoiqu'il en soit l'astuce indiquée du cd /tmp juste avant l'appel à find fonctionne à merveille pour moi.