vrolland

C'est encore moi, suite à quelques erreurs dans mes syslogs, 1 petite chose a modifier dans le fichier de conf rsynd.conf il faut remplacer "aut users" par "auth users", cela n’empêche pas le fonctionnement mais le démon ne comprenant par l'argument il l'ignore...du coup cela peut créer un problème de sécurité.

Salut, Merci beaucoup pour ton tuto, un petit détail cependant, en l'état actuel des choses l'utilisateur créé n'a pas accès au fichier de log. Extrait du syslog lors de la connexion du syno rsync: failed to open log-file /var/log/rsyncd.log: Permission denied (13) Pour ma part, sur mon serveur distant (debian sur une dedibox) j'ai du créer le fichier et lui donner les droits avec ces commandes touch /var/log/rsyncd.log chown backsyno /var/log/rsyncd.log chmod 664 /var/log/rsyncd.log A+

Salut, Je mettais penché sur cette solution aussi il y a quelques temps, mais je n'ai jamais réussi à faire fonctionner Haprixy comme je voulais. J'ai fini par acheter un raspberry (25€) et je fais le reverse avec apache...en plus c'est mieux sécurisé car le trafic http/https arrive sur le raspberry qui redirige les flux donc le syno n'est plus en frontal. J'ai également installé sslh sur le raspberry qui fait multiplexer ssl donc en arrivant avec plusieurs protocole sur le port 443 il te redirige vers la bonne appli (ssh/apache...) A+

Salut, Non j'ai abandonné cette idée...a priori personne ne l'a fait, Je n'ai pas eu plus d'aide sur le forum anglais. Pour terminé j'ai acheté un raspberry que je fais tourner sous archlinux avec sslh et apache qui fait reverse proxy. Avantage de cette solution : quand je fais une mise a jour du NAS je n'ai plus rien à reconfigurer... A+

Je suis reparti de la conf sur mon premier post, en mettant le port 50443 dans la partie 'listen ssl'. Je n'ai plus d'erreur sur le port mais d'autres...ce sont des WARNING mais haproxy ne se lance pas pour autant. [WARNING] 076/232737 (17439) : [/usr/local/haproxy/sbin/haproxy.main()] Cannot raise FD limit to 4011. [WARNING] 076/232737 (17439) : [/usr/local/haproxy/sbin/haproxy.main()] FD limit (1024) too low for maxconn=2000/maxsock=4011. Please raise 'ulimit-n' to 4011 or more to avoid any trouble. Je tourne un peu en rond, c'est dommage car un package sslh a été abandonné car Haproxy devait faire la même chose... Edit : Le package est bien lancé...mais les connexions ssl/ssh sur le port 50443 sont refusées... 28562 root 2976 S /bin/sh /var/packages/haproxy/scripts/start-stop-status start 28567 haproxy 2976 S -sh -c PATH=/usr/local/haproxy/bin:/usr/local/haproxy/env/bin:/usr/loc 28569 haproxy 4912 S /usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/var/haproxy.cfg

Oui mais c'est définie dans le fichier de conf ça ou c'est en dure ? Voici la première ligne de mon fichier de conf original frontend https bind :5443 ssl crt /usr/local/haproxy/var/crt/default.pem C'est ce qui me fait penser que l'on peut changer cette valeur, cependant je vais essayer avec le port 5443

Salut, merci beaucoup pour ta réponse. As tu testé cette conf de ton côté ? Voila ce que ça donne chez moi. Il semble qu'il n'aime pas trop le port 80443 (bind : 80443) au lancement j'ai cette erreur : [ALERT] 075/092926 (23420) : parsing [/usr/local/haproxy/var/haproxy.cfg:8] : 'bind' : invalid port '80443' specified for address '*:80443'. J'ai donc changé le port (1002 ici mais j'en ai essayé d'autres) et au lancement la même erreur qu'avant Starting HAProxy ... [WARNING] 075/093224 (2416) : [/usr/local/haproxy/sbin/haproxy.main()] Cannot raise FD limit to 4011. [ALERT] 075/093224 (2416) : Starting proxy https_in: cannot bind socket [0.0.0.0:1002]

