CoolRaoul

Sur le fond, ça ne fait pas vraiment de différence. A moins que fufu pense à autre chose quand il écrit "configuré le reverse proxy à la main"

Je ne voyais vraiment pas comment faire autrement qu'en éditant le fichier!

Pas besoin de ldap ni d'AD pour utiliser les ACL. Une fois activées, dans les propriétés de sécurité des fichiers du syno tu va avoir acces aux comptes et groupes du syno tout simplement. Et ca marche . Faut juste savoir que les ACL sont prioritaires par rapports aux droits unix ("ugo") , et que pour les modifier en ligne de commande c'est un peu galère car la commande qui fait ça ("/usr/syno/bin/synoacltool") n'est tout simplement pas documentée (on a juste un résumé de syntaxe si on le lance sans arguments) De plus (il me semble que c'est que que depuis la DSM 4), on peut modifier les ACL dans l'interface de file station.

Tiens tiens, comme ça on nous sort sa botte secrète (pas pu m'empécher d'attraper la perche ) Comme je l'ai dit plus haut "en DSM 4; la sauvegarde de la configuration analyse le *contenu* de ces fichiers. Si ils ont été modifiés manuellement elle ne retrouve plus ses petits et plante." Donc il y a doit avoir des cas ou les modifs manuelles ne perturbent pas l'analyse de contenu que fait la procédure de sauvegarde de configuration et d'autre non. Il ne s'agit pas du backup mais de la sauvegarde de configuration (qui est aussi faite pour tout job de backup). Cette partie ne se contente pas de copier betement les fichiers de conf mais traite un par un une liste explicite de fichiers pour appliquer à chacun un traitement ad-hoc

Pourquoi le modifier? Il est possible qu'il serve ou soit utilsé dans certains configurations présente et/ou à venir de DSM Autant le laisser et ajouter le sien.

Pas sur que ce soit l'approche idéale Je prefère la mienne (version 2, celle qui marche ): il 'y a qu'une ligne a ajouter dans un fichier système. Et ensuite tu peux aussi "charger plein de fichier conf" mais cette fois-ci en les mettants dans le répertoire que *tu* as choisis pour le "#Include"

Oui, pour ma part j'ai deux réponses sur mes 3 tickets du week-end (dont un déja résolu)

