Browse Month: November 2009

Velocity Online Conference Fall 2009

来月、Velocity のオンラインカンファレンス Fall 2009 が開催されるようです。O’Reilly では、たくさんのオンラインカンファレンスがあるみたいです。オンラインカンファレンスとは、インターネット上でのカンファレンスでその場でディスカッションなどができるようです。

この Velocity のオンラインカンファレンスですが、今年は次の内容で開催されるということで、さっそく申し込んでみました。

日時は、US-PST(太平洋標準時)で 12/8(火)9:00am – 12:40am なので、日本時間にすると 12/9(水)午前 2:00 – 5:40 になります。かなり深夜から早朝にかけて行われることになります。

料金は、$149 なのですが、通常で $25 の割引があります。また、過去の Velocity の参加者は $50 の割引があります。僕は、過去の Velocity 参加者なので、メールして特別なクーポンコードを発行してもらいました。さらに今回の Velocity Online Conference Fall 2009 の参加者には、次回の Velocity の 25% 割引という得点もあるので次回 Velocity に参加する人は参加するとよいと思います。

今回のオンラインカンファレンスの中では、Rails、Varnish、座談会の話がもっとも興味あります。

今から、とても楽しみです!

MacBook Pro で外付けディスプレイのみを使う方法

MacBook Pro を愛用しているのですが、MacBook Pro で外付けディスプレイのみを使う方法が、どうしても分からなかったのですが、ついにその方法を発見したので紹介します。OSX は、現時点での最新版です。

まずは、準備するところから。

  1. InsomniaX 1.3.5 をインストールして起動しておく
  2. MacBook Pro の Mini Display Port と外付けディスプレイを接続する
  3. ディスプレイの表示モードをミラーにする

これで準備完了です。

  1. MacBook Pro の Mini Display Port から外付けディスプレイをはずす
  2. InsomniaX を有効にする
  3. MacBook Pro の LCD を閉じる(このときは、MacBook Pro 本体の LCD は点灯している)
  4. MacBook Pro に Mini Display Port <-> VGA 変換ケーブルを接続する

ポイントは、3 と 4 の順番です。この順番を逆にしてしまうと、MacBook Pro 本体の LCD が点灯してしまい、本体側の解像度になってしまうので注意してください。

ちなみに作業を終了するときの手順は、次のとおりです。

  1. MacBook Pro の Mini Display Port と外付けディスプレイの接続をはずす
  2. InnosomniaX を無効にする
  3. InnosomniaX のメニューあるいは、MacBook Pro 本体の LCD を閉じてシステムのスリープ状態にする

MacBook のころは順番に関係なくできていたのですが、MacBook Pro になってからできなくなってしまったのかなぁと思ったのですができる方法が見つかってよかったです。

これでデスクの大きなディスプレイのみで MacBook Pro を使うことができます。

Repoview の紹介

先日紹介した EPEL では、パッケージ一覧ページが提供されていました。このパッケージ一覧ページは、repoview というプログラムで作成されたものです。

repoview というプログラムも EPEL と同様にはじめて知ったので、さっそく使っていました。

まず、repoview のインストールは、EPEL からパッケージが提供されているので、簡単にインストールすることができます。

$ sudo yum install repoview

repoview をインストールすると、/usr/bin/repoview コマンドがインストールされます。repoview コマンドを使って、yum リポジトリにあるパッケージ一覧を取得してパッケージ一覧ページすることができます。

repoview コマンドの使い方は、次のとおりです。

$ repoview –help

使い方: repoview [オプション] リポジトリディレクトリ

オプション:
–version プログラムバージョンを表示して終了します
-h, –help ヘルプメッセージを表示して終了します
-i IGNORE, –ignore-package=IGNORE “foo-0-1.0-1″のように無視したいパッケージ名を指定します
-x XARCH, –exclude-arch=XARCH “-x src -x ia64″のように無視したいアーキテクチャーを指定します
-k TEMPLATEDIR, –template-dir=TEMPLATEDIR repoviewディレクトリのテンプレートディレクトリを指定します(デフォルトは、/usr/share/repoview/templates です)
-o OUTDIR, –output-dir=OUTDIR repoviewページを生成したときのサブディレクトリ名です(デフォルトは、”repoview” です)
-s STATEDIR, –state-dir=STATEDIR このディレクトリに生成する状態トラッキングデータベースを入れるディレクトリ名です(デフォルトは、出力先ディレクトリに出力します)
-t TITLE, –title=TITLE リポジトリの説明用のタイトルを指定します(デフォルトは、”Repoview” です)
-u URL, –url=URL     RSS Feed を生成するときの URL を指定します、例えば “http://fedoraproject.org/extras/4/i386” と指定します、指定しない場合は RSS の生成がスキップされます
-f, –force     repmod のチェックサムが変更されていなくても、強制的に再生成します
-q, –quiet    致命的なエラーを除いて、何も出力しないようにします
-c COMPS, –comps=COMPS    comps.xml ファイルを使うときに指定します(デフォルトは、オフです)

