tops
-
Compteur de contenus
20 -
Inscription
-
Dernière visite
-
Jours gagnés
1
Messages posté(e)s par tops
-
-
Hello,
Merci pour ce tuto détaillé et très clair.
Mes seuls problèmes ont été :
DOSSIEREXPORTJe ne sais pourquoi mais au début je pensais qu'il faillait indiquer le répertoire du certificat que l'on souhaite remplacer ... mais s'était tellement illogique car non expliqué. La réponse est donnée dans le fil de discussion : c'est une étape temporaire le temps d'installer pour la première fois le certificat sur le syno.
Donc il faut juste indiquer un répertoire simple d'accès depuis l'interface de création de certificat du syno.
SAVED_SYNO_Scheme='http' SAVED_SYNO_Hostname='172.17.0.1' SAVED_SYNO_Port='5000' SAVED_SYNO_Username='nom utilisateur' SAVED_SYNO_Password='le password' SAVED_SYNO_DID='' SAVED_SYNO_Certificate='description du certificat mise dans le DSM'J'ai préféré passer en https et rajouter le DID du user dédié ... la bête n'a pas aimé. La solution est donné ici : https://github.com/acmesh-official/acme.sh/wiki/deployhooks#20-deploy-the-cert-into-synology-dsm
When using https to connect to "localhost" we need to add the --insecure option to the deploy command. refer to [https://github.com/acmesh-official/acme.sh/wiki/Options-and-Params]. If you enabled HTTP/2 you still receive a curl 16 error but the script succeeds.
Donc la dernière commande devient :
docker exec Acme sh -c "acme.sh --insecure --deploy -d 'mydomain.com' --deploy-hook synology_dsm"Le 18/06/2021 à 16:28, MilesTEG1 a dit :@Einsteinium Pour le tuto, ce serait pas mal, je pense, d'ajouter une mention en couleur sur ta dernière édition pour le DEFAULT_ACME_SERVER car certains ont peut-être commencé le tuto sans le finir, et s'ils le reprennent ils ne verront peut-être pas l'ajout.
Et ils ne liront peut-être pas nos derniers échanges, surtout que c'est passé sur une nouvelle page depuis qu'on a évoqué ça 🙂Je te confirme que ton post m'a fait gagner du temps 😀
1 -
Le 07/05/2016 à 16:21, CoolRaoul a dit :
Les étapes 8 à 10 ci dessus sont inutiles: traditionnellement, les options en commentaire dans le sshd_config pré-installé n'ont d'autre rôle que de documenter les options par défaut. Les dé-commenter ne change donc rien
Je précise que c'est optionnel dans le tuto ... par contre, je ne comprends pas bien comment le NAS va accepter la clef que l'on vient lui donner si on ne décommente pas les 2 lignes ...
Le 07/05/2016 à 17:04, CoolRaoul a dit :Je ne vois pas comment cela peut marcher: il n'est pas possible de se connecter "root" à DSM (et ça ne date pas de DSM6) en utilisant SFTP (SSH ou SCP ok par contre si on a bien enregistré la clé publique dans ~root/.ssh/authorized_keys)
C'est justement tout l'objet de ce tuto que de rajouter une clef publique ... encore heureux que cela marche du coup ;)
Le 07/05/2016 à 17:04, CoolRaoul a dit :L'utilisation de cette option "allow the connection agent" présuppose qu'on utilise l'agent (pageant téléchargé avec putty) alors que le tuto n'en parle pas. De plus dans ce cas, il est inutile de spécifier de "private key file" dans Auth parameters.
Je n'utilise pas Pageant ... la manip marche parfaitement même sans avoir installé putty (qui lui l'utilise ... nan on me demande pas pourquoi ^^).
Le 07/05/2016 à 17:04, CoolRaoul a dit :Inutile de préfixer ce "vi" (ainsi que les suivants) de "sudo" étant donné qu'on est *déjà* root (de part le "sudo -l -U root" précédent)
Exact ... sauf que cela ne marche pas chez moi après test (access denied par exemple avec vi /etc/ssh/sshd_config)
Le 07/05/2016 à 17:04, CoolRaoul a dit :C'est normal que ca ne fonctionne pas en SFTP : DSM ne supporte pas les connexions root dans ce mode.
DSM suppose les connections root en SFTP ... en tout cas, cela marche parfaitement sur les 2 NAS à ma dispo.
Le 07/05/2016 à 17:04, CoolRaoul a dit :Si Putty échoue avec un refus de clé c'est que le chemin du fichier de clé privé spécifié dans sa propre configuration de session (Connexion -> SSH -> AUTH -> "authentication parameters") est erroné ou manquant. Mais je te conseille d'utiliser Pageant. Lancé au démarrage de ta session windows, on y charge la clé privée et ensuite plus besoin de retaper sa passphrase jusqu'au prochain login (s'assurer pour cela que dans putty Connexion -> SSH -> AUTH -> "authentication methods", "attempt authentication using pageant" est coché))
Ci-dessous la config ... à noter que mon port SSH n'est évidement pas le 22 (pas fou ^^) mais cela ne change rien au tuto.
A noter aussi que l'on peut décocher "Attempt auth using Pageant", cela marchera quand même (histoire de ne pas penser que Pageant est manquant dans le tuto ;)).
0 -
Hello,
Ayant trouvé mon chemin pour me log en root, je vous donne la recette ;-)
Pour commencer, je n'ai rien inventé, j'ai trouvé mon inspiration ici : http://www.mauchle.name/blog/?p=239&cpage=1#comment-29143
Mes modifications sont en "jaune".
(1) Download PuTTY and PuTTYgen (or just get the installer, everything is in there).
(2) Generate a keypair with PuTTYgen (Parameters: SSH-2 RSA)
(3) Save the private key as “myprivatekey.ppk”
(4) Copy the public key to the clipboard. Looks somewhat like this :
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAzP4MR3lkCD2pa7nwT3NMjjDBMmEuJ4exW4GKBBP+okArZ/IrjbLIpdh8ahpfgjh8kM//OVUGeRa1GigzcCuGzIa2YfS7L4Q9cbUUWFwIu2hGV3ZpJ2xDZExaaLH90Vw+ZBaozD2OI4FZ1Dqh8Bj29SQqIIbmxf/ASyTmXHZCbQk= rsa-key-20130414(5) Connect to your diskstation with PuTTY
diskstation:22(6) Login as
rootadmin (obviously the root will not work on DSM 6 ... so use any administrator account like the original "admin")(7) Elevate your admin user to "root" by typing (then all your command lines will have to be precidered by "sudo " to be executed as "root") :
sudo -l -U root*** Steps 8 to 10 are probably optional based on CoolRaoul comments .... based on my experience, sudo remains needed otherwise you will not have the rights to open / change files ***
(8) Edit the SSH config with
sudo vi /etc/ssh/sshd_config(9) Look for the following lines (using the keyboard arrows up & down) :
#RSAAuthentication yes #PubkeyAuthentication yes #AuthorizedKeysFile .ssh/authorized_keys(10) Change them to this (by hitting “x” when the cursor is over the # and hitting ESC, then typing :wq ENTER).
There is not visible effect after having hitted ESC ... do not search and type :wq ENTER
#RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys(11) Go to /root and create the .ssh folder
(the .ssh dir was already existing in my DSM ... try to go directly to 12.
IF the step 12 is not working ... then type
sudo -sThen, type
cd /root mkdir .sshThen, type
Exit(12) Edit the keyfile
sudo vi /root/.ssh/authorized_keys(13) Press “i”, paste your public key (right clic) and save the file (Hit Esc, type :wq, hit Enter)
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAzP4MR3lkCD2pa7nwT3NMjjDBMmEuJ4exW4GKBBP+okArZ/IrjbLIpdh8ahpfgjh8kM//OVUGeRa1GigzcCuGzIa2YfS7L4Q9cbUUWFwIu2hGV3ZpJ2xDZExaaLH90Vw+ZBaozD2OI4FZ1Dqh8Bj29SQqIIbmxf/ASyTmXHZCbQk= rsa-key-20130414(14) Set the access-rights to the file
sudo chmod 700 /root/.ssh sudo chmod 644 /root/.ssh/authorized_keys(15) Disconnect with
exit(16) Open Putty again and make the following settings
In session :
- Hostname or IP
- Port: 22
- Connection type: SSH
In Connection
- Data->Auto-login username: root
- SSH->Auth->Private Key: Your Keyfile
In session, save the session as <sessionname>
(17) Open WinSCP
- Add a new site
- Select "SFTP"
- Add the Hostname (or IP) and SSH port
- Add as username "root"
- In Advanced > SSH > Auth > Auth parameters : select the same SSH key file as in (16) and tic the option "allow the connection agent"
- Save and log
0 -
pour firefox, historique, clique droit sur le site : oublier ce site
Marche pas non plus dans mon cas ...
Autant sur Chrome, la solution était rapide, autant sur fox, j'ai vraiment pas eu le choix : suppression du profil.
0 -
J'ai fini par creuser et trouvé du côté du stockage dans Firefox ...
Pour Chrome, j'avais déjà fait la manip conseillé dans ton lien avec succès. Mais pour Firefox, niet ... suppression comme expliqué dans le lien, suppression de tous les cookies, suppression des certificats "serveur", safe, ... Peau de balle, rien n'avait marché.
J'ai fini par virer Firefox du PC ... et dégager le dossier %user%\AppData\Roaming\Mozilla ... et là impeccable !
Et si je réinstalle mon profil via Firefox Sync, ca marche sans problèmes.
Bref t'avais vu juste et s'était bien le navigateur qui avait gardé en tête un truc. Je ne saurai jamais où cela était planqué par contre !
Pour Chrome, c'est la même ... il faut aller supprimer tous les trucs qui trainent dans appdata, prog files, ... après désinstallation.
Merci pour tes réponses !
0 -
Bien vu ... mais j'ai essayé et cela sans succès.
Et puis concernant Firefox, il est mentionné que si un site accédé en HTTP, le header STS est ignoré. Il faut que le site fasse un renvoi sur HTTPS lui-même. Je suppose donc que le NAS redirige les sites HTTP vers du HTTPS et qu'après cela devient le bordel total ... reste à savoir pourquoi il me fait des redirections de son propre chef sur des sites sous /web
Quand à avoir le même problème sur deux NAS au même moment ? Avec zéro modif de paramétrage sur les deux NAS ? Ca sent la mise à jour qui fait des trucs pas nets !
0 -
Edit :
J'ai le même soucis sur un autre NAS qui n'est pas dans le même bâtiment ...
A noter que sur celui-ci le HSTS n'est activé nul part et que je rencontre aussi un problème ... pour le coup c'est un NAS hyper clean sans aucun paquet tiers installé (backup) donc le problème est forcément lié au Syno en lui-même. Hors même la dernière mise à jour ne fait aucune mention d'un changement concernant HSTS ...
0 -
Hello,
Petit soucis depuis ce matin mon NAS redirige toutes les adresses HTTP de format "domain.com" vers du HTTPS. Le problème a moins de 15 jours puisque je ne l'avais pas depuis mon lieu de vacances ... La chose est parfaitement normale pour les adresses comme l'accès au DSM mais par contre me faire cela pour des sites installés à la mano dans le /web ou avec des paquets comme sonarr ???? WTF !
Je me balade pour trouver une solution et :
1/ http:// domaine.com:8989 donne https:// domaine.com:8989 il redirige tout vers https, les paquets, les sites web, ... même la page video station pour laquelle j'ai spécifiée un port HTTP 2/ 192.168.xxx.xxx:8989 donne 192.168.xxx.xxx:8989 sans aucune redirection. 3/ Firefox et chrome me font la même blague ... Edge lui me sort les sites sans broncher.Bref ... le problème est lié à une fonctionnalité des navigateurs que Edge n'a pas ? Je continue de chercher et là bim :
Ce site a recours à HTTP Strict Transport Security (HSTS) pour indiquer à Firefox de n'établir qu'une connexion sécurisée. Ainsi il n'est pas possible d'ajouter d'exception pour ce certificat. xxxxxxxx utilise un certificat de sécurité invalide. Le certificat n'est valide que pour les noms suivants : nas.xxxxxxxx.com, xxxxxxxx.com, mail.xxxxxxxx.com (Code d'erreur : ssl_error_bad_cert_domain)Du coup, je vais dans le NAS et je vire le HSTS qui était activé pour les services web (pourtant je ne me rappelle pas d'avoir touché à cela) ... je reboot le NAS pour faire bonne mesure ...
Aucun changement ... cette connerie de HSTS continue à faire mumuse !!!!Je teste dans chrome en virant le domaine : https://kamaradski.com/2856/chrome-clear-hsts-state-http-strict-transport-security
Bingo ! Ca marche. J'ai un backup ... mais je ne comprends pas pourquoi le NAS continue d'utiliser HSTS !J'ai essayer de totalement désactiver le HTTPS pour les services web ainsi que pour le DSM ... mais cela ne change rien non plus.
Conclusion
- Pouvez-vous me dire si j'ai oublié un truc quelque part pour virer HSTS ?
- Peut-on virer cette connerie en SSL ?
SOLUTION :
Essayer de supprimer le jeton HSTS : http://classically.me/blogs/how-clear-hsts-settings-major-browsers
Si cela ne marche pas :
- Firefox : Supprimer le dossier de profil %user%\AppData\Roaming\Mozilla
- Chrome : Désinstaller avec suppression des données utilisateur
0 -
1er point :
Je remarque aussi un truc con, mais très très con ... l'autocompletion de firefox forçait quelques champs de saisie dans mes pages de configuration.
> J'ai honte !
2eme point:
J'ai fini par modifier le détenteur des répertoires + files en passant de sickbeard:root à sickbeard:users.
Il n'y a pas photo ... j'arrive parfaitement à sauver !
3eme point:
SSL ... pas bon non plus !
Vu les retours sur le forums, il y a quelques points bête à ne pas louper qu'il faudrait "épingler" au début de la liste ...
- ne pas utiliser le SSL
- ne jamais faire un update du paquet sans arrêter le dit paquet
- l'importance de la casse (je sais ... très con mais lorsque l'on est pas un habitué de Linux, cela quitte facilement la checklist)
- idem pour les chemins absolus
- ...
0 -
Raahhhhh ...
Mais où sont stockés les paramètres pour qu'ils puissent revenir comme cela à un état inital ?!
J'ai essayé toutes les options, SSL, pas SSL, avec et sans mot de passe, j'ai changé les dates, ... rien à faire.
Sickbeard revient systématiquement sur la configuration par défaut et détaille
Je suis pourtant sur une installation toute fraiche où rien ne pourrait faire que le config.ini plante.
Personne n'a d'idée ?
0 -
Après réinstallation totale du NAS ...
Je reste sur les "fesses" :
- le bug du save qui tourne en rond est toujours là
- et dès qu'il se produit ... j'ai l'impression que le config.ini prend une claque et revient à une configuration antérieure
Le mot de passe "buepumber55779" (qui semble être le mdp par défaut) est revenu tout seul ! Alors qu'en exécutant la commande (more /usr/local/sickbeard/var/config.ini) 20 secondes avant j'avais le bon mot de passe.
0 -
Bah de toute manière, j'ai pris la décision : RAZ du NAS.
Ca va prendre une plombe de faire l'aller-retour du paquet de RAW qui restent dessus mais c'est plus sûr ...
0 -
Et voici le résultat :
Petite précision, j'ai désinstallé le soft et refait une installation toute propre ... lorsque je vais pour la première fois dans les paramètres, les paramètres sont déjà erronés (mais le save marche) ... j'ai eu le malheur de demander le SSL et bim : save qui tourne en rond
J'ai regardé l'arbo avant de reinstaller et tous les dossiers sickbeard avaient bien disparus. Les paramètres sont stockés autre part visiblement et truc que je ne comprend pas ... "web_password = buepumber55779" : je n'ai jamais vu ce mot de passe de ma vie ! Dois-je y voir un trou dans la sécurité de mon NAS ?
Je sens que je vais faire une copie de mon backup et reformater ce NAS là ... chiant mais au moins je serai propre !
NAS_SITH> more /usr/local/sickbeard/var/config.ini [General] log_dir = Logs web_port = 8081 web_host = 0.0.0.0 web_ipv6 = 0 web_log = 0 web_root = "" web_username = "" web_password = buepumber55779 use_api = 0 api_key = "" enable_https = 0 https_cert = server.crt https_key = server.key use_nzbs = 1 use_torrents = 0 nzb_method = blackhole usenet_retention = 500 search_frequency = 60 download_propers = 1 quality_default = 3 status_default = 5 season_folders_format = Season %02d --More-- (11% of 3665 bytes)
0 -
Après vérif, c'est bien sickbeard:root
Sinon, vérifie dans ton config.ini que TOUT les chemins indiqués sont absolus
Là, tu vas devoir me donner un peu la main
J'avoue ne pas savoir comment ouvrir ce fichu config.ini. Pas faute d'avoir cherché sur google mais je n'ai pas trouvé de tuto expliquant les choses "basiques" comme celle-ci (d'ailleurs si tu as une url pour éclairer le newbee ^^).Thanks à tous pour le coup de main ! C'est sacrément plaisant de voir une communauté aussi sympa
0 -
Voilà ce que cela donne :
drwxr-sr-x 6 sickbear root 4096 Sep 12 20:18 . drwxr-xr-x 6 sickbear root 4096 Sep 9 20:51 .. drwxr-sr-x 2 sickbear root 4096 Sep 9 20:51 Logs drwxr-sr-x 4 sickbear root 4096 Sep 10 00:16 cache -rw-r--r-- 1 sickbear root 99328 Sep 12 20:18 cache.db -rw------- 1 sickbear root 0 Sep 12 20:18 config.ini drwx--S--- 2 sickbear root 4096 Sep 10 00:23 logs -rw-r--r-- 1 sickbear root 2099200 Sep 12 20:18 sickbeard.db -rw-r--r-- 1 sickbear root 9216 Sep 9 20:51 sickbeard.db.v0 drwx--S--- 2 sickbear root 4096 Sep 10 00:21 topvader
0 -
Hélas ...
J'ai bien exécuté la commande en "root" mais cela ne change rien.
0 -
Merci Diaoul.
Je vais tester cela et voir si le problème se corrige !
0 -
Hello,
Je rencontre de petits soucis avec Sickbeard ... celui-ci ne veut plus sauvegarder les paramètres de configuration et me fait la misère avec le SSL
Je m'explique :
SSL : Je me prends un message d'erreur qui me dépasse. Pas vraiment eu le temps de creuser la chose mais s'est en tout cas la première fois que je le croise !
Une erreur est survenue pendant une connexion à xxxxxx.com:8081.
SSL a reçu un enregistrement qui dépasse la longueur maximale autorisée.
(Code d'erreur : ssl_error_rx_record_too_long)
Config :
Je crois qu'une image parlera plus ...
https://picasaweb.go...feat=directlink
Le saving tourne en boucle et ne semble plus vouloir accepter de modifications.Un rechargement de la page (F5) permet de voir que certaines modif sont prises en comptes ... mais elles finissent toujours pas revenir à l'état avant "bug de la sauvegarde".
Je note que cela donne un truc très étonnant avec le dossier des Logs, qui passe tout seul sous le nom d'un user utilisé dans les paramètres des providers de NZB. J'ai aussi le problème dans l'onglet "Search Options", où fréquence de recherche reste plantée avec un nom d'utilisateur au lieu d'une durée en chiffres.
Je précise que cela déconne de la même manière avec le pack superzebulon ... exactement le même soucis (le SSL marchant pour le coup ^^).
Moi pas comprendre ! Help
0 -
Hasp Package
dans Corbeille
Hello !
Je n'ai trouvé nul part d'info sur l'utilisation de ce plugin ! Avez-vous un lien vers un tuto ou de la doc synology ?
Thanks !
Antoine
0
[TUTO] Docker : Introduction
dans Tutoriels
Posté(e)
Merci pour ce tuto ... je n'ai pas encore exploité mais juste rapidement parcouru la 1 ère page et c'est déjà une mine d'or et un travail de collecte / mise en forme incroyable.
Merci pour cela !