-
Compteur de contenus
5855 -
Inscription
-
Dernière visite
-
Jours gagnés
57
Messages posté(e)s par CoolRaoul
-
-
Mais modifié les iptables ne me plait pas trop c'est pour cela...
Euh, la config firewall dans l'interface web du syno n'est rien de plus qu'un GUI de modification des iptables tu sais?
0 -
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 ..."
0 -
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
0 -
oui un bug limite inadmissible... à moins que le système ai changé et que l'on doivent inversé les règles...
Et que dit l'aide en ligne de la V4.0 sur ce point?
0 -
Ça ne marchera pas car pour un meme port, quand une règle ACCEPT existe avec une règle DENY, c'est le DENY qui est retenu.
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:
Les règles sont hiérarchisées selon leur position dans la liste.0 -
m
0 -
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.
0 - Une première qui laisse passer tous les flux pour le réseau local, toujours active
-
Je souhaite toutefois pouvoir gérer le NAS à partir d'Ubuntu par la suite.
Quelles sont les opérations à réaliser pour cela ?
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
0 -
Pas si c'est pour un push des données....
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.
0 -
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
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
0 -
Bonjour,
Est il prevu un client FTP avec des options de transfert automatique a heure fixe ?
dans mon cas, c'est la chose qui me manque sur mon nas
possible avec une commande "wget ftp://<host>/<chemin>" dans le cron, non?
0 -
Apparemment il y a encore un petit souci.
Dans le fichier log du Synology, j'ai le message mount.davfs: open files exceed max cache size by 28065 MiBytes
Pourtant les fichiers sont copiés...
Edit: En supprimant les fichiers contenus dans le dossier lost+found le message d'erreur a disparu.
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.
0 -
Savez vous comment éviter le message ci-dessous lors de la commande mount.davfs :
You only should accept this certificate, if you can
verify the fingerprint! The server might be faked
or there might be a man-in-the-middle-attack.
Accept certificate for this session? [y,N]
Merci
tout simplement comme ça:
echo yes | mount.davfs <url> <point de montage>
0 -
Time Backup A
dans Time Backup
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]"
0 -
faut utiliser l'option
use_locks 0
dans /opt/etc/davfs2/davfs2.conf
et ca roule
Pour info, cette option n'est pas nécessaire dans le cas de Hubic
0 -
Tu installes la commande make avec ipkg
ipkg install make
Ca c'était déja ok
Tu vas à l'adresse suivante :http://code.google.c...ce/browse/trunk
Tu télécharge les différents fichiers que tu mets dans un dossier.
Ce sont les derniers en date, car le tar.gz proposé sur le site n'est plus actualisé depuis 1 an.
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:Ensuite tu vas dans le dossier crée. Tu fais : makeFSERV> 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...
0 -
Désolé de multiplier les postes, mais suite à ca, je n'arrive pas à automatiser la connexion à l'idisk.
Il y a une question blocante qui me demande de valider le certificat d'Apple.
J'aimerai le forcer à dire oui. Comment faire ?
Merci.
Essaie ceci, ça devrait le faire
echo yes | mount.davfs https://idisk.me.com/user /volume1/idisk/[/CODE]
0 -
Alors j'ai utilis
0 -
Mis a part le problème du certificat qu'il faut accepter manuellement, j'ai un autre problème:
J'ai testé le backup vers un compte box.net monté en webdav mais je ne parviens pas a lui faire faire des sauvegardes incrémentales. Ca repart systématiquement en full a chaque fois.
Est-ce que quelqu'un y est arrivé?
0 -
Interessant
J'ai fais un test avec box.net, le montage fonctionne:
$ mount -t davfs https://www.box.net/dav on /volume2/box.net type davfs (rw,nosuid,nodev,_netdev,uid=1035,gid=65546)
mais ensuite:$ touch /volume2/box.net/a touch: cannot touch `/volume2/box.net/a': Input/output error
!!!EDIT!!! trouvé la solution ici faut utiliser l'optionuse_locks 0
dans /opt/etc/davfs2/davfs2.conf
et ca roule
(avec les 50 Gigas gratuits chez box.net ces jours ci ça devient franchement intéressant tout ça)
0 -
Salut,
J'ai exactement le m
0 -
USB Station 2 + Disque USB 2 To
Avantages :
- Le disque dur est utilisable pour d'autres transfers éventuels
Le Syno va formater le disque dur en ext4 et donc c'est pas gagné pour le lire ailleurs que sur une machine nunux, je me trompe?
[EDIT] en relisant la FAQ je viens de voir que la FAT32 est possible, dont acte... mais dans ce cas ne pas oublier attention la limitation de taille max des fichiers (4Go)
0 -
-
je sais que le RAID n'est pas une garantie absolue de sauvegarde, de m
0
Interrupteur G
dans Pare-Feu et QoS
Posté(e) · Modifié par CoolRaoul
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.