Me revoila, En effet, j'avais mal testé, mettre des fichier de conf dans /usr/syno/etc/sites-enabled-user/ ne marche pas (ces fichiers sont inclus 2 fois, une fois à l'interieur d'une directive <VirtualHost> et une autre fois directement. J'ai choisi de mettre ma config reverse proxy dans un seul fichier (/volume1/site/etc/httpd/conf.d/vhost.conf si vous voulez tout savoir) et rajouté: Include /site/etc/httpd/conf.d/*.conf à la fin de /usr/syno/apache/conf/httpd.conf-user Faudra juste penser à remettre cette lignes en cas d'upgrade du DSM

oups, j'ai merdé.. Ma solution ne marche pas... je regarde et je reviens dans un moment

Tu as activé les acl sur le partage?

En effet: en DSM 4; la sauvegarde de la configuration analyse le *contenu* de ces fichiers. Si ils ont été modifiés manuellement elle ne retrouve plus ses petits et plante. Une solution, est donc mettre la config reverse proxy dans un fichier situé /usr/syno/etc/sites-enabled-user/ (le nom importe peu pour peu que ça se termine par ".conf") Tu dois avoir de la chance alors: pour ma part, que je met quoi que ce soit à la main dans l'un de ces fichiers, la sauvegarde ne fonctionne plus.

Merci J'ai aussi trouvé comment rediriger proprement tous les log syslog (et pas seulement seux sélectionnable dans la rubrique "syslog client" du panneau de conf) du Syno vers le package syslog serveur (ou un autre syslog). Faudra que je poste ça dans le fil approprié à l'occasion.

Attention a ce que tu va trouver avec "man cron", le cron du syno est une version "light" qui n'est pas identique aux crontabs complets. D'autre part je te conseille *beaucoup* de prudence avec un script automatique qui efface des fichiers. In petite faute de frappe ou une variable mal initialisée et c'est tout un disque supprimé Exemple (à ne surtout pas exécuter!!!) REP=/volume/scratch find $DIR -mtime -7 -type f | xargs rm -f # erreur : $DIR au lieu de $REP !!! Suite à L'errreur sur la variable (DIR au lieu de REP), tu va effacer des fichiers ailleurs qu'à l'endroit souhaité:

Tout baigne j'ai mis mes fichiers de conf proxy dans le répertoire: "/usr/syno/etc/sites-enabled-user/" (dans les fichiers de config "maîtres" d'apache on a un "/usr/syno/etc/sites-enabled-user/*.conf") Redémarré apache. Mon virtual host en proxy marche toujours et la sauvegarde aussi! YESSS!!!

Tu m'as mis sur une piste ! apès avoir renommé les deux fichiers /usr/syno/etc/httpd-ssl-vhost.conf-user /usr/syno/etc/httpd-vhost.conf-user qui contiennent ma conf reverse proxy la sauvegarde marche: FSERV> /usr/syno/bin/synolocalbkp -b "My Backup Set 1" Export confbkp file to : /volume1/@tmp/23531/FSERV_20120314.dss au lieu de FSERV> /usr/syno/bin/synolocalbkp -b "My Backup Set 1" Segmentation fault (core dumped) Dans quels fichiers met-tu ta conf reverse proxy?

C'est bien aussi ce que j'aurais envie de faire, mais maintenant que j'ai ouvert un ticket au support, si je remet tout à zero on ne risque pas de trouver la cause du problème. J'attend au moins de voir ce qu'ils vont me proposer.

Quel modèle le routeur? Ne saurait-il pas faire des redirections différences fonction de l'IP entrante?

J'ai meme donné un script en exemple

Ah, pareil que moi, mauvaise piste alors...

Voici: ConnectionMode="" DSID="<une suite de caracteres hexa ici>" client="<nom netbios de mon pc>" db_loc="C:/Users/<mon user windows>/AppData/Roaming/CloudStation/db" password="" port="" proto_version="2" server="" serverID="<mon id ezcloud>" serverName="" session="<une suite de caracteres hexa ici>" user="<mon username sur le syno>" watch="C:/Users/<mon user windows>/CloudStation"

Stp, ça t'ennuyerait d'exécuter la commande suivante sur ta machine et de nous donner le résultat ? /usr/syno/synoman/webman/modules/BackupApp/sysconfbkp.cgi[/CODE]

Si j'ai bien compris tu as mis en place sur ta box une redirection du port 5666 vers le port 5000 de ton syno sur son IP locale. Si c'est bien cela, pourquoi ne pas avoir gardé le même port des deux cotés? Le résultat est que, dans le cas des connexions sur ton lan interne, j'ai bien l'impression que la redirection de port n'est pas faite et que tu vas attaquer ton syno sur le port 5666, qui ne répond pas bien entendu. La solution suivante pourrait marcher: Essaie de rajouter les lignes suivantes lignes au fichier "/usr/syno/etc/httpd-vhost.conf-user" LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_connect_module modules/mod_proxy_connect.so LoadModule proxy_http_module modules/mod_proxy_http.so NameVirtualHost *:5666 <VirtualHost *:5666> ServerName nas.mondomaine.com <-- REMPLACER ici ProxyRequests Off ProxyVia Off <Proxy *> Order deny,allow Allow from all </Proxy> ProxyPass / http://localhost:5000/ ProxyPassReverse / http://localhost:5000/ </VirtualHost> et ensuite redémarre apache : /usr/syno/etc/rc.d/S97apache-sys.sh restart /usr/syno/etc/rc.d/S97apache-user.sh restart Tiens nous au courant du résultat

Public et anonyme (mais comme tu l'as sans doute remarqué on peut mettre une date d'expiration et/ou un mot de passe)

Avec file station faut procéder comme ceci: ce qui va donner: apres avoir cliqué "partager" tu obtiendra un unique vers le fichier/ A savoir: Ca ne marche pas (a ma connaissance) pour les répertoires. Ca marche pour tous les fichiers, qu'ils soient dans le dossier cloudstation ou pas