ytooyamaのブログ

サーバ構築とか、仕事で発見したこととか、趣味のこととかを書いています。

Ubuntu Server 18.04でNetwork Managerを使う

Ubuntu Server 18.04ではネットワーク周りの機能としてNetplan.ioが使われています(正確にいうと、Ubuntu 17.10から利用されるようになりました)。それに依存して主にネットワーク系はsystemd-networkdが、名前解決関連はsystemd-resolvedが行なっています。

ただし、Ubuntu DesktopフレーバーではNetplan.ioが使われているものの、引き続きNetwork Managerがネットワーク、名前解決周りを担当しています。Ubuntu Desktopではこういった設定のみかかれており、ネットワーク設定などは既存のNetwork Manager GUICLI、TUIなどを使って設定することができます。

Netplan.ioを使ったネットワーク設定の方法はサンプルが公開されているものの、設定はYAML形式で書く必要があります。 こちらもご覧ください。

ytooyama.hatenadiary.jp blog.ubuntu.com

割と最近のツールはYAML形式のファイルをよく使うことがあり、YAML形式に慣れている人であれば問題ないかもしれませんが、慣れていない人にはとっつきにくさを感じると思います。

このとっつきにくさの1番の理由が「スペースの数」だと思います。YAML形式の記述方法はスペースで設定の親、子の関係を表します。大抵は偶数(最小で2つ)のスペースを入力していきます。例えばこんな感じです。

network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
     addresses:
       - 10.100.1.30/24
     gateway4: 10.100.1.1

YAML形式で記述されたファイルを使う場合は、基本的にはスペースの数が正しくないと設定を適用することができません。 これがいわゆる「YAMLの壁」です。慣れてしまえば大したことはないですが、慣れるまでが大変です。

で、今回は「そんなの嫌だ!Network Managerを使ってやる!」という話です。

Ubuntu Server 18.04でNetwork Managerを使うには

前述のように、Ubuntu Desktop 18.04ではNetwork Managerを使っていますので、Ubuntu Server 18.04でも同じように設定すれば良い感じです。次のように設定すると「Netplan.ioをNetwork Manager rendererで利用する」設定を行えます。

% sudo vi /etc/netplan/50-cloud-init.yaml 
# Let NetworkManager manage all devices on this system
network:
  version: 2
  renderer: NetworkManager
(以上の三行だけ書く)

% sudo apt install network-manager && sudo reboot
(Network Managerを入れて再起動する)

% sudo nmtui
(IPアドレスの設定をCLIとかTUIツールとかで実施)

以上です。簡単ですね。

ただ、アプリケーションによってはNetwork Managerだと困るものがあります。身近なところだとOpenStackとか。 そういうものは頑張ってNetplan.io+systemd-networkdで頑張りましょう。というか、次のOpenStackはUbuntu 18.04LTSでやることになるだろうから、どうするのかな。ネットワーク周り。

おまけ: 少しでもNetplan.io+systemd-networkdをラクに設定する

Ubuntu Server 18.04ではインストーラーが刷新され、Live Server Installerが提供されています。このインストーラーはデフォルトでIPアドレスの設定をインストール時にできるので、あらかじめ固定IPアドレスを設定してしまえばYAMLをいじる必要がなくなるのでいいんじゃないかなと思います。定義すればYAMLファイルの雛形ができるので、IPアドレスをちょっと書き換えたりとかもラクになるはずです。

f:id:ytooyama:20180720002151p:plain

OpenStackでMinimal Ubuntuをつかってみた

前回、LXDでMinimalなUbuntuイメージを利用しました。

ytooyama.hatenadiary.jp

今回はOpenStackで使ってみました。

イメージサイズの比較

まず普通のイメージですが、「Ubuntu Cloud Image」からダウンロードできます。

Ubuntu 16.04のイメージは279MB、Ubuntu 18.04のイメージは321MB(7/13/2018時点)だそうです。

