追記

meta's blog - The Power To Serve

筆者について - No Unix, No Life

日本xrdpユーザ会発起人。

とある元大学院生の UNIX 系日記。FreeBSDを通じてOSSに囁かな貢献を。 FreeBSD ports committer やってます。

HTTPS化したいとは思っているんです…


2019-09-24 SoftEtherをパッケージングするための技術 [長年日記]

SoftEtherをパッケージングするための技術

SoftEther VPN (以下SoftEther)は言わずと知れた優れたオープンソースの複数プロトコル、複数プラットフォームVPNソフトウェアです。とても優れたソフトウェアであるにも関わらず、Linuxディストリビューションなどの公式パッケージとしての提供状況は芳しくありません。

ここでは、FreeBSD portsを例に「SoftEtherをパッケージングするための技術」について解説します(技術というほどのものではありませんが…)。

SoftEtherがディストリビューションの公式パッケージで提供されにくい理由

SoftEtherがLinuxディストリビューションに敬遠される理由として、SoftEtherの設計に起因する、ディストリビューションのお作法と相反する部分が原因だと考えます。単に需要がないだけではないかという説は、一旦置いておいておきます(SoftEtherは大変優れたソフトウェアであるため)。

そのお作法に反する部分というのは以下に挙げる、ログファイル、PIDファイル、設定ファイル(以下ログなど)の出力先です。その他の部分に関しては、SoftEther自身の依存関係が最小であるため特にパッケージングの障害となる要素は見られませんでした。

ログファイルの出力先

一般的にLinuxディストリビューションにおいて、ログファイルの出力先といえば /var/logやサブディレクトリの/var/log/softetherといった場所をイメージすることが多いのではないでしょうか。

ところが、3.10.1 ログの保存形式と保存周期 にあるように、実行ファイルのある場所にサブディレクトリを作成しログを書き出します。

すべてのログファイルは、「vpnserver」プロセス (VPN Bridge では、「vpnbridge」プロセス) の実行可能ファイルが設置されているディレクトリに、「server_log」、「security_log」および「packet_log」の 3 つのサブディレクトリを作成し、そこに各々「サーバーログ」「セキュリティログ」、および「パケットログ」をそれぞれ書き出します。なお、仮想 HUB ごとに書き出されるセキュリティログおよびパケットログについては、さらに「仮想 HUB 名のサブディレクトリ」が作成され、そこに書き出されます。

これは、www.softether-download.com からコンパイル済みのバイナリのtarballをダウンロードして展開する場合にはとても都合がよく、妥当な設計です。なぜなら、実行中に書き出される一切のファイルは展開先のディレクトリの下に作成されるため、不要になった場合はディレクトリごと削除してしまえば一切後を濁さず綺麗サッパリとアンインストールできるからです。

ところが、ディストリビューションのパッケージを作る立場からするとこれはとても困った設計です。実行可能ファイルが設置されているディレクトリにサブディレクトリを作成するということは、/usr/bin/usr/libexecといったディレクトリに勝手にディレクトリを掘ってログファイルを書くことになるからです。パッケージシステム以外のソフトウェアがこれらのパスに書き込むのは行儀が悪いですし、なによりこれらのパスが書き込み可能である保証がありません。

これではオリジナルのSoftEtherをそのままパッケージにするのが難しく、公式パッケージとして提供されにくいのも頷けます。

PIDファイルの出力先

PIDファイルの出力先も同様で、実行可能ファイルと同じディレクトリに出力されます。これもログファイルと同様に行儀がよくないですね。

/var/run/runといったディレクトリ、またはそのサブディレクトリに書くのが一般的ではないでしょうか。前述の通り、実行ファイルと同じディレクトリというのは書き込み可能である保証がないため、避けるべきでしょう。

設定ファイルの出力先

同じく設定ファイルも、実行可能ファイルと同じディレクトリに出力されます。一般に設定ファイルというと/etc以下に置かれることをイメージすると思います。

SoftEtherの場合は、設定ファイルをテキストエディタで書き換えて設定を行うという使い方がメインではなく、vpncmdという管理コマンドやサーバ管理マネージャを使用して設定を行い、設定の内部データのダンプがテキストファイルに書き出されるというイメージです。もちろん設定ファイルを書き換えての設定変更も可能ですが、ここでは省略します。

また、SoftEtherは自動的に一定時間ごとに設定内容の履歴を取り、バックアップしています。詳しくはSoftEtherのマニュアルの 3.3.7 コンフィグレーションファイルの項を参照ください。

