CassetteOSを「パーソナルクラウドOS」から「オフィスクラウドOS」にするための作業をしています。

CassetteOSのロードマップ

このうち、マイクロカーネルを実装して、同時にマルチユーザ化の基本部分ができました。

CassetteOSを「パーソナルクラウドOS」から「オフィスクラウドOS」にするための作業

とか言ってるのですが、実際にはほぼスクラッチからの実装です。 実装言語もGoからJavascript(Node.js)に変わっています。 UI的な外見はほとんど変わりませんけどね。

マイクロカーネル化

これは前のエントリでも書いていますが、OS kernelで言うところの「マイクロカーネル」とはちょっと意味が異なります。 Machを使いますとか、そーゆー話とは関係ありません。 システム運用に必要な機能やシステムサービスを細かく分割して、それぞれを小さい処理単位の「サーバ」で実現するというものです。

これが何が嬉しいかと言えば、

  • 個々の機能の実装の自由度が上がる(記述言語とか)
  • 機能の取捨選択が自由になる
  • 機能の実装が単純化される

というようなことが挙げられます。 この辺はkernelのマイクロカーネルのそれと同じです。 また、それぞれが別のkenel processですから、最適な権限で動かすことが可能になります。

この手の「OS」はAPI呼び出しはいわゆるweb APIなのですが、「マイクロカーネル」は個々の「カーネルサーバ」に対するプロキシとなります。 つまり、「マイクロカーネル」は、「カーネルサーバ」を束ねることが主な仕事となります。

従来の「パーソナルクラウドOS」では、単一のアプリケーションとして実装されるか、バラバラのAPIサーバを呼び出すことになっていました。

この辺、どっちがどうで、どんなメリット/デメリットがあるかというのは、OS kernelの実装の話と同じです。

今回は、

  • API呼び出し頻度そのものは少ない

    呼び出しオーバーヘッドを意識する必要がない

  • コツコツ実装する方が色々楽になる

    ロードマップが作りやすい

  • 柔軟性に期待が持てる

    機能を大きく拡張することも容易

ということでマイクロカーネル実装となりました。

まぁ現在実際に動いているのは、「プロキシ」と後で述べる「ランチャ」だけなんですが、これがマイクロカーネルの本体になります。 マイクロカーネル自体の機能は少なければ少ないほど良いものです。

マルチユーザ化

「パーソナルクラウドOS」の「何でもroot」は、「パーソナル」であれば許されますが、「オフィス」では許されません。 管理でも運用でも実用でも、大勢で使うとなると「個々」を実現しなければなりません。 一番大きいのは、ファイルサーバとして使った時とメモ帳系のアプリを動かした時に、マルチユーザを期待するというのがあるのですが。

マルチユーザの実現には様々な方法がありますが、今回は「OSのユーザを使う」ことを選択しました。 これは「POSIX互換のOSであれば、ユーザ管理はOSに任せた方が楽」という理由からです。

ユーザ管理そのものは、ウェブアプリでやってるように「自分で認証系を持って自分で管理する」のが色々楽な面もあるのですが、アクセスコントロールを実装しようと思うと、とても面倒臭いことになります。 また、Sambaのように「ユーザとはOSのユーザのこと」と思っているソフトウェアは少なくありません。 ですから、そういったことも含めて考えると、ユーザとしてOSのユーザを使うことが現実的だと言えます。

環境変数あたりの処理がちょっと面倒臭かったりしますが、今のところ最適解だと考えています。

認証系もLinux上のものを使って、PAMというかNSSにも対応しています。 つまりLDAP等にも対応しています。

ランチャ

マルチユーザ化に伴い、アプリケーションを実行するための工夫が必要になります。

具体的には、「パーソナルクラウドOS」は「何でもrootとして起動」で済んでいたのですが、今回は「アプリケーションの性質によって要求されたユーザとして起動」する必要があります。 システム系のアプリケーションやマルチユーザのサーバアプリであればrootあるいは特定ユーザで起動する必要がありますし、個々のユーザ環境を前提とするアプリケーションであれば、起動したユーザとして起動する必要があります。

また、個々のアプリケーションは原則的にweb UIを持っていますが、そのURL(ポート)はCasaOS等では「自分で管理」する必要がありました。 ここは特に自動化もされていないので、ミスはつきものです。 ポート番号の付番も自動化したいところです。

「アプリケーション」は原則的にDocker(的なもの)ですが、必ずしもそれに限定されません。 アプリケーションの性質によって色々あっても不思議ではありません。

というような諸々の問題を解決するための汎用ランチャを実装しました。 汎用なので、CassetteOSで起動する「アプリケーションみたいなもの」は全部これが起動します。 カーネルサーバもシステムサービスも、共有アプリ(サーバ)もユーザアプリも、一手に引き受けます。

ランチャは起動したアプリの状態を監視しています。 なので、勝手に死んだ場合は自動的に再起動します。 ランチャが死んだ場合は多くの場合起動したアプリを道連れにしてしまいますが、ランチャを再起動した時には復元します。 ランチャ自体はsytemdです。

まとめ

とりあえずここまで進捗しました。

これらは「OSの基盤」と言える部分なので、後はダッシュボードとかファイルマネージャとかをコツコツ実装して行けば、それなりのものができるだろうなと思っています。

まだ先は長いですが、現状のCassetteOSと同じ程度の動作をするようになったら公開したいと思っています。

最近のエントリー

CassetteOSマイクロカーネルの実装

地震

あけましておめでとうございます🎍

金曜ごはん #15 「フジツボ香るポトフと手作り肉まん」

ある冬の晴れた日、海岸でフジツボに出会いました

金曜ごはん #14 「手作りつくね鍋~スーパーに導かれて~」

SaaS基盤のアイディア (公知化情報)

第18回 3年以内に起きる「オンプレ回帰」の5つの具体的イベント予測

金曜ごはん #13 「醤油と塩の2種のお鍋」

CassetteOSのロードマップ

Orcinusを開発した理由

12月スタート!事務所をクリスマス仕様にしました

金曜ごはん #12 「リピートハンバーグ」

第17回 業務システムをオープンソースで作ること

金曜ごはん #11「タルタルチキン南蛮と、アボカドシュリンプの彩り晩餐」

金曜ごはん #10 「鶏肉祭り」

Hieronymus Ver 2.0.6 release

HieronymusとOJT後のgemini-cli

金曜ごはん #9 「お肉たっぷり700g!"欲張りハンバーグ"ディナー」

金曜ごはん #8 「ジェネリック山ちゃん再び」