BSD

FreeBSD Daily Topics：2011年12月22日　独立性の高い軽量ports管理ツール「portmaster」｜gihyo.jp … 技術評論社

portmasterが記事にのっていたので、ついでに手元のjailを更新する。

親側でportsを更新してから

ezjail-admin update -P

各jailでbaseにあるxzをのぞいて更新。

portmaster --no-confirm -ady -x xz

portscleanがないので手動で後始末。

# find /var/ports -type d -name work -depth 3 -exec rm -r '{}' ';'

ドメインをとったので、そのためにウェブサーバをjailで構築。入口はpoundを使い、ホスト名で分岐している。

まずは、パッケージをバイナリでインストール。久しぶりなのでports以外でパッケージをいれるためにはどうすればいいか、Handbookを探してしまった。

# pkg_add -r lighttpd
# pkg_add -r php5

/usr/local/etc/lightttpd を編集。

modules.confでfastcgiを有効に。ついでに、ロードバランサとしてpound経由にしたので、extforwardモジュールを使いロードバランサを指定してログに元のIPアドレスが出るようにしておく。

##
## FastCGI (mod_fastcgi)
##
include "conf.d/fastcgi.conf"
include "conf.d/extforward.conf"

server.modules += ( "mod_extforward" )
extforward.forwarder = (
    "192.168.xxx.xxx" => "trust"
)

fastcgi.server = ( ".php" =>
                   ( "php-local" =>
                     (
                       "socket" => socket_dir + "/php-fastcgi-1.socket",
                       "bin-path" => "/usr/local/bin/php-cgi",
                       "broken-scriptfilename" => "enable",
                        "min-procs" => 2,
                        "max-procs" => 5,
                        "bin-environment" => (
                                "PHP_FCGI_CHILDREN"     => "1",
                                "PHP_FCGI_MAX_REQUESTS" => "5",
                        )
                     )
                   )
)

lighttpdの起動でエラーが出たので、IPv6を無効化。

# service lighttpd start
Starting lighttpd.
2011-11-27 10:19:00: (network.c.203) socket failed: Protocol not supported
/usr/local/etc/rc.d/lighttpd: WARNING: failed to start lighttpd

server.use-ipv6 = "disable"

favicon.icoが表示できないので、conf.d/mime.confに指定を追加

  ".ico"          =>      "image/x-icon",

コンテンツは以前実験したPukiwikiをコピーして、無事稼動。

qjail は、従来のezjailより後に設計された第4世代のjail管理システム。前から気になっていたので、テストがてらに入れてみる。大規模管理にむいていて、いきなりflavorから10個新jailを作る、とかもできるらしい。

qjail for Freebsd jail system から qjail-portMakefiles.tar.bz2 をダウンロードして /usr/ports で展開すると、sysutils/qjail ができる。

# cd /usr/ports/sysutils/qjail
# make config-recursive
# make install

更新されたのかdistinfoが妙でエラーが出ていたので、修正。

SHA256 (qjail-1.0.tar.bz2) = c28fd8663f96c5bb03f6a497d7a1953ed7ecc2f8f2690ed17a8760f73a10cf94
SIZE (qjail-1.0.tar.bz2) = 40214

あらためて、インストール。

# make install

qjail-intro(8) と qjail(8) に目を通す。

/usr/local/etc/ に qjail.conf.sample が生えているので、qjail.conf として編集。

# cp qjail.conf.sample qjail.conf
# chmod u+w qjail.conf
# vi qjail.conf

jail用のストレージを /jail に確保してあるのでそちらに向けるのと、ftpサーバを近いjpに変更。

qjail_jaildir=/jail
qjail_archivedir=/jail/archive
qjail_ftphost=ftp.jp.freebsd.org

起動スクリプトは qjail2 と qjail-jail2 の二種類がある。後者は前者のクローンで、大規模用に起動メッセージを省略したもの、らしい。

/etc/rc.d に qjail_enable="YES" を追加し、/usr/local/etc/rc.d/qjail2 を qjail2 として ln しておく。

