CoolRaoul

et que donnent les commandes suivantes? ls -ld /volume1/@optware mount | grep /volume1

Non, c'est essentiellement parce que "/usr/local" se trouve dans la partition système sur laquelle la place est limitée. Et d'ailleurs dans la doc developpeurs de Synology dont j'ai donné le lien précédemment on trouve la remarque suivante:

En effet, c'est suffisant. Faudra trouver la liste des packages Ipkg pre-requis pour la compile (en plus de gcc bien entendu)

C'est du binaire, faudra prévoir une version pour les différentes architectures.

Oui Oui J'ai un lien /site -> /volume1/@site A recréér a chaque upgrade DSM (j'ai un script de startup qui m'évite ça). La stucture est créé lors du "make install" si necessaire. Mais dans le cas d'une compilation croisée (sur linux) ca se passera différement: le "prefix" spécifué lors du "configure" correspond au chemin sur la cible (syno) Mais, lors du "make install", on donne un "prefix" différent qui désigne, sur le serveur de compilation; la racine ou vont être déposés les fichiers constituant le "kit". Le "make" install va crééer les sous répertoires requis si necessaire. Mais j'utilise mon arbo "/site" plus particulièrement pour mes outils perso (surtout des scripts) C'est a toi de voir ce qui t'es necessaire, moi j'ai "bin", "etc", "var" par exemple... Absolument; ce que j'avis écrit sur mon lien /site était bien à prendre dans le contexte de ma phrase: "Toutefois, pour des usages perso, tu peux bien entendu continuer à compiler directement sur ton Syno" Notamment, la création de paquets SPK je ne m'y suis pas encore attaqué. Et même, la compil croisée je ne pratique que depuis deux semaines Faudra attendre de l'aide de plus spécialistes que moi sur ces parties.

/usr/local est "safe" aussi, j'ai entre-temps découvert dans le doc "Synology DiskStation Manager 3rd-Party Apps Developer Guide" de Synology ce qui suit: "When DSM is being upgraded, the directory /var/packages/[package name] and /usr/local will be backed up and restored automatically"

Aucune idée

J'ai dit ça parce que que tu semblais eventuellement envisager l'option MC ("garder la solution sous le coude") , bien que réticent à la contrainte d'acces en ligne de commande ("ça implique aussi d'avoir un accès telnet ou ssh") Et ce n'est pas forcément une solution aussi "shadok" que cela peut sembler à première vue. Shellinabox, une fois compilé, est un simple exécutable qu'il suffit de lancer au boot avec les bons arguments. Ajouter à ça quelques lignes de conf apache, un user unix avec shell=<chemin de midnight commander> et tu te retrouve avec un résultat dont le niveau "wife compliance" est relativement correct

Si le PATH construit dans /etc/profile est correct, inutile de le redéfinir dans /root/.profile (mettre en commentaire) La définition suivante marche bien pour moi: /opt/bin:/opt/sbin:/usr/syno/apache/bin:/usr/local/bin:/usr/local/sbin:/usr/syno/bin:/usr/syno/sbin:/bin:/sbin:/usr/bin:/usr/sbin[/CODE] Si tu veux met plutôt celle-la dans /etc/profile, et commente les lignes PATH (si il en reste) de /root/profile Attention aux futures mise a jour de firmware qui peuvent modifier tout ça. Sauvegarder ces deux fichiers est une bonne idée.

"Packages.gz has sprung into existence": on a déjà rencontré cette erreur. Jette un oeil à ce fil:

Pour le rootkit scanner je n'ai plus rien a te proposer (ne connaissant pas le produit). Par contre pour le ipkg update essaye de le lancer comme ceci ipkg -verbose-wget update[/CODE] et donnes-nous le résultat [EDIT] vérifie aussi que "/opt/bin" est *avant* "/usr/syno/bin" dans ton PATH lorsque tu exécute ipkg update [EDIT #2] ah non, apres test, pas important semble-t-il

Acces ligne de commande dans une page web, ça existe:

Connaissais pas, ça a l'air pas mal du tout dis donc! Tiens je donne lien puisque tu as oublié de le faire https://github.com/S...ommunity/spksrc

C'était de l'humour hein ... Cela dit utiliser dit la ligne de commande n'interdit pas le copier/coller

Essaie déja de rebooter, Sinon va falloir aller demander de l'aide à la source, sur http://www.synology-...s-3rd-party-app Tu parles allemand ?

<troll on> Les vrais hackers (*) n'ont pas besoin de GUI pour faire un malheureux ftp. Et d'ailleurs ils n'utilisent *jamais* la souris. "wget -r ftp://<host>/<rep>" et ça roule </troll> (*) pas dans le sens que les journalistes donnent à ce mot!

Oublie ipkg pour le moment et gardons le focus sur ton erreur "rootkit scanner" si tu veux bien (au passage pourrais-tu nous dire ou tu a récupéré cet outil?) . Je suis tres étonné de son message d'erreur Que donnent les commandes: which cut which egrep which sed which tr

Oui pour les 3 premieres mais pour la 4eme tu es sur de ne pas avoir besoin de l'ajout de /volume1/@appstore/java6/jre/bin au PATH ?

