ytooyamaのブログ

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

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)

macOSにPython 3を入れる

macOSPython 3を入れるには色々方法があります。

まずはHomebrewとかMacPortsを使う方法。これはWeb検索すると一番よく出てくる方法だと思います。Qiitaとかで書かれているのはだいたい Homebrewを使う方法ですね。

で、ふたつめが公式のインストーラーを使う方法です。例えば以下からダウンロードするとか。

www.python.org

ただ、実はPython 3.6.5以降、macOS向けには二つのインストーラーが提供されるようになりました。

OS X 10.9以降の環境向けにTcl/Tk 8.6がバンドルされた64bit専用バージョンと、OS X 10.6以降の環境向けに提供された64bit/32bitハイブリットインストーラーです。OS X 10.6以降向けのバージョンは最近のmacOSでも動作しますが、このバージョンを動作させるにはTcl/Tk 8.5のインストールが別途必要です。というわけで多分OS X 10.9以降の環境向けの方をダウンロードした方がラクかと。

こちらからいずれのバージョンもダウンロードできます。

www.python.org

ちなみに公式のインストーラーでPython 3をインストールすると、次のような感じにパスが通りました。 pythonとpython2.7コマンドがmacOS標準のPython 2.7.10で、python3やpython3.6コマンドがパッケージでインストールしたバージョンのPythonが呼ばれます。

% which python
/usr/bin/python
% which python2.7
/usr/bin/python2.7
(macOS標準のPython)

% which python2
python2 not found
(python2という実行ファイルはなかった)

% which python3
/Library/Frameworks/Python.framework/Versions/3.6/bin/python3
% which pip3
/Library/Frameworks/Python.framework/Versions/3.6/bin/pip3
% which pip
/Library/Frameworks/Python.framework/Versions/3.6/bin/pip
(pipコマンドはPython3用)

最近のpip

最近pip listを実行すると次のような警告が現れます。

% pip3 list
DEPRECATION: The default format will switch to columns in the future. You can use --format=(legacy|columns) (or define a format=(legacy|columns) in your pip.conf under the [list] section) to disable this warning.
numpy (1.14.2)
paramiko (2.4.1)
pip (10.0.1)
...

なのでpip.confを作って設定します。

$ vi ${HOME}/.pip.conf
[list]
format=legacy

$ export PIP_CONFIG_FILE="${HOME}/.pip.conf"

ところが、最近のpipだと次のような警告が現れます。そのため、format=columnsを設定すれば警告は表示されなくなります。

% pip3 list
DEPRECATION: The legacy format has been deprecated and will be removed in the future.

こんな感じです。

% pip3 list      
Package      Version
------------ -------
asn1crypto   0.24.0 
bcrypt       3.1.4  
cffi         1.11.5 
cryptography 2.2.2  
idna         2.6    
mpmath       1.0.0  
numpy        1.14.1 
paramiko     2.4.0  
pip          10.0.1 
pyasn1       0.4.2  
pycparser    2.18   
PyNaCl       1.2.1  
setuptools   39.0.1 
six          1.11.0 
sympy        1.1.1 

pipでインストールしたパッケージの更新

--oでアップデートできる一覧を確認して、pip install -Uでパッケージをインストールすれば良いそうです。

% pip3 list --o               
Package  Version Latest Type 
-------- ------- ------ -----
numpy    1.14.1  1.14.2 wheel
paramiko 2.4.0   2.4.1  wheel

% pip3 install -U numpy paramiko
...
Successfully installed numpy-1.14.2 paramiko-2.4.1

macOSにインストールしたPythonを削除する

「フォルダをゴミ箱に入れて終わり」...ではないようです。

superuser.com

MavericksやYosemite利用中の環境に通常アップデートとしてHigh Sierraを提供開始した件を調べてみた

下記の記事を見たので、試してみました。

applech2.com

ちなみにEl Capitan以降のバージョンをインストールしている環境にはきていないようです。というわけで、はやくEl Capitan以降にアップグレードしましょう。

早速、実証

