PrimtuxMenu : vers l'infini et au delà

[Philippe Dpt35]

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:app

et c'est sur ce port que j'ai bien accès à mon application test par le réseau.
Le 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.

[mothsart]

Le mieux c'est de lire leur doc pour le déploiement : https://www.uvicorn.org/deployment/#runn...hind-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.

[mothsart]

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).

[mothsart]

et servir les fichiers statiques (css, js, images, polices etc.) uniquement par nginx.

[mothsart]

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.

[mothsart]

Pour y voir plus claire sur l'état d'avancement, j'ai maj le CHANGELOG : https://framagit.org/mothsart/primtuxmen...ANGELOG.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.

[Philippe Dpt35]

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.

[mothsart]

Je réussis à lancer l'appli par Nginx.

C'est super ça!

Il me reste à trouver comment faire prendre en charge par Nginx la partie statique.

Je dirais que ça, ça doit suffire

Code :

location ^~ /static/  {
    include  /etc/nginx/mime.types; // permet à nginx de reconnaitre les fichiers à partir de leur mimes types
    root /chemin/; // le chemin qui va correspondre à l'url http://0.0.0.0.:5000/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.

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.

[Philippe Dpt35]

@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=5500

N° de port bien sûr modifiable

Pour que les fichiers statiques passent par Nginx, je m'appuie sur les indications de la doc de uvicorn
https://www.uvicorn.org/deployment/#runn...hind-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 {
    listen 5500;
    location / {
      proxy_set_header Host $http_host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
      proxy_redirect off;
      proxy_buffering off;
      proxy_pass http://uvicorn;
    }
   location /static {
      include  /etc/nginx/mime.types;
      # path for static files
      root /var/www/html/primtuxmenu/static;
    }
}
  upstream uvicorn {
    server unix:/tmp/uvicorn.sock;
  }

puis le lien symbolique

Code :

sudo ln -s /etc/nginx/sites-available/pmenuconf /etc/nginx/sites-enabled

Je lance mon application par

Code :

uvicorn primtuxmenu:app --uds /tmp/uvicorn.sock

L'application se lance bien, mais sans la partie statique.
Si je supprime la partie

Code :

location /static {
      include  /etc/nginx/mime.types;
      # path for static files
      root /var/www/html/primtuxmenu/static;
    }

du fichier /etc/nginx/sites-available/pmenu
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.

[Philippe Dpt35]

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;
sql (get_page) : SELECT id, name, apt_name, generic, prof_icon_path AS icon_path, default_icon_path, prof_path AS path, default_path, in_mini, in_maxi, in_super, in_prof FROM apps WHERE in_prof = 1 LIMIT 0, 10;
sql (count_apps) : SELECT count(id) FROM apps WHERE in_prof = 1;
sql (get_categories) : SELECT id, name, icon_path, level, session, parent_id FROM categories WHERE session = "prof";
INFO:      - "GET / HTTP/1.0" 200 OK

A noter que
location /static/
location ^~ /static/
donnent le même résultat.

[mothsart]

As-tu quelques chose dans :

Code :

tail /var/log/nginx/error.log

Pour ma part, j'ai ajouté la règle dans mon fichier default et ça marche :

Code :

server {
    listen 5500;
    location /static {
      include /etc/nginx/mime.types;
      # path for static files
      root /var/www/html/primtuxmenu;
    }
}

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.

[Philippe Dpt35]

As-tu quelques chose dans :

Code :

tail /var/log/nginx/error.log

J'avais examiné les fichiers log de Nginx, mais je n'avais pas de retour d'erreur sur ces tentatives.

Pour ma part, j'ai ajouté la règle dans mon fichier default et ça marche :

Code :

server {
    listen 5500;
    location /static {
      include /etc/nginx/mime.types;
      # path for static files
      root /var/www/html/primtuxmenu;
    }
}

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.

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.

[Philippe Dpt35]

Bon, là ça marche !

Je remets tout ça dans l'ordre pour la marche à suivre.

[Philippe Dpt35]

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 ?

[mothsart]

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.

[Philippe Dpt35]

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 !

[mothsart]

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.

[Alain]

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

[mothsart]

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.

[mothsart]

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.sock

[Philippe Dpt35]

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.

[mothsart]

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.

[Philippe Dpt35]

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.sync
./sync_db --dev
sql (get_all_apps) : SELECT * FROM apps

sql (get_categories) : SELECT id, name, icon_path, level, session, parent_id, nb_installed_apps, nb_not_installed_apps FROM categories

Traceback (most recent call last):
  File "./sync_db", line 21, in <module>
    sync_to_apt(db, conf, dev)
  File "/home/debian/test-pmenu/primtuxmenu/pmenu/package.py", line 51, in sync_to_apt
    categories = [dict(cat) for cat in list(db.get_categories())]
  File "/home/debian/test-pmenu/primtuxmenu/pmenu/request.py", line 253, in get_categories
    ''' % _where
  File "/home/debian/test-pmenu/primtuxmenu/pmenu/request.py", line 54, in _exec
    result = self.db.execute(request)
sqlite3.OperationalError: no such column: nb_installed_apps
make: *** [makefile:25: db.sync] Error 1

[mothsart]

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.create

puis :

Code :

make db.sync

[mothsart]

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