例えば、cobbler で管理しているリポジトリの場合は、次のように使います。

$ sudo repoview -t “yum.example.com – x86_64” -u “http://exmaple.com/cobbler/repo_mirror/hoge-x86_64/repoview/” /var/www/cobbler/repo_mirror/hoge-x86_64

なお、reposync してしまうと repo_mirror ディレクトリがリセットされてしまうので、createrepo したあとは、再度 repoview を実行する必要があります。

独自にローカル yum リポジトリをたてている場合、repoview を使うと提供しているパッケージ一覧がチェックでき、いつどんなパッケージを追加したのか、後から分かるのでとても便利です。

はじめての EPEL

RHEL, Centos 向けに EPEL というボランティアベースの拡張パッケージが提供されているリポジトリがあることを知りました。

EPEL とは、次のようなリポジトリです(About EPEL から意訳)。

エンタープライズ Linux 用の拡張パッケージ(略して EPEL)は、Fedora プロジェクトからのボランティアベースの貢献によって作成された Red Hat Enterprise (RHEL) 向けの高品質な追加パッケージのリポジトリで、CentOS あるいはその他同等の Linux 互換になっています。Fedora は RHEL の上流であり、EPEL 向けの追加パッケージは Fedora リポジトリを起源にしており RHEL 向けに提供されています。

ということで、高品質な追加パッケージが提供されている便利なリポジトリです。

以前、rpmforge というサードパーティ製のリポジトリを使っていたことがあったのですが、一部のパッケージでトラブルが発生して以来使っていませんが、EPEL は高品質そうなので、さっそく CentOS に導入してみました。

まず、EPEL の RPM をダウンロードします。

$ wget http://download.fedora.redhat.com/pub/epel/5/x86_64/epel-release-5-3.noarch.rpm

$ sudo rpm -i epel-release-5-3.noarch.rpm

EPEL パッケージをインストールすると、/etc/yum.repos.d/epel.repo がインストールされて EPEL の yum リポジトリを使うことができます。

例えば、ganglia パッケージを取得してみると、次のようになります。

$ sudo yum info ganglia

Available Packages
Name       : ganglia
Arch       : i386
Version    : 3.0.7
Release    : 1.el5
Size       : 91 k
Repo       : epel
Summary    : Ganglia Distributed Monitoring System
URL        : http://ganglia.sourceforge.net/
License    : BSD
Description: Ganglia is a scalable, real-time monitoring and execution environment
: with all execution requests and statistics expressed in an open
: well-defined XML format.

Name       : ganglia
Arch       : x86_64
Version    : 3.0.7
Release    : 1.el5
Size       : 91 k
Repo       : epel
Summary    : Ganglia Distributed Monitoring System
URL        : http://ganglia.sourceforge.net/
License    : BSD
Description: Ganglia is a scalable, real-time monitoring and execution environment
: with all execution requests and statistics expressed in an open
: well-defined XML format.

EPEL で提供されているパッケージ一覧は、x86_64 の場合はここから確認することができます。提供パッケージ一覧をざっと見たところ、nagios、monit、ganglia、memcached、munin、など公式では提供されていないたくさんのパッケージが提供されています。いずれも品質重視のためか、バージョンが若干古いですが、自分でパッケージを作成する手間を考えると、とても便利な yum リポジトリといえるでしょう。

今後は、EPEL は本番環境でもミラーして使っていきたいと思いますが、何かの事情で新しいバージョンを必要になったときには EPEL から SRPM を取得して改良する方針にしていこうかなと思います。

hbstudy #5 に行ってきた

株式会社ハートビーツが開催している hbstudy #5 に行ってきました。hbstudy はインフラエンジニア向けの勉強会です。

