CoolRaoul

D'après les retours dans ce forum et celui de Synology (ainsi que ma propre expérience, mais je n'ai pas testé toutes les configurations possibles) il semble bien que la réponse soit positive.

Qui aurait une idée sur (ou déja rencontré) ce problème? Lorsque je me connecte à l'interface d'admin http Syno à partir de mon taff (ou je passe par un proxy), lorsque certains applications DSM sont actives (interface syslog par exemple) Chrome se met par moment à consommer du cpu en permance (un core pour lui tout seul). J'ai essayé en désactivant toutes les extensions sans plus de résultat. Pas de problème par contre avec d'autres navigateurs (IE, Opera ou Firefox) Je n'ai rencontré ce problème qu'avec DSM jusqu'ici

A l'occasion de la sortie de DSM 4.0 je me permet un petit "up" sur ce sujet Il n'est désormais plus necessaire d'editer "/usr/syno/etc/synosyslog" en se connectant en ssh (ou telnet) sur le syno Cela se fait directement dans l'interface d'admin. dans le panneau de configuration sélectionner ce qui nous donne: Dans le champ "serveur" mettre l'IP du serveur syslog (dans l'exemple ci dessus on redirige sur le package syslog installé en local) L'onglet "filtre de journal" permet de choisir quelles catégories d’évènements sont propagées.

Ah, Ok la *fonction* En tout cas, je confirme qu'elle se cache bien, elle cache même son nom!

5000 Megas, autrement dit 5 Gigas Bigre! Mais bof, qu'est-ce que 5 gigas de nos jours...

Quelle fonction?

sauf si on a mis le syno en DMZ sur la box. ou si on a redirigé certains ports de la box vers le syno et que l'on veux filtrer les chinois par exemple...

ménonménon: pour les paquets entrants, c'est l’adresse *cible* qui est nattée, l'IP source est inchangée (un simple tcpdump te convaincra) et donc ma solution fonctionne.

Euh, la config firewall dans l'interface web du syno n'est rien de plus qu'un GUI de modification des iptables tu sais?

Autre solution plus simple, avec une seule règle à ajouter. (Déjà vue ici me semble-t-il est et confirmée dans le forum syno) Ajouter en fin de liste une règle de type "refuser" mais au lieu de cocher "tous" dans la rubrique "ports", aller dans "sélectionner" et tout cocher seulement à cet endroit. et mettre "autoriser acces" dans "si aucune règle ..."

Une solution de contournement à ce problème a été proposée dans le forum synology : (ref: http://forum.synolog...tart=15#p183555) Mettre ceci dans /etc/rc.local: iptables -D INPUT -i eth0 -j DROP iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -i eth0 -j DROP

Et que dit l'aide en ligne de la V4.0 sur ce point?

Je pensais plutôt qu'il faut surtout tenir compte de l'ordre des règles (de haut en bas). La première qui "matche" est appliquée. Si c'est un "accept" le flux est autorisé même si il y a un "deny" un peu plus bas. D'ailleurs c'est confirmé par l'aide en ligne:

Ce que je peux te proposer c'est ajouter deux règles dans le firewall en début de liste. Une première qui laisse passer tous les flux pour le réseau local, toujours active Une suivante qui bloque tout, activable a la demande Comme ceci: Suffit de cocher la case entourée de rouge pour bloquer tous les flux externes. A toi de configurer correctement l'ip et le masque de la 1ère règle afin que cela corresponde au plan d’adressage de ton lan.

La gestion du Synology se fait avec un navigateur en http Par conséquent, que le navigateur utilisé tourne sous Windows, Linux, MacOs ou n'importe quoi d'autre ne changera pas grand chose

Tu as raison, mais dans ce cas il pourra alors utiliser n'importe client ftp (il y a en a plusieurs sur les dépots ipkg), mettre la commande kivabien dans un script et ensuite le tout en cron. @micke21: faut comprendre que faire du scheduling ce n'est pas le boulot du client ftp, chaque outil a sa fonction.

J'ai lu ici et la le conseil de remonter les disques avec l'option "noatime" pour éviter des écritures inutiles. Mais j'ai bien l'impression que le noyau linux du Synology ignore superbement cette option: Avant $ mount | grep /volume2 /dev/mapper/vol2-origin on /volume2 type ext4 (usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,synoacl) Les options sont donc : usrjquota=aquota.user grpjquota=aquota group jqfmt=vfsv0 synoacl Exécution de mount -o remount,noatime /volume2 Résultat; $ mount | grep /volume2 /dev/mapper/vol2-origin on /volume2 type ext4 (usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,synoacl) L'option n'est pas prise en compte Pour en avoir le coeur net, je viens de faire le test sur un linux installé dans un virtualbox, et la l'option s'affiche bien: [root@VCentOS ~]# mount | grep " / " /dev/mapper/vg_vcentos-lv_root on / type ext4 (rw) [root@VCentOS ~]# mount -o remount,noatime / [root@VCentOS ~]# mount | grep " / " /dev/mapper/vg_vcentos-lv_root on / type ext4 (rw,noatime) <EDIT> Au temps pour moi: finalement il semble que l'option soit bien effective, c'est juste à l'affichage que ca coince. Le test suivant montre bien que l'acces time n'est pas mis a jour quand le volumé est monté "noatime" $ mount -o remount,noatime /volume1 $ /bin/ls -alu hubic.pl -rwxrwxrwx 1 gilles users 5290 Feb 29 22:37 mhubic.pl $ tail -1 hubic.pl exit(0); $ /bin/ls -alu hubic.pl -rwxrwxrwx 1 gilles users 5290 Feb 29 22:37 mhubic.pl # le tail n'a pas changé l'access time $ mount -o remount,atime /volume1 $ /bin/ls -alu hubic.pl -rwxrwxrwx 1 gilles users 5290 Feb 29 22:37 mhubic.pl $ tail -1 hubic.pl exit(0); $ /bin/ls -alu hubic.pl -rwxrwxrwx 1 gilles users 5290 Mar 4 13:19 hubic.pl # et là, la date a bien été mise a jour

possible avec une commande "wget ftp://<host>/<chemin>" dans le cron, non?

Me semble que ceci signifie simplement que tu transfere des fichiers beaucoup plus grand que la taille du cache. D'apres la doc (http://linux.die.net/man/5/davfs2.conf) le parametre "cache_size" vaut 50 MBytes par défaut (faut dire "MiBytes" maintenant ) mais le système davfs sait dépasser cette valeur si nécessaire ("mount.davfs will always take enough space to cache open files, ignoring this value if necessary") Faut bien comprendre la différence entre le cache ("cache_dir") et le répertoire contenant les fichiers ne pouvant pas être transférés ("backup_dir", refusés par le serveur par exemple si entraînant un dépassement de capacité). Voir la page de doc dont j'ai donné le lien ci-dessus. Donc, vu ce que tu décris, le pense plutôt que les fichiers que tu a supprimés de lost+found n'ont pas été transférés correctement.

tout simplement comme ça: echo yes | mount.davfs <url> <point de montage>

J'ai le meme problème depuis que j'ai décidé de tester time backup sur un répertoire ce week-end. Ca se passe bien pendant quelques passes et soudain ça coince avec ce genre d'erreur (dans la syslog) BK_WARN:Another backup is still in process, abort Me demande si c'est bien fiable ce mécanisme ... EDIT: Trouvé l'explication de ce problème spécifique, suite a une fausse manip j'avais deux cron qui tournaient en parallèle et les tous les jobs étaient donc exécutés deux fois simultanément, parmi lesquels celui de time backup. Ceci dit je retrouve a nouveau les problèmes comme ceux décrit plus haut, à savoir " [failure to create snapshot]"

Pour info, cette option n'est pas nécessaire dans le cas de Hubic

Ca c'était déja ok Ah oui, en effet (Je dois dire que ça met pas en confiance sur le suivi du projet ce genre de choses...) Pour ma première tentative, j'avais récupéré le tgz obsolète et le make était en effet parti en vrille: Bon, nouvel essai: je récupère les sources avec svn comme ceci: svn checkout http://boxfs.googlecode.com/svn/trunk/ boxfs-trunk Aie, ca commence moyen: FSERV> make Package fuse was not found in the pkg-config search path. Perhaps you should add the directory containing `fuse.pc' to the PKG_CONFIG_PATH environment variable No package 'fuse' found Compiling boxfs.c cc -g -c boxfs.c -o boxfs.o make: cc: Command not found make: *** [boxfs.o] Error 127[/code] Je relance le "make" en forcant gcc a la place de cc, et c'est reparti comme en 14: [code] FSERV> make CC=gcc Package fuse was not found in the pkg-config search path. Perhaps you should add the directory containing `fuse.pc' to the PKG_CONFIG_PATH environment variable No package 'fuse' found Compiling boxfs.c gcc -g -c boxfs.c -o boxfs.o boxfs.c:15:18: error: fuse.h: No such file or directory etc .... [/code] Apparement il me manque un composant "fuse" mais ipkg ne connait pas: [code] FSERV> ipkg list "*fuse*" confuse - 2.7-2 - a configuration file parser library [/code] Bon, je pense que je vais plutôt aller me coucher...

Essaie ceci, ça devrait le faire echo yes | mount.davfs https://idisk.me.com/user /volume1/idisk/[/CODE]