StephWe

Cela a fonctionné. L'astuce et le programme est génial. Pour l'erreur, c'est surement un copié/collé qui a mal tourné Voici ce que j'ai trouvé via WinSCP Par la suite, j'ai renommé avant de supprimer et ça ne bug plus Un très grand merci pour ton aide. Passe une bonne soirée a+

Bonjour à tous, je vous explique mon problème. Après avoir installé Docker, j’ai installé l’image mongodb et un conteneur. Et cela a fonctionné toute la journée d’hier. Ce matin, j’ai essayé de localiser ou Docker sauvait les fichiers collection de mongodb. Et après plusieurs recherches sur le web, j’ai constaté que le dbpath était indispensable. J’ai inséré dans un conteneur dans une option un chemin vers un dossier. Mais cela n’a pas fonctionné. Par la suite, je ne sais via quelle ligne de commande ou autre (car j’ai fait plusieurs test en ssh), j’ai fait quelque chose qu’il ne fallait pas. Dès que je me connecte en ssh, et que je tape « ls -l / » dans le terminal, cela crée un gros bug qui n’est pas visible directement. Par contre, via le DSM, je n’ai plus de paquet installé dans le centre de paquet du DSM comme si je n’avais rien installé. Et par la suite, si je coupe ma connexion ssh et que j’ouvre une connexion via Putty, avant même de taper mon login, j’ai instantanément le message d’erreur « Network error : Software caused connection abort ». Après le redémarrage complet du Nas, les paquets sont à nouveaux disponibles et chaque programme fonctionne correctement. Mais si je me connecte en ssh et que je tape dans la console « ls -l », le problème revient. Voici un print screen du terminal avec le résultat de la commande ; de plus, il y a une chose étrange, il y a un deuxième dossier « var » avec un caractère bizarre à la fin. Quelqu'un a une idée du problème que je rencontre ?

Salut, j'ai fait les modif comme ceci : is_running() { PID=$(get_pid) ! [ -z "$(pidof node | grep "^$PID$")" ] && ! [ -z "$(netstat -lnt | egrep ".*:1337" | awk -F' ' '{print $6}' | grep "^LISTEN$")" ] } Je suis dans le bon ? J'ai testé la commande nohup et cela fonctionne temps que je ne quitte pas le terminal. Mais d'après ceci : Voici ce que j'ai tapé : nas> nohup /usr/local/etc/rc.d/s0001_manage-nodeJS.sh start & nas> nohup: appending output to nohup.out nas> exit Tu as une idée sur le fait qu'après avoir tapé exit, le processus s'arrête ? PS : le site http://www.christopher.compagnon.name est vraiment génial merci pour le lien.

