Started using the rthread:
% ls -l /usr/lib/libpthread.so.* -r--r--r-- 1 root bin 813680 Jan 10 11:43 /usr/lib/libpthread.so.13.1 -r--r--r-- 1 root bin 822508 Feb 7 19:48 /usr/lib/libpthread.so.13.3 -r--r--r-- 1 root bin 183080 Feb 21 22:36 /usr/lib/libpthread.so.14.0 %
http://marc.info/?l=openbsd-misc&m=132922427000548&w=2 で知ったけど、 bind10 は python が必要 らしいので試してみたら、:
% pwd /source/yasuoka/misc/bind10-devel-20120119 % ./configure checking for a BSD-compatible install... /usr/bin/install -c : (snip) checking for a Python interpreter with version >= 3.1... none configure: error: no suitable Python interpreter found %
本当っぽい。
tar でファイルを展開している時に、他のプロセスが軒並み I/O 待ちになってシステムがハングしたような状態になって気になっている。 まだちゃんと読んでないけど misc@ の "long hangs with heavy IO" と 関係するかもしれない。勘違いかも知れないけど、昔は気にならなかったので。 OpenBSD 5.0 => 5.1 またはディスク交換のどちらかが原因になっているかもしれない。
OpenBSD の chrome (chomium) でプラグインを使う方法。gnash (SWF player) や mozplugger (よろずプラグイン) のパッケージは、firefox 用に作られているので、 これを chrome で使えるように、
# ln -s /usr/local/lib/mozilla/plugins /usr/local/chrome/plugins
としている。
mozplugger は、どうもそのままでは、プラグインがクラッシュしましたという メッセージが表れて、そのまま使えず、次の patch をあてて使っている。:
--- mozplugger.c-ORIG Wed May 11 12:05:42 2011
+++ mozplugger.c Wed May 11 12:07:01 2011
@@ -1072,9 +1072,14 @@ static int read_config_cb(const char *fname)
pid_t pid;
int fd;
FILE *fp;
+ sigset_t set, oset;
D("READ_CONFIG(%s)\n", fname);
+ sigprocmask(SIG_BLOCK, NULL, &set);
+ sigaddset(&set, SIGCHLD);
+ sigprocmask(SIG_BLOCK, &set, &oset);
+
fd = open(fname, O_RDONLY);
if (fd < 0)
{
@@ -1126,6 +1131,7 @@ static int read_config_cb(const char *fname)
fclose(fp);
int status;
+ sigprocmask(SIG_BLOCK, &oset, &set);
waitpid(pid, &status, 0);
D("M4 exit status was %i\n", WEXITSTATUS(status));
設定を読み込むプロセスが終了した時に SIGCHLD が発生すると、ダメっぽいのだが、 これは mozilla と chomium でプラグインを呼び出した時のシグナルマスクの状態が 異なるために発生しているのでは? と予想しているが...
OpenBSD の vi が .exrc を読み込まず困っていたが (2011-10-24 とか 2012-01-06 )、原因は OpenBSD デフォルトの .login (/etc/skel/.login => ~/.login) に EXINIT 環境変数が設定されているからだった。
2012-02-07 の chromium の問題は、そもそも libevent の問題ということで、 http://archives.seul.org/libevent/users/Feb-2012/msg00009.html と報告されている。
ports の mew-6.4 も nvi も 5.1 に入らなかった... push しとけば良かった。
NetBSD 5.1-beta -> mew.org 80/tcp が SYN_SENT で刺さる。 net.inet.tcp.rfc1323=0 で回避できる。たぶん linux の time-wait ソケットの インチキ回収と {OpenBSD,Net}BSD の timestamp option の問題だと思うが、 時間があれば packet capture したい。発生した時のネットワーク構成的は、 横取りプロキシが挟まってて、mew.org とは直接 TCP してないのかもしれない。
生活環境の chrome が頻繁に Segmentation fault となる。 OpenBSD 5.1-beta (2/3 snapshot) + chromium-16.0.912.77 という環境だが、 このまま 5.1 になりそうな雰囲気なので、なんとかしたい。落ちる時の stacktrace
#0 0x1af81265 in base::MessagePumpLibevent::OnLibeventNotification ()
from /usr/local/chrome/chrome
#1 0x074e50b2 in event_base_loop (base=0x8950cc00, flags=2)
at /usr/src/lib/libevent/event.c:402
#2 0x1af7f555 in enterprise_management::protobuf_ShutdownFile_old_5fgeneric_5fformat_2eproto () from /usr/local/chrome/chrome
#3 0x1afb4659 in MessageLoop::Quit () from /usr/local/chrome/chrome
#4 0x1afb470d in MessageLoop::Quit () from /usr/local/chrome/chrome
#5 0x1afb4874 in MessageLoop::Quit () from /usr/local/chrome/chrome
#6 0x1afedabd in base::DefaultLazyInstanceTraits<base::ThreadLocalBoolean>::Delete () from /usr/local/chrome/chrome
#7 0x1afede6e in base::LazyInstance<base::ThreadLocalBoolean, base::DefaultLazyInstanceTraits<base::ThreadLocalBoolean> >::OnExit ()
from /usr/local/chrome/chrome
#8 0x1afed7bc in base::subtle::TaskClosureAdapter::Run ()
from /usr/local/chrome/chrome
#9 0x03b6da2e in _thread_start ()
at /usr/src/lib/libpthread/uthread/uthread_create.c:242
#10 0x0000002b in ?? ()
#11 0x00000000 in ?? ()
robert@ さんに報告したら、 http://marc.info/?l=openbsd-cvs&m=132791695512275&w=2 じゃね? ってことになり、この変更を revert したら直った。さすが。 自分も、libevent かも? とは思ってたので、次回は自力で解決したい。
npppd またもや 5.1 リリースには間に合わない感じなので、頭を切り替えて 5.2 狙いとするか。
NetBSD に取り込まれた IPFilter 5.1.1 によると http://mail-index.netbsd.org/tech-net/2012/01/30/msg003082.html
One of those is a "divert" action that takes a packet and puts an IP + UDP header on the front, allowing "raw packets" to be delivered to any socket.
IP + UDP ヘッダを足して divert 相当を行う拡張が入った。
xlock してても ctrl-alt-f? で、ロックされてない端末にアクセスできるという話 http://marc.info/?l=openbsd-misc&m=132731150004416&w=2 今後はアクセスできなくなるのか。
github/openbsd の話 http://marc.info/?l=openbsd-misc&m=132650695213810&w=2 自分も 自作スクリプト で、cvs => svn 変換を行っている。 原理的に cvs から svn などに完璧に変換するのは不可能だと思うが、 この自前のスクリプトでは、 原理的に不可能なこと以外にも何点か変換をあきらめることで、 シンプルな実装 & 処理を軽くしている。いつか詳しく書きたい。
npppdctl あらため npppctl の件 実行結果は次のような感じ。:
% npppctl -n session brief
Ppp Id Assigned IPv4 Username Proto Tunnel From
---------- --------------- -------------------- ----- -------------------------
1 10.0.0.100 yasuoka L2TP 125.30.2.102:1701
% npppctl -n session packets
Ppd Id Username In(Kbytes/pkts/errs) Out(Kbytes/pkts/errs)
---------- -------------------- ----------------------- -----------------------
1 yasuoka 17.6 194 0 1.4 65 0
stm1: {401} % npppctl -n session all
Ppp Id = 1
Ppp Id : 1
Username : yasuoka
Realm Name : local
Concentrated Interface : tun0
Assigned IPv4 Address : 10.0.0.100
Tunnel Protocol : L2TP
Tunnel From : 125.30.2.102:1701
Start Time : 2012/01/13 09:07:23
Elapsed Time : 13404 sec (3 hours and 43 minutes)
Input Bytes : 17976 (17.6 KB)
Input Packets : 194
Input Errors : 0 (0.0%)
Output Bytes : 1429 (1.4 KB)
Output Packets : 65
Output Errors : 0 (0.0%)
% npppctl clear ppp-id 1
Successfully disconnected 1 session.
%
OpenBSD 5.1 に向けてガリガリやってます... parse.y 含めて... 間に合うかなぁ..
『UNIX ファイルシステムの歴史』 http://www.slideshare.net/magoroku15/unix-9720732 を読んだ。
最近 OpenBSD/luna88k が活発なのは、 http://mail-index.netbsd.org/port-m88k/2011/12/thread1.html#000025 このへんの流れか。
cvs server の /tmp の空きがたりなくて cvs up できない場合:
env CVS_SERVER="/usr/bin/cvs -T /var/tmp" cvs update
IPv6 でも、実環境では Path MTU Blackhole だらけだから、やっぱ tcp mss 書き換えちゃおうという意見があるみたいだが、 IPv6 は Path MTU Blackhole があるとプロトコル的に辻褄があわないと思っていたので、 そのあたりをどう理解すべきかよくわかっていない。たぶん不勉強なだけだと思うけど。 あとで http://www.potaroo.net/ispcol/2009-01/mtu6.html を読んでみよう。
2007 年 3 月のセキュリティアドバイザリ OpenBSD's IPv6 mbufs remote kernel buffer overflow を復習。修正である kern/uipc_mbuf2.c に対する diff を読んでみる。 M_DUP_PKTHDR が MGETCL した後だったがこれは誤りだったということ。 MGETCL で確保したメモリ領域を示していた m_data を struct mbuf 内の領域に上書きしてしまう。このため、 struct mbuf の領域をはみ出して書き込んでしまう。あとは、当該関数を呼んでいる IPv6 の処理や、メモリの状態でこの不具合の影響が決まる。はみ出した領域も mbuf であることが予想されるし、 mbuf には mbuf 解放のための関数ポインタが格納されているので、その関数ポインタを書き換えて、任意のコードを実行させることが可能だったということ。
そもそも IPv6 (kame) の実装で m_pulldown() という関数が作られ、 その関数で必要となった m_dup1 という関数に不具合があった。 現在の OpenBSD でも、 m_pulldown は、IPv6 スタックでしか使われていない。そもそも m_pulldown を作ることなく実装できたかもしれない、と思う。 IPv6 拡張ヘッダで使用されている部分は、 そもそもネットワークプロトコルのヘッダなので、 小さいと考えて全体を連続領域に載せてしまい、 その仮定で実装した方がシンプルだと思われる。 それ以外で使用される箇所は、 m_copy{data,back} で代用できる、というか m_copy{data,back} のほうがむしろふさわしいと思う。
ついでに CVE-2008-3584 も復習。 NetBSD のアドバイザリ に名前がクレジットされている。発見したのは僕じゃないじゃないけど。 OpenBSD では、 NetBSD のアドバイザリ直後に commit されていた。
よく見ると、NetBSD のアドバイザリ間違ってて、cvs up すべきは、if_spppsubr.c じゃなく if_pppoe.c。いまさら時効だと思うけど。
以前、 OpenBSD の vi が .exrc を読み込まないと書いた が、普通に読み込んでいる。勘違いだったか...
~/ 以下を暗号化して保護しても、vi.recover で編集中の文書が丸見えという問題 があることに気づいたので、~/.exrc に set recdir=/home/yasuoka/.vi.recover を追加した。
swap は暗号化可能か、されているのか知らなかったが、 OpenBSD では、swapencryptという仕組みが入っていて、
vm.swapencrypt.enable=1 vm.swapencrypt.keyscreated=0 vm.swapencrypt.keysdeleted=0
デフォルトで有効なようだ。 vm.swapencrypt.keys{created,deleted} は、swap が実際に使われると増えていくらしい。詳細は、 Encrypting Virtual Memory - Niels Provos というペーパーがあるので、これに書いてあるっぽい。
NetBSD の場合は cgd(4) で、 FreeBSD の場合は geom(4) 上の gbde(4) で暗号化できる。 OpenBSD 以外は、暗号化している仮想ディスクを swap として使う、という考え方。 OpenBSD は uvm の機能として実装されている。
phk が作った HTTP キャッシュサーバ varnish から、 それで使われてるらしい B-Heap をななめ読み。
ghostscript-fonts をインストールすると、xfe が文字化けする。
reStructuredText では、取り消し線付きテキスト、HTML の strike タグ相当は利用できない。自前で role を追加して HTML の CSS クラスでスタイルとして定義することで実現する方法が、 http://stackoverflow.com/questions/6518788/rest-strikethrough に書かれている。しかし、この方法では HTML でスタイルが適用されない場合や HTML 以外の出力形式を使う場合に、取り消されずに出力されてしまうため、文章の意味が変わってしまう。当面はあきらめることにする。
本番環境で初期不良の SSD を踏みました - mura日記 (halfrack) を読んで、自分のノート PC のカウンタも調べてみた。 昨年末に換装したばかりの新品 HDD だが、将来、現在の値が参考になるかもしれないので、張っておく
% sudo atactl wd0 readattr Attributes table revision: 16 ID Attribute name Threshold Value Raw 1 Raw Read Error Rate 62 100 0x000000000000 2 Throughput Performance 40 100 0x000000000000 3 Spin Up Time 33 181 0x001100000001 4 Start/Stop Count 0 100 0x000000000057 5 Reallocated Sector Count 5 100 0x000000000000 7 Seek Error Rate 67 100 0x000000000000 8 Seek Time Performance 40 100 0x000000000000 9 Power-On Hours Count 0 100 0x00000000012a 10 Spin Retry Count 60 100 0x000000000000 12 Device Power Cycle Count 0 100 0x000000000054 191 G-Sense Error Rate 0 97 0x000000060001 192 Power-Off Retract Count 0 100 0x00000000000d 193 Load Cycle Count 0 91 0x000000016593 194 Temperature 0 153 0x002d000a0027 196 Reallocation Event Count 0 100 0x000000000000 197 Current Pending Sector Count 0 100 0x000000000000 198 Off-Line Scan Uncorrectable Sect 0 100 0x000000000000 199 Ultra DMA CRC Error Count 0 200 0x000000000000 223 Load/Unload Retry Count 0 100 0x000000000000 %
OpenBSD日本語入力の怪（というより知識不足）- OpenBSD日記 に、 30分でできる OpenBSD 日本語デスクトップ環境 を読んでハマったポイントが書いてある。要改善ポイントまとめておく。
その他、自分で見直しての要改善ポイント