This site uses cookies! Learn More

Ce site utilise des cookies !

En continuant à utiliser ce site, vous vous engagez à nous permettre de stocker des cookies sur votre ordinateur.

 

Si nous utilisons des cookies et retenons des données anonymes, c’est pour nous aider à mieux gérer notre mesure d’audience, aider nos partenaires commerciaux à nous rémunérer et nos partenaires publicitaires à proposer des annonces qui vous correspondent.

 

Grâce à ces cookies, le forum est en mesure de savoir qui écrit un message et utile pour le système d'authentification.

 

En cliquant sur « J'accepte », vous acceptez l'utilisation par NAS-Forum de cookies publicitaires et de mesure d'audience fine.

StephWe

Membres
  • Compteur de contenus

    38
  • Inscription

  • Dernière visite

À propos de StephWe

  • Rang
    Initié
  • Date de naissance 06/12/1976

Profile Information

  • Gender
    Male

Visiteurs récents du profil

647 visualisations du profil
  1. Bonjour Zeus merci pour ton retour 🙂 J'ai installé via Docker, l'image 1and1internet-ubuntu-16-apache-php-7.22 Je me suis logué en root et j'ai créer le dossier var/www/ et fait un chmod 777 -R /www Pour finir, j'ai lancé le conteneur (Tout cela avec succès) Mais je ne parviens pas à joindre le dossier root via mon navigateur : http://192.168.1.xx:8443 Il y a peut-etre une manipulation que j'ai omis. Ou une autre image à tester (celle installé est un pur hasard) ! Tu as une image à me proposer ou une solution pour joindre le root via mon navigateur ?
  2. Bonjour à tous, Avec la version de Symfony 4.x, j'ai besoin que PHP 7.2 soit installé sur le Nas. D'après le support Synology, cette version du serveur PHP sera pris en charge sur le DSM 7 combiné au WebStation 3.0. (Je suis sur la version DSM 6.1) D'après le support, une installation manuelle du serveur PHP serait possible ! Quelqu'un a déjà résolut cette installation ou trouver un dépôts de packages avec PHP .7.2 ?
  3. 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+
  4. 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 ?
  5. 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.
  6. 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 ?
  7. 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.
  8. 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.
  9. 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.
  10. 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 ?
  11. 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 ?
  12. 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 .
  13. 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
  14. 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.
  15. 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 ?