Singularity + openSUSEでコンテナ管理

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

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

OSC 2020 online/kyoto

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

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

openSUSE Leap で iSCSI Target のセットアップ

最近、電源が壊れた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 を使って設定します。

$ sudo zypper in targetcli

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

$ sudo targetcli

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

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

/> cd backstores/fileio 
/backstores/fileio> create file_or_dev=/var/storage/disk1.img name=disk1 size=10G
Created fileio disk1 with size 10737418240
/backstores/fileio> ls
o- fileio ............................................................. [Storage Objects: 1]
  o- disk1 ....................... [/var/storage/disk1.img (10.0GiB) write-back deactivated]
    o- alua ............................................................... [ALUA Groups: 1]
      o- default_tg_pt_gp ................................... [ALUA state: Active/optimized]

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

/backstores/fileio> cd /iscsi
/iscsi> create
Created target iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.b527a14e621a.
Created TPG 1.
Global pref auto_add_default_portal=true
Created default portal listening on all IPs (0.0.0.0), port 3260.
/iscsi> ls
o- iscsi ...................................................................... [Targets: 1]
  o- iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.b527a14e621a ................ [TPGs: 1]
    o- tpg1 ......................................................... [no-gen-acls, no-auth]
      o- acls .................................................................... [ACLs: 0]
      o- luns .................................................................... [LUNs: 0]
      o- portals .............................................................. [Portals: 1]
        o- 0.0.0.0:3260 ............................................................... [OK]

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

/iscsi> cd iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.b527a14e621a/tpg1/luns
/iscsi/iqn.20...21a/tpg1/luns> create storage_object=/backstores/fileio/disk1 
Created LUN 0.
/iscsi/iqn.20...21a/tpg1/luns> ls
o- luns .......................................................................... [LUNs: 1]
  o- lun0 ....................... [fileio/disk1 (/var/storage/disk1.img) (default_tg_pt_gp)]

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

/iscsi/iqn.20...21a/tpg1/luns> cd ../acls
/iscsi/iqn.20...21a/tpg1/acls> create iqn.2020-04.example.com:desktop-pc
Created Node ACL for iqn.2020-04.example.com:desktop-pc
Created mapped LUN 0.
/iscsi/iqn.20...21a/tpg1/acls> cd iqn.2020-04.example.com:desktop-pc/
/iscsi/iqn.20...om:desktop-pc> set auth userid=testuser
Parameter userid is now 'testuser'.
/iscsi/iqn.20...om:desktop-pc> set auth password=testpassword1234
Parameter password is now 'testpassword1234'.
/iscsi/iqn.20...om:desktop-pc> ls
o- iqn.2020-04.example.com:desktop-pc ..................................... [Mapped LUNs: 1]
  o- mapped_lun0 .................................................. [lun0 fileio/disk1 (rw)]

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

create mapped_lun=0 tpg_lun_or_backstore=lun0

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

/> ls /
o- / ................................................................................. [...]
  o- backstores ...................................................................... [...]
  | o- block .......................................................... [Storage Objects: 0]
  | o- fileio ......................................................... [Storage Objects: 1]
  | | o- disk1 ..................... [/var/storage/disk1.img (10.0GiB) write-back activated]
  | |   o- alua ........................................................... [ALUA Groups: 1]
  | |     o- default_tg_pt_gp ............................... [ALUA state: Active/optimized]
  | o- pscsi .......................................................... [Storage Objects: 0]
  | o- ramdisk ........................................................ [Storage Objects: 0]
  | o- rbd ............................................................ [Storage Objects: 0]
  o- iscsi .................................................................... [Targets: 1]
  | o- iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.b527a14e621a .............. [TPGs: 1]
  |   o- tpg1 ....................................................... [no-gen-acls, no-auth]
  |     o- acls .................................................................. [ACLs: 1]
  |     | o- iqn.2020-04.example.com:desktop-pc ........................... [Mapped LUNs: 1]
  |     |   o- mapped_lun0 ........................................ [lun0 fileio/disk1 (rw)]
  |     o- luns .................................................................. [LUNs: 1]
  |     | o- lun0 ............... [fileio/disk1 (/var/storage/disk1.img) (default_tg_pt_gp)]
  |     o- portals ............................................................ [Portals: 1]
  |       o- 0.0.0.0:3260 ............................................................. [OK]
  o- loopback ................................................................. [Targets: 0]
  o- vhost .................................................................... [Targets: 0]
  o- xen-pvscsi ............................................................... [Targets: 0]

Dec 25th, 2019

2019年のイベントふりかえり

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 大阪に出展します。

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

KVMにbridgeしたときにうまく通信ができない時に確認することその1

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

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

Dec 22nd, 2019

LibreOffice で OpenType フォントの機能を使ってみる

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だったんだ?

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

Dec 19th, 2019

openSUSEでファイルがどのパッケージのものなのか調べる方法

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



openSUSEはnmapからどう見えるか

セキュリティ的な観点からサーバの情報を調べるツールとしてnmapがあります。nmapを使うと、そのサーバがどのような種類かを外部から調べることができます。そこで、 nmapからopenSUSEサーバはどのように見えるかを簡単に調べてみました。

nmapはOSやディストリビューションごとにバージョンが異なります。できるだけ最新の方がよいので、openSUSE 15.1/15.0に含まれているものを使用しました。バージョンはどちらも7.70 です。
openSUSE 15.0から15.1に対してテストした結果は以下の通りです。

