| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 |
kdump を設定済みのサーバは増えてきたようですが、シリアルコンソールを設定したサーバはまだ多くはないようです。同一のサーバで複数回の予期せぬリブートを経験して初めてシリアルコンソールの設定を検討するようになるという状況ですので、予期せぬリブートの原因についての問合せでは初回の事象発生時に何も手掛かりを見つけられず、残念な思いをすることが多いです。しかも、再発するまでに何ヶ月も待たされることが多く、調査する側としては何だか落ち着かない状況が続きます。この記事が、初回発生時に手掛かりを見つけるのに役に立てばいいなぁ。
誰かさんは
> 現在放送中の某アニメに倣って「○○ノススメ」を予定しています。
という部分を読んで何のアニメなのかを検索したらしく、「侵略！イカ娘」ですかと訊かれてしまいました。
え〜？そっちは知らないにゃ〜。（笑）
LinuxCon Japan 2014 で使用した「エンタープライズ向けサーバのトラブル対応のための情報取得方法について」を、紙面では説明しきれなかった内容も含めて丁寧に解説することにより、業務用 Linux サーバ管理者のトラブルシューティングスキル向上に資することを願って、「OSSコラム 安らかな夜を迎えるために」を開始しました。
本業にいつ余裕ができるかを全く予測できないという性質上、原稿を書く時間を定期的に割けることを約束できないため、不定期連載という形になります。各話のタイトルは、現在放送中の某アニメに倣って「○○ノススメ」を予定しています。
撮影されないようにカメラから逃げ回っている熊猫が、何故かクラス紹介の動画で喋るはめになってしまいました。（汗）
昨年度は「セキュリティの見える化を考えるゼミ」という名前で募集し、「利用者を置いてけぼりにしないセキュリティを考えてみよう」というテーマには８名もの応募がありました。セキュリティについて利用者が置いてけぼりにされているというモヤモヤ感を持った人が予想以上に多く存在していると感じました。そして、セキュリティという得体のしれないものを相手にするのは学生には難しいとも感じました。
そのため、今年はＯＳのセキュリティを考える前段階である「ＯＳの見える化を考えるゼミ」という名前で募集します。応募者の希望テーマに応じて講義内容を考える予定ですが、参考資料として、来週 LinuxCon Japan 2014 の発表で使用する「エンタープライズ向けサーバのトラブル対応のための情報取得方法について」を紹介しておきます。
仕事として Linux サーバのトラブル対応をしているのですが、障害発生時のカーネルメッセージは /var/log/messages に残せないため、 /var/log/messages を確認しても原因が判らないものです。技術的にはカーネルメッセージをシリアルコンソールに出力することができるのですが、運用としてシリアルコンソールを導入することが困難なサーバが多く、もどかしい思いをしていました。
そんな中、 netconsole をシリアルコンソールの代替機能として活用できそうだと判明したので、 netconsole からのメッセージを受信するための専用プログラムを作成して http://sourceforge.jp/projects/akari/scm/svn/tree/head/branches/udplogger/ に置きました。
コメントおよびディストリビューション向けパッケージのメンテナになっていただける方を募集しています。
昨年の始め頃、 208.5 日以上連続稼働すると動作が停止したり kernel panic が発生したりする可能性があるという TSC 絡みの不具合が話題になりました。
Linux カーネルの sched_clock() が 208.5 日の連続稼働でオーバーフローする現象について
https://access.redhat.com/site/solutions/121233
Does Red Hat Enterprise Linux 6 or 5 have a reboot problem which is caused by sched_clock() overflow around 208.5 days?
https://access.redhat.com/site/solutions/68466
しかし、上記の不具合を修正したカーネルには落とし穴があったようです。（誰も話題にしないので、注意喚起の意味で URL を貼っておきます。）
Systems with Intel® Xeon® Processor E5 hung after upgrade of Red Hat Enterprise Linux 6
https://access.redhat.com/site/solutions/433883
手元の VMware Player 上で 4 VCPU を割り当てた CentOS 6 32bit 環境において、 TSC の書き換えにより連続稼働をエミュレートするという方法で再現試験を行った限りでは、この不具合の再現率は１００％のように見受けられます。
Intel Xeon E5 は業務用サーバとして広く使われていると思いますので、油断していると襲われますよ〜。
いろいろと Linux 利用者を悩ませてきたＬＳＭですが、変化の時が近づきつつあるようです。
熊猫の９年間の試行錯誤を纏めて LinuxCon North America と Linux Security Summit で発表した、 ARIA ワールド満開（嘘）なプレゼン資料も貼っておきます。アクセス制御に興味のある方に読んでほしいなぁ。
Fedora 17 のネットワークインストーラは、環境によっては「次へ」ボタンが表示されないことがあるようです。以下は熊猫の PC 上の VMware Workstation 上に Fedora-17-i386-netinst.iso からインストールしようとした時の画面です。
画面外には表示されているので、 Tab キーを使ってフォーカスを移動してください。
以下は同じ条件で Fedora-17-i686-Live-Desktop.iso からインストールしようとした時の画面です。
どうしても最小インストールをしたいと言うのでなければ、 Live 版を使う方が正解かと思います。
Linux 3.4 では、 call_usermodehelper() の引数で指定されている UMH_* 定数の値が変更されています。 UMH_* 定数の代わりにハードコードされた整数を指定しているソースコードは、 Linux 3.4 以降では期待通りに動かなくなります。
現時点では、この修正は Ubuntu にバックポートされています。この修正は他のいくつかのディストリビューションにもバックポートされることが予想されます。
call_usermodehelper() を含むコードを使用する場合、 UMH_* 定数を使用するように修正されているかどうか確認するようにしてください。
一例として、 DRBD モジュールでは call_usermodehelper() でハードコードされた整数を指定していたため、バグ報告が出ています。
https://bugs.launchpad.net/ubuntu/+source/drbd8/+bug/1000355
Linux にあまり関係ない話ですが、 Windows 版だけでなく Linux 版でも再現できるバグだったので、ここに載せておきます。
Thunderbird で受信したメールを整理しようとしてフォルダを作成していた時に、 Thunderbird では受信したメールを保存するフォルダの名前が「受信トレイ」と表示されていたので、「それなら Inbox という名前のフォルダを作成しても大丈夫だろう。もし駄目ならエラーメッセージが表示されて作成できないようになっているだろうから。」と思って、 Inbox というフォルダ名を指定したところ、既に存在する Inbox フォルダの内容が消滅してしまうという恐ろしいバグを踏んでしまいました。（証拠動画： http://www.youtube.com/watch?v=No3lyZNk9Hc ）
https://bugzilla.mozilla.org/show_bug.cgi?id=749909 にて進行中ですが、その中にナレッジベースへのリンクが登場したので、貼っておきます。
http://kb.mozillazine.org/Disappearing_mail
こういう情報は事前に知っておかないと間に合わないでしょうから・・・今回のバグには無力そうな気がしますが・・・。
近頃のディストリビューションで採用されているバージョンの tail コマンドは inotify を使っているため、環境によっては tail -f が希望通りに機能しないことがあるようです。 Ubuntu 12.04 の LiveCD から tail -f を試してみたのですが、動きませんでした。
| # tail -f /var/log/tomoyo/reject_000.txt /var/log/tomoyo/reject_001.txt /var/log/tomoyo/reject_002.txt /var/log/tomoyo/reject_003.txt |
strace で確認すると、特定のファイルディスクリプタの読み込みでブロックしていることが判ります。
|
# strace -p `pidof tail` Process 4418 attached - interrupt to quit read(7,^C <unfinished ...> Process 4418 detached |
ls で確認すると、そのファイルとは anon_inode:inotify であることが判ります。
|
# ls -l /proc/`pidof tail`/fd/ total 0 lrwx------ 1 root root 64 May 2 11:40 0 -> /dev/pts/0 lrwx------ 1 root root 64 May 2 11:40 1 -> /dev/pts/0 lrwx------ 1 root root 64 May 2 11:40 2 -> /dev/pts/0 lr-x------ 1 root root 64 May 2 11:40 3 -> /var/log/tomoyo/reject_000.log lr-x------ 1 root root 64 May 2 11:40 4 -> /var/log/tomoyo/reject_001.log lr-x------ 1 root root 64 May 2 11:40 5 -> /var/log/tomoyo/reject_002.log lr-x------ 1 root root 64 May 2 11:41 6 -> /var/log/tomoyo/reject_003.log lr-x------ 1 root root 64 May 2 11:41 7 -> anon_inode:inotify |
inotify を使わせないようにするには、 ---disable-inotify という隠しオプションを使います。 - が３つ連続していることに注意してください。
| # tail ---disable-inotify -f /var/log/tomoyo/reject_000.txt /var/log/tomoyo/reject_001.txt /var/log/tomoyo/reject_002.txt /var/log/tomoyo/reject_003.txt |
CentOS 4 は EOL を迎えたわけですが、既にミラーサーバ上から消滅しているので、 yum 設定の更新が必要です。
|
# yum -y update Setting up Update Process Setting up repositories not using ftp, http[s], or file for repos, skipping - 4 is not a valid release or hasnt been released yet Cannot find a valid baseurl for repo: update Error: Cannot find a valid baseurl for repo: update |
具体的には、 baseurl 行にサーバとして vault.centos.org を指定します。
| # sed -i -e 's/^mirrorlist=/#mirrorlist=/' -e 's/^#baseurl=/baseurl=/' -e 's@mirror.centos.org/centos@vault.centos.org@' -e 's/$releasever/4.9/' -- /etc/yum.repos.d/CentOS-Base.repo |
最初の報告から１ヶ月経ったけどまだ何の反応も無いので、犠牲者をこれ以上増やさないようにするために、先に周知します。
lmbench パッケージには、プログラム実行に要する遅延時間を測定する lat_proc というプログラムが入っていますが、 Debian/Ubuntu の lmbench-3.0-a9 をパッケージでインストールした場合には正しい結果が得られません。
これは、存在しない /var/tmp/lmbench/hello というプログラムを lat_proc が実行しようとするため、 execve() が失敗してしまうことが原因です。（失敗してもエラーメッセージ１つ出さないという作りはどうかと思いますが。（汗））
TOMOYO で解析すると、 sh -c を実行しているのに hello プログラムのためのドメインが作成されていないことが確認できます。
43: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lmbench
44: 0 /bin/cp
45: 0 /bin/date
46: 0 /bin/hostname
47: 0 /bin/mkdir
48: 0 /bin/mount
49: 0 /bin/netstat
50: 0 /bin/rm
51: 0 /bin/sleep
52: 0 /bin/sync
53: 0 /bin/tar
54: 0 /bin/uname
55: 0 /sbin/ifconfig
56: 0 /usr/bin/awk
57: 0 /usr/bin/expr
58: 0 /usr/bin/touch
59: 0 /usr/bin/uptime
60: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/bw_file_rd
61: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/bw_mem
62: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/bw_mmap_rd
63: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/bw_pipe
64: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/bw_tcp
65: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/bw_unix
66: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_connect
67: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_ctx
68: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_fs
69: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_http
70: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_mmap
71: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_pagefault
72: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_pipe
73: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_proc
74: 0 /bin/sh
*** ↑ hello プログラムのドメインが存在しない ***
75: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_rpc
76: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_select
77: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_sig
78: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_syscall
79: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_tcp
80: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_udp
81: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_unix
82: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lmdd
83: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lmhttp
84: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/msleep
85: 0 /usr/lib/lmbench/scripts/os
lmbench-3.0-a9.tgz から作成すると正しい結果が得られていることが判ります。
182: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lmbench
183: 0 /bin/cp
184: 0 /bin/date
185: 0 /bin/hostname
186: 0 /bin/mkdir
187: 0 /bin/mount
188: 0 /bin/netstat
189: 0 /bin/rm
190: 0 /bin/sleep
191: 0 /bin/sync
192: 0 /bin/tar
193: 0 /bin/uname
194: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/bw_file_rd
195: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/bw_mem
196: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/bw_mmap_rd
197: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/bw_pipe
198: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/bw_tcp
199: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/bw_unix
200: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_connect
201: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_ctx
202: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_fs
203: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_http
204: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_mmap
205: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_pagefault
206: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_pipe
207: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_proc
208: 0 /bin/sh
209: 0 /tmp/hello
*** ↑ hello プログラムのドメインが作られている ***
210: 0 /tmp/hello
211: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_rpc
212: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_select
213: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_sig
214: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_syscall
215: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_tcp
216: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_udp
217: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_unix
218: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lmdd
219: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lmhttp
220: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/msleep
221: 0 /sbin/ifconfig
222: 0 /usr/bin/awk
223: 0 /usr/bin/expr
224: 0 /usr/bin/touch
225: 0 /usr/bin/uptime
ということで、 lmbench/3.0-a9-1 を使う場合、事前に hello プログラムを /var/tmp/lmbench/hello にコピーするか、あるいは、 lmbench-3.0-a9.tgz からコンパイルしたものを使用するようにしてください。（これ以外にも不具合があるかもしれないので、修正が完了するまでは lmbench-3.0-a9.tgz からコンパイルする方がおススメです。）
Adobe Flash Plugin は rpm などの形式でインストールできますが、単にインストールしただけではブラウザから認識してくれないようです。しかも、最新版をインストールした後も Firefox が「安全のために最新版ではない Flash を無効化したよ（ For your safety, Firefox has disabled your outdated version of Flash. ）」なんて表示してくるものですから、「認識しているけど使っていない」のだと誤解するでしょう。
Firefox から認識できるようにするには、最新版をインストールした後に、以下のようにシンボリックリンクを張る必要があります。
| # ln -s /usr/lib/flash-plugin/libflashplayer.so /usr/lib/mozilla/plugins-wrapped/ |
ちょうどＤＮＳを使った隠れ通信ネタが出たので、熊猫からも１つ。
RHEL6.2 カーネルには、 Linux 3.0 で導入された sendmmsg() システムコールがバックポートされています。これを使うと、１回のシステムコールで複数の宛先に送信できるので、１個目のパケットだけでなく２個目以降のパケットについても宛先チェックをしないと、不審なホストとの隠れ通信に利用されてしまいます。
Linux 3.0.0 のリリース直後に sendmmsg() システムコールが追加されていることに気付き、ソースコードをチェックしてみたところ、ＬＳＭによるチェックは１個目のパケットの送信時だけしか行われていませんでした。そのため、「はぅ〜、１個目の宛先しかチェックできないのでは、 AKARI による送信先アドレスチェックが不完全なものになってしまうよ〜」とガッカリしました。当時、 TOMOYO 2.x にネットワークに対する送受信アドレスチェック機能を追加することも目指していたため、せっかくのパフォーマンス向上分を減少させてしまう仕様変更をどうやって提案しようかと悩みました。でも、幸いなことに、 SMACK が既に宛先アドレスから算出されるラベルに基づくアクセス制御を搭載していたため、 TOMOYO のための仕様変更パッチとしてではなく SMACK のためのリグレッション修正パッチとして提案することができました。
そうして Linux 3.0.2 で熊猫が提案したリグレッション修正パッチが取り込まれたのですが、そのパッチには別のバグがありました。そのバグを修正するパッチは Linux 3.0.5 で取り込まれました。
そんな中、 RHEL 6.2 のカーネル 2.6.32-220.el6 がリリースされた訳ですが、熊猫のリグレッション修正パッチだけしか含まれていなかったので、「熊猫のリグレッション修正パッチのバグを修正するパッチを忘れてるよ」と報告したところ、 CVE-2011-4594 として登録されてしまいました。何か対応が大げさな気がしないでもない。（＾＾；
で、その修正パッチを含んだカーネル 2.6.32-220.7.1.el6 がリリースされたことを今日知りました。
ところで、熊猫が提案したリグレッション修正パッチ、 SELinux しか有効にする気が無い RedHat 系カーネルにとっては、実はバックポートする必要性はありませんでした。なぜなら、 SELinux では宛先アドレスに基づくアクセス制御をしていないからです。情報フロー制御は気にするのに、 sendmmsg() システムコールを使って不審なホストのＤＮＳサービスとの隠れ通信をすることは気にしないとはこれ如何に？
kernel.org が復旧して tar ball をダウンロードできるようになりましたが、署名のチェック方法が従来とは異なっているようです。
今までは圧縮されたファイル毎に署名ファイルがあったので、例えば linux-3.0.tar.bz2 に対する署名ファイルは linux-3.0.tar.bz2.sign という名前で配布されていました。そのため、チェックするには、 linux-3.0.tar.bz2 と linux-3.0.tar.bz2.sign を同じディレクトリに置き、
|
$ gpg --verify linux-3.0.tar.bz2.sign gpg: Signature made Fri Jul 22 12:31:02 2011 JST using DSA key ID 517D0F0E gpg: Good signature from "Linux Kernel Archives Verification Key <ftpadmin@kernel.org>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: C75D C40A 11D7 AF88 9981 ED5B C86B A06A 517D 0F0E |
のように実行していました。しかし、 https://lkml.org/lkml/2011/10/23/122 によると、これからは圧縮前のファイルに対する署名ファイルのみの配布となるため、例えば linux-3.1.tar.bz2 に対する署名ファイルは linux-3.0.tar.sign のようになります。チェックするには、 linux-3.1.tar.bz2 と linux-3.1.tar.sign を同じディレクトリに置き、
|
$ bzcat linux-3.1.tar.bz2 | gpg --verify linux-3.1.tar.sign - gpg: Signature made Mon Oct 24 16:17:58 2011 JST using RSA key ID 00411886 gpg: Good signature from "Linus Torvalds <torvalds@linux-foundation.org>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: ABAF 11C6 5A29 70B1 30AB E3C4 79BE 3E43 0041 1886 |
のように実行します。署名に使われている鍵もアップデートされているので、忘れないでくださいね。
とあるひとから、 TOMOYO を SUSE カーネルで有効になるようにしたいという要望を受け、過去のスレッドを探すために TOMOYO SUSE で検索していたら、↓なページを発見しました。
どのマスコットがお好き？−＠ＩＴそれによると、 openSUSE のマスコットキャラクターである Geeko くんは、カメレオンではなくヤモリなのだそうです。また、みなさんが良くご存じの Geeko くんは日本版なのだそうで、欧州版の Geeko くんはなんだか「恐竜かよ！？」って突っ込みたくなる顔のようです。
Linus さんが Linux 2.6 系は 2.6.39 で終わりにして、 Linux 3 系を 3.0 から始めることを決断した模様です。ペンギンさんから新しいマスコットキャラクターに交代するのかなぁ？
以前、お遊び： tar ball のハッシュ値を選ぶでファイルを作成した時刻により md5sum の値が変化するというのを紹介しましたが、調査の結果、 gzip ファイルのヘッダ部分に埋め込まれている MTIME 部分が変化していることが原因であることが判明しました。
ということで、この MTIME 部分の値を書き換えれば、好きな md5sum 値を簡単に取得できるわけです。
TOMOYO Linux の tarball は、「配布用かテスト用か」および「最後までダウンロードされたかどうか」を簡単に見分けられるようにするために、以下のようなプログラムを用いて md5sum 値の先頭４桁が同じになるように選んでいます。（熊猫が作成した tarball かどうかの確認には、ファイル名の末尾に .asc を付与したファイルもダウンロードして、 gpg で確認してください。）
/* gcc this_file.c -lssl */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <openssl/md5.h>
static void mkfile(const char *dir, const char *cmdline, const char *outfile)
{
unsigned char *buf = NULL;
unsigned long buflen = 0;
time_t *mtime;
FILE *fp;
if (chdir(dir)) {
fprintf(stderr, "Can't change directory.\n");
return;
}
fp = popen(cmdline, "r");
if (!fp) {
fprintf(stderr, "Can't read gzipped data.\n");
return;
}
while (1) {
int len;
buf = realloc(buf, buflen + 1048576);
if (!buf) {
fprintf(stderr, "Can't allocate memory.\n");
pclose(fp);
return;
}
len = fread(buf + buflen, 1, 1048576, fp);
if (len == 0)
break;
buflen += len;
}
pclose(fp);
if (buflen < 8 || buf[0] != 0x1f || buf[1] != 0x8b) {
fprintf(stderr, "Invalid gzipped data.\n");
return;
}
fp = fopen(outfile, "w");
if (!fp) {
fprintf(stderr, "Invalid gzipped data.\n");
return;
}
mtime = (time_t *) (buf + 4);
while (1) {
const unsigned char *md5 = MD5(buf, buflen, NULL);
unsigned char c[4] = { md5[0] >> 4, md5[0] & 0xF,
md5[1] >> 4, md5[1] & 0xF };
printf("%02x%02x%02x%02x%02x%02x%02x%02x"
"%02x%02x%02x%02x%02x%02x%02x%02x\n",
md5[0], md5[1], md5[2], md5[3], md5[4], md5[5],
md5[6], md5[7], md5[8], md5[9], md5[10], md5[11],
md5[12], md5[13], md5[14], md5[15]);
if (c[0] == c[1] && c[1] == c[2] && c[2] == c[3])
break;
(*mtime)++;
}
if (fwrite(buf, 1, buflen, fp) != buflen || fclose(fp)) {
fprintf(stderr, "Can't write.\n");
unlink(outfile);
}
}
int main(int argc, char *argv[]) {
mkfile("ソースのディレクトリ", "tar -zcf - --exclude .svn -- *", "出力ファイル");
return 0;
}
|
先頭８桁が同じになるまでループさせるとか言って電力を浪費するの禁止！
configure スクリプト中で、 gcc が -static オプションをサポートしているかどうかをチェックする箇所があるかと思います。
| checking if gcc static flag -static works... no |
ところが、そのチェックを行うために使われる「エラーになる筈がない」と思われていた簡単なプログラムが、最近の Fedora や RHEL6 ではエラーになるのです。
|
$ echo 'int main(){return(0);}' | gcc -Wall -static -x c - /usr/bin/ld: cannot find -lc collect2: ld returned 1 exit status |
これは、開発用パッケージである glibc-devel の中にスタティックリンクライブラリである /usr/lib/libc.a が含まれていないことが原因です。このエラーを解決するには、 glibc-static というパッケージを別途インストールする必要があります。
| # yum install glibc-static |
ダイナミックリンクライブラリだけしかインストールされない開発用パッケージが他にも存在しており、スタティックリンクライブラリを使いたい場合には開発用パッケージをソースパッケージから再コンパイルしなければいけないという、面倒な状況になってきているようです。
CentOS 5.5 がリリースされましたので、 TOMOYO の LiveCD を更新中です。
CentOS 5 に付属の squashfs-tools 3.0 に含まれている mksquashfs コマンドは、 CentOS 5 のカーネルがサポートしている squashfs 3.0 形式のイメージファイルを作成できますが、複数ＣＰＵを用いた並列処理はサポートしていません。それに対し、 squashfs-tools 3.4 に含まれている mksquashfs コマンドは、複数ＣＰＵを用いた並列処理をサポートしていますが、 squashfs 3.1 形式のイメージファイルを作成してしまうため CentOS 5 のカーネルでは使えません。
なんとかならないものかと思って mksquashfs のソースコードを見たところ、ブロックサイズが６４ＫＢ以下で、スパースファイルをサポートしないようにコマンドラインオプションで指定してやれば squashfs 3.0 形式のイメージファイルを作成できることが判明しました。つまり、 squashfs-tools 3.4 （ https://projects.centos.org/trac/livecd/browser/trunk/i386/RPMS/squashfs-tools-3.4-1.i386.rpm?rev=54 ）をインストールして、 mksquashfs コマンドの実行時に -b 65536 -no-sparse -no-exports -no-recovery を追加してやれば、複数のＣＰＵを用いた並列処理という美味しいところだけをいただくことができます。
http://en.wikipedia.org/wiki/SIGCHLD によると、 SIGCLD ではなく SIGCHLD を使うのが正しいそうだ。
ccs-tools-1.6.7-20090401.tar.gz の中の ccs-editpolicy-agent.c で SIGCLD を使ってしまったため、某クロスコンパイル環境ではコンパイルエラーとなってしまった。はぅ〜。