![]() |
|
PrimtuxMenu : vers l'infini et au delà - Version imprimable +- PrimTux, la distribution éducative (https://forum.primtux.fr) +-- Forum : PrimTux: LA DISTRIBUTION: présentation, aide et développement (https://forum.primtux.fr/forumdisplay.php?fid=5) +--- Forum : Demandes d'évolution - Tests des iso - Développement (https://forum.primtux.fr/forumdisplay.php?fid=10) +--- Sujet : PrimtuxMenu : vers l'infini et au delà (/showthread.php?tid=1441) |
PrimtuxMenu : vers l'infini et au delà - Philippe Dpt35 - 09-09-2020 mothsart a écrit :Je pense que c'est lié au port. Sur ton cas avec Flask, tu ne mentionnes pas de port donc il va partir sur le port 80 et nginx est déjà connecté la dessus par défaut.Non, j'indique bien un port, puisque je lance la commande Code : gunicorn --bind 0.0.0.0:5000 wsgi:appLe port 80, port http par défaut, me donne la page d'accueil de Nginx. Avec uvicorne et Quant, la liaison ne se fait pas avec Nginx. Je la teste bien sur le port 8000 qui est celui indiqué lorsqu'on lance uvicorne. PrimtuxMenu : vers l'infini et au delà - mothsart - 09-09-2020 Le mieux c'est de lire leur doc pour le déploiement : https://www.uvicorn.org/deployment/#running-behind-nginx Il faut que nginx soit plugé sur le socket de uvicorn. Malheureusement (comme beaucoup de truc dans la tech), ce n'est disponible que dans la langue de Shakespeare. PrimtuxMenu : vers l'infini et au delà - mothsart - 09-09-2020 Il faudra aussi quelque chose comme "supervisor" pour relancer automatiquement le serveur si on a un bug serveur critique (bien sur, ça ne devrait pas arriver ).Le mieux (à mon sens) est d'utiliser systemd pour faire ça (le lien précédent en parle pour gunicorn). PrimtuxMenu : vers l'infini et au delà - mothsart - 09-09-2020 et servir les fichiers statiques (css, js, images, polices etc.) uniquement par nginx. PrimtuxMenu : vers l'infini et au delà - mothsart - 10-09-2020 en session prof, il est désormais possible de voir les apps des autres sessions et de filtrer par installés/non installés. Ca a été un peu dev au couteau donc y'a un peu de review à faire et potentiellement des bugs. Je vais avancer sur d'autre sujet et je ferais une passe "qualité" pour résoudre tous les détails... J'ai commencé aussi à garder une trace des actions admin : du coup, il conserve ses params de filtrage par exemple. PrimtuxMenu : vers l'infini et au delà - mothsart - 12-09-2020 Pour y voir plus claire sur l'état d'avancement, j'ai maj le CHANGELOG : https://framagit.org/mothsart/primtuxmenu/-/blob/master/CHANGELOG.md [0.x] représente ce qui a été fait [Unreleased : 0.1] ce qui reste à faire pour un déploiement N'hésitez pas à me dire si il manque des choses ou si certaines vous semble supperflus. Bien entendu, je ne liste ici quasiment que les fonctionnalités et non les bugs. Donc une fois que tout sera atteint au niveau fonctionnel, il faudra bien se donner une fourchette de recette et de correctifs. PrimtuxMenu : vers l'infini et au delà - Philippe Dpt35 - 12-09-2020 De mon côté, j'avance un peu. Je réussis à lancer l'appli par Nginx. Il me reste à trouver comment faire prendre en charge par Nginx la partie statique. Mais je n'ai pas eu trop le temps de m'y consacrer en cette fin de semaine. PrimtuxMenu : vers l'infini et au delà - mothsart - 12-09-2020 Philippe Dpt35 a écrit :Je réussis à lancer l'appli par Nginx. C'est super ça! Philippe Dpt35 a écrit :Il me reste à trouver comment faire prendre en charge par Nginx la partie statique. Je dirais que ça, ça doit suffire Code : location ^~ /static/ {Perso, je procéderais ainsi : 1. je m'assure que quart est coupé 2. je crée un chemin de test pour m'assurer que nginx délivre bien des fichiers statiques : par exemple /var/test/essai.png (je remplace "root /chemin/;" par "root /var/test/;") 3. je regarde que http://0.0.0.0.:5000/static/essai.png me renvoi bien mon image 4. Si tout ce passe bien, je met le chemin avec les vrais donnés statiques du primtuxmenu dans (par exemple) /var/primtuxmenu/static 5. je vérifie que tout est encore en place quand on lance quart et que dans les logs de nginx c'est bien lui qui s'occupe de délivrer les données statiques. Philippe Dpt35 a écrit :Mais je n'ai pas eu trop le temps de m'y consacrer en cette fin de semaine. Pas de prob. Tout ce que tu as fait est du temps gagné pour moi. J'essai de me consacrer uniquement à l'applicatif pour pas trop m'éparpiller. PrimtuxMenu : vers l'infini et au delà - Philippe Dpt35 - 13-09-2020 @mothsart Voici l'état de mon avancement, et ce sur quoi je bute. Je réussis à faire passer l'application par Nginx avec Code : uvicorn primtuxmenu:app --host 0.0.0.0 --port=5500Pour que les fichiers statiques passent par Nginx, je m'appuie sur les indications de la doc de uvicorn https://www.uvicorn.org/deployment/#running-behind-nginx Pour cela, je paramètre Nginx de la façon suivante : je crée un fichier /etc/nginx/sites-available/pmenu avec le contenu suivant Code : server {puis le lien symbolique Code : sudo ln -s /etc/nginx/sites-available/pmenuconf /etc/nginx/sites-enabledJe lance mon application par Code : uvicorn primtuxmenu:app --uds /tmp/uvicorn.sockL'application se lance bien, mais sans la partie statique. Si je supprime la partie Code : location /static {là css et js sont bien pris en compte, mais ils ne sont pas pris directement en charge par Nginx. Je n'arrive pas à faire prendre en compte le chemin des fichiers statiques dans la configuration de Nginx. PrimtuxMenu : vers l'infini et au delà - Philippe Dpt35 - 13-09-2020 Voici les retours de la console avec la partie static dans le fichier de conf : Code : sql (count_apps) : SELECT count(id) FROM apps WHERE in_prof = 1;A noter que location /static/ location ^~ /static/ donnent le même résultat. PrimtuxMenu : vers l'infini et au delà - mothsart - 13-09-2020 As-tu quelques chose dans : Code : tail /var/log/nginx/error.logPour ma part, j'ai ajouté la règle dans mon fichier default et ça marche : Code : server {J'ai mis un fichier au chemin /var/www/html/primtuxmenu/static/script.js et http://0.0.0.0:5500/static/script.js me délivre bien le bon fichier. PrimtuxMenu : vers l'infini et au delà - Philippe Dpt35 - 14-09-2020 mothsart a écrit :As-tu quelques chose dans :J'avais examiné les fichiers log de Nginx, mais je n'avais pas de retour d'erreur sur ces tentatives. mothsart a écrit :Pour ma part, j'ai ajouté la règle dans mon fichier default et ça marche :Je n'ai pas le même comportement chez moi. Avec cette syntaxe, il va en fait chercher dans /var/www/html/primtuxmenu/static et non dans /var/www/html/primtuxmenu Il me faut modifier la ligne en alias /var/www/html/primtuxmenu; pour qu'il aille dans /var/www/html/primtuxmenu Je réétudie la chose avec ce correctif et je te redis. PrimtuxMenu : vers l'infini et au delà - Philippe Dpt35 - 14-09-2020 Bon, là ça marche ! Je remets tout ça dans l'ordre pour la marche à suivre. PrimtuxMenu : vers l'infini et au delà - Philippe Dpt35 - 14-09-2020 Petite question pratique : mes tests ont été faits dans un environnement virtuel Python. En production, vaut-il mieux passer par un environnement virtuel ou non ? PrimtuxMenu : vers l'infini et au delà - mothsart - 14-09-2020 Philippe a écrit :Bon, là ça marche ! Ah, super. J'ai pas d'avis tranché sur la question mais dans l'absolu c'est plus pour de dev : ça permet d'installer une tonne de lib (avec des versions spécifiques pas forcément compatibles avec ceux de ta bécane) sans toucher à ton système. C'est isolé (le terme c'est "sandbox" et comme son nom l'indique, c'est un bac à sable) Donc l'idéal c'est qu'une fois en prod, on ne dépende plus que des libs apt. Maintenant, ça veut dire empaqueter "quart" dans notre paquet ou, encore mieux, créer un paquet pour quart (ça existe peut-être tout fait, j'ai pas creusé) et un pour le primtuxmenu. Le 2ème dépendant du premier. Après, c'est une vision très "Debian". Si c'est trop contraignant pour nous, on peut très bien allé au plus simple voir améliorer dans un second temps. PrimtuxMenu : vers l'infini et au delà - Philippe Dpt35 - 14-09-2020 En revanche, j'ai un problème en dehors de l'environnement virtuel. J'obtiens un bad gateway, et le log m'informe d'un problème de permission. Si je fais un chmod 666 /tmp/uvicorn en ligne de commande, là ça me renvoie un Internal servor error. A mon avis il faut certainement changer les permissions du socket, sans doute dans un fichier de configuration que prendrait en compte uvicorn. Sur la page d'uvicorn, je ne vois pas d'infos sur un éventuel fichier de configuration. Je fais des recherches de ce côté, mais si tu as déjà des idées, je suis preneur ! PrimtuxMenu : vers l'infini et au delà - mothsart - 14-09-2020 Il reste le fait de relancer en auto le serveur si crash : je vais voir pour te créer une URL qui effectue volontairement un crash (une division par zéro par exemple) : si le serveur n'est pas relancé par nginx ou unicorn, c'est qu'il faut passé par un daemon : le plus standard c'est systemd. Aussi, il faudra vérifier qu'on a bien ces erreurs de visible dans les logs de nginx. Je me demande d'ailleurs si il n'est pas possible d'avoir un fichier de logs spécifiques au primtuxmenu : ça éviterais d'avoir un mélange si nginx est utilisé pour autre chose. PrimtuxMenu : vers l'infini et au delà - Alain - 14-09-2020 Bonjour J'avoue que je suis un peu largué... néanmoins une question Est ce que dans cette version nginx est atteignable par les autres postes du réseau ? Alain PrimtuxMenu : vers l'infini et au delà - mothsart - 14-09-2020 Oui Alain, c'est aussi une des utilités de nginx : on peut mettre à dispo sur un réseau local, réseau étendu, internet etc. Ca fait penser qu'il serait aussi bien d'avoir 1 (ou plusieurs) nom de domaine (voir un nom de domaine par session) pour un réseau local. PrimtuxMenu : vers l'infini et au delà - mothsart - 14-09-2020 Pour ton soucis, Philippe : et si tu mets ton socket dans un répertoire ou tu es sur d'avoir les droits ? Code : uvicorn primtuxmenu:app --uds /var/run/uvicorn.sockPrimtuxMenu : vers l'infini et au delà - Philippe Dpt35 - 14-09-2020 J'avais déjà testé, le fichier socket se met automatiquement avec des droits restreints. Et quand je change les droits, ça me renvoie un internal service erreur. J'ai trouvé des discussions à propos du même problème où ils évoquent un fichier de configuration dans lequel il faudrait passer un PrivateTmp à false. Mais je ne trouve aucune trace d'un fichier de configuration pour uvicorn, ni aucune info sur comment en créer un. PrimtuxMenu : vers l'infini et au delà - mothsart - 14-09-2020 Tu as dit plus haut que tant que l'applicatif est dans l'env virtuel, ça fonctionne. Du coup, je pense que le soucis est plutôt lié à ça : il te manque une dépendance (ou ça casse pour une autre raison) et du coup unicorn n'arrive pas à répondre. Nginx n'ayant plus de réponse du proxy, il te balance une erreur 502. PrimtuxMenu : vers l'infini et au delà - Philippe Dpt35 - 15-09-2020 Je repars de zéro sur une nouvelle installation, et la dernière version de primtuxmenu plante lorsqu'on lance un make run avec, dans le navigateur : OperationalError no such column: nb_installed_apps Suit une très longue liste d'indications. Un make db.sync renvoie Code : $ make db.syncPrimtuxMenu : vers l'infini et au delà - mothsart - 15-09-2020 Oui, ça me semble normal : j'ai changé pas mal de chose sur la structure de la bdd et y'a pas encore (avant une version officiel) de script de migration auto. faut faire : Code : make db.createpuis : Code : make db.syncPrimtuxMenu : vers l'infini et au delà - mothsart - 15-09-2020 Effectivement, pour toi et Steph, ça ne présente pas beaucoup d'intérêt. J'ai unifié ces 2 commandes avec : Code : make db.init |