で、ここまでやった所で目的を思いだす。そういえば vnet がezjailで使えないから止めたんだっけ。qjail2の中を覗いて vnet があるかチェック…。

…うん、無いね。

だとすると、あまり現時点での旨味はないかも。ezjailでいいや。

というわけで、さくさくと作りなおす。結局vnetを使って遊びたければ、(nullfsでの省力化は普通にするとして)手動でjail管理するしかないのか。

まずはサーバ類を分類するために、FreeBSD 8.2RELEASEでjailの受け口をつくっておく。unboundとかdhcpdとかはこちらに移す予定。

最初8.0でつくっていたが、bootonlyのディスクだと当然ftpサーバから取ってこれるわけもなく、8.2で素直にやりなおす羽目になった。

VMWare Toolsがportsのvmware-guestd6でうまく入らなかったので、perlだけインストールしてそのまま付属のVMWare Toolsを導入。若干厄介だったが、まあこんなものだろう。

ネットワークをvxnにして、メモリ管理ができるようになったので本日の作業は終了。

dnsops MLで見たI.root-servers.net への IPv6 アドレス追加に伴う設定変更についてを受けて、Unboundのルートヒントを更新

まずはINTERNIC.NETよりファイルを取得。

# ftp ftp://FTP.INTERNIC.NET/domain/named.cache

unbound.conf を探すとroot-hintsがあるので、先程取得したファイルを指定。

# file to read root hints from.
# get one from ftp://FTP.INTERNIC.NET/domain/named.cache
# root-hints: ""
root-hints: "/usr/local/etc/unbound/named.cache"

反映して終了。

# service unbound retart

portauditでdns cache jailにunboundの警告がきていたので、対応。CVE-2011-1922の件らしい。どういう脆弱性かというと、特定のDNSクエリを受けた時にエラーを返すのだが、そのエラーにより空のUDPメッセージを作成されてしまい、サービス妨害になるというもの。

条件として、interface-automatic option が設定されている必要があり、configure時に-enable-checking か –enable-debug をつけていなければ問題はないらしい。FreeBSD portsやRHLE/Fedora, Debian/Ubuntuあたりは標準の設定では問題なし。

まずはJailの親でupdate。

# ezjail-admin update -p

子供も同様に更新。unboundのついでに、wwwのjailも更新しておく。大分色々とたまっていて長くかかった。perlのライブラリ系は結構更新が多い。

# portmaster -ady -x xz

FreeNAS 8.0がリリースされたようなので、試してみる。VMWare ESXiに載せて適当に設定。scsiは駄目だったが、ネットはvmxnetを素直に解釈してくれるのは嬉しい。

まだローカライゼーションは間に合っていないようで、インタフェースは英語のみ。なんとでもなるけど、iSCSIとか未知のものを試す時には日本語があった方が便利。

最初がDHCP強制なのでタイムアウトが面倒。DHCPなんてないゾーンで固定IPで運用するので、変更するまでが大変だった。

ZFSがメモリを喰うというのは本当らしい。25GBx2で500GBのボリュームを作ってみたら、800MB程使っていた。普通に組むなら大人しくUFSでRAIDはハードウェアまかせがいいのかな。

速度は感覚的にはTimeCupsuleがやっているよりは早い。比較元が遅すぎるだけだが。

本体をアップデートして、basejailをアップデートして、各jailのportsをアップデートするだけの簡単なお仕事。

半日かかってなんとか終了。

将来Railsを試したくなったり、仮想ホストを色々と展開してみたいので、リバースプロキシ兼バーチャルホスト振り分けとしてPound(www/pound)を導入する。

FreeBSDだとportsのwww/poundにあったので、そのまま導入。設定ファイルはmanを参考に/usr/local/etc/pound.cfgとして作成。

試しにport 8080で受けて今port 80で動かしているウェブサーバにリダイレクトをかけてみたところ、普通に通ってくれた。ログがsyslogなのでノーマルのsyslogでは微妙に振り分けしにくいかもしれないが、まあそれはそれでなんとでもなるか。

