ラベル NetBSD の投稿を表示しています。 すべての投稿を表示
ラベル NetBSD の投稿を表示しています。 すべての投稿を表示

NetBSDでlibuvがコンパイルできない件。

自分用メモです。

NetBSD-8 で Neovim の master ブランチをビルドしようとしたら、libuv で
~/build/neovim/.deps/build/src/libuv/src/unix/thread.c:222:22: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function)
     if (stack_size < PTHREAD_STACK_MIN)
                      ^
というエラーが出て、コンパイルできませんでした。 ちょっと調べてみると、/usr/include/limits.h
/*
 * These are the correct names, defined in terms of the above
 * except for PTHREAD_KEYS_MAX which is bigger than standard
 * mandated minimum value _POSIX_THREAD_KEYS_MAX.
 */
#define PTHREAD_DESTRUCTOR_ITERATIONS   _POSIX_THREAD_DESTRUCTOR_ITERATIONS
#define PTHREAD_KEYS_MAX                256
/* Not yet: PTHREAD_STACK_MIN */
#define PTHREAD_THREADS_MAX             _POSIX_THREAD_THREADS_MAX
という部分があり、確かに定義されていません。 さらに調べてみると、NetBSD の tech-userlevel メーリングリストで2014年にPTHREAD_STACK_MINというメールが投げられていました。そこでの結論は、 PTHREAD_STACK_MINの代わりにsysconf(_SC_THREAD_STACK_MIN)を使ったほうが安全、ということのようです。 一方 libuv のほうでは、今年の4月に Do not use PTHREAD_STACK_MIN unconditionally for the unix target #2252というのが出ており、結果として「定義されていれば使用する」という形に落ち着いたようです。途中、GNU じゃない FreeBSD とか NetBSD は libuv はサポートせんよ、みたいな投稿もありましたが。

ともあれ、現状では Neovim の CMake では libuv-1.26.0(2019年2月11日リリース)を使用しているようで、1.29.0 では上記の変更が反映されているようなので、そのうち修正なしでコンパイルできるようになるでしょう。

Neovim でのコンパイルにおいては、最初にある thread.c に #2252 のパッチを当てればいいかと思います。

NetBSDとBIND 9。

ふと、インターリンクで IPv6 に対応しているから、じゃあやってみるためにちょっと調べようと思いまして。

うちは 光ルーターとして RS-500KI を使っています。この場合、インターリンクに接続するとここで示唆されている通り、.hgw6 が付加されて接続できません。そしてこの設定はユーザがいじることができません

であれば、光ルーターはただのブリッジにして、内側には Aterm WG1900HP があるのでそれを使って IPv6 PPPoE してやればできるんじゃないかと思ったわけです。いずれにしてもインターリンクは IPoE はやっていないので、だれかが PPPoE してやればいいわけです。当然ながらフレッツ・v6オプションは有効になっています。

と、周囲の状況を確認した上で、さてネームサーバはどうしましょう、と。
NetBSD は 1.3 の頃にいじり始めて、サーバとしてドメインをとって BIND とかをいじり始めたのは 2003年以降だったと思いますが、当初は ADSL 回線でした。当時は DNS サーバは WAKWAK 側で用意していたので、こちらでは権威サーバではなくローカルの名前解決用として使うくらいでした。
その後、インターリンクにプロバイダを切り替えたのは独自ドメインが安く取得できるからという理由です。最近はさくらインターネットなどでも安価に運用できるようになっていますが、おうちサーバを立てるなら全部自分でやってね、プライマリネームサーバもね、というスタンスのインターリンクはやる気になればいろいろできるので便利です。サブドメインや仮想ホスト(CNAME)も作り放題ですし。

ということでネームサーバですが、BINDの設定を見ていて、そういえば /usr/share/example に IPv6 の設定例みたいなのがあるのでは、と探してみたところ、bind のサンプルが収録されていません。変だな、と思って他のサンプルを見てみると、nsd と unbound があります。おや?と不審に思って検索してみたら、2016年8月に bind -> unbound/nsd というメールが christos 氏から投げられていて、ISC が BIND のライセンスを変更したから、NetBSD に収録する DNS サーバの変更を検討したほうがいいんじゃね?と提起されていました。その結果、おそらく BIND は積極的には使わない方向にいっているのかもしれません。

