| 導購 | 订阅 | 在线投稿
分享
 
 
 

功能豐富的Perl:Perl自動化系統管理

來源:互聯網  2008-05-19 06:25:56  評論

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。它真的是極好的實用程序,每個系統管理員都應該使用。

  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。它真的是極好的實用程序,每個系統管理員都應該使用。   
󰈣󰈤
 
 
 
>>返回首頁<<
 
 
 
 
 熱帖排行
 
王朝網路微信公眾號
微信掃碼關註本站公眾號 wangchaonetcn
 
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有