Distribuzione FUSS » Octofuss » octonet

Ricordarsi di esplicitare la dipendenza da python3-django >= 1.8, che viene da backports, altrimenti con la 1.7 standard di jessie ci sono problemi (non compatibile)

Documentazione di riferimento: https://wiki.debian.org/DjangoPackagingDraft

Documentazione di riferimento:

• https://wiki.debian.org/DjangoPackagingDraft
• https://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html
• https://wiki.debian.org/Python/Pybuild

Anche http://meetbot.debian.net/debian-women/2010/debian-women.2010-12-02-20.02.log.html dalla posizione 20:33:07

Rileggendo anche la descrizione del ticket, mi ero dimenticato l'altro giorno dell'aspetto dei firewall: dobbiamo metterlo in ascolto su 13402, e poi forniamo il pezzo per apache2/conf.d per il reverse proxy dal vhost 'octofuss'. Ma almeno e' accessibile da entrambi i canali.

Per il deploy, gunicorn3 funziona molto bene, e ha il suo supporto (gunicorn3-debian e relativa conf.d) per fornire snippet di configurazione per l'avvio/stop del servizio

Per riferimento: https://wiki.debian.org/Apache/PackagingFor24

Christopher R. Gabriel, non trovo il pacchetto gunicorn3-debian. Mi puoi mandare uno snippet di configurazione d'esempio per lo start/stop di un servizio django?

Sull'attuale testing, nessuno di quei due pacchetti contiene gunicorn3-debian. L'ho cercato anche in packages.debian.org ma non trovo un pacchetto che lo fornisca.

Intanto, in 6bbb795f ho aggiunto una unit di systemd per far partire il server via gunicorn3.

Hai uno snippet di apache pronto per fare il reverse proxy, da qualche altro progetto?

Enrico Zini ha scritto:

Sull'attuale testing, nessuno di quei due pacchetti contiene gunicorn3-debian. L'ho cercato anche in packages.debian.org ma non trovo un pacchetto che lo fornisca.

Ti rammento che l'attuale target e' stable, incluso backports:

cgabriel@filippone ~ $ apt-cache policy python3-debian gunicorn3
python3-debian:
  Installed: 0.1.27
  Candidate: 0.1.27
  Version table:
 *** 0.1.27 0
        500 http://httpredir.debian.org/debian/ jessie/main amd64 Packages
        100 /var/lib/dpkg/status
gunicorn3:
  Installed: (none)
  Candidate: 19.6.0-2~bpo8+1
  Version table:
     19.6.0-2~bpo8+1 0
        100 http://httpredir.debian.org/debian/ jessie-backports/main amd64 Packages

Intanto, in 6bbb795f ho aggiunto una unit di systemd per far partire il server via gunicorn3.

Hai uno snippet di apache pronto per fare il reverse proxy, da qualche altro progetto?

Da altri progetti no, te lo scrivo qui:

<Location /octofuss>
        <Directory /var/lib/FIXME/DIR/WITH/CODE>
                Options -Indexes
                AllowOverride None
                Require all granted
        </Directory>

        Alias /static/ /var/lib/FIXME/PATH/TO/COLLECTED/STATIC
        ProxyPass /static !
        ProxyPass / http://127.0.0.1:13402/
        ProxyPassReverse / http://127.0.0.1:13402/
        ProxyPreserveHost On

</Location>

da testare poi, scritto a braccio. Lo snippet da piazzare direi in /etc/apache2/conf.d/

https://packages.debian.org/search?searchon=contents&keywords=gunicorn3-debian&mode=exactfilename&suite=stable&arch=any
mi dice:
"You have searched for files named gunicorn3-debian in suite jessie, all sections, and all architectures. Sorry, your search gave no results"

Ad ogni modo, sembra basti systemd.

Non so che dirti, guarda qua su stable:

natalia:~# dpkg -S gunicorn3-debian 
gunicorn3: /usr/share/man/man8/gunicorn3-debian.8.gz
gunicorn3: /usr/sbin/gunicorn3-debian

natalia:~# apt-cache policy gunicorn3
gunicorn3:
  Installed: 19.6.0-2~bpo8+1
  Candidate: 19.6.0-2~bpo8+1
  Version table:
 *** 19.6.0-2~bpo8+1 0
        100 http://httpredir.debian.org/debian/ jessie-backports/main i386 Packages
        100 /var/lib/dpkg/status
natalia:~# 