一方、発表のあったクラウド向けのUbuntu Minimal Imageは、現在はUbuntu 16.04と18.04のイメージが以下からダウンロード可能です。 Ubuntu 16.04のイメージは149MB、同18.04のイメージは157MBです。

標準のクラウドイメージと比べるとUbuntu 16.04は130MB、Ubuntu 18.04は164MBのダイエットに成功しています。

OpenStackのクラウドイメージとして使ってみた

サイズ比較

Ubuntu 16.04は次の通り。起動するとrootとして865MB消費した状態で起動します。 カーネルlinux-image-genericと同じものです。Ubuntu 16.04の場合、標準カーネルは4.4系で、物理マシンなどにUbuntu Server 16.04をインストールした時のカーネルと同じものを使って起動します。

$ df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/vda1      ext4      3.9G  865M  3.0G  23% /

$ uname -srv
Linux 4.4.0-121-generic #145-Ubuntu SMP Fri Apr 13 13:47:23 UTC 2018

一方Ubuntu Minimal 16.04。おおよそ400MBカットです。この差は大きいですね。 イメージサイズが小さい方がインスタンスの起動に要する時間は少なくてすみますし、実際の消費サイズも同様に小さいほうがシステムに優しいので良いはずです。

Ubuntu Minimalに含まれるカーネルは標準のものではなく、クラウド利用にチューニングされたものが使われます。

$ df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/root      ext4      3.9G  463M  3.4G  12% /

$ uname -srv
Linux 4.4.0-1029-kvm #34-Ubuntu SMP Thu Jun 14 10:10:41 UTC 2018

使い勝手

特にそこまで変わりません。せいぜいエディターを入れるか入れないか程度でしょうか。私だったらbusyboxを入れて終わり...でいいかなと思います。

Canonicalによると、エンタープライズ契約を結んでいる場合、通常のUbuntuと同様、Ubuntu Minimalについてもサポートをするようです。インスタンス起動もちょっとばかし速かった(気がする)ので、今後はUbuntu Minimalを使っていこうと思いました。

参考

Minimal - Ubuntu Wiki

LXDでMinimal Ubuntuをつかってみた

こんな記事を見たので、LXDで試しに使ってみました。 コンテナーでの比較なので、カーネルなにがしの利点は関係ありません。

news.mynavi.jp

Ubuntu Wikiにもまとめられていました。

https://wiki.ubuntu.com/Minimal

Ubuntu 18.04にLXDをインストールして、lxd initコマンドで初期設定済みである前提とします。 LXDは3.0.1/stableをつかいました。

それぞれ次のようにコマンドを実行しました。

Ubuntu
$ lxc launch ubuntu:bionic first

Ubuntu-minimal
$ lxc remote add --protocol simplestreams ubuntu-minimal https://cloud-images.ubuntu.com/minimal/releases/
$ lxc launch ubuntu-minimal:bionic second

イメージサイズは次の通りでした。その差は80.38MB。 小さい方がイメージのインポート、更新に要する時間を削減できます。思ったより標準イメージも小さいですね。

$ lxc image list -c ds
+-----------------------------------------------------+----------+
|                     DESCRIPTION                     |   SIZE   |
+-----------------------------------------------------+----------+
| ubuntu 18.04 LTS amd64 (minimal release) (20180705) | 92.76MB  |
+-----------------------------------------------------+----------+
| ubuntu 18.04 LTS amd64 (release) (20180617)         | 173.14MB |
+-----------------------------------------------------+----------+

両イメージでもbashを利用可能のようです。ただし、Minimal Imageにはvimbusyboxはインストールされていませんでした。 まあ、テキストファイルの生成はechoで頑張ればなんとか。

$ lxc exec first bash
root@first:~# which vim busybox
/usr/bin/vim
/bin/busybox

$ lxc exec second bash
root@second:~# which vim busybox
root@second:~#

Minimal imageはロケールとして「en_US.utf8」が削られているようです。manパッケージもインストールされていませんでした。

$ lxc exec first -- locale -a
C
C.UTF-8
POSIX
en_US.utf8

