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 ,
その他 |
受け付けていません
By Syuta Hashimoto @
2019-12-20 06:40
この記事はopenSUSE Advent Calendar 2019 の20日目です。
openSUSEのパッケージ管理はYaSTやzypperなどで行うのですが、パッケージそのものはRPMです。ですので、そのRPMパッケージが含んでいるファイルを一覧表示するなどの、rpmのコマンドを利用することができます。
ここでは、次のことををしてみたいと思います。
パッケージに含まれているファイルの一覧を取得する コマンドやファイルがどのパッケージに含まれているかを調べる （なお、zypperで直接行う方法や、もっとよい方法などがあると思いますので、そういった情報をお持ちの方は是非ご提供ください。）
パッケージに含まれているファイルの一覧を取得する
以下のrpmコマンドで可能です。
$ rpm -ql [パッケージ名]
例：
$ rpm -ql podman
（含まれているファイルのフルパスの一覧）
私は、そのパッケージがどんな設定ファイルを使っているか、また、どこにインストールしているか、などを調べたい時などに使っています。
コマンドやファイルがどのパッケージに含まれているかを調べる
以下のrpmコマンドで可能です。
$ rpm -qf [調べたいファイルやコマンドのフルパス]
例：
$ rpm -qf /usr/bin/podman
podman-1.4.4-lp151.3.6.1.x86_64
ここで、幾つかのコマンドを組み合わせて便利に使ってみましょう。
まず、コマンドのフルパスを取得します。which、typeなどありますが、ここではtypeを使ってみます。
$ type -p podman
/usr/bin/podman
-pオプションで、パス名だけを取得しています。これをrpmコマンドと組み合わせると、次のようになります。
$ rpm -qf $(type -p podman)
podman-1.4.4-lp151.3.6.1.x86_64
これで、rpmのパッケージ名が取得できます。この名前をそのままzypper infoに渡しても識別してくれないので（そんなパッケージは無いと言われてしまうので）、さしあたって、最初の「-（ハイフン）」までの文字を取得してみます。これで「podman」が取得できます。
$ rpm -qf $(type -p podman) | awk -F ‘-‘ ‘{print $1}’
podman
awkはテキストの加工とパターン処理を行ってくれるコマンドです。 -F ‘-‘ で、ハイフンを区切り文字に指定し、 ‘{print $1}’ で、区切られた最初の部分を出力します。
これを、zypper infoに渡せば、zypperでのパッケージ情報を取得できます。
$ zypper info $(rpm -qf $(type -p podman) | awk -F ‘-‘ ‘{print $1}’)
リポジトリのデータを読み込んでいます…
インストール済みのパッケージを読み込んでいます…
パッケージ podman に関する情報:
——————————-
リポジトリ : openSUSE:Leap:15.1:Update
名前 : podman
バージョン : 1.4.4-lp151.3.6.1
アーキテクチャ : x86_64
ベンダ : openSUSE
インストール後のサイズ : 103.1 MiB
インストール済み : はい (y)
状態 : 最新
ソースパッケージ : podman-1.4.4-lp151.3.6.1.src
概要 : Daemon-less container engine for managing containers, pods and images
説明 :
Podman is a container engine for managing pods, containers, and container
images.
It is a standalone tool and it directly manipulates containers without the need
of a container engine daemon.
Podman is able to interact with container images create in buildah, cri-o, and
skopeo, as they all share the same datastore backend.
見事、zypperで情報が取得できました。
見返してみれば、「そもそも、zypper info podmanでよくないか？」と思えますが、コマンド名とパッケージ名が違う場合や、コマンドではなく設定ファイルから情報を引き出したい時などに利用できます。
ただ、間にハイフンが入るパッケージ名では、当然うまく動きませんね・・・typeでパスを取得するためにrootになって、brctlで試してみたのですが、rpmのパッケージ名がbridge-utils-1.6-lp151.2.3.x86_64だったため、ハイフンの前がbridgeとなってしまい、zypper infoで情報を取得できませんでした。まだ改良の余地ありです。
このように、いろいろな方法でrpmコマンドで取得できる情報の活用を試してみて下さい。
Category
openSUSE ,
Tips |
受け付けていません
