Samba には日本語マニュアルがあるのにパッケージ化されていません。ですので、日本語マニュアルのtar.gz ファイルを持ってきて展開することになります。このままですと管理が不便なので、RPMファイルを作ってみることにしました。ただ、一から作るのも大変なので、Linuxのコマンド日本語マニュアルのRPMファイルをベースにして作ってみることにしました。

まず、openSUSE 15.2 のSRPMファイルを入手し、rpm コマンドでインストールします。すると ホームディレクトリ配下のrpmbuild/SPECS ファイルにspecファイルが展開されます。これをベースに修正することにしました。…. が単にマニュアルファイルを所定のディレクトリにコピーするだけ、という単純なものかと思いきや、ちょっとしたテクニックが使われていました。

細かなことをやっているのは install セクション。ここでは、既存のディレクトリにインストールしようとするファイルと同じものがある場合、RPMファイルに含めないようにしています。また、複数のパッケージの日本語マニュアルをまとめているため(たとえば sudo とか tcpdump とか)、各パッケージ毎のサブディレクトリがあり、その中にさらにmanのカテゴリ毎(man1とかman8とか)に分けて日本語マニュアルが格納されています。このままではSambaの日本語訳ファイルアーカイブとは合わないため調整しました。そうして各ファイルをインストールする部分は以下のようになりました。