poound側でVirtualHostの振り分けをしてしまうと、ApacheのVirtualHost設定が働いてくれないようなので、設定はしてみたもののひとまず現行のままにする。いざとなったらルータで捻じ曲げればOK。

現在はMuninでローカル環境の稼動監視をしている。

だが、Muninだと微妙にプラグインが書きにくく、仮想マシンの台数を増やす度に色々と入れなければいけないので、Pandora FMSを試してみる。

Pandora FMSはエージェントとサーバとコンソールに分かれていて、エージェントはほぼ素のPerlで動く。サーバはエージェントからの情報を収拾し、コンソールはウェブから操作できるようにする。

今回は公式のVMを使いサーバとコンソールを構築。エージェントは、Unix用をとってきてFreeBSDで展開し、# pandora_agent_installer --installで導入。
/usr/local/etc/pandora/pandora_agent.confのserver_ipをサーバのIPアドレスに変えて最低限の構築が完了。サーバ側でエージェントを認識して、各項目を出してくれるようになる。

具体的な監視項目(モジュール)は、サーバ側から設定するものとエージェント側から設定するものがあるが、ローカルの方が都合が良いので主にエージェント側で構築。

例えば、pandora_agent.confで以下のように書けばメールログを読んでローカルへの配送メールのカウントができる(はず)

module_begin
module_name Mail Delivered
module_type generic_data_inc
module_exec grep lmtp /var/log/maillog | grep 'status=sent (250' | wc -l | awk '{print $1}'
module_description Postfix statistics received mail (count)
module_end

それでも足りなければ、簡単なXMLを吐き出すようにしたスクリプトをplugins以下に置いて、呼び出す。

module_plugin nsd /var/log/nsd.log

適当に作った中身はこの程度。ちょっと面倒だけど、書こうと思えばconfの中にも直接書けたかも。

#!/bin/sh

LOGFILE=$1

if [ -z $1 ]; then
        exit 1
fi
if [ ! -f $1 ]; then
        exit 1
fi

STATLINE=$(grep NSTAT $1 | tail -1)

#################### A
echo '<module>'
echo '<name><![CDATA[Query A]]></name>'
echo '<type><![CDATA[generic_data_inc]]></type>'
echo -n '<data><![CDATA['
echo -n $(echo $STATLINE | cut -f 7 -d" " | cut -f 2 -d"=")
echo ']]></data>'
echo '<description>DNS Query</description>'
echo '</module>'
(以下同様に各クエリを設定)

公式のプラグイン置き場はあるけれども、いくつか使ってみた結果としては微妙なところ。Linuxだと良いのだろうけど、echoの-eオプションなんてBSDにはないです、とか。決め打ちパス止めてとか。nagiosのプラグインを流用できるそうなので、多分普通はそっちにするのでしょう。

サーバ側のプラグインの使い方がいまいちよくわからないので、なんとかしないと。

FreeBSDのjail管理(というかportsまわり管理)はいまいちよくわからないなあ、と思いながら、更新作業。

FreeBSD 8.2-RELEASE Announcementを見て手順通りにupgrade。

# freebsd-update upgrade -r 8.2-RELEASE
# freebsd-update install
# shutdown -r now
# freebsd-update install
# freebsd-update install
# shutdown -r now

mergemaster(8)も実行しておく。今回は特に困るような変更はなし。

# mergemaster

Jail も対処。

# ezjail-admin update -b
# ezjail-admin restart
# ezjail-admin update -P
# PORTSDIR=/jail/basejail/usr/ports/ portsdb -u

と、ここで個々のportupgradeをしようとして気がついた。portupgradeはrubyに依存している。なんというか、同じスクリプト言語が色々なjailに入っているのは凄くみっともない。

とうわけで、FreeBSD Handbookのports項を参考にしつつ、全jailにportmasterを入れて更新。portupgradeと違い依存が無いので非常に楽。

