By ftake @
2020-12-14 23:16
openSUSE Advent Calendar の14日目です。
オンラインイベント続きで Zoom が欠かせない今日この頃ですね。openSUSE 用のクライアントアプリの RPM パッケージは公開されていますが、なぜかリポジトリからの配信ではありません。そのため、アップデートが簡単にできなく不便です。
ということで、1コマンドで更新する小ネタです。単に zypper で URL を指定するだけです。自動更新がよければ、Systemd Timer で定期実行してもいいかもしれませんね。
sudo zypper in https : //zoom .us /client /latest /zoom_openSUSE_x86_64 .rpm
By ftake @
2020-12-10 23:25
この記事は 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/
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を動かすのには失敗しました。
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となりました。
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
ドキュメントに従ってビルドします。
ビルド結果は 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