使用Perl自動化UNIX系統管理

　　　集中化的配置文件策略

　　Teodor Zlatanov ([email protected])

　　程序員，Northern Light

　　2001 年 7 月

　　UNIX 系統管理總是一個棘手的問題，運用正確的工具會使這個問題變得容易。在這一部分中，Teodor 提出了關於使用 Perl 來簡化和牢固系統管理的想法。在這種環境中，系統配置引擎 cfengine 是一個極其重要的工具。

　　要完成本文中的練習，系統中必須安裝了 Perl 5.6.0。操作系統最好是主流 UNIX 安裝（Linux、Solaris、BSD）的最近版本（2000 或更新）。在較早版本的 Perl 和 UNIX 以及其它操作系統上也可以使用本文中的示例，但應當將可能的功能故障作為練習來解決。

　　UNIX 管理具有挑戰性的一大原因是每個 UNIX 供應商認為標准是針對低能傻瓜。所以，即使是同一供應商的操作系統（SunOS 4.x 和 Solaris 5.x）也可以是根本不同。在某些情況下，甚至根本沒有供應商。例如，Linux 沒有單獨的供應商（雖然 Red Hat 目前是最大的 Linux 分發版），每一個版本的 Linux 都有其獨到之處。如果 POSIX 標准化做得正確，那麼它是解決這一問題的正確方向上的一個步驟。遺憾的是，它只能保證系統管理所需功能的一個小的子集。

　　正如我經常所說：了解您的工具。如果試圖僅用一種工具、語言、或方法做每件事情，可能是一場噩夢。要具有靈活性。

　　如果存在一個系統管理公理，那就是：兩次過後，沒有系統管理任務是有趣的。如果您發現正在重復做單調而枯燥的事，那麼自動化它。當然，有時很難自動化，但應該至少考慮這個問題，並且權衡其優勢及自動化所花費的時間。

　　cfengine 工具

　　如果您對自動化系統管理是認真的，那麼應該了解 cfengine 工具。僅當您寧願把時間都花在 vi 編輯器時，可以不去了解 cfengine。

　　cfengine 是一種系統配置引擎。它獲取配置腳本作為輸入，然後根據這些腳本來行動。目前版本是 1.6.3（非常穩定的發行版），而且版本 2.0 也呼之欲出。有關 cfengine 開發的更多信息，請訪問 cfengine 網站（請參閱本文後面的參考資料）。

　　不一定要用 cfengine 提供您的所有東西，而且您不可能立刻需要所有東西。一開始時，您的 cfengine 配置文件應該很簡單，並且隨著發現更多東西希望自動化而增長。

　　來自 cfengine 命令參考大全，這裡有其最值得注意的特性：

　　可以監控和修改文件許可權和 ACL。例如，/etc/shadow 可以與 0400/root/sys 許可權保持一致，而且如果那些許可權發生變化，可以警告系統管理員或即刻糾正它們。

　　根據相應 fstab 變化，可自動安裝和卸載 NFS 文件。

　　可以通過單一文件來管理子網掩碼、DNS 配置、缺省路由和主網絡接口；

　　文件和目錄可以遞歸復制至另一位置，要麼本地復制，要麼從遠程服務器復制。

　　可以編輯（這是一個非常強大的特性，提供了正則表達式和全局查找／替換）、輪轉（譬如，日志文件）或刪除文件。

　　可以鏈接文件（單一的和／或目錄下的所有文件或與正則表達式匹配的文件）和整個目錄。

　　可以根據進程表中正則表達式的匹配來啟動、殺死、重啟進程或發送任意信號。

　　可以運行任意命令。

　　上述所有這些根據操作系統類型和修訂版本、一天中的時間、任意用戶定義的類、文件中文件、目錄或數據的有無等等可以是有條件的。

　　即使用 Perl 可以做 cfengine 所做的所有事情，為什麼要從頭開始呢？例如，如果想用另一個詞替換某個詞，編輯文件可以是簡單的一行程序。當開始允許系統的子類型、邏輯系統部分以及所有其它雜項因素時，這一行程序會變成 300 行。為什麼不在 cfengine 中做呢？它產生 100 行可讀的配置代碼。

　　根據我自己的經驗，因為可以從最小配置文件開始，然後隨著時間流逝逐步地向 cfengine 添加一些東西，所以將 cfengine 介紹給站點是很容易的。沒有人喜歡突然的變化，所有系統管理員更是如此（因為如果任何事出錯，他們理所當然地會受到責難）。