Forse packages non cerca in backports?

Confermo, al momento esiste solo in backports. Il nuovo gunicorn dice questo:

$ cat /usr/share/doc/gunicorn/README.Debian
README.Debian for gunicorn
==========================

The /etc/gunicorn.d (and related usr/sbin/gunicorn{,3}-debian) scripts were
removed in 19.6.0-3 due to inflexibility, lack of documentation, not
adopted/supported upstream, did not work with virtualenvs, etc.

They were dropped prior to the stretch release to avoid having to support it
for another full release.

Users relying on this feature should invoke gunicorn manually. For an example
systemd .service file, please see the ``gunicorn-mysite.service`` file in the
gunicorn-examples package or a process manager such as runit, etc.

 -- Chris Lamb <lamby@debian.org>  Thu, 06 Oct 2016 19:45:15 +0100

Quindi direi che possiamo stare sulla configurazione di systemd che ho già fatto e funziona.

Ottimo! Allora non vedo l'ora di poterla usare cosi' elimino gunicorn3-debian :D

In e7ee27dc ho aggiunto una configurazione iniziale per apache. Ha due problemi:

1. se il modulo proxy_http non è attivo, non parte. Non ho trovato ancora un modo per far attivare il modulo mod_proxy_http all'installazione del pacchetto. Lo aggiungo alla checklist.
2. django è fatto per girare come http://sito/ e non come http://sito/octonet/. Questo vuol dire che se al momento vado su http://localhost/octonet lui mi ridirige su http://localhost/login/?next=http%3A//localhost/.

Per risolvere il secondo punto, la soluzione consigliata è fare un NameVirtualHost http://octonet.sito, però significa che in fase di deploy c'è da assicurarsi che il dominio risolva, e da chiedere il nome del dominio per metterlo nel file.

In alternativa, si cambia il root urlconf per avere tutto sempre sotto a /octonet. Procedo con questa seconda ipotesi?

Ho risolto il punto 2 con FORCE_SCRIPT_NAME: https://docs.djangoproject.com/en/1.8/ref/settings/#force-script-name

Cosí va da apache, ma genera URL sbagliati se uno visita direttamente http://localhost:13402/

Al momento non ho idea se sia possibile far andare entrambi

...forse pastrugnando con un middleware? Bisogna vedere come django gestisce FORCE_SCRIPT_NAME, e se vale la pena lavorare per far andare entrambi i casi.

Ora gestisce anche gli static file. Manca solo attivare mod_proxy e mod_proxy_http a tempo di installazione.

Riguardo a mod_proxy, ho cercato un po' e ho trovato questo:

enrico> codehelp: I'm studying lava-server's debian/ dir because I have a similar case at hand (django website to be packaged deployed with gunicorn3 and mod_proxy). How do you make sure mod_proxy and mod_proxy_http are loaded by apache?
enrico> codehelp: (if you do)
codehelp> enrico: not part of the packaging - it's a documented installation step
enrico> codehelp: ack, thanks

"A documented installation step" conflitta con la richiesta di avere octonet che è installato e va.

Vuoi che aggiunga una domanda di debconf "attivo mod_proxy?" con default a no, che poi uno lo mette a si coi preseeding, o anche quello è un passo in piú che crea fastidio?

In alternativa, chiamo a2enmod proxy_http in postinst, e il pacchetto avrà il side effect che se lo installo e lo purgio, mi ritrovo con mod_proxy attivo in apache.

gunicorn non supporta il servire file statici, e Django in teoria nemmeno a meno di non fare una porcheria: http://stackoverflow.com/questions/12800862/how-to-make-django-serve-static-files-with-gunicorn

In alternativa si può dipendere da WhiteNoise (http://whitenoise.evans.io/en/stable/), che però non c'è in jessie.

Farli servire a django direttamente, aggiungendo

from django.contrib.staticfiles.urls import staticfiles_urlpatterns
urlpatterns += staticfiles_urlpatterns()

Visto il tipo di deploy, non lo vedo problematico, no?

Uploadati backport di python-whitenoise e python3-whitenoise nel nostro repository reprepro.

Messi anche nel repository FUSS, che e' quello che viene utilizzato

Altra documentazione di riferimento:
https://code.djangoproject.com/wiki/SplitSettings

Fatto usando /etc/octonet.conf come altro nuovo settings.py. All'installazione, viene fatto girare il management command makesecret che genera un SECRET_KEY nel file se non è ancora stato fatto.