J'ai été obligé de garder "-an" car "-l" prend trop de temps à charger dans la fonction is_running et le retour n'est jamais correct. Donc, j'ai réécrit la commande netstat et j'affiche uniquement le String (6ème colonne) si le résultat est égal à 'LISTEN' et si le port 1337 est ouvert dans la liste : nas> /usr/local/etc/rc.d/s0001_manage-nodeJS.sh stop Stopping node app ... Killing process 11291 Removing pid file Node app stopped nas> netstat -an | egrep ".*:1337" | awk -F' ' '{print $6}' | grep "^LISTEN$" nas> /usr/local/etc/rc.d/s0001_manage-nodeJS.sh start Starting node app ... Node app started with pid 12763 nas> netstat -an | egrep ".*:1337" | awk -F' ' '{print $6}' | grep "^LISTEN$" LISTEN nas> J'ai également réécrit la commande pidof et j'affiche uniquement le pid si il est égale au pid demandé dans le grep : nas> pidof node 12763 nas> pidof node | grep "12763" 12763 Donc, dans la fonction is_running (je n'ai pas oublié le not "!" au départ de la condition ) : Quand penses-tu ? is_running() { PID=$(get_pid) ! [ -z "$(pidof node | grep "^$PID$" && netstat -an | egrep ".*:1337" | awk -F' ' '{print $6}' | grep "^LISTEN$")" ] } J'ai rien trouvé qui pouvait me mettre sur la piste. Tu peux m'en dire plus ?

Salut , pour vérifié le statut, voici ce que j'ai fait en utilisant les commandes pitof et netstat : is_running() { PID=$(get_pid) [ -z "$(pidof node | awk '{print $2}' | grep "^$PID$" && netstat -an | egrep ".*:1337" | awk '{print $2}' | grep "^$PID$")" ] } Donc, lancé manuellement via la console cela donne : nas> /usr/local/etc/rc.d/s0001_manage-nodeJS.sh stop Stopping node app ... Killing process 17292 Removing pid file Node app stopped nas> /usr/local/etc/rc.d/s0001_manage-nodeJS.sh status Node app stopped nas> /usr/local/etc/rc.d/s0001_manage-nodeJS.sh start Starting node app ... Node app started with pid 17391 nas> /usr/local/etc/rc.d/s0001_manage-nodeJS.sh status Node app running with pid 17391 Penses-tu que la fonction is_running peut être optimisé ou c'est bon comme cela ? Également, pour les testes. J'ai lancé le daemon nodsJS manuellement et si je quitte la console, le serveur nodeJS ne fonctionne plus. Sais-tu comment faire pour lancer le daemon nodsJS manuellement et quitté la console sans que le serveur nodeJS soit hors-service ? Je voudrais une solution pour éviter de redémarrer le nas . Vu comme ça, en effet . Sur un premier temps, je relance le serveur comme prévu. Comme ça, cela me permet de créer mon premier cron Par la suite, une fois que j'ai créé l'appli web, je ferais comme tu m'as dit car évidement, je ne voudrais pas me retrouver dans une des situations que tu as cités.

Par contre je ne suis pas pour relancer un programme toutes les minutes s'il se plante, car s'il s'est planté, c'est surement pour une bonne raison, donc il faut mettre des limites (par exemple vérifier depuis combien de temps il est planté) La seule façon pour le serveur de planter est de ne pas initialiser une variable correctement, une erreur de syntaxe du code js ou (le pire), une lenteur dans l’exécution du script car même si le JavaScript est exécuté en lecture ligne par ligne (procédurale) la ligne 2 peut-être plus lente et la ligne 3 n'attend pas et le bug se produit (variable non initialé ou vide). Si le serveur nodeJS se plante, je le saurais coté client car la connexion au port sera fermé. Je m'enverrais un email directement et les clients auront un message avec un compte à rebours vers la reprise du serveur. Les clients connectés seront sauvés dans la db. Cette une sécurité que je met en place car le javascript est instable. Je sauve les données d'un array avec un json_encode (PHP) coté serveur qui devient un String dans un champ de la table et je recrée les array et object sans problème. Il faut impérativement que le serveur continue à tourner et que je règle le problème en parallèle.

Oui, en effet. J'ai une seule erreur sur mes testes, c'est quand je vérifie le statut : nas> /usr/local/etc/rc.d/s0001_manage-nodeJS.sh status ps: invalid option -- 'a' BusyBox v1.16.1 (2015-11-12 18:01:52 CST) multi-call binary. Usage: ps Report process status Options: w Wide output Cela vient du ps aux : is_running() { PID=$(get_pid) ! [ -z "$(ps aux | awk '{print $2}' | grep "^$PID$")" ] } Je crois que ps n'est pas utilisé dans cette version du Shell. Tu as une idée ? Je voudrais également ajouter dans cette vérification, si le port est ouvert.

En effet, je devrais peut-être créer un cron vers un autre script qui toutes les 60 sec., vérifie si le serveur nodeJS est lancé. Et donc, je préserve le script actuel tel qu'il est. Et je le relance dans le cas ou le serveur est hs. Tu as peut-être une autre idée (plus optimisé ou plus simple) pour créer le script qui surveille l'état du daemon nodeJS ?

Dans les commentaires, il annonce ceci : # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 Ce que je ne comprend pas, donc, comment sont initialisées les variables $1 et $2 à la ligne 136 et 150 J'imagine qu'à la ligne 33, il y a un genre un array ou object. Peux-tu m'expliquer cette ligne stp ?

Oui, en effet mais l'erreur ne vient pas de là et ni de la modification du script. J'avais redémarrer le serveur et par la suite, le navigateur m'affichait une erreur 404. Alors j'ai lancé manuellement par la console et j'ai fait une erreur La vrai erreur est que si le serveur (nas) redémarre, le fichier server.pid pose problème au démarrage du serveur nodeJS. A mon avis, le développeur a ajouté une condition inutile dans le script. J'ai regardé le script de plus prêt et à la ligne 83, la variable $FORCE_OP doit être égale à true alors qu'à la ligne 34, elle est initialisée à false par défaut. J'ai réglé le problème en initialisant la variable à true. Désolé pour le retour négatif .

Re : j'ai un message d'erreur à la ligne 13 nas> node /usr/local/etc/rc.d/s0001_manage-nodeJS.sh start /usr/local/etc/rc.d/s0001_manage-nodeJS.sh:13 NODE_EXEC=$(which node) ^^^^ SyntaxError: Unexpected identifier at exports.runInThisContext (vm.js:73:16) at Module._compile (module.js:443:25) at Object.Module._extensions..js (module.js:478:10) at Module.load (module.js:355:32) at Function.Module._load (module.js:310:12) at Function.Module.runMain (module.js:501:10) at startup (node.js:129:16) at node.js:814:3

Tu as raison, mon expression était mal placé. Elle s'utilise uniquement si l'on maîtrise le sujet (la syntaxe). Mais il y a plusieurs façons d’apprendre. Il est également possible de plonger la tête la première directement dans le code (C'est une expression qui convient le mieux pour ce que je veux expliquer ). A chaque fois que je rencontre un soucis inconnu, une définition très complète s'offre à moi avec d'autres choses en parallèles qui n'étaient pas forcement liés et qui m'ouvre l'esprit. De plus, j'ai gagné du temps dans l'optimisation de la syntaxe. La personne qui a développé ce script m'offre une vision plus large pour en créer d'autres Si je parle de cette façon, c'est parce-que je suis développeur et j'ai une logique qui me permet de réfléchir de cette façon. Enfin, je crois . J'ai fait la modification est cela a fonctionné. Je dois encore y compléter un plantage volontaire du serveur nodeJS et qu'il se relance automatiquement. Merci pour ton aide précieuse. J'avais pas vu ta dernière intervention. Je fais les modif.

Re : Merci CoolRaoul, en effet. Mais je ne savais pas que l'on pouvait pré-configurer les sauts de ligne pour Unix directement dans Notepas++. J'ai installé le packet nodeJS, et j'ai créé un script avec le contenu suivant pour le serveur nodeJS : var http = require('http'); http.createServer(function (req, res) { res.writeHead(200, {'Content-Type': 'text/plain'}); res.end('Hello World\n'); }).listen(1337, '192.168.1.250'); console.log('Server running at http://192.168.1.250:1337/'); Via la console, j'ai bien un retour positif : nas> node /volume1/web/nodeJS_server-xxx-xxx/server.js Server running at http://192.168.1.250:1337/ Via le port 1337 (http://192.168.1.250:1337) sur le navigateur j'ai également un retour positif : Hello World Jusqu'ici tout vas bien. Pour évité de réinventer la roue, j'ai fait quelques recherche sur un éventuel script pour gérer le lancement de nodeJS et j'ai trouvé ceci https://github.com/chovy/node-startup/blob/master/init.d/node-app. Donc, j'ai créé et copié/collé le contenu dans le fichier /usr/local/etc/rc.d/s0001_manage-nodeJS.sh et également créé les sous-dossiers et fichier /pid et /log/server.log. Il ne faut pas créer le fichier server.pid car il stop le script avec le message d'erreur suivant : nas> ./s0001_manage-nodeJS.sh start ps: invalid option -- 'a' BusyBox v1.16.1 (2015-11-12 18:01:52 CST) multi-call binary. Usage: ps Report process status Options: w Wide output Node app stopped, but pid file exists J'ai modifié les variables suivante dans le fichier /usr/local/etc/rc.d/s0001_manage-nodeJS.sh : #!/bin/sh USER="root" NODE_ENV="production" PORT="1337" APP_DIR="/volume1/web/nodeJS_server-xxx-xxx" NODE_APP="server.js" CONFIG_DIR="$APP_DIR" PID_DIR="$APP_DIR/pid" PID_FILE="$PID_DIR/server.pid" LOG_DIR="$APP_DIR/log" LOG_FILE="$LOG_DIR/server.log" NODE_EXEC=$(which node) ############### J'ai rendu le fichier exécutable : nas> cd /usr/local/etc/rc.d/ nas> chmod +x s0001_manage-nodeJS.sh nas> chmod 0755 s0001_manage-nodeJS.sh nas> ls -l s0001_manage-nodeJS.sh -rwxr-xr-x 1 root root 3278 Jan 2 15:54 /usr/local/etc/rc.d/s0001_manage-nodeJS.sh J'ai lancé le script manuellement pour vérifier si il fonctionne. Voici les erreurs que j'ai en retour : nas> ./s0001_manage-nodeJS.sh start Starting node app ... ./s0001_manage-nodeJS.sh: line 170: sudo: not found cat: can't open '/volume1/web/nodeJS_server-xxx-xxx/pid/server.pid': No such file or directory Node app started with pid Pourquoi ne trouve-t-il pas la commande sudo ?

En effet, je comprend mieux l'importance du PATH. Ce sont les répertoires dans lesquels le shell cherche la commande et la recherche se fait dans l'ordre des répertoires contenus dans la variable PATH. On peut également avoir depuis les sources une version plus récente de la commande dont l'exécutable se trouve dans un autre dossier. Alors il faut utiliser le chemin absolu et l'adjoindre au départ du PATH. Mais le PATH peut également inclure des répertoires dans les quels se trouve des fichiers à exécuter. Pour par exemple écrire un script qui sera exécuté via d'autres scripts (au boot, manuellement, en cron, etc ...) comme disait CoolRaoul. C'est génial merci pour toutes ces précisions.

Ton problème peut venir de plusieurs choses, l'erreur la plus courante c'est de créer son script sous Windows (il ajoute des caractères de contrôle afin d'être moins compatible avec le reste du monde mais de le rester avec DOS). Si tu es sous Windows, tu peux utiliser notepad++ en spécifiant bien le format d'encodage (UTF-8 sans BOM) Oui, je suis sous Windows mais j'avais bien utilisé Notepad++ et sauver en UTF-8 sans BOM. Dans le passé, un administrateur m'avait parlé que Windows générait sur la première ligne un caractère genre retour à la ligne qui ne plaisait pas à Linux :) Comme tu me l'as conseillé, j'ai utilisé vi pour générer un nouveau fichier et cela à fonctionné du premier coup :) Je peux même le rééditer et sauver avec Notepad++. Tout d'abord, si tu veux vraiment que ton script soit lancé à chaque démarrage de ton NAS et qu'il se soit pas supprimé à chauqe upgrade du NAS, il vaut mieux le mettre dans le répertoire suivant (si ma mémoire est bonne): "/usr/local/etc/rc.d/" et lui donner un nom de la forme "S99Monscript.sh" avec comme structure : Super, comme ça je vais dans la bonne direction et cela me fait une base de script pour démarrer Pour ma part, je préconise de *toujours* spécifier le PATH *dans* le script, au début En rapport avec le PATH, si on l'ajoute dans le fichier, c'est uniquement parce-qu'il est possible d'inclure le fichier dans un autre fichier comme en PHP avec : include 'fichier.php'; J'essai de comprendre l'utilité. Au départ, je croyais qu'il était utile de redéfinir le PATH. Comme ça, en ligne de commande, je ne devait plus retrouver le bon dossier (cd /) et également, si j'étais dans le bon dossier, ne plus taper "./" mais directement le nom du fichier depuis n'importe où dans la racine. Peux-tu m'en dire plus ?

Bonjour à tous, Pour commencer, je suis débutant ! Merci de le prendre en considération. Je doit créer un script qui sera exécuté automatiquement par le serveur dans le dossier /etc/init/le_script.sh Son objectif, lancer le serveur nodeJS au démarrage/redémarrage du nas et également, vérifier si le serveur nodeJS n'a pas planté sinon, le script relance nodeJS. Cette vérification devra être faite toute les 60 sec. Donc, j'ai lu plusieurs topic et tuto sur le langage Shell. J'ai également découvert qu'il y a plusieurs versions et chacune hérite de la plupart des fonctionnalités de son ancêtre (voir image ci-dessous). sh : Bourne Shell. L'ancêtre de tous les shells. bash : Bourne Again Shell. Une amélioration du Bourne Shell, disponible par défaut sous Linux et Mac OS X. ksh : Korn Shell. Un shell puissant assez présent sur les Unix propriétaires, mais aussi disponible en version libre, compatible avec bash. csh : C Shell. Un shell utilisant une syntaxe proche du langage C. tcsh : Tenex C Shell. Amélioration du C Shell. zsh : Z Shell. Shell assez récent reprenant les meilleures idées de bash, ksh et tcsh. J'exécute la commande suivante pour voir ma version : nas> echo $SHELL /bin/ash Donc ma version est la plus basic "sh". Par la suite, je crée un fichier pour un test dans le dossier /etc/init/essai.sh #!/bin/ash # List folder web ls -l /volume1/web/ Je rend le script exécutable : nas> cd /etc/init/ nas> chmod +x essai.sh nas> chmod 0755 essai.sh nas> ls -l essai.sh -rwxr-xr-x 1 root root 71 Jan 1 16:12 essai.sh Par la suite, je modifierais le PATH pour y adjoindre mon dossier avec mes scripts : export PATH=$PATH:/home/steph/mes_scripts J’exécute le script dans le répertoire courant et cela ne fonctionne pas : nas> ./essai.sh -ash: ./essai.sh: not found Si j'ai mis autant de détails c'est que j'ai plusieurs questions : Pourquoi le script essai.sh n'a pas fonctionné ? Je sais qu'il est possible d'installer un nouveau shell en tapant ceci : apt-get install ksh Mais je n'ai pas testé. Question : si j’exécute cette commande, le support Synology sera toujours fonctionnel ? Par la suite, j'ai testé cette commande pour vérifier si je peux changé de Shell : nas> chsh -ash: chsh: not found Pourquoi la commande chsh n'a pas fonctionné ? Merci d'avance pour tous ceux qui voudront bien m'aider

J'ai une petite astuce. Je vais utilisé quelques mots qui sont surement proscrits et qui alertera un sauveur inattentif au sujet Couille, proute, téton Voyons voir

Je ne penses pas que ma question est incomplète ! Y a t-il un bonne administrateur pour répondre à cette question ou je me suis trompé de forum ?

La solution évidente est un .htaccess dans le dossier /volume1/web/ Order deny,allow Deny from all Allow from site1.com Allow from site2.com Allow from site3.com Mais pour une raison qui m’échappe, cela ne fonctionne pas. Il y a uniquement les adresses IP qui sont acceptés. J'ai également fait le même teste sur mon serveur local (wamp) et pareil. J'ai regardé la doc et pour que cela fonctionne, ce module doit être actif dans la conf d'apache et c'est le cas : LoadModule authz_host_module modules/mod_authz_host.so Si quelqu'un a une idée, je suis tout ouïe PS : si je ne trouve pas de solution, je vais devoir faire cela en PHP sur l'index avec une expression booléenne qui teste le nom de domaine pour rediriger les domaines non acceptés vers la page 403; ce qui est dommage.

Bonjour, j’imagine que Deteklover a trouvé la solution J Je reviens sur le sujet car il est intéressant. J’ai moi-même utilisé la configuration du VH comme Mike913 sur mon nas Syno avec DSM 5.2. L'arborescence de web : volume1/web/ volume1/web/site1 volume1/web/site2 Liste des hôtes virtuels : Nom du sous-dossier : site1 Nom d’hôte : www.site1.com Protocole : HTTP Port : 80 Nom du sous-dossier : site2 Nom d’hôte : www.site2.com Protocole : HTTP Port : 80 Et le tout fonctionne parfaitement. Mais il y a plusieurs problèmes de sécurités. l'adresse IP de la BOX vu de l’extérieur à accès au dossier volume1/web/ et les sous-dossiers. Comment sécuriser cela ? j’ai un autre nom de domaine www.site3.com ou le VH n’est pas configuré. il a donc accès au dossier volume1/web/ par défaut. Et également aux sous-dossiers des deux autres sites volume1/web/site1 et volume1/web/site2 Comment sécuriser cela ? et jamais deux sans 3, au départ chez mon hébergeur, j’ai modifié les dns des 3 noms de domaine www.site1.com, www.site2.com et www.site3.com pour qu’ils pointent vers mon serveur nas. Ils ont accès au dossier par défaut volume1/web/. Il serait intéressant de bloquer par défaut tous les domaines qui pointent sur mon nas. Et de donnée une autorisation aux 3 domaines www.site1.com, www.site2.com et www.site3.com. Comment faire cela ?