CoolRaoul

Les droits d’accès via l'application photostation en http sont complètement indépendants des droits du partage "photo" (je sais, au premier abord, ça surprend) J'en ai parlé ici: Donc tu peux restreindre les droits du partage "photo" en les mettant aussi restrictifs que tu veux (uniquement "admin" si tu le souhaite) et pourra toujours gérer séparément les acces pour les utilisateurs utilisant photostation.

Ben c'est expliqué dans le (paragraphe "Notes au sujet du fichier "xml2epg.conf")

moi aussi Si on n'utilise pas l'infra SPKSRC jusqu'au bout (génération du spk) faut d'abord rassembler les libraries dépendantes (je suppose dans ../gnutls/work-88f6281/install/, etc ...) et ensuite soit les mettre dans le bon répertoire à l'arrivée soit passer par un LD_LIBRARY_PATH. J'ai eu la flemme... Tant qu'a faire "crade", j'ai utilisé mes petits scripts perso qui, sur mon nas, mettent tout dans /site/(local|bin|lib|etc...) (/site est un "mount -bind" vers un répertoire de /volume1, "à la optware"), je génère un .tar avec des chemins relatifs que j'extrait sur mon syno) et ainsi je mutualise les .so à l'arrivée C'est pas tres industriel (c'est pourquoi je garde mes scripts pour moi) mais ça fonctionne .

A la lecture de ce fil je me pose une question: pourquoi est-t-il si difficile (en tout cas je n'y suis pas parvenu) en partant de la page "produits" du site officiel Synology de savoir quel CPU

Ah non, j'ai pas eu le temps Justepus compiler un wget fonctionnel pour mon archi avec mes propres scripts, mais faire un spk me faudra prendre un peu de temps

Dans ce cas suffit de désactiver/réactiver les fonctions correspondantes dans l'interface DSM et les lignes seront automatiquement régénérées.

et surtout (le cron DSM est tres sensible à ça) attention de séparer les champs par des tabulations et pas par des espaces!

Par principe tous les crontabs sont différents en fonction des sauvegardes programmées, des jobs timebackup, etc

Tu n'as pas de PC ? ***EDIT*** PS: Je dit ca parce que je suis toujours étonné du nombre de gens qui se compliquent la vie a vouloir absolument faire tourner sur de petits NAS des applications qui sont déjà disponible pour leur PC (Windows et/ou Linux) ou Mac et fonctionneront forcément bien plus lentement vu le ratio de puissance et de mémoire entre un PC de base et un NAS entrée ou milieu de gamme.

Tu es au courant qu'il n'y a pas de sortie video sur un syno? Donc quoi que l'on puisse trouver, ça ne peut être *équivalent*

Mon script ne génère rien: il ne fait que *convertir* le détail des programmes contenus dans le fichier xml qu'on lui donne en paramètre (ou celui contenu dans le .zip) dans le format (les fichiers epg.nnn) utilisé par Videostation. Tu peux d'ailleurs consulter le contenu du fichier xml avec n'importe quel éditeur. La liste des chaines est en début de ce dernier. Les programmes dont tu as pu constater la présence ont donc forcément étés générés par Videostation lui-même (plus exactement par l'outil "synodvbepg") à partir du contenu du flux TNT (le script ne supprime pas les fichiers epg déja présents dans le dossier EPG)

Je réalise un truc tout a coup: Tu a écris Il est normal que pour les chaines ajoutées, les programmes restent vident dans VideoStation, si ces chaïnes ne sont pas présentent dans le tnt_lite.zip! Mon script ne peut pas inventer les programmes de chaines qui ne sont pas dans le source xmltv!

Faut quand même bien inclure les librairies dont dépend wget dans le spk non? Sinon j'ai un doute pour que wget fonctionne a l'arrivée Voici ma liste de plist apres le make: work-88f6281/gmp.plist work-88f6281/gnutls.plist work-88f6281/nettle.plist work-88f6281/wget.plist A moins de faire un spk supplémentaire pour chaque librairie (gmp, gnutls, nettle), et les installer tous les 4?

