search

PnX-SI / GeoNature

Application de saisie et de synthèse des observations faune et flore
GNU General Public License v3.0
103 stars 102 forks source link

Problème de migration entre 2.6.2 et 2.7.X #1423

Closed geobrun closed 3 years ago

geobrun commented 3 years ago

Bonjour,

Depuis ma migration vers les versions 2.7.X, je n'arrive plus à me logger dans l'interface de GeoNature. Quand je réactive la version 2.6.2, pas de problème, cela fonctionne.

Le login dans Taxhub et Userhub fonctionne toujours bien, seul celui dans GeoNature pose problème. Je reçois le message d'erreur "Identifiant ou mot de passe incorrect" alors que les logins et mots de passe testés sont corrects. Par ailleurs, dans la console de Firefox/Chrome, je reçois une erreur 403.

En regardant les logs dans /var/log/apache2/error.log et geonature/var/log/gn-errors/log, je ne vois rien d'anormal. La route https://urlgeonature/occtax/defaultNomenclatures renvoie une erreur 404 ce qui ne devrait pas être le cas si je comprends bien.

Cela ressemble à un souci que j'ai déjà rencontré il y a quelques mois il me semble quand j'ai passé notre GeoNature en HTTPS. Quelque chose a changé dans la configuration Apache ?

camillemonchicourt commented 3 years ago

Oui cela peut venir des évolutions de la conf Apache où on a ajouté un servername, où il faut que tu renseignes ton domaine : https://github.com/PnX-SI/GeoNature/issues/1420

Mais en y réfléchissant, l'ajout de ce servername dans la conf par défaut, ne devrait pas poser de soucis si tu n'en as pas. C'est seulement utile pour l'Admin quand on utilise GeoNature sur un serveur.

geobrun commented 3 years ago

Oui, j'avais vu ce sujet, mais j'avais compris que cela n'était valable que pour une nouvelle installation, pas dans le cas d'une migration ?

Où est-ce que je peux modifier ce servername ? J'ai regardé les fichiers dans /etc/apaches2 mais je ne vois pas lequel je pourrais modifier pour arriver à mes fins. Dans 000-default.conf ?

camillemonchicourt commented 3 years ago

Oui c'est fait que sur les nouvelles installations. Tu peux le répercuter sur une installation existante, en t'appuyant sur l'exemple du template de conf Apache : https://github.com/PnX-SI/GeoNature/blob/master/install/assets/geonature_apache.conf

Mais ce n'est pas utile, sauf si tu es sur une adresse IP. Et donc il n'y a pas de raison que cela règle ton soucis.

geobrun commented 3 years ago

