m1thos

Salut, Le répertoire où est installé ton debootstrap (volume1/debian de mémoire). Le supprimer complètement, en recréer un autre et réinjecter le tar issu de ton debootstrap. Puis tenter à nouveau de chrooter ton système.

Bonjour, C'est vrai que les codecs sont un eternel problème : l'exemple du hi10p est flagrant (ce n'est d'ailleurs pas un codec mais plutôt un setting d'encodage). Le wd tv live lit le h264 mais pas le 10bits, et il est vrai que c'est spécifié nul part. Après moi franchement hormis le hi10p je n'ai jamais eu aucun problèmes quelque soit la vidéos (meme si il est vrai que depuis un an environ tous mes nouveaux fichiers sont des backup que j'encode moi même, en dehors des animes). Je te parlais du 10bits à cause des infos de ton profiĺ, étant moi même "victime" de ce problème. Regarde le mediainfo des vidéos incriminée. Ca doit être spécifié. Concernant mon script, je ne vois aucun inconvénient á te le passer, mais sache qu'il est construit autour d'outils et avec des paramêtres propre à mon NAS (712+ Avec une architecture Atom). Il faudra surement l'adapter á ton NAS si il n'est pas du même type. PS : détails importants que j'ai oublié, un Nas, même un Atom, n'est pas dédié à l'encodage. Je veux dire par là que le processus prend plus de temps qu'en le faisant depuis un PC. Pour ma part, je ne réencode que des animes (donc des fichiers entre 200-450Mo). Le NAS travaille environ 30minutes (je ne fais qu'une passe avec un profil HQ...sur des animes je ne vois pas la différence en multi-passe), contre un peu plus de 5 minutes sur mon PC. Le principe étant que la nuit, le NAS vérifie dans un dossier spécifique si il y a des vidéos, et si c'est le cas, les réencode et les déplace. Si les vidéos que tu ne peux pas lire sont d'un autre type (un film de plusieurs Giga), ou si c'est juste 2-3 vidéos dans toute ta ludothèque, le réencodage par le NAS, n'est pas DU TOUT une idée ingénieuse. T'auras nettement plus vite fait de passer par ton PC.

Bonjour. mkv c'est le conteneur. Au même titre que les autres extensions (avi, mp4 etc....). Dans un conteneur tu as plusieurs choses : la ou les pistes son, les sous titre et la video encodé sous un certain format). En d'autre termes, dans un mkv tu peux avoir une vidéo encodée en divx, xvid, h264 etc...). Pour ma par et en dehors de quelques formats très exotiques je n'ai jamais eu de soucis de lecture (mes backup blue ray sont en h264 et les mkv font souvent plus de 10-15 go). Ceci dit, puisque qu'apparemment tu es toi aussi fan d'animes attention : les seuls gros soucis que j'ai pu avoir sont sur les vidéos encodées en h264 hi10p ( en 10bits). C'est la mode depuis quelques temps déjà chez certaines teams de fansub. Le wd live ne lit pas ce format ( aucune passerelle à ma connaissance non plus d'ailleurs). Il faut donc ré-encoder (pour ma part jje me suis développé un petit script sur le synology qui fait ça tout seul).

Salut, T'es vraiment reparti de 0 ? (En supprimant le repertoire debian sur ton syno et en reprenant toues les etapes ?) ton erreur pue le problème d'architecture. PS : je reponds quand je peux. Je ne suis pas toujours disponible surtout en ce moment. D'autant plus qu'il y a sur ce forum des personnes nettement plus compétentes que moi en la matière :-)

D'autant plus que l'offre 30Mb de numéricable n'est même pas du FTTLA (qui est déjà considéré par certains comme n'étant pas de la fibre). Sur du FTTLA avec quelques mètres de coaxial à la limite, qu'ils commercialisent ça sous appellation "fibre" ça ne me gêne pas. Mais quand t'as plusieurs centaines de mètre de coax avant d'arriver au répartiteur et vendre ça sous le nom "fibre" c'est juste scandaleux. A ce moment là, l'adsl aussi c'est de la fibre.