Je vois mais au départ je cherchais un fichier nommé "PLIST" alors que ce sont bien des "*.plist" (plusieurs si il y a des dépendances: wget.plist, gnutls.plist, etc ... ...) qui sont générés On construit donc le "PLIST" final a partir d'eux (en élaguant ce qui n'est pas forcément indispensable comme les docs par exemple)

En effet, j'ai (encore) un peu merdé dans mon explication En fait, comme tu viens de nous dire que tu pouvais accéder a ton site distant en ssh, tu n'as plus besoin d'utiliser wget puisque rsync répond a ton besoin. Et comme rsync est natif sous DSM tu n'as pas besoin d'installer (à fortiori de compiler) quoi que ce soit pour faire ton miroir.

Ce que je voulais dire est que le bug de ssh ne s'applique que dans le cas ou le site distant est un site ftp Par conséquent, si tu dispose d'un acces ssh sur ton site, tu devrais pouvoir arriver à faire ton mirroir avec le wget natif de DSM sans rien d'installer de plus.

(Je m'auto-quote) Toujours dans mon répertoire wget j'ai fait comme cela pour générer le PLIST find . -name '*.plist' | xargs cat | egrep -v "^(include|share/(man|info))" > PLIST[/CODE] [i]Copy a standard SPK directory like spksrc/spk/transmission in your new SPK directory spksrc/spk/newspk[/i] [i]Edit the stuff to fit your needs[/i] Damned, je suis un peu perdu la... Une question (parmi les dizaines qui me viennent) : A quoi servent les PLIST dans les répertoires "spksrc/spk/*", ils sont *tous* vides? Découragé je suis

Bon, voici ou j'en suis [*]j'ai mis le "depends" propre: DEPENDS = cross/gnutls[/CODE] [*]vir

Par curiosité j'ai tenté le coup pour mon archi (88f6281) Voici mon Makefile: PKG_NAME = wget PKG_VERS = 1.14 PKG_EXT = tar.xz PKG_DIST_NAME = $(PKG_NAME)-$(PKG_VERS).$(PKG_EXT) PKG_DIST_SITE = http://ftp.igh.cnrs.fr/pub/gnu/wget/ PKG_DIR = $(PKG_NAME)-$(PKG_VERS) DEPENDS = cross/openssl cross/gnutls HOMEPAGE = http://www.gnu.org/software/wget COMMENT = free software package for retrieving files using HTTP, HTTPS and FTP, the most widely-used Internet protocols. It is a non-interactive commandline tool, so it may easily be called from scripts, cron jobs, terminals without X-Windows support, etc. LICENSE = GPL GNU_CONFIGURE = 1 CONFIGURE_ARGS = --prefix=/site include ../../mk/spksrc.cross-cc.mk et le "make" plante comme ceci: configure: error: --with-ssl was given, but GNUTLS is not available. make: *** [configure_target] Error 1 ***EDIT*** Peut-être une piste: je pensais que les dépendances étaient résolues automatiquement mais il semble bien que $ cd ../gnutls/ $ make ARCH=88f6281 soit necessaire C'est ça?

Et pourtant il me semblait avoir été clair dans ma réponse: "L'option "optware" n'est, malheureusement pour toi, pas (encore?) disponible pour ton modèle de CPU." Ce que décrit ce tuto c'est tout simplement du rsync sur ssh Et donc ça ne s'applique pas dans le cas ou le site distant est accessible uniquement en ftp (ou http). Et vu l'erreur que tu nous a décrit dans ton premier message du fil, c'est en ftp que tu rencontre le bug non?

Oups, je viens de m'apercevoir de quelques conneries dans ce que je viens d'écrire: j'ai confondu "wget" et "rsync" Donc la partie sur la version spéciale de wget avec les extension ACL est fausse (cela s'applique à rsync) Mais le reste reste OK et j'ai lu le lien détaillant le problème sur wget entre temps aussi. Pas sur que le support Syno soit utile dans ce cas...