Installation GeoNature-citizen
geobrun opened this issue · 54 comments
Bonjour tout le monde,
Je souhaite procéder à l'installation de GeoNature-citizen 0.99.4-dev sur un serveur Debian 11 où sont déjà installés GeoNature 2.12.2 et TaxHub 1.11.1.
D'après ce que j'ai compris, étant donné que TaxHub est déjà installé, je dois procéder à une installation manuelle. J'en suis actuellement au téléchargement du référentiel des géométries communales. Pour cela, je dois télécharger des fichiers SQL qui se trouvent normalement dans le répertoire suivant : https://github.com/PnX-SI/GeoNature/raw/master/data/core
Or, on dirait que ce répertoire n'existe plus dans les dernières versions de GeoNature. Quelqu'un sait si son contenu a été rebasculé dans un autre répertoire ?
Bonne journée
Bonjour,
Le référentiel des géométries communales n'est plus nécessaire car Citizen utilise l'api Nominatim (https://nominatim.openstreetmap.org) pour récupérer les informations sur les villes.
La documentation n'est malheureusement pas à jour.
Si je ne dis pas de bêtises, normalement lancer le script suivant : https://github.com/PnX-SI/GeoNature-citizen/blob/master/install/install_app.sh devrait suffire puisqu'il s'occupe de créer la base de données, créer le rôle postgres, d'installer le backend, le frontend et la configuration apache.
En espérant que cela fonctionne pour vous
Ok, merci pour l'information ! Par contre, si j'utilise le script "install_app" (je ne l'ai pas regardé), je ne risque pas d'écraser mon Taxhub actuel ?
Non, si la variable install_taxhub est bien à false dans le fichier config/settings.ini, alors cela n'impactera pas votre installation de TaxHub.
GeoNature-citizen/install/install_app.sh
Lines 106 to 109 in ccc23c0
Quoiqu'il en soit, il est toujours préférable d'effectuer une sauvegarde préalable ;).
Ok, merci pour l'information @lpofredc ! De mon côté, j'avais seulement renseigné le fichier config.toml, pas le fichier settings.ini. Je vais tester ta solution. Il faut forcément renseigner les deux fichiers je suppose ?
Pas de souci pour les sauvegardes ! ;)
Pour une installation nouvelle, il suffit d'éxécuter le fichier install_app.sh. Ce script se chargera de créer les fichiers de configuration settings.ini (en lançant ./install/check_settings.sh) et le fichier config.toml (via le script ./install/copy_config.sh)
Mon premier essai est un échec : l'URL que j'ai paramétré débouche sur une erreur 503. J'ai remarqué qu'aucun schéma du genre gnc_core n'a été créé. Petite question toute bête : est-ce que ces schémas GeoNature-citizen doivent être créés dans ma BDD GeoNature classique ou est-ce qu'ils doivent être créés dans une nouvelle BDD, avec un nouvel utilisateur PostGreSQL ?
GeoNature-citizen est conçu pour être indépendant de GeoNature avec sa propre BDD et fonctionne sans GeoNature.
Si tu veux l'intégrer dans une BDD existante (GeoNature ou autre), il faut peut-être adapter les scripts.
Ok, merci @camillemonchicourt.
Donc si j'ai bien compris, dans le fichier settings.ini, j'indique le chemin de ma BDD GeoNature pour faire le lien avec mon Taxhub. Puis au cours de l'installation, lorsqu'une fenêtre me demande de nouveau des identifiants de BDD, je renseigne des informations pour la création de la nouvelle base de données. A moins que ce ne soit l'inverse ?
Bon, tout ce que j'ai testé s'est soldé par un échec. Et même pire : une de mes installations a même plus ou moins écrasé mon Usershub et Taxhub précédemment installé ! J'ai réussi à restaurer Usershub mais je butte sur Taxhub. J'ai actuellement deux Taxhub installés : un sur ma BDD geonature2db classique et un autre sur ma nouvelle BDD geonature2citizen. Après réinstallation, Taxhub fonctionne bien, mais il continue à pointer sur ma nouvelle BDD et non sur l'ancienne. J'ai regardé dans les paramètres : je ne trouve pas l'endroit où c'est sûrement indiqué de pointer la nouvelle BDD... Quelqu'un a une idée du paramètre qu'il faudrait que je modifie pour refaire pointer Taxhub sur la bonne BDD ? Sinon je ferai une restauration.
Au PNE on ne connaît pas/maîtrise pas l'installation de GeoNature-citizen qu'on n'utilise pas.
Et je ne suis pas certain que d'autres avant toi aient déployé GeoNature-citizen sur le même serveur que GeoNature.
Pour TaxHub, sa BDD est définie dans son fichier de configuration.
Ok, c'est bon, Taxhub est bien reparti. Je devais être un peu fatigué hier soir car j'étais passé à côté du paramètre qui avait été modifié par erreur dans le fichier apptax/config.py.
Merci pour l'info @camillemonchicourt. C'est sûr que ce n'est pas évident de s'y retrouver entre la documentation qui semble partiellement obsolète et le fait que la dernière version date d'il y a maintenant presque un et demi. Du coup, je vais voir pour passer le script install/install_app.sh petit à petit afin de déterminer ce qui cloche dans l'installation.
Pour commencer, voilà ce que j'ai compris de Citizen :
- Il y a un dossier
gncitizendans lequel se trouve la configuration de l'application - Il y a une BDD dédiée dans laquelle doivent être créés des schémas spécifiques Citizen
- Il y a une connexion à ma BDD GeoNature pour accéder au schéma
ref_geo - Il y a une connexion à mes Taxhub et Usershub via leur API (ou directement via la BDD ?)
Est-ce que quelqu'un peut me dire si je me trompe sur un point ? :)
Pour l'instant, voilà les deux points sur lesquels j'ai bloqué :
- Je n'ai jamais réussi à créer les schémas spécifiques à Citizen dans la BDD dédiée
- Après l'installation, je me retrouve avec une erreur 503 comme s'il y avait un problème de configuration du supervisor/apache (j'ai l'impression que Citizen et GeoNature n'ont pas le même fonctionnement sur ce point)
Suite et fin (a priori) de mes problèmes d'installation !
D'abord, je me suis rendu compte que j'étais en train d'installer la version 0.99.4-dev de Citizen alors qu'il existe une version 1.0.0. C'est seulement qu'elle n'est pas indiquée dans la partie "release" du dépôt. Du coup, je suis reparti de cette version 1.0.0.
Pour information, avec cette release, j'ai buté sur deux petits soucis.
Premier problème, la commande sudo apt -y install python-dev me renvoyait cette erreur :
Certains paquets ne peuvent être installés. Ceci peut signifier
que vous avez demandé l'impossible, ou bien, si vous utilisez
la distribution unstable, que certains paquets n'ont pas encore
été créés ou ne sont pas sortis d'Incoming.
L'information suivante devrait vous aider à résoudre la situation :
Les paquets suivants contiennent des dépendances non satisfaites :
libpython2.7-minimal : Casse: python (< 2.7.18)
Casse: python-dev (< 2.7.18)
Casse: python-minimal (< 2.7.18) mais 2.7.13-2 devra être installé
libpython2.7-stdlib : Casse: python (< 2.7.18)
Casse: python-dev (< 2.7.18)
Casse: python-minimal (< 2.7.18) mais 2.7.13-2 devra être installé
python : Dépend: libpython-stdlib (= 2.7.13-2) mais il n'est pas installable
python-dev : Dépend: libpython-dev (= 2.7.13-2) mais il n'est pas installable
python2 : Casse: python (< 2.7.15-2)
python2-minimal : Casse: python-minimal (< 2.7.15-2) mais 2.7.13-2 devra être installé
python2.7 : Casse: python (< 2.7.18)
Casse: python-dev (< 2.7.18)
Casse: python-minimal (< 2.7.18) mais 2.7.13-2 devra être installé
python2.7-minimal : Casse: python (< 2.7.18)
Casse: python-dev (< 2.7.18)
Casse: python-minimal (< 2.7.18) mais 2.7.13-2 devra être installé
python3-six : Casse: python (< 2.7.18)
Casse: python-minimal (< 2.7.18) mais 2.7.13-2 devra être installé
python3-yaml : Casse: python (< 2.7.18)
Casse: python-minimal (< 2.7.18) mais 2.7.13-2 devra être installé
E: Erreur, pkgProblem::Resolve a généré des ruptures, ce qui a pu être causé par les paquets devant être gardés en l'état.
Je ne sais pas si elle est importante mais mon installation a l'air de fonctionner correctement malgré tout. Par contre, cette erreur empêchait l'installation d'autres paquets, et notamment de supervisor (d'où l'erreur 503 que j'avais depuis hier).
Second problème, dans le fichier install/install_app.sh, la ligne python3 -m virtualenv $venv_path débouchait sur l'erreur suivante :
ModuleNotFoundError: No module named 'virtualenv.activation.xonsh'
J'avais déjà rencontré ce type d'erreur par le passé avec GeoNature : j'ai remplacé cette commande par la suivante python3 -m venv $venv_path.
Après ça, pas de souci : les schémas de Citizen sont bien installés dans la BDD dédiée, le lien avec l'API de Taxhub semble opérationnel, et les frontend et backend fonctionnent !
Et merci pour votre aide bien sûr ! :)
Tant mieux si tu t'en es sorti.
Il faudrait finaliser/stabiliser une installation fonctionnelle et documentée.
Je ne vois pas où tu as trouvée une version 1.0.0 ?
Je l'ai téléchargée directement depuis la page d'accueil du dépôt : onglet vert "Code", puis "Download ZIP".
Ah OK, tu as pris la branche master dans laquelle une version 1.0.0 est en préparation, mais pas encore officielle (ni finie ?) car pas dans les releases.
C'est ça !
Je réouvre car les sujets mentionnés ici ne sont pas réglés, tant que la 1.0.0 n'est pas sortie.
Il y a aussi pas mal de corrections/améliorations qui sont seulement présents dans la branche dev, potentiellement la plus à jour et fonctionnelle ? https://github.com/PnX-SI/GeoNature-citizen/compare/dev
A voir avec @lpofredc si il en sait plus.
J'ai créé une PR pour résoudre le problème de venv que j'ai mentionné plus haut (355).
Par contre, je ne sais pas comment résoudre le premier problème que j'ai rencontré avec la commande sudo apt -y install python-dev.
Ok, c'est bon, Taxhub est bien reparti. Je devais être un peu fatigué hier soir car j'étais passé à côté du paramètre qui avait été modifié par erreur dans le fichier
apptax/config.py.
Bonjour,
Je me suis lancée dans l'installation de citizen 0.99.4-dev sur un serveur ayant déjà une install de GeoNature, Taxhub, Usershub et Atlas. J'ai mal interprété les items dans le fichier de config settings.ini, du coup je n'ai pas renseigné ce qu'il fallait, et je me retrouve dans une situation simiaire à celle que vous avez rencontrée ..
La plupart des applis marchent, sauf citizen, mais je rencontre des bugs, sûrement du au fait que mon install de Taxhub a été modifiée ..
Qu'est ce que vous avez du modifier dans le fichier apptax/config.py ?
Savez-vous comment je peux supprimer l'installation de citizen proprement ?
Merci !
Bonjour,
Il me semble que c'était le paramètre SQLALCHEMY_DATABASE_URI qui avait été modifié. Il faut le faire repointer sur ta BDD GeoNature. Et ensuite redémarrer tous les services de mémoire.
Le paramètre SQLALCHEMY_DATABASE_URI pointe toujours sur la BDD GeoNature ..
Et aucune BDD n'a été créée pour citizen, ce qui est sans doute logique vu que dans la section Configuration PostgreSQL du fichier config/settings.ini, j'ai spécifié les paramètres de ma BDD GeoNature existante .. Qu'as-tu spécifié dans cette section ?
Bon finalement les applis ont l'air d'aller mieux (??), je vais supprimer le dossier gncitizen et retenter une install sans taxhub et avec les bons paramètres de config ?
Dans cette section, j'ai renseigné un nouveau nom de BDD et un nouveau nom d'utilisateur (pas sûr que ce soit utile pour ce dernier).
Je te conseille de repartir de la version 1.0.0 car j'ai rencontré pas mal de souci avec la version 0.99.4-dev !
OK merci !
Oui attention, la dernière version officielle est la 0.99.4-dev, mais depuis il y a eu beaucoup de corrections et évolutions, en vue de sortir une 1.0.0. Celle-ci n'est pas finalisée et sortie, mais le code est dans la branche MASTER - v0.99.4-dev...master
Et à priori, au regard des différents retours, elle corrige différents soucis de la version 0.99.4-dev.
Il faut qu'on trouve du temps ou de l'argent pour finaliser et sortir cette version 1.0.0...
OK, j'ai installé la version de la branche master.
J'ai du modifier le fichier install/install_app.sh comme expliqué ici :
Second problème, dans le fichier install/install_app.sh, la ligne python3 -m virtualenv $venv_path débouchait sur l'erreur suivante :
ModuleNotFoundError: No module named 'virtualenv.activation.xonsh'
J'avais déjà rencontré ce type d'erreur par le passé avec GeoNature : j'ai remplacé cette commande par la suivante python3 -m venv $venv_path.
La BDD est bien créée, je n'ai aucun message d'erreur.
Mais j'ai une erreur 404 sur toutes les URL de l'application Citizen.
Dans le fichier settings, j'ai mis :
my_url = http://geonature.oreme.org/gncitizen/
url_application = http://geonature.oreme.org/gncitizen/
api_endpoint = http://geonature.oreme.org/gncitizen/api
api_taxhub = http://geonature.oreme.org/taxhub/api
Pourtant, à la fin de l'install, j'ai un message pour le backoffice avec une mauvaise URL pour l'API (cette URL ne marche pas non plus ) :
Backoffice access informations are stored in /home/geonatureadmin/gncitizen/config/backoffice_access as follows:
Backoffice password
===================
url: (geonature.oreme.org/api/admin)
J'ai modifié le fichier de conf /etc/apache2/sites-available/gncitizen.conf pour ajouter le segment manquant /gncitizen :
<VirtualHost *:80>
# Host
ServerName geonature.oreme.org
# Root url (for frontend)
<Location /gncitizen>
ProxyPass http://localhost:4000/ retry=0
ProxyPassReverse http://localhost:4000/
</Location>
# API Url
<Location /gncitizen/api>
ProxyPass http://localhost:5002/gncitizen/api retry=0
ProxyPassReverse http://localhost:5002/gncitizen/api
</Location>
# Secured backoffice
<Location /gncitizen/api/admin/>
AuthType Basic
AuthName "Restricted Area"
AuthBasicProvider file
AuthUserFile "/home/geonatureadmin/gncitizen/config/backoffice_htpasswd"
Require user citizen
</Location>
# Error logs
ErrorLog /home/geonatureadmin/gncitizen/var/log/apache2-citizen.log
CustomLog /home/geonatureadmin/gncitizen/var/log/apache2-citizen.log combined
</VirtualHost>
Mais ça n'a rien changé.
Et je n'ai rien dans aucun fichier de log ....
A priori, ton fichier de configuration a l'air bon. Tu as bien lancé les commandes sudo a2ensite citizen.conf et sudo service apache2 restart pour le prendre en compte ?
Tu as essayé de redémarré les services ou le serveur ? Ca m'a souvent dépanné par le passé quand des URL n'étaient plus accessibles.
Oui j'ai bien suivi les 2 commandes apache .. Et après un reboot de la VM c'est pas mieux ...
Bonjour,
Une petite idée : as-tu essayé la commande sudo apache2ctl -S, elle permet de lister notamment tous les virtualhost. Pour bien voir si Apache a bien pris en compte cette configuration de citizen.
J'ai l'impression que le problème vient bien d'Apache.
Après, tu peux tester si tu peux accéder à http://localhost:4000 depuis le serveur en utilisant wget, pour voir si le front répond.
Je cherche si j'ai d'autres idées...
Merci, a priori tout semble OK :
$ sudo apache2ctl -S
VirtualHost configuration:
*:80 is a NameVirtualHost
default server geonature.oreme.org (/etc/apache2/sites-enabled/geonature.conf:1)
port 80 namevhost geonature.oreme.org (/etc/apache2/sites-enabled/geonature.conf:1)
port 80 namevhost geonature.oreme.org (/etc/apache2/sites-enabled/gncitizen.conf:1)
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/var/log/apache2/error.log"
...
$ wget http://localhost:4000
--2023-05-26 12:42:16-- http://localhost:4000/
Résolution de localhost (localhost)… 127.0.0.1
Connexion à localhost (localhost)|127.0.0.1|:4000… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 75708 (74K) [text/html]
Sauvegarde en : « index.html »
En revanche j'ai une erreur 404 sur le wget de l'API :
$ wget http://localhost:5002/gncitizen/api
--2023-05-26 12:52:40-- http://localhost:5002/gncitizen/api
Resolving localhost (localhost)... 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|:5002... connected.
HTTP request sent, awaiting response... 404 NOT FOUND
2023-05-26 12:52:40 ERROR 404: NOT FOUND.
$ wget http://localhost:4000 --2023-05-26 12:42:16-- http://localhost:4000/ Résolution de localhost (localhost)… 127.0.0.1 Connexion à localhost (localhost)|127.0.0.1|:4000… connecté. requête HTTP transmise, en attente de la réponse… 200 OK Taille : 75708 (74K) [text/html] Sauvegarde en : « index.html »
Cela génère des erreurs dans supervisor_gncitizen_front.log :
getAllPrograms failed: ErrorEvent is not defined
getAllPrograms failed: ErrorEvent is not defined
ERROR ReferenceError: ErrorEvent is not defined
at CatchSubscriber.selector (/home/geonatureadmin/gncitizen/frontend/dist/server.js:337642:42)
at CatchSubscriber.error (/home/geonatureadmin/gncitizen/frontend/dist/server.js:40609:31)
at XMLHttpRequest.onLoad (/home/geonatureadmin/gncitizen/frontend/dist/server.js:92614:30)
at XMLHttpRequestEventTarget.dispatchEvent (/home/geonatureadmin/gncitizen/frontend/dist/server.js:117878:20)
at XMLHttpRequest._dispatchProgress (/home/geonatureadmin/gncitizen/frontend/dist/server.js:118373:12)
at XMLHttpRequest._onHttpResponseEnd (/home/geonatureadmin/gncitizen/frontend/dist/server.js:118328:12)
at IncomingMessage.<anonymous> (/home/geonatureadmin/gncitizen/frontend/dist/server.js:118287:24)
at ZoneDelegate.invokeTask (/home/geonatureadmin/gncitizen/frontend/dist/server.js:611:35)
at Object.onInvokeTask (/home/geonatureadmin/gncitizen/frontend/dist/server.js:29357:33)
at ZoneDelegate.invokeTask (/home/geonatureadmin/gncitizen/frontend/dist/server.js:610:40)
Bonjour,
L'erreur 404 venait effectivement d'un problème de configuration apache, il y avait un conflit avec le virtual host de GeoNature. En séparant les virtual host, c'est mieux.
J'ai aussi corrigé le fichier settings.ini :
# My host URL or IP with / at the end
my_url=http://citizen.oreme.org/
url_application=http://citizen.oreme.org/gncitizen # Url For the frontend
api_endpoint=http://geonature.oreme.org/geonature/api # Url for the geonature api don't forget /api
api_port=5002 # GeoNature-citizen API port, recommended settings
api_taxhub=http://geonature.oreme.org/taxhub/api/ # Url for the taxhub api
Désormais j'ai quelque chose sur http://citizen.oreme.org et sur api/admin (mais pas sur http://citizen.oreme.org/gncitizen)
J'ai cependant toujours une erreur sur le frontend dans supervisor_gncitizen_front.log :
-------------------------------------------------
GeoNature-citizen frontend server is starting ...
-------------------------------------------------
Found '/home/geonatureadmin/gncitizen/frontend/.nvmrc' with version <v14.17.6>
Now using node v14.17.6 (npm v6.14.15)
> frontend@1.0.0 serve:ssr /home/geonatureadmin/gncitizen/frontend
> node dist/server
/home/geonatureadmin/gncitizen/frontend/dist/server.js:382
throw error;
^
Error: listen EADDRINUSE: address already in use :::4000
at Server.setupListenHandle [as _listen2] (net.js:1320:16)
at listenInCluster (net.js:1368:12)
at Server.listen (net.js:1454:7)
at Function.listen (/home/geonatureadmin/gncitizen/frontend/dist/server.js:128475:24)
at Module.<anonymous> (/home/geonatureadmin/gncitizen/frontend/dist/server.js:178:5)
at __webpack_require__ (/home/geonatureadmin/gncitizen/frontend/dist/server.js:20:30)
at /home/geonatureadmin/gncitizen/frontend/dist/server.js:84:18
at Object.<anonymous> (/home/geonatureadmin/gncitizen/frontend/dist/server.js:87:10)
at Module._compile (internal/modules/cjs/loader.js:1072:14)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1101:10)
Emitted 'error' event on Server instance at:
at emitErrorNT (net.js:1347:8)
at ZoneDelegate.invokeTask (/home/geonatureadmin/gncitizen/frontend/dist/server.js:611:35)
at Zone.runTask (/home/geonatureadmin/gncitizen/frontend/dist/server.js:378:51)
at ZoneTask.invokeTask (/home/geonatureadmin/gncitizen/frontend/dist/server.js:693:38)
at ZoneTask.invoke (/home/geonatureadmin/gncitizen/frontend/dist/server.js:682:52)
at data.args.<computed> (/home/geonatureadmin/gncitizen/frontend/dist/server.js:1634:63)
at processTicksAndRejections (internal/process/task_queues.js:82:21) {
code: 'EADDRINUSE',
errno: -98,
syscall: 'listen',
address: '::',
port: 4000
}
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! frontend@1.0.0 serve:ssr: `node dist/server`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the frontend@1.0.0 serve:ssr script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! /home/geonatureadmin/.npm/_logs/2023-06-30T12_39_48_990Z-debug.log
Et dans les log npm en question :
0 info it worked if it ends with ok
1 verbose cli [
1 verbose cli '/home/geonatureadmin/.nvm/versions/node/v14.17.6/bin/node',
1 verbose cli '/home/geonatureadmin/.nvm/versions/node/v14.17.6/bin/npm',
1 verbose cli 'run',
1 verbose cli 'serve:ssr'
1 verbose cli ]
2 info using npm@6.14.15
3 info using node@v14.17.6
4 verbose run-script [ 'preserve:ssr', 'serve:ssr', 'postserve:ssr' ]
5 info lifecycle frontend@1.0.0~preserve:ssr: frontend@1.0.0
6 info lifecycle frontend@1.0.0~serve:ssr: frontend@1.0.0
7 verbose lifecycle frontend@1.0.0~serve:ssr: unsafe-perm in lifecycle true
8 verbose lifecycle frontend@1.0.0~serve:ssr: PATH: /home/geonatureadmin/.nvm/versions/node/v14.17.6/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/home/geonatureadmin/gncitizen/fronte>
9 verbose lifecycle frontend@1.0.0~serve:ssr: CWD: /home/geonatureadmin/gncitizen/frontend
10 silly lifecycle frontend@1.0.0~serve:ssr: Args: [ '-c', 'node dist/server' ]
11 silly lifecycle frontend@1.0.0~serve:ssr: Returned: code: 1 signal: null
12 info lifecycle frontend@1.0.0~serve:ssr: Failed to exec serve:ssr script
13 verbose stack Error: frontend@1.0.0 serve:ssr: `node dist/server`
13 verbose stack Exit status 1
13 verbose stack at EventEmitter.<anonymous> (/home/geonatureadmin/.nvm/versions/node/v14.17.6/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:332:16)
13 verbose stack at EventEmitter.emit (events.js:400:28)
13 verbose stack at ChildProcess.<anonymous> (/home/geonatureadmin/.nvm/versions/node/v14.17.6/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.js:55:14)
13 verbose stack at ChildProcess.emit (events.js:400:28)
13 verbose stack at maybeClose (internal/child_process.js:1055:16)
13 verbose stack at Process.ChildProcess._handle.onexit (internal/child_process.js:288:5)
14 verbose pkgid frontend@1.0.0
15 verbose cwd /home/geonatureadmin/gncitizen/frontend
16 verbose Linux 5.10.0-23-cloud-amd64
17 verbose argv "/home/geonatureadmin/.nvm/versions/node/v14.17.6/bin/node" "/home/geonatureadmin/.nvm/versions/node/v14.17.6/bin/npm" "run" "serve:ssr"
18 verbose node v14.17.6
19 verbose npm v6.14.15
20 error code ELIFECYCLE
21 error errno 1
22 error frontend@1.0.0 serve:ssr: `node dist/server`
22 error Exit status 1
23 error Failed at the frontend@1.0.0 serve:ssr script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 1, true ]
Il vaudrait peut-être mieux que je fasse une nouvelle issue ?
OK je crois que c'est encore un conflit avec GeoNature, conflit sur le port 4000.
Il n'y a rien qui tourne sur le port 4000 côté GeoNature
En effet j'ai plané !
Votre gncitizen est sur l'url http://citizen.oreme.org/, votre config de frontend (dans src/conf/app.config.ts) semble indiquer que l'API de Citizen (variable API_ENDPOINT) est à http://geonature.oreme.org/gncitizen/api alors quelle est disponible à http://citizen.oreme.org/api. En principe il ne vous reste plus qu'à changer cette variable dans la conf du frontend et le recompiler. Par précaution, je vous recommande de tuer le processus node en cours et de le relancer via supervisor (sudo supervisorctl restart gncitizen_front)
Bonjour,
Merci !
Dans le fichier de settings il est indiqué # Url for the geonature api don't forget /api, j'ai donc bêtement renseigné http://geonature.oreme.org/geonature/api à mon 2ème essai d'installation ..
Désolée pour la question de béotienne, mais quelle commande dois-je lancer pour recompiler le frontend après avoir modifié la conf ?
En effet, c'est à revoir dans les fichiers de config, merci pour ce retour.
Voici concernant la commande de recompilation:
cd ~/gncitizen/frontend/
nvm use
npm run build:i18n-ssrMerci !
La compilation a bien marché, j'ai relancé le front, mais j'ai toujours les mêmes erreurs dans les logs ..
Error: listen EADDRINUSE: address already in use :::4000
at Server.setupListenHandle [as _listen2] (net.js:1320:16)
at listenInCluster (net.js:1368:12)
at Server.listen (net.js:1454:7)
at Function.listen (/home/geonatureadmin/gncitizen/frontend/dist/server.js:128475:24)
at Module.<anonymous> (/home/geonatureadmin/gncitizen/frontend/dist/server.js:178:5)
at __webpack_require__ (/home/geonatureadmin/gncitizen/frontend/dist/server.js:20:30)
at /home/geonatureadmin/gncitizen/frontend/dist/server.js:84:18
at Object.<anonymous> (/home/geonatureadmin/gncitizen/frontend/dist/server.js:87:10)
at Module._compile (internal/modules/cjs/loader.js:1072:14)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1101:10)
Emitted 'error' event on Server instance at:
at emitErrorNT (net.js:1347:8)
at ZoneDelegate.invokeTask (/home/geonatureadmin/gncitizen/frontend/dist/server.js:611:35)
at Zone.runTask (/home/geonatureadmin/gncitizen/frontend/dist/server.js:378:51)
at ZoneTask.invokeTask (/home/geonatureadmin/gncitizen/frontend/dist/server.js:693:38)
at ZoneTask.invoke (/home/geonatureadmin/gncitizen/frontend/dist/server.js:682:52)
at data.args.<computed> (/home/geonatureadmin/gncitizen/frontend/dist/server.js:1634:63)
at processTicksAndRejections (internal/process/task_queues.js:82:21) {
code: 'EADDRINUSE',
errno: -98,
syscall: 'listen',
address: '::',
port: 4000
}
J'ai tenté de modifier également dans la config URL_APPLICATION:http://citizen.oreme.org (sans le segment gncitizen final) mais pas mieux ...
C'est sans doute que le service précédent tourne toujours en tache de fond. Tentez les commandes suivantes:
sudo supervisorctl stop gncitizen_front
sudo killall node
sudo supervisorctl start gncitizen_frontOuiiii ça marche ! Merci infiniment !
Bonjour,
J'ai tenté l'installation de la Geonature Ctitizen version 1.0.0 en suivant les conseils mentionnés dans ce post, dont je remercie les participants.
L'installation a globalement bien fonctionné, mais le chargement du site est très long (plus d'une minute) et j'ai une erreur "getAllPrograms failed: ErrorEvent is not defined..." dans le fichier supervisor_gncitizen_front.log.
La partie admin (/api/admin/) fonctionne normalement.
Une idée d'où peut venir le problème ? Toute aide sera la bienvenue !
Merci d'avance.
Bonjour @sig-pnrbsn, que donne l'url d'API /api/programs, correspondant à celle appelée par la fonction getAllPrograms du frontend? Comment la première enquête a-t-elle été créée?
@lpofredc merci pour votre aide. L'url /api/programs renvoie la liste des programmes en JSON. Il y a 2 enquêtes test créées sur l'interface d'administration (/api/admin). Voici le résultat :
{"type": "FeatureCollection", "features": [{"properties": {"id_program": 1, "id_project": 1, "title": "prgm test", "short_desc": "test de programme", "image": null, "logo": null, "id_module": 1, "taxonomy_list": 106, "is_active": true, "timestamp_create": "2024-01-15 10:21:35.340038", "timestamp_update": "2024-01-15 10:21:35.340041", "module": {"id_module": 1, "name": "observations", "label": "observations", "desc": "Module d'observations taxonomiques", "icon": null, "on_sidebar": false, "timestamp_create": "2024-01-15 09:08:14.166076", "timestamp_update": "2024-01-15 09:08:14.166081"}, "project": {"id_project": 1, "unique_id_project": "e529cb0d-a4f7-4bcd-89dc-5ccd7e40d21c", "name": "projet test", "short_desc": null, "long_desc": "", "timestamp_create": "2024-01-15 10:21:09.549706", "timestamp_update": "2024-01-15 10:21:09.549709"}}}, {"properties": {"id_program": 2, "id_project": 1, "title": "prgm test 2", "short_desc": "test prgm2", "image": null, "logo": null, "id_module": 1, "taxonomy_list": 103, "is_active": true, "timestamp_create": "2024-01-15 10:45:12.497003", "timestamp_update": "2024-01-15 10:45:12.497005", "module": {"id_module": 1, "name": "observations", "label": "observations", "desc": "Module d'observations taxonomiques", "icon": null, "on_sidebar": false, "timestamp_create": "2024-01-15 09:08:14.166076", "timestamp_update": "2024-01-15 09:08:14.166081"}, "project": {"id_project": 1, "unique_id_project": "e529cb0d-a4f7-4bcd-89dc-5ccd7e40d21c", "name": "projet test", "short_desc": null, "long_desc": "", "timestamp_create": "2024-01-15 10:21:09.549706", "timestamp_update": "2024-01-15 10:21:09.549709"}}}], "count": 2}
merci @sig-pnrbsn. Je ne parviens pas à reproduire.
L'interface de Citizen se charge-t-elle a minima (logo, image de l'introduction). Une capture d'écran complète avec le rendu de la page et la console du navigateur ouverte aiderait à mieux comprendre le problème.
Par ailleurs, ce message d'erreur que vous avez m'interpelle, il stipule que ErrorEvent is not defined alors que c'est un type d'object javascript normalement reconnu par les navigateurs modernes: https://developer.mozilla.org/fr/docs/Web/API/ErrorEvent.
Quel navigateur utilisez-vous, avez-vous essayé sur Chrome ou Firefox ?
@lpofredc Oui l'interface se charge avec les éléments par défaut (elle n'est pas encore personnalisée).
J'utilise un navigateur Firefox à jour.
Voici le message complet dans le log :
getAllPrograms failed: ErrorEvent is not defined
ERROR ReferenceError: ErrorEvent is not defined
at CatchSubscriber.selector (/home/geonat/gncitizen1/frontend/dist/server.js:337642:42)
at CatchSubscriber.error (/home/geonat/gncitizen1/frontend/dist/server.js:40609:31)
at XMLHttpRequest.onError (/home/geonat/gncitizen1/frontend/dist/server.js:92635:26)
at XMLHttpRequestEventTarget.dispatchEvent (/home/geonat/gncitizen1/frontend/dist/server.js:117878:20)
at XMLHttpRequest._dispatchProgress (/home/geonat/gncitizen1/frontend/dist/server.js:118373:12)
at XMLHttpRequest._onHttpRequestError (/home/geonat/gncitizen1/frontend/dist/server.js:118363:12)
at ClientRequest. (/home/geonat/gncitizen1/frontend/dist/server.js:118232:24)
at ZoneDelegate.invokeTask (/home/geonat/gncitizen1/frontend/dist/server.js:611:35)
at Object.onInvokeTask (/home/geonat/gncitizen1/frontend/dist/server.js:29357:33)
at ZoneDelegate.invokeTask (/home/geonat/gncitizen1/frontend/dist/server.js:610:40)
Locale: fr.
Ci-joint une capture d'écran avec la console. L'adresse du site (provisoire) est la suivante si vous voulez voir directement :
https://citizen.cartaparc.fr
Merci
Bonjour @lpofredc, avez-vous une idée de l'origine du problème. Ou bien d'autres tests à réaliser ?
Merci
Bonjour @sig-pnrbsn,
Rien n'aboutit sur l'URL fournie (https://citizen.cartaparc.fr).
J'ai en effet pu constater une telle erreur dans le log du frontent côté serveur, lorsque le backend (API flask) était off. Cela fait penser à ce ticket: https://stackoverflow.com/questions/76517268/angular-universal-ssr-not-reaching-api-with-error-errorevent-is-not-defined
Les services frontend et backend sont-ils bien opérationnels ?
Pouvez-vous préciser les configurations suivantes ?
GeoNature-citizen/config/config.toml.template
Lines 19 to 22 in 93472ea
GeoNature-citizen/frontend/src/conf/app.config.ts.template
Lines 3 to 21 in 93472ea
Bonjour @lpofredc ,
L'URL https://citizen.cartaparc.fr/ finit par aboutir, mais il faut être vraiment très patient... :)
La commande sudo supervisorctl status renvoie les services gncitizen_api et gncitizen_front en statut "running".
Voici le contenu des fichiers de configuration.
- /frontend/src/conf/app.config.ts :
API_ENDPOINT:"https://citizen.cartaparc.fr/api",
API_TAXHUB:"https://citizen.cartaparc.fr/taxhub/api",
API_CITY: 'https://nominatim.openstreetmap.org/reverse',
// HCAPTCHA_SITE_KEY: null,
// FRONTEND: {
// PROD_MOD: true,
// MULTILINGUAL: false,
// DISPLAY_FOOTER: true,
// DISPLAY_TOPBAR: true,
// DISPLAY_SIDEBAR: true,
// DISPLAY_STATS: true,
// DISPLAY_BADGES: true,
// NEW_OBS_FORM_MODAL_VERSION: true,
// },
// META: {
// keywords: 'biodiversite enquetes participatif observations',
// },
// about: true,
URL_APPLICATION:"https://citizen.cartaparc.fr",
- /config/config.toml :
URL_APPLICATION = "https://citizen.cartaparc.fr"
API_TAXHUB = "http://127.0.0.1:5000/api/"
# URL to get info about a municipality (from a latitude and a longitude)
API_CITY = "https://nominatim.openstreetmap.org/reverse",
Bonjour @lpofredc ,
Je me permet de relancer cette discussion car je n'ai toujours pas trouvé de solution à mon problème.
Les paramètres ci-dessus vous semblent-ils corrects ?
Merci d'avance.
Je tente une installation sur debian 12. J'utilise la branche dev après un git clone du projet. Je vous fais un retour des difficultés rencontrées.
Premier lancement de install/install_app.sh :
E: Le paquet « python-setuptools » n'a pas de version susceptible d'être installée
E: Le paquet « python-dev » n'a pas de version susceptible d'être installée
Dans install/install_app.sh, je remplace python-dev par python-dev-is-python3 et python-setuptools par python3-setuptools
Je relance install/install_app.sh
L'installation des paquets se déroule alors normalement mais l'erreur suivante remonte :
error: externally-managed-environment
× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
python3-xyz, where xyz is the package you are trying to
install.
If you wish to install a non-Debian-packaged Python package,
create a virtual environment using python3 -m venv path/to/venv.
Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
sure you have python3-full installed.
If you wish to install a non-Debian packaged Python application,
it may be easiest to use pipx install xyz, which will manage a
virtual environment for you. Make sure you have pipx installed.
See /usr/share/doc/python3.11/README.venv for more information.
note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.
Dans install/install_app.sh je commente la ligne 31 pip3 install --upgrade pip et je mets ce code dans la partie correpondant à l'exécution de pip dans le venv. C'est à dire après l'activation du venv
...
source .venv/bin/activate
#Maj de pip
pip3 install --upgrade pip
pip install -r requirements.txt
...
Je relance install/install_app.sh. Cette fois-ci pip se met à jour en version 24 puis installe tout sans erreur. Puis nouvelle erreur :
Successfully installed alembic-1.13.1 attrs-23.2.0 blinker-1.7.0 cachelib-0.9.0 certifi-2024.2.2 charset-normalizer-3.3.2 click-8.1.7 click-plugins-1.1.1 cligj-0.7.2 coloredlogs-15.0.1 fiona-1.9.5 flasgger-0.9.7.1 flask-2.3.3 flask-admin-1.6.1 flask-caching-2.1.0 flask-ckeditor-0.4.6 flask-cors-3.0.10 flask-jwt-extended-4.6.0 flask-migrate-4.0.5 flask-sqlalchemy-2.5.1 geoalchemy2-0.14.3 geojson-2.5.0 greenlet-3.0.3 gunicorn-20.1.0 humanfriendly-10.0 idna-3.6 itsdangerous-2.1.2 jinja2-3.1.3 jsonschema-4.21.1 jsonschema-specifications-2023.12.1 mako-1.3.2 markupsafe-2.1.5 marshmallow-3.20.2 marshmallow-geojson-0.5.0 marshmallow-sqlalchemy-1.0.0 mistune-3.0.2 packaging-23.2 passlib-1.7.4 psycopg2-binary-2.9.9 pyjwt-2.8.0 python-dateutil-2.8.2 pyyaml-6.0.1 referencing-0.33.0 requests-2.31.0 rpds-py-0.17.1 setuptools-69.0.3 shapely-1.8.5.post1 six-1.16.0 sqlalchemy-1.4.51 toml-0.10.2 typing-extensions-4.9.0 urllib3-2.2.0 utils-flask-sqlalchemy-0.4.1 utils-flask-sqlalchemy-geo-0.2.8 werkzeug-3.0.1 wtforms-3.1.2 xlwt-1.3.0
Traceback (most recent call last):
File "/home/geonatureadmin/gncitizen/backend/.venv/bin/flask", line 8, in <module>
sys.exit(main())
^^^^^^
File "/home/geonatureadmin/gncitizen/backend/.venv/lib/python3.11/site-packages/flask/cli.py", line 1064, in main
cli.main()
File "/home/geonatureadmin/gncitizen/backend/.venv/lib/python3.11/site-packages/click/core.py", line 1078, in main
rv = self.invoke(ctx)
^^^^^^^^^^^^^^^^
File "/home/geonatureadmin/gncitizen/backend/.venv/lib/python3.11/site-packages/click/core.py", line 1688, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/geonatureadmin/gncitizen/backend/.venv/lib/python3.11/site-packages/click/core.py", line 1688, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/geonatureadmin/gncitizen/backend/.venv/lib/python3.11/site-packages/click/core.py", line 1434, in invoke
return ctx.invoke(self.callback, **ctx.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/geonatureadmin/gncitizen/backend/.venv/lib/python3.11/site-packages/click/core.py", line 783, in invoke
return __callback(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/geonatureadmin/gncitizen/backend/.venv/lib/python3.11/site-packages/click/decorators.py", line 33, in new_func
return f(get_current_context(), *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/geonatureadmin/gncitizen/backend/.venv/lib/python3.11/site-packages/flask/cli.py", line 355, in decorator
app = __ctx.ensure_object(ScriptInfo).load_app()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/geonatureadmin/gncitizen/backend/.venv/lib/python3.11/site-packages/flask/cli.py", line 313, in load_app
app = locate_app(import_name, None, raise_if_not_found=False)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/geonatureadmin/gncitizen/backend/.venv/lib/python3.11/site-packages/flask/cli.py", line 219, in locate_app
__import__(module_name)
File "/home/geonatureadmin/gncitizen/backend/wsgi.py", line 13, in <module>
app = get_app(config)
^^^^^^^^^^^^^^^
File "/home/geonatureadmin/gncitizen/backend/server.py", line 85, in get_app
from gncitizen.core.commons.routes import commons_api
File "/home/geonatureadmin/gncitizen/backend/gncitizen/core/commons/routes.py", line 39, in <module>
admin.add_view(FileAdmin(MEDIA_DIR, "/api/media/", name="Medias"))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/geonatureadmin/gncitizen/backend/.venv/lib/python3.11/site-packages/flask_admin/contrib/fileadmin/__init__.py", line 1239, in __init__
storage = LocalFileStorage(base_path)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/geonatureadmin/gncitizen/backend/.venv/lib/python3.11/site-packages/flask_admin/contrib/fileadmin/__init__.py", line 34, in __init__
raise IOError('FileAdmin path "%s" does not exist or is not accessible' % self.base_path)
OSError: FileAdmin path "/home/geonatureadmin/gncitizen/media" does not exist or is not accessible
Je passe sur une exécution manuelle du script install/install_app.sh
L'erreur ci-dessus est levée par la commande flask db upgrade et est dûe au fait que le répertoire media n'existe pas. On voit dans https://github.com/PnX-SI/GeoNature-citizen/blob/dev/install/install_app.sh#L83 que la création du répertoire media est faite après la commande flask db upgrade. Il faut donc inverser l'ordre de ces 2 actions dans le script d'installation.
Pour tester je crée manuellement le répertoire media et j'y copie les medias depuis frontend/src/assets/. Puis je relance flask db upgrade. La création des schémas de citizen dans la base geonature se créent correctement. Je fini l'installation manuellement en reprenant les commandes du fichier ìnstall/install_app.sh`
A noter qu'il manque un deactivate après l'exécution de la commande flask db upgrade.
A noter également : dans le fichier settings.ini, il y a cette ligne :
api_endpoint=http://mydomain.net/api # Url for the geonature api don't forget /api
On peut être tenter de mettre l'url de l'api de geonature comme indiqué. Mais il faut mettre l'url de l'api de citizen.
A modifier ainsi :
api_endpoint=http://mydomain.net/api # Url for the gncitizen api don't forget /api
En poursuivant l'installation + configuration apache et https avec letsencript, l'application est disponible et fonctionnelle sur son url. L'url d'admin est accessible et fonctionnelle également.
Merci à tous pour vos commentaires et éclairages. Je reviens vers vous si dysfonctionnements manifestement en lien avec debian 12 une fois les enquêtes configurées.
Salut,
Retour sur une installation faite ce jour sur la branche dev en Debian 12 suite aux retours de @gildeluermoz et au taff de @hypsug0 pour finaliser la release d'une v1.0 (grand merci en passant !)
- Pas de soucis avec l'install des paquets suite aux corrections faites par @hypsug0 dans
install_app.sh👍 - Je confirme le soucis rencontré par Gil sur l'ordre de création du répertoire
mediadansinstall_app.sh. - Erreur levée lors de l'install :
./install/copy_config.sh: ligne 46: [! : commande introuvable
En effet, coquille dans./install/copy_config.shsur cette ligne avec un espace manquant entre[et!:
if [ ! -d media ]; then
mkdir media
fi- Problème de droits d'accès au répertoire de l'utilisateur crée pour l'install de GNC : avec Debian 12, le répertoire par défaut d'un nouvel utilisateur crée n'a que des droits 700 ne permettant pas aux autres utilisateurs (groups & others) de lire le répertoire (notamment
www-datapour Apache). Avec Debian 11 les droits d'un nouvel utilisateur était en 755.
Voici une PR avec les fix appliqués pour ces 3 derniers points #387
Après ça install OK, config OK, création d'un programme OK, saisie OK...
Merci encore !!
Trop bien, on tient le bon bout !
Merci pour les retours et la PR.
Installation corrigée et améliorée dans la version 1.0.0.