Esecuzione di xinc sul server Apache di OpenBSD

Question

Qualcuno è riuscito a far funzionare xinc correttamente con l'Apache predefinito in chroot di OpenBSD?Mi piacerebbe mantenere il nostro server di sviluppo in esecuzione completamente in chroot, proprio come il nostro server di produzione, in modo da assicurarci che il nostro codice funzioni perfettamente in chroot.

Answer 1

Hai postato il problema su Xinc localizzatore di bug?Xinc stesso dovrebbe funzionare correttamente poiché funziona sia come demone che come app Web.Come hai accennato, il problema potrebbe essere che il demone non è in esecuzione in un ambiente chroot dove si trova l'interfaccia web, il che porta entrambe le parti a non catturare i file.

Answer 2

@dragonmantank

Nel caso di Xinc, spero che tu abbia usato PEAR per installarlo.

pear list-files xinc/Xinc

Questo dovrebbe farlo e mostrarti dove la tua installazione Xinc ha messo i suoi file.Quindi, anche se Xinc è "solo" un grande script PHP, è comunque suddiviso in script rc e tutte quelle altre cose necessarie per far funzionare un'applicazione.Sono sicuro che non è necessario aggiungere tutti i percorsi elencati lì, ma probabilmente alcuni per farlo funzionare.

A parte Xinc stesso, penso che abbia bisogno anche di phpUnit e di un sacco di altre librerie PEAR per funzionare, quindi quello che proporrei è questo:

pear config-get php_dir

E poi devi aggiungere quel percorso (come suggerito da Henrik) all'ambiente chroot.

Answer 3

Non avendo mai usato xinc, posso solo suggerire come di solito utilizzo le app in chroot.

Il primo passo sarebbe raccogliere informazioni su tutto ciò di cui l'app ha bisogno per funzionare;questo di solito lo realizzo correndo sistema(1) E ldd(1) per scoprire cosa è necessario per eseguire il software.

Passa attraverso l'output di

systrace -A -d. <app>
ldd <app>

e assicurati che tutto ciò che l'app tocca e di cui ha bisogno (molte app toccano cose di cui non ha effettivamente bisogno) sia disponibile nell'ambiente chroot.Potrebbe essere necessario modificare leggermente le configurazioni e le variabili di ambiente.Inoltre, se c'è un'opzione per avere il registro dell'app su syslog, di solito lo faccio e creo un socket syslog (vedi l'opzione -a di syslogd(8)) per ridurre i luoghi a cui l'app necessita dell'accesso in scrittura.

Quello che ho appena descritto è un modo generico per far funzionare praticamente qualsiasi programma in un ambiente chroot (tuttavia, se hai bisogno di importare metà dello spazio utente e alcuni comandi suid, potresti voler semplicemente non eseguire chroot :).Per le app in esecuzione su Apache (sono sicuro che sei consapevole che OpenBSD httpd(8) è leggermente diverso) hai la possibilità (una volta avviato il programma;eventuali librerie dinamiche devono ancora essere presenti nella jail) di utilizzare apache per accedere ai file, consentendo l'uso di httpd.conf per importare risorse nell'ambiente chroot senza effettivamente copiarle.

Anche utile (anche se leggermente obsoleto) lo è Questo link, delineando alcuni trucchi nel PHP in chroot su OpenBSD.

Answer 4

Il primo passo sarebbe raccogliere informazioni su tutto ciò di cui l'app ha bisogno per funzionare;questo di solito lo realizzo eseguendo systrace(1) e ldd(1) per scoprire cosa è necessario per eseguire il software.

Ci proverò.Il grosso problema che ho riscontrato con xinc è che pur essendo un'applicazione PHP, vuole conoscere i percorsi di installazione dell'applicazione (eppure diffonde comunque materiale in altre cartelle) ed esegue alcuni script PHP in modalità demone (quelli script sono i più difficili da mettersi a correre).Quindi, ad esempio, gli ho detto di installarlo su /var/www/xinc e poi ho creato un collegamento simbolico di

/var/www/var/www/xinc -> /var/www/xinc

e parzialmente ha funzionato.Ho fatto in modo che la GUI si attivasse ma si rifiutava di riconoscere qualsiasi progetto che avevo impostato.Penso che il problema più grande sia che una parte esegue un chroot e l'altra metà esegue all'esterno.

Se tutto il resto fallisce, dovrò semplicemente costruire qualcosa mentre programmiamo all'interno di ambienti chroot poiché la nostra produzione è chroot.Ci siamo imbattuti in problemi in cui codifichiamo al di fuori di un chroot e poi dobbiamo tornare indietro per trovare ciò di cui abbiamo bisogno per farlo funzionare all'interno di un chroot.