Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
informatique:hardware:synology_ds415plus [2018/01/15 14:37] – [Virtualisation] pteu | informatique:hardware:synology_ds415plus [2018/11/02 16:29] – Erreur syno-letsencrypt pteu |
---|
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 [[https://www.synology.com/en-global/knowledgebase/DSM/help/Virtualization/requirements_and_limitations|prérequis officiels]]. | 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 [[https://www.synology.com/en-global/knowledgebase/DSM/help/Virtualization/requirements_and_limitations|prérequis officiels]]. |
| |
En pratique on peut palier à ces problèmes moyennant d'avoir un volume formaté en BRTFS, pour tester le nouveau paquet Virtual Machine Manager fraîchement pondu par Synology. | En pratique on peut quand même tester le **Virtual Machine Manager** fraîchement pondu par Synology, moyennant : |
| * d'avoir un volume formaté en [[https://fr.wikipedia.org/wiki/Btrfs|BTRFS]] |
| * d'augmenter la RAM (8 Go c'est bien) |
| * d'activer le "beta channel" dans le gestionnaire de paquets |
| |
====Upgrade de la RAM==== | ====Upgrade de la RAM==== |
====Certificat SSL/TLS let's encrypt==== | ====Certificat SSL/TLS let's encrypt==== |
| |
Pour revalider son certificat [[https://letsencrypt.org/|let's encrypt]] (qui n'est valide que 3 mois) : | Pour renouveler son certificat [[https://letsencrypt.org/|let's encrypt]] (qui n'est valide que 3 mois) : |
* ouvrir le port tcp/80 vers le syno | * ouvrir le port public tcp/80 vers le port tcp/80 syno |
* lancer en tant que root (login SSH + ''sudo -i'') | * se logguer en SSH avec un compte admin au syno, puis : |
<code bash> | <code bash> |
/usr/syno/sbin/syno-letsencrypt renew-all | sudo /usr/syno/sbin/syno-letsencrypt renew-all [ -v[v] ] |
</code> | </code> |
| (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==== |
| |
| 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 : |
| <code bash> |
| 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."} |
| </code> |
| |
| 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 : |
| <code bash> |
| # 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 |
| } |
| </code> |
| |
| 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 : |
| <code bash> |
| 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- } |
| </code> |
| 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 : |
| <code bash> |
| 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" |
| </code> |
| 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 : |
| <code bash> |
| echo "TEST" > /var/lib/letsencrypt/.well-known/acme-challenge/test |
| </code> |
| |
| Puis, j'appelle le fichier depuis mon navigateur ou un wget : |
| <code bash> |
| wget -d http://mydomain.com/.well-known/acme-challenge/test |
| [..] |
| 2018-11-02 16:21:06 (121 KB/s) — « test » sauvegardé [5/5] |
| </code> |
| 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... |
| <code bash> |
| /usr/syno/sbin/syno-letsencrypt renew-all -v |
| [..] |
| DEBUG: renew success. [/usr/syno/etc/certificate/_archive/OufCaMarche]. |
| </code> |
| ... 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 [[https://stackoverflow.com/questions/5791651/find-is-returning-find-permission-denied-but-i-am-not-searching-in|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. |
| |
=====Liens===== | =====Liens===== |