今回は、次のタイトルで発表がありました。

個人的には、業務ではほとんど MySQL を使っていますが、すこしだけ業務 PostgreSQL を使ったことがあります。

PostgreSQL の話は、かなりボリュームのある内容を1時間という限られた時間の中で発表してくださいました。PostgreSQL のアーキテクチャーの話、Vacuum、PostgresQL の設定をする上のポイントなど、かなり実践投入向きな説明で勉強になりました。PostgreSQL を使う機会があったら、改めてポイントを確認したいと思います。

次の MySQL の話は、松信さんの話ということで、かなり期待していましたが、期待以上の話でした。

以下、メモになります。

  • いかにしてデータベース内のデータサイズにしていくかが重要
  • カラムの型は、最低限のものにする
  • Blog/Text は、無駄になることが多い
  • InnoDB は、ブロック単位の I/O になって、ブロックにはレコードがそれぞれ含まれている
  • 違うテーブルは、必ず別のブロックになる
  • Falcon は、TEXT 型の列を別領域に保存する
  • PBXT は、一定以上の長さの列を別領域に保存する
  • Explain の Using Index があると、Index が使われていることになる
  • MySQL 5.1.41 に含まれている InnoDB plugin 1.0.5 には、innodb_old_blocks_time というパラメータが追加されているが、これは InnoDB の old という領域に保存していく時間をミリ秒単位で指定することができる(SET GLOBAL innodb_old_blocks_time = 1000; で設定することができる)
  • Linux のチューニングのポイントは、次のとおり
  • /proc/sys/vm/swappiness = 0;
  • 0 ならファイルシステムキャッシュ優先、100 なら A 優先(デフォルトだと 60)
  • ext3: InnoDB なら writeback でもあり (double buffer)、dir_index, noatime(realtime)
  • xfs: 実績が少ないとのこと
  • ext2: あえて ext2 を使う、ジャーナリングが無いための高速(kazuho さんは、ext2 を使っているとのこと)
  • btrfs(zfs): コピーオンライト
  • cat /proc/net/dev, mtstat = dstat
  • SSD もライトキャッシュが必要だが、RAID コントローラーが SSD に最適化されていないといけないの要注
  • PCI-E 型の SSD にも、高価だが注目するとよい
  • HDD を使っているときは、あえて full table scan するという選択肢もある
  • メモリが何よりも最速

ということで、自分の過去のデータベース設計に後悔したことは言うまでもありませんが、データベースのチューニングまわりは参考になる話ばかりでした。

MySQL を使っている以上、InnoDB ストレージエンジンの構造は理解しておくべきだと思いました。

hbstudy #6 の当日の資料は、それぞれ公開されています。

rpmbuild を便利するスクリプト

rpmbuild を使って、RPM をビルドしようとするとき、BuildRequires の設定がある場合にパッケージがインストールされないというメッセージを見る機会が増えてきた。

開毎回必要なパッケージを、メッセージを確認してから手動でインストールするのがかなりめんどうになってきたので、簡単な rpmbuild のラッパースクリプト auto-rpmbuild.sh を書いてみた。

このスクリプトでは、おもに次のような機能を提供します。

  • 指定された SPEC ファイルが存在しない場合は、.rpmmaros の topdir/SPECS を自動的に参照する
  • rpmbuild –nobuild で RPM のビルドをテストしてエラーだった場合のメッセージが、「** is needed by **」の場合は、必要なパッケージ sudo yum install でインストールする

auto-rpmbuild.sh の使い方は、rpmbuild とまったく同じで、次のように使います。

$ auto-rpmbuild.sh -ba ~/rpmbuild/SPECS/hoge.spec

もしくは、SPEC ファイルのフルパスを指定するのがめんどくさいという場合は、次のように実行します。

$ auto-rpmbuild.sh -ba hoge.spec

実は、このラッパースクリプトを作成する前に、既存のツールでできないかどうか調査したところできない様子だったので、ラッパースクリプトを作成しました。

auto-buildrequires という、まさに * それ * っぽいものを見つけたのですが、これは RPM をビルドしたあとに BuildRequires に指定するべきパッケージ一覧を列挙するツールのようだったので、今回の要件にあいませんでした。

個人的には、あまり野良スクリプトを増やしたくないので、もし既存のツールでできるようであれば、ぜひコメントで教えてください!

