CoolRaoul

Voici: copier le script dans le répertoire de son choix (remplacer <répertoire> par le chemin du répertoire dans les commandes ci après) comme ceci /usr/syno/bin/wget -O <répertoire>/xml2epg.pl http://pastebin.com/raw.php?i=xj3s2MxY récupérer le fichier de config et l'installer à sa place par défaut avec les commandes suivantes mkdir -p /usr/local/etc /usr/syno/bin/wget -O /usr/local/etc/xml2epg.conf http://pastebin.com/raw.php?i=aDbPxBEQ [/code] exécuter le script (au moins une fois par semaine) comme ceci [CODE]perl <répertoire>/xml2epg.pl http://xmltv.dyndns.org/download/tnt_lite.zip[/code] Le mieux est d'utiliser la crontab pour automatiser le 3eme étape, si tu ne sais pas comment faire, cherche dans le forum, on trouve des tutos pour ça aussi.

Suffit de le copier ou tu veux, D'apres les retours que j'ai eu dans le ipkg n'est pas obligatoire (faut juste supporter quelques warnings intempestifs dans ce cas) Il suffit d'utiliser le perl natif de DSM pour lancer le script, comme ceci /usr/bin/perl <chemin du script> <parametres>[/CODE]

Avant de lire ton "EDIT" je le sentais bien aussi ton problème de reboot: garder une session ssh/putty active indique bien qu'en fait il n'y a pas eu de reboot (ou qu'il ne s'est pas encore terminé) Lorsque tu lance la commande de reboot en ligne de commande elle se détache pour faire son travail en tache de fond et tu n'est pas déconnecté de suite ce qui donne l'impression sur le moment que cela n'a pas fonctionné. TIP: la commande "uptime" te permet de savoir depuis combien de temps ton système est booté: root@fserv> uptime 08:41:49 up 2 days, 10:14, load average: 0.01, 0.05, 0.01 ____________^^^^^^^^^^^^^^ système démarré depuis 2 jours, 10 heures, 14 min par exemple ici

Bon me voila sec alors

Ne pouvant comme tu l'imagines reproduire le ph

Si tu veux mon avis, le mieux est d'installer le phpmyadmin original et se passer du package fourni par Synology. Et tu pourra le nommer comme tu le souhaites (c'est ce que j'ai fait) La procédure de mise à jour n'est franchement pas compliquée et tu pourra de cette façon toujours bénéficier si tu le souhaites de la toute dernière version sans attendre que Syno mette à jour sont dépot avec une nouvelle version du package Cela dit, si l'objectif du changement de nom n'est que pour des questions de sécurité, un simple .htaccess à la racine du répertoire de phpmyadmin peut peut-être faire l'affaire: order deny,allow deny from all allow from <host ou ip autorisé #1> allow from <host ou ip autorisé #2> etc ...

C'est la première fois que je vois ça, il n'y a en principe aucun rapport entre l'acces WEB à l'interface d'admin(https et/ou http) et l'installation du bootstrap optware/ipkg Aucune idée de ce qui ce passe la. Aucun acces même apres un reboot?

Je pense qu'en prenant dans la liste le bloc auquel l'IP dynamique que tu recois se trouve devrait suffire. (deux blocs en fait: un pour chacun des sites entre lesquels tu fait ton bacckup) Le pool d'addresses dans lequel ton fournisseur choisit les IP de ses clients d'une zone g

J'avais oubli

Et tu as essayé des trucs au hasard pour ça? J'ai l'impression que c'est ton install optware (ipkg) qui est un peu vérolée. Le mieux est de tout recommencer a partir de zero (install du bootstrap optware/ipkg) et surtout ne jamais tenter des trucs sans bien maitrriser pourquoi tu les fais. Donc, mon conseil: supprimer (ou renommer) "/volume1/@optware" et recommencer.

Oh, vraiment? http://kb.mediatempl...p (Mac OS X)#gs remplacer ssh example.com@s00000.gridserver.com par ssh root@<hostname syno>[/code] (je ne connais pas MacOS pour ma part)

Jusqu'ici tout va bien et ça devrait être suffisant d'ailleurs. Et qui t'a dis de faire ca ? Il y en a qui cherchent vraiment les problèmes...

Le firewall du syno accepte des ranges d'IP. suffit de ne laisser passer que le(s) bloc(s) d'addresse(s) dans laquelle ces IP dynamiques sont prises. Donc: Tu fais une (ou plusieurs) règles avec "action=autoriser", "ports=22", "ip-source=sous-réseau" et tu indiques les caractéristiques du range (address IP et masque) correspondant au bloc d'addresses (une règle par bloc si il y en a plusieurs) un autre règle, toujours en "autoriser sur le port 22", "ip-source=sous réseau" ou tu spécifie ton réseau local (ne pas se couper la branche sur laquelle on est assis) tu met ces règles en prioritaire (en haut dans la liste) et tu ajoute une règle en dessous, action=refuser, port=22, ip source=tous et voila

