CoolRaoul

Si ça peut t'être utile, je me suis attelé par curiosité à la compilation de bacula pour le syno, C'est OK pour le dernière version (5.2.6) avec la commande "configure" suivante: LIBS="/lib/libpthread.so.0 -ldl" ./configure \ --prefix=/volume1/site/bacula \ --enable-smartalloc \ --with-sqlite3=/opt \ --with-x=no On met ce que l'on veut comme cible pour "--prefix" bien entendu Pre-requis: avoir installé le pakage sqlite via ipkg.

Si je comprend bien tu dépose le .bat dans le dossier et tu l'exécute ensuite. Dans un dossier "normal" un .bat va etre exécuté avec le dossier comme répertoire par défaut. Ce n'est pas le cas dans le cas d'un dossier accédé avec un nom UNC. Donc, si tu veux conserver le même comportement, te faudra préfixer dans ton script *tous* les noms de fichiers par %~dp0 (qui contient le chemin complet du dossier ou se situe le script)

C'est une limitation de cmd.exe: le r

Non, pour tout dire c'est même la première fois que j'entend parler de ce Bacula

il y a un tuto ici: http://reijndael.org...n-synology-nas/ Apparement les versions > à 5.0.1 poseraient problème: "I have tried to compile several version of bacula (up to 5.0.3) and the highest version that would compile was 5.0.1"

Suffit de faire une sauvegarde de configuration: suivi de Correctif: Je viens de m'apercevoir que j'ai dis une grosse c***ie dans mes posts ci-dessous Bien entendu ce n'est pas la modif de "/usr/syno/apache/conf/httpd.conf-user" qui pose probleme mais bien celle de "/usr/syno/etc/httpd-vhost.conf-user". Cela dit je pense qu'il est plus propre de se limiter a insérer juste un "#include" dans le premier et de mettre la configuration perso dans un fichier dédié.

La différence c'est que le "#" est obligatoire

La sauvegarde intégré à DSM, regarde Ca doit le faire mais en ce qui me concerne je préfère utiliser un "vrai" éditeur (emacs )

En complément (et surtout pour vraiment répondre à la question posée) je te conseille d'ajouter à la fin de /usr/syno/apache/conf/httpd.conf-user une ligne de ce genre: Include /volume1/<dossier partagé>/<chemin>/<fichier>.conf (et ce sera la seule chose à faire avec "vi") et de mettre ta conf virtual hosts dans ce fichier. Ainsi tu pourras éditer ce dernier sous windows via l'explorateur avec l'éditeur de ton choix. Par contre, à chaque fois que tu fera des modifications, pour qu'elles soient prises en compte, faut penser à redémarrer le serveur apache. Normalement faut utiliser la ligne de commande ("/usr/syno/etc/rc.d/S97apache-user.sh restart"), cependant cela peut être effectué via DSM en désactivant puis reactivant webstation (panneau de config->services web->activer web station).

Tu dois être prévenu qu'en DSM 4, si tu modifie a la main le contenu de "/usr/syno/apache/conf/httpd.conf-user"la sauvegarde ne fonctionnera plus.

J'ai trouvé ceci, ça ressemble a ton problème. Et c'est tout récent en plus.