Bonsoir, @Cignale Supernews par exemple a 10 ans de rétention pour les fichiers textes (8 ans pour giganews). Après niveau tarif, ça dépend effectivement de l'offre que tu as prise (je suppose vu tes besoins, que tu as pris la plus petite offre avec quota). J'en doute pas, même si la première phrase de mon intervention précédente était assez ironique. Il faut dire que dans 95% des cas, on associe les FAU aux fichiers binaires...et donc forcément... Toutes mes excuses donc. Après sur le fond, je suis un peu dans la même situation que toi : de toute façon je n'ai pas (ou pour être honnête "plus") le temps de m'adonner à ce type de pratiques. Après j'ai une opinion tout à fait différente du droit d'auteur (tel qu'il existe à l'heure actuelle, pas sur le principe)...mais bon, c'est un tout autre débat. @StephanH Bah pour être clair oui, c'est le principal intérêt (si on peut dire). Après oui, la connexion est chiffrée, ce qui peut laisser penser qu'on gagne en sécurité. Mais on est dans le cadre d'un proxy publique, donc cet argument ne tient pas forcément la route.

Bonsoir, Concernant ton script, je pense qu'il y a un problème de codage lorsque tu as créer son script (attention aux éditeurs de texte qui souvent posent problème quand on envoie le truc tel quel sur linux). Via putty sur ton NAS, fais vi /volume1/debian/chroot.sh Regardes si t'as pas des caractères à la con ou un problème du genre sur ton script. Au besoin modifies le pour que tout soit nickel. Si t'as ipkg sur ton nas, tu peux tenter d'installer nano, plus aisé d'un vi quand on a pas trop l'habitude.

