Mercurial > hg > Document > Growi
changeset 126:314fd9757b8f
backup 2023-05-30
author | autobackup |
---|---|
date | Tue, 30 May 2023 00:10:03 +0900 |
parents | 6ada2ac89a42 |
children | 252d26ac7623 |
files | user/matac42/notes/2023/05/29.md user/mizuki/メモ/2023-5-29.md |
diffstat | 2 files changed, 139 insertions(+), 0 deletions(-) [+] |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/user/matac42/notes/2023/05/29.md Tue May 30 00:10:03 2023 +0900 @@ -0,0 +1,101 @@ +## 研究目的 + +- システム全体の信頼性を上げたい +- Gears OSを使って実現する +- FSとDBをRedBlackTreeで統一 + +## 中間報告書を作った + +- https://growi.cr.ie.u-ryukyu.ac.jp/user/matac42/2023/research_plan#%E4%B8%AD%E9%96%93%E5%A0%B1%E5%91%8A%E6%9B%B8 + +## 中間報告書に対するフィードバック + +### 将来像に対する質問 + +原則としてはGearsOS上で各種検証することで信頼性保証するという方向だと想像します。 +しかしながら他OSで他ライブラリ満載を前提としたシステム開発が当然であることを踏まえると、わざわざGearsOSに移植するのは手間ですし、移植作業そのものが外乱になり使いづらいイメージがあります。この辺りの問題は何か考えていることがあるでしょうか。 + +- 言語レイヤでGears OSの仕組みを導入する +- 既存の言語をCbCにトランスパイルする +- 既存の言語で書かれたリソースを使うことができる + +### FSやDBの設計上の問題と実装上の問題の切り分けについて + +RedBlackTreeで実装するための設計について、その設計自体の問題がある場合と、実装に落とした際に問題がある場合があると思います。今回の「信頼性を保証するOS」という点からは、それらをどう切り分けるのか、もしくはどう保証していくかという方針があれば教えてください。(的外れな質問かもしれないですが、意図としては保証の範囲やそこから外れた部分に対してどういう前提を持っているかということを知りたいです) + +- 考え中...... + - 信頼性を保証する必要がある要素はおそらく無限にある + - なので部分的な信頼性の保証を列挙する + - 列挙した部分に関しては保証されている + - 保証の対象から外れているであろう部分について + - そもそも感知できない + - 設計自体の信頼性を保証する方法はあるかもしれないが別で考える必要がある + +### RedBlackTreeによるファイルシステムの拡張性について + +例えばファイルシステム側で暗号化、重複排除といった直接的にはファイルシステムの範疇を超えているような機能までも提供しているファイルシステムが多々あります。GearsOS上のFSでも代表的なFS機能を提供することは可能でしょうか? + +- 可能ではあるがその機能の信頼性を保証する必要が出る + - 正しく暗号化、復号できるか + - 重複排除は正しく行われているか + +### 評価について + +現時点で想定している評価項目や評価方法について教えてください。 + +- 評価項目 + - RedBlackTreeの変更の正しさ + - トランザクションの正しさ + - アクセス権限の正しさ + - SSDへのコピーの正しさ + - 正しくスキーマに対応しているかどうか +- 評価方法(上から順に) + - invariantの証明 + - TPC-C + - ? + - ? + - ? + +### Treeの選択について + +RedBlackTreeを採用した根拠は何でしょうか?そもそもDBやFSではBTreeがよく用いられますが、平衡木としてならばよりシンプルなAVLTreeがあるので、AVLTreeを採用した方が実装しやすくて良さそうに思えます。特段の理由・目的・根拠があれば説明ください。 + +- 証明がしやすいから +- 性能的にはAVL木の方が良い? + - http://wwwa.pikara.ne.jp/okojisan/avl-tree/index.html + +### 課題について + +OSの信頼性を高める必要があることはわかったのですが、GearsOSではまだ未実装な機能がある、または信頼性が十分でないからなのでしょうか?それともほかのOSにも共通して、信頼性を高めることが課題となっているのでしょうか? + +- Gears OSは未完成 +- OSとして必要な機能を信頼性を確保しながら実装していく +- 他のOSにそのまま適応できるわけではない + - FSはRBTreeでなく、B+Treeで実装されているなどの違いがある + +## 研究計画書について + +- 様式が変わったらしく、書き直す必要がある +- 研究指導計画の記入をお願いしたい + +## TPC-Cについて調査中 + +- トランザクションを評価する方法を知らない +- TPC-Cという手法がある + - https://www.tpc.org/TPC_Documents_Current_Versions/pdf/tpc-c_v5.11.0.pdf + - > database server, file system, or other data repository that provides a functionally equivalent implementation. + - RDBでなくても使えるかもしれない + +## n重で再帰する関数を言葉で説明するのは難しい(Erlang) + +- https://www.blog.matac.info/posts/yaep31/ + +## CbC x.v6 DB + +- 進捗なし + +## その他 + +- 就活始めました(遅 +- 「パプリカ」を読んだ(映画も観た) +- Beatmaniaで七段に受かった \ No newline at end of file
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/user/mizuki/メモ/2023-5-29.md Tue May 30 00:10:03 2023 +0900 @@ -0,0 +1,38 @@ +## 研究目的 +・サービスを保守運用する中で、システム障害は避けられないものである。しかしながら、障害が発生した時には既に手遅れであることが多く、普段からシステムの状態を把握することが重要である + +・障害が発生した際だけでなく、常にシステムの状態を気軽に確認できることが望ましい + +・その際、現状ではサーバーやサービスの管理画面にログインしコマンドを打って調査する必要があり手間がかかる。 + +・また琉球大学知能情報コースには学生が管理するシステムがあり, 職員と学生が主体となる管理チームによって管理している。これらのシステムは利用者である学生も管理に参加することが教育的観念から好ましいと考える + +・そこでチャットツール上からシステムの管理を行う手法を提案する。 + +## やったこと +### 中間報告書の提出 +https://growi.cr.ie.u-ryukyu.ac.jp/user/mizuki/%E3%83%A1%E3%83%A2/2023/midterm +FBはまだないです + +### podmanでvulsの構築 +https://vuls.io/docs/en/install-with-vulsctl.html +https://gist.github.com/kotakanbe/5e7ff3ca54bb8232d6cf1a75af18262d +上記のドキュメントとpullした設定ファイルなどを見ながら構築 +脆弱性情報を取得するためのイメージの構築やスキャンのコマンドがdokcerコマンドで書かれていたのでpodmanに修正 +コンテナ内からホストにアクセスする必要があるためsshkeyの作成とknown_hostsにホストOSの情報を記入 +その後脆弱性scanの実行ができたが結果は脆弱性の数が0となった。 +明らかにおかしいので再度設定の見直しを行います。 + +### golangでのldap情報の取得 +go-ldapのドキュメントとかexampleを参考に情報の取得ができた。 +これをコンテナ上で動作させればldapsearchの部分は動く。 + +[情報処理学会インターネットと運用技術研究会の確認](https://www.iot.ipsj.or.jp/) +- IOT63 +- 日程: 2023 年 9 月 上旬 (予定) +- 場所: 調整中 +- OS研究会, RDM研究グループと共催 +- PC: 調整中, LA: 調整中 +- CfP: IOT63 CFP +- Program: IOT63 プログラム +- Report: IOT63 開催報告