Pas tout a fait: pas d'amélioration des performances en écriture (et même légère dégradation) c'est exact, par contre, en lecture, comme les I/Os peuvent être réparties sur deux disques on y gagne (quand le systeme a deux blocs a lire il peut lire le premier sur un disque et le deuxième sur l'autre en parallélisant le tout).

Si tu choisis la solution reverse proxy, pas besoin de rediriger le port 443 vers le 5000: suffit de rediriger le vers le et le 443 vers le 443.

Si c'est bien ça, Il s'agit donc strictement d'un problème Freebox et non Synology, et donc à mon avis tu trouvera plus d'aide en postant sur des sites plus dédiés Free (ADUF, universfreebox,...) (PS: c'est la première fois que j'entend parler d'un serveur http sur la Freebox V5, me semblait que ce n'était que la V6 qui en disposait)

Le serveur http natif du synology est un serveur Apache Pour quelle raison avoir installé Cheyenne?

On a échangé par mail sur le sujet mais il n'a pas du avoir encore le temps de mettre a jour son site

attention ce tuto est obsolete! Depuis DSM 4.0 il ne faut plus modifier "/usr/syno/etc/httpd-vhost.conf-user" sous peine de faire planter la sauvegarde La solution est de mettre toutes les lignes décrites dans le tuto dans un unique fichier dédié ( "/usr/local/etc/hhtpd-local.conf" me semble un bon choix étant donné que tout le contenu de "/usr/local" est automatiquement préservé par les upgrades de DSM), et simplement ajouter Include /usr/local/etc/hhtpd-local.conf à la fin de "/usr/syno/apache/conf/httpd.conf-user" Ca marchera aussi bien Exemple de contenu qui fonctionne chez moi: # -*- apache -*- <IfModule !proxy_module> 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 </IfModule> #/ NameVirtualHost *: <VirtualHost *:> ServerName webman.<mon domaine ici>.com ProxyRequests Off ProxyVia Off <Proxy *> Order deny,allow Allow from all </Proxy> ProxyPass / http://localhost:5000/ ProxyPassReverse / http://localhost:5000/ </VirtualHost> # etc ... si on veux définir d'autres virtual hosts, # exemple filestation.<mon domaine> .com à rediriger en http://localhost:7000/ # et ainsi de suite

Pour partager des fichiers à distance en famille sans passer par filestation je me demande si webdav ne serait pas la solution.

Non: rsync transfere un fichier à la fois. J'imagine qu'il met à jour la progression *apres* chaque fichier transféré. Donc si le pourcentage ne bouge pas, il est envisageable qu'il soit en cours d'envoi d'un gros fichier. Tu peux ajouter de la "verbosité" a rsync en ajoutant plusieurs arguments "-v" (exemple "-vvv") pour avoir plus de détail. Sinon, l'approche rouleau compresseur est possible avec "strace" (à installer par ipkg), et exécuter rsync comme ceci: strace -e open rsync <reste des arguments>[/CODE] Comme ça tu aura une trace à chaque fois que rsync ouvre un fichier source et pourras savoir sur lequel ça coince.

Pour commencer, faudrait savoir quelle est la volumétrie totale du répertoire à envoyer chez OVH/Hubic est de bande passante du dispose en upload.

C'est quoi le "moniteur réseau"? Lancé en connexion ssh y a t-il le même phénomène?

En tout cas, dans la table de la base sqlite l'uid est bien présent: Reste a trouver un volontaire avec deux Syno voulant bien faire le test.

Bon, j'ai voulu en avoir le coeur net. Le fichier exporté .dss s'ouvre avec 7zip (probablement un tar.gz) et contient une database sqlite. Les données d'options utilisateurs individuelles n'y figurent pas. Dommage.

L'avantage décisif, à mon avis, d'utiliser la solution utilisant l'outil intégré de DSM (je reconnais le bémol du près-requis DSM 4.0 minimum) est que *toutes* les informations utilisateurs sont transférées, et non pas seulement celles inscrites dans les fichiers /etc/passwd et /etc/shadow (tu a oublié d'ajouter /etc/group au passage) comme, par exemple, l'email, les privileges d'applications. La c'est tout le contenu de l'applet "utilisateur" du panneau de configuration DSM qui est migré sur le nouveau serveur. Et si ça se trouve (je n'ai pas testé je doit avouer) les options individuelles définies dans le panneau ci dessous sont également migrées.

Il y a mieux et, à mon avis, plus sur, en utilisant les outils intégrés à DSM: Sur le serveur source: Et ensuite, sur le serveur cible: sélectionner uniquement ce que l'on veux récupérer: