Sylar

Modération : Inutile de citer le post précédent Si je pouvais, c'est ce que je ferais. Mais ce n'est pas possible malheureusement ...

Modération : Inutile de citer le post précédent Heureusement, j'ai la fibre, et la NAS de destination est également connecté via la fibre. C'est toujours long, mais beaucoup plus rapide que l'ADSL.

Je voulais m'éparger le coût d'un disque de plus. Mais je peux faire un backup distant sur un autre NAS, ce sera juste un peu plus long.

Autant pour moi. L'opération est du coup encore plus critique, en effet. Merci de m'avoir corrigé.

Evidemment. Avec 2 disques de 3 To utilisés pour stocker au max 3To, je bénéficie encore des 3To de redondance, non ?

Merci pour vos réponses. En effet, je veux utiliser le 4To en backup externe des 2 disques 3 To restés sur le NAS, avant de les reformater tous les 2 en BTRF. L'idée est ensuite de réintégrer le 4To dont j'aurai à nouveau copié le contenu sur le NAS au groupe. En effet, les données seront à un moment lors de la migration sur un seul disque, celui de 4 To. Mais je vais mettre en sécurité mes données ailleurs au cas où, évidemment. Au final, je veux juste m'assurer que je peux : - enlever le disque de 4To du groupe actuel, - sans perte des données actuellement présentes dessus (et cela n'est possible que si ces données occupent un espace < 3To, c'est ça ?)

Bonjour à tous, Maintenant que DSM6.1 est sorti, j'en profiterais bien pour passer mon système de fichier en BTRFS. Comme aucun outils de migration n'est prévu, il est donc nécessaire de repartir de 0. J'ai actuellement un DS415+, dans lequel est monté 3 disques (2 disques de 3To, et un disque de 4To). Avec une telle configuration, j'ai donc 6To de disponible, pour 3To de redondance (et 1To non utilisé ...). Je souhaiterais : - enlever un des 3 disques du volume pour le mettre de côté, - y sauvegarder mes données, - puis reconfigurer les 2 disques restant du NAS en SHR formaté en BTRFS, - y remettre mes données depuis le disque enlevé, - pour enfin réajouter le 3ème disque au volume. J'ai bon ? Par ailleurs, à quelle condition puis-je enlever un des 3 disques (celui de 4To probablement) pour que l'intégralité des données ne soient pas touchées par la dégradation du volume ? Puisque le volume d'origine a 3To de redondance, il me semblerait logique qu'il ne faille pas qu'il y ait pas plus de 3To de données sur le NAS avant la suppression du disque. Mais je préférerais m'en assurer ... Merci d'avance pour vos avis éclairés !

Bon, pour info, un reset "simple" permet de rendre l'accès au compte "admin" par défaut. OUF !

Il semble que ce soit un ajout qui a été fait dans la dernière mise à jour. Je venais d'installer le paquet carddav, et j'ai par erreur cru que je gérais les droits de cette application, et non l'accès au DSM lui même ... car en effet, cette application "Bureau" n'apparassait pas avant. EDIT : je ne suis pas le seul visiblement à avoir découvrir trop tard de quoi il s'agissait ... : https://forum.synology.com/enu/viewtopic.php?f=19&t=123062&p=454280#p454280

Bonsoir, Je viens de faire un truc complètement idiot : dans le portail des applications, j'ai supprimé tous les droits par défaut à l'application "Bureau", qui n'est rien d'autre que l'interface web du DSM elle-même. Du coup, impossible de me logguer, même en tant qu'admin. Un bêtise, je disais ... Une idée de comment je peux récupérer ça ? J'ai toujours accès à SSH sur le NAS, j'espère que ça peut aider ...

Bon, en fouillant un peu dans les paramètres des partages de fichier, je me suis retrouvé à "vider le cache SMB" dans les paramètres avancés du partage de fichier windows, et ça a été radical, du moins jusqu'à maintenant. A l'instant où j'ai vidé ce cache samba, le NAS est réapparu instantanément dans le Finder et est maintenant accessible sans message d'erreur, et mes sauvegardes Time Machine sont reparties toutes les heures, comme avant l'update. Je vois pas bien le lien avec AFP, mais vider ce cache provoque visiblement un "redémarrage des services réseau", ce qui a peut être permis de refaire fonctionner l'ensemble. Il reste à voir si ça dure dans le temps maintenant.

Malheureusement j'ai besoin des 2. J'ai un raspberry Pi sous OSMC qui monte les dossiers vidéos, music, etc. via smb. Je pourrais peut être tester via AFP ceci-dit ... A noter que sous DSM 5.2, ma configuration était identique et ne posait aucun soucis à OSX 10.11. Je pensais avoir trouvé une solution via le post ICI, mais désactiver l'IPv6 n'a rien changé.

Bonjour à tous, Depuis mon passage sous DSM6, j'ai des soucis avec Time Machine, et plus généralement avec AFP. Time Machine ne sauvegarde plus toutes les heures ma machine, alors que c'était encore le cas il y a quelques jours. Je pense donc que ça date du passage de mon DS415+ sous DSM6. Après un long moment de "Recherche du disque de sauvegarde ...", j'ai le droit à : Evidemment, le NAS est pourtant accessible, puisque je peux monter un partage en AFP depuis le finder (avec la combinaison cmd+K, puis afp://mon_user@mon_nas.local). A noter que depuis le finder, si je clique sur la petite icône de mon NAS dans la colonne de gauche, j'obtiens : Si je désactive le service AFP, puis le réactive à nouveau, cette fois la sauvegarde fonctionne et le disque Time Machine est bien trouvé. Dernier symptôme : une fois monté, mes partages AFP se déconnectent très souvent tout seul. Suis-je le seul pour qui tous ces soucis se produisent ?

OK, merci de "l'info" (qui du coup ne doit pas être nouvelle).

Bonjour à tous, Je viens de passer le NAS de mes parents sous DSM6. Je constate un soucis (que je n'avais pas remarqué avant sous DSM5, mais ça ne veut pas dire qu'il n'existait pas) concernant les droits des fichiers, dossiers, etc. qui apparaissent différents selon l'utilisateur. Exemple : admin@Diskstation:~$ ll total 12 drwxrwxrwx 2 admin users 4096 Apr 16 11:07 . drwxrwxrwx 6 root root 4096 Dec 29 19:34 .. admin@Diskstation:~$ touch test admin@Diskstation:~$ ll total 12 drwxrwxrwx 2 admin users 4096 Apr 16 11:07 . drwxrwxrwx 6 root root 4096 Dec 29 19:34 .. -rwxrwxrwx 1 admin users 0 Apr 16 11:07 test admin@Diskstation:~$ sudo -i root@Diskstation:# ll total 12 drwx--x--x 2 admin users 4096 Apr 16 11:07 . drwx--x--x 6 root root 4096 Dec 29 19:34 .. -rwx--x--x 1 admin users 0 Apr 16 11:07 test Un fichier, qui apparait avec les droits rwxrwxrwx pour admin, est vu avec les droits rwx--x--x pour root. Je ne comprends pas ...

Je découvre à l'instant vos réponses. Mieux vaut tard que jamais ;) Pour info, bien que mes premiers tests ne semblaient ne pas concluants, je me suis rendu compte qu'en effet l'option --network=host permettait enfin de faire fonctionner le blocage des IPs correctement. Mais nous sommes toujours bloqué à la version 1.6, qui commence à dater vu l'activité des développeurs de docker. J'espère que Synology mettra à jour le paquet bientôt (peut être à l'occasion du DSM 6 ?)

Bon, en utilisant le paquet, la seule différence avec ce que j'ai indiqué précédemment est ici : Pour le container docker (pour rappel 192.168.1.2 est l'IP du diskstation sur le réseau local), lancé avec l'option --net="host" : [SERVER_ADDR] => 192.168.1.2 [REMOTE_ADDR] => 192.168.1.2 Pour le paquet : [SERVER_ADDR] => 127.0.0.1 [REMOTE_ADDR] => 127.0.0.1 Mais cette fois, en cas de saisie erronée multiple, c'est bien la bonne adresse IP qui est bloquée : celle du client, et non 192.168.1.2. Dans les 2 cas, X-FORWARDED-FOR contient bien l'adresse IP du client. Je comprends bien la différence entre les 3 approches que j'ai testées (docker bridgé + NAT, docker hosté, et paquet "natif"), mais j'avoue ne pas saisir, compte tenu des en-têtes HTTP transmises pour les 2 derniers cas, comment fonctionne le système de blocage des IPs ... Il y a certainement un truc moche, du type "si SERVER_ADDR différent de 127.0.0.1, alors bloque SERVER_ADDR, sinon bloque X-FORWARDED-FOR".

Aller, promis, après j'arrête mon monologue ;) J'ai lancé docker en mode "host", ce qui permet au container haproxy de partager la même pile réseau que le diskstation. De cette façon, les entête X_FORWARDED_FOR et X_CLIENT_IP sont correctement attribuées et contiennent bien la vraie IP du client. Pour autant, le système de blocage d'IP continue de se bloquer lui-même ... Au cas où, voici les infos que je trouve dans les requêtes HTTP envoyées depuis l'extérieur. L'IP locale du diskstation est 192.168.1.2, et le client depuis lequel je fais un wget qui me renvoie ceci a pour adresse 134.X.X.X Array ( [USER] => http [HOME] => /var/services/web [FCGI_ROLE] => RESPONDER [REDIRECT_MOD_X_SENDFILE_ENABLED] => yes [REDIRECT_HANDLER] => php5-fastcgi [REDIRECT_STATUS] => 200 [MOD_X_SENDFILE_ENABLED] => yes [HTTP_USER_AGENT] => Wget/1.17 (darwin15.0.0) [HTTP_ACCEPT] => */* [HTTP_ACCEPT_ENCODING] => identity [HTTP_HOST] => www.mondomaine.com [HTTP_X_CLIENT_IP] => 134.X.X.X [HTTP_X_FORWARDED_FOR] => 134.X.X.X [HTTP_CONNECTION] => close [PATH] => /bin:/sbin:/usr/bin:/usr/sbin:/usr/syno/bin:/usr/syno/sbin:/usr/local/bin:/usr/local/sbin [SERVER_SIGNATURE] => [SERVER_SOFTWARE] => Apache [SERVER_NAME] => www.mondomaine.com [SERVER_ADDR] => 192.168.1.2 [SERVER_PORT] => 80 [REMOTE_ADDR] => 192.168.1.2 [DOCUMENT_ROOT] => /var/services/web [SERVER_ADMIN] => admin [SCRIPT_FILENAME] => /var/services/web/test.php [REMOTE_PORT] => 40132 [REDIRECT_URL] => /test.php [GATEWAY_INTERFACE] => CGI/1.1 [SERVER_PROTOCOL] => HTTP/1.1 [REQUEST_METHOD] => GET [QUERY_STRING] => [REQUEST_URI] => /test.php [SCRIPT_NAME] => /test.php [ORIG_SCRIPT_FILENAME] => /php-fpm-handler [ORIG_PATH_INFO] => /test.php [ORIG_PATH_TRANSLATED] => /var/services/web/test.php [ORIG_SCRIPT_NAME] => /php-fpm-handler.fcgi [PHP_SELF] => /test.php [REQUEST_TIME_FLOAT] => 1450273339.6406 [REQUEST_TIME] => 1450273339 ) Donc même avec les bonnes options, il me semble que DSM persiste à bloquer autre chose que l'IP indiquée dans les entêtes ajoutées par haproxy ... Je vais tenter avec le package et voir si le comportement est différent. Merci de votre aide/commentaire/suggestion !

Alors, après investigation, c'est clairement lié à Docker. Celui-ci crée une nouvelle passerelle réseau d'IP X.X.X.1, et le container a une adresse X.X.X.2. Et il se trouve que l'en tête X_FORWARDED_FOR ajoutée par haproxy, et qui capture normalement l'IP du client, est celle de la passerelle de docker (logique, du point de vue d'haproxy), et non celle du vrai client. D'où le blocage. Finalement, c'est donc comme si j'avais 2 serveurs à traverser avant d'atteindre les backends. Bon, je vais regarder comment jouer avec les options réseau de docker pour comprendre comment modifier ça. Si c'est faisable ...

C'est probablement à cause de docker, oui. Enfin, j'imagine, mais conceptuellement le cas ne devrait pas être géré différemment : on a un serveur faisant office de reverse proxy, avec sa propre IP, et derrière le diskstation qui héberge une partie des backends. Quant à l'utilisation de docker, disons qu'il me permet de d'éditer facilement le fichier de conf, sans passer par le GUI du paquet qui ne permet pas de saisir l'ensemble des paramètres dont j'ai besoin. Mais s'il le faut je reviendrai vers le paquet haproxy. A vrai dire, entre les 2 configurations (celle avec le paquet et celle avec docker), la seule différence concerne la déclaration des backends, spécifiés sur localhost contre l'IP du diskstation, respectivement. Comme localhost est exclu du blocage d'IP par défaut semble t'il, est il absolument certain que le blocage d'IP est bien actif dans le cas du paquet ?

Bonjour à tous, Désolé pour cette remontée de topic bien ancien, mais je me retrouve confronté exactement au même soucis que celui mentionné dans le post. Je viens de mettre en place haproxy dans un conteneur docker, et tout marche parfaitement bien. Sauf que DSM persiste à bloquer l'IP du reverse proxy, au lieu de celle du client, malgré l'ajout de ce qu'il faut pour ajouter les bons headers dans la configuration. J'avais le sentiment que le soucis était résolu, mais il ne semblerait pas ? Au cas où, je joins ma configuration de haproxy. Merci de vote aide ! haproxy.cfg

J'ai un backup externe redondant, c'est pour ça que je peux le faire. Sinon, en effet, c'est risqué ! Donc certain, mon RAID1 à 1 disque pourra booter sans erreur ? Il faut vraiment que tous ses services tournent sans encombre, car il faudra que je migre données, mails, etc.

Bonjour à tous, Je vais bientôt changer de DS (DS213+ vers DS415+). Afin de repartir sur une base propre, j'aimerais réinstaller proprement DSM sur le nouveau modèle, donc je ne ferai pas de "migration" d'une installation vers une autre. Par ailleurs, pour l'instant, je souhaiterais éviter d'avoir à acheter un nouveau HDD. Voici la configuration actuelle : - ancien NAS (2 baies) : 2 HDD, en RAID1 - nouveau NAS (4 baies) : pas de nouveau disque idéalement. J'aimerais donc récupérer 1 des 2 disques de l'ancien NAS pour l'installer dans le nouveau (après un format complet pour faire les choses proprement). Pour autant, j'aimerais avoir confirmation qu'une fois 1 disque enlevé, l'ancien NAS sera toujours capable de booter avec un seul disque sans soucis. C'est censé être OK vu que les 2 disques sont en RAID1, mais je préférerais en être sûr ... Merci !

En effet, c'est bien ce qui me venait en tête. En l'état, je n'ai rien de particulier dans les logs (/var/log/https/*), pas de htaccess dans /volume1/web, pas de fichier owncloud, etc. Par contre, comment utiliser la page de status de haproxy "pour voir où j'arrive" ? C'est quand même trèèèèès bizarre que www.mondomaine.com/owncloud soit redirigé "automatiquement" vers www.mondomaine.com:8888/owncloud , mettant ainsi en évidence le port sur lequel tourne le serveur web local hébergeant owncloud. Bien sûr, le port 8888 est fermé, je veux justement que tout passe par le 443 via haproxy.

Alors, une idée ? Je sèche ...