logwatch を無効にする

CentOS でサーバ運用をしていて、サーバ台数がだんだんと増えてくると、logwatch のメールをまったく見なくなります。logwatch には、その日のサーバの状態が書かれてていてチェックすることでサーバの状態を把握することができます。しかし、サーバ台数が増えてくると、毎日すべてのサーバの logwatch のメールを見ていると時間がかかってきてしまいます。基本的に、すべて Nagios で監視しているので logwatch のメールを送信しないように logwatch を無効にしてみました。

CentOS の logwatch を無効にするには、/etc/cron.daily/0logwatch を削除するだけです。

puppet だと、次のように記述します。

file { “/etc/cron.daily/0logwatch”:
ensure => absent,
}

これで、logwatch を毎朝実行しなくなるので、logwatch のメールが受信しなくてすむようになりました。

一人でサーバ運用していると、こういった日々の小さな改善が大事になってくると、しみじみと思いました。

サーバの消費電力を測定する

インフラエンジニアたるもの、自前でサーバを調達して運用している場合は、自分が使っているサーバの消費電力を測定することはとても重要です。サーバの消費電力が分からないと、ラックにあと何台のサーバを収めるか把握できません。

サーバの消費電力を計測するには、クランプメータという機械が必要です。

今回は、小型クランプメータの三和電気計器の DCL10 を購入してみました。これにした理由は、そこそこの精度で、価格も安いからです。あと、あわせてラインセパレーターもあわせて購入しました。ラインセパレーターを使うと、感度倍率を1倍あるいは10倍にして測定することができます。

もちろん、インフラエンジニアたるもの自分で持っていたいということで、自費で購入しました。

server_power

さっそく、このクランプメータとラインセパレーターを使って、業務で使用している DELL のサーバの消費電力を測定してみました。

測定方法は、次のとおりに行いました。

  • サーバの電源ケーブルとコンセントの間に、上のラインセパレーターを挟んで測定する
  • CentOS 5.x x86_64 をインストールした状態で、アイドル時と stress を使って高負荷時(ロードアベレージが CPU コア数と同じくらいなったあたり)で感度倍率 10 倍のところで測定した

DELL サーバの消費電力は、次のとおりです。

DELL PowerEdge R200

  • CPU: Xeon X3210 x 1
  • RAM: 8GB
  • Disk: SATA 160GB x 1
  • idle: 1.08A
  • max: 1.53A

DELL PowerEdge R300

  • CPU: Xeon L5410 x 1
  • RAM: 8GB
  • Disk: SAS 300GB x 1
  • idle: 0.99A
  • max: 1.30A

DELL PowerEdge 1950 III(販売終了モデル)

  • CPU: Xeon L5410 x 2
  • RAM: 8GB
  • Disk: SATA 1TB x 1
  • idle: 1.60A
  • max: 2.36A

DELL PowerEdge SC1435(販売終了モデル)

  • CPU: Opteron 2376 x 2
  • RAM: 8GB
  • Disk: SATA 1TB x 1
  • idle: 1.46A
  • max: 2.27A

DELL PowerEdge R610

  • CPU: Xen L5530 x 2
  • RAM: 16GB
  • Disk: SATA 500GB x 2 (HW RAID 10)
  • idle: 1.32A
  • max: 2.06A

所感は、次のとおり。

  • Xen 5500  番台の低電圧版(L がついているもの)は、かなり消費電力が少ない
  • Xen 3200 番台(今は 3300 番台)は、消費電力が大きいが、Xeon 5400 番台低電圧版もそれほど大きく変わらない

来週には、R410 を試しに導入してみる予定ですが、R610 の CPU と同じなのでほぼ変わらないはずです。

サーバの消費電力をちゃんと測定して、よりよいサーバ運用をめざしたいものですね。

# 2009.11.12 追記

  • ディスク情報を追記しておきました

CentOS 5 の初期設定

CentOS 5.x をインストールしたあと、いろいろと初期設定を行っています。今は、サーバ用途の場合 kickstart の %post セクションでいろいろな初期設定をまとめて行って自動化しています。kickstart は、別の機会に公開するとして、今回は %post セクションで行っている初期設定を順番に紹介します。紹介する順序は、順不同です。

  • NOZEROCONF を設定する

