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

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

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

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

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

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

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

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

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

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

この記事は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コマンドで取得できる情報の活用を試してみて下さい。