2020/11/06(金)rsync 3.2.3 のインストール
2020/11/06 6:33
rsync は、別名「ソフトウェア RAID」とも言われ、任意のディレクトリやファイル単位で複写を行うことが出来るソフトウェアで、ご存じの方も多いでしょう。
ネットワークを介して、物理的に別の機器にバックアップする、といったことが可能です。
今年６月になって、3.2.x にバージョンアップし、現在の最新バージョンは、3.2.3 になっています。
3.2 系になってから、下記のライブラリが必要になった模様。
FreeBSD の場合は、予め Ports で導入してしまいます：
liblz4 (Ports カテゴリ：archivers) zstd (Ports カテゴリ：archivers) xxhash (Ports カテゴリ：devel)その後、
# tar xvzf rsync-3.2.3.tar.gz # cd rsync-3.2.3 # setenv CPPFLAGS '-I/usr/local/include -I/usr/include' # setenv LDFLAGS '-L/usr/local/lib -L/usr/lib' # setenv LD_LIBRARY_PATH '/usr/local/lib /usr/lib' # ./configure --disable-md2man # gmake # gmake install（※注 csh を使用)
とすると、インストールできます。使用方法は、3.1 系と変わりません。
〔2024/06/17 追記〕
rsync の最新版は、3.3系 になっていますが、今のところ、インストールに関しては 3.2系と同様の手順で上手くいくようです。
2020/07/08(水)Whois情報の入力不備？？
2020/07/08 14:52
こちらからすると、「正しい情報」を提示して登録しているのであるが、この有様。
問い合わせしてから２日目の返信とか、対応は今一つだが、全く返信が無いよりはマシですね。
返事内容も「Whois 情報に入力不備がございます」の一点張りで、このままでは埒があかない。
正直なところ営業妨害されている状態で胸糞悪いが、何が問題なのか判らないので「こうして欲しい」が出てこない限りどうにも出来ませんね。
とはいえ、予測は出来ます。悪い奴かもしれませんが、おそらく
実務に合わない変更を強要されることになるので、ここで問題提起です。
ここでは、存在しない住所を敢えて例示しますが、問題なのはおそらく「北５０条西２１丁目」といった住所表記です。
札幌市では市街地の一部が「条丁目」表記になっていて、南北方向は「南〇条」「北〇条」といった表記、東西方向は「東〇丁目」「西〇丁目」といった表記です。
これを一般的な英語表記では、N50W21 のように表記するのが通例。
kita50jo nishi21chome でも通じるとは思うが、表記が長い・却って読みにくい、何よりも「間違いの原因を作る」ので実務では使われないことが多く、当方も見たことが無いですね。
また、電話番号も 札幌の市外局番は011 だが、(英語表記)における通常は先頭のゼロを省き、
日本の国番号 81 を加え、+81.11-987-6543 のような表記が一般的。
たぶん、実務に合う・合わないに関係なく、「体裁だけは整えろ」と強制的に来るだろうと思うところ。
こんなことでゴタゴダするほど暇では無いですが、釈然としないのでね、、、
2020/07/12 追記：
予測したとおり、住所表記がお気に入りでなかっただけの模様でした。
理由も述べずに「不備があります！！！」では、話になりませんね。
これでは「何故こうするのか」が判らない。改善も出来ない。
いつから日本の大手企業は、こうも馬鹿になってしまったのか。
2019/08/16(金)少なくとも Passenger Ver 5 以降は、FreeBSD11.3 ではコンパイル不能
2019/08/16 21:57
redmime を一部のプロジェクトで運用していますが、これを Apache で動作させるために、Passenger という連携モジュールが必要。
今回はこれにハマりました。現状の最新版 Passenger-6.0.2 でも同様です。
先ず、 redmine の動作に必要な ruby ライブラリをインストール後、最後にこのモジュールのインストール作業を行います。
通常、redmine をインストールしたディレクトリにて、
# gem install passenger # passenger-install-apache2-moduleとやるんですが、これがどうも上手く行かない。調べると、上記手順を実施する前に、
# setenv APXS2 '/usr/local/apache2/bin/apxs' # setenv PATH '/bin:/usr/local/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/pgsql/bin:/usr/local/apache2/bin'といった、環境変数の設定が必要な模様。
ソースコードから Apache をインストールした場合、passenger インストーラがApache を確認できないらしい。
これで、
# gem install passengerは、上手く行きます。しかし、
# passenger-install-apache2-moduleは、途中でコンパイルエラーになります。こんな感じ：
/usr/include/c++/v1/string_view:771:37: note: 'Passenger::ApiAccountUtils::string_view' declared here調べると、どうも C++17 からでないと、サポートしていない構文を使っている模様。
typedef basic_string_viewstring_view;
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
1 warning and 20 errors generated.
rake aborted!
Command failed with status (1): [c++ -o buildout/support-binaries/WatchdogMain.o -Isrc/agent -Isrc/cxx_supportlib -Isrc/cxx_supportlib/vendor-copy -Isrc/cxx_supportlib/vendor-modified -Isrc/cxx_supportlib/vendor-modified/libev -Wno-ambiguous-member-template -Isrc/cxx_supportlib/vendor-copy/libuv/include -Isrc/cxx_supportlib/vendor-copy/websocketpp -I/usr/local/include -DHAS_CURL_EASY_RESET -D_REENTRANT -I/usr/local/include -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wpointer-arith -Wwrite-strings -Wno-long-long -Wno-missing-field-initializers -Wno-ambiguous-member-template -fvisibility=hidden -DVISIBILITY_ATTRIBUTE_SUPPORTED -DHAVE_ACCEPT4 -DHAS_SFENCE -DHAS_LFENCE -DPASSENGER_DEBUG -DBOOST_DISABLE_ASSERTS -g -fno-limit-debug-info -Wno-unused-local-typedefs -Wno-format-nonliteral -DHAS_UNORDERED_MAP -c src/agent/Watchdog/WatchdogMain.cpp]
Tasks: TOP => apache2 => buildout/support-binaries/PassengerAgent => buildout/support-binaries/WatchdogMain.o
C++17 をコンパイラに強制させて解決するには、こうします：
# setenv EXTRA_CXXFLAGS '-std=c++17'要するに、上記の環境変数にて、追加のコンパイラオプションを設定し、再度
# passenger-install-apache2-moduleと、するのです。ですが、これで解決するはずが、別の場所でエラーが出ました。こんな感じ：
pedefs -Wno-format-nonliteral -DHAS_UNORDERED_MAP -std=c++17 -c src/cxx_supportlib/IOTools/IOUtils.cppん～、、調べると、この random_shuffle という関数は C++17では「廃止」されたらしい。
src/cxx_supportlib/IOTools/IOUtils.cpp:288:3: error: use of undeclared identifier 'random_shuffle'
random_shuffle(result.begin(), result.end());
^
1 error generated.
rake aborted!
Command failed with status (1): [c++ -o buildout/apache2/module_libpassenger_common/IOTools/IOUtils.o -Isrc/cxx_supportlib -Isrc/cxx_supportlib/vendor-copy -Isrc/cxx_supportlib/vendor-modified -Isrc/cxx_supportlib/vendor-modified/libev -Wno-ambiguous-member-template -Isrc/cxx_supportlib/vendor-copy/libuv/include -O -fPIC -I/usr/local/apache2/include -I/usr/local/apache2/include -I/usr/local/apache2/include -D_REENTRANT -I/usr/local/include -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wpointer-arith -Wwrite-strings -Wno-long-long -Wno-missing-field-initializers -Wno-ambiguous-member-template -fvisibility=hidden -DVISIBILITY_ATTRIBUTE_SUPPORTED -DHAVE_ACCEPT4 -DHAS_SFENCE -DHAS_LFENCE -DPASSENGER_DEBUG -DBOOST_DISABLE_ASSERTS -g -fno-limit-debug-info -Wno-unused-local-typedefs -Wno-format-nonliteral -DHAS_UNORDERED_MAP -std=c++17 -c src/cxx_supportlib/IOTools/IOUtils.cpp]
Tasks: TOP => apache2 => buildout/apache2/mod_passenger.so => buildout/apache2/module_libpassenger_common/IOTools/IOUtils.o
なのでエラーになるのです。これには困った・・・というか、バグの類でしょう。。
結局、３箇所修正することで、コンパイルできます。
/usr/local/lib/ruby/gems/2.5/gems/passenger-6.0.2/src/cxx_supportlib/IOTools/IOUtils.cpp
37 #include <algorithm>
38 #include <string>
39 #include <vector>
+ 40 #include <random>
41 #include <sys/socket.h>
42 #include <sys/types.h>
287 freeaddrinfo(res);
288 if (shuffle) {
289 // random_shuffle(result.begin(), result.end());
+ 290 std::shuffle(result.begin(), result.end(),std::mt19937());
291 }
292 return result;
293 }
/usr/local/lib/ruby/gems/2.5/gems/passenger-6.0.2/src/cxx_supportlib/vendor-copy/websocketpp/websocketpp/common/memory.hpp65 #ifdef _WEBSOCKETPP_CPP11_MEMORY_ 66 using std::shared_ptr; 67 using std::weak_ptr; 68 // using std::auto_ptr; 69 using std::enable_shared_from_this; 70 using std::static_pointer_cast; 71 using std::make_shared; 72 using std::unique_ptr;ソースコード修正後、
# setenv EXTRA_CXXFLAGS '-std=c++17' # passenger-install-apache2-moduleとすることで、使用できるモジュールが出来上がるようです。
2019/07/12(金)FreeBSD11/FreeBSD12 にて無償利用可能なサーバ証明書 Let's Encrypt を使う
2019/07/12 17:39
Let's Encrypt は、有効期間90日（自動延長可能）な無償サーバ証明書です。
FreeBSD におけるやり方について、余り情報が書かれていないので、ここで提示しておきます。
これを使うには、先ずは使用するサーバにて、管理ツールのようなものをインストールします：
FreeBSD Ports においては、 securiry/py-certbot をインストールします。
＃Python を使用したスクリプトなので、依存関係で Python 本体と、動作に必要な python モジュールが
＃インストールされます。
インストールが終わったら、Apache や nginx を一旦停止して、
のようにコマンドを入力します。# certbot certonly --standalone -d 《FQDN名》-m 《通知電子メールアドレス》
# certbot certonly --standalone --non-interactive --agree-tos --keep --expand --email 《通知電子メールアドレス》 --no-eff-email --domains 《FQDN名》
＃このスクリプトが一時的に http サーバになるため、ポート番号が競合するからのようです。
《FQDN名》は、証明書発行申請するときのコモン名。例えば https://server.example.com/ のサーバ証明書が欲しければ、 ここに server.example.com と記述します。
《通知電子メールアドレス》は、何かある場合に連絡が入る電子メールアドレスを指定します。
実在する電子メールアドレスを指定します。
証明書の期限が間近になった場合などに連絡が入るようです。
コマンドの実行が始まると、先ず、下記のメッセージが表示されます：
Saving debug log to /var/log/letsencrypt/letsencrypt.log使用条件・契約条件を許諾するか否かの問いです。Agree のA を入力します。
Plugins selected: Authenticator standalone, Installer None
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v02.api.letsencrypt.org/directory
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(A)gree/(C)ancel: A
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -次に、各種の連絡を電子メールで送るけれど、本当に良いか？ という趣旨の問いです。
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about our work
encrypting the web, EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: Y
これも Yes の Y を入力します。
Obtaining a new certificate上記で、'Congratulation' のメッセージが含まれていたら、作成は成功です。
Performing the following challenges:
http-01 challenge for server.example.com
Waiting for verification...
Cleaning up challenges
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/usr/local/etc/letsencrypt/live/server.example.com/fullchain.pem
Your key file has been saved at:
/usr/local/etc/letsencrypt/live/server.example.com/privkey.pem
Your cert will expire on 2019-10-10. To obtain a new or tweaked
version of this certificate in the future, simply run certbot
again. To non-interactively renew *all* of your certificates, run
"certbot renew"
- Your account credentials have been saved in your Certbot
configuration directory at /usr/local/etc/letsencrypt. You should
make a secure backup of this folder now. This configuration
directory will also contain certificates and private keys obtained
by Certbot so making regular backups of this folder is ideal.
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
正直なところ、少し判り難いです。
上記例では有効期限は 2019/10/10 だと言っています。
失敗しているような場合は、再度、
上記のコマンドを入力してみましょう。# certbot certonly --standalone -d 《FQDN名》-m 《通知電子メールアドレス》
# certbot certonly --standalone --non-interactive --agree-tos --keep --expand --email 《通知電子メールアドレス》 --no-eff-email --domains 《FQDN名》
但し、FQDN名がDNSで正引き出来ないと、上手く行かないみたいです。
Apache には以下の要領で設定します (要所を抜粋)：
SSLCACertificateFile /usr/local/etc/letsencrypt/live/server.example.com/chain.pem'server.example.com' の部分を、使用するFQDN に合わせて変更します。
SSLCertificateFile /usr/local/etc/letsencrypt/live/server.example.com/cert.pem
SSLCertificateKeyFile /usr/local/etc/letsencrypt/live/server.example.com/privkey.pem
最後に自動更新させるには、以下を、crontab に追加します：
0 6,21 * * * /usr/local/bin/certbot renew --agree-tos --webroot -w＃表示の便宜上３行に分けているが、実際に適用の際は半角スペースで区切って１行にすること。
/home/webroot/server.example.com/public --renew-by-default
&& /usr/local/etc/rc.d/apache2 restart
-w のあとのフルパスは、該当 FQDN におけるドキュメントルート絶対パスを指定します。
１日２回の更新チェックが推奨されているようです。しかしながら、実用上、月に１回でもよいと思います。
※ certbot certonly コマンドが例示だと上手く動作しなくなっていたので、動作確認出来た内容に修正。〔2021/09/13〕
2019/06/05(水)Postfix にて Cyrus SASL 認証のセットアップ
2019/06/05 17:31
以前は管理の都合上、ソースコードから構築していたが、最近はFreeBSD でも Ports から導入する方が確実。
最近の FreeBSD では、素の Cyrus-SASL ソースコードでは色々面倒なことのほうが多い。
security/cyrus-sasl-2.1.27
security/cyrus-sasl-saslauthd-2.1.27_1
の２つを Ports からインストールします。
その後で、SMTP 認証にCyrus SASL を使えるように Postfix をセットアップします。
Postfix は、Ports ではなく、ソースコードから構築しないと、管理上却って面倒。
root で先ずはこんな感じで環境設定：
# setenv CPPFLAGS '-I/usr/local/include -I/usr/local/include/db5 -I/usr/include -I/usr/local/include/sasl' # setenv LDFLAGS '-L/usr/local/lib -L/usr/local/lib/db5 -L/usr/lib' # setenv LD_LIBRARY_PATH '/usr/local/lib /usr/local/lib/db5 /usr/lib'これやらないと、当方の環境ではコンパイル自体が上手く行かないんです。
続いて root で make ファイル生成
（画面上では見やすいように複数行にしているが、実際は半角スペースで区切って１行にしてください）：
# make -f Makefile.init makefiles
'CCARGS=-DUSE_TLS -DUSE_SASL_AUTH -DUSE_CYRUS_SASL
-I/usr/local/include -I/usr/local/include/sasl -I/usr/include/openssl'
'AUXLIBS=-L/usr/lib -lssl -lcrypto
-L/usr/local/lib -lsasl2 -licudata -licui18n -licuio -licutest -licutu -licuuc
-L/usr/local/lib/db5 -ldb'
これが上手く出来れば、あとは普通に # make # make install # rehashとすれば、Cyrus SASL 認証サポート対応の Postfix が出来るはず。
続いて設定：
下記の内容で、 /usr/local/lib/saal2/smtpd.conf のテキストファイルを作成：
pwcheck_method: auxpropこの設定は、cyrus SASL 独自で認証ユーザを管理することを意味します。
サーバ自身にユーザアカウントを追加せずに済むので、このメールアドレス管理方法はお勧めです。
以下でメールアドレスを設定・管理できます：
# saslpasswd2 -c -u example.com xxxxuser （ユーザ新規追加） # saslpasswd2 -d -u example.com xxxxuser （ユーザの削除） # sasldblistusers2 （登録ユーザの確認）ここで、example.com は実際に使用するドメイン名、 xxxxuser は、メールアドレスの＠マークの左側を指定します。
ユーザ新規追加の際のみ、設定するパスワード入力を促されます。２回同じパスワードを入力するようになります。
/usr/local/etc/sasldb2 に登録されます。このファイルのパーミッションは 644 にしておきます。
更に、/etc/postfix/main.cf に下記の設定追加：
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = cyrus
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $mydomain
smtpd_relay_restrictions = permit_mynetworks,
permit_sasl_authenticated,
defer_unauth_destination
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination
smtpd_helo_restrictions = permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination
最後に自動起動の設定です。/etc/rc.conf にsaslauthd_enable="YES" saslauthd_flags="-a pam"の２行を追加しておきましょう。
最後に、サーバを再起動するか、 /usr/local/etc/rc.d/saslauthd start で、認証デーモンをスタート出来たら設定完了。
2019/03/16(土)CPU マイクロコードのアップデート
2019/03/16 6:36
聞いたことはあっても、『マイクロコードって何？』的な方々が殆どだと思います。
これはＣＰＵの基本的な仕組みを知らない方々に対して言葉で説明するのも難しい代物ですが、
できるだけ簡単に述べると、ＣＰＵに対する命令コード（いわゆる昔は「機械語」と言っていた）の解析・実行処理を司る部分の一部を、内部の配線を変更するかの如くに書き換えるのです。
実際に配線を変更するのではなく、同等の効果を得るようにファームウェアを書き換えるようなイメージが最も近いでしょうか。しかし、実際はＣＰＵ内部にファームウェアを持っているわけではありません。やはり、ＣＰＵの仕組みを習得してもらわないと的確な説明は難しいです、はい。
FreeBSD においては、Ports の中の sysutils/devcpu-data をインストールすることで可能です。
# cd /usr/ports/sysutils/devcpu-data # make installインストール完了時にこのようなメッセージが出ます：
The first method ensures that any CPU features introduced by a microcode update are visible to the kernel. In other words, the update is loaded before the kernel performs CPU feature detection. To enable updates using the first method, add the following lines to the system's /boot/loader.conf: cpu_microcode_load="YES" cpu_microcode_name="/boot/firmware/intel-ucode.bin" This method will not load the microcode update until the system is rebooted. To enable updates using the second method, add the following line to the system's /etc/rc.conf: microcode_update_enable="YES" Updating CPU Microcode... /usr/local/share/cpucontrol/m32306c3_00000022.fw: updating cpu /dev/cpuctl0 from rev 0x17 to rev 0x22... done. /usr/local/share/cpucontrol/m32306c3_00000022.fw: updating cpu /dev/cpuctl2 from rev 0x17 to rev 0x22... done. /usr/local/share/cpucontrol/m32306c3_00000022.fw: updating cpu /dev/cpuctl4 from rev 0x17 to rev 0x22... done. /usr/local/share/cpucontrol/m32306c3_00000022.fw: updating cpu /dev/cpuctl6 from rev 0x17 to rev 0x22... done. Done.インストール時にマイクロコードの更新は出来ているようですが、上記の英文見ると、どうやら自動更新させるために更に設定が必要なようです。
自分も含めて英語が苦手な方々向けに説明を残します。
１つ目：
/boot/loader.conf に下記の行を追記：
cpu_microcode_load="YES" cpu_microcode_name="/boot/firmware/intel-ucode.bin"再起動で必要に応じ、マイクロコードの更新がされる模様。
２つ目；
/etc/rc.conf に下記の行を追記：
microcode_update_enable="YES"ＯＳブート時に必要に応じ、マイクロコードの更新がされる模様。
どちらか１つで良さそう（後者だけを指示しているブログ等も見かける）ですが、よくわからないので、とりあえず一応両方入れています。
2019/02/07(木)FreeBSD の portupgrade
2019/02/07 18:47
===> Cleaning for ImageMagick7-nox11-7.0.8.22 ---> Cleaning out obsolete shared libraries No such file or directory @ realpath_rec - /usr/local/lib/compat/pkg/db5 No such file or directory @ realpath_rec - /usr/local/lib/compat/pkg/db5 No such file or directory @ realpath_rec - /usr/local/lib/compat/pkg/db5 No such file or directory @ realpath_rec - /usr/local/lib/compat/pkg/db5 No such file or directory @ realpath_rec - /usr/local/lib/compat/pkg/db5 No such file or directory @ realpath_rec - /usr/local/lib/compat/pkg/db5のようなメッセージが毎回出るようにになります。実害は無いのでほったらかし状態だったが、気になるものは気になるので、対策を。。
# cd /usr/local/lib/compat/pkg # ls -al lrwxr-xr-x 1 root wheel 22 7月 4 2018 libdb_cxx-5.3.so.0@ -> db5/libdb_cxx-5.3.so.0 lrwxr-xr-x 1 root wheel 18 7月 4 2018 libdb_cxx-5.so.0@ -> libdb_cxx-5.3.so.0 lrwxr-xr-x 1 root wheel 22 7月 4 2018 libdb_stl-5.3.so.0@ -> db5/libdb_stl-5.3.so.0 lrwxr-xr-x 1 root wheel 18 7月 4 2018 libdb_stl-5.so.0@ -> libdb_stl-5.3.so.0 lrwxr-xr-x 1 root wheel 18 7月 4 2018 libdb-5.3.so.0@ -> db5/libdb-5.3.so.0 lrwxr-xr-x 1 root wheel 14 7月 4 2018 libdb-5.so.0@ -> libdb-5.3.so.0実に簡単。上記６つのシンボリックリンクを削除するだけ。これで解決しました。
ＯＳをメジャーバージョンアップデートしたら、依存ライブラリは変更されていることが殆どなので、できるだけ早めに各ソフトウェアは再コンパイルするのが無難。
FreeBSD は、後方互換機能で何事もなく動作することが多いです。
しかしそれに頼り切っていると経験上、ある日突然、不可解な障害に悩むことになるのです。
2019/01/25(金)FreeBSD 12.0 カーネルにバグか
2019/01/25 5:30
ログメッセージにこんな感じで現れます：
Jan 25 04:15:46 uranus kernel: Fatal trap 12: page fault while in kernel mode Jan 25 04:15:46 uranus kernel: cpuid = 1; apic id = 01 Jan 25 04:15:46 uranus kernel: fault virtual address = 0xd8 Jan 25 04:15:46 uranus kernel: fault code = supervisor read data, page not present Jan 25 04:15:46 uranus kernel: instruction pointer = 0x20:0xffffffff8091527d Jan 25 04:15:46 uranus kernel: stack pointer = 0x28:0xfffffe00185b9560 Jan 25 04:15:46 uranus kernel: frame pointer = 0x28:0xfffffe00185b96b0 Jan 25 04:15:46 uranus kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Jan 25 04:15:46 uranus kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Jan 25 04:15:46 uranus kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Jan 25 04:15:46 uranus kernel: current process = 0 (if_io_tqg_1) Jan 25 04:15:46 uranus kernel: trap number = 12 Jan 25 04:15:46 uranus kernel: panic: page fault Jan 25 04:15:46 uranus kernel: cpuid = 1 Jan 25 04:15:46 uranus kernel: time = 1548357259 Jan 25 04:15:46 uranus kernel: KDB: stack backtrace: Jan 25 04:15:46 uranus kernel: #0 0xffffffff8077a8c7 at kdb_backtrace+0x67 Jan 25 04:15:46 uranus kernel: #1 0xffffffff8072e4b3 at vpanic+0x1a3 Jan 25 04:15:46 uranus kernel: #2 0xffffffff8072e303 at panic+0x43 Jan 25 04:15:46 uranus kernel: #3 0xffffffff80a6496f at trap_fatal+0x35f Jan 25 04:15:46 uranus kernel: #4 0xffffffff80a649c9 at trap_pfault+0x49 Jan 25 04:15:46 uranus kernel: #5 0xffffffff80a63fee at trap+0x29e Jan 25 04:15:46 uranus kernel: #6 0xffffffff80a3f825 at calltrap+0x8 Jan 25 04:15:46 uranus kernel: #7 0xffffffff808feb43 at tcp_input+0x1553 Jan 25 04:15:46 uranus kernel: #8 0xffffffff80876a55 at ip_input+0x145 Jan 25 04:15:46 uranus kernel: #9 0xffffffff8084f496 at netisr_dispatch_src+0xd6 Jan 25 04:15:46 uranus kernel: #10 0xffffffff80833d83 at ether_demux+0x163 Jan 25 04:15:46 uranus kernel: #11 0xffffffff80834ee6 at ether_nh_input+0x346 Jan 25 04:15:46 uranus kernel: #12 0xffffffff8084f496 at netisr_dispatch_src+0xd6 Jan 25 04:15:46 uranus kernel: #13 0xffffffff80834184 at ether_input+0x54 Jan 25 04:15:46 uranus kernel: #14 0xffffffff8084b646 at iflib_rxeof+0xa16 Jan 25 04:15:46 uranus kernel: #15 0xffffffff80846476 at _task_fn_rx+0x76 Jan 25 04:15:46 uranus kernel: #16 0xffffffff80779154 at gtaskqueue_run_locked+0x144 Jan 25 04:15:46 uranus kernel: #17 0xffffffff80778db8 at gtaskqueue_thread_loop+0x98 Jan 25 04:15:46 uranus kernel: Uptime: 4h16m16s Jan 25 04:15:46 uranus kernel: ---<<BOOT>>---どうも、これに似ている模様・・・：
Bug 234296 - FreeBSD 12.0-STABLE r342216 Fatal trap 12
IPv4,IPv6 を直接扱う部分のようです。どうやら解決をみたらしいのですが、まだリリースバージョンへの反映はなされていません。FreeBSD12 への更新は様子見したほうがよさそう。
〔2019/02/06(Wed)追記〕
昨日、リリースバージョン向けの対策版(FreeBSD 12.0-p3) が公開されたので、早速、本日未明から午前中にかけてFreeBSD 12 を稼働させている５台のサーバに対し、この不具合対策を行いました。
数日様子を見て、安定しているようであれば他のサーバも FreeBSD12 に更新予定。
〔2019/02/28(Thu)追記〕
どうも根本解決には至らない模様。頻度は減ったものの、５～６日経つと、勝手にリブートを繰り返します。
なので、FreeBSD12 を運用環境に持ってくるのはお勧めできません。当面 FreeBSD 11系でやり過ごすことにします。
〔2019/08/02(Fri)追記〕
Patch 7(FreeBSD12.0R-p7) あたりで安定した模様。引き続き、しばらく様子を見ます。
2019/01/17(木)ハードウェア不調によりサーバ１台交換。。
2019/01/17 5:13
ついに今年に入ってから、ほぼ毎日動作不全に陥るようになったため、「もう寿命なのだろう」ということで、新品と交換。今回はこれ。
ＣＰＵはこれ（左側。画像クリックで少し大きな画像表示します）。店頭で販売していた最も安価なものを選んだ（要求される仕様からみて充分なので）んですが、４コアの模様。
今まで使っていたハードウェアのＣＰＵ（右側。画像クリックで少し大きな画像表示します）は新品で購入して、９年３ヶ月使っていた模様です。
ＣＰＵはまだ使えるのですが、SocketAM2 と称される仕様で、新品でマザーボードを入手するのは不可能。 ＨＤＤとかはある程度使い回しが利くのですが、最早、ＩＤＥインタフェースタイプの ATA133 とか、そういうものは普通に使えなくなっています。
2019/01/05(土)dovecot 2.3.4 はコンパイルエラーになる
2019/01/05 3:09
途中で下記のようなエラーが出て、構築が出来なくなります：
test-event-stats.c: In function 'kill_stats_child':どうやら調査すると、構築環境依存による（？）バグらしく、パッチが出ていました：
test-event-stats.c:101:2: warning: implicit declaration of function 'kill'
[-Wimplicit-function-declaration]
(void)kill(stats_pid, SIGKILL);
^
test-event-stats.c:101:24: error: 'SIGKILL' undeclared (first use in this
function)
(void)kill(stats_pid, SIGKILL);
^
test-event-stats.c:101:24: note: each undeclared identifier is reported
only once for each function it appears in
gmake[2]: *** [Makefile:656: test-event-stats.o] Error 1
gmake[2]: Leaving directory
'/usr/local/src/dovecot-2.3.4/src/lib-master'
gmake[1]: *** [Makefile:565: install-recursive] Error 1
gmake[1]: Leaving directory
'/usr/local/src/dovecot-2.3.4/src'
gmake: *** [Makefile:683: install-recursive] Error 1
https://github.com/dovecot/core/compare/10048229%5E...de42b54a.patch
このパッチでコンパイル自体は通りますが、実際の運用で問題ないかどうかまでは判りません。
dovecot 2.3.3 で特段問題が出ていない場合、2.3.4 へのアップデートは見合わせたほうがいいかもしれません。