Diaoul

Si c'est le cas n'importe quelle commande lancée de cette manière devrait être impactée, y compris : import subprocess subprocess.check_output(['exit 0'], stderr=subprocess.STDOUT) Quelqu'un peut tester ça sur son NAS en lançant un Python avec /usr/local/python/bin/python ?

On peut me faire un récap du problème ? Il y a un message d'erreur alors que tout va bien c'est ça ?

C'est certainement du à un changement de config fait par Gaetan. Ou alors HAProxy a déprécié une fonction comme ça a été le cas par le passé.

L'ajout dans le PATH est un paramètrage utilisateur et ne devrait pas faire partie d'un package à mon sens.

Regarde ici : https://github.com/SynoCommunity/spksrc/issues/1041

Faut cliquer sur un bouton.

Les toolchains DSM 4.3 sont compatibles DSM 5.0 donc pas de souci de ce coté là.

Non ce n'est pas possible sur un Syno boostrappé car spksrc cross compile et ne compile pas en natif. Pour l'instant oui car les toolchains 5.0 ne sont pas compatible DSM 4.x.

Chez moi ça marche DSCam comme les autres applications. Si tu fais du HTTPS il faut juste spécifier le port 443 en plus de l'URL.

La version de SynoCommunity fourni virtualenv sur Python 2.7 et Python3. Si tu veux utiliser venv à la place, effectivement il te faudra Python3. Flask fonctionne en Python3 mais il se peut que certaines librairies tierces (extensions de Flask ou autres) ne soient pas encore portées. Le mieux c'est de commencer avec Python3 et si tu vois qu'un module dont tu as besoin n'est pas porté tu repasses sur Python 2.7. De toute façon 2.7 est très proche de 3.3+. SynoCommunity fourni Python3 à la version 3.4.1 ainsi que certains modules préinstallés.

Je vais t'indiquer la méthode la plus "propre" : Installer le paquet Python de SynoCommunity Se connecter en "root" en SSH > PATH=/usr/local/python/bin:$PATH # inclut les binaires python > cd /volume1/monappli/ # te déplace dans le répertoire de ton appli > virtualenv env # créé l'environnement virtuel > source env/bin/activate # active l'environnement virtuel > pip install Flask # installe flask dans cet environnement virtuel Pour retourner dans ton appli par la suite : > cd /volume1/monappli/ && source env/bin/activate Puis pour lancer ton appli "app.py" avec ton environnement virtuel : > python app.py L'avantage de cette technique c'est que tu as un environnement séparé et que tu peux mettre à jour le paquet Python sans perdre aucune donnée. Par ailleurs si tu veux supprimer l'environnement virtuel tu n'as qu'a supprimé le répertoire "env" dans /volume1/monappli/

Pour faire du CGI je te conseillerai Flask, ça évite de réinventer la roue. Tu fais ton application avec Flask puis tu fais un CGI à coté. Tu trouveras plein de documentation sur Flask + CGI sur Google et en plus tu peux tester en live avec le serveur intégré. Coté protocole, il faut savoir que le XPL c'est très verbeux et tu vas te faire chier à sérialiser ton message si tu veux faire de l'XBee, c'est pour ça que je suis passé par protobuf perso, en plus ça fait du code clean. L'inconvénient c'est que nanopb, aussi petit soit-il, prend de la place sur l'Arduino donc je recommande 32kb minimum.

Ne pas passer par un protocole haut niveau pour communiquer avec l'Arduino ? L'UDP ce n'est pas fiable, vaut mieux faire du TCP si tu veux rester sur de l'IP. Perso je passe par des XBee avec protobuf pour la sérialisation des messages (librairie nanopb sur Arduino). Tu peux regarder le module Python que j'ai développé pour la communication avec un module XBee : http://hachi.readthedocs.org/en/latest/

Par défaut, l'appli prendra le port du service au lieu de prendre le port https standard (443). Par conséquent il faut rajouter :443 à la fin de l'URL pour fixer le numéro de port.

Le problème a déjà été remonte, regarde https://github.com/SynoCommunity/spksrc/issues/1177 et d'autres issues

Donc pour faire quelque chose d'aussi simple que ça il faut passer par SSH ? Ils auraient pu l'intégrer au SPK...

Effectivement si tu as déjà 5To de données, un 2 baies ça fait short.

Je m'autoquote parce que je n'ai pas eu de réponse à cette question Merci

@Gaetan : Est-ce que la config par défaut est si catastrophique qu'il faudrait mettre à jour la config lors de l'update du SPK selon toi ? Ou est-ce que ça suffit de le faire pour les nouveaux utilisateurs ? Si je fais l'update sur les utilisateurs existants, quid de la rétrocompatibilité ?

Parfait merci, j'inclurai ça dans la prochaine release.

Je ne sais pas ou se situe le DS415+ par rapport au DS415play mais ça peut valoir le coup de se pencher sur la question étant donné que le DS415play est relativement cher. Tu as aussi le DS414 qui est pas mal et qui doit avoir un tarif raisonnable. Il est inutile d'attendre la sortie d'un modèle x15 juste pour avoir le dernier cri, si l'architecture est récente et la fréquence correspond à ton utilisation fonce J'ai hésité avant de prendre mon DS412+ en 2013 et j'ai bien fait de le prendre parce que la relève aura sauté 2 générations (DS415+). Edit: Si le transcodage t'intéresse alors tu devrais te pencher sur du play effectivement. Maintenant il faut être bien au courant des limitations (DTS, bande passante, etc.)

Merci pour ton retour, tu peux faire une pull request pour modifier la conf par défaut? Il te faut juste te connecter à GitHub et éditer ce fichier: https://github.com/SynoCommunity/spksrc/blob/develop/spk/haproxy/src/haproxy.cfg la PR sera automatiquement crée

Je ne dis pas qu'il n'y a pas d'amélioration, je dis qu'elle ne sont pas notables. Je trouve que c'est un peu sortir un NAS parce qu'il faut sortir un NAS quoi. Purement marketing.

Pas révolutionnaire par rapport au DS412+

Le bug est déjà remonté : https://github.com/SynoCommunity/spksrc/issues/1229 J'ai envoyé un mail à mon contact chez BTSync, on verra bien.