Diaoul

He bien il ne te reste plus qu'a acheter un nom de domaine (6€/an) et faire pointer *.tondomain.tld vers xxx.hd.free.fr en CNAME. Ansi tous les sous domaines sont redirigés vers la même IP que xxx.hd.free.fr.

Oui tu as bien compris, en fait, tu peux faire toute sorte de règle pour rediriger un frontend (écoute le HTTP sur le port 5080) vers un backend (service web tournant sur le syno, ou ailleurs sur ton réseau comme SABnzbd, SickBeard, WebDAV, AudioStation, etc.) Par exemple: * box.mondomain.tld => 192.168.1.254: La condition que l'on met c'est sur la structure de la requête reçue par HAProxy. Voir ici pour un peu de détail sur la structure d'une requête HTTP. La condition est : si le header Host commence par "box." alors faire le proxy vers 192.168.1.254: Dans la configuration ça se traduit par cette condition. Ca marche avec les NDD xxx.hd.freebox.fr si et seulement si les sous domaines sont possibles. Par exemple il faut que sickbeard.xxx.hd.freebox.fr pointe bien vers chez toi.

Dans ma configuration : https://sabnzbd.mondomaine.tld (port 443) -> box -> syno (port 5443) -> haproxy decipher le SSL, voit que ça commence par "sabnzbd.", redirige donc vers localhost:8080 Avantages dans ton cas : * Je peux ajouter d'autres services que SABnzbd sur un même port externe (SickBeard, DSM, CouchPotato Server, etc.) * Pas besoin d'activer le SSL dans SABnzbd * Gestion du SSL à un seul endroit, HAProxy, facile pour la maintenance et changer le certificat, il suffit de le faire à un seul endroit * Peu de ressource consommées par rapport à la gestion du SSL sur certains services comme SABnzbd * Blocage complet de plages d'IP possible directement depuis HAProxy * Bien d'autres choses, voir la doc de HAProxy

Tu peux faire un wrapper SSL avec HAProxy SSL ne permet pas d'éliminer les tentatives de connexion mais juste de sécuriser les mots de passes qui transitent sur le réseau et ainsi d'éviter de te le faire piquer par un attaquant.

Si tu enregistres le service lancé dans le chroot via l'interface je peux faire en sorte qu'il se coupe lors de l'arrêt du SPK. Par contre pour un service non enregistré ce sera toujours un problème.

Un nom de domaine à 6€ / an que tu fais pointer en CNAME vers ton entrée DDNS Synology et c'est réglé.

Essaye de lancer les umount à la main pour voir si t'as un message d'erreur quelconque.

Pour avoir accès à Gtalk (ou quasiment toute autre type de messagerie instantanée) via IRC tu peux te tourner vers BitlBee

C'est exactement ça

Tu peux toujours éditer le postprocessing de SickBeard ou alors le mettre en mode watch directory et lancer ton propre script de post-traitement SABnzbd qui te virre le trucmoche

Pour information SynoCommunity a des miliers d'utilisateur, tu n'arrives pas à installer correctement un package et c'est de la faute de SynoCommunity ? T'es sur ? Ce qui est dramatique c'est d'installer des packages sans même lire leur description...

Ils sont en qinst, nous non. Je pense que c'est ça.

Il y a déjà Mylar mais c'est buggé. Omniverse me semble pas maintenu.

Oui

Tu peux confirmer que fermer tous les services avant de stopper le SPK fonctionne sans l'option -l ?

Ce n'est pas un problème, c'est juste le comportement par défaut du Package Center sur un dépôt tiers. Le premier clique ne fait que le téléchargement (même s'il met le formulaire d'installation) et le secon clic installe vraiment le SPK. Il faut voir avec Piwi si y'a pas des options dans le JSON de retour qui permettraient de répliquer le comportement du repo officiel.

Si les umount ne se font pas c'est que tu as un service qui tourne dans le chroot et qui utilise le mount (ou même peut être ta fenêtre SSH ?) Donc ça me parrait mieux de stopper les services dans le chroot plutôt que de laisser les mounts se défaire en mode lazy

Apparament ce n'est pas une option très conseillée car elle laisse en fait le mount actif pour le processus qui l'utilise...

Tu peux éditer le script manuellement et tester ta solution ? C'est l'occasion

Cool merci

Stop le SPK et relance le. Les mounts peuvent merder si tu as coché "Lancer après l'installation"

Un chroot est un environnement mort, il ne démarre pas. C'est un ensemble de librairies et binaires stockées dans un répertoire qui n'est pas la racine. La commande permet juste "de faire comme si" ce répertoire était en fait ta racine. Par conséquent tu ne peux pas remonter plus haut que la racine, tu es donc enfermé dans le chroot. On parle aussi de "jail", prison. Ca te donne donc accès à tout l'environnement Debian mais tu ne peux pas interragir avec le reste de ton Syno, par exemple depuis le chroot tu n'as pas accès à tes disques /volume1/, /volume2/, etc. Démarrer/arrêter debian-chroot permet juste de faire les mounts nécessaires au bon fonctionnement du chroot : https://github.com/S...-control.sh#L13 Il n'est pas possible actuellement de relancer les services enregistré dans l'interface automatiquement au redémarrage. Je ne suis pas sûr que ce soit une bonne idée, a voir

Te connecter en SSH au chroot en root == Faire /var/packages/debian-chroot/scripts/start-stop-status chroot Je te suggère donc d'utiliser la seconde méthode pour mettre en place des users.

Va voir dans l'aide de DSM, section "Debian Chroot"

Alors ces tests ça donne quoi ? J'ai du filer le SPK beta à 5 ou 6 personnes