このように、設定ファイルはSoftEtherによって単に読み取られるのではなく、プログラムの実行により更新される状態を保持するファイルという性質があるため、置き場所としては/var/libあたりがFHS的には適切でしょう。

FreeBSD portsの場合

以上のように、SoftEtherが実行中に書き込むディレクトリは大きく分けて3つに区別されます。

  • ログファイルの出力先
  • PIDファイルの出力先
  • 設定(状態)ファイルの出力先

オリジナルのSoftEtherではこれらの3つが区別されず、全て実行ファイルのディレクトリとされています。内部ではGetExeDir()GetExeDirW()という関数で取得しています。

FreeBSD portsでは、オリジナルのSoftEtherにパッチを当ててこれらのディレクトリを取得する関数を追加、GetExeDir()を呼んでいる箇所をみてログなのか、PIDなのか、設定ファイルなのかコンテキストによって書き換えました。詳しくはportのMakefileや実際のパッチを参照ください。

  • GetLogDir()/var/log/softether
  • GetPidDir()/var/run/softether
  • GetDbDir()/var/db/softether

先程 /var/lib が適切といった部分が、/var/db に変わっているのは、FHSの/var/libに相当するパスがFreeBSDでは/var/dbだからです。hier(7)参照

また、冒頭で示した3.10.1 ログの保存形式と保存周期の通りログの保存先には server_log, security_log, packet_log というサブディレクトリが作成されるため、最終的なパスが以下のようにlogがダブり、些か冗長であるため _log を取り除く改変も合わせて加えています。

  • /var/log/softether/server_log → /var/log/softether/server
  • /var/log/softether/security_log → /var/log/softether/security
  • /var/log/softether/packet_log → /var/log/softether/packet

このようにして、FreeBSD portsにおいてはオリジナルのSoftEtherにある「ログなどを変な場所に吐く問題」を解決しし、FreeBSDのお作法に沿った場所にログやPIDファイルなどを出力するようにしています。通常のportsのようにmake installpkg installで簡単にインストールでき、バージョンの管理もOSの仕組みにそって行えるため、扱いやすいのではないでしょうか。

余談ですが、FreeBSD portsにはSoftEtherは3つのバージョンが収録されています。3つのバージョンを並行してサポート・メンテナンスする必要があるのかというと正直微妙なところですが、SoftEther 4系はFreeBSDにおいてはx86, x86-64アーキテクチャしかサポートしないため、主にRaspberryPiなどのARMアーキテクチャで使用するために5系を用意しています。

  • security/softether → 4.29 安定版の正式リリース(RTM)
  • security/softether-devel → 4.30 安定版のbeta版
  • security/softether5 →5.01 開発版

upstreamに投げないのか?

それほど難しいパッチではありませんが、数行の簡単なパッチではないためupstreamに投げた方が後の運用が楽ではないかという疑問が出てくると思いますが、これをupstreamに投げるかどうかはまだ悩んでいます。

本記事中でも言及したように、コンパイル済みの公式バイナリのtarballをダウンロードして展開して実行するというユースケースにおいては、展開したディレクトリ以外を散らかさない全てを展開したディレクトリ以下に書き込むという設計には一定の妥当性を感じているからです。

ディストリビューションのパッケージを作成する立場としては、ログなどをOSの標準的なパスに書き出してくれないと扱いづらいのは事実ですが、一方で現状の設計にも一定の妥当性を感じているため一概にどちらがいいと言い切れるものではなくこの程度の方向性の違いはローカルパッチで対処してもいいかなとも思っています。

とにかく1回PRを投げみてupstreamの判断を仰げ?その通りです。

まとめ

  • SoftEtherは優れたソフトウェアにも関わらず、ディストリビューションの公式パッケージとして提供されにくい現状がある
  • その理由はSoftEtherの独特な設計(ログなどの書き出し先)にあるのではないか
  • FreeBSD ports ではログをOSのお作法に沿った場所に書くように改変している

他のLinuxディストリビューション向けにSoftEtherをパッケージングする際の助けとなれば幸いです。


2019-08-06 FreeBSD developer (ports) になる方法 [長年日記]

FreeBSD developer (ports) になる方法

はじめに

この記事はえのもとさんNetBSD/pkgsrc開発者になる方法に触発されて書きました。私がOSC東京で喋った内容に触発されてNetBSDの場合はどうなのか書いてみようというのがきっかけの記事なので、インスパイアのインスパイア、逆輸入なのですが。

