FreeBSD 11.0RでZFSの特定プロパティ条件下でkern.proc.pathnameが失敗する
FreeBSD 11.0-RELEASEでVirtualBoxが起動しない問題、もといKERN_PROC_PATHNAMEのsysctlに失敗するのは、どうやらZFSが原因っぽい。ZFSのcasesensitivityないしnormalizationプロパティがデフォルト値以外になっていると、VFS絡みでうまく動かない模様。うちはnormalization=formCにしてるので、どう見てもこいつのせいです。本当にありがとうございました。
幸い、既にパッチが投稿されており、10/7付けでstableにも取り込まれているので11.1では直ると思われる。
が、それまでVirtualBoxが使えないのは地味に辛いなぁ。うちの環境では今のところVirtualBoxしか表面化してないけど、割と影響受けるソフト多いんじゃないかしら?久々にカーネルを自前ビルドしてみましょうかね。
参考サイト
- 8/20にFrederic Chardon氏が報告してるのに誰からも相手されてなくてカワイソス(´・ω・`) 原因が原因だけに殆どの環境では問題なかったんだろうけど…。
FreeBSD 11.0RにしたらVirtualBoxが動かなくなった(´・ω・`)
先日、家鯖をFreeBSD 11.0-RELEASEに更新してからVirtualBoxが動かなくなった。起動しようとするとVirtualBox: supR3HardenedExecDir: sysctl failedとエラーを吐いて終了する。sysctlに失敗するってどういうこっちゃ。
当該ソースはSUPR3HardenedMain.cppの1243行目付近で、VirtualBox自身の実行ファイルパスを取得してる部分。
# else /* RT_OS_FREEBSD */ int aiName[4]; aiName[0] = CTL_KERN; aiName[1] = KERN_PROC; aiName[2] = KERN_PROC_PATHNAME; aiName[3] = getpid(); size_t cbPath = sizeof(g_szSupLibHardenedExePath); if (sysctl(aiName, RT_ELEMENTS(aiName), g_szSupLibHardenedExePath, &cbPath, NULL, 0) < 0) supR3HardenedFatal("supR3HardenedExecDir: sysctl failed\n"); g_szSupLibHardenedExePath[sizeof(g_szSupLibHardenedExePath) - 1] = '\0'; int cchLink = suplibHardenedStrLen(g_szSupLibHardenedExePath); /* paranoid? can't we use cbPath? */ # endif
何の変哲もないコードだし、特に最近変わったような雰囲気もない。原因切り分けのため、上記コードと同じ事をする簡単なテストコードをでっちあげて実行してみたら、同じように失敗する。
#include <sys/param.h> #include <sys/sysctl.h> #include <stdio.h> int main(void) { int pid = getpid(); int mib[4] = { CTL_KERN, KERN_PROC, KERN_PROC_PATHNAME, pid }; printf("pid = %d\n", pid); size_t bufSize = 1024; char buf[bufSize]; int result = sysctl(mib, 4, buf, &bufSize, NULL, 0); if (result < 0) { perror("sysctl"); } return 0; }
-------- 実行結果 -------- $ ./sysctltest pid = 66245 sysctl: No such file or directory
supR3HardenedExecDirでググるとprocfsをマウントし忘れてんじゃね?という投稿が出てくるが、今回の問題箇所はprocfsを不要とするための部分なのでprocfsをマウントしようがしまいが変わらない(大体今までprocfsマウントしてなくても動いてたし…)、と思いつつ藁をも掴む思いでマウントしてみたけど、やっぱり何の解決にもならなかった\(^o^)/
portsでソースからのインストールも試みたけどビルドがコケるし、もぅマヂ無理。リスカしょ…。
参考サイト
PortsにNetatalk 3.1.10がキテタ━━━(゚∀゚)━━━ !!!!!
家鯖をFreeBSD 11.0-RELEASEに上げたタイミングで、Netatalk 3.1.8に更新したのだが、どうにもBonjourで広告されなさげ。OS更新で諸々おかしくなったか?と思い、NetatalkやmDNSResponderを再ビルドしても症状変わらず。
afpd -Vしてみたら、なんとZeroconfがAvahiになってた。間違いなくmDNSResponderを選んでるんだけどな…。
$ afpd -V afpd 3.1.8 - Apple Filing Protocol (AFP) daemon of Netatalk This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. Please see the file COPYING for further information and details. afpd has been compiled with support for these features: AFP versions: 2.2 3.0 3.1 3.2 3.3 3.4 CNID backends: dbd last tdb Zeroconf support: Avahi TCP wrappers support: Yes Quota support: No Admin group support: Yes Valid shell checks: Yes cracklib support: No EA support: ad | sys ACL support: Yes LDAP support: No D-Bus support: Yes Spotlight support: No DTrace probes: No afp.conf: /usr/local/etc/afp.conf extmap.conf: /usr/local/etc/extmap.conf state directory: /var/netatalk/ afp_signature.conf: /var/netatalk/afp_signature.conf afp_voluuid.conf: /var/netatalk/afp_voluuid.conf UAM search path: /usr/local/libexec/netatalk-uams// Server messages path: /var/netatalk/msg/
portsの更新ログ見ると、10/10に「Fix build with mDNSResponder」とあったので、portsがバグってたっぽい。と、ここで、11-RELEASEにした際Portsツリーを更新してなかったことに気付く。
portsnap fetch extractしてportmaster netatalk3したところ、無事mDNSResponderで広告されるようになった。
$ afpd -V afpd 3.1.10 - Apple Filing Protocol (AFP) daemon of Netatalk This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. Please see the file COPYING for further information and details. afpd has been compiled with support for these features: AFP versions: 2.2 3.0 3.1 3.2 3.3 3.4 CNID backends: dbd last tdb Zeroconf support: mDNSResponder TCP wrappers support: Yes Quota support: No Admin group support: Yes Valid shell checks: Yes cracklib support: No EA support: ad | sys ACL support: Yes LDAP support: No D-Bus support: Yes Spotlight support: No DTrace probes: No afp.conf: /usr/local/etc/afp.conf extmap.conf: /usr/local/etc/extmap.conf state directory: /var/netatalk/ afp_signature.conf: /var/netatalk/afp_signature.conf afp_voluuid.conf: /var/netatalk/afp_voluuid.conf UAM search path: /usr/local/libexec/netatalk-uams// Server messages path: /var/netatalk/msg/
3.1.7では問題なかったので、もしかして最近までずっとバグってた系・・・?
FreeBSD 10.1-RELEASEを11.0-RELEASEに更新
FreeBSD 11.0-RELEASEが出たとのことで、家鯖を更新することにした。
10.1-RELEASE-p10からひとっ飛びにあげようとしたら「The update metadata is correctly signed, but failed an integrity check.」と言われて出来なかったので、まずは10.3-RELEASEに更新。もしかするとパッチレベルあげるだけで事足りたかも?
# freebsd-update upgrade -r 10.3-RELEASE # freebsd-update install # reboot # freebsd-update install
10.3-RELEASE-p7になったところで、再度更新を試みたら無事に通った。今回は更新方法がちょっと特殊らしいので要注意。
# : > /usr/bin/bsdpatch # freebsd-update upgrade -r 11.0-RELEASE # freebsd-update install # reboot # freebsd-update install
ここで本来はports/packagesの11.0-RELEASE対応を行うべきだが、とりあえずシステムだけさっさと更新して、ports/packagesの更新は追々行うことにする。この際、忘れずに/etc/rc.confと/boot/loader.confで有効にしているサードパーティ製ソフトを無効化すること。特にloader.confの方を忘れると起動時にカーネルパニック起こして泣きを見る事になり兼ねない(経験談)。
# pkg-static install -f pkg # freebsd-update install # reboot
正しく更新されたか確認。
$ freebsd-version -ku 11.0-RELEASE-p1 11.0-RELEASE-p1
参考サイト
ApacheがCannot load mod_authn_file.soと言って起動しない
社内wikiを立ち上げようと、FreeBSD 10.2-RELEASEにpkgでApache 2.4を入れてservice spache24 startしたら、以下のようなエラーで起動しなかった。
Performing sanity check on apache24 configuration: httpd: Syntax error on line 66 of /usr/local/etc/apache24/httpd.conf: Cannot load libexec/apache24/mod_authn_file.so into server: Cannot open "/usr/home/www/libexec/apache24/mod_authn_file.so" Starting apache24. httpd: Syntax error on line 66 of /usr/local/etc/apache24/httpd.conf: Cannot load libexec/apache24/mod_authn_file.so into server: Cannot open "/usr/home/www/libexec/apache24/mod_authn_file.so" /usr/local/etc/rc.d/apache24: WARNING: failed to start apache24
mod_authn_file.soってLoadModuleの最初の行じゃないですかー、何でこんな所でコケてるんですかー、やだー!
/usr/local/libexec/apache24/mod_authn_file.soは間違いなくあるし、マジ意味わかんないですケド…。今までずっとports版を使ってきたところに、今回はpkgで導入したからそのせい?なんて思ったりしたが、いくら何でも基本中の基本のモジュール読み込みに失敗するようなバイナリが落ちてくるとは考えられない。
で、まぁ上記のログをよく見てみるとCannot open “/usr/home/www/libexec/apache24/mod_authn_file.so”となってるんですな。うん、これは明らかにオカシイですな。
結局原因はというと、DocumentRootを書き換えたつもりでServerRootを書き換えてたという…。みんなも気をつけようね!
DokuWikiにはSessionとXML Parserが必要
前項の社内WikiというのはDokuWikiな訳だが、無事Apacheが起動したので次はDokuWikiのインストーラを起動したみたところ、start_session(), utf8_encode(), utf8_decode()関数がないと言われて進めなかった。これらもpkgでサクッとインスコ。これらだけならphp56-session, php56-xmlを入れれば事足りるが、php56-extensionsを使って標準っぽいモジュール群を入れておく。
pkg install php56-extensions php56-openssl php56-gd php56-mbstring
DokuWikiの動作にはGDとOpenSSLもあった方がいいのでついでに。mbstringは他のPHPスクリプトで使われてそうだから、これも一緒に。
最終的に導入されたモジュールはこんな感じ。
$ php -m [PHP Modules] Core ctype date dom ereg filter gd hash iconv json libxml mbstring mhash mysqlnd openssl pcre PDO pdo_sqlite Phar posix Reflection session SimpleXML SPL sqlite3 standard tokenizer xml xmlreader xmlwriter Zend OPcache zlib [Zend Modules] Zend OPcache
これでようやくDokuWikiが使えるようになった。