2019/08/16(金)少なくとも Passenger Ver 5 以降は、FreeBSD11.3 ではコンパイル不能

2019/08/16 21:57 サーバ運営・管理
発端は、ruby を2.4系から 2.5系にアップデートしたことに始まります。
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
typedef basic_string_view string_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 からでないと、サポートしていない構文を使っている模様。
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
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
ん~、、調べると、この random_shuffle という関数は C++17では「廃止」されたらしい。
なのでエラーになるのです。これには困った・・・というか、バグの類でしょう。。

結局、3箇所修正することで、コンパイルできます。
/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.hpp
 65 #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 サーバ運営・管理
他のFreeBSD バージョンでも恐らく使用可能です。
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
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
使用条件・契約条件を許諾するか否かの問いです。Agree の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
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
上記で、'Congratulation' のメッセージが含まれていたら、作成は成功です。
正直なところ、少し判り難いです。
上記例では有効期限は 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
SSLCertificateFile /usr/local/etc/letsencrypt/live/server.example.com/cert.pem
SSLCertificateKeyFile /usr/local/etc/letsencrypt/live/server.example.com/privkey.pem
 'server.example.com' の部分を、使用するFQDN に合わせて変更します。

最後に自動更新させるには、以下を、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
#表示の便宜上3行に分けているが、実際に適用の際は半角スペースで区切って1行にすること。
 -w のあとのフルパスは、該当 FQDN におけるドキュメントルート絶対パスを指定します。

1日2回の更新チェックが推奨されているようです。しかしながら、実用上、月に1回でもよいと思います。

※ 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

の2つを 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 ファイル生成
(画面上では見やすいように複数行にしているが、実際は半角スペースで区切って1行にしてください):
# 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 は、メールアドレスの@マークの左側を指定します。
ユーザ新規追加の際のみ、設定するパスワード入力を促されます。2回同じパスワードを入力するようになります。
/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"
の2行を追加しておきましょう。
最後に、サーバを再起動するか、 /usr/local/etc/rc.d/saslauthd start で、認証デーモンをスタート出来たら設定完了。

2019/03/16(土)CPU マイクロコードのアップデート

2019/03/16 6:36 サーバ運営・管理
昨年、CPU自体の脆弱性として、「Meltdown」(メルトダウン)と「Spectre」(スペクトル)というものが知られるようになり、対処するためにCPU製造メーカでは、「マイクロコードの修正・更新」という手法を使って居ます。

聞いたことはあっても、『マイクロコードって何?』的な方々が殆どだと思います。
これはCPUの基本的な仕組みを知らない方々に対して言葉で説明するのも難しい代物ですが、
できるだけ簡単に述べると、CPUに対する命令コード(いわゆる昔は「機械語」と言っていた)の解析・実行処理を司る部分の一部を、内部の配線を変更するかの如くに書き換えるのです。

実際に配線を変更するのではなく、同等の効果を得るようにファームウェアを書き換えるようなイメージが最も近いでしょうか。しかし、実際はCPU内部にファームウェアを持っているわけではありません。やはり、CPUの仕組みを習得してもらわないと的確な説明は難しいです、はい。

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.
インストール時にマイクロコードの更新は出来ているようですが、上記の英文見ると、どうやら自動更新させるために更に設定が必要なようです。
自分も含めて英語が苦手な方々向けに説明を残します。

1つ目:
/boot/loader.conf に下記の行を追記:
cpu_microcode_load="YES"
cpu_microcode_name="/boot/firmware/intel-ucode.bin"
再起動で必要に応じ、マイクロコードの更新がされる模様。

2つ目;
/etc/rc.conf に下記の行を追記:
microcode_update_enable="YES"
OSブート時に必要に応じ、マイクロコードの更新がされる模様。

どちらか1つで良さそう(後者だけを指示しているブログ等も見かける)ですが、よくわからないので、とりあえず一応両方入れています。

2019/02/07(木)FreeBSD の portupgrade

2019/02/07 18:47 サーバ運営・管理
FreeBSDを10 から11にしたあと、portupgrade で ports 導入の各ソフトウェアを更新したりすると、
===>  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
実に簡単。上記6つのシンボリックリンクを削除するだけ。これで解決しました。
OSをメジャーバージョンアップデートしたら、依存ライブラリは変更されていることが殆どなので、できるだけ早めに各ソフトウェアは再コンパイルするのが無難。

FreeBSD は、後方互換機能で何事もなく動作することが多いです。
しかしそれに頼り切っていると経験上、ある日突然、不可解な障害に悩むことになるのです。

2019/01/25(金)FreeBSD 12.0 カーネルにバグか

弊社管理サーバ19台の内、5台のサーバを FreeBSD12 に更新したのですが、そのうちの1台だけ、不定期に時折 Panic を起こして再起動を繰り返すサーバが・・・

ログメッセージにこんな感じで現れます:
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 を稼働させている5台のサーバに対し、この不具合対策を行いました。
 数日様子を見て、安定しているようであれば他のサーバも FreeBSD12 に更新予定。

〔2019/02/28(Thu)追記〕
 どうも根本解決には至らない模様。頻度は減ったものの、5~6日経つと、勝手にリブートを繰り返します。
 なので、FreeBSD12 を運用環境に持ってくるのはお勧めできません。当面 FreeBSD 11系でやり過ごすことにします。