%install
mkdir -p %{buildroot}%{_mandir}/ja
for i in find output/manpages/ -name *.*
do
SUBDIR=man${i##*.}
mkdir -p %{buildroot}%{_mandir}/ja/$SUBDIR
install -m 644 $i %{buildroot}%{_mandir}/ja/$SUBDIR
done

#find の所、バッククォートがうまく入力できないのですが実際にはあります。

Samba日本語マニュアルのアーカイブはmanpages というディレクトリ配下にすべてのカテゴリ(man1からman8まで)が含まれています。そこで、カテゴリ毎に振り分けが必要です。そのため、

• findでファイル一覧を作って do ループに渡す
• ${i##*.} で、拡張子のみを抜き出し、振り分け先のディレクトリ名を作る
• そこにinstall する

という形になります。拡張子のみをどうやって抜き出すかが大変なのですが、bash の変数名の後に ## を付けると、変数展開時に前方一致した部分を削除することが出来るのですね。そこで、ピリオドより前の部分を全部そぎ落としてしまえば、拡張子のみが残るというしくみです。この辺はbashシェル職人じゃないと思いつかないところですね。

後は多少調整して無事RPMファイルを作成できました。これで、openSUSE でも簡単にSamba の日本語マニュアルを参照できます。出来上がったものは
Samba翻訳プロジェクト のダウンロードの所に置いておきました。
….なのですが、openSUSE 15.2のSambaはバージョン4.11.x なので、作成したものとはバージョンが違ってました…. まあだいたいの所は同じですけれど。

参考URL
https://qiita.com/t_nakayama0714/items/80b4c94de43643f4be51
https://qiita.com/mriho/items/b30b3a33e8d2e25e94a8

この記事は openSUSE Advent Calendar 10日目です。

今日は Open Build Service（動画配信ソフトと紛らわしいですが、以下 OBS）をセルフホストする話です。

Open Build Service

ご存知の人も多いかと思いますが、まずは OBS についておさらいしておきたいと思います。OBS は openSUSE で使用しているパッケージの開発のためのシステムです。openSUSE で使用している OBS の Web UI には次のページからアクセスすることができます。
https://build.opensuse.org

OBS が提供する主な機能は以下のとおりです:

• パッケージソースのバージョン管理
• Pull request スタイルのパッケージ開発のコラボレーション
• CI 環境（オンラインビルド、ビルド結果の配信）
  • rpm はもちろん、deb パッケージも扱えます！

OBS のセルフホスト

OBS 自体もオープンソースソフトウェアであり、openSUSE で使うインスタンスを SaaS として使うだけではなく、自身のサーバーにインストールして使うことができます。これにより、会社内で使用するビルドサーバーをローカルに構築することも可能です。

今回は openSUSE Leap 15.2 上にパッケージから OBS をセットアップする方法を紹介します。公式ウェブサイトのダウンロードページの目立つところには（2020年12月現在） 15.1 ベースの ISO イメージからインストールする簡単な方法が書かれていますが、15.1 のサポート期間もそろそろ終わることですし、この方法は今回は使わないことにします。
https://openbuildservice.org/download/

パッケージから OBS をインストール

それでは始めましょう。openSUSE Leap 15.2 はいつものようにセットアップしてください。私が今回実験する上では VirtManager で KVM の VM を作って試しました。

セットアップした後、Web アプリサーバーですので、OBS サーバーにアクセスするときに使用するホスト名の設定をしておいてください。この後の設定スクリプトでがこのホスト名でオレオレ証明書を作ってくれます（設定されていないと止まります）。ちゃんとしたドメインのホスト名でも良いですし、LAN 内の /etc/hosts に設定して回っても OK です。私はルーター (RTX810) の DNS で、LAN 内でのみ有効なホスト名を割り当ててます。

OBS サーバーのパッケージをインストールしましょう。リポジトリを追加して OBS_Server パターンをインストールするだけです。実際は機能ごとにサーバーを分けることもできますが、今回は全部入れてしまいます。

zypper ar -f https://download.opensuse.org/repositories/OBS:/Server:/2.10/openSUSE_15.2/OBS:Server:2.10.repo
zypper in -t pattern OBS_Server

※OBS を構成するサービスについては、ユーザーガイドに解説があります。今回はビルドも含めて一緒に動かします。
https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs.architecture.html

OBS サーバーを起動するために色々設定しましょう。ここでも手を抜いて設定スクリプトを使います。/usr/share/doc/packages/obs-server/README.md に書かれている通り、次のスクリプトを実行して、あとは待つだけです。

/usr/lib/obs/server/setup-appliance.sh

OBS アプリケーションの設定

セットアップが終わったら、https://設定したホスト名/ にアクセスしてみましょう。オレオレ証明書の警告は出ると思いますので、続行するか信頼済みの証明書に登録するかはおまかせします。

まずは Admin アカウントでログインしてみてください。初期パスワードは opensuse です。そうすると、いつもの OBS の Web UI に見たことのない管理用のアイコンが並んでいます。（画像はプロジェクトとパッケージをいくつか追加した後の状態）

あとは、ユーザーを追加したり、プロジェクトとパッケージを追加したり、好きなようにできます。1つやっておいたほうがよいことは、openSUSE の OBS との連携設定です。というのも、セットアップした状態では、ビルドターゲットのディストリビューションの定義（パッケージ類）がない状態です。これを1から作る（パッケージをアップロードしたり）のは大変です。そこで、openSUSE の OBS とリンクします。これにより、openSUSE をはじめとしたディストリビューションの定義やパッケージを必要に応じて、自動的に openSUSE の OBS から取ってこられるようにできます。設定自体は簡単で、設定画面から「Interconnect」にあるボタンを1回クリックするだけで終わります。

詳しい情報

ユーザーガイドとアドミニストレータガイドがあるので、見ておくと良いでしょう。 https://openbuildservice.org/help/

仮想環境プラットフォームとしてとても便利なProxmox VEですが、バージョン6.3が出ています。

変更点は https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_6.3 にありますが、順当に少しずつ機能が強化されてるという所でしょうか。あと今回は、Proxmox Backup Server との統合機能がメインかな。

地味にモダンなインタフェースになっているところもあります。例えば、今までプルダウンメニューで選択していたブート順の指定が、GUIのドラッグ&度ラップで出来るようになっていたりします。

日本語訳については最新版が反映されていないようです(画面ではテスト環境なので最新版になってますが、まだバグがありますね)。

そのほか、クラスタ回りとかストレージ回りで少しずつ改良がされているようです。ただ、openSUSE をゲストOSにしてテストするような場合にはあまり影響はないようです。

某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
  • master 1 worker 2 構成
  • 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使用率やメモリ使用量の上限などを設定できます。このあたりについてもおいおい見ていきたいと思います。

この記事は openSUSE Advent Calendar の6日目です。今日時点でまだ半分残っているので、みなさん参加してくださいね！

12月19日（土）に OSC でおなじみの OSPN 主催で開発者向けイベント Open Developers Conference 2020 Online が開催されます。今回は openSUSE としてではなく Cross Distro Developers Camp として出展します。
https://event.ospn.jp/ODC2020-Online/

14時からのセミナーでは「Linuxディストリビューション大集合　〜あなたのLinuxディストリビューションを見つけてみよう〜」と題し、「ディストリビューション」についての説明の後、各ディストリビューションの関係者からそれぞれのディストリビューションの特徴について紹介する予定です。openSUSE については私が担当し、Debian、Solus についての発表も聞けます。

セミナーの後、15時15分からの枠では、パネルディスカッション形式でディストリビューションの開発について話す予定です。パネリストの体験談と会場からの質問をもとに、ディストリビューションの開発に参加してみようかなと思ってもらえるような情報を提供できればと思っています。

2020-12-08 コマンドの引数にコメントをいただき、一部修正しました。

openSUSE でインストール済みのパッケージ一覧を表示するときには、 rpm -qa コマンドを使っていました。しかし、Proxmox VE で使うコンテナイメージには rpm コマンドが含まれていませんでした。もちろんzypper コマンドで rpmコマンドを入れれば良いのですが、zypper コマンドだけで出来る方法がないか考えてみました。結果、

zypper –no-refresh se -i -t package

で代用することが出来ることが分かりました。結果はこんな感じになります。リモートリポジトリの検索を全部やめてしまえばローカルだけになる、と言う仕掛けです。

結論から先に書きます。Proxmox VEのLXC コンテナでX をぅこかすことは出来ませんでした。

コンソールとしてSPICEクライアントやxterm.js も指定できるので、出来るかなと思ったのですが、そうは問屋が卸しませんでした。

Xはインストール出来ます。しかし、xinit で起動してみると、 /dev/tty0 がないと言ってきて起動しません。確かに、/dev/ 配下を見ると、

ls -l

total 0

crw–w—- 1 root tty 136, 0 Nov 20 10:10 console

lrwxrwxrwx 1 root root 11 Nov 20 10:03 core -> /proc/kcore

lrwxrwxrwx 1 root root 13 Nov 20 10:03 fd -> /proc/self/fd

crw-rw-rw- 1 nobody nobody 1, 7 Nov 11 08:28 full

lrwxrwxrwx 1 root root 25 Nov 20 10:03 initctl -> /run/systemd/initctl/fifo

lrwxrwxrwx 1 root root 28 Nov 20 10:03 log -> /run/systemd/journal/dev-log

drwxrwxrwt 2 nobody nobody 40 Nov 20 10:03 mqueue

crw-rw-rw- 1 nobody nobody 1, 3 Nov 11 08:28 null

crw-rw-rw- 1 root root 5, 2 Nov 20 2020 ptmx

drwxr-xr-x 2 root root 0 Nov 20 10:03 pts

crw-rw-rw- 1 nobody nobody 1, 8 Nov 11 08:28 random

drwxrwxrwt 2 root root 40 Nov 20 10:03 shm

lrwxrwxrwx 1 root root 15 Nov 20 10:03 stderr -> /proc/self/fd/2

lrwxrwxrwx 1 root root 15 Nov 20 10:03 stdin -> /proc/self/fd/0

lrwxrwxrwx 1 root root 15 Nov 20 10:03 stdout -> /proc/self/fd/1

crw-rw-rw- 1 nobody nobody 5, 0 Nov 15 23:26 tty

crw–w—- 1 root tty 136, 0 Nov 20 10:03 tty1

crw–w—- 1 root tty 136, 1 Nov 20 10:03 tty2

crw-rw-rw- 1 nobody nobody 1, 9 Nov 11 08:28 urandom

crw-rw-rw- 1 nobody nobody 1, 5 Nov 11 08:28 zero

となっていて、/dev/tty0 がありません。そこで以下を試してみました。

1. /dev/console を /dev/tty0 に ln しようとしたのですが、
   Invalid cross-device link エラーで駄目
2. ln -s でやってみたのですが、xinit を動かしたときに
   parse_vt_settings: Cannot find a free VT: Inappropriate ioctl for device
   エラーで駄目
3. mknod tty0 c 136 0 でデバイスファイルを作ろうとしたのですが、
   operation not permitted
   エラーで駄目

でした。これで行き止まり。

ちなみに、他のディストリビューションも見てみましたが、結果は同じ。そもそも tty0 がないところから同じでした。

というわけで、残念ながらコンテナ内でXを動かすのには失敗しました。

手軽な仮想化環境 Proxmox-VE は、LXC を使ったコンテナ環境も用意されています。コンテナ環境では、kernel は 仮想化環境のベースOSのものを使いますが、ユーザランドはopenSUSE のものが使われます。この記事を書いている時点で openSUSE 15.2 相当のコンテナ環境があったので使ってみることにしました。

openSUSE 15.2 のコンテナ環境は、Proxmox VE 標準で用意されていますので、それをWebインタフェースから選択するだけでダウンロード、インストールができます。

インストール完了後は、パッケージの総数は181個でした。見てみましたが、最低限の動作をするために必要なものだけしかない状態です。ssh,sshもないですし、yastも入っていませんでした。ほとんど何も出来ないと行っていいでしょう。/ ディレクトリも 213M しか使っていませんでした。必要最低限のユーザランドを一気に入れてしまうFreeBSDよりまさらにコンパクトです。さすがにzypper は入っていましたので、パッケージの追加は出来ます。

そこで、まずは zypper update を行ったのち、openssh を入れ、さらに yast (パッケージとしてはyast2) を入れてみました。

yast を入れた直後の画面は図1のようになります。

何もないですね。この時点では、yast2-ycp-ui-bindings, yast2-perl-bindings,yast2,yast2-core,yast2-xml,yast2-logs,yast2-ruby-bindings,yast2-hardware-detection,yast2-pkg-binding というものしか入っていません。 yast のサブメニューに対応するパッケージを何も入れていないため、何もないわけです。

そこで、他のサーバを参考にしつつ、yast パッケージを入れてみることにしました。取りあえずはSamba サーバにしたいため、yast2-samba-server を入れることにしました。すると、yast2-samba-client を含め、関連するパッケージが42個も入りました。

続いてSamba本体のパッケージ Samba を入れます。ここでも40パッケージが追加されました。

さて、Sambaをyast で設定するためには少し準備が必要です。useradd でユーザの追加、共有ディレクトリの準備とアクセス権の設定をします。また、pdbedit でSamba用ユーザの登録をします。その後に yast で Sambaの設定をします。しかし、起動すると、図2のように cups を無効にするかどうかを聞いてきます。

今はSamba経由で印刷することはほぼ皆無なので、最初から無効にしておいてもいいんじゃないかと思うのですけどね。

さて、一通り設定が終わり、Sambaを起動しようとしたのですが、smbdがなぜか起動しません。ログを見ると、

ERROR: failed to setup guest info.

と言うエラーが出ていました。これはSambaが使うゲストユーザの定義がないということでした。調べて見ると、普通OSをインストールしたときには、nobody というユーザが作られているのですが、このLXC環境では入っていなかったのでした。そこで、uid 65534,gid 65533 の nobody を作りました。これでsmbの起動はOKとなりました。

openSUSE Advent Calendar 2020 が始まりました。今年も完走できるのか！？まだ空きがありますので、みなさんご協力お願いします。

みなさん、Spotify を使っていますか？ Spotify は定額サブスクリプションで音楽をストリーミングで聴けるサービスです。再生クライアントはデスクトップ、モバイル各種プラットフォームに対応しており、さらに Linux 用の公式クライアントもあります。

これまで音楽を再生するときは、PC から再生するか、PCの電源が切れているときは、スマホとオーディオアンプ（AI-301DA）を Bluetooth で接続して再生していました。ただ、スマホからの再生は電池を消費するのがちょっと難点です。

ということで、常時電源が点いているファイルサーバー（もちろん OS は openSUSE）から Spotify を再生できるようにしてみました。Spotify の公式クライアントにはちょっと便利な機能があり、自身のアカウントでログインした、他のデバイスの Spotify クライアントを使ってリモートで再生することができます（Spotify Connect）。スマホの Spotify クライアントを使って、PC や Amazon Echo から再生するというのがおそらく一般的な使い方です。

ファイルサーバーにはディスプレイが接続されておらず、デスクトップ環境も動いていませんので、公式の Spotify クライアントではなく、今回は Spotifyd という OSS の非公式クライアントを使用してみました。その名の通り、デーモンとしてバックグラウンドで動作するクライアントです。

ビルド・インストール

誰かが作ったパッケージがあるにはあるのですが、今回はソースからビルドしてインストールしました。master ブランチではなく、リリース版の 0.2.24 を使います。設定ファイルのフォーマットが違う（master では TOML 形式になっている）ので、ドキュメントのバージョンには気をつけて下さい。

https://github.com/Spotifyd/spotifyd/releases/tag/v0.2.24

Rust は openSUSE Leap 15.2 で提供されているものが使えました。

$ sudo zypper in cargo alsa-devel make gcc

ドキュメントに従ってビルドします。

cargo build --release

ビルド結果は target/release/spotifyd にありますので、これをファイルサーバーの /opt/spotifyd/bin あたりに転送します。

設定

/etc/spotifyd.conf を作成します。設定例は README.md に書いてあるとおりです。 https://github.com/Spotifyd/spotifyd/blob/v0.2.24/README.md

• password: Spotify の管理画面でデバイス用のパスワードを発行しておく
• device: 書いてあるとおり aplay -L で使いたい出力のデバイス名を調べて下さい
• cache_path: /var/cache/spotifyd あたりに設定しておきましょう

自動起動に使用する service ファイル（/etc/systemd/system/spotifyd.service）はこんな感じです。ソースコードの contrib ディレクトリ内の例からは少し変えてあります。まず、User は spotifyd ユーザーを作成して root から落としてあります。RestartSec は、spotifyd がときどき落ちていることがあったので、起動ループになると嫌だなと思い、長めに設定してみました。

[Unit]
Description=A spotify playing daemon
Documentation=https://github.com/Spotifyd/spotifyd<br>Wants=sound.target
After=sound.target
Wants=network-online.target<br>After=network-online.target

[Service]
ExecStart=/opt/spotifyd/bin/spotifyd --no-daemon
Restart=always
RestartSec=300
User=spotifyd
Group=nobody
Type=simple

[Install]
WantedBy=default.target

あとは spotifyd を起動して、クライアントからデバイスに接続できるかを試してみて下さい。

$ systemctl enable spotifyd<br>$ systemctl start spotifyd

当ブログではお久しぶりです。鹿野と申します。
あ〜、同じ苗字の人が多いのでそれで(汗)

今回はSingularityを使用して、コンテナ運用する方法を紹介します！

Singularityって何か？

一言で言うと、Dockerみたいなコンテナフレームワークです。
下記のような特徴を持っています。

・ 主に一般ユーザーで使用することを想定（故にGPUとも相性抜群！）
・ Dockerイメージをそのまま使用可能（DockerHUB……もちろん使えます）

……のため、主にスパコンで使用されることが多いようです。
（私も仕事でそっち方面の調査していく中でたどり着いた次第だったり）

openSUSEとSingularityは相性抜群！？？

openSUSE 15.2ではSingularityは公式パッケージが用意されています。
ワンクリックインストールも可能ということですね！
https://software.opensuse.org/package/singularity

zypperでももちろんインストール可能です。

zypper install singularity

実は、公式パッケージが用意されてるのは現時点でかなり稀のディストリのようです。RHELやCentOSではRPMファイルが公開されているのみですし、DebianやUbuntuに至っては自分でコンパイルする必要があったり。

openSUSEがDeepLearningに力を入れてる！
……と数日前まで本気で疑ってましたが、どうやら間違えではなさそう？？？

PyTorch with CUDAを動かしてみよう！

openSUSE 15.2 で Singularityインストール後は下記のおまじないが必要です。

usermod -a -G singularity (Singularityを動かすユーザ名)

openSUSEのSingularity READMEにも書いてありますが、要するにsingularityのグループに実行するユーザを追加してあげる必要があります。（これするならDockerと変わらない気もしなくもないですが……まぁGPUをコンテナ内で動かすという点では一般ユーザ権限で動かせるのは利点なのかな……？）

あとは下記のコマンドで、Singularity用コンテナイメージをビルドすると、コンテナ内でPyTorch + CUDA で動かすことができます。

singularity build pytorch.sif docker://pytorch/pytorch:latest
singularity shell --nv pytorch.sif

たったこれだけですね！
NVIDIA-Dockerのような煩わしさがなく、非常にシンプルだと思います。

singularity shellコマンドに –nv オプションをつけてあげるとコンテナ内でGPUが使用できます。NVIDIAのGPUを使用するには事前にNVIDIAのドライバなども必要ですが、それについては下記のURLから。
https://opensuse-community.org/

まとめ

いかがでしたでしょうか。
簡単にopenSUSE + Singularityを使用して、コンテナ内でGPU（PyTorch）を使用する方法を紹介しました。
openSUSE 15.2でAI開発がしやすくなった！？という触れ込みは、どうやら嘘ではなかったのかも？？←筆者がそもそも半信半疑だったとか(汗)