This site uses cookies! Learn More

Ce site utilise des cookies !

En continuant à utiliser ce site, vous vous engagez à nous permettre de stocker des cookies sur votre ordinateur.

 

Si nous utilisons des cookies et retenons des données anonymes, c’est pour nous aider à mieux gérer notre mesure d’audience, aider nos partenaires commerciaux à nous rémunérer et nos partenaires publicitaires à proposer des annonces qui vous correspondent.

 

Grâce à ces cookies, le forum est en mesure de savoir qui écrit un message et utile pour le système d'authentification.

 

En cliquant sur « J'accepte », vous acceptez l'utilisation par NAS-Forum de cookies publicitaires et de mesure d'audience fine.

quenbo

Membres
  • Compteur de contenus

    58
  • Inscription

  • Dernière visite

À propos de quenbo

  • Rang
    Novice Syno

Visiteurs récents du profil

946 visualisations du profil
  1. BINGO ! J'étais persuadé que le Syno déconnait ! J'ai finalement remplacé en SSH les "vieux" certificats qui se trouvaient dans /usr/syno/etc/certificate/system/default et que je soupçonnais d'être mal utilisés, par ceux que je venais d'importer et qui se trouvaient dans /usr/syno/etc/certificate/_archive/ Un reboot du NAS et ça refonctionne enfin !!! Alleluia ! 😀
  2. Bonjour Zeus, merci pour la réponse. Je tiens quand même à préciser, suite à votre commentaire "... Tu as été jusqu'à ajouter des ports dans des entrées DNS..." que j'ai en effet utilisé les redirections proposées par OVH. Celles-ci me permettent facilement d'accéder au services de mon NAS en tapant, par ex. audio.ndd.fr plutôt que ndd.fr:46569 comme adresse, et c'est plus facile à retenir que les ports. Mais ces redirections se rajoutent automatiquement dans la zone DNS également, ce qui en effet surcharge un peu. Enfin bref... Puisque en effet ma zone DNS était un peu chargée, j'ai remis de l'ordre, sur vos conseils, et j'ai pu faire 2 choses : 1. réussir à créer un nouveau certificat Let's Encrypt à partir du Synology, ce qui ne fonctionnait pas avant, et qui m'a permis de récupérer le fameux "renew.json" manquant /usr/syno/etc/certificate/_archive/ymzCAP/renew.json Cependant, j'ai toujours une erreur dans Firefox, qui n'est plus "SSL_ERROR_BAD_CERT_DOMAIN" (Le certificat n’est valide que pour les noms suivants : mailconfig.ovh.net, www.mailconfig.ovh.net) mais est devenue "SEC_ERROR_UNKNOWN_ISSUER"(Le certificat n’est pas sûr car le certificat de l’autorité l’ayant délivré est inconnu.) 2. J'ai alors tenté d'utiliser à la place le certificat Wildcard (de SSL for Free), qui lui aussi fonctionne de la même façon avec "SEC_ERROR_UNKNOWN_ISSUER" dans certains cas Ce qui m'étonne, c'est que c'est le même message que pour les certificats autosignés ! ? Ce qui m'étonne encore plus, c'est que j'ai ce message pour une connexion vers le DSM ou PhotoStation mais que les autres connexions https vers AudioStation, NoteStation, ... fonctionnent sans problèmes ! => Donc les connexions à nas.ndd.fr:5001 (DSM) ou nas.ndd.fr:443 (photostation) sont KO, mais les autres connexions à nas.ndd.fr:8801 (AudioStation) ou nas.ndd.fr:9351 (NoteStation) fonctionnent ! Seul le port diffère ! ? ? ! J'en viens à me demander si le NAS ne se mélange pas dans ses certificats et présenterait soit le vieux certificat auto-signé (installé par défaut) pour la connexion DSM ou un certificat "vide" comme sur le printscreen. De plus, quand je clique sur afficher le certificat, je n'ai rien qui s'ouvre.
  3. @ZeusBon, avant de me lancer "profondément" dans ton tuto (et surtout dans le tuto serveur DNS de Ferir), j'ai d'abord tenté la création d'un certificat wildcard via sslforfree, à importer manuellement dans DSM... J'ai bien obtenu les certificats avec *.ndd.tld et ndd.tld, que j'ai importée correctement mais j'ai toujours une erreur dans Firefox... 😤 ndd.tld utilise un certificat de sécurité invalide. Le certificat n’est valide que pour les noms suivants : mailconfig.ovh.net, www.mailconfig.ovh.net Code d’erreur : SSL_ERROR_BAD_CERT_DOMAIN Apparemment, même si les adresses créée dans le certificat sont affichées correctement (*.ndd.tld et ndd.tld) dans sslforfree et dsm, il y a encore quelquechose qui foire, en lien avec le service mail ovh... Avez vous une idée? Merci !
  4. Ah ok... Ca me tente de plus en plus et je parcours ton topic mais je ne pige pas bien tes prérequis : - pour l' entrée CNAME avec "*.ndd.tld" chez son provider (je suis chez OVH aussi), tu crois que tu pourrais mettre un printscreen ? 😏 - pour la configuration du serveur DNS sur NAS (ou ailleurs), je comprends pas non plus ? Dans mon routeur j'utilise les DNS de cloudflare? Bref c'est un peu hors sujet mais bon. Merci +++
  5. Merci @Zeuspour la réponse. J'ai vu le topic pour un certificat wildcard via acme... mais je crois comprendre que le renouvellement automatique ne fonctionne pas encore à 100% chez toi ? J''attends maintenant la réponse de Synology chez lesquels j'ai déposé un ticket... On verra si, avant l'expiration du certificat, Synology ou d'autres forumeurs me répondent et savent m'aider ? Sinon je me retrousserai les manches une nouvelle fois...
  6. Merci pour ta réponse, malheureusement la démarche simple d'ajout de certificat via DSM ne fonctionne pas non plus. J'ai une erreur et dans le DSM et dans le log "Failed to create Let'sEncrypt certificate"...
  7. Salut à tous, vu le peu de réponse qu'inspirait mon premier post, je l'ai corrigé et précisé suite à différents essais de résolution... Je n'arrive pas ni a renouveller mon certificat Let's Encrypt, ni a en créer un nouveau, et le champ de couverture du certificat s'est restreint (le port du DSM n'est plus couvert)... Et il me reste 12 jours... Merci pour votre aide.
  8. Bonjour à tous, ayant reçu récemment, avec étonnement, un mail de Let's Encrypt m'invitant à renouveller mon certificat (installé depuis > 1 an) avant la fin du mois, j'ai d'abord tenté la commande suivante, qui n'a pas fonctionné...(mon port 80 est ouvert) /usr/syno/sbin/syno-letsencrypt renew-all -vv J'ai du forcer un hard reset de mon NAS il y a quelques temps et le certificat n'a pas bien vécu le passage semblerait-il... Bref, après quelques recherches, j'ai ouvert le log dans /var/log/messages et ai constaté le problème suivant : 2019-02-02T10:48:44+01:00 Diskstation syno-letsencrypt: syno-letsencrypt.cpp:312 can not find renew.json. [No such file or directory][/usr/syno/etc/certificate/_archive/ymzCAP/renew.json] En effet, le répertoire /usr/syno/etc/certificate/_archive/ymzCAP/ existe bien mais ne contient en effet que 4 fichiers *.pem : cert.pem, chain.pem, fullchain.pem, privkey.pem. Il n'y a pas de trace du fichier renew.json. Une petite lecture sur le net m'a suggéré de deleter l'ensemble de ce dossier _archive afin de resetter l'installation correcte des certificats (et de renew.json), puis de tenter renouveler mon certificat, mais ce delete a entrainé une erreur de volume sur un des disques du Syno ??? (qui a vérifié longuement sa cohérence de parité). Après redémarrage, un certificat autosigné "Synology.com" s'est réinstallé par défaut... J'ai réimporté mes clés de certficat let's encrypt, mais ce certificat maintenant ne couvre plus mon port 25001 (utilisé pour DSM) mais bien celui d'autres applications comme NoteStation... J'ai donc un message de connexion non sécurisée lors de la connexion au DSM, mais pas à NoteStation... Et ceci n'a pas corrigé non plus mon problème de renouvellement du certificat, car la commande " /usr/syno/sbin/syno-letsencrypt renew-all -vv " me renvoie toujours la même erreur de "renew.json not find" root@Diskstation:~# /usr/syno/sbin/syno-letsencrypt renew-all -vv DEBUG: Issuer name of certificate. [Let's Encrypt]->[/usr/syno/etc/certificate/_archive/l3npXZ/cert.pem] J'ai alors voulu demander un tout nouveau certificat Let's Encrypt àpd du DSM mais j'ai l'erreur suivante "failed to create Let's Encrypt certificate : (je suis chez OVH) 2019-02-02T12:17:51+01:00 Diskstation synoscgi_SYNO.Core.Certificate.LetsEncrypt_1_create[12501]: certificate.cpp:973 syno-letsencrypt failed. 102 [Invalid response from http://MONSITE.FR/.well-known/acme-challenge/B_-FMOcsiyIqDbCRt-qjXJwwXOZs8cFGRRFQfHcBR1s: "<html xml:lang=\"fr-FR\" lang=\"fr-FR\">\n<head>\n<title qtlid=\"28806\">Félicitations ! Votre domaine a bien été créé chez OVH !</"] 2019-02-02T12:17:51+01:00 Diskstation synoscgi_SYNO.Core.Certificate.LetsEncrypt_1_create[12501]: certificate.cpp:1392 Failed to create Let'sEncrypt certificate. [102][Invalid response from http://MONSITE.FR/.well-known/acme-challenge/B_-FMOcsiyIqDbCRt-qjXJwwXOZs8cFGRRFQfHcBR1s: "<html xml:lang=\"fr-FR\" lang=\"fr-FR\">\n<head>\n<title qtlid=\"28806\">Félicitations ! Votre domaine a bien été créé chez OVH !</"] Bref je ne sais plus trop quoi faire et viens vers vous pour voir si quelqu'un a une idée de solution et/ou peut vérifier l'existence de ce fameux "renew.json" chez lui et, si ce fichier est standard, me l'envoyer ? Pour des raisons de sécurité vous comprendrez bien je n'accepterai ce fichier que de forumeurs "reconnus"... D'ores et déjà merci pour votre aide, Quenbo
  9. Bonjour à tous, depuis la RAZ de mon Syno, un problème "bizarre" est survenu dans Download Station, qui m’empêche de lancer les torrents. Si je dépose via glisser-déposer un torrent dans la fenêtre de DLStation, la fenêtre de choix du répertoire cible s'ouvre comme d'habitude, mais lors de la validation, j'ai un message "Echec de l'opération" qui empêche le torrent de s'ajouter. J'ai essayé avec plusieurs torrents de plusieurs sites et ça le fait à chaque coup. J'ai vérifié si le user connecté dans DownloadStation avait les droits et c'est le cas. J'ai stoppé/redémarré le paquet. J'ai désinstallé/réinstallé le paquet, avec puis sans conservation des paramètres. J'ai vérifié via WinSCP que, avant de réinstaller, tout était bien viré de var/package et de volume1/@download. Tout ça sans succès... Par contre, j'ai découvert par chance l'option "dossier surveillé" (où Download Station va directement lancer tous les torrents déposés dans le répertoire)... Et là ça marche, pour les mêmes torrents ! Mais c'est moins pratique car on ne sait pas sélectionner le répertoire cible ni sélectionner certains fichiers du torrent ! Avez vous une idée sur la cause de ce comportement bizarre? Merci pour vos réponses !
  10. Bonjour à tous, j'aimerais savoir s'il est possible de forcer l'installation d'un paquet même si le Syno le refuse et le considère incompatible : "Ce paquet n'est pas pris en charge sur la plate-forme Diskstation ou est incompatible avec la version actuelle de DSM" En effet, depuis la mise à jour DSM 6.1, le paquet Plex n'était plus supporté sur mon DS213+, mais comme il était resté installé sur mon système depuis le DSM 6.0, je pouvais toujours le lancer par une commande : /var/packages/Plex\ Media\ Server/scripts/start-stop-status start Et le paquet fonctionnait alors parfaitement même s'il apparaissait désactivé dans le centre de paquets 🙂 Malheureusement, j'ai dû resetter mon DSM et, bien évidemment, le paquet a été supprimé de /var/packages/Plex. Donc ça ne marche plus. Je voudrais donc savoir si il est possible de soit : - éditer un des fichiers du fichier spk (après ouverture dans 7-zip) pour leurrer le DSM sur la version installée et le faire installer malgré tout - installer manuellement les fichiers présents dans le paquet spk en var/packages/ (mais je connais peu Linux et ai peur que ça ne marche pas sans un tuto un peu clair pour moi) (via putty ou Winscp?) Merci pour votre aide ! Quenbo
  11. quenbo

    Où sont planqués les fichiers .torrent originaux ?

    Ah ok merci pour les infos (notamment le transmission-edit) Finalement mon post est intéressant, on apprend des trucs !
  12. quenbo

    Où sont planqués les fichiers .torrent originaux ?

    @agnotos : c'est clair que se taper 800 torrents à la main, c'est un peu chaud... Perso j'en garde entre 20 et 50 actifs et je nettoie régulièrement, surtout que je garde pas tous les films dans /video/ une fois visionnés... Ca me permet un upload de 8 à 10 Go par jour et c'est bien assez. Et mes 4 To commencent à être étroits... (j'ai des films en 4K de 40 à 60 Go donc ça n'aide pas). Donc dans mon cas ça reste jouable à la main. Je n'ai pas les compétences pour attaquer la DB en postgres et je joue avec putty/winSCP mais avec prudence et modération. J'avais tenté des lignes de commande pour modifier tous mes torrents en /volume1/@download/XXX/XXX.torrent mais mes torrents se sont tous mis en "invalides"... Bizarre car les adresses des torrents étaient modifiées correctement mais il semblerait que le fait d'ouvrir et de refermer le fichier torrent avait modifié des caractères "cabalistiques" dans le corps du fichier torrent... (des caractères qui apparaissent dans un cadre noir quand j'ouvre le fichier dans Notepad++) Pour info voici les lignes de commande : J'ai essayé ceci, torrent par torrent : sed -i -e 's@adresse1@adresse2@g' /volume1/@download/541/541.torrent Puis ceci, avec scan des sous-répertoire : find . -name "*.txt" | xargs sed -i .old -e "s/adresse1/adresse2/g" Ca m'avait l'air bon mais bon comme je l'ai dit ça a fait foirer mes torrents...
  13. quenbo

    Où sont planqués les fichiers .torrent originaux ?

    Merci pour ta réponse. Entretemps j'ai fini par voir que l'adresse du tracker était bonne mais qu'il était down. Comme l'adresse vient de changer de nouveau, j'ai finalement utilisé l'astuce de Salamafet dans un autre post qui était de rajouter la bonne adresse du tracker directement dans DLStation, puis de supprimer l'ancien tracker foireux ---- Posté(e) 3 novembre 2014 (modifié) --- Vue que l'url du tracker et la même pour tout les torrents, il suffit d'ajouter un tracker pour chaque torrent en collant l'url à chaque fois. Exemple: http://tracker.t411.me:8880/la_clef_du_compte/announce EDIT: Par contre il faut ce taper tout les torrents un par un :/
  14. Bonjour à tous, suite à un changement de tracker, je me suis "amusé" à remplacer tous les fichiers xxx.torrent originaux présents dans /volume1/@download/XXX/xxx.torrent par les nouveaux torrent avec la bonne adresse, que j'ai retéléchargé un à un du site web et rangé un à un dans les bons dossiers /volume1/@download/XXX/ par la commande mv (après avoir coupé DL Station) En vérifiant donc les fichiers .torrents directement dans /volume1/@download/XXX/, la bonne adresse du tracker était marquée et tout semblait rouler, DL Station redémarrait nickel. Je trouvais juste mon upload un peu bas ces derniers temps. Par hasard, en cliquant sur "télécharger le torrent d'origine" dans DL Station, j'ai découvert à ma grande surprise que ce torrent téléchargé contenait tjs l'ancienne adresse, alors que le fichier torrent dans le répertoire correspondant /volume1/@download/XXX/XXX.torrent contient lui la nouvelle adresse !!! Encore plus fort, en supprimant le "nouveau" fichier .torrent de /volume1/@download/XXX/XXX.torrent et en relancant DL Station, je m'attendais à ce que le torrent se mette en erreur... Et bien non, il redémarre correctement dans DLStation et le "vieux" fichier .torrent est recréé dans /volume1/@download/XXX/XXX.torrent J'en déduis donc que le Synology garde une copie cachée du torrent original, qu'il utilise constamment, et finalement se contrefiche du torrent localisé dans /volume1/@download/XXX/XXX.torrent. Quelqu'un sait-il où trouver ces torrents cachés et/ou a-t-il une autre solution ? Merci ! PS : je n'utilise pas Transmission et ne comprends d'ailleurs pas trop la différence entre les 2, ou la complémentarité de Transmission par rapport à DL Station
  15. quenbo

    Plus de backup depuis DSM 6.0.1-7393 Update 1

    @gaetan.cambier Merci pour les infos. Je suppose que si je veux profiter du "versioning" offert par Hyperbackup je suis "obligé" de passer par leur système de base de données propriétaires (qui découpe les fichiers) et que mes backup actuels en "rsync avec fichiers directement lisibles" (sur le NAS de mon frère) ne sont pas réutilisables pour cet Hyper Backup... Car le backup devrait être fait via le cloud (pas possible de déplacer un des 2 NAS) et ça avait pris des plombes la première fois. EDIT : Synology a tout prévu, comme je vois sur leur site... Cliquez sur + dans le coin inférieur gauche et sélectionnez Tâche de sauvegarde des données pour lancer l'assistant de sauvegarde. Sélectionnez le type de destination de sauvegarde souhaité. Configurez le type souhaité de tâche de sauvegarde : Pour créer une toute nouvelle tâche, sélectionnez Créer une tâche de sauvegarde. Pour réutiliser des données de sauvegarde existantes sur une destination, sélectionnez Se reconnecter à une tâche existante. La reconnexion vous aide à utiliser directement les données de sauvegarde provenant d'une tâche différente. Suivez les instructions de l'assistant pour finaliser les paramètres. (c'est le genre de détails où je me félicite d'avoir acheté un NAS chez eux !) EDIT 2 : Bon ben je me suis emballé un peu trop! En essayant de me "reconnecter à une tache existante" afin d'utiliser mes données en clair sur le NAS de mon frère, j'obtiens un message : Le format de sauvegarde de cette cible n'est pas pris en charge... En même temps c'était presque trop beau que Hyperbackup arrive à remouliner les données en local sur le NAS de mon frère pour les convertir dans son format propriétaire de DB...