By Syuta Hashimoto @
2022-05-11 20:06
openSUSE.Asia Summit は、コントリビューターやファンがアジア全域から参加者が集まる、アジア地域の年次openSUSEカンファレンスです。このイベントでは、openSUSEディストリビューションとそのコミュニティ、個人や企業で使用するアプリケーション、そしてオープンソースの文化について、主に焦点を当てています。
2014年から、openSUSE.Asia Summitはオフラインで開催され、コミュニティの人たちが実際に会う非常に良い機会でした。しかしながら、COVID-19の影響により、2020年のサミットはキャンセルせざるを得ませんでした。そして2021年、サミットはインドチームによりオンラインで開催されました。
openSUSE.Asia Summit 2022はどうなる？
openSUSE.Asia Summit 2022はハイブリッドイベントとなります。
中心となるオンラインサミットと共に、各国/地域でのオフラインイベントをそれぞれ開催します。
アジア全体パート（オンライン + サテライトのオフライン）
各アジア地域から参加しやすいよう、4:00 – 6:00 UTC（13:00 – 15:00 JST）を目安に開催します。 ローカルパート（オンライン/オフライン – 開催場所に依る）
各国、各地は、COVID-19の影響や制限を熟慮した上で、オフラインイベントを開催することができます。 開催内容はそれぞれの開催場所によって異なります。それぞれの開催場所で、トークセッション、ワークショップ、ミートアップなどが企画されます。 ボランティアにお願いしたいこと
このイベントを実現する為、ボランティアを募集しています。今年はボランティアはどの地域からでも参加できます。
ボランティアにお願いしたいことは以下の通りです。
アジア地域パートの準備の為のレギュラーオンラインミーティングに参加してください（今は金曜日の 13:00 UTC <22:00 JST>にSlackで行っています。） ローカルパートのイベントを企画し、アジア地域パートとスケジュール調整を行ってください オンラインカンファレンスを手伝い、ボランティア同士のミーティングのスケジュールを調整してください オフラインイベントを開催してください（openSUSE.Asia Summitの実行委員に相談し、必要なサポートを受けることができます） ボランティアに興味がありましたら、5月30日までに簡単な自己紹介と共にメールを opensuseasia-summit@googlegroups.com までお送りください。
▶原文はこちら
※訳者コメント※
今年のopenSUSE.Asia Summitは、メインのオンラインイベントと、各地域のローカルイベントのハイブリッド開催となりました。ボランティアスタッフには、オンラインイベント、ローカルイベントの両方（もしくは片方）のお手伝いをして頂ければと思っています。興味を持たれましたら、上記の実行委員連絡先や、ユーザ会の方へご連絡ください。疑問・質問なども遠慮なくお問い合わせください。
By Syuta Hashimoto @
2020-12-23 01:30
諸事情で、MicroOSのルートにbtrfsの機能でディスクを追加したのですが、balasceを実行しようとすると「read onlyだよ」と警告が。
ユーザ会slackに投げてみた所、武山さんから「transactional-update shellの中ならいけるのでは？」との助言を頂きました。
結論
成功
コマンド
transactional-update shell
transactional-updateそのもののアップデートが行われた後、独自のシェルに移行しました。
transactional update #
この状態で書き込み可能になります。書き込み後、シェルを抜けてrebootすれば反映されるしくみですね。
btrfs balance /
前後の状態を撮り損ねてしまったのですが、無事にbalanceされてました。
transactional-updateの真価はまだ味わえてないので、ロールバック等含め、近いうちにまとめて検証してみたいですね。
そもそも、transactional-update shellが一体何をどうしているのかも追えていない・・・
By Syuta Hashimoto @
2020-12-21 01:00
12/19(土)に開催された、ODC 2020 onlineに参加してきました。
Cross Distro Developers Camp
今回は、ディストリビューション横断で日本語入力の課題などを解決しようと結成されたチーム、Cross Distro Developers Campで参加してきました。
ディストリビューションとはなんぞや？から、openSUSE、Debian、Solusの各ディストリビューションの紹介を行いました。
openSUSEは武山さんが紹介してくださいました。
Debianさんなど、あらためて説明を聞くと、特色や方向性が理解できて面白かったです。開発体制なんかも普段は目にすることがないので、興味深かったです。
Solusさんからは、日本語入力関連のパッケージの開発にまつわる、難題のお話も・・・・
休憩時間・雑談タイム
次のコマがミーティングだったので、間で雑談を。
参加者からは話題の？Centos8の事や、ターミナルでの日本語表示に関する問題などが出てました。
データの形式と、それを表示するソリューション（ターミナル）は独立しているべきですけど、ソリューション側で対応すると、それぞれのソリューションで日本語対応しなければならないことに・・
Linuxディストリビューション開発談話
openSUSEから武山さん、Debianから杉本さんがメインパネラーとして、あとはSolusのPG_MANAさん、ひよこLinux（?）の羽鳥さん、opencoconの島田さんにオブザーバーとして参加して頂いて、ディストリビューション開発について談話しました。
結構、ディストリビューション開発って（ソフトウェアもですが）敷居高いイメージありましたが、もちろん世界でどなたかが実際に開発しているわけで、方法もノウハウもあるわけですよね。
日本のコミュニティがそういった情報を持っているし、世界とのコネクションもあるので、まぁアクセスしてよ、とおっしゃってました。
私も来年はパッケージ開発何かしたいなぁ。
ブース
終日、JitsiをOSPNからお借りしてブース展示をしていました。私は主にこのブースの管理をしていました。
関係者の方？が多く入ってくださって、openSUSEユーザ会のRibbonさんとは、最近MLで話題になってた日本語manの話とかを聞けました。あとはみなさんと近況を連絡しあったり、と、普段はオフラインで開催している時にやってた情報交換ができた感じでよかったです。
新しい方はちょっと入りにくかったですかね・・私も無理に声掛けとかしなかったのですが、もうちょっと配慮してもよかったかもしれません。反省。そのあたり、東海道LUGの島田さんが上手にアプローチしてくださっていて、さすがだなぁと思いました。（島田さんには、セミナーのディストロとは？の所をお話して頂きまして、それもあってブースに来てくださってました。）
感想
セミナー・ミーティングは、Zoom 30人強、YouTube 40人弱で70人前後の方が見てくださってました。ありがとうございます。
openSUSEに興味持たれたら、ぜひアクセスしてください！
Cross Distro Developers Campとしては、次回活動は2021年1/31日（日）にもくもく会（オンライン）を予定しています。
Category
レポート ,
未分類 |
受け付けていません
By Syuta Hashimoto @
2020-12-17 01:00
私はKubicでKubernetesを構築しているのですが、Kuibcをアップデートしてkubeletのバージョンが1.19に上がったはずなのにもかかわらず、kubectl get nodeでずっとバージョンが1.18となっていて悩んでいました。
結論
/etc/sysconfig/kubelet に設定されている KUBELET_VERを、1.18から1.19に変更する
調査
パッケージを確認
まず、パッケージがなんのバージョンが入っているかを確認します。
kubic1-host:~ # zypper se kubelet
どうやら、1.17、1.18、1.19、と、いろいろなバージョンが入ってるようです。
今見たら、1.20も入ってますね。
使ってるバイナリを確認
kubic1-host:~ # type kubelet
kubelet is hashed (/usr/bin/kubelet)
ふむふむ。/usr/bin/kubelet、ですね。
こういう実行ファイルはスクリプトの場合があったりするので、種別を調べてみます。
kubic1-host:~ # file /usr/bin/kubelet
なるほど、スクリプトっぽいですね。
中身を確認します。
kubic1-host:~ # cat /usr/bin/kubelet
どうやら、/etc/sysconfig/kubeletの値を参照しているようです。こちらを確認してみます。
kubic1-host:~ # cat /etc/sysconfig/kubelet
なるほど、KUBELET_VERが定義されています。nodeのバージョンが低いときは、ここが1.18となっていましたので、それを1.19に更新しました。
それからKubernetesを起動すると、見事バージョンが1.19にあがってました。
今なら1.20に上がる予感・・・・
メーリングリスト
最近忙しいこともあって、なかなかメーリングリストなどの情報源にあたれず・・・もしかしたら、こういったことはとうに情報共有されていたのかもしれません。また、この設定がKubic独自なのか、一般的なのか、といったことも追いきれておらず。追って調査したいと思います。
そもそもの使い方
アップデートで使い続けるのではなく、折を見て最新プリメイドイメージに乗り換えていく運用が今っぽいのかも・・・・・
Category
サーバ ,
未分類 |
受け付けていません
By Syuta Hashimoto @
2020-12-07 00:10
某LUGで、Kubernetesのメモリ使用量を気にされていたので、測ってみました。
結論
masterノードはKubernetes起動後、1.3G前後のメモリを使用。workerは、コンテナを動かせば動かしただけメモリを使用。15pod程度では、2つのworkerでそれぞれ1G使わない程度でした。
方針
KVM上にKubicを展開して、そこでKubernetesを動かします。
VMの起動のみの状態、Kubernetesを起動した状態、いくつかのpodを動かした状態、で、freeや、topのメモリ使用量上位10のプロセスを拾ってみます。
また、Kubernetes起動後はcrictl statsの結果も見てみます。今回、IDを名前で置き換えていますのでご注意下さい。（通常のcrictl statsですと、IDのみの表示となり名前は表示されません。）
環境
Kubernetes KVM上で動かす OSはKubic CPU数 master 2 worker 1 メモリ それぞれ 3G Kubernetes 1.19.4 ホストopenSUSE 15.2 CPU Ryzen 3900 メモリ 32G Kubic ・・・openSUSEプロジェクトで開発している、Kubernetes専用OSです。Tumbleweedをベースにしていて、Kubernetesを動かすことに焦点を絞ったパッケージ構成＆システム設定。プリビルドなイメージが毎日のように公開されるため、ignitionなどの初期設定ツールを使って手早く最新Kubernetesを展開できます。
Ryzen 3900・・・コア数12なので、VMは結構たてられます。目指せおうちクラウド。
ちなみに、saltstackのマスター用VMを別途立てていて、各ゲストは基本的にそこから制御しています。（今回のコマンド実行は直接各ゲストで行いました。）
VMの起動のみ
master
worker1
worker2
利用可能メモリが、3台とも2.5G程度であることがわかります。
Kubernetes起動後
Kubernetesとネットワークアドオンのweaveを起動します。
master
worker1
worker2
masterがさらに1G程使用しました。workerは数百程度の使用にとどまっています。
podを幾つか起動した後
15個程podを走らせてみます。
走らせたサービスは、Promeheus、Grafana、DokuWiki、Nextcloud、Harborなどです。
master
worker1
worker2
masterの使用量はほとんどかわりませんが、動いたpod分、両workerのメモリが使用された感じです。
参考までに、pod一覧です。
感想
色々と検証しているときは、clairが1G以上メモリを使ったりしていましたが、今回計測しているときは100Mいかないぐらいでした。当然ですが、podの起動だけでなく、実際に使ってみた時のメモリ使用量なんかが実運用上では参照値になると思います。
まだ、プロセスやコンテナの動作と使用メモリとの関連を掴みきれてないので、追って調査してみたいと思います。コンテナのメモリとディスクの関連も。
なお、今回動かしたサービスの殆どはiscsiのPersistentVolumeに接続しています。このあたりの方法も消費リソースと関わっていそうですね。
Kubernetesってメモリ使うんだよなー、よし、各ノードに6G割り当てるか、とかやっていたのですが、今回の計測で今の所3Gでも大丈夫なことがわかったので、設定を変更しました。やはり適切な設定は適切な計測から、ですね。ちなみに、Kubernetesでpodを動かす時に、CPU使用率やメモリ使用量の上限などを設定できます。このあたりについてもおいおい見ていきたいと思います。
Category
openSUSE ,
Tips ,
サーバ |
受け付けていません
By Syuta Hashimoto @
2019-12-24 21:09
この記事はopenSUSE Advent Calendar 2019 の24日目です
※2020/01/26 追記 この設定をしてしまうと、Dockerが動かなくなってしまいます。詳細は現在調査中。まとまりましたら報告させて頂きます。※
GeekoMagazine 2019 冬号 に、仮想サーバーをさくっと建てる方法を書かせていただいております。よろしくお願いいたします。
さて、私は実際にこの方法で立てた仮想サーバーを活用しているのですが、最近、家のルーターがipv4アドレスを仮想サーバーに割り振ってくれなくなってしまいました。
結論 ホストがbridgeしたパケットをフィルタリングするのを無効にする
sysctlで以下の設定を行った所、無事、DHCPでipv4が割り振られました。
net.bridge.bridge-nf-call-ip6tables = 0
1行づつ、sysctl -w で設定してもよいですし、ファイルに記述して、sysctl -p でそのファイルを読み込んでもOKです。
ただ、/etc/sysctl.d/ にファイルを配置しても、起動時に読み込んでくれません・・・ここは追って調査して、記事にしたいと思います。
これらは、bridgeのフィルタリングを無効にする設定とのことです。
もしかしたら、最近のカーネルのアップデートなどで設定が消えてしまったのかもしれません。私が忘れているだけで、以前はこの設定をしていたかもしれず、記事から抜けてしまっていて申し訳ないです・・・
Category
openSUSE ,
サーバ ,
仮想化 |
受け付けていません
By Syuta Hashimoto @
2019-12-21 11:46
この記事はopenSUSE Advent Calendar 2019 の21日目です
今日はLeapのバージョニングについて振り返ってみたいと思います。
Leapの登場は2015年のLeap 42.1が最初のようです。この前がopenSUSE 13.2。
つまり、13.2（Leapの前） > 42.1 （以降、Leap）> 42.2 > 42.3 > 15.0 > 15.1（今年リリースの現行版）とバージョニングされています。
なお、リリースは年に一回で計画されていて、来年は15.2のリリースが予定されています。（現在開発中。）マイナーリリースは3年の計画なので、このままいけば再来年はメジャーバージョンがかわります。
はたして、素直に16にいくのでしょうか？
42?
元ネタは「銀河ヒッチハイク・ガイド 」というSF小説とのことです。ある宇宙人が、「生命、宇宙、そして万物についての究極の疑問の答え」をスーパーコンピューターで計算したところ、答えが「42」だったらしいです。
ちなみに、このスーパーコンピューターは、究極の答えに対応する究極の問いが何なのかわからないため、42 の意味まではわからないのだとか。そこで、その問いを算出する為にスーパースーパーコンピューターを作って、といった所がストーリーにからんでくるようです。そのスーパースーパーコンピューターというのが、実は・・・
Leap 42.1のポータルには、次の素晴らしい一文が乗っています。
openSUSE Leap 42.1 はその重要さに合った名前に値します。
Portal:42.1 なお、15.0がリリースされたあと、「最新バージョンを取得しようとすると、42用パッケージとってきちゃうんですけど・・」「あ、数字が大きいものをとってくるようにしてるから、15じゃなくて42とってきちゃうんだね。」といったやりとりが頻発した模様。
まとめ
バージョニングに突如42をもってくるところに、私はopenSUSEプロジェクトっぽさを感じています。
そもそもLeapが誕生した経緯を調べたい 私がopenSUSEプロジェクトに関わり始めたのはLeap 15目前のときで、42のやりとりはタイムリーには見れていないんですよね openSUSE Advent Calendar 2019、明日はftakeさんの「 LibreOffice で OpenType フォントの機能を使う話」です。有意なお話っぽそうですね。お楽しみに！
Category
openSUSE ,
その他 |
受け付けていません
