CoolRaoul

Dans quelle partie de l'interface a-t-on une liste de chaines avec un menu droit avec "sélectionner tout"? Je trouve pas! Suis allé dans "Modifier les canaux'" et effacé une par une mais la scan ne m'a trouvé que deux chaines, c'est pas suffisant comme remise à zero?

Avez-vous remarqué que, pour la France, dans "Region" le scan propose en plus de "All" les choix "All_166" et ALL_834": Est-ce que quelqu'un aurait eu la patience de tester avec les 3 options (je ne sais pas à quoi ça correspond)?

Hyper Backup Explorer, téléchargeable sur le site Syno, section téléchargements Dispo pour Windows et Ubuntu uniquement (pour l'instant):

Son problème est que son syno a migré sous DSM6 et que sous cette version l'accès root ssh/telnet n'est plus possible directement. Faut désormais se connecter admin et faire un "sudo -i" pour se retrouver root. Ça à été évoqué à de multiples reprises ici même dans le forum, les sujets qui en parlent ne devraient pas être difficiles à trouver.

J'ai récupéré une sauvegarde perso du tuto qui intègre les dernières modifications pour compatibilité DSM6. Je l'ai restaurée dans un nouveau fil de la même section du forum (tutos) Si tu n'as pas appliqué ces modifs, ça ne peux pas fonctionner en DSM6. Rassure-toi, elles sont mineures. Ne sont (marginalement) touchés que le script de démarrage et le fichier de conf ssl. Si après ça tu rencontres toujours des problèmes, postes dans le nouveau fil nginx

Impec Je teste ça et l'intègre dans le tuto des que la situation est rétablie (original effacé par moi même comme un gland, donc on reste sur ce fil de backup ou on repart sur l'original)

Merci!

Et sinon, pour une éventuelle restauration, puis-je me contenter de ce fil ou mieux vaut-il le doubler d'un autre dans "Accueil -> A propos de ce forum -> Aide & Support Technique" ?

Arrêtes, tu m'a presque fait verser une larme. Je suis aller jeter un oeil à la home page de mon premier FAI, IBM (si si): http://web.archive.org/web/19961106073156/http://www.ibm.net/

Décidemment... sont habitués de ce genre de gag chez Syno!

Pas d'inquiétude pour le tuto en lui-même: j'ai une sauvegarde à jour (datée de lundi), au format HTML source, qu'on récupère par ce bouton de la barre d'outils: Ca serait inconfortable de demander au lecteurs d'aller lire les réponse en cache par contre. A ce propos, il y a également ça qui pourrait être plus pérenne que chez Google

En fait elle n'est disponible que sur les fil qu'on a soi-même commencé (ça peut se défendre) Mais en temps normal le bouton est *en haut à droite du post initial du fil*. La, le voyant en bas à droite de la réponse en cours de rédaction que je voulais effacer (bug), j'ai pas trop réfléchi et cliqué dessus. **EDIT** Je viens de vérifier, il y a bien une demande confirmation (je suis une quiche) mais elle ne rappelle pas que c'est *tout* le fil qu'on s’apprête à effacer par contre.

un "top" en ligne de commande nous donnerait plus d'info. Sinon, faut savoir que suite à la migration DSM6, le Syno fait une opération de type de celle mentionnée ici. (par contre chercher l'utilité de ce bidule est au delà de ma patience) Ca prend pas mal de temps avec le CPU à fond mais ca fini par se calmer (et ça n'est effectué qu'une seule fois) Sur le mien je m'étais aussi inquiété et capturé la commande en cours d'exécution: root 00:00:00 /bin/sh -e /proc/self/fd/9 root 00:00:00 \_ /bin/sh -e /proc/self/fd/9 root 00:29:24 \_ /usr/bin/openssl dhparam -outform pem -rand /dev/urandom -out /usr/syno/etc/