　　配置文件管理

　　管理配置文件是艱苦的。可以通過考慮 cfengine 是否勝任該任務開始。遺憾的是，cfengine 的編輯是面向行的，所以它可能不太適合復雜的配置文件。但對於如 TCP 包裝器配置文件 /etc/hosts.allow 那樣的簡單文件 cfengine 是最適合的。

　　通常，希望保留配置文件的多個版本。譬如，可能需要在 /etc/resolv.conf 中有兩組 DNS 配置設置，一組是用於外部機器，另一組是用於內部機器。很自然，外部 DNS resolv.conf 可以進入稱為 "external" 的目錄，而內部 resolv.conf 可以進入相應的 "internal" 目錄。讓我們假定這兩個目錄都在一個全局 "spec" 目錄下，該目錄是配置文件的一種根目錄。

　　下列代碼會遍歷 spec 目錄，搜索適合於給定機器的文件名。它將從 /usr/local/spec 開始，然後往下，尋找與請求相匹配的文件。而且，它將檢查每個目錄的名稱是否與屬於某些機器的類相同。因此，如果我們請求 locate_global('resolv.conf', 'wonka')，該函數將在 /usr/local/spec 目錄下查找 resolv.conf 文件，該文件要麼在根目錄下，要麼在該根目錄的子目錄下，它的名稱應與 "wonka" 機器所屬的類相匹配。所以，如果 "wonka" 屬於 "chocolate" 類，並且如果有 /usr/local/spec/chocolate/resolv.conf 文件，那麼 locate_global() 將返回 "/usr/local/spec/chocolate/resolv.conf"。

　　如果 locate_global() 找到與文件相匹配的多個版本（譬如，/usr/local/spec/chocolate/resolv.conf 和 /usr/local/spec/resolv.conf），則它會放棄。這裡假設沒有配置比有兩個錯誤之一要好。還有，請注意，機器可以屬於不止一個類。

　　可以構建這樣的結構。譬如，

　　/usr/local/spec/external/chocolate/resolv.conf

　　/usr/local/spec/internal/chocolate/resolv.conf

　　/usr/local/spec/external/sugar/resolv.conf

　　/usr/local/spec/internal/sugar

　　將包含外部和內部 "chocolate" 以及 "sugar" 機器的文件。只需要正確地設置 your machine_belongs_to_class() 函數。

　　一旦 locate_global() 返回一個文件名，將它用 scp 或 rsync 復制至遠程系統是相當簡單的。請記住，總是要保持該文件的許可權和屬性。scp 需要 "-p" 標志，rsync 需要 "-a" 標志。查閱想要使用的文件復制命令的文檔。這樣就有了一個統一的配置文件樹。

　　清單 1：Spec 目錄遍歷

　　# {{{ locate_global: use spec directory to find a file matching the current class

　　sub locate_global($$)

　　{

　　# this code uses File::Find

　　my $spec_dir = '/usr/local/spec';

　　my $file = shift || return undef; # file name sought

　　my $machine = shift || return undef; # machine name

　　my @matches;

　　my $find_sub =

　　sub

　　{

　　print "found file $_\n";

　　push @matches, $File::Find::name if ($_ eq $file);

　　# the machine_belongs_to_class sub returns true if a machine

　　# belongs to a class; we stop traversing down otherwise

　　$File::Find::prune = 1 unless

　　machine_belongs_to_class($machine, $_) || $_ eq '.';

　　};

　　find($find_sub, $spec_dir);

　　if (scalar @matches > 1)

　　{

　　print "More than one match for file $file,",

　　"machine $machine found: @matches\n" ;

　　return undef;

　　}

　　elsif (scalar @matches == 1)

　　{

　　return $matches[0]; # this is the right match

　　}

　　else {

　　return undef; # no files found

　　}

　　}

　　# }}}