# nmap -O 172.31.255.189
Starting Nmap 7.70 ( https://nmap.org ) at 2019-12-14 16:42 JST
Nmap scan report for 172.31.255.189
Host is up (0.00051s latency).
(略)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 – 4.9

意外とおおざっぱな結果しか出ませんね。15.1から15.0へも同じ結果でした。
では、ほかのディストリビューションではどうでしょうか。手元ですぐに試せるものを試してみたところ、
CentOS 7.4

OS details: Linux 3.10 – 4.11, Linux 3.2 – 4.9

Windows 10

Running (JUST GUESSING): Microsoft Windows XP|7|2008 (87%)

Windows 8.1

Running: Microsoft Windows 2008|8.1|7|Phone|Vista

Windows Server 2012R2
という感じになりました。やはり以外とおおざっぱです。
ということで、 nmapで調べると、どの系統のOSか、という所くらいまでは分かる、という事がわかりました。

Dec 16th, 2019

Cross Distro Developers Camp 2019 秋 行ってきました

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

前回にCross Distro Developers Campの春の合宿のレポートを書きましたが、今回は秋の合宿です。11/16(土)、17(日)に行われた開発合宿をレポートします。

Cross Distro Developers Campとは

日本語入力など、ディストロに関係せず解決するべき課題を共有・解決していくための有志の集まりです。前回にも紹介文を書いていますので、そちらもぜひお読み下さい。今回の参加は、Debian、Ubuntu、openSUSEのメンバーの方達でした。あと、LibreOfficeからも参加して頂きました。

秋の合宿

9月に日程は決まっていたのですが、趣味でやっているキックボクシングの試合などで私がちょっと疲れてしまっていて、肝心の場所探しなどは10月になってから慌ててやりました。(みなさん申し訳なかったです)

千葉や熱海の方に開発合宿プラン有りの評判の宿がいくつかあったのですが、日程がタイトだったためどこも予約でいっぱい。都内のホテルフクラシア晴海なども検討したのですが、結局、真鶴のペンションshiosaiさんにお世話になることにしました。開発合宿用の設備(ホワイトボード、wifi、プロジェクター)などを貸してくれることと、食事が美味しいということ、お値段も良心的な所などで決めました。チェックイン・チェックアウトの時間を調整して頂けたこともポイント高かったです。

ペンションshiosai

私はLibreOfficeのnaruogaさんの車に家の近くから乗せて頂いたのですが、最寄りの駅(真鶴)からペンションshiosaiまではちょっと距離があった様子です。丘の中で起伏もある感じでした。そのかわり、海を見下ろせる景色はすごく良かったです。

部屋は6人ぐらいの大きめの和室と、3人のベッドありの洋室をとって頂きました。 和室はそのまま開発合宿に使用して良いとのことで、ずっとここで作業を行い、食事になったらテーブルを並べて食事をして、夜になったら布団を敷いて寝る、みたいな感じでした。

露天風呂もあって、男性は午後から夕方までの利用だったのですが、温泉合宿な感じは充分でました。まぁペンションですので前回のマホロバマインズ三浦のようなリゾートホテルといったイメージではないのですが、男性の開発合宿や、家族旅行などでしたら愉しめると思います。今回の合宿の時も、ご高齢の方達が料理を愉しんだりしていらっしゃいました。

舟盛り

舟盛りが一つ12kだったのですが、電話予約で6kにしてくださるとのことでしたので、二つ頼みました。8人でしたので、1人2kいかないぐらいですね。この他にもさらにお刺身が出たり、ステーキも出たり、で、量、質、ともに満足な食事でした。さすが予約時に自信たっぷりに「うちは料理がいいですよー」とおっしゃっていただけのことはあります。

土曜日の昼11時にチェックインして、日曜日の16時まで使わせて頂いて、1人14kな予算感でした。真鶴までの交通費や日曜日の昼などもあるのでこの限りではないのですが、納得のお値段でした。

作業

私は前回同様、今回もGeekoMagazineの執筆をさせて頂きました。合宿の時期がGeekoMagazine執筆締め切り前になりがちなので、どうしても原稿作業になってしまう模様。お陰で、難航必死の執筆が、第一校があがるまで進みました。

他の方はDebianのneologdのパッケージングや、Cross Distro Developers Campのサイト作成、橋本雅彦さん作のかな漢字変換エンジンの試用など、色々と作業されてました。

夜に共通話題についての意見交換も行いました。前から議題になっているインプットメソッドの問題や、フォントに関する現状などがトピックになりました。

今回サイトが作成されましたので、ここで出たトピックの取りまとめなど、情報発信も積極的に行っていきたいと思います。(なかなかコンテンツを作成できず、すみません・・・)

また、OSC 2020 Tokyo/Springで、ディストロ横断でセッションを持ったら面白いんじゃないか、という話になり、現在、実現に向けて準備していますので、来年2/21(金)、22(土)のOSC 2020 Tokyo/Springを楽しみにしていて下さい。場所は駒沢大学、アクセスも良好かと思いますので皆さんの参加をお待ちしています。内容は、各ディストロがどうやって開発してるか、開発するにはどんな方法があるか、といった話になりそうです。

次回の合宿は

次回は2020年2月を予定しています。これは蕪さんの温泉合宿にあいのりさせてもらう予定です。

また、その前に1月11日(土)に、もくもく会を開催いたします。ディストロに興味のある方、実際に開発している方、参加歓迎ですので検討してみてください。

さて、Advent Calendar、明日はribbonさんによるnmapの記事です。お楽しみに〜