Cobbler Manページ
このページは本家サイトのCobbler Manpageを、作者である Michael DeHaan 氏に許可を得て、個人的に翻訳したものを公開しています。
あくまでも個人的な訳となっており、意訳・超訳的なところも多々ありますので、翻訳・記述の内容に不備やご意見等あればご指摘・ご連絡頂けると助かります。
（翻訳日：2007/9/23 最終更新日：2008/8/17）
名前
cobblerは、サーバのプロビジョニングとアップデートを行うためのサーバソフトウェアです。プロビジョニング機能においては、PXE（ネットワークブート）を使用してのデプロイメント、仮想化（XenとQEMU/KVM）、そして既存のLinuxシステムの再インストールをサポートしており、これらのうち仮想化と既存システムの再インストールは、リモートシステム上の「koan」を使用することで可能となります。アップデート機能では、yumレポジトリのミラーの構築、および構築したミラーをキックスタートインストールと統合することができます。また、cobbler は複数のインタフェースをサポートしており、コマンドラインやブラウザ経由での操作はもちろん、拡張可能なPython APIとXMLRPC APIを使って、外部のスクリプトやアプリケーションと連携させることも可能です。
書式
cobbler コマンド [サブコマンド] [--オプション1=値1] [--オプション2=値2]
説明
cobblerは、ディストリビューション、プロファイル、システム、レポジトリからなる階層構造的なコンセプトを使用して、プロビジョニングの管理を行います。
ディストリビューションは、使用するカーネルとinitrdと、それに関連するメタデータ（必要なカーネルパラメータ、など）の情報を含みます。
プロファイルは、ディストリビューションと任意のキックスタートファイルとの関連付けを行い、オプションとしてさらにメタデータをカスタマイズすることができます。
システムは、MACアドレス、IPアドレス、そして/またはホスト名をプロファイルと関連づけて、こちらもオプションとしてメタデータのカスタマイズを行うことができます。
レポジトリは、yumのミラー情報を含んでいます。cobblerを使ったレポジトリのミラーはオプションですが、プロビジョンニングとパッケージ管理は多くの点で共通点があります。
cobblerの最大の利点は、多くの別々の技術やコンセプトを組み合わせて、ユーザがそれを理解する必要がないように抽象化していることです。これによりシステム管理者は「どのように行われるのか？」ではなく「何をすべきか？」に集中することができます。
この man ページはcobblerの設定を行うために必要なコマンドラインのインタフェースに焦点を当てていますが、これ以外にもcobblerのインストールおよび設定が完了した後に日々のオペレーションを行うために必要なウェブインターフェースにも言及しています。API や XMLRPC コンポーネントに関するドキュメントは、http://cobbler.et.redhat.com や 有志による wiki （http://hosted.fedoraproject.org/projects/cobbler/）で公開されていますのでオンラインで参照可能です。
ほとんどのユーザはウェブインタフェースの方に興味を持つと思いますので、そちらをセットアップすると思いますが、初期設定にはコマンドラインのツール、特に"cobbler check" と "cobbler import" は必要です。
注意
キックスタートファイルの作成には、"system-config-kickstart"を試してみるか、新規に1台システムをインストールした時にインストーラが作成する/root/anaconda-ks.cfg を確認してみるとよいでしょう。キックスタートに関する一般的な疑問は、kickstart-list@redhat.com で尋ねてみてください。また、cobbler をインストールすると /etc/cobbler 配下にいくつかキックスタートファイルのテンプレートがありますので、こちらも参考にして下さい。
より詳細なドキュメントや、ユーザから寄せられたTIPSなどは、前述のウェブサイトを参照してください。
COBBLER使用方法
セットアップ
インストールが完了したら、"cobbler check" を実行して、cobbler のエコシステムが正しく設定されているかを確認します。cobbler check を実行すると、設定ファイルのチェックが行われ、どこを変更すればよいか？が表示されますので、テキストエディタで編集します。
cobbler check で検出されたエラーは修正する必要がありますが、例外としてDHCP関連の警告が表示される場合があります。1これについては、あなたの環境でDHCPを使用するかどうかを判断する必要があるでしょう。設定ファイルに変更を行った後は必ず "cobbler sync" を実行して、変更内容を反映します。
これらの設定の中で特に重要なのは、/var/lib/cobbler/settings の server name が正しく設定されていることです。この箇所が正しく設定されていなければ、キックスタートのインストールツリーが見つからず、自動インストールは失敗します。
PXEの場合、DHCPをcobblerサーバ上でローカル実行するのであれば、"cobbler check" で指定されたようにdhcp設定ファイルを変更してください。ローカルではなくリモートの別のサーバ上でDHCPを実行する場合は、そのDHCPサーバ上のdhcp設定ファイルで "next-server" にcobblerサーバのIP、"filename" に "pxelinux.0" を指定します。また、別の方法として、dhcpをローカルで実行する場合は、cobbler から dhcp設定ファイルを生成することも出来ます -- 詳しくは後で説明します。もしほかのツールなどを使ってDHCPを管理していないのであれば、cobblerを使うとDHCPの割当を他のデータと一緒に管理が出来るのでとても便利です。既にDHCPサーバをセットアップ済みの場合でも、既存の設定管理を cobbler に移行することはそれほど難しくありません — あくまでも cobbler の DHCP管理機能はオプションです。もしPXEを使用したネットワークブートを必要とせず、koan を使って単に仮想システムをインストールしたいというだけであれば、DHCPについて全く気にする必要はありません。また koan にはライブCD機能もありますので、これを使ってPXE環境をシミュレートすることもできます。
ディストリビューションの追加
プロビジョニングを設定するための最初のステップは、cobblerにディストリビューションの設定を追加することです。
もし、rsyncのミラー、インストールDVD、NFS、ファイルシステム上など、既に利用可能なインストールツリーからインポートを行うことができる場合は、このドキュメントの"import"コマンドの章までスキップしてください。その方が作業は簡単で、単にミラーからのコンテンツのコピー・読み込みが終わるを待つだけです。また、インポートされたミラーは、OSインストール時に参照されますので、外部のインストールソースへアクセスする必要がなく、インストール時間を節約できます。
しかしながら、もしディストリビューションをきっちりと定義したいなら、以下のように設定することができます:
cobbler distro add --name=string --kernel=path --initrd=path [--kopts=string] [--ksmeta=string] [--arch=x86|x86_64|ia64] [--breed=redhat|debian|suse]
- name
- ディストリビューションを識別する文字列を指定します。例えば"rhel4"という感じになります。
- kernel
- カーネルイメージへの絶対パスを指定します。
- initrd
- initrdイメージへの絶対パスを指定します。
- kopts
- ディストリビューションが使用するカーネルへ渡すコマンドライン引数を指定します。配下のプロファイル/システムはディストリビューションの設定に依存します。2
例: --kopts="foo=bar baz=3 asdf"
- arch
- PXEブートローダのアーキテクチャを指定します。
デフォルト設定（'standard'）では pxelinux が使用されます。elilo を使う場合は 'ia64' を指定します。
'x86' と 'x86_64' は、事実上 'standard' と同じ動作になります。
- ksmeta
- これはより高度な機能で、キックスタートファイル上の変数を置き換えることができます。つまり、キックスタートファイルをテンプレートとして使うことができるということです。テンプレートエンジンには Cheetah を使用しており、このmanページでも別途説明しますが、Cobbler Wikiにも記載があります。
例: --ksmeta="foo=bar baz=3 asdf"
詳細は"キックスタートのテンプレート化"のセクションを参照してください。
- breed
- 自動インストールのためのカーネル引数をどのようにコントロールするかを指定します。デフォルトは"redhat"になっており、FedoraやCentOSを使う場合に適した値、つまり redhat ベースという意味です。
まだ実験的なサポートに限られたレベルですが、"debian"や"suse"を指定すると、異なるフォーマットのキックスタートファイルを使用し、カーネル引数もそれぞれに適した形に変わります。将来、他のタイプのディストリビューションをサポートする可能性があります。
breedの設定に関係なく、アンサーファイルとして使用されるファイルは、プロファイルを作成した時に --kickstart で指定されたファイルとなります。
- owners
小規模なサイトや管理者がそれほど多くない場合はこのオプションは無視してもかまわないでしょう。全てのcobblerのオブジェクト（ディストリビューション、プロファイル、システム、レポジトリ）は、--ownersパラメータを指定することで、どのユーザがどのパラメータを変更することができるかを設定できます。この設定は、CobblerのウェブインタフェースとXMLRPCインタフェースのみに適用され、シェルから実行される"cobbler"コマンドには適用されません。さらに、この設定は、"authz_ownership"モジュールが/etc/cobbler/modules.confで有効になっている場合にのみ適用されます。--ownersの引数には、/etc/cobbler/users.confで指定されているユーザ・グループをカンマ区切りで指定します。詳細はusers.confファイル、またはCobbler Wikiを参照してください。
プロファイルの追加
プロファイルは、ディストリビューションを追加の特別なオプション、例えば、キックスタートの自動化ファイルと関連づけます。プロファイルは、プロビジョニングの中心ユニットとなり、プロビジョニングを行うディストリビューションごとに最低1つのプロファイルが存在していなくてはなりません。例えば、ウェブサーバ用やデスクトップ用といった設定にプロファイルは相当するかもしれません。こんな感じで、プロファイルは、どのように動作するかという役割を定義するものです。
cobbler profile add --name=string --distro=string [--kickstart=path] [--kopts=string] [--ksmeta=string] [--virt-file-size=gigabytes] [--virt-ram=megabytes] [--virt-type=string] [--virt-cpus=integer] [--virt-path=string] [--virt-bridge=string] [--server-override]
引数は、ディストリビューションのところでも紹介したものから、"arch" と "breed" を除き、さらにいくつか追加したものになります。以下に列挙します。
- name
- プロファイルを説明する名前。"rhel4webservers" とか "fc6desktops"といった風になるはずです。
- distro
- 先に定義したcobblerのディストリビューションの名前。
- kickstart
- キックスタートファイルへのローカルファイルシステム上のパス。http:// で始まるURL（CGIでさえも）も指定可能ですが、キックスタートのテンプレートエンジンを利用できるので、ローカルファイルシステム上のパスを指定することをお薦めします。
もしこのパラメータが指定されなければ、キックスタートファイルはデフォルトで/etc/cobbler/default.ksになります。このファイルは初期状態で空のファイルであり、デフォルトのキックスタートで"特に何もしなくても"自動化がされるわけではないということを意味しています。管理者はdefault.lsを変更することが出来ます、もし望むならですが、、、
キックスタートファイルを使用する場合、ファイルシステム上のどこにでも置くことが出来ますが、/var/lib/cobbler/kickstarts に置くことをお薦めします。
- virt-file-size
- （仮想環境のみ）ディスクイメージの容量をギガバイト単位で指定します。デフォルトは"5"です。カンマ区切りのリスト（例："5,6,7"）で指定して、-virt-pathで指定された複数の異なるサイズのディスクイメージを指定することも可能です。
- virt-ram
- （仮想環境のみ）消費するRAMの容量をメガバイト単位で指定します。デフォルトは512MBです。
- virt-type
- （オプション）（仮想環境のみ）koan は、Xen paravirt（"xenpv"）と QEMU/KVM("qemu")のどちらを使ってもイメージをインストールすることが出来ます。どちらか一方を選択して文字列を指定してください、デフォルトではクライアントシステム上で互換性のあるインストールタイプを見つけようとします（"auto"）。詳細は"koan"のmanページを参照して下さい。このパラメータが指定されていない場合のデフォルトの virt-type は cobbler の設定ファイルで設定することもできます。
- virt-cpus'
- （仮想環境のみ）koanが仮想マシンに設定する仮想CPUの数を設定します。デフォルトは1です。
- virt-path
- （仮想環境のみ）ホストシステムの仮想システムの保存先を設定します。高度な場合を除いて、このパラメータが通常省略できます。ディスクイメージの場合、値は存在するディレクトリの絶対パスとオプションのファイル名で構成されます。"/dev/sda4"といったパーティションや"VolGroup?00"といったボリュームグループでの指定も可能です。
複数のディスクを指定する場合は、"VolGroup?00,VolGroup?00" や "/dev/sda4,/dev/sda5" という風にカンマ区切りで指定してください。どちらの例もVMに対して二つのディスクを作成します。
- virt-bridge
（仮想環境のみ）プロファイル配下のすべてのシステムが使用するデフォルトのネットワークブリッジを指定します。指定がなければ、cobblerの設定ファイル内のデフォルト値が適用され、現在配布されているRPMパッケージでは'xenbr0'が設定されています。KVMを使用する場合、これは正しい値ではありませんので、システムの設定でこれを上書きしたいと思うかもしれません。ブリッジの設定は、外部ネットワークがゲストへどのようにアクセスするかを定義しますので重要です。ブリッジ設定の詳細については、Cobbler Wiki の koan 使用方法について記載されているセクションを参照してください。
- repos
- （オプション）プロファイルがキックスタートインストールで使用する全てのレポジトリ（"cobber repo add" で作成し、 "cobbler reposync" でアップデート ）を、スペース区切りで指定します。例えば、既にcobblerサーバ上に構築されている二つのミラーにプロファイルからアクセスさせたい場合は、 --repos="fc6i386updates fc6i386extras" といった形になります。
- inherit
- これはより高度な機能です。
（オプション）--distro を指定する代わりに、他のプロファイルから設定を継承することが出来ます。継承されたプロファイルでは、親プロファイルで設定されたどんな設定も上書きすることができます。ただし、--ksmeta（テンプレート化）と--kopts（カーネルオプション）は例外で、これらは一つに組み合わされます。
例：もしプロファイルAに--kopts="x=7 y=2"が指定されていて、BはAから継承、Bに--kopts="x=9 z=2"が指定された場合、Bで使用される実際のカーネルオプションは"x=7 y=2 z=2"となります。
例：プロファイルBに--virt-ram=256が指定されていて、Aに--virt-ramで512が指定されていれば、プロファイルBは256を値として使用します。
例：プロファイルAの--virt-file-sizeに5が指定されていて、Bはサイズが指定されていない場合、BはAから継承した値を使用します。
- server-override
- このパラメータは限られた条件下でのみ有効となるでしょう。もし対象のマシンが、cobbler設定ファイル内で定義されたサーバ名/IPアドレスを使ってcobblerサーバにアクセスできないようなサブネット上に存在する場合、このパラメータを使用してサーバ名を上書きすることが可能です。Cobblerを使用してDHCP設定管理も行う場合は、システムのnext serverとDHCP情報の設定について--dhcp-tagも参照してください。
システムの追加
システムは、ハードウェアと、そのハードウェア上で実行するように割り当てられるcobblerのプロファイルをマッピングします。これは特定のシステムに対して役割を選択するといった考え方になるのかもしれません。
注意してほしいのは、koanを使う場合やPXEメニュー単体でプロビジョニングを行う場合、システムのレコードを作成する必要はないということです。もちろん、システムに特定のテンプレートを割り当てる必要がある場合や、特定のシステムが常に特定のソフトウェアをインストールしなければ行けない場合は、これらは便利な機能です。任意の機器に特定の意図した役割があるのであれば、そのシステムのレコードを作成すべきです。
cobbler system add --name=string --profile=string [--mac=macaddress] [--ip=ipaddress] [--hostname=hostname] [--kopts=string] [--ksmeta=string] [--netboot-enabled=Y/N]
ではcobblerの対象となるシステムを設定に追加します。引数は、"profile add" で示したように、以下のいくつかの変更を加えて、指定します:
- name
- 他のコマンドのnameオプションと同じように、システム名を指定します。
名前がMACアドレスやIPアドレスとして推測される場合は、どちらの場合もそれぞれ暗黙的に --mac と --ipとしても使用されます。ベストプラクティス的な使い方としてはMacアドレスをsystemの--nameとして使用することをお勧めします、なぜならMACアドレスは、世界に一つしかなく、変更されることもない、とても明確なものだからです。
システム名に"default"が使用された場合は特別な動作になります。デフォルトのシステム要素が存在する場合、定義されていないシステムは全てPXEで特別なプロフィールがセットされます。"default"というシステム名が作成されていなければ、設定されていないシステムではPXEが失敗しローカルでブートすることになるでしょう。
- mac
-
MACアドレスを--macで指定すると、システムをPXE経由でブートさせることが出来ます。もしcobblerのシステム名が既にMACアドレスのように見える場合は、そのシステム名から推測されるので、指定する必要はありません。
MACアドレスの形式はAA:BB:CC:DD:EE:FFとなります。
- ip
- cobblerがDHCPの設定を生成するように設定してある場合（高度な話題のセクションを参照してください）は、DHCPでこのシステムに割り当てる特定のIPアドレスを定義してください。このパラメータを指定しない場合、このシステムではDHCPでの管理を行わないということになります。
例: ---ip=192.168.1.50
itaniumを使用している場合の注意: DHCP管理の有効/無効に関わらず、IA64の場合はこの設定は常に必須です。
- hostname
- DHCP設定機能（高度な話題のセクションを参照してください。）をdnsmasqを使って使用する場合、DNSから回答を受け取るためにシステムに定義するホスト名を指定してください。DHCP管理を使用しない、もしくはdnsmasqを使用しない場合、このフィールドは、説明用のコメントとして扱われ、基本的には無視されます。
例: --hostname=mycomputer.example.com
- --kickstart
- （オプション）--kickstartパラーメータは"profile add"コマンドにおいてのみ使用することをお勧めしますが、cobberに切り替えたインストール元サーバにシステム単位でキックスタートファイルが存在する（1システムに1キックスタートファイル、共有はしない）場合や、cobblerのテンプレートシステムをすぐには使いたくない、といった場合が考えられます。このオプションは、システム単位を基準として使っているキックスタートファイルを指定することを可能とします。ただしその場合でも親プロファイルの作成は必須です。キックスタートファイルがファイルシステム上に存在する場合はcobblerのテンプレートとして使用されます。
- --netboot-enabled
- falseがセットされている場合、システムはkoanを通じてプロビジョニングが行われ、標準的なPXE経由では行われません。これを使うと、cobblerのシステムオブジェクトを削除することなく、デフォルトのPXEブートが行われないようにさせることができます。デフォルト値はPXEを許可します。
レポジトリをミラーに追加
cobblerはインストールツリーのミラー化ができるだけではなく（"cobbler import"がこれを行います）、オプションのパッケージ、サードパーティのコンテンツ、さらにはアップデートさえも、レポジトリのミラーとしてミラー化できます。これらのコンテンツをあなたのローカルネットワーク上に全てミラー化することで、最新状態でのインストールが高速に行われ、また最新のアップデートが可能になります。もしあなたが単に自宅環境でプロビジョニングを行うだけであれば、ちょっとやり過ぎかもしれませんが、大規模なセットアップを必要とする環境（研究所、データセンター、など）ではとても便利な機能です。
cobbler repo add --mirror=url --name=string [--local-filename=string] [--rpmlist=list] [--creatrepo-flags=string]
- mirror
- yumのミラーのアドレスを指定します。ここでは、rsync://のURL、sshの場所、!http:// や ftp:// といったミラーの場所を指定することが出来ます。ファイルシステムへのパスももちろん指定できます。
ミラーのアドレスは、ミラーに対して厳密にレポジトリを指定する必要があります — つまり、単一のアーキテクチャで単一のディストリビューションということです。もし異なるアーキテクチャに対して別々のレポジトリがある場合には、別々に分けてそれらのレポジトリを追加して下さい。
以下は、URLの指定として良い場合の例です。
rsync://yourmirror.example.com/fedora-linux-core/updates/6/i386 （rsyncプロトコルの場合）
http://mirrors.kernel.org/fedora/extras/6/i386/ （http://の場合）[[BR]]user@yourmirror.example.com/fedora-linux-core/updates/6/i386 （SSHの場合）
実験的なサポートとして、RHNのコンテンツをローカルで迅速に行いたい場合のミラーリングをサポートしています。このミラーを指定する場合の形式は、--mirror=rhn://channel-name となり、これを実行する場合はあなたはその権利を持っていなければなりません。またこの場合、cobblerサーバはRHEL5以降でインストールされている必要があります。
- name
- この名前は、保存されたミラーの場所として使用されます。ミラーが、例えば、Fedora Core 6 i386 updates、に相当するとしましょう。この場合に良い名前は "fc6i386updates" といった感じになるでしょう。再度になりますが、一意である必要があります。
この名前が、"cobbler profile add" の --repos パラメータで指定される値となります。もしプロファイルが --repos で指定した値にマッチする名前があれば、プロビジョニングにおいてそのレポジトリが自動的に設定されます。これは、Anacondaがサポートしている場合はキックスタートインストールにおいてもそのレポジトリが使用され、もう一つ、Anacondaがサポートしている／していないに関係なくどちらの場合でも、プロビジョニング対象のクライアントがそのレポジトリを使えるように自動的に設定される、という意味です。（--local-filenameを参照してください。）
詳細についてはドキュメントの"cobbler profile add"の箇所を参照してください。
- local-filename
- local finenameは、キックスタートファイル上にテンプレートのパラメータとして"yum_config_stanza"が指定されている場合に、どのファイルをプロビジョニング対象の/etc/yum.repos.dに配置するかを指定します。
言い換えると、もしここに"foo"が指定してあれば、プロビジョニング対象のクライアントには"/etc/yum.repos.d/foo.repo"としてレポジトリ設定がインストールされます。
もしクライアントにレポジトリをインストースしたくない場合は、そのレポジトリに名前を追加しないでください、そうすればプロビジョニング対象の機器はこのレポジトリのyumの設定を行いません。 — あなたが選択するものを手動で行うことは可能です。その場合でも、インストールにはこのレポジトリが使用されますが、クライアントの/etc/yum.repos.dには自動で設定されることはないということです。
キックスタートのテンプレート化でこれをどのように利用すればよいかについては、例として/etc/cobbler/kickstart_fc6.ksを参照してみてください。
- rpm-list
- --rpm-listにパッケージの名前をスペース区切りで指定すると、レポジトリの一部（指定されたパッケージとそれに依存するパッケージ）だけをミラー化することができます。これは時間、容量、帯域の節約という点ではとても便利です。例えば、FC6 Extrasのうち、単にcobblerとkoanだけをミラー化して、全てのゲームなどはスキップするといった具合です。この場合は、--rpm-list="cobbler koan"と指定します。
このオプションは http:// と ftp:// で指定されるレポジトリでのみ機能します。他のミラータイプ、例えば、ローカルファイルシステムへのパスや rsync:// ミラーの場合は、無視されます。
- createrepo-flags
- createrepoツールに追加するオプションのフラグを指定します。これは、"cobbler reposync"がレポジトリに対して実行された時に呼ばれます。デフォルトは'-c cache'が指定されています。
arch::
レポジトリが使うアーキテクチャを指定します。デフォルトでは（サーバの）現在のシステムのアーキテクチャが使用されますが、これが望ましくない場合もあるでしょう。これをつかって、デフォルトのアーキテクチャを上書きすると、ソースレポジトリのミラー化が可能になります。（その場合、--arch=srcと指定します。）
設定されているエントリの表示
以下のコマンドはどのようにcobblerを使っているかに関係なく使用できます。"report"は詳細な設定情報を表示します。"list"は単に設定されているエントリの名前だけを表示します。cobblerがどのように設定されているかをチェックする場合はこれらのコマンドを実行してください。
cobbler report
cobbler distro|profile|system|repo report [object-name]
cobbler list
cobbler distro|profile|system|repo list [object-name]
もう一つの手段として、/var/lib/cobbler以下の設定ファイルを見ると同じ情報を参照することが出来るでしょう。
設定されているエントリの削除
もし特定のエントリを削除したい場合、そのエントリを追加する時に指定した名前に対して以下の削除コマンドを実行してください。
cobbler distro remove --name=string
cobbler profile remove --name=string
cobbler system remove --name=string
cobbler remove repo --name=string
編集
もし特定の設定を再び"add"することなく変更したい場合、"edit"を使ってください。エントリを追加した時に指定したのと同じ名前でコマンドを実行します。パラメータリストで渡された全ての値が既存のエントリの設定を更新し、渡されなかった設定はそのままで残ります。
cobbler distro|profile|system|repo edit --name=string [parameterlist]
複製
エントリはコピーすることも出来ます：
cobbler distro|profile|system|repo copy --name=oldname --newname=newname
リネーム
他のエントリで参照されていない場合に限り、エントリはリネームすることも出来ます。
cobbler distro|profile|system|repo rename --name=oldname --newname=newname
設定の再構築
cobbler sync
cobber sync は、舞台裏で何かが変更された時に /tftpbootや/var/www/cobblerの内容を修復・再構築するのに使用されます。つまり、cobblerが設定を解釈してファイルシステムを最新の状態にします。
syncは/var/www/cobbler配下のファイルを手動で編集した時やキックスタートファイルに変更を加えた時は常に実行するようにしてください。ただ実際には、それほど頻繁には実行することはないと思いますが、syncを何度実行しても特に問題があるわけでもないので実行し過ぎということはありません。
cobblerでDHCPの管理を行っている場合（このmanページの高度なトピックのセクションを参照して下さい）は、システムを追加してDHCP設定の生成・再読み込みが行われた後はsyncを実行する必要はありません。
例
インポートのワークフロー
この例では、プロビジョニングのインフラをディストリビューションのミラーから作成する方法を紹介します。その後、デフォルトのPXE設定が作成されますので、デフォルトでシステムはPXEブートし、そのディストリビューションのインストールプロセスが完全に自動化されます。
またネットワーク上のrsyncミラー、マウントしたDVDの場所、ネットワークファイルシステム経由で既に利用可能なツリーも使えます。
cobbler check
cobbler import --path=rsync://yourfavoritemirror.com/foo --name=anyname
# または
cobbler import --path=/mnt/dvd --name=anyname
# または（外部のNASボックスをミラー化せずに使用する場合）
cobbler import --path=/path/where/filer/is/mounted --name=anyname --available-as=nfs://nfs.example.org:/where/mounted/
# ミラーのrsyncが完了するのを待ちます。。。
cobbler report
cobbler system add --name=default --profile=name_of_a_profile1
cobbler system add --name=AA:BB:CC:DD:EE:FF --profile=name_of_a_profile2
cobbler sync
通常のワークフロー
以下の例は、ローカルのカーネルとinitrdファイル（既にダウンロードされているものとします）を使って、二つの異なるキックスタートファイルを使用したプロファイルを作成する場合です。 — 一つはウェブサーバ用の設定でもう一つはデータベースサーバ用の設定です。その後、機器にそれぞれのプロファイルを割り当てます。
cobbler check
cobbler distro add --name=rhel4u3 --kernel=/dir1/vmlinuz --initrd=/dir1/initrd.img
cobbler distro add --name=fc5 --kernel=/dir2/vmlinuz --initrd=/dir2/initrd.img
cobbler profile add --name=fc5webservers --distro=fc5-i386 --kickstart=/dir4/kick.ks --kopts="something_to_make_my_gfx_card_work=42,some_other_parameter=foo"
cobbler profile add --name=rhel4u3dbservers --distro=rhel4u3 --kickstart=/dir5/kick.ks
cobbler system add --name=AA:BB:CC:DD:EE:FF --profile=fc5-webservers
cobbler system add --name=AA:BB:CC:DD:EE:FE --profile=rhel4u3-dbservers
cobbler report
レポジトリのミラー化のワークフロー
以下の例は、二つのレポジトリからレポジトリのミラーを作成し、これらのレポジトリ設定がプロビジョニング対象のシステムに自動でインストールされるようにプロファイルを作成する場合の例です。
cobbler check
# ここでディストリビューションを設定します。
cobbler repo add --mirror=http://mirrors.kernel.org/fedora/core/updates/6/i386/ --name=fc6i386updates
cobbler repo add --mirror=http://mirrors.kernel.org/fedora/extras/6/i386/ --name=fc6i386extras
cobbler reposync
cobbler profile add --name=p1 --distro=existing_distro_name --kickstart=/etc/cobbler/kickstart_fc6.ks --repos="fc6i386updates fc6i386extras"
XEN
仮想化環境の場合、ディストリビューションが仮想用のカーネルとinitrdを使うようになっていることを確かめ、そして上記で示したのと同じ手順に従ってください。また、必要な場合は追加のパラメータを指定してください：
cobbler distro add --name=fc7virt [options...]
仮想イメージのサイズ（ギガバイト）と必要なRAM（メガバイト）で適切な値を指定します。
cobbler profile add --name=virtwebservers --distro=fc7virt --kickstart=path --virt-file-size=10 --virt-ram=512
必要な場合のみ、システムを定義します。koanでもプロファイル名を元にしたプロビジョニングが行えます。
cobbler system add --name=AA:BB:CC:DD:EE:FE --profile=virtwebservers
もしcobblerのインストール直後であれば、"cobblerd" サービスが起動していて、25151ポートがブロックされていないことを確かめてください。
クライアント側の手順についてはkoanのmanページを参照してください。
高度なトピック
PXE メニュー
cobblerは定義された全てのプロファイルのPXEメニューを自動的に生成します。メニューの生成と更新を行うには、"cobbler sync"を実行する必要があります。
メニューにアクセスするには、システムのPXEブート時の"boot:"プロンプトで"menu"と入力してください。何も入力されない場合はネットワークブートはデフォルトでローカル（ハードディスクからの）ブートとなります。"menu"と入力された場合は、システムが利用可能なcobblerプロファイルのどれかを選択してプロビジョニングを行うことが出来ます。
システム（MACアドレス）とプロファイルの関連づけが既にわかっている場合は、単に"system add"コマンドを使ってcobblerにおける関係を定義してしまうほうが便利かもしれません; しかし多くの利用ケース、特に、新しい機器にインストールすると同時にプロビジョニングが完了するような場合など、PXEシステムを用意しておくとよいと思います
こういった動作を望まないのであれば、"cobbler system add --name=default --profile=plugh"を実行して、デフォルトで全てのPXEブートする機器に"plugh"という同じプロファイルを使うようにしてください。再びメニューシステムを利用する場合は、"cobbler system remove --name=default"を実行した後、"cobbler sync"してメニューを再生成してください。
PXEメニューを使ったデプロイだけの場合は、cobblerにsystemレコードを作成する必要はありませんが、これらの両方をミックスすることはとても簡単です。
もう一つ、pxeメニュー設定で生成される全てのファイルはテンプレート化可能だということに注意してください、もしカラースキームやその他の設定を変更したいなら、/etc/cobblerは以下のファイルを参照してください。
キックスタートのテンプレート化
上で出てきた--ksmetaオプションについてはもう少し詳細な説明が必要でしょう。
--kickstartオプションがファイスシステム上のURLを参照している場合（のみ）、--ksmetaを使うとキックスタートファイルをテンプレート化するという高度な機能が使用可能になります。プロファイルの--ksmetaオプションに--ksmeta="foo=7 bar=llama"が指定されている場合、キックスタートファイル上の"$bar"という文字列は全て"llama"という文字列に置き換えられます。
変更を有効にするには、"cobbler sync"を実行して個々のプロファイル／システム向けにカスタマイズしたキックスタートを生成する必要があります。
キックスタートのURL形式がNFSやHTTPといった形式で指定された場合、"--ksmeta"オプションは効果がありません。ただ、これはあくまでもキックスタートを生成するウェブアプリケーションといったようなものを含む、レガシーなインフラとの統合を踏まえた機能という意味で提供されているに過ぎず、いっそのことcobblerにキックスタートファイルの管理を任せてしまうにはよいきっかけとなるでしょう。
キックスタートファイルのテンプレート化は、テンプレート化プログラム／パッケージであるCheetahを使用して処理されています、従ってCheetahのテンプレートで可能なことは全てキックスタートファイルのテンプレートに対して実行することが可能です。詳細は http://www.cheetahtemplate.org/learn.html を参照してください。
Cheetahと連携する場合、"$(this)"のようなシェルのマクロを"\$(this)"という形できちんとエスケープする必要があることに注意してください。そうしないと、sync処理でエラーが発生します。
キックスタートのスニペット
キックスタートファイルのテンプレートでSNIPPET::スニペット名が指定されている場合、/var/lib/cobbler/snippet/スニペット名のファイルがキックスタートファイルのテンプレート中にインクルードされます。つまりよく使うキックスタートの表現を何度も書くことなく再利用するためのものです。またスニペット内にもテンプレート変数を含むことが可能であり、変数はそれを使うプロファイルと/またはシステムの設定に基づいて評価されます。
キックスタートの妥当性チェック
キックスタートの潜在的なエラーをチェックする為に、インストールを実行する前に、"cobbler validateks"を実行して下さい。この機能は、全てのプロファイルとシステムのキックスタートをチェックして、エラーを検出します。pykickstart は 未来のAnacondaのバージョンを意識しているわけではないため、もしかすると誤検出する場合があるかもしれません。"cobbler validateks"はキックスタートのレンダリング出力結果に対して実行されるものであり、キックスタートのテンプレートに対して行われるものではないということを注記しておいた方がいいでしょう。
DHCP設定の管理
cobblerはオプションで、プロビジョニング/管理したいシステムに対する、DHCPと（どのように使うかにもよりますが）DNSの管理で補助する機能があります。これを使うと、cobblerは、インストールされた全てのシステムのデータベースを維持し、それらのシステムのセットアップに関して様々な点で管理の中心点となります。
この機能はデフォルトではオフになっており、/var/lib/cobbler/settingsの'manage_dhcp'を1に設定することで有効となります。ISC dhcpd（デフォルト）かDNSmasqから選択することができ、dnsmasqを選択する場合はmanage_dhcp_modeを'dnsmasq'に設定することで可能となります。もし既にdnsmasqを選択していてISCに戻したい場合は、'isc'を設定してください。
選択に応じて、cobblerは/etc/cobbler/dhcp.templateか、/etc/cobbler/dnsmasq.templateのどちらかを開始点として使用します。このファイルはユーザのネットワーク環境に合わせてユーザが編集する必要があります。処理を開始する前に、ファイルを参照して、どちらのアプリケーション（ISC dhcpdかdnsmasq）がどのように機能しているかを理解してください。
もし既に残しておきたいDHCP設定のデータがある場合（例えば、DHCPが手動で既に設定されていた場合など）は、"cobbler sync"を実行すると以前の設定は上書きされてしまうため、関連する箇所をテンプレートファイルに追加してください。
要約すると、このmanage_dhcpのビットを有効にするだけで、以下の機能が有効になります：
(A) DHCPでホスト名をMACアドレスに自動的に固定で割り振る。 (B) Itaniumマシンとx86/x86_64マシンをPXE環境で比較的シームレスに混在させる（ISCの場合のみ）。 (C) DNSを使用してホスト名をMACアドレスに割り当てる（dnsmasqの場合のみ）。
これらのオプションは、"cobbler system add"コマンドで--hostnameオプションと--ipオプションを使用した場合に有効となります。
Itaniumシステムの名前は"--arch=ia64"パラメータをつけて作成されたディストリビューションにも割り当てる必要があります。Itaniumuシステムが存在する場合、/var/lib/cobbler/settingsの'manage_dhcp_mode'を'isc'に設定し、それらのシステムでPXEを使用するためにシステムのエントリを作成する時に--ipを使用する必要が（現在のところ）あります。
"cobbler sync"が実行される都度、dhcpd.confファイルが更新され、実行されない限りは更新されません、従って、この機能を使用する為には"cobbler sync"を実行することを忘れないでください。オンラインのままでDHCP（とDNS、これはdnsmasqの場合）の更新を行う機能は保留中です。
ENCHANT
通常のプロビジョニング手順は、PXEを使ったベアメタルなインストールも、koanを使った別の方法（既存のシステムをキックスタートする、またはVirtでデプロイする）も使えますが、cobblerにはもう一つ、"enchant"と呼ばれるオプションがあります。
エンチャントは既に定義されている設定（"cobbler enchant"の前に"cobbler sync"を必ず実行してください）を取得して、koanがインストールされていないリモートのシステムに対して適用します。用途が変わったサーバのリプレースやPXE環境が構築できない場合などでこのコマンドを使いたいと思うかもしれません。
基本的には、エンチャントは、remoteのcobblerサーバからkoanを実行することを可能にします。通常のモードで"enchant"を実行すると対象となるマシンのオペレーションシステムをリプレースしますので注意が必要です。
使用方法：cobbler enchant --address=ip|hostname --profile=string
使用方法：cobbler enchant --address=ip|hostname --system=string
どちらの形式でも"--virt=yes"を追加すると、リモートマシンの再プロビジョニングではなく、仮想化イメージのプロビジョニングが行われます。デフォルトはマシン（仮想ではなく）の再プロビジョニングとなります。
例：cobbler enchant --virt=yes --address=192.168.10.10 --profile=fc6xen
エンチャントを使用する前に、/var/lib/cobbler/settingsにkoanのnoarchのRPMの場所（ローカルパス）を設定して、"cobbler sync"を再実行してください。
エンタープライズ環境のユーザは、これはkoanに対するSSHコマンドのラッパー以上のものではないことに気づくかもしれませんが、OSバージョンに関係なく、up2dateやyumが利用できない場合でもkoanをインストールさせることができます。
ツリーのインポート
cobblerは、ファイルシステムのパスやrsyncのミラーなどといった、リモートのソースからディストリビューションとプロファイルを自動追加することができます。これを使うと、新しくプロビジョニング環境を構築するのにかかる時間を大幅に節約することができます。インポートは多くのユーザがその便利さを求める機能であり、使用もシンプルです。
インポートが実行されると、cobblerはディトリビューションの種類を判別して自動的にキックスタートファイルを割り当てます。デフォルトでは、システムに対して、ハードディスクの消去、eth0をDHCPで設定、デフォルトのパスワードを"cobbler"と設定して、プロビジョニングを行います。もしこれを望まない場合は、/etc/cobbler配下のキックスタートファイルを編集するか、cobblerがプロファイルを作成した後に設定されているキックスタートファイルを変更してください。
ミラー化されたコンテンツは自動的に/var/www/cobbler/ks_mirrorに保存されます。
例: cobbler import --mirror=rsync://mirrorserver.example.com/path/ --name=fedora
例2: cobbler import --mirror=!root@192.168.1.10:/stuff --name=bar
例3: cobbler import --mirror=/mnt/dvd --name=baz
例4: cobbler import --mirror=/path/to/stuff --name=glorp
例5: cobbler import --path=/path/where/filer/is/mounted --name=anyname --available-as=nfs://nfs.example.org:/where/mounted/
インポート後、追加されたものを確認する場合は"cobbler list"か"cobbler report"を実行してください。
デフォルトでは、rsyncの処理において、PPC向けのコンテンツ、デバッグ用RPMパッケージ、そしてISOイメージは同期の除外となっています — インポート中に除外されるものを変更するには、/etc/cobbler/rsync.excludeを参照してください。
--available-asでネットワーク的にアクセス可能な場所が指定されない限り、全てのインポートコマンドはインストールツリーのコンテンツを/var/www/cobbler配下にミラー化することに注意して下さい。--available-asは主に、外部のNASボックスや同一マシンの別のパーティションに保存されている、http:// や ftp:// などでアクセス可能なディストリビューションをインポートする場合に使用します。3
デフォルトのPXEブートの挙動
PXEでブートさせる場合に、cobblerにブートさせるシステムのレコードがないと、何が起こるでしょうか？
デフォルトでは、cobblerは/ec/cobbler/default.pxeの内容をブートさせようとし、その内容は（もし編集されていなければ）単にローカルブートプロセスになるということです。管理者がこの挙動を変更したい場合はこのファイルを編集することが出来ます。
PXEブートにおけるデフォルトのcobblerのプロファイルを指定する簡単な方法は、"default"という名前のシステムを作成することです。これを実行すると/etc/cobbler/default.pxeを無視するようになります。以前の挙動に戻す場合は、"default"のシステムに対して"cobbler system remove"を実行してください。
cobbler system add --name=default --profile=boot_this
cobbler system remove --name=default
レポジトリの管理
これは既にコマンドリファレンスの章でほとんどカバーされています。
yumレポジトリの管理はオプションの機能であり、cobblerを使ったプロビジョニングでは必須というわけではありません。しかし、特定のレポジトリをミラーするようにcobblerを設定しておけば、プロファイルとこれらのレポジトリを関連づけて使用することが出来ます。これらのプロファイルを使ってインストールされたシステムは、/etc/yum.repos.d でこれらのレポジトリのミラーを使うように自動設定され、もしサポートしているなら（Fedora Core 6 以降）これらのレポジトリは Anaconda においても使用されます。もし(A) baseのインストールが大量な場合、(B)システムのインストールとアップデートを速く行いたい場合、(C)標準のレポジトリに含まれていない追加のソフトウェアがありプロビジョニング対象のシステムにはそれを含むレポジトリを設定しておきたい場合、などの場合にはこれは便利です。
cobblerのWebディレクトリ、デフォルトでは/var/www/cobbler、に十分な空きスペースがあることを確認してください。
cobbler reposync
cobbler reposync は、"cobbler repo add"で設定されたレポジトリをアップデートするのに使用するコマンドです。ミラー化には時間がかかり、プロビジョニング対象のシステムに、ミラー化されたレポジトリを実際に使う場合に必要なファイルが配置されることを確認する為に、cobbler sync に先立ってcobbler reposyncを実行しなければなりません。もし単にレポジトリを追加して"cobbler reposync"を実行しなかった場合、レポジトリはミラー化されません。恐らく crontab に追加しておきたいと思うかもしれませんが、crontabにおける実行の頻度と出力結果をどこに残しておくかについてはシステム管理者次第です。
yumのreposyncに精通している人の為に言っておくと、cobblerのreposyncはyumコマンドのラッパーです。reposync は全ての必要な手順を実行しませんので、cobblerのミラーをアップデートする場合は"cobbler reposync"を使用してください。またyumのreposyncがyumがサポーチしているもの(http/ftp)しかサポートしないのに対して、cobblerはrsyncとsshのサポートを追加しています。
コアパッケージのyumミラーとしてブートサーバが使用されるのに十分な情報をcobbler importが提供するなら、cobblerは、外部のミラーを使う代わりにcobblerサーバ自体をミラーとして使うようにキックスタートを設定することが出来ます。もしこの機能を望むのであれば、/var/klib/cobbler/settingsのyum_core_mirror_serverを1に設定して（そして"cobbler sync"を再実行）してください。プロダクション環境ではなく、異なるVLAN/ネットワーク環境でプロビジョニングを行う場合はこの機能を有効にすべきではありません。
PXEブートのループ抑制
もしマシンのブートの順序でPXEが一番最初に設定されている場合（ハードディスクよりも前）、/var/lib/cobbler/settingsの"pxe_just_once"フラグを1に変更してください。これで、一旦インストールが完了したマシンに対してはそれ以降PXEブートが成功しないように設定することが出来ます。
特定のマシンに対して再度PXEを有効にする場合は、以下のコマンドを実行してください：
cobbler system edit --name=name --netboot-enabled=1
キックスタートの記録
cobblerにはマシンをキックスタートした状況を記録する機能があります。
cobbler status
statusコマンドを実行すると、マシンがキックスタートを開始した時と最後にファイルが要求された時が表示されます。これはキックスタートにおいて対話形式になってしまっているマシンを記録するのに良い方法です。またcobblerはキックスタートファイルのpostセクションに、マシンがキックスタートを終了したことを通知する特別なリクエストを追加します。
この機能を使うには、キックスタートツリーのファイルが http://server/cblr/... のURLで配布される必要がありますが、"cobbler import"コマンドを使ってrsyncミラーからキックスタートファイルを引っ張ってきた場合は自動的に行われます。
もしキックスタートツリーが別の場所にある場合でも、/var/www/cobbler/localmirror/ディストリビューション名に対するシンボリックリンクを作成し、キックスタートが上記で示した記録用のURLを通じて配布されるようにすれば、このキックスタートの記録機能の恩恵をうけることができます。URLが記録したい各ディストリビューションのキックスタートツリーを指すように http://server/cblr/ のURLを使用するようにしてください。
キックスタートの記録機能のsyslogサポートは、Anacondaがsyslog転送をサポートしている必要があります。RHEL5は良いでしょう、FC6以降もです。URLの記録は、現在のところ、mod_pythonの一部を使用しているので、サーバ上にpython2.3以降を必要とします。より古いディストリビューションでもcobblerサーバとしてうまくサポートできるように今後改善していく予定です。
カスタマイズ
コマンドラインを使うのに対して、エンタープライズ環境のユーザなら/var/lib.cobblerのファイルを直接編集するということも可能。もしユーザエラーが発生した場合、それを修復するには、/var/lib/cobblerは以下のファイルを削除します。また、/etc/cobbler配下にも編集可能な設定ファイルがいくつかあります。
手動で変更した内容を反映させるには"cobbler sync"の実行が必要です。
トリガー
トリガーは、cobblerのソースを編集することなく、任意のサードパーティのソフトウェアと連携する為の手段を提供します。ディストリビューション、プロファイル、システム、レポジトリを追加する時に、/var/lib/cobbler/triggers/add が特定のエントリのタイプごとに実行されます。個々のファイルは実行可能な形式である必要があり、エントリの名前にパラメータとして追加される形で実行されます。削除も同様に機能します — 削除のトリガーは/var/lib/cobbler/triggers/deleteとなります。実行の順序は不定で、cobblerがデフォルトで提供しているトリガーはありません。
API
cobblerは、より高度な管理ソフトウェアでの使用のために、Python APIとしても利用可能です。詳細はhttp://cobbler.et.redhat.comを見てください。
EXIT_STATUS
cobblerのコマンドラインは、成功の場合は0、失敗の場合は0以外を返します。
追加の情報源
cobblerには、ユーザと開発関連の質問・コメント用のメーリングリスト et-mgmt-tools at redhat.com があります。また、執筆時点では、irc.freenode.net（#cobbler）にIRCチャンネルがあります。
作者
Michael DeHaan <mdehaan at redhat.com>
翻訳者
Kuniaki Shimizu <kunkichi at gmail.com>