Salut, Au tout début j'avais fait ça en mettant 4443 et c'est la même chose...merci quand même en tout cas ! A+

Bon, ça intéresse personne on dirait Pourtant il y a plein d'avantage a faire tourne ssh sur le port 443 il y a beaucoup moins d'attaque par exemple et puis du boulot on peut monter un tunnel ssh et encapsuler le traffic http dedans pour naviguer sur tous les sites sans filtrage de l'entreprise et sans laisser de trace....

Bonjour à tous, J'ai lu qu'il était possible, via haproxy, de faire fonctionner ssl et ssh sur le même port un peu comme on peut le faire avec sslh. L'intérêt, dans mon cas, est de pouvoir accéder à mon syno en ssh depuis le port 443 qui est le seul port ouvert depuis le boulot. Voici la conf que j'ai mise en place et que j'ai mise dans le fichier de conf haproxy ( /usr/local/haproxy/var/haproxy.cfg) defaults timeout connect 5s timeout client 50s timeout server 20s listen ssl :444 tcp-request inspect-delay 2s acl is_ssl req_ssl_ver 2:3.1 tcp-request content accept if is_ssl use_backend ssh if !is_ssl server www-ssl :443 timeout client 2h backend ssh mode tcp server ssh :22 timeout server 2h L'idée est d'écouter le traffic sur le port 444 du syno (redirection du port 443 de la freebox sur le port 444 du syno) et en fonction de ce que haproxy voit il oriente soit sur son port 443 (ssh) soit sur son port 22 (ssh). C'est la conf que l'on trouve partout sur le net pour cette config (pour la version 1.4 je crois) quand je lance haproxy j'ai une erreur /var/packages/haproxy/scripts/start-stop-status start Starting HAProxy ... [WARNING] 061/150555 (10478) : [/usr/local/haproxy/sbin/haproxy.main()] Cannot raise FD limit to 4011. [ALERT] 061/150555 (10478) : Starting proxy ssl: cannot bind socket [0.0.0.0:444] J'ai essayé de changer de port de mettre les adresses IP, j'ai ouvert le port 444 dans le firewall....ça ne change rien J'ai beau chercher je ne trouve pas de réponse à ce problème. Je ne sais pas si cela vient d'un pb de la conf ou d'une limitation du syno Quand je passe la commande "netstat -lpn" le port 444 n'est pas pris par un autre processus. Si une âme charitable et surtout plus douée que moi peut m'aider, merci d'avance. Vincent

Salut, La fontion reverse Proxy d'apache permet de faire ce que tu souhaites il me semble. Pas de package à installer, juste une connexion ssh...et une modif de la conf d'apache dans le Syno. Bon courage.

Bonjour, Pour en terminer avec mon sujet, cela s'est terminé par un échange de mon DS212 par le SAV syno. 2 mois de galère pour en arriver la.... maintenant c'est réglé, plus de problème.

Bonjour, Suite à divers problème sur mon NAS, j'ai décidé de réinstaller DSM sur celui ci (après formatage des disques). Je n'ai pas pensé à supprimer la licence 4 caméras supplémentaire que j'avais installée. Savez vous comment faire pour la récupérer ? Merci Vincent

Update presque 3 semaines plus tard, problème toujours présent, après formatage bas niveau des 2 disques et réinstallation de DSM rien de résolu. Le support Syno me demande de faire un échange du NAS car le problème serait hardware. J'ai lancé la procédure avec le site web chez qui j'ai acheté le NAS...j'espère ne pas trop galérer ! En attendant plus de NAS...enfin ça va faire 2 mois que le problème dure...et que le NAS fonctionne quand il a le temps !

