Sylar

Voici la config complète, directement dans le texte : global user haproxy daemon maxconn 256 log localhost user info spread-checks 10 tune.ssl.default-dh-param 2048 defaults mode http stats enable default-server inter 30s fastinter 5s log global option httplog timeout connect 5s timeout client 50s timeout server 50s timeout tunnel 1h listen stats :8280 stats uri / stats show-legends stats refresh 10s stats realm Haproxy\ Statistics frontend http bind :5080 option http-server-close option forwardfor redirect scheme https if !{ ssl_fc } default_backend web frontend https bind :5443 ssl crt /usr/local/haproxy/var/crt/default.pem ciphers AESGCM+AES128:AES128:AESGCM+AES256:AES256:RSA+RC4+SHA:!RSA+AES:!CAMELLIA:!aECDH:!3DES:!DSS:!PSK:!SRP:!aNULL no-sslv3 option http-server-close option forwardfor rspirep ^Location:\ http://(.*)$ Location:\ https://\1 rspadd Strict-Transport-Security:\ max-age=31536000;\ includeSubDomains use_backend dsm if { hdr_beg(Host) -i domaine.com } use_backend transmission if { path_beg /transmission and hdr_beg(Host) -i www.domaine.com } use_backend haproxy if { path_beg /haproxy and hdr_beg(Host) -i www.domaine.com } use_backend owncloud if { path_beg /owncloud and hdr_beg(Host) -i www.domaine.com } use_backend darkstat if { path_beg /darkstat and hdr_beg(Host) -i www.domaine.com } default_backend web backend web server web localhost:443 ssl check verify none backend dsm server dsm localhost:5000 check backend transmission server transmission 192.168.1.16:9091 check backend haproxy server haproxy localhost:8280 check backend owncloud server owncloud localhost:8888 ssl check verify none backend darkstat reqrep ^([^\ :]*)\ /darkstat/(.*) \1\ /\2 server darkstat localhost:667 check

Bonjour à tous, J'utilise avec succès haproxy pour avoir accès à tout plein de services derrière les mêmes ports 80 et 443, et ça marche plutôt bien. J'ai quand même quelques petites incohérences que je ne comprends pas. Peut être ma configuration a-t'elle un soucis ? Voici les quelques bizarreries que je constate : - www.mondomaine.com/owncloud et www.mondomaine.com/owncloud/ ne fonctionnent pas de la même façon (remarquez le / à la fin !). Le 2nd marche très bien, et redirige vers le bon backend, tandis que le premier ne marche tout simplement pas (l'adresse se "transforme" dans le navigateur alors en www.mondomaine.com:8888/ownclound/, qui n'est évidemment pas accessible directement). - un peu de la même façon (mais la config est différente, cf. plus bas, car modification de l'URL à coup de reqrep) www.mondomaine.com/darkstat ne marche pas (Not Found The page you requested could not be found. Generated by darkstat/3.0.719rc1), tandis que www.mondomaine.com/darkstat/ fonctionne sans soucis. Là encore, la seule différence est le / en bout d'adresse. Si vous avez une idée/explication, ça m'intéresse. Merci ! haproxy.cfg

Je viens de terminer la "traduction" de mon post. J'ai depuis joué un peu avec le NFC, et c'est génial pour lancer ou arrêter la surveillance en partant/rentrant de chez moi. Amusez vous bien !

Il doit y trainer des IDs temporaire liés à l'authentification, non ? (un peu comme dans la web API)

J'avais regardé la webAPI de Surveillance Station également. J'ai un peu joué avec, mais je n'ai pas trouvé comment désactiver une caméra de cette façon (a priori la fonctionnalité est non documentée).

J'ai beaucoup cherché également pour trouver une solution moins "binaire" que éteindre et allumer la surveillance. Tout ce qui se base sur sscamera n'a visiblement aucun effet ... Comme toi, la désactivation est seulement partielle : la caméra est désactivée sur l'interface web, mais continue à envoyer des données (et continue à détecter des mouvements). Ce que j'ai constaté, c'est que la désactivation depuis sscamera met les caméra dans le statut numéroté 1, tandis que la désactivation depuis l'interface web la met dans le statut numéro 2. Donc pour l'instant, je n'ai pas d'autres solutions, malheureusement.