ともあれ BIND の設定サンプルはないようだし、BIND の設定は面倒だし、もうちょっと楽にできないかしらというのもあって、NSDUNBOUND が採用されたようだし、みてみることにしました。

NSD も UNBOUND もどちらも NLnet Labs の製品で、NSD は権威サーバ、UNBOUND はキャッシュ&リゾルバです。それ以外には packages に PowerDNSもあります。

とりあえず、本家の流れに従って、BIND から NSD/UNBOUND に移行してみましょうか。

From Bind to nsd and unbound on OpenBSD 5.6を参考にすると、NSD では BIND の ZONE ファイルをそのまま使えるようです。であれば権威サーバの移行はスムーズです。
ArchLinux の Wiki にも NSDUNBOUND のページがあります。また、日本 Unbound ユーザ会が日本語ドキュメントを用意してくれています。ちなみに NetBSD-8 の base.tgz には nsd は含まれていませんが、ソースツリーには /usr/src/external/bsd/nsd にあるので make install すれ使えるようになります。バイナリが含まれていないのは権威サーバが必要な人は make くらいできるでしょ、という感じでしょうか。
ちなみに NetBSD-8 の nsd は 4.1.14(2016/12)、unbound は 1.6.8(2018/1) です。新しいバージョンは pkgsrc/net にありますので、必要な人は各自インストールでしょう。

php-fpmの動作確認。

Apache 2.4 の構成をいろいろといじっています。

Apacheのmod_cgiとmod_cgidとpreforkとevent。でも触れていますが、PHP と Perl と Python をそれぞれ別のアプリケーションで使いたいということなのですが、歴史的な経緯もあり、Perl は太古の CGI(ゆいちゃっと)、PHP は WordPress、Python は GNU Mailman 2 となります。それぞれの API は、ゆいちゃっとと Mailman が CGI で、WordPress が FastCGI を使おうと考えています。実際には CGI と FastCGI はアプリケーションから見ると同じなので、結局すべてを CGI または FastCGI でやる、という感じです。

NetBSD の pkgsrc では、www/fcgi に cgi-fcgi という実行形式が含まれていて、CGI 形式でリクエストを送ると、FastCGI として FastCGI デーモンに投げ、応答を再度 CGI 形式にして返してくれます。php-fpm で使ってみるとこんな感じ。
$SCRIPT_NAME=info.php SCRIPT_FILENAME=/srv/www/Test/info.php REQUEST_METHOD=GET cgi-fcgi -bind -connect /var/run/php_fpm.sock

Apache の mod_cgid は、ちょっと勘違いしていたんですが、Apache 2.4 の説明をよく読むと、
Unix オペレーティングシステムの中には、マルチスレッドのサーバから プロセスを fork するのが非常にコストの高い動作になっているものがあります。 理由は、新しいプロセスが親プロセスのスレッドすべてを複製するからです。 各 CGI 起動時にこのコストがかかるのを防ぐために、mod_cgid は子プロセスを fork して CGI スクリプトを実行するための 外部デーモンを実行します。 主サーバは unix ドメインソケットを使ってこのデーモンと通信します。
となっていて、mod_cgid 自体が子プロセスを fork して外部デーモンを起動する、ということは、別途外部デーモンを用意する必要はなく、そのあたりは mod_cgid で面倒を見てくれる、ということのようです。prefork で使われる mod_cgi は自分自身で面倒を見るけれど、worker/event で使われる mod_cgid は自分でデーモンを起動してそちらに任せる、ということで、アプリケーションから見ると何も変わらないことになります。

ということであれば、上記の Perl / PHP / Python のアプリケーションは全部 mod_cgid で引き受けることができそうです。外部に CGI サーバを別途用意するなら uWSGI の CGI plugin を使って、とか考えていましたが、特に必要はなさそうです。