Bon; il y une couille dans "/etc/profile", sans doute suite à un copier/coller hasardeux sous vi: ~ ~ ~ ~PATH=$PATH:/volume1/@appstore/java6/jre/bin JAVA_HOME=/volume1/@appstore/java6/jre Commence par supprimer ces 4 caractères "~" (si tu utilise vi pour la modif déplace le curseur sur chacun des "~" et tape "x") et ça devrait aller déja mieux

Pour la création des paquets, il y a déja des membres "historiques" du forum qui ont une solide expérience (il sont tous dans la premiere page de la toplist). Notamment Bud77, Diaoul, PiwiLAbruti (que ceux que j'oublie me pardonnent) qui, entre autres choses, participent à l'administration du dépot de paquet "SynoCommunity" Dans tous les cas pour crééer des paquets SPK, il est préférable de procéder par cross-compilation sur un Linux quelconque à base architecture Intel (pas forcément 64 bits, une machine virtuelle est un bon choix). Il devient ainsi en plus possible de compiler pour des syno d'autre architecture que le tien. Pour cela Il faut télécharger et installer le toolchain sur ton serveur linux pour l'architecture cible que tu récupèrera ici: http://sourceforge.n....0 Tool Chains/ Ensuite tu va pouvoir compiler tes applis sur ton serveur Linux et les transférer ensuite sur le Syno pour exécution. Synology fournit une doc ("Synology DiskStation 3rd-Party Apps Integration Guide") qui détaille comment s'y prendre. Elle est disponible ici: http://www.synology....nt.php?lang=enu Toutefois, pour des usages perso, tu peux bien entendu continuer à compiler directement sur ton Syno Mais alors je ne peux que te conseiller , pour ne pas risquer de faire de dégats, c'est quand tu compile ces applis, de le faire comme je t'ai dis plus haut: à savoir te créer un répertoire dédié dans "/volume1" et le donner comme cible des commandes "configure" comme ceci: ./configure --prefix=<mon rep local perso>[/CODE] Ca te créera les binaires dans <mon rep local perso>/bin, les config dans <mon rep local perso>/etc, et ainsi de suite/ Ensuite tu peux soit ajouter <mon rep local perso>/bin à ton PATH ou bien faire des liens de <mon rep local perso>/<commande> dans /usr/local/bin. *PROTIP* Encore un peu plus propre, pour rendre tes packages plus facilement relogeables: créer un lien symbolique ("/site" pour moi) vers le répertoire des extensions perso (toujours chez moi exemple "/site" -> "/volume1/site") mettre ce dernier en "prefix" dans les commandes "./configure" ainsi tu pourra toujours déplacer la cible (de volume1 vers volume2 ou n'importe quoi d'autre), suffira juste de refaire le symlink

En étant connecté root effectue les commandes suivantes: set -x . /etc/profile et ensuite . ~/.profile[/code] et copie/colle les deux résultat ici met nous aussi une copie des fichiers "/etc/profile" et "/root/.profile" [EDIT] Oublié de demander: les erreurs "permission denied" que tu avais il y a quelques mois tu les as toujours ou c'est résolu?

Pour commencer, je te conseilles d'éviter au maximum d'installer des choses dans les répertoires système (/usr, /usr/syno/etc/ ...) A chaque upgrade de firmware tu prend le risque voir disparaitre tes ajouts. Et en plus il vaut mieux aussi de ne pas trop gaspiller l'espace dans le file system root. La seule exception est tout ce qui est situé sous "/usr/local" que Synology s'engage à sauvegarder et restaurer lors des upgrades (ceci est documenté). Par exemple, pour ma part je me suis fait un arborescence "/volume1/site" (avec sous répertoires bin, etc, var ... ), pointée par un lien symbolique "/site" ou je met mes petits trucs perso bien à l'abri. (Il aurait été peut-être préférable de choisir le chemin "/volume1/@site" pour éviter la création auto du partage "site" mais c'est pas si grave) Pour les scripts de startup/shutdown un bon endroit est "/usr/local/etc/rc.d": tous les scripts situés dans ce répertoire et dont le nom se termine par ".sh" sont automatiquement invoqués au démarrage (avec le parametre "start") et à l'arret (avec le parametre "stop") Et pour terminer, pour la crontab si il y a une chose à savoir, c'est celle-ci: le cron de DSM est tres pointilleux avec le format du fichier "/etc/crontab". Il est *impératif* que les champ minute, heure, jour du mois, mois, jour de semaine, compte et commande soit séparés *exclusivement* par des tabulations (pas d'espace donc, par contre le contenu du champ "command" lui est de format libre).

Le fait que, dans le cas d'un spk, l'utilisateur ait la liberté de choisir où installer le package peut rendre l'utilisation du rpath lors du link plus problématique: (A moins d'installer systématiquement les fichiers dont le path est en dur dans les binaires sur "/volume1" sans tenir compte de choix ci dessus) A ce propos quelle approche a-t-elle été choisie pour régler ce problème dans le package Python de SynoCommunity ?

Suis pas sur que DS audio n'utilise aussi webdav lui..

tu veux dire Redirect / https://<host>:<port>? Et pourquoi ne pas simplement essayer?