# cd /usr/ports/ports-mgmt/portmaster
# make all-depends-list
# make config-recursive
# make install clean

何故か-Lでチェックした時にxzにIGNOREがついていたので、除外して更新。各jail環境するので少々面倒。

# portmaster -L  # update check
# portmaster -ay -x xz # ports update (exclude xz)

…何故portupgradeが推奨されて、portmasterではないのかを十分に理解したつもりになる。細かく制御できるのはいいけれども、放置して一括更新にはあまり向かない。

ついでに、ホスト側にjailaudit を導入。各jailに一々portauditを導入しなくても、脆弱なバージョンのチェックをしてくれるらしい。

/etc/periodic.conf (無ければ作成)に以下を追記。これで、無事dailyで監査してくれるはず。

daily_status_security_jailaudit_enable="YES"

# jailaudit generate
# jailaudit mail -  ALL

何故かウェブサーバのapache22のupgradeでハマる。apachectlで確認するとモジュールをロードしているはずなのに、httpd.confに書いたディレクティブが有効にならない。結局、LoadModuleの位置が悪く、IfModuleした後にLoadしているのが原因と判明。今迄はゆるかったのか、厳密になったのか。わかってしまえば対応は楽なのでさっさと復帰。

葉っぱ日記を参考に、ApacheでX-XSS-ProtectionとX-Content-Type-Optionsを指定した。

<IfModule headers_module>
        Header append X-XSS-Protection 1
        Header append X-Content-Type-Options nosniff
</IfModule>

書いておくと、一部の攻撃が通用しにくくなるので、まあ気休めですね。

「はてなダイアリーキーワードふりがなリスト」をSKKの辞書に変換を参考に、AquaSKKに辞書を追加してみた。

OSXですると面倒なので、VMのFreeBSDでskktoolsを入れてそちらで作業。なんとなくEUC-JPではなく途中だけUTF-8で処理してみた。

AquaSKKの辞書にそのまま追加してもあまり面白くなかったので、「ダイナミック補完」を有効にして、先読み候補が出るようにしてみる。1個だけならさほどうるさくないのでまあいいかな。結構意外な選択肢がでて面白い。

そしてなにより、SKKの弱点である^[1]固有名詞に強くなった。

1. SKKは辞書を鍛えやすいのですぐ克服できる弱点ですが。同音異義語が一番怖い。 [↩]

ふと思いついて、あまり意味のあるレポートが取れないからとsendmailを止めていた各種jailたちで、smart relayをするように設定してみる。やり方は /etc/mail/sendmail.cf でrelayを探して宛先を書くだけ。

すると、メールサーバのログがどんどん流れはじめた。そういえば、各jailに貯まっているスプールを消していなかった。まあいいや、そんなに無いだろうし、と思ったのが運のつき。

どうやらエラーメールへのエラーメールや、cronでのちょっとした警告メールが積もりに積っていたらしく、Mail.appが長い逡巡の末に出した数値は15530通。

当然、inboxに詰まる。IMAPでアクセスしているので表示はなんとかしてくれたものの、そこから先、削除&ゴミ箱の削除がどうやってもできない。ただひたすらの待ち時間。

数時間たってから見てみると、Mail.appが5GB程のメモリを喰っていた。ハードウェア的には4GBなので、当然スワップしてさらに処理時間倍増。大きなプロセスをいくつか終了させて、無理矢理メモリを空けてから放置。

…結局翌日一日放置でなんとか消えてくれたようで。流石にこの数の一気処理は無謀すぎたようです。

iCalとiPod touch用に、AppleのiCal ServerのDarwin公開版であるDarwin Calendar and Contacts Server(Apache Licence 2.0)を、Roy’s Techblogを参考にFreeBSDで導入しようとしてみる。

CalDAVに対応しているだけならば、Bedeworkとかmod_caldavもあるのだが、まあApple iCal Serverにしておけば相性問題は無いだろうということで。英語での前例もあるということで、地味な安牌狙いをしてみる。

