In questo documento vengono suddivisi e illustrati ciascuno dei file di configurazione distribuiti in un server dispatcher standard fornito in Adobe Managed Services. Il loro utilizzo, la convenzione di denominazione, ecc…
Convenzione di denominazione
Apache Webserver in realtà non si preoccupa dell'estensione di un file quando lo esegue il targeting con un'istruzione "include" o "include" opzionale. Denominarli correttamente con nomi che eliminano conflitti e confusione aiuta una tonnellata. I nomi utilizzati descrivono l’ambito di applicazione del file, facilitandone la vita. Se tutto si chiama .conf questo diventa molto confuso. Vogliamo evitare file ed estensioni con nomi non corretti. Di seguito è riportato un elenco delle diverse estensioni di file personalizzate e convenzioni di denominazione utilizzate in un dispatcher configurato con AMS tipico.
File contenuti in conf.d/
File | Destinazione file | Descrizione |
---|---|---|
FILENAME.conf | /etc/httpd/conf.d | Un’azienda predefinita Linux install utilizza questa estensione di file e include folder come posizione per sostituire le impostazioni in httpd.conf e consente di aggiungere funzionalità aggiuntive a livello globale in Apache. |
FILENAME.vhost | Staging: /etc/httpd/conf.d/available_vhosts/ Attivo: /etc/httpd/conf.d/enabled_vhosts/ *Nota: I file .vhost non devono essere copiati nella cartella enabled_vhosts, ma usa collegamenti simbolici a un percorso relativo al file available_vhosts/ .vhost |
I file *.vhost (Virtual Host) sono voci VirtualHosts che corrispondono ai nomi host e consentono Apache per gestire il traffico di ogni dominio con regole diverse. Dal file .vhost verranno inclusi altri file come riscritture, whitelist, ecc. |
FILENAME_rewrite.rules | /etc/httpd/conf.d/rewrites/ | I file *_rewrite.rules memorizzano le regole mod_rewrite da includere e utilizzare esplicitamente in un file vhost |
FILENAME_whitelist.rules | /etc/httpd/conf.d/whitelists/ | I file *_ipwhitelist.rules sono inclusi nei file *.vhost. Contiene regex IP o consente regole di negazione per consentire l’inserimento di IP nella whitelist. Se tenti di limitare la visualizzazione di un host virtuale basato su indirizzi IP, genererai uno di questi file e includerlo dal file *.vhost |
File contenuti in conf.modules.d/
File | Destinazione file | Descrizione |
---|---|---|
FILENAME.any | /etc/httpd/conf.dispatcher.d/ | Dispatcher AEM Apache Il modulo le origini sono le impostazioni dei file *.any. Il file di inclusione padre predefinito è conf.dispatcher.d/dispatcher.any |
FILENAME_farm.any | Staging: /etc/httpd/conf.dispatcher.d/available_farms/ Attivo: /etc/httpd/conf.dispatcher.d/enabled_farms/ *Nota: questi file di farm non devono essere copiati nella cartella enabled_farms ma utilizzano collegamenti simbolici a un percorso relativo a available_farms/ file farm.any* i file farm.any sono inclusi nel file conf.dispatcher.d/dispatcher.any . Questi file farm padre esistono per controllare il comportamento del modulo per ciascun rendering o tipo di sito web. I file vengono creati nella directory available_farms e attivati con un link simbolico nella directory enabled_farms. Li include automaticamente per nome dal file dispatcher.any. I file farm della linea di base iniziano con 000 per assicurarti che siano caricati per primi. I file farm personalizzati devono essere caricati dopo avviando lo schema del numero a 100 per garantire il comportamento corretto di inclusione. |
|
FILENAME_filters.any | /etc/httpd/conf.dispatcher.d/filters/ | I file *_filters.any sono inclusi nei file conf.dispatcher.d/enabled_farms/*_farm.any. Ogni farm dispone di un set di regole che cambiano il traffico da filtrare e non da indirizzare ai render. |
FILENAME_vhosts.any | /etc/httpd/conf.dispatcher.d/vhosts/ | I file *_vhosts.any sono inclusi nei file conf.dispatcher.d/enabled_farms/*_farm.any. Questi file sono un elenco di nomi host o percorsi URI che devono essere confrontati con corrispondenze blob per determinare quale renderer utilizzare per elaborare la richiesta |
FILENAME_cache.any | /etc/httpd/conf.dispatcher.d/cache/ | I file *_cache.any sono inclusi nei file conf.dispatcher.d/enabled_farms/*_farm.any. Questi file specificano quali elementi sono memorizzati nella cache e quali no |
FILENAME_invalidate_allowed.any | /etc/httpd/conf.dispatcher.d/cache/ | I file *_invalidate_allowed.any sono inclusi nei file conf.dispatcher.d/enabled_farms/*_farm.any. Specificano quali indirizzi IP sono autorizzati a inviare richieste di scaricamento e di annullamento della validità. |
FILENAME_clientheaders.any | /etc/httpd/conf.dispatcher.d/clientheaders/ | I file *_clientheaders.any sono inclusi nei file conf.dispatcher.d/enabled_farms/*_farm.any. Specificano quali intestazioni client devono essere trasmesse a ogni renderer. |
FILENAME_renders.any | /etc/httpd/conf.dispatcher.d/renders/ | I file *_renders.any sono inclusi nei file conf.dispatcher.d/enabled_farms/*_farm.any. Specificano le impostazioni di IP, porta e timeout per ciascun renderer. Un modulo di rendering appropriato può essere un server livecycle o qualsiasi sistema AEM in cui il dispatcher può recuperare/proxy le richieste da |
Problemi evitati
Seguendo la convenzione di denominazione è possibile evitare alcuni errori abbastanza semplici da commettere che possono avere risultati catastrofici. Vi presenteremo alcuni esempi.
Esempio di problema
Come esempio del sito per ExampleCo, gli sviluppatori delle configurazioni del dispatcher hanno creato due file di configurazione.
/etc/httpd/conf.d/exampleco.conf
VirtualHost *:80 ServerName "exampleco" ServerAlias "www.exampleco.com" … SNIP … IfModule mod_rewrite.c ReWriteEngine su LogLevel warning rewrite:trace1 Include /etc/httpd/conf.d/rewrites/exampleco.conf /IfModule /VirtualHost
/etc/httpd/conf.d/rewrites/exampleco.conf
1
2 | RewriteRule /$ /content/exampleco/en.html PT,L RewriteRule /robots.txt$ /content/dam/exampleco/robots.txt PT,L
PERICOLO POTENZIALE
I nomi dei file sono gli stessi
Se il file vhost viene accidentalmente inserito nella cartella di riscrittura e il file di riscrittura viene inserito nella cartella vhosts. Sembra che sia stato distribuito correttamente dal nome del file, ma Apache genererà un errore e il problema non sarà immediatamente evidente.
In che modo questo diventa generalmente un problema
Se i due file vengono scaricati nella stessa posizione, possono sovrascriversi o renderli indistinguibili rendendo il processo di distribuzione un incubo.
Le estensioni dei file sono le stesse e rischiano l'inclusione automatica
Le estensioni dei file sono le stesse e utilizzano l'estensione inclusa automaticamente che Apache includerà automaticamente tutti i file .conf in molte delle cartelle predefinite.
In che modo questo diventa generalmente un problema
Se il file vhost con estensione .conf viene inserito nella cartella /etc/httpd/conf.d/, tenterà di caricarlo in memoria su Apache che è tipicamente ok, ma se il file delle regole di riscrittura con estensione .conf viene posizionato nella cartella /etc/httpd/conf.d/, verrà incluso automaticamente e applicato globalmente causando risultati confusi e indesiderati.
Denomina i file in base alle loro operazioni e in modo sicuro fuori dallo spazio dei nomi delle regole di inclusione automatica.
Se si tratta di un file host virtuale, denominalo con .vhost come estensione.
Se si tratta di un file di regola di riscrittura, denominalo con site_rewrite.rules come suffisso ed estensione. Questa convenzione di denominazione chiarirà per quale sito si tratta e che si tratta di un insieme di regole di riscrittura.
Se si tratta di un file di regola della whitelist IP, denominalo description_whitelist.rules come suffisso ed estensione. Questa convenzione di denominazione fornisce una descrizione delle funzioni e di un insieme di regole di corrispondenza IP.
L'utilizzo di queste convenzioni di denominazione evita problemi, se un file viene spostato in una directory di inclusione automatica che non appartiene.
Ad esempio, l'inserimento di un file denominato con .rules, .any o .vhost nella cartella di inclusione automatica di /etc/httpd/conf.d/ non avrebbe alcun effetto.
Se una richiesta di modifica della distribuzione riporta “distribuire exampleco_rewrite.rules ai dispatcher di produzione”, la persona che distribuisce le modifiche può già sapere che non sta aggiungendo un nuovo sito, sta solo aggiornando le regole di riscrittura come indicato dal nome del file.
Ordine di inclusione
Quando estendi funzionalità e configurazioni in Apache Webserver installato in Enterprise Linux hai degli ordini di inclusione importanti da comprendere
Apache Include linea di base
Come mostrato nel diagramma sopra il binario httpd cerca solo il file httpd.conf come file di configurazione. Tale file contiene le seguenti istruzioni:
Includi conf.modules.d/.conf IncludeOptional conf.d/.conf |
---|
Include di livello superiore AMS
Quando abbiamo applicato il nostro standard, abbiamo aggiunto alcuni tipi di file aggiuntivi e abbiamo aggiunto alcuni dei nostri.
Di seguito sono riportate le directory della linea di base AMS e gli include di livello superiore
Costruzione ApacheLa linea di base mostra come AMS ha creato alcune cartelle aggiuntive e include di livello superiore per le cartelle conf.d e le directory specifiche del modulo nidificate in /etc/httpd/conf.dispatcher.d/
Quando Apache carica il /etc/httpd/conf.modules.d/02-dispatcher.conf e quel file includerà il file binario /etc/httpd/modules/mod_dispatcher.so lo stato in cui è in esecuzione.
1 | Moduli dispatcher_module /mod_dispatcher.so |
---|
Per utilizzare il modulo nel nostro VirtualHost / rilasciamo un file di configurazione in /etc/httpd/conf.d denominato dispatcher_vhost.conf e all'interno di questo file vedrai come impostare i parametri di base necessari per il funzionamento del modulo:
IfModule disp_apache2.c DispatcherConfig conf.dispatcher.d /dispatcher.any …SNIP… /IfModule
Come puoi vedere sopra, questo include il file di livello superiore dispatcher.any per il modulo dispatcher per raccogliere i file di configurazione da /etc/httpd/conf.dispatcher.d/dispatcher.any
Presta attenzione al contenuto di questo file:
/farms
Il file dispatcher.any di livello superiore include tutti i file farm abilitati presenti in /etc/httpd/conf.dispatcher.d/enabled_farms/ con il nome file di FILENAME_farm.any conforme alla convenzione di denominazione standard.
Più tardi nella dispatcher_vhost.conf file menzionato in precedenza facciamo anche un'istruzione include per abilitare ogni file host virtuale abilitato in /etc/httpd/conf.d/enabled_vhosts/ con il nome del file FILENAME.vhost conforme alla convenzione di denominazione standard.
IncludeOptional /etc/httpd/conf.d/enabled_vhosts/*.vhost
In ciascuno dei nostri file .vhost noterai che il modulo dispatcher viene inizializzato come gestore di file predefinito per una directory. Ecco un esempio di file .vhost per mostrare la sintassi:
VirtualHost *:80 ServerName "weretail" ServerAlias www.weretail.com weretail.com Directory / IfModule disp_apache2.c ....SNIP.... SetHandler dispatcher-handler /IfModule ....SNIP.... /Directory ....SNIP.... /VirtualHost
Una volta che gli “include di livello superiore” risolvono, vale la pena citare altri “sotto-include”. Ecco un diagramma di alto livello su come i file farm e vhosts includono altri sottoelementi
Include host virtuali AMS
Quando qualsiasi file .vhost da /etc/httpd/conf.d/available_vhosts/ la directory viene collegata in modo simbolico /etc/httpd/conf.d/enabled_vhosts/ verranno utilizzati nella configurazione in esecuzione.
I file .vhost dispongono di sottoinsiemi basati su parti comuni che abbiamo trovato. Cose come variabili, whitelist e regole di riscrittura.
Il file .vhost avrà istruzioni di inclusione per ogni file in base a dove devono essere incluse nel file .vhost. Ecco un esempio di sintassi di un file .vhost come buon riferimento:
Include /etc/httpd/conf .d /variables/weretail .vars VirtualHost *:80 ServerName "${MAIN_DOMAIN}" Directory / Include /etc/httpd/conf .d /whitelists/weretail *_whitelist.rules IfModule disp_apache2.c ....SNIP.... SetHandler dispatcher-handler /IfModule ....SNIP.... /Directory ....SNIP.... IfModule mod_rewrite.c ReWriteEngine on LogLevel warn rewrite:trace1 Include /etc/httpd/conf .d /rewrites/weretail_rewrite .rules /IfModule /VirtualHost
Come puoi vedere nell’esempio precedente c’è un include per le variabili necessarie in questo file di configurazione che vengono utilizzate in seguito.
All’interno del file /etc/httpd/conf.d/variables/weretail.vars possiamo vedere quali variabili sono definite:
Definire MAIN_DOMAIN dev.weretail.com
È inoltre possibile visualizzare una riga che include un elenco di file whitelist.rules che limitano gli utenti che possono visualizzare il contenuto in base a diversi criteri di elenchi consentiti. Diamo un'occhiata al contenuto di uno dei file della whitelist /etc/httpd/conf.d/whitelists/weretail_mainoffice_whitelist.rules:
Richiedi ip 192.150.16.0/23 /RequireAny
Puoi anche visualizzare una riga che include un set di regole di riscrittura. Diamo un'occhiata ai contenuti del weretail_rewrite.rules file:
RewriteRule /robots.txt$ /content/dam/weretail/robots.txt NC,PT RewriteCond %{SERVER_NAME} brand1.weretail.net NC RewriteRule /favicon.ico$ /content/dam/weretail/favicon.ico NC,PT RewriteCond %{SERVER_NAME} brand2.weretail.com NC RewriteRule /sitemap.xml$ /content/weretail/general/sitemap.xml NC,PT RewriteRule /logo.jpg$ /content/dam/weretail/general/logo.jpg NC,PT
Include farm AMS
In caso di file FILENAME_farm.any da /etc/httpd/conf.dispatcher.d/available_farms/ la directory viene collegata in modo simbolico /etc/httpd/conf.dispatcher.d/enabled_farms/ verranno utilizzati nella configurazione in esecuzione.
I file di farm dispongono di sotto-elementi in base a sezioni principali dell'azienda come cache, intestazioni client, filtri, render e vhosts.
I file FILENAME_farm.any avranno istruzioni di inclusione per ogni file in base a dove devono essere inclusi nel file di farm. Ecco un esempio di sintassi di un file FILENAME_farm.any come buon riferimento:
/weretailfarm { /clientheaders { $include "/etc/httpd/conf.dispatcher.d/clientheaders/ams_publish_clientheaders.any" $include "/etc/httpd/conf.dispatcher.d/clientheaders/ams_common_clientheaders.any" } /virtualhosts { $include "/etc/httpd/conf.dispatcher.d/vhosts/weretail_vhosts.any" } /renders { $include "/etc/httpd/conf.dispatcher.d/renders/ams_publish_renders.any" } /filter { $include "/etc/httpd/conf.dispatcher.d/filters/ams_publish_filters.any" $include "/etc/httpd/conf.dispatcher.d/filters/weretail_search_filters.any" } ....SNIP.... /cache { ....SNIP.... /rules { $include "/etc/httpd/conf.dispatcher.d/cache/ams_publish_cache.any" } ....SNIP.... /allowedClients { /0000 { /glob "*.*.*.*" /type "deny" } $include "/etc/httpd/conf.dispatcher.d/cache/ams_publish_invalidate_allowed.any" } ....SNIP.... } }
Come puoi vedere ogni sezione per la farm weretail invece di avere tutta la sintassi necessaria, utilizza invece un’istruzione "include".
Diamo un'occhiata alla sintassi di alcune di queste "include" per avere l'idea di come apparirebbe ogni sottoinclusa
/etc/httpd/conf.dispatcher.d/vhosts/weretail_publish_vhosts.any:
"brand1.weretail.com" "brand2.weretail.com" "www.weretail.comf"
Come puoi vedere, si tratta di un nuovo elenco separato da riga di nomi di dominio che deve eseguire il rendering da questa farm sugli altri.
Ora diamo un'occhiata al /etc/httpd/conf.dispatcher.d/filters/weretail_search_filters.anyApache:
/400 { /type "allow" /method "GET" /path "/bin/weretail/lists/*" /extension "json" } /401 { /type "allow" /method "POST" /path "/bin/weretail/search/' /extension "html" }