Un petit update 10 jours plus tard, Je pensais le problème réglé avec cette histoire de caméra Foscam qui n'était pas dans la liste de compatibilité et que j'avais donc mal configurée...mais non. Le Syno a fini pas crashé 5 joues plus tard...suite à quoi j'ai désactivé surveillance station et tout fonctionne bien depuis. Le support étant a priori à cours d'idée mon cas a été escaladé aux développeurs. J'ai du fournir un mot de passe admin temporaire pour qu'il puisse avoir accès au Syno...ils ont relancé surveillance station aujourd'hui à 11h30 et le Syno à crashé vers 19h40 ce soir. Une chose est sure, le problème vient de surveillance station... J'attends maintenant un retour des développeurs. A+

On touche au but...Suite à un nouvel échange avec le support Syno il apparaît que c'est c'est bien surveillance station qui bascule le syno dans un mode d'hibernation "bâtard" (aucune mode d'hibernation n'est activé sur mon DS) J'utilise 4 caméras Foscam dans surveillance station dont une FI8909W qui n'est pas dans la liste des Foscam compatible. J'ai donc sélectionné une autre caméra qui me paraissait avoir les mêmes fonctinnalités...le problème viendrait de la...fallait trouver. Voici le message du support Syno : Hi Vincent, Thank you for your feedback. Based on the error messages from the kernal log, the camera which is not setup properly is the root cause of abnormal hibernation mode. Please note that different camera model may use different chip set and firmware so that may I say the two cameras are different. Since the camera is not on the compatibility list, we could not ensure it can work on DS. However, if it is not supported, then you still try to install it on DS with the following methods: 1.User user defined, and fill the source path which can be obtain from the camera manufacturer. 2.If it is made with PSIA standard then you may give a try to choose the option on the camera drop list and try install it. 3.If it is made with ONVIF standard then you may give a try to choose the option on the camera drop list and try to install it. If still to no avail, may I suggest you not to use the camera in surveillance station so that it won't affect hibernation feature. Voila, mon DS212 tourne depuis plus de 4 jours depuis que j'ai désinstallé surveillance station...je vais maintenant le réinstaller sans cette caméra dans un premier temps puis je tenterai ensuite de la remettre en fonction...

Quelques news de mon problème. Suite à l'analyse du kernel.log le support Syno détecte des erreurs avec surveillance station. J'ai donc supprimer le package...et le syno tourne sans problème depuis 4 jours...bizarre. Ils m'ont aussi demandé de faire un test de mémoire, que j'ai fait, et qui est ok. Je retourne maintenant vers eux pour leur dire que ça a l'air de fonctionner sans surveillance station, maintenant il va falloir comprendre pourquoi. A+

Test du second disque avec l'outils de WD...rien à signalé. Le Syno tourne sur un seul disque, je fait donc une "préparation" d'un des disques avant de le remettre dans le Syno pour reconstruire le Raid. Ensuite je fais pareil avec le second. je viens de cliquer...c'est encore plus long que le test, il m'annonce 32h00 pour 1 disque !