モチベーションは同じく、FreeBSD開発者になるにはどうしたらいいかという文書が日本語では少ない(少なくなってきている)というところにあり、今後開発者になろうとする人の助けになることを望みます。

FreeBSDを使う

NetBSDの場合と同様、FreeBSDを使わないことには始まりません。FreeBSD開発者になろうとしてこの文書にたどり着いている時点で、既にFreeBSDのユーザーであることは間違いないでしょうから細かい話は省略します。

FreeBSD portsになにか貢献してみる

ここでは「中の人」ではない人による、portsの作業を「貢献(contribute)」と呼ぶことにします。

メンテナのいないports、即ちメンテナのメールアドレスが ports@FreeBSD.org にセットされているものを見つけてメンテナを担当したり、メンテナがいてもそのソフトウェアが新しいバージョンに更新されていないものを見つけて、アップデートをしたりするところから始めるのが良いでしょう。また、ports treeに存在しないソフトウェアを追加するというのもありです。望まれているportsのリストはFreeBSD WikiのWantedPortsに載っているので、それらをFreeBSDで使えるようにすると喜ばれるでしょう。

作業の際はPorter's Handbookで解説されている方法やプラクティスを参考にしながら作業しましょう。日本語版は更新が遅れているため英語版を参照することをおすすめします。

具体的な方法はここでは細かく解説しませんが、Bugzillaにアカウントを取得し、ports treeへのパッチを作って報告、メンテナが承認、コミット権を持っている開発者がコミットするというのが大まかな流れです。

貢献者としての実績を積む

ある程度慣れてきたら、外部の貢献者として作業を続け、実績を積み重ねていきます。これが、後に開発者として推薦してもらう際にスキルや実績の証明となります。実績は必ず必要で、いきなり開発者になることはできません。

ここから開発者になるという先の段階へ進まず、外部貢献者のまま多大な貢献を続けている方も多いです。開発者よりもPorts Frameworkに詳しい人も中にはいます。貢献者のリストはAdditional FreeBSD Contributorsに掲載されていますが「この人よく見るし載せてもいいんじゃない?」と雰囲気で提案することも多いので、ここに掲載されている人で全てではありません。

OSS系のイベントやカンファレンスでの発表はあるに越したことはないですが、必須ではありません。FreeBSDのBugzillaやメーリングリストで「この人よく見るな」というレベルの活動があれば十分です。地理的にFreeBSD勉強会FreeBSDワークショップに参加しやすい環境にあるならば、参加しておいたほうが良いでしょう。

筆者の場合

地方在住で、地理的な制約もあり上の両イベントにはほとんど参加したことはありません。貢献者としての活動は両イベントが始まる前からで、グローバルなコミュニティにオンラインで参加していました。オープンソースカンファレンスへの出展を通じてNetBSDのebijunさんと交流はありますが、日本のFreeBSD開発者とのオフラインでの交流は皆無でした。また、AsiaBSDConにも参加したいとは思っているものの、現時点では参加したことがありません。

推薦者・メンターを探す

NetBSDでは「スポンサーを探す」という手順です。FreeBSDでも同様に、この手順が最難関となるでしょう。オフラインのカンファレンスに出席したり、発表したりするのは必須ではありませんが、これまでの貢献や成果を示す場としては最適です。

新しい開発者を推薦する流れがNew Account Creation Procedureに書かれています。必要な情報を推薦者に送り、推薦してもらいます。メンターと推薦者は同じ場合もあれば、異なる場合もあります。

  • 候補者のこれまでのFreeBSDへの貢献実績(必須)
  • 候補者のメンターになることを志願した人
  • 候補者のメールアドレス

推薦されたら、候補者を新しい開発者として承認するかどうかの投票が portmgr@ チームによって行われます。通常は7日以内に投票が完了します。

筆者の場合

佐藤 広生先生とKurt Jaegerに志願し、推薦してもらいメンターになっていただきました。「ports committerになりたいんだけどどうしたらいい?メンターになってくれない?」オンラインで声をかけて、2人とも忙しいにも関わらず無理を言って引き受けてもらいました。どちらにもオフラインでお会いしたことはなく、全てオンライン上でのやり取りです。

アカウント作成手続き