Salut, Giganews pour un simple lecteur de news ? T'as pas trouvé le plus économique ( je mets de coté évidemment toute autre forme d'utilisation plus controversée..et même là giganews n'est plus ce qu'il était ). Pour en revenir au sujet, hypervpn est plus selon moi un proxy sécurise. J'entends par là que son intérêt est différent d'un vpn "perso" ou d'entreprise permettent de créer un tunnel entre 2 réseaux LAN. Là on est dans le cadre d'un vpn public. Comme je disais l’intérêt premier est le coté proxy de la chose. Autrement dit cacher ton ip derrière une autre (fournie par giganews). Ca apporte entre autre un relatif anonymat (utilisé pour des raisons philosophiques...ou pour passer inaperçu auprès d'une certaine institution commençant par h et finissant par i ). Ca peut également être utilisé pour avoir accès à certaines ressources et sites bloqués en dehors de leurs pays diffuseurs. Attention ! je ne dis pas que hypervpn est un proxy ! c'est bien un VPN au sens premier du terme étant donné que tout le flux sortant est encapsulé dans un tunnel. Je parle uniquement du "rôle" qu'il peut jouer. PS1 : désolé pour les fautes. Taper à la tablette c'est pas simple quand on a pas l'habitude.

Salut, A condition que vous n'ayez pas désactivé le compte admin (en utilisant un autre compte du groupe administrateur ça ne fonctionne pas.

Salut, Je suis pas dieu le père hein... T'as essayé ce dont j'avais parlé il y a quelques posts de ça déjà (indiqué également dans le tuto donné par Vincs) ? A savoir rentrer dans le chroot avant la commande d'installation de debian ? (En résumé, linkage des répertoires nécessaires, lancement du chroot, puis une fois dans le chroot, la commande debootstrap). Parceque, et aux risques de me répéter, si je me base sur la procédure que t'as suivi et que t'as donné dans le post #212, tes répertoires ne sont pas linkés. je vois donc pas comment tu peux rentrer dans un chroot dans ces conditions.

Salut, @nautilus Heuuuuuu.... je viens de réaliser en relisant ta procédure. Y a une grosse coquille. Ton architecture n'est pas bonne ! Le MPC8533E n'est PAS un proc 64 Bits....Il a un BUS mémoire est en 64bits oui mais ne gère le jeu d'instructions 64 bits. Donc quand tu fais ton first stage pour le bootstrap, y a un problème.. sudo debootstrap --foreign --no-check-gpg --arch=ppc64 --variant=buildd sid chrootcible "http://ftp.de.debian.org/debian-ports" C'est plutôt l'arch powerpc sur laquelle il faut que tu partes.

Bonsoir, Est-ce que tu as activé telnet et/ou ssh sur ton syno ?

Salut, T'as essayé de rentrer ta commande debootstap après être entré dans le chroot ? (après avoir linker les répertoires nécessaires). Parceque ce que je comprends pas (mais je ne suis pas un spécialiste) c'est comment tu peux entrer le chemin "chrooté" du debootstrap en n'étant pas encore dans le chroot.

Salut, Petit problème, tu ne donnes pas le lien de ce tuto Ce que je comprends pas c'est le point "5". Le script chroot.sh est, je suppose vu le nom, chargé de lancer le chroot ? donc le début de ta commande (chroot /volume1/debian) n'a pas lieu d'être ? (dans la mesure où tu exécutes le script avant).

Bonsoir, Le problème du ffmpeg installé par défaut sur le nas est très limité. Y a plusieurs solutions : - via ipkg (mais le problème est identique...version ancienne) - compilant toi même ce que tu veux sur ton NAS. On en parle ici : J'avais tenté la crosscompilation, mais c'est pas évident. Y a énormément de dépendances. Faut donc s'armer de courage. - En utilisant le chroot Debian du syno. C'est la solution que j'ai choisi personnellement. Ca fonctionne nickel. Voir ici :

Bonjour, Voilà, j'ai un petit soucis avec le module permettant de voir les connexions en cours sur DSM (que ce soit via le panneau latéral ou dans le moniteur de ressources) : Je ne vois pas les connexions extérieures à mon réseau LAN. D'ailleurs même en incluant celles ci, le comportement est pour le moins étrange : toutes les connexions n'apparaissent pas forcément, ou bien des connexions fermées depuis des heures sont toujours listées. Les connexions extérieures elles ne sont jamais affichées. Dans les journaux, les transferts de fichiers depuis l'extérieur (via filestation) sont bien listés, mais aucune connexion hors LAN. Ca m'ennuie assez déjà pour des raisons pratiques (savoir qui est connecté sur mon NAS, ou si la connexion est opérationnelle quand je donne des droits à des utilisateurs), ou par exemple pour tuer un upload en cours, si par exemple je veux jouer. J'en profite pour poser une autre question : existe t-il un paquet ou un script permettant d'avoir un résumé plus précis des échanges de fichiers (durée du transfert, vitesse moyenne, échec ou réussite du transfert etc...) ?

Je suis pas spécialiste en commande unix, mais je doute fortement que la commande suivante puisse passer /mnt/./cod4 . Dans la mesure ou tu passes le chemin absolu tu dois pas mettre ./ (ça c'est quand t’exécute un script ou un programme qui n'est pas défini dans le PATH et que t'es dans le dossier en question). enfin de toute façon "/dossier/./executable" ça fonctionnera pas en tout cas. Si /mnt/cod4_Inxded +set fs_game "mods/promodlive216" +exec server.cfg +map mp_shipment +set dedicated 2 (sans le ./ donc) ne fonctionne pas, essaye en mettant des guillemets. je ne sais pas comment est interprété la commande passée dans le gestionnaire de service chroot. Après le problème est de savoir si le gestionnaire chroot sous DSM autorise de passer des paramètres à une application. Après encore une fois, tu peux toujours tenter un truc : tu fais un script (start_cod4.sh par exemple), que tu mets dans /volume1/@appstore/debian-chroot/var/chroottarget/bin par exemple, avec dedans un truc tout con : #!/bin/sh cd /mnt ./cod4_Inxded +set fs_game "mods/promodlive216" +exec server.cfg +map mp_shipment +set dedicated 2 (dans l'absolu faudrait un test avant de lancer le serveur pour voir si celui ci est déjà lancé). Lances ce script sous putty une fois le chroot monté pour voir si déjà ça fonctionne. Puis (si c'est OK sous putty) dans le gestionnaire de chroot sous DSM tu passes la commande /bin/start_cod4.sh, et tu regardes ce que ça donne. Après faut créer un autre script pour arrêter le serveur (stop_cod4.sh), encore faut il trouver la commande qui te permet d'arrêter le serveur COD en cours d'utilisation. Ce script d'arrêt est indispensable. La commande "Arreter" de l'interface DSM n'arrêtera pas le serveur (il va essayer d'arrêter un script qui est juste là pour lancer une commande). PS : la solution du script à passer dans le gestionnaire de chroot sous DSM, merdait un peu chez moi, j'avais plusieurs instances (de x264 ou ffmpeg chez moi ) qui se lançaient en parallèle. C'est pour ça que j'ai adopté une autre solution. J'ignore si c'est récurent quand tu passes un script en paramètre ou si c'est un problème lié à ma config. Enfin tu le verras vite en regardant la consommation de la mémoire.

Ah oui en effet, ça ne risquait pas de fonctionner... Au fait, ton serveur COD dans mnt, il est monté depuis un autre répertoire (mount -o bind) ou les fichiers ont été directement copier vers le répertoire via winscp ? Dans le premier cas attention : quand tu exécuteras la commande, ton répertoire ne sera pas monté. Il faudra donc lancer ton appli via un script qui mount le répertoire en question puis ensuite qui lance la commande. Si c'est le second cas (enfin moi perso, dans /mnt j'aurais tendance à mettre que des répertoires/disques à monter mais bon..) évidemment tu ne devrais pas avoir ce problème.

Sous DSM dans le chroot, quand t'as rentré ta commande, tu as bien mis le chemin depuis le racine du chroot hein ? (/mnt) et pas le chemin depuis la racine du syno ( /volume1/@appstore/debian-chroot/var/chroottarget/mnt ) ? Sinon le problème étant que je ne sais pas si on peut rentrer directement ce type de commande dans le chroot manager : essaye de créer un script de lancement (un truc tout simple quoi...qui ouvre le répertoire /mnt et puis la commande du serveur). place ce script dans l'arborescence du chroot (/volume1/@appstore/debian-chroot/var/chroottarget/mnt), puis dans le chroot manager tu rentres la commande "/mnt/serveur.sh". Au moins tu pourras voir si c'est un problème de syntaxe de commande dans le chroot manager.

Et bien...Si on en croit ce topic : il y a eu en effet des problèmes de portage des paquets synocommunity pour ton NAS en particulier, mais d'après ce qui est dit, ce n'est plus d'actualité. A moins que certains spk (dont debian chroot) ne soient pas disponibles pour ton architecture. Mais là seul un responsable synocommunity (ils sont nombreux sur ce forum) pourrait te répondre.

Flo4428 => C'est peut être le "serveur.cfg" qui pose problème quand tu le passes en paramètre dans le chroot manager. Il arrive peut être pas à le trouver. T'as essayé de mettre le chemin du fichier dans tes paramètres de commande ? (testes avant sous putty pour voir si cod4_lnxded accepte que tu lui passe un chemin) metaneox => Le paquet en question s'appelle Debian chroot dans le gestionnaire de paquet (onglet "Communauté"). Quand tu rajoutes le dépot, tel que te l'a expliqué Flo4428, tu vois les autres paquets dans communauté ?

Bonsoir, Si tu passes /mnt/cod4_lnxded +exec server.cfg +map mp_shipment +set fs_game "mods/promodlive216" +set dedicated 2 en paramètre dans l'onglet service de chroot dans DSM ça fonctionne pas ? Ce n'est qu'une simple question hein. Je ne me sers pas de cet onglet, ça fonctionne, mais mal dans mon cas, j'utilise donc chroot différemment (j'ai un script qui jail une application et l’exécute dans le planificateur de taches de DSM, soit de façon programmée, soit en l’exécutant via le bouton adéquat. Enfin dans mon cas c'est de l'encodage vidéo, donc l'application se termine toute seule. Toi c'est pas ton cas...donc avec cette méthode à moins de créer 2 scripts, un qui démarre le serveur et un qui l’arrête, c'est pas envisageable).

Bonsoir, Effectivement, y a cette solution là aussi Enfin dans mon cas, le montage du répertoire dans le /mnt du chroot reste la solution la plus simple (puisque de toute façon dans un chroot on ne peut pas remonter plus haut que le répertoire racine). Et comme je bouge mes fichiers sous smb ou sous filestation, c'est ce qu'il y a de plus rapide. Peut être que dans le cas d'un serveur CoD, en effet, la solution winscp est la meilleure.

Salut, Une fois le chroot démarré ( /var/packages/debian-chroot/scripts/start-stop-status chroot ) il faut que tu lances ces commandes sous putty : aptitude install locales dpkg-reconfigure locales Ça devrait résoudre ton problème.

Je ne suis pas certain qu'il faille prendre le problème dans ce sens là. Je ne connais pas le fonctionnement d'un serveur CoD (je joue à un fps d'homme moi ), mais je suppose que le principe est commun à tous les autres : ton serveur va connecter des IP, non pas des utilisateurs. Créer des comptes DSM ne servira pas à grand chose. A la limite si tu veux faire un filtrage, c'est sur l'IP ou par zone : n'autoriser que les clients LAN à se connecter ou si c'est par internet, si tes amis ont tous une IP fixe, en créant des règles au niveau de ton routeur et/ou du parefeu du synology. Ou bien encore en mettant un password sur ton serveur à la connexion des clients. Pour TS ou mumble, même combat. Plus généralement, dans la mesure où tu ouvres une application sur l'extérieur, tu es forcément à la merci de failles éventuelles. Mais je ne suis pas spécialiste en la matière donc bon.