Percorso preferito per gli eseguibili cgi in Lion Server

OS X essendo un sistema basato su unix, puoi usare la struttura standard del file unix per quello.

In generale, la maggior parte delle distribuzioni unix / linux usano / var / www / per l'archiviazione del server web, si potrebbe immaginare qualcosa come / var / www / html per pagine e media e / var / www / cgi-bin per i file eseguibili cgi.

Ci sono altre posizioni disponibili (/ srv per esempio), vedi questo elenco su wikipedia per una spiegazione sulla directory struttura (se necessaria)

La mia preferenza sarebbe quella di posizionare gli eseguibili CGI comuni a tutto il sistema in /Library/Server/Web/Data/Exec

Alcuni concetti mi sono venuti in mente pensando a quale cartella potrebbe essere la migliore:

1. Evita di memorizzare il mio CGI nel sistema CGI fornito da Apple.

2. Evita di archiviare il mio CGI in una cartella in cui Server Admin e Finder sono nascosti per impostazione predefinita.

   Di minore importanza sono le azioni intraprese da Apple per non spedire più o continuare a nascondere alcune cartelle dalla vista (sono felice di rompere dal lead del fornitore - ma generalmente ho bisogno di una buona ragione per farlo)

3. Non modificare la posizione di Snow Leopard di /Library/WebServer/CGI-Executables (il principio di sysadmin pigro - perché modificare tutto ciò che non è necessario)

4. Minimo sforzo - se devo mettere in moto qualcosa - meno cambiamenti sono migliori.

Sembra chiaro che /Library/Server/Web/Data/Sites conterrà dati che il server Web avrebbe offerto in modo differenziale in base alle esigenze di ciascun sito. Quindi, se il mio sito Orange avesse CGI che era destinato solo a quel sito, potrei memorizzarli in /Library/Server/Web/Data/Sites/Orange/Exec anziché nella posizione "predefinita".

Non vedo una buona ragione per mantenere /Library/WebServer da quando modifico il mio file di configurazione Apache per aggiungere i miei siti - e suppongo che lo vedremo cambiare in un punto di rilascio e vinto devo indovinare.

Ignorerei qualsiasi cartella che era nascosta di default in Finder e Server Manager - quindi per me /private sarebbe fuori. Non sto dicendo che è sbagliato per chiunque immagazzinare cose lì - specialmente se ti risparmia lavoro o intelligenza riutilizzando la struttura del codice da un altro sistema operativo UNIX che non impiega la struttura unica di directory /System e% co_de di Mac OS X.

Rispondere alla mia domanda nel caso in cui la conclusione non fosse chiara. Nessuno ha chiarito perché Apple ha modificato la struttura delle directory per il server web nel server OS X Lion (& Mountain Lion). Tuttavia, per me la domanda saliente era se esistesse una "best practice" location per gli eseguibili web - o una posizione "preferita" come lo ha detto @bmike. La mia conclusione dai numerosi commenti utili e dai miei test è che la scelta della posizione è arbitraria, e quindi ciò che conta come best practice è individuare i file eseguibili del Web in cui sono più adatti al tuo sito, seguendo i criteri e i suggerimenti menzionati dai commentatori .

Per quanto mi riguarda, il mio server è solo un passo verso la posizione finale del mio materiale sul server di qualcun altro o in qualche ISP. Ogni build crea quindi due distinte configurazioni: una per la struttura della directory del mio server di prova (ora Mountain Lion) e l'altra per la struttura di directory in cui verrà distribuita l'app. Tutto il resto è lo stesso.

Quindi ho creato una struttura di directory per il mio server web che rende facile tenere traccia dei miei progetti e registrato i suoi percorsi nel mio sistema di compilazione. Questo aliasing in stile Apache (cioè usando 'cgi-bin' come un alias per la directory degli eseguibili) significa che non mi guarderò più indietro ora che la mia struttura di directory è a posto. Ho appena creato l'app e atterra nel posto giusto per funzionare sul mio server. Quindi questa è la risposta per me.

In un server di produzione, la best practice dovrebbe probabilmente incorporare i suggerimenti dei commentatori sul cambiamento minimo, la sorpresa minima per un manutentore successivo e la persistenza attraverso gli aggiornamenti del sistema. Grazie a tutti.