Life日本xrdpユーザ会発起人。FreeBSDを通じてOSSに囁かな貢献を。(以下SoftEther)は言わずと知れた優れたオープンソースの複数プロトコル、複数プラットフォームVPNソフトウェアです。優れたソフトウェアであるにも関わらず、Linuxディストリビューションなどの公式パッケージとしての提供状況は芳しくありません。portsを例に「SoftEtherをパッケージングするための技術」について解説します(技術というほどのものではありませんが...)。SoftEtherがディストリビューションの公式パッケージで提供されにくい理由SoftEtherがLinuxディストリビューションに敬遠される理由として、SoftEtherの設計に起因する、ディストリビューションのお作法と相反する部分が原因だと考えます。需要がないだけではないかという説は、一旦置いておいておきます(SoftEtherは大変優れたソフトウェアであるため)。そのお作法に反する部分というのは以下に挙げる、ログファイル、PIDファイル、設定ファイル(以下ログなど)の出力先です。その他の部分に関しては、SoftEther自身の依存関係が最小であるため特にパッケージングの障害となる要素は見られませんでした。/var/logやサブディレクトリの/var/log/softetherといった場所をイメージすることが多いのではないでしょうか。あるように、実行ファイルのある場所にサブディレクトリを作成しログを書き出します。つのサブディレクトリを作成し、そこに各々「サーバーログ」「セキュリティログ」、および「パケットログ」をそれぞれ書き出します。名のサブディレクトリ」が作成され、そこに書き出されます。コンパイル済みのバイナリのtarballをダウンロードして展開する場合にはとても都合がよく、妥当な設計です。実行中に書き出される一切のファイルは展開先のディレクトリの下に作成されるため、不要になった場合はディレクトリごと削除してしまえば一切後を濁さず綺麗サッパリとアンインストールできるからです。ところが、ディストリビューションのパッケージを作る立場からするとこれはとても困った設計です。実行可能ファイルが設置されているディレクトリにサブディレクトリを作成するということは、/usr/binや/usr/libexecといったディレクトリに勝手にディレクトリを掘ってログファイルを書くことになるからです。パッケージシステム以外のソフトウェアがこれらのパスに書き込むのは行儀が悪いですし、なによりこれらのパスが書き込み可能である保証がありません。これではオリジナルのSoftEtherをそのままパッケージにするのが難しく、公式パッケージとして提供されにくいのも頷けます。PIDファイルの出力先PIDファイルの出力先も同様で、実行可能ファイルと同じディレクトリに出力されます。これもログファイルと同様に行儀がよくないですね。/var/runや/runといったディレクトリ、またはそのサブディレクトリに書くのが一般的ではないでしょうか。前述の通り、実行ファイルと同じディレクトリというのは書き込み可能である保証がないため、避けるべきでしょう。設定ファイルも、実行可能ファイルと同じディレクトリに出力されます。一般に設定ファイルというと/etc以下に置かれることをイメージすると思います。SoftEtherの場合は、設定ファイルをテキストエディタで書き換えて設定を行うという使い方がメインではなく、vpncmdという管理コマンドやサーバ管理マネージャを使用して設定を行い、設定の内部データのダンプがテキストファイルに書き出されるというイメージです。設定ファイルを書き換えての設定変更も可能ですが、ここでは省略します。SoftEtherは自動的に一定時間ごとに設定内容の履歴を取り、バックアップしています。コンフィグレーションファイルの項を参照ください。このように、設定ファイルはSoftEtherによって単に読み取られるのではなく、プログラムの実行により更新される状態を保持するファイルという性質があるため、置き場所としては/var/libあたりがFHS的には適切でしょう。以上のように、SoftEtherが実行中に書き込むディレクトリは大きく分けて3つに区別されます。設定(状態)ファイルの出力先オリジナルのSoftEtherではこれらの3つが区別されず、全て実行ファイルのディレクトリとされています。内部ではGetExeDir()やGetExeDirW()という関数で取得しています。portsでは、オリジナルのSoftEtherにパッチを当ててこれらのディレクトリを取得する関数を追加、GetExeDir()を呼んでいる箇所をみてログなのか、PIDなのか、設定ファイルなのかコンテキストによって書き換えました。詳しくはportのMakefileや実際のパッチを参照ください。変わっているのは、FHSの/var/libに相当するパスがFreeBSDでは/var/dbだからです。取り除く改変も合わせて加えています。portsにおいてはオリジナルのSoftEtherにある「ログなどを変な場所に吐く問題」を解決しし、FreeBSDのお作法に沿った場所にログやPIDファイルなどを出力するようにしています。installで簡単にインストールでき、バージョンの管理もOSの仕組みにそって行えるため、扱いやすいのではないでしょうか。portsにはSoftEtherは3つのバージョンが収録されています。x86-64アーキテクチャしかサポートしないため、主にRaspberryPiなどのARMアーキテクチャで使用するために5系を用意しています。開発版upstreamに投げないのか?それほど難しいパッチではありませんが、数行の簡単なパッチではないためupstreamに投げた方が後の運用が楽ではないかという疑問が出てくると思いますが、これをupstreamに投げるかどうかはまだ悩んでいます。本記事中でも言及したように、コンパイル済みの公式バイナリのtarballをダウンロードして展開して実行するというユースケースにおいては、展開したディレクトリ以外を散らかさない、全てを展開したディレクトリ以下に書き込むという設計には一定の妥当性を感じているからです。ディストリビューションのパッケージを作成する立場としては、ログなどをOSの標準的なパスに書き出してくれないと扱いづらいのは事実ですが、一方で現状の設計にも一定の妥当性を感じているため一概にどちらがいいと言い切れるものではなくこの程度の方向性の違いはローカルパッチで対処してもいいかなとも思っています。1回PRを投げみてupstreamの判断を仰げ?その通りです。ログをOSのお作法に沿った場所に書くように改変している他のLinuxディストリビューション向けにSoftEtherをパッケージングする際の助けとなれば幸いです。なる方法はじめにこの記事はえのもとさんのNetBSD/pkgsrc開発者になる方法に触発されて書きました。私がOSC東京で喋った内容に触発されてNetBSDの場合はどうなのか書いてみようというのがきっかけの記事なので、インスパイアのインスパイア、逆輸入なのですが。モチベーションは同じく、FreeBSD開発者になるにはどうしたらいいかという文書が日本語では少ない(少なくなってきている)というところにあり、今後開発者になろうとする人の助けになることを望みます。FreeBSDを使うNetBSDの場合と同様、FreeBSDを使わないことには始まりません。FreeBSD開発者になろうとしてこの文書にたどり着いている時点で、既にFreeBSDのユーザーであることは間違いないでしょうから細かい話は省略します。portsになにか貢献してみるここでは「中の人」ではない人による、portsの作業を「貢献(contribute)」と呼ぶことにします。セットされているものを見つけてメンテナを担当したり、メンテナがいてもそのソフトウェアが新しいバージョンに更新されていないものを見つけて、アップデートをしたりするところから始めるのが良いでしょう。treeに存在しないソフトウェアを追加するというのもありです。WikiのWantedPortsに載っているので、それらをFreeBSDで使えるようにすると喜ばれるでしょう。Handbookで解説されている方法やプラクティスを参考にしながら作業しましょう。日本語版は更新が遅れているため英語版を参照することをおすすめします。treeへのパッチを作って報告、メンテナが承認、コミット権を持っている開発者がコミットするというのが大まかな流れです。貢献者としての実績を積むある程度慣れてきたら、外部の貢献者として作業を続け、実績を積み重ねていきます。これが、後に開発者として推薦してもらう際にスキルや実績の証明となります。実績は必ず必要で、いきなり開発者になることはできません。ここから開発者になるという先の段階へ進まず、外部貢献者のまま多大な貢献を続けている方も多いです。Frameworkに詳しい人も中にはいます。Contributorsに掲載されていますが「この人よく見るし載せてもいいんじゃない?」と雰囲気で提案することも多いので、ここに掲載されている人で全てではありません。OSS系のイベントやカンファレンスでの発表はあるに越したことはないですが、必須ではありません。FreeBSDのBugzillaやメーリングリストで「この人よく見るな」というレベルの活動があれば十分です。地理的にFreeBSD勉強会やFreeBSDワークショップに参加しやすい環境にあるならば、参加しておいたほうが良いでしょう。地方在住で、地理的な制約もあり上の両イベントにはほとんど参加したことはありません。貢献者としての活動は両イベントが始まる前からで、グローバルなコミュニティにオンラインで参加していました。オープンソースカンファレンスへの出展を通じてNetBSDのebijunさんと交流はありますが、日本のFreeBSD開発者とのオフラインでの交流は皆無でした。AsiaBSDConにも参加したいとは思っているものの、現時点では参加したことがありません。推薦者・メンターを探すNetBSDでは「スポンサーを探す」という手順です。FreeBSDでも同様に、この手順が最難関となるでしょう。オフラインのカンファレンスに出席したり、発表したりするのは必須ではありませんが、これまでの貢献や成果を示す場としては最適です。Procedureに書かれています。必要な情報を推薦者に送り、推薦してもらいます。メンターと推薦者は同じ場合もあれば、異なる場合もあります。チームによって行われます。通常は7日以内に投票が完了します。Jaegerに志願し、推薦してもらいメンターになっていただきました。committerになりたいんだけどどうしたらいい?メンターになってくれない?」オンラインで声をかけて、2人とも忙しいにも関わらず無理を言って引き受けてもらいました。どちらにもオフラインでお会いしたことはなく、全てオンライン上でのやり取りです。アカウント作成手続き新しいコミッターになることが承認されたら、アカウントの作成です。公開鍵あとは、メンターが新しいコミッターのコミットビットを有効化したりという手続きを行います。FreeBSD開発者として活動する上ではPGPの利用や公開鍵の登録が必須となるので、早めに使い方に習熟しておきましょう。見習い開発者となる以上で、FreeBSD開発者の一員となります。間はメンターからの指導を受けながら、メンターの承認があって初めてコミットが行えるという見習い状態が続きます。ひとりだち明確な決まりはありませんが、2人のメンターから十分なスキルを身に着けたと判断された時点でメンターが外れ、晴れて一人前となり、1人でコミットできるようになります。スキルが不足していれば長くなり、十分であると判断されれば短期間で見習い期間が終了することがあります。一人前とはいえ、まだまだ開発者の仲間入りをしたばかりの新米なので、わからないことがあれば他の開発者に尋ね、レビューをしてもらったり、必要に応じて判断や指導を仰ぎましょう。Frameworkの改良に積極的に関わる人まで、活躍の種類は様々です。Teamの選挙権が与えられます。NCロードスターのブロアが止まらなくなった→レジスター交換で直ったロードスターのブロアが止まらなくなりました。エアコンのコントロールスイッチの状態に関わらず、ブロアが全開で動いていて止まらない、Iイグニッションをオフ(ACC)にすると止まるという状態です。コンプレッサーのクラッチはスイッチをオフにすると切れています。詳しい症状は以下の動画で。までも正常そう、とりあえずブロアファンリレー交換してみるのはどうか。12,636ヒーターコントロールは部品自体が高額なので、まず安い方のレジスターから交換してみて直ったらラッキー、直らなければ中古部品を探してDIYするかという気でいました。無償で診断してもらった手前、安い方の部品は工賃を払ってディーラーでお願いすることにしました。結果は、レジスターのみの交換で無事に直りました。NC2が2008年12月登場なのでNC2ですら10年落ち、NC1.5はすべての個体が10年落ち、うちの車は走行距離も10万km近いので、これまでとは違う故障やメンテナンスが必要になりそうです。@25635kmリトルカブのプラグを交換しました。後、最初の整備をしたときなので、もう4年も前のこと。走行距離は正確には控えてないものの19800km付近でした。差し引き5800kmくらい。プラグメーカー指定の交換目安は3000〜5000kmとのことなので、既に交換時期を過ぎていました。交換前後のプラグは以下のような感じ。プラグは何の変哲もなくNGK。交換前のものはCR6HSA、交換後はCR5HSA。短距離走行が多いので熱価をひとつ下げてみました。様子を見て元に戻すかもしれない。交換時期を過ぎていたので、スパークが飛びにくくなっていていたのかもしれません。スパークの調子が良くなりちゃんと燃焼するようになったんだとすると、発熱が大きくなったのも、排気音が大きくなったのも、トルクアップも納得の結果。プラグ交換前の最後の燃費は59km/Lでした。悪い値ではないけど、プラグ交換で燃焼が改善されてどうなるか。界隈では有名なろくすけさんのやつを取り付けました。NCロードスターの外気導入口にフィルターをつけるための枠NCロードスターの外気導入口にフィルターをつけるための枠の取り付けDMM.makeで出力して購入することもできますが、ろくすけさんが3Dプリンターで出力した物をメルカリで販売しているので今回はこれを購入。到着したのはこんな感じのブツ。レンジフードフィルタをつけたみた図。左は実際に装着した東レの換気口用のフィルタ。取り付けは最初に提示したろくすけさんの解説が詳しいので、そっちを見てください。カウルトップを外すと、今までいちども外したことがなく、雨水が流れ込む場所だけあって乾いた泥だらけ。フロントガラスの付け根部分も泥だらけなので、このへんは濡れ雑巾で噴いたり洗ったり。この車は2オーナー目ですが、最初のオーナーが鹿児島で6万キロ乗っていたので火山灰と思しき鋭利な砂塵も積もっていました。取り付けるとこんな感じ。間口が狭いのでちょっと取り付けづらいです。取り付けのときにキャップの爪を折ってしまったり、プラのリベットが劣化して外しただけでポロポロ崩れてしまっていたので、ディーラーで部品を注文して後日交換しました。掃除した後の写真を取り忘れていたので、リベット交換するときに撮り直し。隅々まできれいにというわけにはいきませんが、最初に比べるとだいぶきれいになったと思います。@25440km行きつけのバイク屋が、閉店してしまったので自分で交換します。アンダーカバーを外してドレンボルトにアクセスするのが面倒だったのと、ドレンワッシャの予備も持ち合わせがなかったので今回は上抜き。25440kmにて交換。ついでに洗車もしました。過去を振り返ってみると、リトルカブに乗り始めてから丸4年経っていたらしいです。2回盗難に遭って2回発見された車体を譲り受けたときの走行距離は19789.2kmだったので、4年間で5650kmほど走った計算になります。Piで使えます)SoftEtherの解説は不要だと思いますが、筑波大学における学術目的の研究プロジェクトとして開発された強力なVPNソフトウェアで、高い移植性を念頭に開発されており、FreeBSDでの動作も公式にサポートしています。2.0で提供されています。ARMやMIPSなどのアーキテクチャでは使用することができません。2.0共々、組み込み機器で使いやすいライセンスにも関わらずSoftEtherがIntel以外のアーキテクチャで使用できないのは残念です。実はGitHubで開発されているSoftEtherの開発版であるバージョン5系では、この「FreeBSDではi386とamd64のみサポート」いう制限がなくなっています。詳しく調べたわけではありませんが、特定のOSではサポートされるアーキテクチャが限定されるということはなくなり、OSによらず以下のアーキテクチャをサポートするようです。5をコミットしました。PiなどのARMデバイスでもSoftEtherを使ったVPNサーバ/VPNルータを構築できるようになりますね。5は開発版なので、安定動作することは保証されていない点には注意が必要です。CPU上で動作させる必要があります。書くまでもないかもしれませんが、一応インストール方法を書いておきます。softether5バイナリパッケージはアーキテクチャによっては提供されていない場合があります。雑記RSSフィードRSSフィードが必要な方は下からどうぞ。収集した情報の扱いはプライバシーポリシーに従います。2.5.7-p206。