　　一旦建立了這種 /usr/local/spec 結構的一個問題是：我們怎麼知道 resolv.conf 應當進入 /etc？要麼沒有如這裡所示的漂亮層次結構，改寫它（譬如，用 "+" 替代 "/" －一種危險的和有點丑陋的方法），要麼在鏈接名與真實名之間保持單獨的映射。譬如，"root-profile" 可以是 "~root/.profile" 的鏈接名。最後一種方法，也是我喜歡的方法，由於它平鋪文件名並且消除了有隱藏文件名的問題。在一個目錄結構下，每一樣都是可見的和整潔的。當然，每次在將文件添加到列表時，需要多做一些工作。程序必須知道 "resolv.conf" 應該復制到遠程系統的 "/etc/resolv.conf"，並且 "dfstab" 應該進入 "/etc/dfs/dfstab"（共享 NFS 文件系統的 Solaris 文件）。

　　一旦設置完 spec 目錄層次結構，現在讓我們討論可以做什麼。如果想做，可以查找所有名為 Joe 的用戶：

　　清單 2：查找所有 password 文件並用 grep 找出 Joe

　　grep Joe `find /usr/local/spec -name passwd`

　　或者可以使用工具，如 rep.pl（鏈接到 rep.pl），由 David Pitts 編寫，來用另一個詞替換每一個詞：

　　清單 3：查找所有 host 文件並將 "wonka" 改成 "willy"

　　find /usr/local/spec -name hosts -exec rep.pl wonka willy {} \;

　　現在，如果願意，可以用 Perl 編寫清單 2 和 3；find2perl 就是為此編寫的實用程序。雖然它非常簡單，從開始只使用 find。它真的是極好的實用程序，每個系統管理員都應該使用。更重要的是，編寫這兩個清單只花了我 5 分鐘。了解如何使用 find2perl，將它生成的代碼存儲在文件中，然後運行該文件，要花多長時間呢？自己試試看！

　　任務自動化

　　任務自動化是一個很泛的主題。我將本節僅限於非交互式 UNIX 命令的簡單自動化。對於交互式命令的自動化，Expect 是當前可用的最好工具。應該要麼了解它的語法，要麼用 Perl Expect.pm 模塊。可以從 CPAN 獲取 Expect.pm；請參閱參考資料以了解更多詳細信息。

　　利用 cfengine，可以根據任意標准自動化幾乎任何任務。但是，它的功能非常象 Makefile 功能，對變量的復雜操作是很難處理的。當發現需要運行這樣的命令，該命令的參數來自於散列或通過單獨的函數時，通常最好切換到 shell 腳本或 Perl。由於 Perl 的功能，其可能是較好的選擇。雖然，不應該將 shell 腳本棄為替代來使用。有時，Perl 是不必要的，您只需要運行一些簡單的命令。

　　自動添加用戶是一個常見問題。可以編寫自己的 adduser.pl 腳本，或者用大多數現代 UNIX 系統提供的 adduser 程序。請確保使用的所有 UNIX 系統間語法是一致的，但不要嘗試編寫一個通用的 adduser 程序接口。它太難了，在您認為涵蓋了所有 UNIX 變體後，遲早會有人要求 Win32 或 MacOS 版本。這不是僅僅用 Perl 就能解決的問題之一，除非您是非常有野心的。這裡只是讓腳本詢問用戶名、密碼、主目錄等等，並以 system() 調用來調用 adduser。

　　清單 4：用簡單的腳本調用 adduser

　　#!/usr/bin/perl -w

　　use strict;

　　my %values; # will hold the values to fill in

　　# these are the known adduser switches

　　my %switches = ( home_dir => '-d', comment => '-c', group => '-G',

　　password => '-p', shell => '-s', uid => '-u');

　　# this location may vary on your system

　　my $command = '/usr/sbin/adduser ';

　　# for every switch, ask the user for a value

　　foreach my $setting (sort keys %switches, 'username')

　　{

　　print "Enter the $setting or press Enter to skip: ";

　　$values{$setting} = ;

　　chomp $values{$setting};

　　# if the user did not enter data, kill this setting

　　delete $values{$setting} unless length $values{$setting};

　　}

　　die "Username must be provided" unless exists $values{username};

　　# for every filled-in value, add it with the right switch to the command

　　foreach my $setting (sort keys %switches)

　　{

　　next unless exists $values{$setting};

　　$command .= "$switches{$setting} $values{$setting} ";

　　}

　　# append the username itself

　　$command .= $values{username};

　　# important - let the user know what's going to happen

　　print "About to execute [$command]\n";

　　# return the exit status of the command

　　exit system($command);

