Ivanovitch

vendu a Elgger.

Hello, je peux te faire l'ensemble pour 600e cash. Par contre je suis pas motorisé et vu le poids, ce sera à venir chercher chez moi (métro Chatillon ligne 13). Go MP si ça te va.

c'est toujours d'actualité si il y a des intéressés pour ce nice matos 😮 !! prix / délottage possible vu la durée de l'annonce (et flemme de mettre en vente ailleurs, si ca continue ca va finir en backup @2nd home 😄 ) ps: je vérifie la batterie du 5P650IR périodiquement, mais elle ne semble ne pas se décharger (ou très lentement), c'est de la bonne came 😄 !

oui en effet l'onduleur est plus long que le nas, c'est le plus court que j'avais trouvé en 1U à l'époque... je peux te faire le nas seul pour 500e edit: l'onduleur fait moins de 36cm de prof cependant (mesure depuis les oreilles en face avant), juste 4cm de plus que le nas et, avec des connecteurs iec pas trop gros je pense qu'il est possible de rester sous les 36. A voir ptet que ca passe suivant les dimensions de ton rack ? voir photo :

toujours d'actualité.

- Modèle : Syno RS819 & Eaton 5P650IR (rackables 1U) - Facture : oui - Date d'acquisition : sep. 2020 - Pourquoi vous vous en séparez : rs1221+ à la place & onduleur 2U - Avec ou sans disque : sans - Prix souhaités : 700e le lot - Frais de livraison : 30e - Pays de livraison : France uniquement - Garantie : oui, une lettre de cession sera fournie le nas et l'onduleur n'ont servis que quelques mois et sont quasi neufs, il étaient en standby power off depuis l'achat du 1221+ en février 2021

Non, cette string d'erreur est envoyée en cas d'échec d'authentification, quel qu'il soit (cf. le code :: L114).

sinon, pour les histoires de pare-feu (à priori ce que axb rencontrait comme problème un peu au dessus) il faut au moins ouvrir le port 443 du pare-feu du synology (pas celui de la box !) pour les conteneurs dockers en bridge (c'est le cas dans ce tuto) ! Ils sont considérés comme externes d'un point de vue de dsm (7) et de son PF. en mode parano on ouvrirai uniquement pour l'ip du docker acme le 443 en destination tcp (mais elle peux changer si j'ai bien compris docker, donc pas génial) ou, moins parano toutes les IP du bridge0 docker ( 172.17.0.0/16 ). pour le deploy il faut aussi ouvrir le port http dsm (encore une fois, que du syno, pas nécessaire sur la box) Mais mieux encore, et a moins que vous ne fassiez pas confiance à votre propre lan, autorisez tout pour les plages d'ip locales de la rfc1918, c'est à dire en toutes premières règles du pf, autoriser tout pour les 10.0.0.0/8, 172.16.0.0/12 (qui intègre donc le 172.17.0.0/16) et 192.168.0.0/16. C'est ce qui est décrit dans tuto de Fenrir sur la sécurisation du nas partie config du PF 🙂 edit: pour ceux qui utilisent le serveur dns du syno, il faut aussi ouvrir le port de celui ci (53)

je sais pas si on parle de la même chose, mais pour les soucis ovh évoqués les pages d'avant, mon bugfix a été mergé dans le master acme (et donc le docker) il y a 4 jours donc normal 😜 ! quand tu dit "supprimé les autres certificats", tu veux dire que tu as suppr les certs générés par acme et gardé que ceux en convertis par openssl ? si oui c'est normal qu'il arrive pas a les déployer, il veux utiliser ceux qu'il a généré lui 😜! t'es bon pour redemander un nouveau cert et refaire le deploy (à priori pas besoin de passer par l'étape conversion + import manuel cette fois ! )

