Konfigurační soubory, které obsahují další soubory, nejsou nové. Od začátku bylo také možné umístit tyto zahrnuté soubory do podadresářů. Pojďme se podívat na případy použití a uvidíme, jak z této organizační metody vytěžit maximum.
Někteří lidé považují jeden konfigurační soubor za "jednoduchý" přístup a celý strom souborů za složitější. Zastavte se však a zamyslete se nad tím, jak velké mohou některé konfigurační soubory narůst nebo kolik různých lidí nebo programů je potřebuje upravit. Skutečně může být snazší umožnit každému podprojektu přenést konfiguraci do vlastního souboru v podadresáři. Nedávno, například v systemd dokumentaci, tyto soubory se někdy nazývají "drop-in" soubory.
Postupem času a zejména v posledních několika letech se používání podadresářů v /etc se zvýšil. Tento pohyb řídí dvě významné situace:
- Větší programy rozdělují složité konfigurační soubory do několika menších souborů.
- Mnoho dalších programů se stalo závislých na jediném nástroji. Každý z těchto nástrojů musí spravovat část konfigurace.
Vyplňte na balíček
Některé z prvních použití *.d adresáře, se kterými jsem se setkal, byly pro protokolování a plánování. Podívejme se na logrotate užitečnost. Hlavní konfigurační soubor je /etc/logrotate.conf . Není to příliš složité, ale každý soubor, který se má otáčet, je potřeba specifikovat. Každý soubor může také vyžadovat různé možnosti konfigurace. Namísto úprav tohoto jediného souboru při každém přidání nebo aktualizaci aplikace v systému oddělujeme konfiguraci pro každou aplikaci do konkrétního souboru.
$ grep ^include /etc/logrotate.conf
include /etc/logrotate.d Hlavní konfigurační soubor obsahuje všechny soubory v jiném adresáři. Soubory v adresáři mohou pocházet z různých RPM balíčků.
$ rpm -qf /etc/logrotate.d/aide
aide-0.16-12.fc31.x86_64
$rpm -qf /etc/logrotate.d/rsyslog
rsyslog-8.2002.0-1.fc31.x86_64
$ rpm -qf /etc/logrotate.d/chrony
chrony-3.5-4.fc31.x86_64
Majitel každého balíčku ví, co je třeba otáčet a jak často. Poskytnou konfigurační soubor specifický pro jejich aplikaci a přidají jej do logrotate.d adresář během instalace. Je také odstraněn z logrotate.d adresář, když je balíček odinstalován ze systému.
Další příklady tohoto případu použití jsou plánování pomocí cron v cron.d adresář a konfigurace ověřování pomocí PAM v pam.d adresář. Při použití samostatných souborů nemusí správce systému spravovat konfliktní zápisy do jednoho souboru.
Uspořádat podle funkce
Webový server Apache je rozsáhlý program s mnoha možnostmi konfigurace. Apache využívá conf.d adresář pro organizaci. Když jsem začínal s Apache, bylo běžné, že jeden server hostil více virtuálních stránek. Každý z těchto virtuálních hostitelů měl svůj vlastní konfigurační soubor. Tento přístup nám umožnil sdílet povinnosti správy souborů a také sdílet soubory na různých systémech během migrace, obnovy a vyvažování zátěže. Dnes vidím více případů, kdy je konfigurace oddělena funkcí.
Dalším faktorem je, pokud je funkce instalována jako samostatný modul.
$ rpm -qf /etc/httpd/conf.d/ssl.conf
mod_ssl-2.4.43-1.fc31.x86_64
Soubor ssl.conf konfigurace je dostupná pouze při mod_ssl balíček je nainstalován. Jiné moduly mohou také ukládat soubory do conf.d adresář. Některé aplikace, například mod_auth_kerb poskytněte ukázku v /usr/share/doc adresář. Je na správci webu, aby vytvořil nebo spravoval produkční soubory.
[ Potřebujete další pomoc s učením se Linuxu? Bezplatný online kurz:Technický přehled Red Hat Enterprise Linux. ]
Centralizovaná správa
Jak jsem navrhl u webových konfiguračních souborů, dalším použitím samostatných konfiguračních souborů je usnadnit centralizovanou správu těchto souborů a distribuovat relevantní součásti pouze do každého spravovaného uzlu.
Soubor modules.d adresář obsahuje konfiguraci pro nastavení modulu jádra a sysctl.d adresář obsahuje nastavení ladění jádra. Tato nastavení mohou být potřeba pouze na některých systémech nebo mohou vyžadovat nastavení specifická pro hardware. Nastavení lze organizovat podle hardwaru, funkce nebo kombinace.
Programy pro správu konfigurace mohou odeslat pouze relevantní soubory konkrétním spravovaným hostitelům nebo vygenerovat soubory na každém hostiteli na základě šablony. Pokud tyto soubory distribuujete pomocí řešení pro správu konfigurace, jako je Ansible, použijte něco jako ansible_managed proměnnou, která obsahuje komentář označující, že soubor je spravován vzdáleně.
Určete název a umístění
Zatímco adresáře dot-d mají běžné případy použití pro pomoc s organizací a distribucí, existuje mnoho různých způsobů, jak zacházet s zahrnutím. Pro každou aplikaci nebo nástroj musíme určit, jak nejlépe pojmenovat naše soubory. Některé konfigurace rozpoznávají pouze soubory s určitou příponou, například .conf , zatímco ostatní odkazují na všechny soubory v adresáři.
man stránky pro hlavní konfigurační soubor, jako je man logrotate.conf , obvykle popisuje možnosti. Přesto začínám hledáním příkazu include v konfiguračním souboru.
Když hledám include, vidím různé metody (formátované pro čitelnost):
$ grep ^include /etc/*conf
krb5.conf : includedir /etc/krb5.conf.d/
ld.so.conf : include ld.so.conf.d/*.conf
logrotate.conf : include /etc/logrotate.d
rsyslog.conf : include(file="/etc/rsyslog.d/*.conf" mode="optional")
Soubor ld.so a rsyslog konfigurace obě očekávají, že zahrnuté soubory budou končit .conf . Ostatní vypadají, že zahrnují všechny soubory, ale další vyšetřování může ukázat metodu pro vyloučení souborů. Například man logrotate.conf ukazuje, že tabooext a taboopat lze použít k odfiltrování .orig , .bak , .rpmnew nebo jiné soubory, které mohou být výsledkem verzování nebo aktualizací. Pro krb5.conf existuje oba include a includedir směrnice. Manuál ukazuje, že includedir direktiva pokrývá "všechny soubory v adresáři, jejichž názvy se skládají výhradně z alfanumerických znaků, pomlček nebo podtržítek." Dále zdůrazňuje, že soubory začínající tečkou (.) jsou ignorovány.
Dalším aspektem pro zahrnuté soubory je pořadí čtení a slučování. Viděl jsem několik, které čtou v náhodném pořadí, ale většina obsahuje soubory v pořadí, v jakém se nacházejí v adresáři. Pokud je sekvence obzvláště důležitá, jako například u modulů nebo spouštěcích skriptů, je běžné začínat názvy souborů číslem. Běžné jsou i další standardy pojmenování, jako je „pre“ nebo „post“.
$ ls /etc/NetworkManager/dispatcher.d/
04-iscsi 20-chrony no-wait.d pre-down.d pre-up.d
Některé nástroje mohou mít dokonce rozšiřující symboly, které pomáhají se správou a distribucí centralizovaných souborů. sudoers konfigurace je příklad, kde %h představuje krátký tvar názvu hostitele.
include /etc/sudoers.d/sudoers.%h
Řádek pro začlenění výše uvádí konfigurační soubor pro aktuálního hostitele, i když adresář obsahuje jiné soubory. Viz man sudoers pro další příklady.
Ověřte soubory
Dalším rizikem používání adresářů dot-d je to, že možná budete muset upravit příkazy pro kontrolu syntaxe.
V některých případech je nutné zkontrolovat všechny konfigurační soubory najednou. Například u Apache je to apachectl configtest příkaz vždy zkontroluje hlavní konfigurační soubor, který může obsahovat další soubory. Používá výchozí možnosti. Můžete spustit httpd -t příkaz s dalšími možnostmi. Například je zde možnost vypsat všechny zahrnuté soubory.
$ httpd -t -D DUMP_INCLUDES
Included configuration files:
(*) /etc/httpd/conf/httpd.conf
(59) /etc/httpd/conf.modules.d/00-base.conf
(59) /etc/httpd/conf.modules.d/00-dav.conf
httpd příkaz také přebírá -f možnost určit konkrétní soubor. Tento soubor však musí projít všemi kontrolami konfigurace, takže kontrola zahrnutého souboru nemusí poskytnout požadované výsledky. Při kontrole výchozího ssl.conf dojde k následující chybě konfigurační soubor poskytnutý mod_ssl balíček.
$ httpd -t -f /etc/httpd/conf.d/ssl.conf
AH00534: httpd: Configuration error: No MPM loaded.
Jiné aplikace mají metody ověřování syntaxe pro zahrnutý soubor. sudo konfigurace se normálně upravuje pomocí visudo příkaz, aby bylo možné provést ověření syntaxe před uložením a ukončením. Tento nástroj upravuje /etc/sudoers soubor ve výchozím nastavení, ale také podporuje -f možnost zadat jiný soubor.
$ sudo visudo -f /etc/sudoers.d/demo
>>> /etc/sudoers.d/demo: syntax error near line 1 <<<
What now? q
Options are:
(e)dit sudoers file again
e(x)it without saving changes to sudoers file
(Q)uit and save changes to sudoers file (DANGER!)
What now? x
Stejný příkaz také podporuje --check možnost pouze ověřit soubor bez úprav.
$ visudo -c demo.sudo
>>> demo.sudo: syntax error near line 1 <<<
parse error in demo.sudo near line 1
Zkombinujte to s možností ověření v programu pro správu konfigurace, abyste zajistili, že rozšíření šablon neporuší konfigurační soubor. V dokumentaci k modulům Ansible copy a template jsou ukázky. Také jsem uvedl následující příklad z ansible-doc template pro sshd :
- name: Update sshd configuration safely, avoid locking yourself out
template:
src: etc/ssh/sshd_config.j2
dest: /etc/ssh/sshd_config
owner: root
group: root
mode: '0600'
validate: /usr/sbin/sshd -t -f %s
backup: yes Malé prozkoumání komentovaných řádků a manuálových stránek vám pomůže vytěžit maximum z této organizační metody zobrazením možností distribuce, konvencí pojmenování a informací o ověření syntaxe.
Zabalit
Uspořádání konfiguračních souborů do adresářů může usnadnit správu a delegování správy. Soubory mohou být organizovány podle balíčků nebo funkcí a řešení správy konfigurace, jako je Ansible, mohou dokonce těžit z menších souborů šablon. Možná budete muset standardizovat názvy a umístění souborů a možná budete muset aktualizovat nástroje pro ověřování souborů, ale použití složky dot d k umístění více konfiguračních souborů vám může ušetřit spoustu úsilí.
[ Chcete si vyzkoušet Red Hat Enterprise Linux? Stáhněte si ji nyní zdarma. ]