新しいコミッターになることが承認されたら、アカウントの作成です。以下の情報を安全な方法でメンターに送り、メンターが安全な方法で(通常はPGP署名で) accounts@ チームに送信します。

  • 希望するログイン名(小文字のa-z, 0-9)
  • 氏名 (UTF-8; GECOSフィールドに使用されます)
  • 追加のGENOS情報
  • shell (sh, csh/tcsh, bash, zsh)
  • ssh V2 公開鍵

あとは、メンターが新しいコミッターのコミットビットを有効化したりという手続きを行います。FreeBSD開発者として活動する上ではPGPの利用や公開鍵の登録が必須となるので、早めに使い方に習熟しておきましょう。

見習い開発者となる

以上で、FreeBSD開発者の一員となります。ただし、しばらくの間はメンターからの指導を受けながら、メンターの承認があって初めてコミットが行えるという見習い状態が続きます。

ひとりだち

明確な決まりはありませんが、2人のメンターから十分なスキルを身に着けたと判断された時点でメンターが外れ、晴れて一人前となり、1人でコミットできるようになります。スキルが不足していれば長くなり、十分であると判断されれば短期間で見習い期間が終了することがあります。

一人前とはいえ、まだまだ開発者の仲間入りをしたばかりの新米なので、わからないことがあれば他の開発者に尋ね、レビューをしてもらったり、必要に応じて判断や指導を仰ぎましょう。

Ports committerとなっても、担当するportsのメンテナンスを淡々とこなすだけの人から、FreeBSD Ports Frameworkの改良に積極的に関わる人まで、活躍の種類は様々です。

おまけ

FreeBSD開発者となり、commit bit を持つと2年に1度のFreeBSD Core Teamの選挙権が与えられます。


2019-06-22 NCロードスターのブロアが止まらなくなった→レジスター交換で直った [長年日記]

NCロードスターのブロアが止まらなくなった→レジスター交換で直った

ロードスターのブロアが止まらなくなりました。エアコンのコントロールスイッチの状態に関わらず、ブロアが全開で動いていて止まらない、Iイグニッションをオフ(ACC)にすると止まるという状態です。コンプレッサーのクラッチはスイッチをオフにすると切れています。

詳しい症状は以下の動画で。

いろいろアドバイスをもらいつつ、結局ディーラーに持っていって診断してもらうと、ヒーターコントロールもしくはブロアレジスターのどちらかの故障とのこと。

作業・部品 部品代 技術料
ヒーターコントロールASSY取替 5,616
ヒーターコントロール N12361190B 50,047
ブロアレジスタ取替 7020
ブロアーユニット レジスター NE5161B15 3,466
部品代・技術料 計 53,513 12,636

ヒーターコントロールは部品自体が高額なので、まず安い方のレジスターから交換してみて直ったらラッキー、直らなければ中古部品を探してDIYするかという気でいました。無償で診断してもらった手前、安い方の部品は工賃を払ってディーラーでお願いすることにしました。

結果は、レジスターのみの交換で無事に直りました。NC2が2008年12月登場なのでNC2ですら10年落ち、NC1.5はすべての個体が10年落ち、うちの車は走行距離も10万km近いので、これまでとは違う故障やメンテナンスが必要になりそうです。

修理完了時の走行距離は 96273km でした。


2019-06-01 リトルカブ プラグ交換 @25635km [長年日記]

リトルカブ プラグ交換 @25635km

リトルカブのプラグを交換しました。交換したのはボロボロのリトルカブを譲ってもらって引き取った 後、最初の整備をしたときなので、もう4年も前のこと。走行距離は正確には控えてないものの19800km付近でした。差し引き5800kmくらい。

プラグメーカー指定の交換目安は3000〜5000kmとのことなので、既に交換時期を過ぎていました。交換前後のプラグは以下のような感じ。

交換前後のプラグ比較

プラグは何の変哲もなくNGK。交換前のものはCR6HSA、交換後はCR5HSA。短距離走行が多いので熱価をひとつ下げてみました。様子を見て元に戻すかもしれない。

交換後は

  • エンジンが暖まるのが早くなった(熱くなった)
  • 排気音が大きくなった
  • 低回転のトルクが上がったような気がする といった印象。

交換時期を過ぎていたので、スパークが飛びにくくなっていていたのかもしれません。スパークの調子が良くなりちゃんと燃焼するようになったんだとすると、発熱が大きくなったのも、排気音が大きくなったのも、トルクアップも納得の結果。

プラグ交換前の最後の燃費は59km/Lでした。決して悪い値ではないけど、プラグ交換で燃焼が改善されてどうなるか。


