Des testeurs avec un processeur qoriq ?

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

Ok pour l'install sur Cedarview, interface ok.

Pour la suite, j'ai rapido tenté le tuto du début ()

Pas moyen de lancer le chroot.

Ok y a la commande chroot, que explore en ce moment.

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

Ah oui effectivement je suis un boulet.

Tu as fait ça bien ...

Ok nickel, ma console SSH répond sur un port 220 pour le Chroot Debian, mais pas moyen de m'y connecter.

Dois-je créer des comptes et comment sans la console ?

UsePrivilegeSeparation yes > No dans fichier /etc/ssh/sshd_config ???

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.

Modifié le 1 novembre 201212 a par Diaoul

Ok j'ai changer le mot de passe root avec la commande "passwd" le Chroot du SSH DSM et j'ai maintenant complètement la main en SSH direct.

Super cool ... Une dernière question : Après un redémarrage le chroot ne sera donc pas démarré. Il faut donc mettre le commande /var/packages/debian-chroot/scripts/start-stop-status chroot dans un script de démarrage du DSM, lequel est le plus approprié ?

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

Modifié le 1 novembre 201212 a par Diaoul

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

Bonjour Diaoul,

Malheureusement pour moi, pour le moment je suis out, comme je te l'expliquais, j'attends mes disques (rupture chez les fournisseurs), mais d'ici deux semaines ça devrait être bon.

Je te tiens au courant dés que c'est bon.

salut, j'ai tester de me connecté au chroot, alors, j'ai un problème :

je me connecte en admin sur mon nas, ensuite je lance la commande suivante :

DiskStation> /var/packages/debian-chroot/scripts/start-stop-status chroot .

et le message d'erreur qui suit :

chroot: can't change root directory to /volume1/@appstore/debian-chroot/var/chroottarget/: Operation not permitted

une explication .

merci d'avance

je vais me repondre à moi meme, se connecter en root au lieu qu'en admin sur son nas , c'est mieux,

ca fonctionne nickel

mon ssh est demarré, mais je n'arrive pas à m'autentifié :

PTY allocation request failed on channel 0

peut etre encore une betise, mais un avis serai le bienvenu

Merci d'avance

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

fonctionne parfaitement, v tester cela plus en profondeur,

c'est très bien fait l'interface pour ajouter les service que l'on veut demarrer c'est très facile

j'ai tester l'arret et le redemmarage du paquet, et je suis arrivé à un blocage

les umount ne voulais pas se faire correctement et au redemarrage du paquet, les mount ne se faisait donc pas

je pense qu'il faudrait ajouter l'option -l aux umount dans le fichier /var/packages/debian-chroot/scripts/start-stop-status pour regler ce problème qui peux arrivé de temps en temps

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

J'ai pas attendu, j'ai tester et apparement ca regle le problème

Modifié le 2 novembre 201212 a par Gaetan Cambier

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...

j'ai pas trouvé mieux comme iddée, autrement quand on arrete le spk, il ne fait parfois pas tout les umount --> problème après pour les mount

si quelqu'un d'autre à une meilleure iddée c'est le moment

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

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

J'ai essayé avec tout les service arreter, les mount reste le il reste ceci :

proc /volume1/@appstore/debian-chroot/var/chroottarget/proc proc rw,relatime 0 0

/dev/root /volume1/@appstore/debian-chroot/var/chroottarget/dev ext4 rw,relatime,user_xattr,barrier=1,journal_checksum,data=ordered 0 0

none /volume1/@appstore/debian-chroot/var/chroottarget/dev/pts devpts rw,relatime,gid=4,mode=620 0 0

bref 3 des 4 mount reste là :s

désolé de pas avoir répondu plus tot, en semaine, c'est assez dur

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

après verification, j'avais oublié un service, et j'ai bien fermé toute les session ssh, et alors, ca se passe enfin bien

ceci dis, ca ne resoud pas le problème d'un utilisateur qui desactive le paquet en laissant un service actif ou autre, les mount ne font feront pas au lancement

c'est la tout le problème car oublié un service , c'est très vite fais ou avoir une session ssh d'un utilisateur distant en cours

Modifié le 9 novembre 201212 a par Gaetan Cambier