　　用 Perl 來處理的另一個常見任務是監控和重新啟動進程。通常，這是用 Proc::ProcessTable CPAN 模塊進行的，它浏覽整個進程表，並返回給用戶帶許多重要屬性的進程列表。然而，在這裡，我必須推薦 cfengine。與快速的 Perl 工具相比，它提供了更好的進程監控和重新啟動進程的選項。如果您想編寫這樣的工具，那麼這只是在做別人做過的事情（而且 cfengine 已經偷了您的輪毂蓋）。如果由於個人原因，不想用 cfengine，考慮一下大多數現代 UNIX 系統中附帶的 pgrep 和 pkill 實用程序。pkill -HUP inetd 將用一條簡潔的命令可以做四行或更多行 Perl 腳本所做的事情。這就是說，如果正在做的進程監控是很復雜或對時間敏感，那麼應該明確用 Perl。

　　為了完整性緣故，這裡是一個演示了如何使用 kill() Perl 函數的 Proc::ProcessTable 示例。"9" 作為參數，是最強的 kill() 參數，大體意味著“不管三七二十一，殺死進程再說”。不要以 root 運行這條命令，除非真想殺死 inetd 進程。

　　清單 5：遍歷進程，然後殺死所有 inetd

　　use Proc::ProcessTable;

　　$t = new Proc::ProcessTable;

　　foreach $p (@{$t->table})

　　{

　　# note that we will also kill "xinetd" and all processes

　　# whose command line contains "inetd"

　　kill 9, $p->pid if $p->cmndline =~ 'inetd';

　　}

　　結束語

　　UNIX 系統管理最讓人失望的部分是 UNIX 供應商逃避標准而找到的各種方式。由於這種原因，當 Perl 單獨應付 UNIX 系統中所有問題時，它是無能為力的。如果沒有象 cfengine 這樣的工具，象密碼文件語法、共享文件系統以及跟蹤日志等問題很快就變得無法管理。然而，還是存在一些希望；畢竟，我們只是查看了 Perl 可簡化系統管理的一些方法。

　　Perl 與 cfengine 結合得很好。可以用 Perl 生成定制的 cfengine 配置，或者可以從 cfengine 運行 Perl 腳本。我用過這兩者，發現集成不難。然而，cfengine 受過分簡單的配置語言和缺乏數據結構影響。我將在有關 cfengine 的未來文章中展開這一問題。

　　如果選擇實現的話，本文中介紹的集中化配置文件策略應當是非常實用的。在我的站點上現在已經使用了六個月，而且獲得了巨大成功。如果將完整的層次結構檢入一個如 CVS 那樣的版本控制系統，您還將享受到版本化系統文件的好處，即可以回復到已檢入版本控制系統的任一狀態。

　　參考資料

　　請訪問 CPAN 以查找您所感興趣的所有 Perl 模塊。

　　Perl.com 有關於 Perl 信息和相關資源。

　　請獲取 cfengine 模塊，這是多合一的 UNIX 管理工具。

　　UNIX System Administration Handbook, 3rd Edition，由 Evi Nemeth、Garth Snyder、Scott Seebass 和 Trent R. Hein 著 (Prentice Hall 2000)，描述了系統管理許多不同方面，從基本問題到 UNIX 秘籍，並且明確地包含了四種流行的系統：Solaris 2.7、Red Hat Linux 6.2、HP-UX 11.00 和 FreeBSD 3.4。

　　Programming Perl Third Edition，由 Larry Wall、Tom Christiansen 和 Jon Orwant 著 (O'Reilly & Associates 2000)， 這本書是現今最好的、針對 Perl 5.005 和 5.6.0 的指南。

　　Perl for System Administration: Managing multi-platform environments with Perl, 由 David N. Blank-Edelman 著 (O'Reilly & Associates 2000)，該書全面地總結了用 Perl 編寫的用於系統管理的不同工具和技術。這裡重點是放在可移植性。

　　UNIX Power Tools, 2nd Edition，由 Jerry Peek、Tim O'Reilly & Mike Loukides 著 (O'Reilly & Associates 1997)，是 UNIX shell 和相關工具入門的較好的指南。雖然該書有點老，但仍然很優秀。

　　請訪問 O'Reilly & Associates：Programming Perl 和許多其它好書的出版社。

　　如果想閱讀由本文作者所寫的相關文章，請參閱 developerWorks 上 “功能豐富的 Perl：一行程序 101”和“用於 C 和 Java 程序員的 Perl 5.6”。