Forum libero

ho provato un sacco di cose, ho pensato che forse la direttiva server_name lo stava confondendo, non ho un dominio quindi ho usato gli ip dovunque ma poi ho scritto nel files hosts del mio laptop la entry per mappare l'ip e accedevo dal browser scrivendo quel nome nella barra con ort1 o ort2, dall'error log di nginx ho visto che la richiesta GET era fatta con "host: IP oppure mapping di /etc/hosts sul mio laptop" e forse processando la richiesta si confondeva, sarebbe strano il fatto che wordpress continua ad andare ed infatti il problema non sta li, ho provato diverse configurazioni ed il risultato e' sempre quello.

ho ricontrollato i permessi mille volte, sono identici sia nelle roootdoc che nei sock sia per wordpress sia per mediawiki, wordpress lo serve senza battere ciglio, mediawiki da sempre un 403.

le ho provate tutte, ho provato a mettere 3 server in listening su 3 porte (di cui 2 non raggiungibili da fuori la nat, che e' cmq una config interessante che mi permetterebbe di esporre all'internetto solo una porta con un webserver per servire due siti) uno dei quali di fatto reindirizzava le richieste a seconda del server_name, funzionava per wordpress ma wikimedia continua con un 403.

merd questo problema non riesco proprio a risolverlo. di solito prima di esaurire i tentativi che mi vengono in mente trovo la soluzione e se cmq non ce la faccio me ne vengono in mentre altri leggendo la documentazioni, ho passato ore sul sito di enginics ma niente.

in passato ho realizzato che ansible ti puo fottere, nel senso che e' un coso che gestisce gli stati della macchina target e bisogna un minimo entrare in questa logica altrimenti non succede quello che vorresti, nei file di playbook, che in realta' non sono script, scrivi delle dichiarazioni di stati legate a dei moduli (yum: name=packet state=installed o anche unarchive: src=/path dest=path module_options=) ansible leggendo il playbook per ogni modulo crea un coso python, via ssh lo mette sulla target machine e poi glielo fa eseguire, il coso python e' il vero e proprio script e si gestisce lui la logica dello stato.

uno avvia il playbook e per ogni task il risultato puo essere ok=changed ok=unchanged failed=error.
Questa cosa in passato mi ha fottuto cosi:

il modulo template copia dei file dal playbook alla target machine, parsa le variabili dal file nel template prendendosele dal template stesso e poi cerca sulla target machine il file specificato, se non c'e' un file con lo stesso nome con l'aggiunta di .default allora lo crea e poi copia il file dal template, se invece esiste un file con lo stesso nome con l'aggiunta di .default allora fa l'md5 dei due file (non quello con l'estensione.default, i due con lo stesso nome), e se sono diversi lo riscrive, senno da ok=unchanged, perche' il file sula target machine esiste, non e' quello di default di sistema (se uno fa le cose nell'ordine giusto) ed e' identico a quello che uno aveva specificato nel playbook.

se uno usa cambia la struttura del proprio template e fa multiple run di diverse versioni del playbookk sulla stessa target machine puo incasinarsi, nel mio caso ho aggiunto il file di configurazione di mediawiki per nginx modificando la struttura del template, il risultato ora e':

nginx.conf
nginx.conf.default
conf.d/wordpress.conf
       mediawiki.conf

solo che in run precedenti il template generava questo risultato:

nginx.conf
conf.d/default.conf

(conf.d di default e' vuoto)

e questo default.conf conteneva le impostazioni per il server block di wordpress in una versione precedente del playbook, dopo la mia modifica e la rerun del playbook i file di configurazione sulla macchina erano tre, non due come nel mio secondo template:

nginx.conf
nginf.conf.default
conf.d/default.conf
       mediawiki.conf
       wordpress.conf

il modulo template non puo sapere che io avevo eliminato il file default.d da una run ad un altra ed avevo smesso di chiamarlo nel playbook, quindi non lo aveva tolto dalla target machine e nginx si parsava anche il vecchio file di conf.

di questo me ne ero accorto subito perche' nginx non partiva per via di un errore nel file di conf, default.conf e wordpress.conf generavano server duplicati perche' di fatto contenevano lo stesso server block.

forse pero' e' successo qualcosa del genere, quindi rimuovero' un po di complessita' per capire come mai ho quel 403 e quindi penso che piallero' la macchina e ricomincero facendomi le installazioni a manina per vedere se avevo perso qualche messaggio di erorre facendo tutto con ansible e se non sono incappato in qualche errore del genere.
all'inizio feci cosi', ma poi ho modificato il playbook e aggiunto l'installazione di mediawiki senza prima farla a mano per vedere se andava tutto.

**Modificato dall'autore il 01.08.2017 12:38**