J'aissaierai d'en faire une faire une version française dans la semaine. Je la publierai ici du coup.

J'ai fait un script qui permet d'activer/désactiver automatique Surveillance Station quand je quitte ou rentre de chez moi. Je l'ai posté sur le forum Synology, mais je me suis dis que ça pourrait intéresser la communauté française de NAS-forum (que je consulte régulièrement pour bidouiller mon NAS ), aussi je me permets de vous en avertir. Voici un lien vers le sujet, que je compléterai plus tard avec la partie "téléphone". http://forum.synology.com/enu/viewtopic.php?f=82&t=81181&p=304567#p304567 Je suis sûr que ce que j'ai fait est largement améliorable, donc n'hésitez pas ! EDIT : en voici une traduction pour les non anglophones. ------------------------------------------------------------------------------------------------------------------------ J’ai écrit un script qui fonction avec Tasker (sur Android) pour démarrer et stopper automatiquement Surveillance Station (SS) quand je pars ou reviens de chez moi. J’ai cherché longtemps comment faire, et après quelques tests, la solution ci-dessous marche plutôt bien. Evidemment, je suis certain que tout ça peut être largement amélioré, donc n’hésitez pas ! Pré-recquis : - un ordinateur pour générer les clés SSH. C’est facile à faire sous Linux et OSX, et probablement sous Windows aussi - sur le NAS : SSH doit être actif et fonctionnel, de même pour SS. L’accès à l’utilisateur root doit être possible depuis un autre utilisateur (non administrateur) avec la commande su. - sur le téléphone : Tasker doit être installé, ainsi qu’un plugin SSH (j’ai mis des liens en bas du post). Ces 2 applications sont payantes, pour un total de 5 euros environ seulement. Il y a peut être moyen de passer par d’autres applications gratuites, donc si c’est le cas, dites le moi ! Evidemment, un téléphone Android est nécessaire, mais il y a probablement moyen de coder une application pour iOS qui ferait ce que je propose (mais je ne sais pas faire !) Aller, en route ! 1/ Adapter la configuration du serveur SSH Idéalement, SS doit être démarré et stoppé par l’utilisateur root. Ce n’est pas un problème en soit, puisque la commande sudo est justement faite pour ça. Seulement, le script de démarrage de SS est passablement complexe, lance de nombreux binaires, etc., tant et si bien que la solution sudo n’est pas si évidente à utiliser. A la place, l’idée est de gérer SS justement par l’utilisateur root. Mais ceci nécessite que root est accès au NAS par SSH, ce qui n’est PAS DU TOUT une bonne idée. La solution consiste à utiliser les « commandes forcées » (forced commands), c’est à dire que l’accès root ne sera possible que pour lancer une commande spécifique. 1.1/ Modifier la configuration du serveur SSH Pour permettre les commandes forcées, ajouter la ligne PermitRootLogin forced-commands-only au fichier /etc/ssh/sshd_config, et rebooter le NAS (j’ai stoppé et redémarré le serveur SSH, les modifications dans le fichier ne semblent prises en compte qu’au reboot … bizarre !) Maintenant, l’utilisateur root peut accéder au NAAS, mais seulement pour lancer une commande spécifique précisée dans la clé SSH que nous allons générer maintenant. 1.2/ Génération des clés SSH Sur l’ordinateur (ou sur le NAS, mais celui-ci étant moins puissant, la génération des clés sera plus longue), ouvrir un terminal, et lancer % ssh-keygen -t rsa -b 8192 -C « yourname@yourphone » Je génère ici une clé de 8192 octets et le paramètre -C permet d’ajoute un commentaire (on peut y mettre n’importe quoi). A noter que ceci est assez direct sous OSX ou Linux, il y’a probablement moyen de faire ça sous Windows, mais n’ayant pas de PC sous Windows je ne pourrai être plus précis ici. L’utilitaire demande éventuellement une « passphrase » (un mot de passe protégeant la clé). Autant en mettre une, elle pourra être saisie plus tard dans Tasker une fois pour toute. Une fois terminé (selon la longueur de la clé, ça peut être long, même sur une machine récente !), on dispose de 2 fichiers : - id_rsa : c’est la clé privée, qui sera à transférer sur le téléphone plus tard (pour l’instant, laissons la où elle est !) - id_rsa.pub : c’est la clé publique, que nous allons transférer sur le NAS. Ces 2 fichiers sont normalement situés dans le répertoire « caché » .ssh/ de votre répertoire utilisateur. 1.3/ Connexion au NAS Se connecter maintenant au NAS par SSH depuis un utilisateur standard, puis passer root à l’aide de la commande su. Puis : % cd /root % mkdir .ssh (si le dossier .ssh/ existe déjà, sauter cette dernière commande) Puis on va éditer le fichier « authorized_keys ». Si ce fichier n’existe pas, il faut le créer. Il faut ensuite copier la clé publique à l’intérieur de ce fichier (le contenu du fichier id_rsa.pub créé précédemment). authorized_keys doit alors ressembler à ceci (c'est une clé que j'ai générer pour ce tuto. Evidemment, votre clé étant différente, le fichier le sera aussi) : ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCds3+RK4zfG7L5JmNkaSVBPufUPQMJUIxYfesFAEuetHoD2Fvy/hojIXyG3VnSbzZfVZo4ptoXYtiij8fwf2kWzk0W/Dxrt/Npxzs5eUjZFgF+b16xF6YB1yW3tklJrRJmqmOjIQKl6b8tC3OEWbOMzrQrmtNPWL991XjUKT2mIPG5Hrt3fN/4WKiX8nwESr6FnxH97HyQWpPnEjfpBq6uoOuTCKBT8xi6v6L6ReNTvwkmf8k9zqABDE5oe4i48skQws88VMP0nT9wsSlV8J80MurOEX1WwxNByIMndj2shJS5P+gu6mHSufOLTTADUASor2uWZFWsgJyz9Bl7jgFT yourname@yourphone Maintenant, une clé autorise l’accès root depuis SSH. Mais si on tente de se connecter directement, ça ne fonctionne pas ! Et heureusement, car la directive forced-commands-only n’autorise pas le login root, mais seulement le lancement d’une commande donnée. Cette commande doit être ajoutée dans le fichier authorized_keys au tout début de la clé. Par exemple, cela donnerait dans le cas de la clé précédent : command="/bin/ls",no-port-forwarding,no-X11-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCds3+RK4zfG7L5JmNkaSVBPufUPQMJUIxYfesFAEuetHoD2Fvy/hojIXyG3VnSbzZfVZo4ptoXYtiij8fwf2kWzk0W/Dxrt/Npxzs5eUjZFgF+b16xF6YB1yW3tklJrRJmqmOjIQKl6b8tC3OEWbOMzrQrmtNPWL991XjUKT2mIPG5Hrt3fN/4WKiX8nwESr6FnxH97HyQWpPnEjfpBq6uoOuTCKBT8xi6v6L6ReNTvwkmf8k9zqABDE5oe4i48skQws88VMP0nT9wsSlV8J80MurOEX1WwxNByIMndj2shJS5P+gu6mHSufOLTTADUASor2uWZFWsgJyz9Bl7jgFT yourname@yourphone Maintenant, si on tente depuis l’ordinateur : % ssh root@NAS_IP un « ls » est fait sur le NAS par l’utilisateur root. Et ce sera la seule commande qui sera accessible à l’utilisateur root en login direct (sans passer par su). Bien sûr, tout cela n’est possible que si la clé privée id_rsa est utilisée par le client SSH pour se connecter. Si ce n’est pas le cas, cela ne fonctionnera pas, et heureusement ! authorized_keys sera modifié un peu plus tard pour lancer la commande qui lancera ou stoppera SS. 2/ Script pour démarrer et arrêter Surveillance Station Je propose le script suivant. Je ne suis clairement pas un expert des scripts shell, je suis donc certain qu'il peut être amélioré. Dans tous les cas, il fonctionne bien pour moi #!/bin/sh cd /root/sStation FILE1=here1 case "$SSH_ORIGINAL_COMMAND" in "start") # START SS ONLY WHEN LEAVING HOME if [ -e $FILE1 ]; then # If user1 was here rm $FILE1 echo $(date): "ss START (User1 leaving home)" >> ss.log /var/packages/SurveillanceStation/scripts/start-stop-status start > /dev/null 2>&1 # Launch SS echo 4 > /dev/ttyS1 # Turn POWER LED ON echo $(date "+%H:%M:%S"): "OK, Surveillance ON" else # User1 was not here ... so it means that SS is already ON ! echo $(date "+%H:%M:%S"): "Surveillance already ON" fi ;; "stop") # STOP SS ONLY WHEN ENTERING HOME if [ -e $FILE1 ]; then # Oups, user1 is already here ... echo $(date "+%H:%M:%S"): "Surveillance already OFF" else # User1 is coming ... echo bonjour > $FILE1 echo $(date): "ss STOP (User1 @home)" >> ss.log /var/packages/SurveillanceStation/scripts/start-stop-status stop > /dev/null 2>&1 # Stop ss echo 6 > /dev/ttyS1 # Turn POWER LED OFF echo $(date "+%H:%M:%S"): "OK, Surveillance OFF" fi ;; "status") # CHECK IF SS IS RUNNING ps | grep urveillance > /dev/null if [ $? -eq 0 ]; then echo "SS is ON" else echo "SS is OFF" fi ;; *) echo "Sorry. Command forbidden." exit 1 ;; esac Quelques commentaires : - La première ligne "cd /root/sStation" indique où se situe le script sur le NAS. Il peut être mis n'importe où. - j'utilise ici la variable SSH_ORIGINAL_COMMAND qui permettra de donner accès à root à une seule commande (spécifiée dans le fichier authorized_keys) qui peut réaliser différentes tâches. De cette façon, nous n'aurons pas à générer autant de clé spécifique à une action (start, stop, status, etc.), elle sera simplement spécifiée en argument. - je garde une trace des démarrage/arrêt dans un fichier de log ss.log - j'ai choisi d'allumer et éteindre la diode "power" de mon NAS pour indique si la surveillance est active ou non. C'est optionnel, évidemment - le script renvoie différents textes, en fonction de l'action et du contexte. C'est ce texte qui pourra être affiché sur le téléphone. - enfin, à défaut d'avoir trouvé une autre façon de faire, le script démarre et arrête la surveillance : c'est complètement binaire ... J'ai essayé d'autres solution (désactiver seulement les caméras, ou utiliser l'API officielle), sans succès. Il y a certainement moyen de faire mieux ! 3/ Tests, depuis un ordinateur Tout est normalement prêt maintenant. - tout d'abord, copier le script dans le dossier indiqué sur les premières lignes du script ci-dessus. - le rendre exécutable (chmod +x /root/sStation/surveillance.sh, en tant que root, sur le NAS) - ensuite, modifier le fichier authorized_keys situé dans /root/.ssh/ pour y indiquer que la seule commande autorisée est justement notre script : command="/root/sStation/surveillance.sh",no-port-forwarding,no-X11-forwarding,no-pty - vérifier que la clé privée est bien utilisée pour se connecter en tant que root sur le NAS depuis l'ordinateur (généralement, il faut que le fichier id_rsa généré précédemment soit dans /root/.ssh/) - c'est parti ! Depuis l'ordinateur, il est normalement possible de lancer / stopper la surveillance : % ssh root@NAS_IP start ou % ssh root@NAS_IP stop ou % ssh root@NAS_IP status Pas besoin de spécifier la commande (surveillance.sh), celle-ci est déjà précisée dans le fichier authorized_keys. Seul son argument est à envoyer pour faire un start, stop ou status. ------------------------------------------------------------------------------------------ ATTENTION : ne pas continuer plus loin tant que l'étape 3 ci-dessus est OK ! ------------------------------------------------------------------------------------------ 4/ Tasker - Installer Tasker et son plugin SSH (cf. fin du post) - Je ne peux pas décrire le fonctionnement de Tasker ici. Il y a une tonne de tuto sur le web expliquant bien mieux que moi son fonctionnement. Basiquement, Tasker permet d'exécuter des tâches en fonction d'un contexte (un lieu par exemple). Il faut donc écrire 3 tâches, chacune pour lancer la commande start, stop et status. Et cela est rendu possible en exécutant exactement la même commande que depuis un ordinateur (cf. étape 3). Seulement, il nous faut transférer auparavant la clé privée sur le téléphone afin de l'autoriser à lancer la commande surveillance.sh. Copier donc le fichier id_rsa par le moyen que vous voulez (USB, FTP, etc.), et imaginons que ce fichier soit placé dans /storage/emulated/0/Tasker/ sur le téléphone. - Créer une tâche, appelée par exemple "ss Status" - A l'intérieur, utiliser le plugin SSH pour lancer la commande SSH "magique" : - dans le champ adresse, rentrer « root@NAS_IP:22 » à adapter éventuellement en fonction de votre configuration) - Ensuite, choisir "Keypair" et sélectionner la clé copiée à l'instant sur le téléphone - rentrer la passphrase si celle-ci a été donnée lors de la création des clés (étape 1) - puis, entrer la commande à exécuter. Ici, rentrer simplement "status" - enfin, cocher « return output »n puis entrer le nom d'une variable (%ssout par exemple). Cette variable contiendra le texte renvoyé par la commande pour affichage. J'ai mis des captures d'écran sur le thread synology cité plus haut. Enfin, il ne reste plus qu'à créer de la même façon une tâche pour le démarrage, et une autre pour l'arrêt. Tasker permet d'ajouter des raccourcis vers des tâches sur le launcher : en un clic, on peut allumer ou éteindre la surveillance Puis on peut spécifier des conditions qui lanceront/éteindront automatiquement la surveillance : en fonction de la position, de l'heure, etc. Pour ma part, j'utilise maintenant un tah NFC que je scanne en partant et qui lance la tache "start" Voilà ! J'espère qu'à défaut d'être absolument complet, mon post vous donnera des idées ! Il y a moyen d'améliorer tout ça, c'est certain. Donc n'hésitez pas à le faire dans la suite du thread ! Tasker: https://play.google.com/store/apps/details?id=net.dinglisch.android.taskerm SSH-plugin: https://play.google.com/store/apps/details?id=com.laptopfreek0.sshplugin.paid

