Proxmox VEのLXCでopenSUSEを使う

By ribbon @ 2020-12-03 00:02

手軽な仮想化環境 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のようになります。

図1 yast を入れた直後の yast の画面

何もないですね。この時点では、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 を無効にするかどうかを聞いてきます。

図2 capsは不要

今は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 + openSUSEでコンテナ管理

By hashimom @ 2020-09-30 02:13

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

今回は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開発がしやすくなった!?という触れ込みは、どうやら嘘ではなかったのかも??←筆者がそもそも半信半疑だったとか(汗)

最近、電源が壊れたPCを1台リプレースし、余ったマザーボード、CPU、メモリーでファイルサーバーを構築しました。その際にデータをファイルサーバーに移し、デスクトップ PC の HDD を外してしまったので、仮想マシン用の VM の仮想ディスクイメージもファイルサーバーに移す必要がありました。しかし、Hyper-V のディスクイメージは Samba サーバーに置くことができないようなので、仮想マシンのディスクイメージを iSCSI で Hyper-V に接続するようにしてみました。

今日は openSUSE Leap 15.2 (beta) で iSCSI Target(サーバー)のセットアップ方法を紹介します。今回設定する構成はディスクイメージを iSCSI で公開するファイルサーバーと、ファイルサーバーと同じネットワークにあり、そのディスクイメージを使用する Windows 10 のデスクトップ PC からなる単純なものです。

必要なパッケージは targetcli をインストールすれば揃います。YaST でも設定できるのですが、設定できる項目が少ないようなので、targetcli を使って設定します。

それでは targetcli を起動して設定していきます。

まずはディスクイメージファイルを作成します。targetcli の中で /backstores/fileio に移動して、create コマンドでディスクイメージを作成できますここでは /var/storage/disk1.img に 10 GB のディスクイメージ作成します。 /var/storage ディレクトリは先に作成しておく必要があります。

ls コマンドで disk1 が作成されたことが確認できます。

次に /iscsi で create コマンドを実行し、iSCSI の target を作成します。create の IQN 形式の ID を省略すると勝手に作成してくれます。

この target で公開するディスク (lun0) を作成し、最初に作成したディスクイメージ(/backstores/fileio/disk1)を割り当てます。

最後に、この taget にはデスクトップPC からしかアクセスできないようにします。ここではデスクトップPCのID(Windows の iSCSI イニシエーターに設定するもの)を iqn.2020-04.example.com:desktop-pc とします。tpg1/acls 内でイニシエーター名を指定し、create コマンドを実行します。さらに、ユーザーIDとパスワードを設定し、事実上誰からもアクセスできる状態にならないようにします。

この段階で mapped_lun0 が作成され、iqn.2020-04.example.com:desktop-pc に mapped_lun0 が作成されます。Leap 15.1 で試したときは、この mapped_lun0 が自動的に作成されず、Windows の iSCSI イニシエーターから接続してもディスクが何も表示されない状態になってしまいました。このような場合は、次のコマンドで mapped_lun を作成することができます。

これまでの設定は以下の通りです。この状態で Windows の iSCSI イニシエーターでファイルサーバーに接続すると、ディスクの管理で iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.b527a14e621a の lun0 (/backstores/fileio/disk1, /var/storage/disk1.img) がディスクとして見えるようになります。あとは Hyper-V でこのディスクを割り当てれば仮想マシンのディスクとして使用することができます。

この記事は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のフィルタリングを無効にする設定とのことです。

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

LibreOffice Advent CalendaropenSUSE Advent Calendar の 22 日目です。毎年、二重投稿ですみません。

今日もちょっと小ネタで LibreOffice で OpenType フォントの機能(feature)の使い方です。※ feature の訳が機能で良いかはいつも困ります

スライドなどで、Noto Sans JP (Noto Sans CJK JP) や源ノ角ゴシックを使うと、IPA Pゴシックや、Meiryo UI、Migu 1C などのプロポーショナル日本語フォントに慣れていると、ちょっと間隔が空き過ぎと思う人はいるのではないでしょうか?

Noto Sans JP を普通に使うと

実は、Noto Sans JP フォントには、プロポーショナルなフォントの文字送り情報が含まれており、OpenType フォントの機能の Proportional Alternate Metrics をサポートするソフトウェアで使用することができます。最近の LibreOffice でもサポートされています。先ほどのスライドはこんな感じになります。見慣れた感じになりますね。

Noto Sans JP:palt

palt を使うには、フォント設定ダイアログの「機能」ボタンを押してダイアログを出し「Proportional Alternate Metrics」を選ぶか、フォント名の最後に「:palt」を付けます。他にも色々な機能がありますが、LibreOffice ではすべての機能に対応しているわけではないようです(選択しても有効にならないものあり)。

OpenType フォントの機能のダイアログ

OpenType フォントの機能について、詳しく知りたい方は以下のページをチェックしてみて下さい。
https://helpx.adobe.com/jp/fonts/using/open-type-syntax.html#palt

openSUSE Leapは、15の前は42だったんだ?

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 フォントの機能を使う話」です。有意なお話っぽそうですね。お楽しみに!