2019-05-23 NCロードスター エアコンフィルタ取付 [長年日記]

NCロードスター エアコンフィルタ取付

界隈では有名なろくすけさんのやつを取り付けました。

DMM.makeで出力して購入することもできますが、ろくすけさんが3Dプリンターで出力した物をメルカリで販売しているので今回はこれを購入。

到着したのはこんな感じのブツ。

とりあえずレンジフードフィルタをつけたみた図。左は実際に装着した東レの換気口用のフィルタ。

取り付けは最初に提示したろくすけさんの解説が詳しいので、そっちを見てください。

カウルトップを外すと、今までいちども外したことがなく、雨水が流れ込む場所だけあって乾いた泥だらけ。

フロントガラスの付け根部分も泥だらけなので、このへんは濡れ雑巾で噴いたり洗ったり。

この車は2オーナー目ですが、最初のオーナーが鹿児島で6万キロ乗っていたので火山灰と思しき鋭利な砂塵も積もっていました。

取り付けるとこんな感じ。間口が狭いのでちょっと取り付けづらいです。

取り付けのときにキャップの爪を折ってしまったり、プラのリベットが劣化して外しただけでポロポロ崩れてしまっていたので、ディーラーで部品を注文して後日交換しました。

掃除した後の写真を取り忘れていたので、リベット交換するときに撮り直し。隅々まできれいにというわけにはいきませんが、最初に比べるとだいぶきれいになったと思います。

走行距離 95500km くらいで取り付け。


2019-04-13 リトルカブオイル交換&洗車 [長年日記]

リトルカブオイル交換&洗車 @25440km

行きつけのバイク屋が、閉店してしまったので自分で交換します。アンダーカバーを外してドレンボルトにアクセスするのが面倒だったのと、ドレンワッシャの予備も持ち合わせがなかったので今回は上抜き。

25440kmにて交換。ついでに洗車もしました。オイルは何の変哲もないホンダ ウルトラG1です。

過去を振り返ってみると、リトルカブに乗り始めてから丸4年経っていたらしいです。2回盗難に遭って2回発見された車体を譲り受けたときの走行距離は19789.2kmだったので、4年間で5650kmほど走った計算になります。


2019-03-07 SoftEther 5のFreeBSD portを作成した (Raspberry Piで使えます) [長年日記]

SoftEther 5のFreeBSD portを作成した (Raspberry Piで使えます)

SoftEtherの解説は不要だと思いますが、筑波大学における学術目的の研究プロジェクトとして開発された強力なVPNソフトウェアで、高い移植性を念頭に開発されており、FreeBSDでの動作も公式にサポートしています

SoftEtherの最新リリースは、 4.29 Build 9680 RTM というバージョンです。余談ですが、このバージョンからupstreamでのライセンス変更が適用されていて、従来のGPLv2からApache License 2.0で提供されています。

そんなSoftEther 4ですが、FreeBSD上で動作させる場合はIntel i386/amd64アーキテクチャのみをサポートします(公式サイトのSoftEther VPN Server の仕様より)。ARMやMIPSなどのアーキテクチャでは使用することができません。FreeBSDのBSDライセンス、SoftEtherのApache License 2.0共々、組み込み機器で使いやすいライセンスにも関わらずSoftEtherがIntel以外のアーキテクチャで使用できないのは残念です。平たくいうと、Raspberry Piでは使えません。

実はGitHubで開発されているSoftEtherの開発版であるバージョン5系では、この「FreeBSDではi386とamd64のみサポート」いう制限がなくなっています。詳しく調べたわけではありませんが、特定のOSではサポートされるアーキテクチャが限定されるということはなくなり、OSによらず以下のアーキテクチャをサポートするようです。

  • Intel i386/amd64
  • ARM (arm/aarch64)
  • MIPS
  • PowerPC

というわけで、FreeBSD portsにSoftEther 5をコミットしました。これでRaspberry PiなどのARMデバイスでもSoftEtherを使ったVPNサーバ/VPNルータを構築できるようになりますね。

SoftEther 5は開発版なので、安定動作することは保証されていない点には注意が必要です。安定版が必要な場合には当面はIntel CPU上で動作させる必要があります。

インストール方法

書くまでもないかもしれませんが、一応インストール方法を書いておきます。

ports
portsnap fetch update
cd /usr/ports/security/softether5
make install
pkg
pkg update
pkg install softether5

バイナリパッケージはアーキテクチャによっては提供されていない場合があります。