余計なネットワーク経路を作らないために、/etc/sysconfig/network に次の設定を追加します。APIPA という仕組みを使う場合は必要です。

NOZEROCONF=yes

  • IPv6 を無効にする

IPv6 を使っていないので、/etc/modprobe.conf に次の設定を追加します。

alias net-pf-10 off
alias ipv6 off

  • ifdown-eth にバッチをあてる

bonding を使っている場合、ifdown-eth がおかしいので、次のようなパッチをあてます。bonding を使っていない場合は、特にパッチをあてる必要もないです。

/usr/bin/patch /etc/sysconfig/network-scripts/ifdown-eth << EOF
60c60,62
<

>     for target in \\$(cat /sys/class/net/\\${DEVICE}/bonding/arp_ip_target) ; do
>         echo “-\\${target}” > /sys/class/net/\\${DEVICE}/bonding/arp_ip_target
>     done
EOF

  • SSH デーモンの設定でパスワード認証を無効にして、公開鍵認証のみに設定変更する

/etc/ssh/sshd_config に、次のようなパッチをあてます。

/usr/bin/patch /etc/ssh/sshd_config << EOF
58c58
< #PasswordAuthentication yes

> PasswordAuthentication no
60d59
< PasswordAuthentication yes
73,75c72
< #GSSAPIAuthentication no
< GSSAPIAuthentication yes
< #GSSAPICleanupCredentials yes

> GSSAPIAuthentication no
EOF

さらに、次の設定を追加します。
#
# local configuration
#
PermitRootLogin without-password
PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no

  • 不要なサービスを無効にする

サーバ用途として、使用しないサービスを無効にします。次のような簡易スクリプトを書いておくと便利です。サービスのリストは、自分の環境で置き換えるとよいでしょう。

#!/bin/sh
function get_cmd() {
echo ‘acpid auditdi autofs avahi-daemon bluetooth cups firstboot gpm hidd ip6tables mcstrans mdmonitor netfs nfslock pcscd restorecond rpcgssd rpcidmapd sendmail xfs yum-updatesd’
}
for cmd in `get_cmd`; do
/sbin/chkconfig $cmd off
/etc/init.d/$cmd stop
done

  • OOM Killer を無効にする

Linux には、メモリ不足になってしまったときプロセスを任意で強制終了させる OOM Killer という仕組みがありますが、これを無効にしてプロセスがメモリ不足で落ちるようにします。どちからというと、そのほうがお行儀がよいです。

/etc/sysctl.conf に、次の設定を追加します。

# disable OOM Killer
vm.overcommit_ratio = 99
vm.overcommit_memory = 2

  • iptables を有効にして設定する

Linux のファイアーウォールである iptables を有効にして、設定します。

iptables の設定は、通常はコマンドで行うものらしいのですが、オプションがまったく覚えることができないので、/etc/sysconfig/iptables  を 600 で作成して、次の内容で作成します。

*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [504:56964]
-A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
-A INPUT -p tcp -m tcp –dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp –dport 25 -j ACCEPT
-A INPUT -p tcp -m tcp –dport 80 -j ACCEPT

上の設定では、内側からの接続はすべて通して、外側からの接続は SSH、SMTP、HTTP ポートだけ許可するという内容になります。

サーバの用途に応じて、開放するポートを設定します。bonding を組んでいる場合は、eth0 ではなく bond0 になります。

  • Ctrl + Alt + Del による再起動を無効にする

サーバの操作中に誤って Ctrl + Alt + Del キーを押して、サーバを再起動させないように /etc/inittab に次のようなパッチをあてます。

/usr/bin/patch /etc/inittab << EOF
31c31,33
< ca::ctrlaltdel:/sbin/shutdown -t3 -r now

> # Trap CTRL-ALT-DELETE
> #ca::ctrlaltdel:/sbin/shutdown -t3 -r now
> ca::ctrlaltdel:/usr/bin/logger ‘CTRL-ALT-DELETE trap is disabled’
EOF

この設定をしておくと、Ctrl + Alt + Del を押したときにログに残ります。

  • デフォルトの yum リポジトリを削除する

ローカルで yum リポジトリをミラーしている場合、デフォルトの yum リポジトリは不要なので設定を削除します。

/bin/rm /etc/yum.repos.d/CentOS-Base.repo
/bin/rm /etc/yum.repos.d/CentOS-Media.repo

  • 管理ユーザを作成する

