結論から先に書きます。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 で提供されているものが使えました。

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

ビルド結果は 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 がときどき落ちていることがあったので、起動ループになると嫌だなと思い、長めに設定してみました。

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

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

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

Singularityって何か？

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

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

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

openSUSEとSingularityは相性抜群！？？

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

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

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

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

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

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

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

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

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

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

まとめ

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

今年のOSCは感染症の影響ですべてオンラインになりました。京都開催のOSCもZoom+Youtube配信。openSUSEのセッションは、2020/08/28 に
「あつまれ！openSUSEユーザーの森」というタイトルで、LTに近い感じで数人がどのようにopenSUSEを使っているかを紹介するという内容でした。
おもしろかったのは、タスクバーをどこに置くか、と言う事が人それぞれだったということです。システムで決まっている位置はあるのですが、使い勝手とかを考慮して、上だったり右だったり左だったり。

自分はリモート接続で繋いだとき、実画面よりも仮想画面の縦方向が長いと、タスクバーが下にあると操作ができなくなってしまうため、常時上にしています。いわゆるMac風ですね。ただ、Windowsだと、メッセージの一部(通知)が右端にしか表示されないため、右に寄せている、という話も出ました。それはそれでしょうが無いと納得でした。

openSUSE Advent Calendar 25日目です。今回も無事完走できました。

最終日の今日は1年間のイベントをふりかえってみます。全体の傾向としては、今年は毎年抑えている OSC のみで、北海道や島根などの地方 OSC への参加は少なめでした。

また、OSC 東京の後、高幡不動で飲んでいる間に企画が立ち上がった Cross Distribution Developers Camp (XDDC) が始動し、openSUSE 単独のもくもく会のかわりに、他のディストリビューションを巻き込んだイベントが多くなりました。

1月

• openSUSE もくもく会・新年会＠京都
• OSC 大阪
  • ブースのみ出展

2月

• OSC 浜名湖
  • 「eBPFを使ってシステムコールをトレースしてみよう」（川上さん）
• OSC Tokyo/Spring
  • 「Kubic で簡単お手軽 Kubernetes クラスタ構築」（修太さん）
  • 「最近良く聞く Kubernetes を体験してみた」（武山）

3月

• openSUSE Leap 15.1 Bug Squashing Party

5月

• openSUSE Conference
• openSUSE Leap 15.1 リリース

6月

• ディストリビューション開発合宿

7月

• OSC 名古屋
  • 「GPU仮想化最前線 – KVMGTとvirtio-gpu -」（安藤さん）
• openSUSE mini Summit

8月

• OSC 京都
  • 「XDPによる高速パケット処理プログラミング入門」（川上さん）
• コミックマーケット C96
• Open Developers Conference
  • 「日本語入力の危機を乗り越える　インプットメソッド・フレームワークとかな漢字変換に訪れている課題とその対策」（Cross Distribution Developers Camp）

9月

• ディストリ開発もくもく会
• 技術書展7

10月

• openSUSE.Asia Summit 2019

11月

• 関西オープンフォーラム
• ディストリビューション開発合宿
• OSC Tokyo/Fall
  • 「最近よく聞く！？ ― eBPF (extended Berkeley Packet Filter) を用いた PostgreSQL の性能測定」（川上さん）

12月

• コミックマーケットC97（4日目の12/31です）

来年のイベントは？

コミケがまだ残っていますが、来年は京都のもくもく会＆新年会と東京の新年会からスタートです。その後は OSC 大阪に出展します。

それでは来年もよろしくお願い致します。良いお年を。

この記事はopenSUSE Advent Calendar 2019の24日目です

※2020/01/26 追記 この設定をしてしまうと、Dockerが動かなくなってしまいます。詳細は現在調査中。まとまりましたら報告させて頂きます。※

GeekoMagazine 2019 冬号に、仮想サーバーをさくっと建てる方法を書かせていただいております。よろしくお願いいたします。

さて、私は実際にこの方法で立てた仮想サーバーを活用しているのですが、最近、家のルーターがipv4アドレスを仮想サーバーに割り振ってくれなくなってしまいました。

結論 ホストがbridgeしたパケットをフィルタリングするのを無効にする

sysctlで以下の設定を行った所、無事、DHCPでipv4が割り振られました。

net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

1行づつ、sysctl -w で設定してもよいですし、ファイルに記述して、sysctl -p でそのファイルを読み込んでもOKです。

ただ、/etc/sysctl.d/ にファイルを配置しても、起動時に読み込んでくれません・・・ここは追って調査して、記事にしたいと思います。

これらは、bridgeのフィルタリングを無効にする設定とのことです。

もしかしたら、最近のカーネルのアップデートなどで設定が消えてしまったのかもしれません。私が忘れているだけで、以前はこの設定をしていたかもしれず、記事から抜けてしまっていて申し訳ないです・・・