By ribbon @
2020-12-05 00:02
2020-12-08 コマンドの引数にコメントをいただき、一部修正しました。
openSUSE でインストール済みのパッケージ一覧を表示するときには、 rpm -qa コマンドを使っていました。しかし、Proxmox VE で使うコンテナイメージには rpm コマンドが含まれていませんでした。もちろんzypper コマンドで rpmコマンドを入れれば良いのですが、zypper コマンドだけで出来る方法がないか考えてみました。結果、
zypper –no-refresh se -i -t package
で代用することが出来ることが分かりました。結果はこんな感じになります。リモートリポジトリの検索を全部やめてしまえばローカルだけになる、と言う仕掛けです。
S | Name | Summary | Type —+———————————–+————————————————————————–+——– i+ | aaa_base | openSUSE Base Package | package i+ | apache2 | The Apache Web Server | package i+ | apache2-example-pages | Example Pages for the Apache 2 Web Server | package i | apache2-prefork | Apache 2 “prefork” MPM (Multi-Processing Module) | package i | apache2-utils | Apache 2 utilities | package i+ | apparmor-abstractions | AppArmor abstractions and directory structure | package i+ | apparmor-parser | AppArmor userlevel parser utility | package i | augeas | An utility for changing configuration files | package i | augeas-lenses | Official set of lenses for use by libaugeas0 | package i | bash | The GNU Bourne-Again Shell | package
By ribbon @
2020-12-04 00:02
結論から先に書きます。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 がありません。そこで以下を試してみました。
/dev/console を /dev/tty0 に ln しようとしたのですが、 Invalid cross-device link エラーで駄目 ln -s でやってみたのですが、xinit を動かしたときに parse_vt_settings: Cannot find a free VT: Inappropriate ioctl for device エラーで駄目 mknod tty0 c 136 0 でデバイスファイルを作ろうとしたのですが、 operation not permitted エラーで駄目
でした。これで行き止まり。
ちなみに、他のディストリビューションも見てみましたが、結果は同じ。そもそも tty0 がないところから同じでした。
というわけで、残念ながらコンテナ内でXを動かすのには失敗しました。
Category
openSUSE ,
Tips ,
サーバ ,
デスクトップ ,
仮想化 |
受け付けていません
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となりました。
Category
openSUSE ,
Tips ,
サーバ ,
仮想化 |
受け付けていません
By ftake @
2020-12-01 00:00
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 Wants=sound.target
After=sound.target
Wants=network-online.target 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 $ systemctl start spotifyd
Category
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でももちろんインストール可能です。
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開発がしやすくなった!?という触れ込みは、どうやら嘘ではなかったのかも??←筆者がそもそも半信半疑だったとか(汗)
Category
openSUSE ,
Tips ,
仮想化 |
受け付けていません
By ribbon @
2020-08-30 15:58
今年のOSCは感染症の影響ですべてオンラインになりました。京都開催のOSCもZoom+Youtube配信。openSUSEのセッションは、2020/08/28 に 「あつまれ!openSUSEユーザーの森」というタイトルで、LTに近い感じで数人がどのようにopenSUSEを使っているかを紹介するという内容でした。 おもしろかったのは、タスクバーをどこに置くか、と言う事が人それぞれだったということです。システムで決まっている位置はあるのですが、使い勝手とかを考慮して、上だったり右だったり左だったり。
自分はリモート接続で繋いだとき、実画面よりも仮想画面の縦方向が長いと、タスクバーが下にあると操作ができなくなってしまうため、常時上にしています。いわゆるMac風ですね。ただ、Windowsだと、メッセージの一部(通知)が右端にしか表示されないため、右に寄せている、という話も出ました。それはそれでしょうが無いと納得でした。
Category
openSUSE ,
イベント ,
レポート |
受け付けていません
By ftake @
2019-12-25 23:55
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月
8月
OSC 京都「XDPによる高速パケット処理プログラミング入門」(川上さん) コミックマーケット C96 Open Developers Conference「日本語入力の危機を乗り越える インプットメソッド・フレームワークとかな漢字変換に訪れている課題とその対策」(Cross Distribution Developers Camp)
9月
10月
openSUSE.Asia Summit 2019
11月
関西オープンフォーラム ディストリビューション開発合宿 OSC Tokyo/Fall 「最近よく聞く!? ― eBPF (extended Berkeley Packet Filter) を用いた PostgreSQL の性能測定」(川上さん)
12月
コミックマーケットC97(4日目の12/31です)
来年のイベントは?
コミケがまだ残っていますが、来年は京都のもくもく会&新年会 と東京の新年会 からスタートです。その後は OSC 大阪に出展します。
それでは来年もよろしくお願い致します。良いお年を。
Category
openSUSE |
受け付けていません