pour le pare feu, tu aurais pas bloqué les USA par hasard ? Sinon, c'est que tu as oublié le pramètre --dns dns_ovh lors dans demande de certificat, dans ce cas le comportement par défaut d'acme est une vérification HTTP-01, la même que celle de DSM et qui nécessite donc l'ouverture des ports 80 et 443 (si c'est ça ils sont donc aussi ouverts sur ton routeur !!)... sinon saute l'étape 3A, j'ai pas trop compris pourquoi le tuto réclame ça. @Einsteinium te rappelles-tu ce qui t'avais amené à passer par un import manuel ? ca m'intéresse 😛 edit: j'ai relu le début du thread, c'est pour forcer tous les services internes du dsm a s'attacher du cert ? moi comme j'utilise un SAVED_SYNO_Certificate='' vide, ca remplace le cert par défaut, qui est seul et utilisé pour tout chez moi, pas besoin d'import donc 😄 Donc @axb, dans ton account.conf tu dois avoir ceci SAVED_SYNO_Scheme='http' SAVED_SYNO_Hostname='172.17.0.1' SAVED_SYNO_Port='ton port' SAVED_SYNO_Username='username' SAVED_SYNO_Password='username_password' SAVED_SYNO_Certificate='' http et non https (inutile de faire du https car tu reste sur la même machine) : à priori déjà OK d'apres ton log l'ip doit rester a 172.17.0.1 (et non pas l'ip locale de ton nas comme dans ton log) le port lui doit bien être le port HTTP de ton dsm (64.... d'après ton log) le SAVED_SYNO_DID pas la peine de le mettre, ca sert a rien si t'as pas la double auth (qui est de façon inutile si t'as bien restreint les droits de ton SAVED_SYNO_Username au strict minimum et bien activé fail2ban (protection de compte compte dans les options dsm). SAVED_SYNO_Certificate='' doit donc rester vide pour te dispenser du step 3A, ca remplacera le cert par défaut directement il faut aussi que tu edites le fichier /docker/Acme/domain.tld/domain.tld.conf et que tu supprimes (on remplace, au choix) les lignes SAVED_SYNO_xxx pour que acme prenne en compte tes modifs du account.conf enfin tu lance en ssh root ou par tache exec unique root : docker exec Acme --deploy -d domain.tld --deploy-hook synology_dsm si tout est OK tu dois voir [Fri Jul 23 20:22:38 UTC 2021] Logging into 172.17.0.1:tonport [Fri Jul 23 20:22:38 UTC 2021] Getting certificates in Synology DSM [Fri Jul 23 20:22:38 UTC 2021] Generate form POST request [Fri Jul 23 20:22:38 UTC 2021] Upload certificate to the Synology DSM [Fri Jul 23 20:22:42 UTC 2021] http services were restarted [Fri Jul 23 20:22:42 UTC 2021] Success le "http services were restarted" est important, c'est ce qui confirme que les serveurs web du dsm ont bien pris en compte le nouveau certificat (on aura un "not restarted" si on ne fait que rajouter / remplacer un certificat non-défaut). En dernière vérif: refresh la page web dsm (relance ton navigateur au besoin pour forcer le refresh) et dans le cadenas à coté de l'url, regardes les propriétés du cert, tu devrais bien avoir ton wildcard dans details / subject alternative name vala 🙂

Yep, faut plutôt voir ça comme un ultime garde-fou (on ne doit recevoir aucun e-mail si le docker marche car il renouvelle à 60 jours, les mails eux ne commencent qu’à 70). L’avantage c’est que c’est indépendant de toute config sur le Nas 🙂 !

Je ne pense pas non, mais tu peux toujours le faire au cas où tu supprimerai le dossier /ca , qui occasionnerai la création d’un nouveau compte Letsencrypt, tu n’aurais alors pas besoin de repasser la commande update-account 😉

tant que j'y pense, si vous voulez que let's encrypt vous envoie un mail de rappel pour le renouvellement (ça commence à partir de 20 jours de validité restante sur les 90 si on a pas déjà renouvelé) vous pouvez ajouter à votre account.conf avant la première demande de certificat : ACCOUNT_EMAIL='votre@email.tld' si vous avez déjà un certificat mis en place par acme (et donc un compte letsencrypt, automatiquement crée lors de la toute première demande), il faut passer la commande (en ssh ou tache planifiée exec unique) docker exec Acme --update-account --accountemail 'votre@email.tld' qui doit retourner account update success for https://acme-v02.api.letsencrypt.org/acme/acct/xxxxxxxxx c'est un mécanisme finalement assez utile, ça permet de se rendre compte si le docker déconne 🙂

si le firewall de ton syno est actif, tu peux essayer de le désactiver temporairement ? le account.conf, tu l'as bien crée depuis l'éditeur de texte du syno en mode utf-8 ? car si tu l'as crée sur windows, les fin de lignes (caractère invisible cr-lf sur windows vs lf sur linux) peuvent foutre en carafe quand acme le relis. sinon, peux-tu paste la sortie de docker inspect Acme a call en ssh sur le nas

yep, c'est tout à fait ce que je j'observe et décrit dans l'issue github j'ai testé mon fix comme un porc et y'a plus aucun soucis ni de délivrance du certificat ni de pollution, yay 😄 !

ma PR a été mergée dans la branche dev, neil à meme pas posé de question donc mon fix sera dispo sur le docker à la prochaine release (merge de dev vers master) en attendant, si vous avez le problème, la seule solution est d'insister comme un porc sur la requête issue, ça fini par passer... c'est normal que tu vois des requetes /domain/zone/__acme-challenge.ndd.tld par contre elles doivent être refusées avec un 403 Unauthorized + "this call has not been granted" des fois elles ne le sont pas et acme considère que ton domaine est "__acme-challenge.ndd.tld" au lieu de "ndd.tld" et ca fait déconner tout le reste vu que c'est pas le bon domaine 😂

pour info, j'ai bien galéré, mais j'ai fini par trouver et ai proposé un patch pour fix le bug d'ajout/suppression des TXT https://github.com/acmesh-official/acme.sh/issues/3616

problème de config réseau en dirait, acme.sh arrive pas à contacter l'API LE. ton nas à bien accès au net ? en ssh dessus, tu peux ping letsencrypt.org ? sinon un log plus long pourrais aider...

bon j'ai une piste qui indiquerai que c'est pas les API ovh qui déconnent mais acme.sh... quand ça fail, c'est le script qui construit une requête "records of the zone" mal formée de Ia forme get domain/zone/_acme-challenge.ndd.tld/record?... au lieu de get domain/zone/ndd.tld/record?... l'api répond du json pour dire que ca n'existe pas (obviously, c'est pas le bon domaine). Le script lui s'attends à l'ID (rid, record id) associé au TXT demandé dans les params du get... il essaye de continuer avec le json au lieu d'un long int sur le call d'après (get record id properties ) et se fait jeter par curl qui lui dit requete mal formée 😄 ! maintenant reste à trouver pourquoi... si c'est avéré j'irai ouvrir une issue (ou ptet une PR de fix si c'est facile) sur GH 🙂 bon, peux pas tester plus maintenant, incident let's encrypt 🤣

ahah, je vois je suis donc pas fou 😂 ton script sera plus que le bienvenu !! Je viens de faire 10 essais de suite: 100% ok : 1 cert ok mais suppr record nok : 2 nok no cert : 7 donc, même avec le script de bruno pour dépolluer la zone, on est sur un taux de réussite de seulement 30% 🥴 Et à priori c'est juste OVH qui déconne car -sur les problèmes que je vois- la partie LE concerne uniquement l'acquisition des challenges à mettre dans les TXT, pas leur création / suppression. A continuer de tester dans les jours/semaines qui suivent mais si OVH continue à faire des siennes, une solution plus pérenne pourrait être délocaliser la zone DNS chez DigitalOcean, CloudFlare, ... pas idéal mais bon 😕 C'est un txt nommé __acme_challenge.ndd.tld ? tu peux le supprimer, car justement il est (sont) normalement crée et détruit durant la procédure de renouvellement

oulah oui en effet😅 ! C'est corrigé, c'était à cause mon extension Dark Reader (pour pas se buter les yeux dans le noir) !

bon ca fait 10 ans que j'ai un compte ici, faudrait ptet que je me présente 😄 ! - Votre âge : ~30 - Votre niveau en informatique : dev 😛 pas trop dans le domaine linux à la base (embarqué, genre petit microcontrôleurs) mais j'y viens petit à petit ! - Vous avez quel modèle de nas et de disque dans celui ci. RS1221+ avec 2 ssd ironwolf pro de 1TB en raid 1 et 3 HDD ironwolf 6TB (les plus gros modeles seagate en 5400rpm) en SHR pour le reste upgradé à fond avec 32GB de ram crucial ECC, une carte réseau 2*10 GB mellanox connect-x 3 MCX312B double sfp+ connecté à un unifi switch aggregation en DAC lui même connecté à une unifi dream machine pro qui choppe son net direct depuis l'ONT FTTH RED (thx lafibre.info ), et j'ai un failover 4G via un modem nighthawk M1 4G (les coupures fibre chez red sont pas si rares que ça....) tout ca dans un rack startech 12U qui héberge aussi mon pc principal dans un boitier 4U. Homelab FTW! Ayy un onduleur 2U 1000VA cyberpower aussi. Bel engin 20kg+ ! j'ai aussi un RS819 qui me sert de backup / test / roue de secours... mais il va probablement partir sur la section A/V ! - Vous êtes utilisateur d’un synology depuis longtemps ? Vous avez eu d’autres modèles avant ? depuis dsm4 je crois, j'ai commencé par un 1511+ qui est monté progressivement à 5*2TB - Un peu d’informations sur votre utilisation, services, paquets, etc... dockers & vm en tout genre pour le taff, en perso en ce moment je teste pleins de trucs pour la domotique: home assistant, esphome, node red, grafana, influxdb, home bridge, ... j'ouvrirai probablement un volet media avec la série des dockers rrrrr par la suite

salut à tous et un grand merci pour le tuto ! est-ce que vous rencontrez des problèmes aléatoires avec les APIs OVH ? Elle sont super instables chez moi: un coup tout passe, un coup c'est un des deux txt record add qui fail (du coup pas de cert derrière), un coup c'est le delete record qui fail (donc cert obtenu mais ca poubellise ma zone DNS)... je précise que quand c'est 100% OK ou quand j'ai juste erreur sur la suppression d'un des record txt je peux continuer et déployer le cert sans soucis. j'ai supprimé puis recrée les API plusieurs fois: ça ne change rien. Surtout, si elles étaient crées NOK ca ne passerai jamais... https://api.ovh.com/createToken/?GET=/domain/zone/ndd.tld/*&POST=/domain/zone/ndd.tld/*&PUT=/domain/zone/ndd.tld/*&GET=/domain/zone/ndd.tld&DELETE=/domain/zone/ndd.tld/record/* pas d'espace alakon ni rien donc voici ma procédure de test ssh root (pas sudo, vrai root par clé) docker run --rm -itd --name=AcmeSSL -v /volume1/docker/AcmeSSL:/acme.sh neilpang/acme.sh daemon puis la boucle de test en elle même: docker exec AcmeSSL --issue --keylength 4096 -d ndd.tld -d *.ndd.tld --dns dns_ovh --test suppr dossiers ca & ndd.tld du volume (pour pouvoir boucler sans se manger un 'domain already verified') go to 1 utilisation du --test pour utiliser les serveurs staging de LE, histoire de pas consommer les 5 certs/semaine comme je lance le docker en --rm je peux éventuellement faire un RAZ total en faisant un docker stop AcmeSSL mais en pratique ca change rien à l'occurrence je vais essayer de faire flow de test un peu plus debuggable avec un soft genre Postman, mais déjà si des gens ici ont une idée / observent la même chose ...?