Je vous réponds, super à la bourre. Le simple reset n'a rien donné, j'ai donc fait le "double", avec reset complet de la machine (mais sans perte de données). Les fichiers systèmes ont bien été réinitialisés, et j'ai pu réinstaller ipkg sans soucis (je n'avais besoin que de unison, un soft de syncho). Je n'ai du coup pas eu l'occasion de tester avec l'interface web, mais bon à savoir qu'admin a les droits root depuis l'interface ...

J'ajoute une précision : s'il y a moyen de faire ça sans reset, ça m'arrangerait ;-)

Bon, j'ai fait mon boulet ... J'ai fait la mise à jour de mon DS209 vers le DSM 3.2. Pour faire cela, j'ai désactivé ipkg en renommant /etc/rc.local. Du coup, au reboot, /opt n'est plus monté automatiquement. MAIS, je n'avais pas fait attention que j'avais changé le shell de root, justement vers /opt/bin/zsh ... du coup, root n'a plus de shell valable pour se logger, et je suis coincé pour remettre "en route" ipkg (et j'en ai évidemment besoin ...) Seul le compte admin peut encore se logger en ssh (et telnet), mais je viens de m'apercevoir qu'en fait il n'est pas un vrai admin du syno, puisque qu'il n'a pas de droits équivalents à root. Bref, je suis coincé. Du coup, les seules solutions que je vois sont : - réinitialier /etc/passwd, de sorte que le shell de root redevienne celui par défaut (/bin/sh) : oui, mais comment faire ? - "forcer" ssh à utiliser un login shell donné : ça m'étonnerait que ce soit faisable ? Je n'ai trouvé en tout cas pour faire ça (et rappel : admin n'a évidemment pas les droits pour changer la config du serveur ssh ...) Merci de votre aide, je suis à court d'idées ...

Bonjour