Je viens d'effacer par erreur le fil "reverse proxy avec nginx" de la secrion "tutos" du forum! J'étais en train de répondre à une question dans le fil, l'éditeur de message à déconné, j'ai voulu effacer le post en cours de rédaction et pour cela j'ai eu le malheur de cliquer sur: qui se trouvait en bas à droite (là ou il y a d'habitude, encore un bug d'IPB... ). Je pensais supprimer juste le message, mais ça a effacé l'intégralité du fil sans la demande de confirmation si je me souviens bien! Coup de pot, j'ai une sauvegarde récente du premier post (merci à l'option "source" de l'éditeur, récemment ajouté à ma demande, qui m'a permis de le faire) mais il y a-t-il un espoir d'avoir une restauration du fil *complet*? Note: j'ai déjà reposté ma sauvegarde mais la section est modérée, et vu que j'ai un autre post toujours en attente de modération depuis Lundi dans "Aide & Support Technique" j'ai peur que l'admin soit en congés. Donc, en désespoir de cause je viens ici au bar pour noyer mon désespoir

Depuis peu, DSM intègre nativement nginx (Merci à Piwi pour l'info) Voila qui nous offre donc une 3eme manière d'implémenter un reverse proxy (en alternative à la modif de conf Apache ou l'utilisation de haproxy). Merci de consulter l'historique des modifications à la fin du post Principe de base Pour ne rien risquer de "casser" dans la configuration du serveur nginx système DSM nous allons utiliser une deuxième instance dédiée, réservée à la fonction de reverse proxy. Les deux instance n'auront aucun fichiers en commun et tourneront de façon entièrement indépendante. Ce dernier va être à l'écoute sur deux ports TCP, un pour le http et l'autre pour https. Comme pour haproxy il conviendra de rediriger sur sa box ou son routeur les connexions entrantes sur les ports http et https standard (80 et 443) vers chacun des ports choisi. Dans la suite du tuto utilisera les ports 6080 et 6043 mais bien entendu chacun peut choisir. Important: Il est requis que ces deux ports internes soient ouverts dans le firewall du Syno (si celui-ci est activé) Préalable: Mettre en oeuvre la redirection de ports dans la box, exemple dans le cas d'une freebox: Configuration nginx Il est préférable de définir un répertoire dédié à la config nginx sur le NAS, je préconise "/usr/local/etc/nginx" (à créer) On va décomposer la configuration dans 3 fichiers pour éviter les répétitions (tous seront à créer dans ce répertoire): fichier principal: "nginx.conf" options proxy: "proxy_defaults.conf" options SSL: "ssl_defaults.conf" nginx.conf Sa structure est la suivante: user http; #+ # chemin du log à remplacer à votre convenance # attention: dans l'état il ne fait que grossir # mettre la ligne en commentaire ou prévoir un mécanisme de rotation #- error_log /var/log/nginx-site-error.log; events { worker_connections 1024; } http { access_log off; proxy_temp_path /var/lib/nginx-local/proxy; # # Default servers # server { listen *:6080 default_server; listen *:6443 default_server ssl; server_name _; include ssl_defaults.conf; location / { proxy_pass http://localhost:80/; include proxy_defaults.conf; } } <déclaration vhost 1> <déclaration vhost 2> ... <déclaration vhost n> } La déclaration "server" initiale sert à rediriger par défaut sur le serveur webstation les requêtes ne correspondant pas à un vhost spécifique. Les VirtualHosts suivants sont à ajouter suivant vos besoins vers les différents services du NAS Exemple de contenu de vhost pour l'interface DSM gérant HTTP et HTTPS: server { listen *:6080; listen *:6443 ssl; server_name ~^dsm..*$; underscores_in_headers on; #uniquement necessaire pour le vhost DSM include ssl_defaults.conf; location / { proxy_pass http://localhost:5000/; include proxy_defaults.conf; } } La syntaxe un peu étrange pour "server_name" est une expression régulière permettant de rediriger toutes les requêtes dont la partie "host" commence par "dsm." (telles que "http://dsm.votre_domaine") vers le port 5000 local. On notera l'utilisation d'un backend http (l'url assiciée à proxy_pass) pouvant être accédé par un front-end https (listen). Dans ce cas le protocole SSL est entièrement géré par nginx, coté interne, en local on est en full http, suivant le schema: <navigateur> <-- HTTPS --> NGINX <--- HTTP --> <service>. Pour les autres services, Il suffit d'ajouter autant de blocs "server" que nécessaire, voici un exemple pour filestation: server { listen *:6080; listen *:6443 ssl; server_name ~^filestation..*$; include ssl_defaults.conf; location / { proxy_pass http://localhost:7000/; include proxy_defaults.conf; } } la définition ci dessus va permettre de rediriger les requêtes de "filestation.votre-domaine" vers le service filestation (quel que soit "votre-domaine") On remarquera que, grâce au support d'expressions régulières dans la clause "server_name", il n'est pas nécessaire de mettre en dur le nom de domaine dans la config. Il peut-être plus lisible et pratique de créer des fichiers séparés pour chaque vhost et de remplacer les blocs par des lignes: include <fichier> ou, mieux, mettre tous les fichiers de déclaration de vhosts dans un unique dossier dédié et utiliser une seule ligne include, exemple: include services.d/*.conf Attention: quand on utilise dans les "include" des chemins relatifs comme ci-dessus (c.a.d sans "/" initial), le répertoire par défaut est celui où se trouve le fichier "nginx.conf", le dossier "services.d" doit donc être situé au même endroit. Filtrage IP dans les blocs "location" on peut ajouter des clauses "allow" et/ou "deny" pour filtrer l'acces au bloc en fonction de l'ip du client, de façon similaire au clauses apache équivalente. La syntaxe est simplement une série de clauses: Allow <IP ou IP Range>; et Deny <IP ou IP Range>; IP ou IP Range utilise la même syntaxe que dans les .htaccess (y compris la pseudo addresse "All"). C'est la première (de haut en bas) action (allow ou deny) qui "matche" l'IP du client qui sera appliquée. Webdav Webdav peut necessiter d'ajouter la clause "client_max_body_size 20M;" dans les blocs "server" des vhosts correspondants pour éviter une erreur de type "413 Request Entity Too Large" dans le cas d'upload de fichiers volumineux (20M pour 20 MegaBytes, à régler suivant votre besoin). Ce qui donne: server { listen *:6080; listen *:6443 ssl; server_name ~^webdav..*$; client_max_body_size 20M; include ssl_defaults.conf; location / { proxy_pass http://localhost:5005/; include proxy_defaults.conf; } } proxy_defaults.conf proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_http_version 1.1; # CF: http://serverfault.com/questions/372886/prevent-nginx-from-redirecting-traffic-from-https-to-http-when-used-as-a-reverse proxy_redirect http:// $scheme://; # CF: https://gist.github.com/micho/1712812 proxy_set_header X-Client-Verify SUCCESS; proxy_set_header X-Client-DN $ssl_client_s_dn; proxy_set_header X-SSL-Subject $ssl_client_s_dn; proxy_set_header X-SSL-Issuer $ssl_client_i_dn; ssl_defaults.conf # NOTE: décommenter un (et un seul) des deux blocks suivants # (pour une compatibilité à partir de windows vista et openssl 1.0.1) ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers ECDHE+AESGCM:ECDHE+AES; # Pour une compatibilité à partir de Windows XP et openssl 0.9.8 ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers ECDHE+AESGCM:ECDHE+AES:DES-CBC3-SHA; ssl_prefer_server_ciphers on; # DSM5: décommenter les deux lignes suivantes #ssl_certificate /usr/syno/etc/ssl/ssl.crt/server.crt; #ssl_certificate_key /usr/syno/etc/ssl/ssl.key/server.key; # DSM6: utiliser les deux lignes suivantes (commenter sinon) ssl_certificate /usr/syno/etc/certificate/system/default/fullchain.pem; ssl_certificate_key /usr/syno/etc/certificate/system/default/privkey.pem; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; Lancement de nginx Pour que nginx soit démarré automatiquement au boot du NAS, il est nécessaire de le faire via un script shell, situé dans "/usr/local/etc/rc.d/". On va le nommer "nginx.sh" (le .sh est requis). Attention de le rendre exécutable (chmod +x) Voici son contenu: #! /bin/ash # # nginx local startup for DSM # PATH="/bin:/usr/bin" BASE="/usr/local" # contourner la restriction AppArmor (DSM6) SYSNGINX=/bin/nginx NGINX=$BASE/bin/nginx cp --update --archive $SYSNGINX $NGINX PREFIX="$BASE/etc/nginx" CONF="$PREFIX/nginx.conf" PIDFILE="/var/run/nginx-local.pid" PROXY_TEMP_PATH="/var/lib/nginx-local/proxy" [ -f $CONF ] || exit 0 if [ ! -d $PROXY_TEMP_PATH ] ; then mkdir -p $PROXY_TEMP_PATH chown http:http $PROXY_TEMP_PATH chmod u=rwx,g=rwx,o= $PROXY_TEMP_PATH fi action=$1 # build nginx arglist set -- -p $PREFIX -c $CONF -g "pid $PIDFILE;" case $action in start) [ -t 0 ] || exec >/tmp/nginx-startup.log 2>&1 $NGINX "$@" && echo >&2 "nginx: $action" ;; stop|reload|quit) $NGINX "$@" -s $action && echo >&2 "nginx: $action" ;; restart) for action in stop start do $0 "$action" done ;; status) if [ -r $PIDFILE ] ; then ps -www -fp $(<$PIDFILE) # <ligne à utiliser en DSM6, suivante pour DSM5 ### /bin/ps -w | awk -vpid="$(cat $PIDFILE)" '($1 == pid)' fi ;; *) echo "$0: unknown param \"$action\"" ;; esac Ce script sert aussi pour forcer le serveur à prendre en compte modification de config. Il faut utiliser pour cela le paramétre "reload": cela à l'avantage de ne pas tuer le process serveur si une erreur de syntaxe est détectée (utile pour les modifs de conf à distance!) "restart" sert a faire un redémarrage complet (si on soupçonne une fuite mémoire ou pour être sur de bien repartir complètement à l'état initial) Utilisation C'est a peu prés tout Pour lancer manuellement le serveur: /usr/local/etc/rc.d/nginx.sh start pour lui faire prendre en compte une modification de config /usr/local/etc/rc.d/nginx.sh reload # ou restart, plus radical Notes Il est fort possible que certaines options puissent être inutiles, ou que d'autres soient à ajouter pour optimiser ou régler tel ou tel détail. Ne pas hésiter à commenter et/ou proposer des modifications. L'approche que j'ai suivie modifie aucun fichier système DSM et l'intégralité de la config est située sous de /usr/local. Cela permet de garder le fonctionnement intact même en cas d'upgrade DSM. J'attends toutes remarques et signalement de bugs Rotation des logs Merci à loli71 qui à soumis dans le fil des instructions pour mettre en place une rotation du log logs. Ses instructions sont ici (et la solution s'intègre directement et proprement au composant de rotation des logs DSM) Historiques des modifications 15/06/2014: déplacé error_log en global proxy_http_version dans proxy_defaults.conf 16/06/2014: "backends" en simple http 19/06/2014 Spécificités WebDav interface admin DSM (5000/5001): retour au backend https pour frontend https suite à remarque. 20/06/2014 mutualisation des blocs "server" HTTPS en HTTPS. solution au problème de la redirection auto en https en ajoutant la clause "proxy_redirect" appropriée (et retour à la mutualisation en un seul backend http de ce fait) le cas "restart" du script de démarrage avait été oublié. 24/06/2014 ajouté "underscores_in_headers on" pour les liens partagés FileStation sur les dossiers 28/06/2014 on peut considérer la solution comme stable, supprimé "work in progress" clauses "Allow" et Deny" 02/07/2014 précisions sur les chemins relatifs pour les "includes" 15/09/2014 supprimé la remarque "work in progress", depuis le temps je pense qu'on peut considérer cette méthode comme stable et pérenne! ajouté l'ouverture des deux ports d'écoute de nginx dans le firewall. 12/11/2014 Ajouté référence à la rotation des logs proposée dans un commentaire 16/04/2016 utilisation du site http://hilite.me/ pour la colorisation des extraits de conf et de code 20/11/2016 mise à jour de la configuration SSL suivant les préconisation de @gaetan.cambier

Ca doit probablement marcher, mais si c'est la façon normale de faire je trouve ça franchement pas naturel. Imaginons que je donne par exemple l’accès notestation (et seulement) à un utilisateur distant novice, il sera un peu perdu.

Ce style aggressif (pas dans les coutumes du forum non plus) est-il vraiment indispensable? J'ai fait l'effort de garder un ton modéré de mon coté, est-il si difficile de faire de même? Je suggère d'attendre que Gaétan donne son point de vue pour trancher le débat. Je m'abstiendrai d'intervenir dans ce fil d'ici là.

J'ai découvert ça avec DSM6 en ayant activé l'option "pour voir ce que ça fait", mais il est possible que c'était déjà identique sous DSM5.X Il s'agit de cette option: Une fois "cacher la bannière" coché, l'accès direct au services FileStation, NoteStation, etc ... a pour effet de masquer le bandeau du haut et en particulier le bouton "déconnexion": Quand cette option est active, comment s'y prend-on pour se déconnecter (pour changer de compte par exemple) (sans avoir à aller vider les mot de passe enregistrés dans le navigateur)?

Ah oui exact, ne serait-ce pas alors un problème similaire à celui mentionné dans cet autre fil:

Possible solution trouvée ici: https://forum.synology.com/enu/viewtopic.php?f=260&t=115878 (pas testé)

Écoute: quand on débarque dans un sujet en postant une réponse qui ne cite pas le message auquel elle se réfère, la coutume veut qu'elle s'applique aux tout derniers messages postés et pas à un post datant de plusieurs mois, ce qui, par suite, exonère de la nécessité de remonter le fil jusqu'à l'année précédente (et ce n'est même pas une tournure de style). Sans oublier que le fait que cette réponse ait utilisé un terme spécifique n'exclue pas une possible confusion de son auteur sur ce dernier. Quand à la manière d'interpréter la réponse de @gaetan.cambier , si tu veux bien, on va attendre qu'il vienne s'exprimer lui-même. Suffit pas d'écrire "on va pas revenir 100 fois la dessus " pour décider unilatéralement que tout le monde est d'accord, y compris et surtout le principal intéressé. De mon coté je persiste à penser (et entre les lignes c'est ainsi que j'ai interprété la position de Gaétan) que le LACP ne devient pertinent que dans le cas d'un NAS supportant un grand nombre de sessions en partage de fichier actives en parallèle (et, bien entendu, sous réserve d'avoir toute l'infrastructure derrière). Quand on parle de 2/3 utilisateurs simultanés, ça signifie juste qu'il s'agit du minimum requis pour avoir un effet *mesurable*. De la à dire que c'est opportun/utile dans le cadre d'une utilisation à domicile il y a un gap.

Je n'étais pas remonté suffisamment dans le fil. Mais ne penses-tu pas qu'Il ait pu paraître logique que ta réponse s'applique à ces derniers, relatifs à des améliorations suite à l'achat d'un routeur WIFI* AC, plutôt qu'a un message remontant 5 mois en arrière? Et même, @gaetan.cambier écrit bien que les améliorations ne commencent à pouvoir se sentir qu'a partir de 2/3 users. Il est bien entendu implicitement question d'utilisateurs *simultanés* consommant *au même moment* une bande passante de plusieurs centaines de megabits *chacun*. En quoi cela peut-il être une utilisation typique d'un particulier à domicile? Mais je vais laisser Gaétan répondre lui même.

Essaie de remplacer "mount -t cifs" par "mount.cifs"

Pourquoi ne pas utiliser les fonctions DSM natives pour monter un dossier CIFS? C'est ce que je fait dans filestation avec ma Freebox et ça marche sans se poser de question (et marchait déja en DSM5): [root@fserv_~]$ mount |grep cifs \\192.168.1.254\pny on /volume2/video-nobackup/Freebox type cifs etc ... Ah j'avais pas capté que tu ne voulais pas faire un montage permanent...

C'était bien le cas. Enfin, après reinstall puis reconfiguration du bouzin (Cloud Station Server) ça refonctionne Petit bug sans importance alors