今回はOS X Yosemite 10.10.5をインストールしました。 これがYosemite 10.10.5のインストール直後にApp Storeを開いたところです。確かにHigh Sierraのアップグレードがアップデートと同系列に並べて表示されています。「アップグレード」なのに「アップデート」というボタンになっているところ、これが批判の元になっているのかな。

f:id:ytooyama:20180416000547p:plain:w360

「アップデートを隠す」を試してみた

試しにHigh Sierraのアップグレードの上で右クリックしました。「アップデートを隠す」というメニューが表示されましたが、何度実行しても隠れてくれません。通常のアップデートではこの方法でアップデートをスキップできます。今回はこの方法は使えないようです。

「High Sierra」以外のアップデートを適用してみた

とりあえずHigh Sierraのアップグレード以外のアップデートを適用してみました。

f:id:ytooyama:20180416000806p:plain:w360

アップデートを完了するには再起動が必要みたいです。ここで再起動すると「High Sierraのアップグレードまで行われたりするのでは?」と心配でしたが、とりあえず「セキュリティーアップデート2017-003 10.10.5」の横に表示された「再起動」ボタンを押してみます。アップデートが始まって、終わると再起動がかかりました。

f:id:ytooyama:20180416000851p:plain:w360

再起動後にOS Xにログインして、App Storeを開きました。iTunesのアップデートが表示されたので、同様に「アップデート」してみました。問題なく終わりました。

f:id:ytooyama:20180416001121p:plain:w360

考察

ボタンが紛らわしいという点を除いて、これを適用すべきか否かがわかる人はなんとか回避できると思います。仕事で使っているわけではなく、「パソコン」として使っているような初心者は、わざわざ古いOSを使い続けることはないと私は思います。

結果

というわけで、現状は「High Sierraのアップグレード」は表示されますが、「アップデート」ボタンを押さない限り「High Sierra」へのアップグレードはされないようです。何が何でも色々な手段(ポップアップを出したり、ウィンドウメッセージを出したり)を使ってWindows 7Windows 8.1Windows 10にしようとしたWindowsとは違いますね。

ちなみに何度も言いますが、はやくEl Capitan以降にアップグレードしましょう。今秋にはmacOS 10.14がリリースされます。El Capitanはそれまでの命ですので、できればSierra以降にすべきかと思います。移行の手間を考えれば。

Raspberry PiにNOOBSを使ってOSをセットアップした時にはまったこと

NOOBSは初心者向けのOSセットアップツールです。これまでRaspberry PiにOSのデータを書き込むにはddコマンドを使っていたのですが、ちょっと楽をしようとNOOBSを使ったら意外とはまったので、まとめておこうと思います。

まずはNOOBSをダウンロード。本家からだとちょっと遅いので、こちらのミラーからダウンロードすることもできます。

現行のRaspberry PiはSDカードをFAT32でフォーマットする必要があるため、ファイルシステムの種類をFAT32にしてフォーマットします。macOS High Sierraの場合は「MS-DOS (FAT)」を選択するとFAT32でフォーマットするようです。

ダウンロードしたNOOBSのZIPファイルを展開して、ファイルをすべてSDカードにコピーしたら、あとはSDカードをRaspberry Piに差し込んでブートするだけなのですが、なぜか起動してくれませんでした。最初は使おうとしていたRaspberry Piが壊れたのかなと思ったのですが、別のRaspberry Piに差し込んで起動しても同様に動きません。そこで公式のマニュアルを見ました。

www.raspberrypi.org

ドキュメントにSD AssociationのSD Formatterを使っている記述がありました。試しにダウンロードしてSD Formatterをフォーマットし、もう一度NOOBSをSDカードにコピーしてブートしてみたところ、うまくいきました。

Raspberry P 1も2も3も壊れてなくて、ただmacOSのディスクユーティリティが壊れていただけでした。 というわけで、フォーマットする時はSD AssociationのSD Formatterを使おうという話でした。