Je pense avoir récupéré la situation: Apres avoir tenté un mv /usr/syno/etc? /usr/syno/etcX (n'oublions pas que le "?" matche n'importe caractere unique) Je me suis aperçu que maintenant les inodes n'était plus les mêmes: root@fserv> ls -ldi /usr/syno/etc* 139588 drwxr-xr-x 33 root root 4096 2012-09-23 22:54 /usr/syno/etc 41302 drwxr-xr-x 18 root root 4096 2012-09-01 10:45 /usr/syno/etc.defaults 17045 drwxr-xr-x 4 root root 4096 2012-09-23 22:29 /usr/syno/etcX [/code] (139588 et 17045) donc a priori je n'ai plus de répertoire doublement linké Quand j'aurais le temps je ferai une vérification plus globale. PS: tout ça m'a permis de faire joujou avec la commande "debugfs" que je n'avais pas pratiqué jusqu'ici.

les grand esprits se rencontrent

Surtout pas malheureux!!! Tout ce qui est sous les deux répertoires ("etc" et ... l'autre) sont strictement les memes fichiers et répertoires. Le rm va tout casser! Fait bien comprendre qu'il s'agit ici d'un hardlink de répertoires, ce qui ne devrait jamais arriver (sauf pour les "." et les ".." bien entendu)

Tu peux déja utiliser le firewall du syno (ou celui de ton routeur) et autoriser ssh qu'a partir d'IPs *connues* (de toi s'entend)

M'arrive un truc étrange J'ai dans le répertoire /usr/syno une deuxième entrée de répertoire doublon de "etc" (avec le meme inode donc) avec un caractere étrange: root@fserv> cd /usr/syno root@fserv> /bin/ls -lid etc* 17045 drwxr-xr-x 3 root root 4096 Sep 11 16:36 etc 41302 drwxr-xr-x 18 root root 4096 Sep 1 10:45 etc.defaults 17045 drwxr-xr-x 3 root root 4096 Sep 11 16:36 etc\302 j'ai bien entendu essayé avec le unlink d'optware: root@fserv> unlink etc? unlink: cannot unlink `etc\302': Is a directory ainsi qu'avec "rm -d" (toujours optware) root@fserv> rm -d etc? rm: cannot remove `etc\302': Is a directory En fait il semble bien que l'appel systeme "unlink" échoue sur un répertroie meme en étant root (un petit programme C ad hoc me l'a démontré) Si quelqu'un avait une idée pour corriger ça de façon "chirurgicale" ça m'arrangerait bien

Je ne comprend pas pourquoi, dans le tuto que tu utilises, on demande de ne pas installer le mkvtoolnix officiel pour la raison foireuse "celui-ci n’a pas fonctionné pour moi (manque de dépendances)." étant donné qu'un des roles d'un gestionnaire de packages comme ipkg est d'assurer la résolution des dépendances! En outre, récupérer un package sur un site inconnu et ensuite forcer l'install en bidouillant le MD5, franchement j'ai des réticences. D'autant plus qu'il suffit de : root@fserv> ipkg install mkvtoolnix Installing mkvtoolnix (4.2.0-1) to root... Downloading http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/unstable/mkvtoolnix_4.2.0-1_arm.ipk Installing boost-regex (1_45_0-1) to root... Downloading http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/unstable/boost-regex_1_45_0-1_arm.ipk Installing libebml (1.0.0-1) to root... Downloading http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/unstable/libebml_1.0.0-1_arm.ipk Installing libmatroska (1.0.0-1) to root... Downloading http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/unstable/libmatroska_1.0.0-1_arm.ipk Installing lzo (2.03-1) to root... Downloading http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/unstable/lzo_2.03-1_arm.ipk Configuring boost-regex Configuring libebml Configuring libmatroska Configuring lzo Configuring mkvtoolnix Successfully terminated. et voila le mkvtoolnix "officiel" de optware installé. Ben c'est DSM, (et le mot distrib est un peu innaproprié puisqu'elle n'est pas distribué a proprement parler puisque reservé aux matériels Synology). et c'est basé sur un busybox PS: je persiste a croire que t'em***r comme on le constate pour installer mkvtoolnix sur don ds212 alors que ca existe sous Windows et MacOS et, qu'étant donné le rapport de perfs brutes en un PC moyen et ton NAS, ca tournera *beaucoup* plus vite, à moins que ce ne soit que pour le fun, je ne vois pas l'intéret.

Comme tu as du sans doute le deviner, la réponse (ou plutôt la solution) est donc; chmod a+rx /var/lib[/code] Maintenant faudrait quand même savoir comment des modes aussi fermés ("rwx------") ont bien pu arriver sur /var/lib et si par malchance d'autres répertoires systèmes n'ont pas également été modifiés dans l'opération.

ah tiens , bizarre, peut-être une limite de VideoStation à 7 jours De toutes façon, le produit est encore jeune, faut bien accepter quelques dysfonctionnements.

voila autre chose, Ou et à quel moment apparaît ce message?