uWSGI

Vi bruker uWSGI som WSGI-implementasjon for å kjøre diverse Python-baserte nettsider.

Ettersom init.d-scriptet som følger med uWSGIs Debian-pakke spiser opp mye output som er nyttig for debugging, i tillegg til at det er dårlig dokumentert, bruker vi et skreddersydd uWSGI-oppsett basert på et eksempel i uWSGI-dokumentasjonen. Dette oppsettet bruker en systemd-unit-template til å lage en systemd-tjeneste per instans.

uWSGI bruker to konfigurasjonsfiler per instans; den ene, /etc/uwsgi/default.ini, brukes for å forhindre at unødvendig output logges til syslog (f. eks HTTP-forespørsler). I tillegg brukes en instansspesifikk konfigurasjonsfil. Disse konfigurasjonsfilene ligger i /etc/uwsgi/apps-available. Dersom en uWSGI-instans skal aktiveres, må konfigurasjonsfilen i /etc/uwsgi/apps-available symlenkes til /etc/uwsgi/apps-enabled.custom.

Hvordan opprette en ny instans

Opprett først en ny konfigurasjonsfil i /etc/uwsgi/apps-available, for så å symlenke den til /etc/uwsgi/apps-enabled.custom. Husk å sette rett «plugin» og å velge en unik unix-socket i http-socket -feltet, som må være den samme som satt i apache-configen og ligge i en mappe som brukeren i uid har tilgang til. Deretter må systemd-tjenesten aktiveres:

 sudo systemctl enable uwsgi-custom@<navn på uWSGI-konfigfil uten .ini>.service

Tjenesten kan så startes ved å kjøre

 sudo systemctl start uwsgi-custom@<navn på uWSGI-konfigfil uten .ini>.service

Instansen kan deretter f.eks. startes på nytt ved å kjøre

sudo systemctl restart uwsgi-custom@<navn på uWSGI-konfigfil uten .ini>.service

Trenger du mot formodning å starte om alle uwsgi-instansene på nytt kan du kjøre

sudo systemctl restart uwsgi-custom@*

For utviklingsformål kan man gjerne legge til

 py-autoreload = 1

i konfigfilen din. Ikke legg til dette i default.ini uten videre.

Hvis instansen må lage en ny mappe i /var/run/uwsgi for å ha uwsgi-socketen sin der må du lage en local.conf i /etc/systemd/system/uwsgi-custom@<instans-navn>.service.d/ for å sette riktig gruppe på systemd-tjenesten (kok en annen local.conf for å se syntax). Dette skal være en gruppe der kun brukeren som er satt i ini filen er medlem. Dette gjelder per nå ikke hvis brukeren allerede er med i uwsgi-users

Av sikkerhetsgrunner er det også viktig å sette uid og gid i configen til riktig bruker avhengig av hvilken side det er snakk om, eks uka sider er uid=uka-httpd, og gid=uka-web, tilsvarende for ufs er uid=ufs-httpd, og gid=ufs-web. Dette er fordi vi ikke vil ha uwsgi instanser kjørende som din personelige bruker siden denne har sudo tilgang.

Da må du også passe på at gruppen, eks uka-web har lesetilgang til kildekoden. NB kun gruppen uka-web skal ha lesetilgang, ikke uka-httpd.

Hvordan slette en gammel instans

Først må tjenesten stoppes:

 sudo systemctl stop uwsgi-custom@<navn på uWSGI-konfigfil uten .ini>.service

Deretter kan den deaktiveres:

 sudo systemctl disable uwsgi-custom@<navn på uWSGI-konfigfil uten .ini>.service

Feilsøking

Dersom instansen ikke starter, vil feilmeldinger bli håndtert av systemd og kan dermed leses ved hjelp av journalctl eller systemctl.

Etter at instansen har startet, vil alt (inkludert stderr og stdout) logges i /var/log/uwsgi/app/<navn på uWSGI-konfigfil uten .ini>.log, eller /var/log/uwsgi/app/default.log dersom «logto» ikke er spesifisert.

Kataloger for unix-sockets

Uwsgi-appserverne bruker unix sockets for å kommunisere med apache. Hver uwsgi-instans har en socket som opprettes automatisk når tjenesten starter, og socketen opprettes i tjenestens RuntimeDirectory, /var/run/uwsgi/<instans-navn>. Katalogen kan som default skrives til av brukerne i gruppa uwsgi-users, men dette er endret for nettsidene våre i produksjon i /etc/systemd/system/uwsgi-custom@<instans-navn>.service.d/ slik at kun den tilhørende webbrukeren kan skrive til katalogen.

Lenker: Start, uka-no, hvordan utvikle