まずは、いつものように Jail を作成。ifconfigは後で/etc/rc.confにも反映しておく。

# ifconfig vxn0 alias 192.168.xxx.xxx netmask 255.255.255.0
# ezjail-admin create -f default calender.example.com 192.168.xxx.xxx

前提として、Running on various operating systemsにあるように、Pythonを中心としたソフトウェア群が必要らしい。

そこで、portsからインストール。xattr は FreeBSD 6.0 時点では setuptools ごと手動makeが必要だったようだが、バージョンを見るに特に問題もなさそうなので、portsそのままで対応した。

PythonはPTHスレッドのサポートを入れておくこと。

shells/bash
devel/subversion
lang/python
www/zope3
textproc/py-xml
security/py-openssl
devel/py-dateutil
databases/py-pysqlite22
devel/py-twisted
deskutils/py-vobject
devel/py-setuptools
devel/py-xattr
security/krb5
ftp/curl

ちなみに、subversionからsqlliteでTCLやPerlが入っているので思った以上にファットな構成になってしまている。流石にPHPは入らないが、最近の大物は何かというとP言語が依存関係で引き摺られやすくて困る。

portsで入らないPyKerberos/PyOpenDirectoryと、CalenderServerをsvnで取得。

# mkdir /usr/local/src
# cd /usr/local/src
# svn co http://svn.calendarserver.org/repository/calendarserver/CalendarServer/trunk CalendarServer
# svn co http://svn.calendarserver.org/repository/calendarserver/PyKerberos/trunk PyKerberos
# svn co http://svn.calendarserver.org/repository/calendarserver/PyOpenDirectory/trunk PyOpenDirectory

というところで本日は終了。krb5の依存がひどく、気がついたらGhostScriptやらteTeXやらが一式入りこんでいて、makeの時間を思った以上に喰ってしまった。なぜまっさらから作った/usr/local/が、700MBを超えているんだろう?

# du -sh /usr/local/
727M    /usr/local/

PyKerberosの Python.h のインクルード位置を変更。無くてもなんとなくどうにかなる気はするけど、先人の教えに従っておく。

# cd PyKerberos
# perl -spi -e 's{

setup.py に以下を追加。具体的位置はRoy’s Techblogを参照。

library_dirs=['/usr/local/lib'],
include_dirs=['/usr/local/include'],

PyKerberosをインストール。

# python setup.py build
# python setup.py install

PyOpenDirectoryも同様にインストール。

# cd PyOpenDirectory
# python setup.py build
# python setup.py install

QuickStartを参考にすると、CalenderServerは、runという付属スクリプトがあるので、それを使うらしい。

bashが/binにある前提のようなので、直接起動。

# cd CalendarServer/
# bash run -s

Downloading libevent...
/usr/local/src/CalendarServer/support/build.sh: line 200: curl: command not found

curlをダウンロードに利用しているらしい。仕方がないのでportsでftp/curlをインストールする。そして、あらためて起動。

# bash run -s

何やらmemcachedとかPostgreSQLとか、あまり心臓に良くないパッケージが見えますが…。

と、PostgreSQLのmakeで中断。configure: error: threaded Python not supported on this platformとあるので、どうやらPythonでスレッドサポートをつけてmakeしてやらないといけないらしい。

というわけで、lang/pythonでmake configしてからmakeしなおす。

普通のスレッドはサポートしているようなので、HUGE_STACK_SIZE(Use a larger thread stack) とPTH(Use GNU Pth for threading/multiprocessing)をつけてみる。

何故かPostgreSQLのconfigureが通らないらしい。 “run -s”ではなく”run -g”で依存関係を出してくれるようなので、そちらでチェックするが、直接の関連物だけらしく出てくれない。

Debianだとパッケージが存在するようだ。BSD派生のOS用がBSDではなくLinuxでとかそういうもにょり方はするけれども、別にmake自体が目的ではないので、そっちに逃げるのもありかな。