一方、php-fpm などの FastCGI サーバが動かせるタイプのものは mod_proxy_fcgi を使ってやれば、Apache からプロセスを切り離すことができます。

ところで PHP 7.3.4 で preg_match() あたりで JIT 警告(正確には、"Warning: preg_match(): JIT compilation failed: no more memory in xxx")が出てるんですが、5月2日にリリースされた 7.3.5 では修正されているようですね。

bozohttpd。

NetBSD で Apache のオプションでモジュール一覧をするのがあったよな、と思い、詳細を確認しようとして man page を見ようとしたら、man apache はなくて、man httpd したらオプションの説明が期待したものと違っていて、ふとタイトルを見ると "BOZOHTTPD(8)" となっていました。なにそれと思ったら、
bozohttpd ? hyper text transfer protocol version 1.1 daemon
ということで、なんと NetBSD に標準で組み込まれている http daemon のようです。
今まで知らなかったのは最初から Apache を使ってたからでしょうけど、調べてみると 1999年5月19日に加えられたようです。歴史的には NetBSD-1.4 なので、たしか自分が NetBSD に手を出したのは Sparc のピザボックスでそのときは 1.3 だった気がするので、もうほとんど最初からそこにあったのに気づかなかったのですね。

pkgsrc の DESCR を見ると、
bozohttpd is a small and secure HTTP version 1.1 server. Its main
feature is the lack of features, reducing the code size and improving
verifiability.

It supports CGI/1.1, HTTP/1.1, HTTP/1.0, HTTP/0.9, ~user translations,
virtual hosting support, as well as multiple IP-based servers on a
single machine. It is capable of servicing pages via the IPv6 protocol.
It has SSL support. It has no configuration file by design.
とあって、CGI も IPv6 も SSL も仮想ホストもサポートしているようです。IPv6 については2000年に itojun 氏が追加しているようです。

ドキュメントはあまりないようで、pkgsrc のほうを見ても man page しかないようです。

bogofilterのデータベースの再構築。

おうちサーバについてちょっと触れたのは、プロバイダ(wakwak)で受信するメールのSPAM振り分け処理をおうちサーバでやっているからなのですが、最近またこぼれて、というかすり抜けてくるSPAMメールが固定化されてきているので、データベースを作り直しました。

プロバイダ側にもSPAM検出の機能はありますが、注意していないとHAMの誤判定で大事なメールをロスト、とかあると困りますので、一旦全部フェッチする、という戦略です。

まず構成ですが、プロバイダ→おうちサーバのfetchmailでフェッチ→mailfilterでSPAM判定処理→受信箱 という形になっています。おうちサーバで courier-imap4 と courier-pop3 を動かし、受信箱は Maildir 形式です。
mailfilter(maildrop)では、特定のメールアドレスからのメールはSPAMフィルタに通さずにふるい分け、その他のメールは nkfで強制UTF-8化→mecabで分かち書き→bogofilterに通してSPAM判定→reformailでヘッダに細工→maildropでフォルダに振り分け という処理をしています。
判定自体はメールそのものには手を加えないので、すべて UTF-8 にしてから判定処理を行い、その判定結果を元のメールヘッダに追加することにしています。なので、bogofilter に学習させるときにも、すべて UTF-8 にしてから単語登録させています。

bogofilter は NetBSD の package システムでインストールする際に、
PKG_OPTIONS.bogofilter=tokyocabinet
して、検索用のデータベースは tokyocabinet にしています。

そこまではいいとして、じゃあ学習(training)はどうするか、ですが、以下のようなシェルスクリプトを使っています。

#!/usr/pkg/bin/bash