〔2019/08/02(Fri)追記〕
 Patch 7(FreeBSD12.0R-p7) あたりで安定した模様。引き続き、しばらく様子を見ます。

2019/01/17(木)ハードウェア不調によりサーバ1台交換。。

2019/01/17 5:13 サーバ運営・管理
昨年春頃から、動作不全に陥るようになったものの、直接、即サービスダウンに結びつくことは無い役割のサーバなのと、その度にハードウェアリセットで復旧するため、騙し騙し使っていたのですが・・

ついに今年に入ってから、ほぼ毎日動作不全に陥るようになったため、「もう寿命なのだろう」ということで、新品と交換。今回はこれ。
20190117_1.jpg


CPUはこれ(左側。画像クリックで少し大きな画像表示します)。店頭で販売していた最も安価なものを選んだ(要求される仕様からみて充分なので)んですが、4コアの模様。
今まで使っていたハードウェアのCPU(右側。画像クリックで少し大きな画像表示します)は新品で購入して、9年3ヶ月使っていた模様です。
20190117_2.jpg
 
20190117_3.jpg


CPUはまだ使えるのですが、SocketAM2 と称される仕様で、新品でマザーボードを入手するのは不可能。 HDDとかはある程度使い回しが利くのですが、最早、IDEインタフェースタイプの ATA133 とか、そういうものは普通に使えなくなっています。

2019/01/05(土)dovecot 2.3.4 はコンパイルエラーになる

2019/01/05 3:09 サーバ運営・管理
FreeBSD 11.2 または 12.0 にて、dovecot をソースコードから構築しようとすると、
途中で下記のようなエラーが出て、構築が出来なくなります:
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 へのアップデートは見合わせたほうがいいかもしれません。

2019/01/04(金)FreeBSD 12.0 に更新する際に気づいたこと

2019/01/05 1:38 サーバ運営・管理
20190104.png

FreeBSD11 からは、5年間(2021年9月まで)のサポート期間が明言されている状態なので、
急いでメジャーバージョンアップデート対応する必要性は無いのだが、やはり動作検証・安定運用の実績は必要なので、メジャーバージョンアップデートしてみました。

FreeBSD12 は、少なくとも 2023年末までのサポートになるものと思われます。
OSのメジャーバージョンアップデートは普通に出来ますが、Ports 等で導入したアプリケーションソフトウェアは、基本的に再構築をかけたほうが無難。

まず、portversion -v コマンドを実行すると、下記のようになります:
root[~][2]# portversion -v
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
[Reading data from pkg(8) ... pkg: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
- 245 packages found - done]
Fetching the ports index ... pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
表示されたとおり、pkg-static install -f pkg を実行して対処します。
これだけでは駄目な場合があり、perl モジュール群の更新で、
encode.c: loadable library and perl binaries are mismatched (got handshake key 0xd480080, needed 0xe180080)
のようなエラーが出て更新自体が出来なくなることがあります。
FreeBSD12 アップデート後にこうなった場合は、現状では、
/usr/local/lib/perl5/site_perl 配下を再構築しないと駄目です。

なので、
# cd /var/db/ports
# rm -rf *
# pkg delete perl5-5.26.3
# cd /usr/local/lib/perl5/site_perl
# rm -rf *
のようにして、perl とその依存モジュールを一旦削除し(ports/pakkage 導入の場合)、
再度新規インストールし直す手順を踏む必要があります。

ここで、perl を最新バージョンへ更新する場合は、
# vi /etc/make.conf
として、以下の行を追記 or 変更します;
DEFAULT_VERSIONS+=perl5=5.28
尚、この手順を踏む前に、
# pkg info -r perl5-5.26.3
などのようにして、インストールされている依存モジュールをメモしておき、抜けが生じないようにしましょう。

あと、perl を最新バージョンにすることは必ずしも得策とは言い切れません。
perl の最新バージョンに対応していないモジュールがあって、パッチを入れる必要があるモジュールが少なからずありますので、このあたりは自己責任で対応してください。

2019/01/02(水)FreeBSD13 になると、10BASE-T LANのサポートは一部終了か

2019/01/02 6:04 サーバ運営・管理
2018/12/11 に FreeBSD 12 がリリースされましたが、
リリースノートの「6.3. Deprecated Drivers」(『非推奨デバイスドライバ』という意味)の中でこんな内容がありました。
The following drivers have been deprecated in FreeBSD 12.0, and not present in FreeBSD 13.0: ae(4), de(4), ed(4), ep(4), ex(4), fe(4), pcn(4), sf(4), sn(4), tl(4), tx(4), txp(4), vx(4), wb(4), xe(4)
要するに、FreeBSD 12 では「非推奨扱い」とし、 FreeBSD 13 で「削除する」扱いのデバイスドライバが列挙されており、大半が 10BASE-T をサポートするLANカード等。

弊社だと、ed(4) が1枚だけなので、影響は小さいですが、1~2年後に提供されるであろう FreeBSD 13 にアップデートする際に慌てないようにする上で、今から考慮しておいたほうがよさそう。

あと、FreeBSD でもサポートを打ち切る対象となるような古すぎるLANカードは捨てるしかなさそう。 いまどきの Windows あたりはとっくにサポート打ち切りとなっているので・・・