さきほどの SSH の設定で root による SSH 接続ができなくなるので、専用の管理ユーザを作成して SSH 経由でログインできるようにします。

/usr/sbin/useradd -g hoge -s /bin/zsh hoge
/bin/mkdir ~hoge/.ssh
/bin/chmod 700 ~hoge/.ssh
/bin/cat << EOF > ~hoge/.ssh/id_rsa
SSH の秘密鍵
EOF
/bin/chmod 600 ~hoge/.ssh/id_rsa
/bin/cat << EOF >~hoge/.ssh/id_rsa.pub
SSH の公開鍵
EOF
/bin/cat << EOF > ~hoge/.ssh/authorized_keys2
SSH 接続を許可したいサーバの SSH 公開鍵
EOF
/bin/chmod 600 ~hoge/.ssh/authorized_keys2
/bin/cat << EOF > ~hoge/.ssh/config
Host *
Compression yes
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
EOF

  • su を無効にする

/etc/pam.d/su に、次のようなパッチをあてます。

/usr/bin/patch /etc/pam.d/su << EOF
6c6
< #auth         required        pam_wheel.so use_uid

> auth          required        pam_wheel.so use_uid
EOF

  • sudo を可能にする

/etc/sudersを、次の内容で書き換えます。CentOS のデフォルトの suders の設定内容がすこしきつく、若干扱いにくいので次の内容だけにしておきます。

%hoge  ALL=(ALL)       ALL

  • シリアルリダイレクトを有効にする

IPMI を SOL 経由で Linux のコンソール画面をみることができるようにシリアルリダイレクトを有効にします。

詳しい設定内容は、こちらを参照してください。

あとは、ウェブサーバ、メールサーバ、データベースサーバ、などサーバの用途に応じた設定を個別で行います。

これには、Puppet を使うとかなり便利なので、実際にどんなふうに使っているかは、別の機会に紹介したいと思います。

facter を拡張する方法

puppet に付属している facter は、とても便利ですがデフォルトで提供されているもの以外にも自分独自に facter を簡単に拡張することができます。

facter を拡張して、”hardware_platform” という変数を拡張して作る方法を公開しておきます。
なお、Puppet バージョン 0.24.7 を想定しています。0.25 系は方法が違うので注意してください。

まず、次のような <MODULEPATH>/modules/plugins/facter に “hardware_platform.rb” を作成します。なお、必ず作成する ruby のファイル名と facter の変数名は同じでないといけません。

# hardware_platform.rb
Facter.add(“hardware_platform”) do
setcode do
%x{/bin/uname -i}.chomp
end
end

とは、puppet の設定ファイルがあるディレクトリ、デフォルトは /etc/puppet だけれど、次のコマンドで確認できます。

$ sudo /etc/init.d/puppetmaster genconfig | grep modulepath
modulepath = /etc/puppet/modules:/usr/share/puppet/modules

ちなみにカスタム facter を置く場所はどこでも大丈夫です。
作成したカスタム facter を ruby 側でロードできるように環境編集 RUBYLIB を設定します。

$ export RUBYLIB=<MODULEPATH>/module/plugins

RUBYLIB は、ruby の検索パスなので facter まで設定しないように注意します。
この状態で、次のコマンドを実行すればカスタム facter の動作を確認することができます。

$ facter hardware_platform
x86_64

まずは、この状態でカスタム facter を作りこんでいきます。

次に作成したカスタム facter を Puppet クライアントへ配布するには、Puppet クライアントの設定が必要になります。
具体的には、puppet.conf の main セクションに次の設定を追加して puppet クライアントを再起動します。

pluginsync = true
factpath = $vardir/lib/facter

あとは、Puppet サーバと同期すれば自動的に Puppet サーバからカスタム facter を転送されてきます。転送されてきたカスタム facter は、factdest パラメータにコピーされて自動的にロードされます。デフォルトは、/var/lib/puppet/lib/facter です。

Puppet クライアントで、カスタム facter の動作をテストしたいときは、次のコマンドを実行します。

$ sudo facter -p hardware_platform
x86_64

最後に拡張した Facter は、次のように ruby プログラムから簡単に使うことができます。

require ‘facter’
puts Facter[:hardware_platform].value

0.25 系での方法は、別の機会に紹介したいと思います。

参考資料