Open JeromeMaruejouls opened 7 months ago
OK merci pour ce retour.
On a fait plusieurs tests d'installation de la 2.13, 2.13.4 etc... avec le script d'installation globale sur du Debian 12 et on n'a pas eu de soucis de droits. Faudrait voir pourquoi tu as eu des soucis.
Oui pour le port c'est identifié que cela ne marche pas automatiquement de le modifier dans la conf (https://github.com/PnX-SI/GeoNature/issues/504), donc améliorable en effet.
Si je reproduis le problème de droit, je posterai les logs avant de corriger de façon brutale comme je l'ai fait là !
Alors voilà le log complet de l'installation :
J'ai remarqué au début d'installation de la base de données des problèmes de droits, mais la base à l'air de bien s'installer qd meme.
Et l'erreur dans les log Apache :
[Thu Jan 11 16:02:37.286415 2024] [core:error] [pid 15138:tid 140316195657408] (13)Permission denied: [client 77.135.203.2:59729] AH00035: access to /geonature/ denied (filesystem path '/home/geonatureadmin/geonature') because search permissions are missing on a component of the path
Comme précisé plus haut, un chmod +x sur le répertoire /home/geonatureadmin résout le problème.
Bonjour,
J'ai fait 2 install sur debian 12 (2.13.3 et 2.13.4). Une sur un VPS OVH, l'autre sur une VM VMWare. Dans les 2 cas, j'ai eu exactement le même soucis que décrit Jérôme. Erreur 403 et correction par un chmod 755
sur le répertoire du user linux. ET surtout pas un chmod -R 755
.
Bizzarement pas de soucis sur UH ni TH. Que sur GN.
Dans 1 cas (OVH), c'est moi qui ai créer l'utilisateur en remplacement du user debian par défaut fourni par le VPS OVH, dans l'autre, il a été créé lors de l'install de l'OS (ce n'est donc pas la manière de créer le user linux qui serait en cause)
J'en ai conclu que depuis Debain 12 les droits sur le répertorie d'un utilisateur sont différents et que qq chose, en lien avec ça, dans la conf apache de GN serait différent de celle de TH et UH
Ce qui est étrange, c'est que Camille dit qu'ils n'ont pas eu le cas...
Bonjour, J'ai fait 2 install sur debian 12 (2.13.3 et 2.13.4). Une sur un VPS OVH, l'autre sur une VM VMWare. Dans les 2 cas, j'ai eu exactement le même soucis que décrit Jérôme. Erreur 403 et correction par un
chmod 755
sur le répertoire du user linux. ET surtout pas unchmod -R 755
.Bizzarement pas de soucis sur UH ni TH. Que sur GN.
Dans 1 cas (OVH), c'est moi qui ai créer l'utilisateur en remplacement du user debian par défaut fourni par le VPS OVH, dans l'autre, il a été créé lors de l'install de l'OS (ce n'est donc pas la manière de créer le user linux qui serait en cause)
J'en ai conclu que depuis Debain 12 les droits sur le répertorie d'un utilisateur sont différents et que qq chose, en lien avec ça, dans la conf apache de GN serait différent de celle de TH et UH
Ce qui est étrange, c'est que Camille dit qu'ils n'ont pas eu le cas...
Testé ce matin, ca fonctionne avec un chmod +x geonatureadin (equivalent à 711) ou un chmod 755 geonatureadin Et de mon coté, c'est un serveur Kimsufi et je crée l'utilisateur geonatureadmin en plus de l'utilisateur debian.
Bonjour à tous, Problème effectivement existant sur raspiOS debian bookworm. Après une installation globale, GN est en forbidden, TH et UH fonctionnent (si le port est laissé en 5432). chmod +x useradmin -->résout bien le soucis. Merci !
Debian est moins laxiste que Ubuntu en terme de sécurité :) En effet, la solution est de changer les droits d’exécution (d'où le +x). Après, quelle est la solution la plus safe par défaut, changer les droits de l'utilisateur ou seulement sur le dossier de geonature généré.
Je ne comprends pas pourquoi il y a ce soucis qu'on n'avait pas avant et pourquoi je ne reproduis pas. Je viens de faire une installation globale de DEVELOP (future 2.14) et je n'ai pas non plus le soucis. 🤔
Ton serveur est vierge ?
Ce que je ne comprends pas c'est pourquoi le soucis ne se manifeste que sur GN et pas sur UH ni TH. Car le répertoire où les droits sont modifiés est le territoire racine du user linux. Donc en amont de UH et TH.
Je me demande si ce n'est pas au niveau Apache. Genre une directive comme le Require all granted ou autre qui manquerait ou serait en trop et que le code de UH ou TH ignore ou ne nécessite pas
J'ai eu le soucis du could not change directory to "/home/geonatureadmin/geonature": Permission non accordée
en installant GN sur un ubuntu vierge cette semaine aussi.
J'ai pas compris d'ou ça venait et ça n'a posé aucun problème sur la suite de l'installation de la base, ni sur l'install globale
Bonjour, J'ai également constaté l'erreur apache sur l'url /geonature (mais ni sur /taxhub ni sur /usershub) après avoir installé geonature à partir du script install_all sur un debian 12 tout neuf. Comme cela a été dit, le problème disparaît après avoir donné des droits de lecture à tous les utilisateurs sur le home dir du compte à partir duquel le script est invoqué (les droits par défaut u+rwx go-rwx ne suffisent pas).
Je pense que l'explication du pourquoi ça marche avec taxhub et usershub et pas avec geonature est que dans le cas taxhub et usershub, c'est gunicorn qui sert les ressources statiques (avec l'identité de l'utilisateur et donc les droits d'accès au home dir) et que dans le cas geonature, c'est apache (avec l'identité www, qui ne permet pas d'accéder aux ressources statiques). Cela voudrait donc dire qu'il y a un souci dans les fichiers apache /etc/apache2/conf-available/taxhub.conf et usershub.conf où le code qui suit doit être incorrect, ou mal placé
Alias "/taxhub/static" "/home/vincent/taxhub/static"
<Directory "/home/vincent/taxhub/static">
AllowOverride None
Require all granted
</Directory>
Si c'est confirmé par un expert apache, il y a donc deux problèmes à résoudre :
Oui bien vu, ta piste d'explication est intéressante. Je ne suis malheureusement pas expert apache non plus. Juste une remarque,
donner à apache les droits d'accès aux ressources sous /home/repertoire_d'installation sans qu'il soit nécessaire d'utiliser chmod
Le problème n'est pas sur le répertoire d'instalaltion /home/linuxuser/geonature mais bien sur /home/linuxuser
le problème disparaît après avoir donné des droits de lecture à tous les utilisateurs
Pour ma part, je ne donne pas des droits de lecture mais d'exécution uniquement (et non récursif) : chmod +x /home/linuxuser/
Il est important de noter aussi que la conf apache n'a pas changé et que ça fonctionnait sur Debian 11. Le changement intervient avec Debian 12 qui ne doit pas gérer les droits du répertoire utilisateur de la même manière.
Bonjour à tous et meilleurs voeux !
Petit retour d'expérience d'une installation et migration de la bdd depuis un serveur Debian 10 avec Postgresql 11 vers un nouveau serveur Debian 12 avec Postgresql 15, en utilisant le script d'installation général (Usershub/Taxhub/Geonature) : (v 2.13.3)
La restauration de la bdd d'un postgres 11 sur un postgres 15 n'a pas l'air de poser de problème ! Je continue mes tests, mais cela simplifie ces mises à jour d'OS.