この問題、「またHigh Sierraか...」という話ではなくて、El Capitan以降の全バージョンのmacOSのディスクユーティリティでFAT32でフォーマットすると、よく失敗する気がします(SDカードだけでなく、USBメモリーなどでも)。ちなみにexFAT形式は特に問題ありません。「FAT32形式でフォーマットすると失敗することがある」と以前Public Betaを使っていた時にレポートはあげましたが、今の所治る気配はありません。

永遠に続くSending build context to Docker daemon

Dockerイメージを作ろうと、Docker for Macを入れた環境でdocker buildをしたら次のようなエラーが表示されました。 出力を見る限り、Docker daemonにどんどん何かを送っているようです。

下記は4.445GB程度を転送していた時の出力のコピペですが、実際はどんどんカウントアップされており、同時にシステムディスクの空き容量がどんどん減少していきました。とりあえずCTRL + Cで中止しました。

% docker build -t ytooyama/ubuntu-utils . 
ERRO[0010] Can't add file /Users/ytooyama/.gnupg/S.gpg-agent to tar: archive/tar: sockets not supported
ERRO[0010] Can't add file /Users/ytooyama/.gnupg/S.gpg-agent.browser to tar: archive/tar: sockets not supported
ERRO[0010] Can't add file /Users/ytooyama/.gnupg/S.gpg-agent.extra to tar: archive/tar: sockets not supported
ERRO[0010] Can't add file /Users/ytooyama/.gnupg/S.gpg-agent.ssh to tar: archive/tar: sockets not supported
Sending build context to Docker daemon  4.445GB

最初はmacOS固有のgnupg周りの問題かなと思ったのですが、いくら検索してもズバリといった情報は見つかりませんでした。そこで検索するキーワードをちょっと変えたところ、次のような情報を見つけました。

beniyama.hatenablog.jp

どうやら、Dockerファイルをホームディレクトリーにおいてdocker buildを実行したため、DockerクライアントからDocker daemonに対してホームディレクトリー配下のファイルを一所懸命転送していたようです。というわけで、~/working/dockerみたいなディレクトリーを掘って、そこにDockerfile「だけ」をおき、docker buildを実行してことなきを得ました。

その時に作ったのがこれです。作ったDockerイメージってDocker Hubで共有できるので便利ですね。

RHEL7/Fedora 27でGlusterFSを利用する

GlusterFSについてはこちらを参照してください。

GlusterFS - Wikipedia

RHEL7/Fedora 27でGlusterFSを利用する方法を調べました。 基本的には次の情報が役立ちました。

GlusterFS - How to Install GlusterFS Server on CentOS 7 / RHEL 7 - YouTube

www.linuxhelp.com stackoverflow.com

現在、RHEL7やCentOS7の場合はEPELリポジトリーは不要のようで、CentOS Storage SIG提供のパッケージを使うとうまく行きました(こちらにもそのリポジトリーを使うことと書かれています)。 こんなglusterfs.repoを用意してあとはインストールするだけです。

# vi /etc/yum.repos.d/glusterfs.repo
[glusterfs]
name = Glusterfs
baseurl = http://mirror.centos.org/centos-7/7/storage/x86_64/gluster-4.0/
gpgcheck = 0
enable = 1

Stable(3.10)版を使うには、baseurlとして以下を指定するとインストールできました。

Fedoraの場合は、以下にあるリポジトリーのパッケージを使います(repoファイルも提供されています)。3系のバージョンを使いたい場合は、Fedora 27の標準パッケージを使えます。ただしGlusterFS 3.12です。Stableを使いたい場合は素直にRHEL7やCentOS7を使った方がいいと思います。

ただ、repoファイルそのままの内容ではGPGのエラーを解決できないため、このリポジトリーのパッケージを使うにはgpgcheckをオフにする必要がありました。

gpgcheck=1
↓
gpgcheck=0

というわけで、RHEL7/Fedora 27ではGlusterFSは割と簡単に動作しました。 ちなみにGlusterFSサーバーを動かしたり、リモートのGlusterFSの共有ボリュームをマウントするためにSELinuxを闇に滅する(無効化する)必要は特にありませんでした。