CoolRaoul
-
Compteur de contenus
5941 -
Inscription
-
Dernière visite
-
Jours gagnés
61
Messages posté(e)s par CoolRaoul
-
-
Cela m'amène à une autre question (désolé !!) : pourquoi créer ce dossier et toute cette arbo alors qu'on a /usr/local/ qui est "upgrade-ready" et qui me semble avoir été conçu pour précisément l'utilisation que tu fais de ton /volume1/site.
Est-ce "juste" pour éviter toute casse de busybox en cas de grave pépin et ainsi cerner les dégâts à la seule partition 'md2' soit /volumeX ?
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:
Despite the fact that the directory /var/packages or /usr/local is reserved for 3rd -party applications,storage space of system volume is limited. If the size of files to be installed exceeds the capacity of system volume, storage space will be run out.Consequently, it is recommended that you directly read or write application files in /var/packages/[package name]/target or other space of a data volume.You can also make a symbolic link in /usr/local point to /var/packages/[package name]/target or other space when running the postinst script. It makes the path easier to be accessed in a library or a daemon.Please note that you may need to specify the correct prefix when running a configure script, so that the application can find the correct path information upon execution.0 -
Oui, je voulais dire que je vais renvoyer vers le site de SIAB pour récup l'archive, et expliquer les commandes pour le compiler + donner un pti zip pour les fichiers à déposer afin d'avoir l'interface intégrée dans le DSM
En effet, c'est suffisant.
Faudra trouver la liste des packages Ipkg pre-requis pour la compile (en plus de gcc bien entendu)
0 -
J'avais commencé un tuto sur le sujet, mais pas finalisé car Nounours44 doit faire un autre outil du genre
Je vais voir pour proposer un mini tuto en attendant, non packagé, car je ne sais pas comment faire, mais avec les fichiers nécessaires au moins
C'est du binaire, faudra prévoir une version pour les différentes architectures.
0 -
Par contre, si je comprends l'esprit de tes symlinks, j'avoue ne pas avoir tout suivi concrètement :-s
Le dossier /volume1/@choses est le dossier réel ?
Oui
Où positionnes-tu le lien ? À la racine du syno ?
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).
Est-ce que l'on doit créer à la main la structure ou ça va se créer à la sortie de la compilation ?
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".
Si oui à tout cela, quelle est précisément l'arbo à mettre en place ? Tu parles de /bin ; /etc ; /var mais y-a-t-il autre chose ?
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...
Et pour être bien sûr, tout cela n'est nécessaire que des executables générés sur le syno lui-même, pas utile si l'on passe par spksrc qui crée un package en bonne et due forme. J'ai bon ?
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.
0 -
PS : Si tu veux pas que tes scripts de démarrage saute à la prochaine mise à jour, tu peux les placer dans /volume1/startup
/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"0 -
Mais est ce que mes modifs sont correctes? A quoi correspondait le $PATH dans mon PATH de /etc/profile? Est un rappel du PATH de /root/.profile?
Aucune idée
0 -
Tu as raison CoolRaoul, techniquement c'est faisable, mais c'est un enchainement de bricolage et ça ne correspond plus à ce que l'on recherche comme solution. Personnellement je fais déjà suffisamment d'administration réseaux et système au boulot, je veux une solution simple, un programme unique qui s'installe sur le syno et qui s'intègre au bureau virtuel.
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
0 -
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.
0 -
"Packages.gz has sprung into existence": on a déjà rencontré cette erreur.
Jette un oeil à ce fil:
0 -
toujours les mêmes erreurs.que ce soit pour rootkit scanner ou pour faire un ipkg update
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
0 -
Ouais, il faut une interface Web pour y accéder de partout en effet..
Acces ligne de commande dans une page web, ça existe:
0 -
(Petite parenthèse, le SPKSRC dispo sur github est une solution clé en main pour la compilation, Diaoul et Piwi pourrons expliquer tout çà bien mieux que moi, je ne suis que le porte parole
)Connaissais pas, ça a l'air pas mal du tout dis donc!
Tiens je donne lien puisque tu as oublié de le faire
0 -
J'ai rien contre la ligne de commande mais quand tu as des noms de dossier farfelu, la souris est largement plus pratique qu'écrire un nom de dossier + nom de fichier de 500 caractères...
C'était de l'humour hein ...
Cela dit utiliser dit la ligne de commande n'interdit pas le copier/coller
0 -
Rootkit scanner provient de http://package.10trum.de/
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 ?
0 -
<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!
0 -
J'ai voulu faire un ipkg update mais j'ai ça maintenant :
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
0 -
@CoolRaoul c'est pas "mieux" de supprimer les 4 lignes (avec dd) ?
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 ?
0 -
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
0 -
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
0 - créer un lien symbolique ("/site" pour moi) vers le répertoire des extensions perso (toujours chez moi exemple "/site" -> "/volume1/site")
-
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?
0 -
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).
0 -
Je suis désolé mais si on fait les choses proprement y'a rien besoin de linker dans /lib. Le rpath est la pour ça.
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 ?
0 -
Suis pas sur que DS audio n'utilise aussi webdav lui..
0 -
Je vais poser la question qui tue : est-il possible de combiner cela avec une redirection de port ?
tu veux dire
Redirect / https://<host>:<port>?
Et pourquoi ne pas simplement essayer?
0
Installation Ipkg Sur Ds212+
dans Installation, Démarrage et Configuration
Posté(e)
et que donnent les commandes suivantes?