$ lxc exec second -- locale -a
C
C.UTF-8
POSIX

$ lxc exec first -- man --version
man 2.8.3
$ lxc exec second -- man --version

Ubuntu Server 18.04でVanillaカーネルのビルド

Ubuntu Server 18.04では割と新しいカーネル 4.15が利用できます。 今回は諸事情でディストリビューション標準のカーネルではなく、独自ビルドしたカーネルを使うことにしました。

VanillaカーネルとはLinuxディストリビューションがメンテナンスするカーネルではなく、Linux kernelコミュニティーがリリースしたバージョンのカーネルを指します。

The Linux Kernel Archives

いくつかのバージョンをダウンロードできますが、今回はサポート期間が長い4.14系のバージョン4.14.52をビルドすることにしました。ちなみに同じ方法で別のバージョンのパッケージを作成することも可能です。

まず、(カーネル以外の)システムの更新をおこないます。

% sudo apt update
% sudo apt upgrade

カーネルビルドに必要なパッケージを入れます。

% sudo apt install fakeroot kernel-package git libssl-dev bison flex

ソースをtarballで取得します。

% wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.14.52.tar.xz
% tar xf /linux-4.14.52.tar.xz
% cd linux-4.14.52

今のkernel configをベースにするための設定を行います。

% cp /boot/config-$(uname -r) .config
% yes "" | make oldconfig

ビルドします。ビルドに要する時間はビルドマシンの性能によります。40Core、64GBメモリー、256GB SSDなサーバーで1時間程度でした。

% fakeroot make-kpkg --initrd --append-to-version=-mybuild kernel-image kernel-headers -j $(getconf _NPROCESSORS_ONLN)

ビルドしたdebパッケージをインストールします。再起動すると新しいカーネルUbuntuを起動できます。

% sudo dpkg -i linux-headers-4.14.52-mybuild_4.14.52-mybuild-10.00.Custom_amd64.deb
% sudo dpkg -i linux-image-4.14.52-mybuild_4.14.52-mybuild-10.00.Custom_amd64.deb
% sudo update-grub && sudo reboot

昔と比べたらマシンの性能も良くなったし、ビルドツールも便利なものが多くなったので割と簡単でした。 これで好きなバージョンのカーネルUbuntu Serverで使えますね。

ちなみにUbuntu Server 18.04でビルドしたカーネルですが、Ubuntu Server 16.04.4でも一応起動するみたいです。ただ、流石にUbuntu Server 14.04.xでは無理でした。

カーネルのバージョンを固定する方法は、以前書きましたので以下を参考にどうぞ。

ytooyama.hatenadiary.jp

Ubuntu 14.04以降のGRUB2でデフォルトのLinuxカーネルを固定する

Ubuntuカーネルを固定する方法を調べたら次のような情報を見つけました。

sweng.web.fc2.com

しかしこれ、Ubuntu 12.04くらいの時の頃の情報で、現在のバージョンではこの方法ではうまくいかないようです。 こういう仕様変更が多いところがUbuntuの難しいところですね。

とりあえず難しい話は置いておいて、参考サイトのように試しに設定を書き換えてみます。

まずは情報収集。現在のシステムにインストールされたカーネルを確認します。 一部省略した実行結果を以下に書き出してみます。

