ytooyamaのブログ

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

Ubuntu 18.04.1を新規インストールするときはapt lineに注意しよう

Ubuntu 18.04.1が7月27日にリリースされたので、早速インストールしてみました。 変更点はこちらにまとまっています。

デスクトップ版はまだインストールしていませんが、サーバー版はインストーラーでソフトウェアRAIDを組めたり、LVMを使うか否か選択するだけで簡単にストレージをセットアップできるようになったり、NICのBondingができるようになったりと改良が施されていました。

Ubuntu Server 18.04.1のインストール後に、利用できるパッケージのバージョンをいろいろ調べようとしたのですが、あれもこれも見つからずはてなマークがたくさん浮かびましたが、原因がわかりました。

これです。 mainリポジトリーしか有効になってなかった!

~$ cat /etc/apt/sources.list
deb http://archive.ubuntu.com/ubuntu bionic main
deb http://archive.ubuntu.com/ubuntu bionic-security main
deb http://archive.ubuntu.com/ubuntu bionic-updates main

ちなみにUbuntu 18.04.0からUbuntu 18.04.1にアップデートした場合は、Ubuntu 18.04.0のsources.listが使われるので特に問題はありません。Ubuntu 18.04.1を新規でインストールしたら、デフォルトの設定がこうなっていました。

Ubuntuにはmain、restricted、universe、multiverseというリポジトリーが用意されています。 この中でmainとuniverseにはフリーソフトウェアが、restrictedやmultiverseには制限付きのソフトウェアが主に収録されています。

mainとrestrictedはCanonicalがメンテナンスを行うパッケージが管理されています。universeはコミュニティーのメンバーが主にボランティアでメンテナンスしているもの、multiverseはボランティアもしくはソフトウェアの開発元がメンテナンスするパッケージが集められています。

UbuntuDebianベースのディストリビューションです。当然ながら多くのオープンソースのパッケージはuniverseに公開されています。パッケージ検索してみると、universeで提供されるパッケージが多いことがわかります。

リポジトリーについてはこちらをご覧ください。

ascii.jp

それに加えてUbuntuにはbackportsとpartnerというリポジトリーもあるのですが、これについては今回説明を省きます(UbuntuリポジトリーについてはWikipediaのUbuntuの記事も参考になります)。

これら、複数あるリポジトリーの中のmainしかデフォルトでは設定されていません。そのため、多くのパッケージが見つからなかったというわけです。

Ubuntu 18.04以降ではsnapdを使って欲しいというCanonicalからのメッセージなのかもしれません。 けれどももし、他のリポジトリーのパッケージも使いたいということであれば、次のようにリポジトリーを追加してください。

deb http://archive.ubuntu.com/ubuntu bionic main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu bionic-security main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu bionic-updates main restricted universe multiverse

mainリポジトリーだけで別に困らないのであればデフォルトのまま運用でもいいですし、フリーソフトウェアだけ使いたいならmainとuniverseだけを指定することもできますが、結局は使いたいパッケージがどこで配布されているかで必要なリポジトリーを設定すればいいと思います。debパッケージにこだわらなければ、snapパッケージを使う手もあります。

snapcraft.io

リリースノートにも記載がありますが、Ubuntu 16.04.xからのアップグレードは7月中には開始される予定です。いつものことですが変更点が16.10,17.04,17.10そして18.04と4リリース分の違いがあり、かなり変更点があります。アップグレードに失敗した時のために、必要なデータはバックアップを取ってから実施することをおすすめします。同じような環境を作って試すのもいいと思います。

最近のバージョンのSafariでデフォルトフォントとサイズを指定する

大抵のブラウザーにはデフォルトのフォントとサイズを指定する設定があります。これらのフォントはHTMLファイルやCSSなどでフォントやフォントサイズが指定されていない場合、ここで設定したフォントとフォントサイズでコンテンツを表示します。

現在のバージョンのSafariには、デフォルトのフォントとサイズを指定する設定はありません。そのため、何も設定していない場合、上記のようなコンテンツを表示した場合、Safariでは明朝体で日本語が表示されます。

これをゴシック体や特定のフォントを使って表示することができます。CSSファイルを作成してSafariでそのCSSを読み込むように設定すれば、定義した設定をSafariに行うことができます。

f:id:ytooyama:20180724214721p:plain

これらの方法は「Safari 明朝体フォント」などのキーワードでWeb検索すると、デフォルトのフォントを指定する方法は多く見つかります。例えばこのような感じです。

a:link{text-decoration:none !important;}
a:visited{text-decoration:none !important;}
a:hover {text-decoration:underline !important;}
    body {
        font-family: 'SourceHanSansJP-Normal';
    }

デフォルトのフォントサイズは上記のコードに次のように一行追加するだけでうまくいきました。

