Einsteinium

Yep tu refais une instance dans un fresh dossier en sautant l’étape 3 et rock n roll 😉

Hummmm (J’ai eu la notif 🚀) Alors si je comprends bien tu as ton nas avec ton ndd qui est déployer en auto et tu voudrais juste générer les certificats de ton pote, alors oui cela ne gênera en rien sur ton nas, tu fais une seconde instance et tu saute la partie pour le déploiement automatique (Et le premier import manuel du coup), te suffira juste de faire un dossier partager dans lequel le certificat sera accessible par ton amis qui viendra le récupérer tous les 2 mois. Par contre si tu veux lui déployer en auto le certificat alors tu lui fais l’import manuel, puis de ton nas le déploiement automatique en utilisant son ndd et la il aura rien a faire. (Avec un compte qui n’a accès à aucun service, accessible que de ton ip et un mot de passe fort bien sûrs)

Pour différencier les demandes et éviter les écrasements ou renouvellement par erreur si multiple demande ?!?

L’application est sur toutes les plateformes et marche plutôt bien 🙂

Sa marche, je vais voir si je peux le faire rapidement ou pas 🙂

Ahhh super pour ce retour, donc on ne peut pas simplement insérer une clef usb avec les key pour le déverrouillage direct au reboot comme actuellement ? Concernant l’intérêt de faire un dossier crypté sur un volume crypté c’est sans intérêt de mon point de vue. Je pense que je vais migré en volume full crypté pour les performances. L’idée est bonne, je retiens.

J’ai pas de soucis non plus pour ma part.

J’avais pas vu le message, 12€/mois encore Je regarde pour voir

@firlin Moi je mets le domaine, afin de bien différencier quand je liste les api, mais sinon oui tu mets ce que tu veux

Pas compris il manque des mots ^^ Mais oui tu peux utiliser les mêmes clés d’api si tu n’as pas mis de blocage IP sur cette dernière.

@firlin https://api.ovh.com/console/#/me/api/application~GET Si je dis pas de bêtise c’est là (mais pour voir la liste seulement) Par contre à moins de voir ce que tu as mis dans le config du premier, tu ne récupéra pas les clefs, faudra la refaire et supprimer la première ou en faire une seconde.

D’accord 3 certificats, peu être la cause alors. J’ai deux domaines pour ma part qui pointe vers le syno, mais j’ai fais un seul wildcard pour inclure les deux domaines. )et je n’ai aucune base64 dans mes fichiers)

J’ai épinglé ton message du coup, mais je ne voyais pas en quoi changer le tutoriel dans la mesure ou dans son était actuel je l’ai déployé encore chez 3 personnes avec succès le mois dernier et chez moi aucun changement fait et tout roule. Tu n’avais rien modifier @Mic13710 ? Clé d’api, compte syno ? A mon avis c’est le Pass World en base64 qui est la cause du problème.

@MilesTEG1 Regarde ma réponse j'ai edit entre deux 😂

@MilesTEG1 Edit je viens de voir : Skip, Next renewal time is: 2023-04-30T00:11:08Z Donc en faites non ton certificat n'a qu'un mois... que dit ton certificat niveau navigateur quand tu visites le site ? Car je vois rien d'anormal... Remonte dans les logs acme lors du dernier renouvellement, à mon avis le déploiement dsm à foiré 😉

Aucune modification prévue… je viens encore d’appliquer avec succès le tutoriel aujourd’hui.

Déjà répondu, j’ai vue ses variables la est aucun soucis.

@Kramlech @oracle7 J’ai été voir directement en manuel, effectivement version 3.0.6, après il est vrai que acme ce met à jour indépendamment du docker, donc c’est que le problème ne vient pas de la version, ayant eu mon update il y a 4 jours sans soucis.

Bonjour, De ce que je vois, c’est un problème de jeton d’accès ovh. j’ai pas été voir les dates de publication des versions, mais mon dernier update avec succès date du 8 février pour information. Je viens d’aller voir github… je me rappel qu’il y avait un problème avec watchtower sur les update de cette image, donc j’avais stoppé une semaine le stack… Le 4 février j’ai relancé le stack… donc en fessant cela… même si j’étais en 3.0.6, je suis repassé directement en 3.0.5 😉 Donc si tu l’as pas compris, supprime et refais le docker 😉 Tu ne perd rien de tes configs 😉

Cela est une suite au reboot du nas généralement, si tu ne veux pas avoir cela, il faut stopper le stack avant reboot, sinon tu le supprimes et recré, cela sera bon 😉

@TuringFan : D ) Réclamer le serveur plex Pour cette étape, il faudra être rapide, après obtention du token, vous aurez 4 minutes. 1 ) Visitez cette page Plex Token et copiez le token obtenu 2 ) Modifiez notre fichier "dockerplex.sh" puis rajoutez la variable : -e PLEX_CLAIM=tokenobtenu \ 3 ) Exécutez manuellement de nouveau la tâche du point "II -> C" 4 ) Votre serveur est maintenant réclamé, supprimez la variable rajoutée au point "II -> D -> 2" Effectivement il faudra que je veille à mettre à jour ce tutoriel

Nan un Google cloud illimité avec rsync. Perso je place à 10% tous mes docker sauf Plex à 50%, je tient à ce que Plex soit prioritaire sur les autres, mais pas au niveau du système 🙂 Merci, sa fait plaisir a lire ☺️

perso aucun soucis, presque instantané, sachant que ma bibliothèque est crypté dans le cloud.

10 = bas, 50 = moyen, 100 = max, synology powered 😉

C’est la priorité des processeurs 🙂