$ grep menuentry /boot/grub/grub.cfg
...
menuentry 'Ubuntu'
...
submenu 'Advanced options for Ubuntu' $menuentry_id_option 'gnulinux-advanced-9d97e78e-777f-11e8-8fb4-001c42dec035' {
    menuentry 'Ubuntu, with Linux 4.17.2-patched' --class ubuntu --class gnu-linux --class gnu --class os 
$menuentry_id_option 'gnulinux-4.17.2-patched-advanced-9d97e78e-777f-11e8-8fb4-001c42dec035' {
    menuentry 'Ubuntu, with Linux 4.17.2-patched (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.17.2-patched-recovery-9d97e78e-777f-11e8-8fb4-001c42dec035' {
    menuentry 'Ubuntu, with Linux 4.15.0-23-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.15.0-23-generic-advanced-9d97e78e-777f-11e8-8fb4-001c42dec035' {
    menuentry 'Ubuntu, with Linux 4.15.0-23-generic (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.15.0-23-generic-recovery-9d97e78e-777f-11e8-8fb4-001c42dec035' {
...

ちょっと見づらいので、必要な部分のみ抜き出してみます。

二つのバージョンのカーネルがインストールされており、通常のカーネルリカバリーモードを呼び出すカーネルが導入されていることがわかります。

そこで、早速設定を書き換えました。「Ubuntu, with Linux 4.15.0-23-generic」をデフォルトにしたかったので次のように設定しました。GRUB2の設定を変更した後はsudo update-grubコマンドの実行が必要です。

$ sudo vi /etc/default/grub

GRUB_DEFAULT="Ubuntu, with Linux 4.15.0-23-generic"

$ sudo update-grub

これで終わるはずだったのですが、次のようなメッセージが表示されました。

Warning: Please don't use old title `Ubuntu, with Linux 4.15.0-23-generic' for GRUB_DEFAULT, use `Advanced options for Ubuntu>Ubuntu, with Linux 4.15.0-23-generic' (for versions before 2.00) or `gnulinux-advanced-87573e56-43ce-4235-b3e6-e28007edff2e>gnulinux-4.15.0-23-generic-advanced-87573e56-43ce-4235-b3e6-e28007edff2e' (for 2.00 or later)
done

doneと表示されているしエラーではなく警告だったので問題ないだろうと思い、Ubuntuを再起動してみました。しかし、予測とは異なり「Ubuntu, with Linux 4.17.2-patched」を読み込んでUbuntuが起動してしまいました。

次に、GRUB_DEFAULTの設定をこう書き変えて、再起動してみました。やはり、この方法でも「Ubuntu, with Linux 4.17.2-patched」を読み込んでUbuntuが起動してしまいました。

$ sudo vi /etc/default/grub

GRUB_DEFAULT="Advanced options for Ubuntu>Ubuntu, with Linux 4.15.0-23-generic"

$ sudo update-grub

結局、(for 2.00 or later)の方法として書かれていた方法でデフォルトカーネルを指定する必要がありました。

$ sudo vi /etc/default/grub

GRUB_DEFAULT="gnulinux-advanced-87573e56-43ce-4235-b3e6-e28007edff2e>gnulinux-4.15.0-23-generic-advanced-87573e56-43ce-4235-b3e6-e28007edff2e"

$ sudo update-grub

ちょっと長いですね。コピペじゃないと辛そうです。

GRUB2の2.0.0以降を採用しているUbuntuは現在一般に使われるバージョン全てが該当します。Ubuntu 14.04や16.04、18.04といったLTSバージョンやStandard版の17.10なども同様です。

一方、FedoraとかRHELCentOSだとこんな感じで番号で指定できるんですよね。それと比べると新しいカーネルがインストールされようがその影響がなく目的のカーネルを指定できて良いけどちょっと煩わしい感じですね。

qiita.com

以上、「Ubuntu 14.04以降のGRUB2でデフォルトのLinuxカーネルを固定する」方法でした。

macOSとMacTeXでTeX文書入門(その2) BasicTeXを使う

去年、次のようなブログ記事を書きました。

ytooyama.hatenadiary.jp

今年の4月にTeX Live 2018がリリースされたので、macOSTeX環境をアップグレードしようと思いました。 macOSの場合はMacTeXという、TeX Live をベースにしたmacOS専用のTeXディストリビューションが用意されています。 去年はMacTeXのバージョン2017をインストールしましたが、インストールしたアプリケーションのうちつかっていたのはほんの僅かなので、今年は最小インストール用のBasicTeXの方を使ってみます。

  • ダウンロードは公式サイトから行います。MacTeXもこちらのページのリンクからダウンロードできます。

あとは次の順番でインストール(およびコマンド実行)していくだけです。

  • BasicTeX
  • sudo tlmgr install collection-langjapanese collection-luatex collection-latexextra lm-math
  • brew install pandoc (Homebrewを使う場合)

  • sudo tlmgr update --self --all (オプション/アップデート)

オプションでTeXShopも入れてみました。

ここまでセットアップすると、去年書いたことと同様の作業が可能になります。

ytooyama.hatenadiary.jp

CoreOSのrktをUbuntuで触ってみる

Linuxでコンテナーというと、まずDockerが連想されると思います。ついでLinux Container(LXC)かなと。 最近その他のコンテナー技術について調査していまして、今回取り上げるCoreOS社が開発しているrktやDocker社が提供するrunCなどを調べているところです。

Dockerとrktの違い、誕生の背景については次によくまとまっていました。

https://qiita.com/datake914/items/a61a1aead43ffa058da9qiita.com

簡単にまとめると次の通りです。

  • Dockerはクライアント+サーバー型
  • Dockerデーモンがroot権限で稼働し続ける必要があり、セキュアではない
  • rktはクライアントから直接コンテナーを起動できる

というのが、CoreOS社の言い分だそうです。

どうやって使うのか

rktを最も簡単に使う方法は、CoreOSをインストールして使うという方法です。現在のCoreOSにはDockerとrktが含まれるので両方を使ってみて、比較をすると楽しいかもしれません。

2018年4月にリリースされたUbuntu 18.04 LTSでもrktをインストールすることができます。 ちなみにVirtualBoxVMの中でも結構サクッと動きます。

% sudo apt install rkt

コンテナーの起動方法は次のドキュメントにまとまっています。

rktではさらに、コンテナーにインストールするイメージとしてDockerのイメージを利用することもできます。 Docker Hubで公開されているイメージの多くを利用できるようです。 デフォルトではhostモードで起動するようです。

% sudo rkt run --insecure-options=image docker://nginx
% sudo rkt list
UUID     APP         IMAGE NAME                      STATE      CREATED         STARTED      NETWORKS
bc178c7e  nginx   registry-1.docker.io/library/nginx:latest  running  5 minutes ago  5 minutes ago  default:ip4=172.16.28.2

NGINXのデフォルトページをcurlで出力してみましょう。

% curl -I http://172.16.28.2
HTTP/1.1 200 OK
Server: nginx/1.13.12
Date: Wed, 23 May 2018 02:37:20 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Mon, 09 Apr 2018 16:01:09 GMT
Connection: keep-alive
ETag: "5acb8e45-264"
Accept-Ranges: bytes

手元のPCのブラウザーで閲覧したい場合は、Trying out rktに書かれているようにルーティングを設定します。

コンテナーにログインする場合、Dockerではdocker execコマンドを使いますが、rktではrkt enterコマンドを使います。

% sudo rkt enter <コンテナーのUUID>
enter: no command specified, assuming "/bin/bash"
root@rkt-4f104344-f8a3-4319-b6eb-24bee362c0dd:/#

いらなくなったコンテナーはrkt rmコマンドで削除できます。

rkt:~$ sudo rkt rm <コンテナーのUUID>

こんな感じで割と簡単に使うことができました。Dockerと比べるとクライアントだけでコンテナーを動かせるので、サーバーOSには無駄なパッケージをインストールすることなく、最低限のパッケージを入れておきたい私のようなタイプにはオススメのコンテナー技術かもしれません。

ちなみにDockerに慣れていれば難なく利用できると思います。

追記

CentOS 7でもrktが使えるようなのですが、以下のリポジトリーを追加して試してみたところ、systemdが標準パッケージよりも新しいものが入ってしまい、正常に起動しませんでした。現在はstableではないので、もう少し経ってからもう一度試してみたいと思います。

【GW自由研究】CUDAをインストールするときに必要なこと/MNISTを動かしてみる

CUDAとは

CUDAとは、NVIDIAが開発・提供している、GPU向けの汎用並列コンピューティングプラットフォームおよび プログラミングモデルを提供する開発環境およびライブラリーのことです。

インストールに必要なこと

CUDAを活用するには対応するNVIDIA GPUが必要です。

CUDAをインストールするにはGPUカードに対応する、CUDAと互換性のあるGPUドライバーおよび、 それらをインストールできるOSが必要です。

CUDAと互換性のあるGPUドライバーが入らないと、GPUリソースを利用できません。 現在最新版のCUDA 9.1を使う場合はnvidia-390をインストールする必要があります。 このnvidia-390バージョンで認識するGPUカードが必要になります。

情報源

最新版のダウンロード

NVIDIA GPU Driver一覧で、GPUカードに必要なドライバーのバージョンを確認

公式の一覧でcompute capabilityを確認できる

レガシーGPU 旧CUDAをサポートしていたGPU。このリストに出ているGPUはCUDA 9.1では使えない。

参考情報

英語版Wikipediaはかなり詳しい情報がまとまっている。参考情報として。

実行環境を理解する

家にあったHPE ML110 G6を使いました。久しぶりに使いました。 メインストレージがHDDだし、CPUもCeleron(R) G1101なので遅いです。 CPUやストレージが速いと、最後に示した結果より差の開きは小さいと思います。

GPUは対応するGPU一覧からGeForce GTX 1050をセレクトしました。 (とりあえずメモリー2GBのモデルでも動きましたが、 本格的に使うにはもう少しメモリーサイズの大きいものを採用したほうがいいかもしれません。)

CUDA 8.x は compute capability 2.0以上 CUDA 9.x は compute capability 3.0以上 が必要だそうです。GPUのcompute capabilityはcuda-gpusで確認できます。

調べた結果GeForce GTX 1050のcompute capabilityは6.1なので、しばらく大丈夫そうです。

GPU Driverを調べると、390.48(nvidia-390)以降をインストールすれば良いことがわかりました。

CUDA 9.1をインストール後、せっかくなのでChainer、CuPyをインストールしてMNISTを動かしてみます。 インストールの容易さから、Chainerを選択しました。

マシンにOSのインストール

今回はCUDA 9.1を動かすので対応するOSの中から、Ubuntu 16.04を選択しました。 Ubuntu Server 16.04.4をインストールして、事前にアップデート、最新のカーネルで起動した状態にします。

CUDAをインストール

基本的に公式の手順に従ってインストールします。

% wget http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1604/x86_64/cuda-repo-ubuntu1604_9.1.85-1_amd64.deb
% sudo apt-key adv --fetch-keys http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1604/x86_64/7fa2af80.pub
% sudo dpkg -i cuda-repo-ubuntu1604_9.1.85-1_amd64.deb 

% sudo apt-get install cuda-9-1 nvidia-390
...
% nvidia-smi
Wed May  2 20:36:36 2018       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 390.30                 Driver Version: 390.30                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 1050    Off  | 00000000:01:00.0 Off |                  N/A |
| 40%   32C    P0    N/A /  75W |      0MiB /  2000MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

Python3とChainer,CuPyをインストール

ChainerでGPUを扱うには、1.3未満はPyCuda、1.3以降はCuPyを利用する。 今回インストールしたChainerは4.0なので、CuPyをインストールします。

% sudo apt install python3 python3-pip
% pip3 install chainer cupy

MNISTテスト

MNISTのテストプログラムはChainerのソースにサンプルが用意されているのでそれを使います。 -g0をつけるとGPUモードで解析処理を行ってくれます。

% wget https://github.com/chainer/chainer/archive/v4.0.0.tar.gz 
% tar zvxf v4.0.0.tar.gz
% python3 chainer-4.0.0/examples/mnist/train_mnist.py         #cpuモードで処理
% python3 chainer-4.0.0/examples/mnist/train_mnist.py -g0  #gpuモードで処理

結果、処理時間はCPUモードでは17分、GPU では1分40秒程度でした。

Ubuntu 18.04 LTSがリリースされた

2018年4月27日、Ubuntu 18.04 LTSがリリースされた。このバージョンは長期サポート版であり、2023年4月までアップデートおよびCanonicalによるエンタープライズサポートの支援を受けることができる。

Ubuntu 18.04 Desktopの方はブログ記事とかニュース記事が色々出ると思うので、ここでは主にUbuntu 18.04 Serverの方を取り上げる。なお、私の愚痴が所々あるかもしれない。適当に流していただければ幸いである。

Linux Kernel 4.15

Linux Kernel 4.15ベースになった。Ubuntu 18.04は5年サポートであり、2023年までGAカーネルはこのバージョンがベースになる。 ただ、Linux Kernel本家のKernel 4.15の開発はすでに終了している。前LTSバージョンであったUbuntu 16.04はLinux Kernelの長期サポート版であったLinux Kernel 4.4ベースであったが、先が思いやられる。

というわけで私は、16.04 LTSはサポート終了ギリギリまで使うと思います。

いくつか「再起動するとKernel Panicに陥る」系のバグが報告されているので、既存環境のアップグレードやセットアップは事前に確認が必要と思われる。

https://bugs.launchpad.net/ubuntu?field.searchtext=bionic+kernel+panic&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=

なんで素直にlongtermの4.14.xカーネルを採用しなかったんだろうか。 ちなみにカーネルとベースカーネルのバージョンは、引き続き次のコマンドで確認できる。

$ cat /proc/version_signature
Ubuntu 4.15.0-20.21-generic 4.15.17

いくつかの問題は4.15.18で修正されているが、EOLなのには変わりはない。

デスクトップ版の主な変更

Ubuntu Desktopの標準のデスクトップ環境がGNOMEにもどった。詳細はここでは述べないが、Ubuntu 18.04 Desktopのインストーラーも刷新され、最小インストールモードが実装された。Ubuntuのデスクトップ環境とブラウザーがあればいい人に最適なセットアップメニューだと思われる。

Xサーバーが再び標準になった。Waylandについては次の20.04 LTSで標準化に向けて開発が行われるらしい。

また、Ubuntu Desktopでは32bit版の提供が行われなくなった。Ubuntuの別のフレーバーでは引き続き32bit版も提供されるので、あえて32bit版が必要であれば、Lubuntuなどを検討すると良い。

Server installerの変更

Ubuntu Serverのインストーラーが変更され、旧来のDebianインストーラーからオリジナルのものに変更になった。セットアップ中にバックグラウンドでインストールが行われるので、結果的にインストール時間を短縮できる。

このインストーラーは良い点が多いが、どうやらインストール時にインターネット接続が必須になった。これまではインターネット接続できない環境では最小セットアップができたが、そのような方法は取れなくなる。

ちなみに旧来のDebianインストーラーが良ければ、Minimal ISO(インターネット接続必須)旧来のインストーラーが利用できる。

netplan.io

ネットワーク設定はnetplan.ioが採用された。使い方はnetplan.ioを参考に。設定例はexampleに書かれている。YAML形式で設定を記述し、「sudo netplan apply」コマンドで設定を適用する。コマンドを実行するとすぐ設定が反映されるので、リモートアクセスする時は注意。

ちなみに標準のUbuntu Server 18.04のインストーラーは、内部的にCloud-initが使われており起動毎にCloud-initの処理が走る。従って、次の設定ファイルにIPアドレスを記述すると良い。

  • /etc/netplan/50-cloud-init.yaml

Minimal ISOを使ってインストールした場合は、17.10の頃と同じ設定ファイルにIPアドレスなど記述する。

  • /etc/netplan/01-netcfg.yaml

設定ファイルのパスが異なるの、勘弁してほしい。

記述の仕方はどちらでも一緒。/etc/network/interfacesというファイルは残っているが、次のようなことが書かれているだけだ。

# ifupdown has been replaced by netplan(5) on this system.  See
# /etc/netplan for current configuration.
# To re-enable ifupdown on this system, you can run:
#    sudo apt install ifupdown

ifupdownをインストールすれば、引き続き旧来の設定方法でIPアドレスの設定ができるようだ。

LXD 3.0

LXDのクラスタリングNVIDIA GPUのパススルー、ポートリダイレクトなどをサポートした。 私的には2個目が注目のポイントです。

QEMU 2.11.1/libvirt 4.0/Open vSwitch 2.9

KVM関連のバージョンがかなり上がった。 OVSも2.9が利用できるようになった。

MAAS

MAASは2.4がバンドルされた。ただしリリース初期はBeta版である。いずれ正式版が利用可能になる。 なお、snapコマンドを使ってMAASをインストールすることもできる。

Juju

Ubuntu 18.04向けのJujuはdebパッケージは用意されていない。snapパッケージをインストールする必要がある。

OpenStack Queens

Ubuntu 18.04はOpenStack Queensをサポートする。このバージョンはUbuntu 18.04のサポート期間終了まで5年間サポートが行われ、必要に応じてCanonicalのサポートを受けられる。

QueensではGPU対応の機能がいくつか機能追加されている。

Python

Python 2は2.7.15-rc1、Python3は3.6.5が提供される。デフォルトでPython 2はインストールされず、Python3はインストール済みになっている。Python2のパッケージはpythonである。これ以降のバージョンについてはPPAで提供されると思われる。

Go

Go言語は1.10がデフォルトで提供される。これ以降のバージョンについてはPPAで提供されると思われる。

OpenJDK

18.04リリースではOpenJDK 10がデフォルトのJRE/JDKになった。

macOSにAnsibleを入れる

先ほどこんなことを書きました。

ytooyama.hatenadiary.jp

次はmacOSにAnsibleを入れようと思ったのですが、HomebrewのFormulaで入れるとPython2が必要なので、python@2というFormulaが追加されます。まとめると次のバージョンがシステムに存在する状態になります。

  • macOSにインストール済みのpython (2.7.10)
  • Homebrewでインストールされたpython (2.7.14)

以前のバージョンのHomebrewでpython Formulaが追加されていると、Homebrew 1.6への更新でpython FormulaはPython 3.xに更新されます。そこら辺の事情は以下のブログ記事にまとまっています。

applech2.com

applech2.com

つまりこうなります。

  • macOSにインストール済みのpython (2.7.10)
  • Homebrewでインストールされたpython@2 (2.7.14)
  • Homebrewでインストールされたpython , python@3 (3.6.5)

そして言い忘れていましたが、私はパッケージ版のPython 3をインストールしています。 つまり、全部で4つのバージョンのPythonがインストールされた状態になっています。

「Homebrewでインストールされたpython (2.7.14)」はHomebrew版Ansibleを使う限り必要ですし、python Formulaが必要なFormulaをインストールしようとした場合はHomebrewがインストールしてしまうので、ごちゃごちゃした状態は解決できません。Pythonを呼び出すたびに、「お前はどこの子のPythonだ」という状態が続く感じです。 だから、本来はpyenvとか使うんでしょうね。

qiita.com

macOSにAnsibleをインストールする

brew install ansibleを実行するだけで簡単に導入できていいのですが、Ansible公式の手順に従って、pipでインストールしてみました。この方法でインストールしたAnsibleはPython 3.6で動くので、Homebrew版のPythonは不要になります。といわけで不要なバージョンのPythonも削除できたし、以前書いたpipの問題も解決できてすっきりしました。

% brew uninstall ansible python@2 python
% pip3 install ansible 

% ansible --version
ansible 2.5.1
  config file = None
  configured module search path = ['/Users/ytooyama/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/ansible
  executable location = /Library/Frameworks/Python.framework/Versions/3.6/bin/ansible
  python version = 3.6.5 (v3.6.5:f59c0932b4, Mar 28 2018, 05:52:31) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)]

% pip -V
pip 10.0.1 from /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/pip (python 3.6)
% pip3 -V
pip 10.0.1 from /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/pip (python 3.6)