a:link{text-decoration:none !important;}
a:visited{text-decoration:none !important;}
a:hover {text-decoration:underline !important;}
    body {
        font-size: 14px;
        font-family: 'SourceHanSansJP-Normal';
    }

次のHTMLファイルを作成して、Safariドラッグ&ドロップすると確認できます。上記のCSSファイルを変更後は、一度設定を開いて読み込み直してください。レンダリング結果が変わるのが確認できます。font-size: 14px;のサイズを小さくしてSafariCSSを再読み込みすると、そのサイズでHTMLが表示されます。

<html>
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
  <h1>Safariのデフォルトフォントを変更</h1>
    <p>Safariで使用するフォントが指定されていないページにアクセスすると、「明朝体」フォントで表示されます。</p>
    <p><b>CSSファイル</b>で使用するフォントを定義して設定を行うと、フォントが指定されていないページを指定したフォントで表示することができます。</p>
</body>
</html>

フォントサイズのイメージを以下に貼り付けます。

14px

f:id:ytooyama:20180724215616p:plain:w240

8px

f:id:ytooyama:20180724215627p:plain:w240

さて、font-familyで指定するフォント名ですが、Font Bookでフォントを選んでフォントの情報に含まれる「PostScript名」を指定すれば良いです。

f:id:ytooyama:20180724220532p:plain

macOS High SierraでUSBインストーラーを作ろうとして困った話

macOSでISOイメージからUSBインストーラーを作る時、だいたい以下のような手順で作成していました。 普段はEasy2Bootを使っていたので、macOSインストーラーを作るのは久しぶりでした。

・デバイス番号確認 
$ diskutil list

・フォーマット
$ diskutil eraseDisk FAT32 MEMISO MBR /dev/disk2

・アンマウント
$ diskutil unmountDisk /dev/disk2

・書き込み
$ sudo dd if=CentOS-7.5-x86_64-Minimal-1804.iso of=/dev/disk2 bs=1m

そして作成したUSBメモリーからインストーラーを起動するわけですが、何らかのよくわからないエラーが表示され、うまく起動してくれませんでした。ISOイメージのダウンロードに失敗したかと思いハッシュ値を確認したのですが全く一緒です。念のためにUbuntuインストーラーも作ってみましたが出てくるエラーこそ違うものの、同じくインストーラーが起動しませんでした。ちなみにSierraまではこの方法でうまくUSBブートするディスクを作れていました。High Sierraのddのバクなのかな。

調べると、/dev/diskXのところを/dev/rdiskXと指定してもイメージを作れるらしいことを見つけました。たしかに、/dev/diskXのを指定するよりもずっと短時間で作成できます。もっと早く知っときゃ良かった。

つまり、次のコマンドでイメージを書き込みできます。

$ sudo dd if=CentOS-7.5-x86_64-Minimal-1804.iso of=/dev/rdisk2 bs=1m

作成したイメージでCentOS 7.5のインストーラーを起動でき、セットアップして正常にOSを起動できました。

ところがどっこいUbuntu Server 18.04のインストーラーは起動せず

同じ方法でUbuntu Server 18.04のインストーラーを作りますが、/dev/rdiskXを指定してもダメでした。 そこで公式のLiveインストーラーではなくdebインストーラーをイメージソースとして作ってみました。

そちらはうまく起動できました。そのあと試しにそのUSBインストーラーを使ってインストールしてみました。特に問題なく、インストール完了です。

ところがどっこいUbuntu Server 18.04は起動せず

インストールが終わって再起動しました。残念ながらカーネルのブート途中でカーネルパニックが発生してしまいました。

この問題はUbuntu Server 18.04をインストールしたいくつかのハードウェアで起こっている問題です。カーネルパニックが起動時に発生したり、シャットダウン時に正常に電源断が行われずにハードウェア強制リブートが行われてしまったりするという問題がいくつか報告されています。ちなみにUbuntu Desktop 18.04ではあまり聞いたことはない事象です。

Canonicalはなんとかしようと現在もカーネルに修正を加えているので、いずれ不具合なく動作するようになるかもしれませんし、しないかもしれません(後者の場合は詳細なログとバグ報告が必要ですね)。カーネルパニックが頻発する問題はLinuxカーネル4.14までは起きていませんでした。Linuxカーネル4.15の途中のRC版から発生するようになり、最近のLinuxカーネルUbuntu 18.04の組み合わせでも、ハードウェアによってはカーネルパニックとの死闘を繰り広げる必要があるようです。かなり深い問題のようです。

とりあえず手元の環境でうまく動かない場合はUbuntu 16.04は2021年まで利用できるので、問題が落ち着くまではUbuntu 16.04を使うといいと思います。 ちなみにUbuntu 16.04+Linuxカーネル4.15の組み合わせは概ね問題なく動くようです。

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ではないので、もう少し経ってからもう一度試してみたいと思います。