if [ $# -lt 2 ]; then
    echo "number of args: $#"
    echo "usage: `basename $0` [ham|spam] directories..."
    echo "at least two arguments must be specified."
    echo "The first argument must be one of [ham|spam],"
    echo "and the second must be directory, not file."
    exit 1
fi

DIC=/usr/pkg/lib/mecab/dic/jumandic
#DIC=/usr/pkg/lib/mecab/dic/ipadic
#DIC=/usr/pkg/lib/mecab/dic/naist-jdic

shopt -s nocasematch

if [[ $1 == "ham" ]]; then
    ARG="-n"
elif [[ $1 == "spam" ]]; then
    ARG="-s"
else
    echo "usage: `basename $0` [ham|spam] directories..."
    echo "the argument must be one of [ham|spam]."
    exit 1
fi

if [ ! -d $2 ]; then
    echo "usage: `basename $0` [ham|spam] directories..."
    echo "at least one directory must be specified."
    echo "and it must be directory, not file."
    exit 1
fi

shift

for dir in $* ; do
    for i in $dir/* ; do
        GUESS="`nkf --guess=1 $i`"
        case $GUESS in
        ISO-2022-JP)
            nkf -J -w $i | mecab -d $DIC -Owakati | bogofilter $ARG
            ;;
        Shift_JIS)
            nkf -S -w $i | mecab -d $DIC -Owakati | bogofilter $ARG
            ;;
        CP932)
            nkf -S -w $i | mecab -d $DIC -Owakati | bogofilter $ARG
            ;;
        EUC-JP)
            nkf -E -w $i | mecab -d $DIC -Owakati | bogofilter $ARG
            ;;
        UTF-8)
            mecab -d $DIC -Owakati $i | bogofilter $ARG
            ;;
        *)
            bogofilter $ARG -B $i
            ;;
        esac
    done
done
まあ無駄な処理、といか全部 nkf -w でいいじゃん、という話もありますが、一応日本語とそれ以外を分けたほうがいいかな、というのと、少しでも処理を軽くしたほうがいいかな、というのでこうしています。

時々こういう処理をしないと、誤判定のメールを再学習させてもあまり改善されず誤判定が繰り返されることがあるので、定常的に同じようなメールを誤判定することが続いたらデータベースを削除して作り直すことにしています。

ちなみに上記の学習をさせるために、SPAMメールもHAM(SPAMじゃない)メールもディスクの肥やしではないけれど保存してあります。ただ、SPAMメールで使われる単語などの傾向は年代によっても変わるようなので、もしも誤判定が増えたり同じメールを何度学習させても間違えるときにはデータベースの再構築が有効だと思います。

うちの場合にはSPAMが平均して月に1200通くらい配信されてきますが、bogofilterの学習には単語数で2000語以上、メール数で500以上は食わせたほうがよいようなので、最近3ヶ月程度を食わせれば十分です。

ftpアプリについて。

外部からおうちサーバのファイルを参照しようと思ったので、ftpクライアントアプリを検索してみました。

窓の杜で、FFFTPとかWinSCPとかが表示されてきて、思わず懐かしさがこみ上げてきたり。

FFFTP、まだ開発継続してたんだ、ありがたや、と思ったんですが…さすがにscpには対応していないようで、代わりにftpsという設定項目がありました。SSLでftpするということのようで、利用するためにはおうちサーバのProFTPDの設定を追加する必要があります。ポートも違うし。

一方のWinSCPはSSH上でのファイル転送を行うものです。SCPによるファイル転送は、TTSSHでもファイルメニューから "SSH SCP" という形で呼び出せます。

という周辺知識は置いといて、今回FFFTPをインストールしてみたんですが、やっぱり生でパスワードが流れるのは好ましくないですし、他に手段はないかなぁと思ったところ、「あれ、もしかしてRLoginでできたりするんじゃ…」と。

早速RLoginでおうちサーバにSSH接続して、ファイルメニューを見てみると、"SFTPファイル転送" の項目がありました。RLoginすごい。すでにSSHで繋いでいるので、新たにコネクションを張る必要もないですし、2ペインのFFFTPライクな画面でファイル選択もカンタン。必要なファイルをドラッグ&ドロップで取得できます。

SWDなら3線でいいとはいうものの。

 安価で優秀なデバッグプローブはないかしら、と探したら、 Raspberry Pi Debug Probe というのがあったんですが、これは3線がにゅるんと出てるだけです。 もちろんSWDなら3線を繋げばいいのではありますが、汎用的に考えるなら5x2のリボンケーブルコネクタが欲し...