J'ai tenté des modifications sur les fichiers /etc/apache2/sites-availables/geonature.conf et /etc/apache2/sites-availables/geonature-le-ssl.conf mais rien n'y fait... :(

camillemonchicourt commented 3 years ago

Oui c'est autre chose. Peux-tu préciser l'erreur dans la console ?

geobrun commented 3 years ago

Dans la console de Firefox par exemple ?

camillemonchicourt commented 3 years ago

Oui

DonovanMaillard commented 3 years ago

Il faudrait jouer la commande sudo supervisorctl restart all

Ca permettrait de s'assurer que GeoNature se lance bien. Il y avait une note de version sur le fait de changer le log de supervisor notamment dans cette montée de version, à voir si cette commande a bien été passée. Sinon il est possible que GeoNature ait ce soucis d'accès au fichier de log qui l'empêche de se lancer... (cf #1003 )

geobrun commented 3 years ago

Quand je clique sur "se connecter", cela envoie la requête suivante : XHR POST https://geonature.pnr-millevaches.fr/api/auth/login. Je reçois un message "403 FORBIDDEN" et "strict-origin-when-cross-origin". Dans la réponse JSON, j'ai "login: false" et "msg:TypeError(sequence item 0: expected str instance, ColumnProperty found)".

@DonovanMaillard : je viens de tester ta commande, aucun problème à signaler.

gildeluermoz commented 3 years ago

Le CORS (cross origin), ça peut venir d'apels dadresses en http depuis du https. Tout est bien en https, y compris usershub ?

geobrun commented 3 years ago

Oui, pas de problème, j'avais fait cela pour déployer l'application Occtax-mobile. Effectivement, le problème vient peut-être du HTTPS car j'avais pas mal galéré pour l'implémenter il y a quelques mois. Mais au final, j'avais trouvé la solution grâce à votre aide et tout fonctionnait jusqu'en version 2.6.2.

Ce que je trouve curieux, c'est que dans tous les logs que j'ai parcourus (GeoNature, Usershub, Apache2, Supervisor), je ne trouve aucune trace de mes "clics" sur le bouton "se connecter". Il doit bien y avoir une trace quelque part pourtant ? A moins que la requête soit bloquée par le client, avant l'arrivée au serveur ?

geobrun commented 3 years ago

Petite information supplémentaire : durant la migration, j'ai le message d'erreur suivant qui apparaît au moment du redémarrage du Supervisor.

Traceback (most recent call last):
  File "/home/geonatureadmin/geonature/backend/geonature/utils/gn_module_import.py", line 391, in create_module_config
    module_object = TModules.query.filter_by(module_code=module_code).one()
  File "/home/geonatureadmin/geonature/backend/venv/lib/python3.6/site-packages/sqlalchemy/orm/query.py", line 3500, in one
    raise orm_exc.NoResultFound("No row was found for one()")
sqlalchemy.orm.exc.NoResultFound: No row was found for one()

Et après, deux autres messages qui paraissent moins importants étant donné que je n'ai pas installé les deux modules en question.

Exception: Module with code 'VALIDATION' not found in database. Exception: Module with code 'OCCHAB' not found in database.

TheoLechemia commented 3 years ago

L'erreur lors de la migration est normale si les modules ne sont pas installé. L'erreur 403 lors du login vient du fait que l'utilisateur n'a pas les droits de connexion sur GN. cela veut aussi dire que le backend tourne bien et que le front fonctionne aussi. Est-ce que tu peux ouvrir le fichier var/log/gn_errors.log et nous dire ce qu'il raconte quand tu essaye de te connecter ?

geobrun commented 3 years ago

Aucune ligne n'apparaît quand je clique sur "Se connecter". Voilà les lignes que j'ai pour aujourd'hui.

[2021-07-21 07:06:55 +0000] [13727] [INFO] Starting gunicorn 19.7.0
[2021-07-21 07:06:55 +0000] [13727] [INFO] Listening at: http://0.0.0.0:8000 (13727)
[2021-07-21 07:06:55 +0000] [13727] [INFO] Using worker: sync
[2021-07-21 07:06:55 +0000] [13754] [INFO] Booting worker with pid: 13754
[2021-07-21 07:06:55 +0000] [13758] [INFO] Booting worker with pid: 13758
[2021-07-21 07:06:55 +0000] [13769] [INFO] Booting worker with pid: 13769
[2021-07-21 07:06:55 +0000] [13789] [INFO] Booting worker with pid: 13789
[2021-07-21 07:07:04 +0000] [13727] [INFO] Handling signal: term
[2021-07-21 07:07:04 +0000] [13758] [INFO] Worker exiting (pid: 13758)
[2021-07-21 07:07:04 +0000] [13754] [INFO] Worker exiting (pid: 13754)
[2021-07-21 07:07:04 +0000] [13769] [INFO] Worker exiting (pid: 13769)
[2021-07-21 07:07:04 +0000] [13789] [INFO] Worker exiting (pid: 13789)
[2021-07-21 07:07:05 +0000] [13727] [INFO] Shutting down: Master
[2021-07-21 07:07:06 +0000] [14114] [INFO] Starting gunicorn 19.7.0
[2021-07-21 07:07:06 +0000] [14114] [INFO] Listening at: http://0.0.0.0:8000 (14114)
[2021-07-21 07:07:06 +0000] [14114] [INFO] Using worker: sync
[2021-07-21 07:07:06 +0000] [14143] [INFO] Booting worker with pid: 14143
[2021-07-21 07:07:06 +0000] [14146] [INFO] Booting worker with pid: 14146
[2021-07-21 07:07:06 +0000] [14153] [INFO] Booting worker with pid: 14153
[2021-07-21 07:07:06 +0000] [14155] [INFO] Booting worker with pid: 14155
[2021-07-21 07:07:12 +0000] [14114] [INFO] Handling signal: term
[2021-07-21 07:07:13 +0000] [14146] [INFO] Worker exiting (pid: 14146)
[2021-07-21 07:07:14 +0000] [14155] [INFO] Worker exiting (pid: 14155)
[2021-07-21 07:07:14 +0000] [14143] [INFO] Worker exiting (pid: 14143)
[2021-07-21 07:07:14 +0000] [14153] [INFO] Worker exiting (pid: 14153)
[2021-07-21 07:07:14 +0000] [14114] [INFO] Shutting down: Master
[2021-07-21 07:07:16 +0000] [14471] [INFO] Starting gunicorn 19.7.0
[2021-07-21 07:07:16 +0000] [14471] [INFO] Listening at: http://0.0.0.0:8000 (14471)
[2021-07-21 07:07:16 +0000] [14471] [INFO] Using worker: sync
[2021-07-21 07:07:16 +0000] [14509] [INFO] Booting worker with pid: 14509
[2021-07-21 07:07:16 +0000] [14535] [INFO] Booting worker with pid: 14535
[2021-07-21 07:07:16 +0000] [14540] [INFO] Booting worker with pid: 14540
[2021-07-21 07:07:16 +0000] [14547] [INFO] Booting worker with pid: 14547
[2021-07-21 07:08:24 +0000] [14471] [INFO] Handling signal: term
[2021-07-21 07:08:24 +0000] [14535] [INFO] Worker exiting (pid: 14535)
[2021-07-21 07:08:24 +0000] [14547] [INFO] Worker exiting (pid: 14547)
[2021-07-21 07:08:24 +0000] [14540] [INFO] Worker exiting (pid: 14540)
[2021-07-21 07:08:24 +0000] [14509] [INFO] Worker exiting (pid: 14509)
[2021-07-21 07:08:25 +0000] [14471] [INFO] Shutting down: Master
[2021-07-21 07:08:27 +0000] [15020] [INFO] Starting gunicorn 19.7.0
[2021-07-21 07:08:27 +0000] [15020] [INFO] Listening at: http://0.0.0.0:8000 (15020)
[2021-07-21 07:08:27 +0000] [15020] [INFO] Using worker: sync
[2021-07-21 07:08:27 +0000] [15054] [INFO] Booting worker with pid: 15054
[2021-07-21 07:08:27 +0000] [15056] [INFO] Booting worker with pid: 15056
[2021-07-21 07:08:27 +0000] [15060] [INFO] Booting worker with pid: 15060
[2021-07-21 07:08:27 +0000] [15066] [INFO] Booting worker with pid: 15066
geobrun commented 3 years ago

Petite précision : lorsque je charge la page de login, avant d'essayer de se connecter, j'ai ce message dans les consoles Firefox/Chrome.

Failed to load resource: the server responded with /api/gn_commons/modules:1 a status of 401 (UNAUTHORIZED)

geobrun commented 3 years ago

Pour information, quand je relance le supervisor, j'ai ça qui apparaît dans le log même s'il démarre bien.

2021-07-21 09:07:21,826 CRIT Supervisor running as root (no user in config file)
2021-07-21 09:07:21,833 CRIT Server 'unix_http_server' running without any HTTP authentication checking
geobrun commented 3 years ago

Je pense que mon problème ne vient pas de l'authentification. Je viens de tester une route au hasard https://urlgeonature/api/gn_commons/t_mobile_apps et je reçois une erreur 500 (The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application). Quand je repasse en version 2.6.2, cette route refonctionne.

bouttier commented 3 years ago

Bonjour, Quelle est l’erreur dans les logs lorsque cette 500 se produit ?

geobrun commented 3 years ago

Bonjour,

Voici l'erreur que je reçois.

[2021-07-21 09:51:00 +0000] [5468] [ERROR] Exception on /gn_commons/t_mobile_apps [GET]
Traceback (most recent call last):
  File "/home/geonatureadmin/geonature/backend/venv/lib/python3.6/site-packages/flask/app.py", line 2446, in wsgi_app
    response = self.full_dispatch_request()
  File "/home/geonatureadmin/geonature/backend/venv/lib/python3.6/site-packages/flask/app.py", line 1951, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/home/geonatureadmin/geonature/backend/venv/lib/python3.6/site-packages/flask_cors/extension.py", line 165, in wrapped_function
    return cors_after_request(app.make_response(f(*args, **kwargs)))
  File "/home/geonatureadmin/geonature/backend/venv/lib/python3.6/site-packages/flask/app.py", line 1821, in handle_user_exception
    return handler(e)
  File "/home/geonatureadmin/geonature/backend/geonature/core/errors/routes.py", line 82, in handle_exception
    raise e
  File "/home/geonatureadmin/geonature/backend/venv/lib/python3.6/site-packages/flask/app.py", line 1949, in full_dispatch_request
    rv = self.dispatch_request()
  File "/home/geonatureadmin/geonature/backend/venv/lib/python3.6/site-packages/flask/app.py", line 1935, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/home/geonatureadmin/geonature/backend/venv/lib/python3.6/site-packages/utils_flask_sqla/response.py", line 19, in _json_resp
    res = fn(*args, **kwargs)
  File "/home/geonatureadmin/geonature/backend/geonature/core/gn_commons/routes.py", line 178, in get_t_mobile_apps
    one_app = d.as_dict()
  File "/home/geonatureadmin/geonature/backend/venv/lib/python3.6/site-packages/utils_flask_sqla/serializers.py", line 238, in serializefn
    _columns, _relationships = get_columns_and_relationships(fields, exclude)
  File "/home/geonatureadmin/geonature/backend/venv/lib/python3.6/site-packages/utils_flask_sqla/serializers.py", line 145, in get_columns_and_relationships
    for key, col in ChainMap(mapper.column_attrs, hybrid_properties).items()
  File "/home/geonatureadmin/geonature/backend/venv/lib/python3.6/site-packages/utils_flask_sqla/serializers.py", line 144, in <dictcomp>
    _columns = { key: col
  File "/usr/lib/python3.6/_collections_abc.py", line 744, in __iter__
    yield (key, self._mapping[key])
  File "/usr/lib/python3.6/collections/__init__.py", line 883, in __getitem__
    return self.__missing__(key)            # support subclasses that define __missing__
  File "/usr/lib/python3.6/collections/__init__.py", line 875, in __missing__
    raise KeyError(key)
KeyError: <ColumnProperty at 0x7ff6d7edb238; version_code>

Une idée ?

camillemonchicourt commented 3 years ago

Ça ressemble vraiment à quelque chose lié aux évolutions de la 2.7.0 sur la méthode de récupération et de chargement des modules.

geobrun commented 3 years ago

J'ai testé quelques routes et voilà les résultats.

Celles-ci fonctionnent.

synthese/defaultsNomenclatures
occtax/defaultsNomenclatures
synthese/taxa_distribution

Celles-ci renvoient vers la page de login.

gn_commons/modules
meta/datasets
occtax/occurrences
permissions/cruved

Celles-ci renvoient une erreur 500.

pypn/register/test_uh
gn_commons/t_mobile_apps
gn_commons/list/parameters
config
geo/municipalities
synthese/taxons_autocomplete
users/roles

Petit précision : je suis sur un serveur Ubuntu 18.04 à jour.

bouttier commented 3 years ago

Je suspecte un problème lié à la version de python. La plateforme cible officiellement supporté est Debian 10, avec python 3.7.

geobrun commented 3 years ago

Ok, ma version de python est 3.6.9.

Qu'est-ce qui est le plus prudent dans ce cas ? Passer à Ubuntu 20.4 qui propose un Python 3.8 par défaut si j'ai bien compris ou forcer une installation de Python 3.7 sur mon Ubuntu 18.4 ?

J'ai prévu de passer sur Debian en milieu d'année prochaine si tout va bien.

bouttier commented 3 years ago

J’imagine que Python 3.7 sous Ubuntu 18.04 devrait fonctionner, mais je ne peux le garantir. Sinon on a au moins un développeur qui utilise Ubuntu 20.04 donc à priori pas de soucis avec cette plateforme.

geobrun commented 3 years ago

Je passerai bien en 20.4 mais j'ai peur que cela ne dérègle d'autres trucs. Il n'y a que GeoNature qui tourne sur ce serveur. Je suppose que si je passe à Python 3.7 sur mon Ubuntu 18.4 comme indiqué ici et que cela pose problème, je pourrait facilement retourner à ma version 3.6.9 ?

bouttier commented 3 years ago

Oui j’imagine qu’il suffira de désinstaller python3.7.

TheoLechemia commented 3 years ago

J'aimerais bien avoir les logs lors de l'erreur 403. C'est normal que toutes les autres redirige vers la login avec un code 401: car ce sont des routes protegés qui ne sont pas accessible sans login

geobrun commented 3 years ago

@bouttier : j'ai bien installé Python 3.7 avec la première méthode décrite dans l'article. J'ai configuré python -V pour qu'il me renvoie 3.7.11. Par contre, j'ai laissé python3 -V en 3.6.9. Pour le moment, cela ne fonctionne toujours pas. Il reste peut-être une manip' que j'ai loupée ?

@TheoLechemia : pas de trace de l'erreur 403 dans gn_errors.log, ni dans supervisor.log.

Rien n'apparaît dans gn_errors quand je clique sur "Se connecter". Pour info, j'ai bien stdout_logfile = /home/geonatureadmin/geonature/var/log/supervisor.log dans le fichier /etc/supervisor/conf.d/geonature-service.conf comme me l'a rappelé @DonovanMaillard.

J'ai bien eu cette erreur ce matin en remontant dans gn_errors.log, mais elle n'est pas liée à l'erreur 403 il me semble.

Traceback (most recent call last):
  File "/home/geonatureadmin/geonature/backend/venv/lib/python3.6/site-packages/gunicorn/arbiter.py", line 578, in spawn_worker
    worker.init_process()
  File "/home/geonatureadmin/geonature/backend/venv/lib/python3.6/site-packages/gunicorn/workers/base.py", line 126, in init_process
    self.load_wsgi()
  File "/home/geonatureadmin/geonature/backend/venv/lib/python3.6/site-packages/gunicorn/workers/base.py", line 135, in load_wsgi
    self.wsgi = self.app.wsgi()
  File "/home/geonatureadmin/geonature/backend/venv/lib/python3.6/site-packages/gunicorn/app/base.py", line 67, in wsgi
    self.callable = self.load()
  File "/home/geonatureadmin/geonature/backend/venv/lib/python3.6/site-packages/gunicorn/app/wsgiapp.py", line 65, in load
    return self.load_wsgiapp()
  File "/home/geonatureadmin/geonature/backend/venv/lib/python3.6/site-packages/gunicorn/app/wsgiapp.py", line 52, in load_wsgiapp
    return util.import_app(self.app_uri)
  File "/home/geonatureadmin/geonature/backend/venv/lib/python3.6/site-packages/gunicorn/util.py", line 376, in import_app
    __import__(module)
ModuleNotFoundError: No module named 'wsgi'

Le seul endroit où je trouve une trace de mon clic, c'est dans le fichier /var/log/apache2/other_vhosts_access.log avec : urlgeonature:443 monadresseip - - [21/Jul/2021:13:55:07 +0000] "POST /api/auth/login HTTP/1.1" 403 1024 "https://urlgeonature/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.164 Safari/537.36"

J'ai remplacé mon URL par "urlgeonature".

geobrun commented 3 years ago

Précision supplémentaire : rien n'apparaît dans les logs de usershub/var/log. Étant donné qu'une erreur 403 apparaît bien dans other_vhosts_access.log mais pas dans les logs de Usershub, j'en conclue qu'Apache récupère bien la requête envoyée par le navigateur mais oppose une fin de non recevoir, sans la transmettre à Usershub. Il doit donc y avoir quelque chose qui coince entre Apache et Usershub ?

geobrun commented 3 years ago

Quelques petites avancées : j'ai bien vérifié, je n'ai pas le même message d'erreur quand je tape un mauvais mot de passe dans ma version 2.6.2 et dans ma version 2.7.2. Voilà les détails :

En fouinant sur le net, ça m'orienterait quand même plus vers une erreur python plutôt qu'apache. J'ai donc remis python en 2.7.17 et j'ai basculé python3 en 3.7.11. Lorsque j'ai effectué une nouvelle migration, après le lancement du venv dans le script, j'ai ce message d'erreur qui arrive, au moment de la commande geonature update_module_configuration validation --build=false.

Restarted supervisord
Restarted supervisord
Traceback (most recent call last):
  File "/home/geonatureadmin/geonature/backend/geonature/utils/gn_module_import.py", line 391, in create_module_config
    module_object = TModules.query.filter_by(module_code=module_code).one()
  File "/home/geonatureadmin/geonature/backend/venv/lib/python3.6/site-packages/sqlalchemy/orm/query.py", line 3500, in one
    raise orm_exc.NoResultFound("No row was found for one()")
sqlalchemy.orm.exc.NoResultFound: No row was found for one()

Je n'ai pas installé le module de validation donc je suppose qu'il n'y a pas de problème. Ce qui m'intrigue dans ce message, c'est que je vois que c'est Python 3.6 qui est appelé. Cela signifie que c'est peut-être encore Python 3.6 qui est encore actif par défaut pour le venv. Est-ce que c'est normal ou est-ce que j'ai loupé quelque chose pour que ce soit Python 3.7 qui soit utilisé par le venv ?

TheoLechemia commented 3 years ago

Oui si le venv n'a pas été supprimé il est toujours en 3.6. Il faut le supprimer et le recréer virtualenv -p venv et ensuite réinstaller la commande geonature..

geobrun commented 3 years ago

Ok, c'est que j'avais fini par comprendre ! Par contre, je bloque sur autre chose maintenant. J'arrive à installer python 3.7 dans le venv, mais par contre, j'ai un problème lorsque de l'exécution de la commande pip install -r requirements.txt. Voilà quelques détails de la console.

Building wheels for collected packages: psycopg2, pypnusershub, pypnnomenclature, pypn-habref-api, utils-flask-sqlalchemy-geo, utils-flask-sqlalchemy
  Building wheel for psycopg2 (setup.py) ... error
  ERROR: Command errored out with exit status 1:
   command: /home/geonatureadmin/geonature/backend/venv/bin/python -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-eple6p6b/psycopg2/setup.py'"'"'; __file__='"'"'/tmp/pip-install-eple6p6b/psycopg2/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' bdist_wheel -d /tmp/pip-wheel-w8ivzu93
       cwd: /tmp/pip-install-eple6p6b/psycopg2/
  Complete output (40 lines):
  running bdist_wheel
  running build
  running build_py
  creating build
  creating build/lib.linux-x86_64-3.7
  creating build/lib.linux-x86_64-3.7/psycopg2
  copying lib/_json.py -> build/lib.linux-x86_64-3.7/psycopg2
  copying lib/extras.py -> build/lib.linux-x86_64-3.7/psycopg2
  copying lib/_lru_cache.py -> build/lib.linux-x86_64-3.7/psycopg2
  copying lib/errors.py -> build/lib.linux-x86_64-3.7/psycopg2
  copying lib/_ipaddress.py -> build/lib.linux-x86_64-3.7/psycopg2
  copying lib/extensions.py -> build/lib.linux-x86_64-3.7/psycopg2
  copying lib/__init__.py -> build/lib.linux-x86_64-3.7/psycopg2
  copying lib/pool.py -> build/lib.linux-x86_64-3.7/psycopg2
  copying lib/errorcodes.py -> build/lib.linux-x86_64-3.7/psycopg2
  copying lib/tz.py -> build/lib.linux-x86_64-3.7/psycopg2
  copying lib/compat.py -> build/lib.linux-x86_64-3.7/psycopg2
  copying lib/_range.py -> build/lib.linux-x86_64-3.7/psycopg2
  copying lib/sql.py -> build/lib.linux-x86_64-3.7/psycopg2
  running build_ext
  building 'psycopg2._psycopg' extension
  creating build/temp.linux-x86_64-3.7
  creating build/temp.linux-x86_64-3.7/psycopg
  x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fdebug-prefix-map=/build/python3.7-LSlbJj/python3.7-3.7.11=. -fstack-protector-strong -Wformat -Werror=format-security -g -fdebug-prefix-map=/build/python3.7-LSlbJj/python3.7-3.7.11=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DPSYCOPG_VERSION=2.8.5 (dt dec pq3 ext lo64) -DPG_VERSION_NUM=100017 -DHAVE_LO64=1 -I/home/geonatureadmin/geonature/backend/venv/include -I/usr/include/python3.7m -I. -I/usr/include/postgresql -I/usr/include/postgresql/10/server -c psycopg/psycopgmodule.c -o build/temp.linux-x86_64-3.7/psycopg/psycopgmodule.o -Wdeclaration-after-statement
  In file included from psycopg/psycopgmodule.c:28:0:
  ./psycopg/psycopg.h:35:10: fatal error: Python.h: No such file or directory
   #include <Python.h>
            ^~~~~~~~~~
  compilation terminated.

  It appears you are missing some prerequisite to build the package from source.

  You may install a binary package by installing 'psycopg2-binary' from PyPI.
  If you want to install psycopg2 from source, please install the packages
  required for the build and try again.

  For further information please check the 'doc/src/install.rst' file (also at
  <https://www.psycopg.org/docs/install.html>).

  error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
  ----------------------------------------
  ERROR: Failed building wheel for psycopg2

Et plus loin : WARNING: You are using pip version 20.0.2; however, version 21.1.3 is available.

Problème sur ma version de pip ?

geobrun commented 3 years ago

Ok, l'erreur ne venait pas de pip directement. Il me manquait juste un paquet pour pouvoir compiler psycopg2que j'ai installé via la commande sudo apt install python3.8-dev.

Dans le fichier migration.sh, j'ai remplacé python3 -m virtualenv -p $python_path venv par virtualenv -p python3.7 venv.

Après ça, j'ai relancé ce script. Plus de rouge ! Mais il me reste encore une erreur, a priori lors de l'exécution de la commande geonature update_configuration --build=false : 

Update app configuration
Traceback (most recent call last):
  File "/usr/bin/supervisorctl", line 6, in <module>
    from pkg_resources import load_entry_point
  File "/home/geonatureadmin/.local/lib/python3.7/site-packages/pkg_resources/__init__.py", line 3242, in <module>
    @_call_aside
  File "/home/geonatureadmin/.local/lib/python3.7/site-packages/pkg_resources/__init__.py", line 3226, in _call_aside
    f(*args, **kwargs)
  File "/home/geonatureadmin/.local/lib/python3.7/site-packages/pkg_resources/__init__.py", line 3255, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/home/geonatureadmin/.local/lib/python3.7/site-packages/pkg_resources/__init__.py", line 568, in _build_master
    ws.require(__requires__)
  File "/home/geonatureadmin/.local/lib/python3.7/site-packages/pkg_resources/__init__.py", line 886, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/home/geonatureadmin/.local/lib/python3.7/site-packages/pkg_resources/__init__.py", line 772, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'supervisor==3.3.1' distribution was not found and is required by the application

Un problème sur le supervisor maintenant ?

bouttier commented 3 years ago

Je pense qu’il y a une différence entre la version de python de supervisor (probablement python 3.6 car par défaut pour ubuntu 18.04) et la version de python lancé par « python3 » (probablement python3.7). Il faudrait par exemple mettre à jour la première ligne du fichier /usr/bin/supervisorctl pour indiquer #!/usr/bin/env python3.6 mais c’est assez du bidouillage …

geobrun commented 3 years ago

Oui, c'est ce que je suis en train de comprendre. Du coup, j'ai maintenant python en version 2.7.17 et python3 en version 3.7.11. Du coup, avec cette configuration, la migration se passe visiblement bien. Quand je lance la commande sudo supervisorctl restart all, maintenant, GeoNature fonctionne et je peux me logger mais plus Usershub ni Taxhub ! Est-ce que ce serait dû au passage de python 3.6 au 3.7 pour seulement GeoNature ?

geobrun commented 3 years ago

Ok, j'ai réussi à redémarrer Taxhub et Usershub en les réinstallant. Du coup, tout le monde tourne et les routes qui ne fonctionnaient pas hier refonctionnent. Et miracle, on dirait que la mise à jour a fonctionné puisque j'ai accès à la création des champs additionnels !

J'ai encore un problème mineur une fois connecté dans GeoNature. Quand je lance la page de login, j'ai cette erreur qui apparaît (elle était déjà présente hier il me semble). Chargement de GeoNature : GET https://urlgeonature/api/gn_commons/modules renvoie {"code": 401, "description": "No token.", "name": "Unauthorized"}

Dans le log d'Apache, je trouve ça.

[Thu Jul 22 14:35:37.529707 2021] [proxy:error] [pid 16625:tid 140432335955712] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:8080 (127.0.0.1) failed
[Thu Jul 22 14:35:37.529761 2021] [proxy_http:error] [pid 16625:tid 140432335955712] [client adresseip:14848] AH01114: HTTP: failed to make connection to backend: 127.0.0.1

Ensuite, quand je me connecte, je me retrouve avec une interface un peu "moche". Les fonctionnalités ont l'air ok mais le design n'est plus aussi léché qu'avant et le logo de notre Pnr est caché en plein milieu.

Je pense que la dernière manipulation indiquée par @bouttier aurait pu fonctionner. Finalement, j'ai opté pour une solution moins bidouille si je puis dire. Petit résumé pour une migration presque fonctionnelle sous Ubuntu 18.4 :

Vivement l'année prochaine que je migre notre GeoNature sous Debian pour éviter tous ces petits soucis ! Je clorai le sujet la semaine prochaine après avoir vérifié que tout fonctionne. Si quelqu'un a des informations pour mon petit problème d'affichage, je suis preneur !

geobrun commented 3 years ago

Je reviens sur mon problème d'affichage. A priori, c'est seulement le bandeau de login du haut qui pose problème. Les éléments du bandeau gris semblent s'être insérés dans le fond bleu (même problème sur Firefox et Chrome). Je mets deux impressions d'écran : la première de ma version 2.6.2 qui va bien et une seconde de la version 2.7.2 qui a un souci.

geonature_2_6_2

geonature_2_7_2

Une idée ? N'hésitez pas à me dire s'il faut que j'ouvre un second sujet pour ce problème.

DonovanMaillard commented 3 years ago

Bonjour,

Ca a l'air d'être un simple soucis de CSS non chargé ou de règles qui ne sont pas appliquées. Dans la dernière version le fichier custom.scss a changé de place,il faut aller controler ses règles et les tenir à jour.

geobrun commented 3 years ago

Ok, c'est ce que je viens de voir. C'est simplement la taille de l'image qui pose problème, donc je vais l'uploader à la bonne taille sur le serveur. Merci !

camillemonchicourt commented 3 years ago

Globalement, j'ai l'impression que le fait d'être sur un Ubuntu 18 a créé pas mal de soucis. En effet, on supporte et teste vraiment Debian (version 10 actuellement). Les installations sur Ubuntu fonctionnant mais utilisées uniquement par les développeurs, pas sur les serveurs en production.

C'est une erreur de notre part d'avoir laissé dans la doc, la possibilité de faire tourner GeoNature sur Ubuntu 18. Mais clairement pour être sur le même environnement que celui qu'on maintient et teste, il faut être sur Debian 10.

Donc je te conseille fortement d'être sur le bon environnement, donc d'installer un GeoNature sur un Debian 10, bien propre et d'y migrer tes données pour ne plus avoir de soucis.

DonovanMaillard commented 3 years ago

Oui, surtout si le serveur ne comporte que GeoNature. la migration vers une nouvelle machine devrait être à peine plus longue que la résolution des bugs pour cette seule mise à jour

geobrun commented 3 years ago

Oui @DonovanMaillard, c'est ce que je me sui dis après coup...

Pour migrer vers Debian, le plus simple est d'installer un GeoNature neuf, de faire un backup de ma base actuelle (je suis avec un postgresql 10 et non 12) et de réimporter tout le backup ? Ou est-ce qu'il vaudrait mieux conserver la base de données neuve et ne réimporter que quelques tables/schémas ?

DonovanMaillard commented 3 years ago

Oui, le plus simple est :

Le passage de postgres10 à 12 ne devrait pas poser de soucis je pense

geobrun commented 3 years ago

Ok, merci pour les informations ! Je ferme le sujet.