Je vient de terminer le test de mon premier disque dure avec l'outils de Western Digital (Data Lifeguard Diagnostics) et pas de problème remonté par l'outils. Le test est long 26h00, je viens de commencer le second disque...on verra bien. En attendant je relance toujours le support syno sur mon problème qui m'a demandé un kernel log, j'espère que ça donnera quelque chose car le fichier n'est pas éditable et je ne sais donc pas ce qu'il raconte. Par contre, pendant le test du premier disque, j'ai redémarré le Syno avec un seul disque, il n'a pas trop aimé (volume dégradé...logique...). Du coup, après la fin du premier test j'ai remis le disque mais le volume raid1 est a reconstruire. Du coup, une fois les tests terminés, en tenant compte des derniers messages et de ce que j'ai pu lire sur le net (en gros le fait que le Syno n'aime pas du tout les secteurs défectueux ce qui peut être la raison des crashs ) je pense faire un formatage bas niveau du premier disque avant de reconstruire le raid 1. Une fois que le volume raid sera ok je ferai pareil avec le second disque. Méthode pas très académique mais qui devrait fonctionner correctement... mais j'ai quand même mes sauvegardes. Je n'avais pas préparer les disques car ils étaient neuf...c'est peut être une erreur...au point ou j'en suis je test tout ! A+

Bonjour à tous, J'étais bien partie sur mon problème USB qui me semblait bien être la cause du problème...sauf que hier vers 14h00 le Syno s'est éteint...toujours aucun périphérique d'attaché donc le problème ne vient pas de l'USB. Je me lance dans le test des disques via l'outils de WD mais s'est très long il faut plus de 24h00 par disque. Une petite image du Syno planté...quand il est comme ça il n'y a plus qu'a le débranché et le rebranché pour le redémarrer c'est clair que le Raid ne va pas aimer à la longue.

Merci pour vos commentaires. Plantage de mon DS212 ce matin mais du a eu coupure EDF...faut que ça arrive quand il est plus sur l'onduleur...comme par hazard En ce qui concerne l’éventuel secteur défectueux je pense faire le test de mes disques via l'outils de Western Digital, ça devrait me dire ce qu'il en est réellement. J'ai eu un retour du support Syno qui me répond que le DS212 à surement un problème pour alimenter mon disque externe, alors que le boitier (dont je leur avait donné la ref) est alimenté par sa propre alim sur 220v...je pense qu'ils ne vont plus m'être très utile... J'ai encore des test à faire, mais si le problème du disque externe USB ce confirme il semblerait que le Syno crash quand le disque est sur un des 2 ports arrières en particulier. En gros sur un port ça fonctionne bien et sur le second le Syno crash....c'est très bizarre comme comportement mais bon. Par contre j'ai un seul boitier, donc je ne peux pas faire le test avec un autre. Cependant il fonctionne très bien, les sauvegardes sont très rapides et ne plantent pas. Je vais essayé d'avancer un peu plus ce weekend car en semaine c'est pas évident.

Salut, Non je n'ai pas transmission sur le Syno. Pour donner une suite à mon problème, voici un petit point. Le test de la carte mère demandé par Syno n'a pas mis en évidence un défaut de celle ci. Ils me demandent un test des disques durs, j'ai donc fait un test étendu S.M.A.R.T qui révèle un status normal des disques. Ils m'ont aussi envoyé un lien vers le site du constructeur pour tester les disques depuis un outils propriétaire, je n'ai pas encore fait ce test la. Cependant mon DS212 fonctionne actuellement depuis plus de 30h00 sans crash. J'ai identifié 2 éléments qui pourrait expliquer cela : - La température à un peu baissé ces derniers jours. - Pour faire le test de la carte mère j'ai du débrancher mon disque dure de sauvegarde externe, c'est un disque dur sata de 500Go dans un boitier Vantec Nexstar 3 (USB 3). J'ai redémarré le DS212 sans celui ci...et depuis ça tourne. J'ai renvoyé un message au support Syno pour leur demandé si cela pouvait être la cause de mon problème, j'attends maintenant un retour. Pour ma part, je penche pour un problème avec le disque externe (soit port usb du Syno, ou cable ou boitier externe). Je laisse tourner un peu comme ça puis je vais le rebrancher pour voir si le pb se reproduit. wait and see A+

Voila le premier retour du support syno qui confirme mes doutes sur un possible problème matériel...je test ce soir/ According to the description, does it mean that the power led and status led are always glowing, but the hdd and lan leds are off sometimes? Please follow the steps below to check the motherboard status in your Synology Product. 1. Power off the Synology Product. 2. Remove all external attached devices. 3. Remove the internal drive(s) of a Synology Product. 4. Power on the Synology Product. If the power LED appears to be flashing blue then the motherboard is defected. Please contact your retailer for repair or exchange procedure.

Et une autre plantage à 22h50, donc l'upgrade n'a vraiment rien changé...

voila c'est fait, il a planté...ça me déprime...en espérant que le support Syno aura une solution