一昔前にフラッシュメモリベースのデータセンター向けストレージ「ioDrive」が一瞬話題になったが、このioDriveはUbuntu 18.04を公式にはサポートしていない。うっかり使っているサーバーをUbuntu 16.04から18.04にアップデートしてしまいトラブったのだが、自前でドライバをビルドすることでとりあえず動くようにはなる。当然サポート範囲外だが、手順をメモしておく。

　まず、Ubuntu 18.04にアップデートして再起動した時点でioDriveをマウントできなくなり、/etc/fstabで起動時にioDriveをマウントするよう設定している場合復旧モードで起動する羽目になる。そのため、まずはここで/etc/fstabを編集し、ioDriveに関する宇の記述をコメントアウトする。自分の環境ではioDriveは/dev/fioa1として認識されていたので、この記述をコメントアウト。

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=29279b34-d2fd-4a10-b3ac-378884b6f579 /               ext4    relatime,errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=ff4e823a-c074-41bf-aa7c-5e63bd8c3f6a none            swap    sw              0       0
#/dev/fioa1 /fioa1 ext4 auto,rw,relatime,stripe=8,data=ordered 0 0

　続いてWestern Digitalのサポートサイトの「Downloads」リンク経由で最新のドライバを入手する（要アカウント登録）。ダウンロードページで「ioDrive」－「Linux_ubuntu-16.04」－「Current Version」（今回使用したのは「3.2.16」）を選択して「Software Source」からソースtarball（今回は「iomemory-vsl_3.2.16.1731-1.0.tar.gz」）をダウンロードする。なお、このページはCORS関連の問題でChromeではまともに動作しないようだ（Firefoxではダウンロードできた）。

　ダウンロードしたアーカイブを適当なディレクトリに展開する。

$ tar xvzf iomemory-vsl_3.2.16.1731-1.0.tar.gz
$ cd iomemory-vsl-3.2.16.1731/

　このソースtarballにはroot/usr/src/iomemory-vsl-3.2.16/kfio/以下にコンパイル済みオブジェクトファイル（いわゆるバイナリblob）が含まれており、このオブジェクトファイルをコンパイル時にリンクして使用するようになっている。このオブジェクトファイルは異なるコンパイラでビルドしたと思われる複数のものが用意されており、ファイル名の「cc??」の部分がコンパイラのバージョンに対応するようだ。今回使用したiomemory-vsl_3.2.16.1731-1.0.tar.gzでは次のようにGCC 4.1/4.3/4.4/4.8/4.9/5.3/5.4/6.3用のバイナリが入っていた。

$ /root/usr/src/iomemory-vsl-3.2.16/kfio/
x86_64_cc41_libkfio.o_shipped  x86_64_cc44_libkfio.o_shipped  x86_64_cc49_libkfio.o_shipped  x86_64_cc54_libkfio.o_shipped
x86_64_cc43_libkfio.o_shipped  x86_64_cc48_libkfio.o_shipped  x86_64_cc53_libkfio.o_shipped  x86_64_cc63_libkfio.o_shipped

　Ubuntu 18.04のデフォルトのGCCはバージョン7.3だが、これに対応するバージョンのバイナリはない。ただ幸いなことにUbuntu 18.04ではGCC 4.8がパッケージで提供されているので、これを利用する。

# apt-get install gcc-4.8

　また、debhelperとdpkg-devパッケージも必要なのでインストールしておく。

# apt-get install debhelper dpkg-dev

　GCC 4.8をインストールしたら、次のように「CC=gcc-4.8」を指定して「dpkg-buildpackage」コマンドを実行する。

$ CC=gcc-4.8 dpkg-buildpackage -b -us -uc

　正常にコンパイルとパッケージ作成が完了すると、親ディレクトリに次のようにファイルが作成される。

$ cd ..
$ ls -1
iomemory-vsl-3.2.16.1731
iomemory-vsl-4.15.0-43-generic_3.2.16.1731-1.0_amd64.deb
iomemory-vsl-config-4.15.0-43-generic_3.2.16.1731-1.0_amd64.deb
iomemory-vsl-source_3.2.16.1731-1.0_amd64.deb
iomemory-vsl_3.2.16.1731-1.0.tar.gz
iomemory-vsl_3.2.16.1731-1.0_amd64.buildinfo
iomemory-vsl_3.2.16.1731-1.0_amd64.changes

　このうち、「iomemory-vsl-4.15.0-43-generic_3.2.16.1731-1.0_amd64.deb」をインストールすれば良い。そのため、まずすでにインストールされているパッケージをアンインストールする。

# dpkg -r iomemory-vsl-source iomemory-vsl-config-3.13.0-77-generic  iomemory-vsl-3.13.0-77-generic libvsl

　続いて新たに作成したパッケージをインストールする。

# dpkg -i iomemory-vsl-4.15.0-43-generic_3.2.16.1731-1.0_amd64.deb

　最後にmodprobeコマンドで「iomemory-vsl」モジュールをロードすればioDriveが利用可能になる。fstabファイルでコメントアウトした部分を元に戻し、問題なくマウントできればOK。

# modprobe iomemory-vsl
# vi /etc/fstab
# mount /fioa1

　CentOS 7でpython-rhsm-certificatesパッケージの仕様が変わり、今までここに含まれていたRed Hat関連の証明書がなくなってしまった模様（CentOS Bug Tracker）。そのせいで、Red Hatが提供しているDockerコンテナリポジトリであるregistry.access.redhat.comにCentOS 7環境からアクセスできなくなる状況が発生する。

　たとえば、CentOS上で組んだKubernetes環境ではregistry.access.redhat.com/rhel7/pod-infrastructureというコンテナが使われるのだが、このイメージがPullできなくなるエラーが発生する。

ErrImagePull: "image pull failed for registry.access.redhat.com/rhel7/pod-infrastructure:latest, this may be because there are no credentials on this request.  details: (open /etc/docker/certs.d/registry.access.redhat.com/redhat-ca.crt: no such file or directory)"

　この変更はほかのさまざまなパッケージでも影響が出ているようだが、根本的な問題解決はRed Hat/Cent OS側で対処してもらうしかない。とりあえずは古いpython-rhsm-certificatesパッケージをダウンロードして、そこから問題の証明書を抜き出して手動で配置することで対処は可能。手順的には下記となる。

$ wget http://mirror.centos.org/centos/7/os/x86_64/Packages/python-rhsm-certificates-1.19.10-1.el7_4.x86_64.rpm
$ rpm2cpio python-rhsm-certificates-1.19.10-1.el7_4.x86_64.rpm | cpio -iv --to-stdout ./etc/rhsm/ca/redhat-uep.pem | tee redhat-uep.pem
$ sudo cp redhat-uep.pem /etc/rhsm/ca/

　自前で構築したKubernetesクラスタでサービス（serivces、svc）関連がうまく動かない場合、原因としてfirewall関連の設定が不適切だったということがよくあります。kube-dns関連のトラブル（kube-dns Podが起動しないなど）もこれが原因であることがよくあります。

　そういった場合、とりあえずiptablesが正しく設定されているか、またクラスタ内からapiserverのbind-addressで指定したアドレスの8080番および6443番ポート）にアクセスできるよう設定しているかを確認してみましょう。

　また、Kubernetesのパケットは複雑な経路でやってくるので、インターフェイス単位でアクセス許可を指定した場合うまく動かない場合があります。そのため、たとえばfirewalldを利用している場合、コンテナに割り当てられるネットワーク（たとえば172.17.0.0/16）をinternalゾーンに追加したうえで8080/tcpおよび6443/tcpを許可する、もしくはtrustedゾーンに追加する、といったようにネットワーク単位で設定した方が確実です。

　テスト用のKubernetesクラスタをメンテナンスしていたら、突然クラスタの操作ができなくなった。次のようなエラーが出る。

$ kubectl get nodes
No resources found.
Error from server (NotAcceptable): unknown (get nodes)

　色々調べたところ、うっかりkubectlコマンドをアップデートしてしまってクラスタ側とバージョンが一致しなくなっていた（クラスタ側は1.7.7、kubectlコマンドは1.11）。kubectlコマンドをダウングレードすることで対処できた。

　とりあえず基本的な流れは以前さくらのナレッジに書いたものと同じ。ただし、クラスタノードのkubelet設定ファイル（/etc/kubernetes/kubelet）の「KUBELET_ARGS」に次のように「–kubeconfig」および「–require-kubeconfig」パラメータを追加した上で、kubelet.ymlファイルを用意する必要がある。

KUBELET_ARGS="--cgroup-driver=systemd --fail-swap-on=false --kubeconfig=/etc/kubernetes/kubelet.yml --require-kubeconfig"

　kubelet.ymlファイルはこんな感じ。

kind: Config
clusters:
- name: local
  cluster:
    server: http://＜api-serverのホスト名かIPアドレス＞:8080
users:
- name: kubelet
contexts:
- context:
    cluster: local
    user: kubelet
  name: kubelet-context
current-context: kubelet-context

　–api_servers（–api-servers）オプションは廃止されているので、このように設定ファイルでapi-serverのURLを指定しなければならない模様（https://github.com/kubernetes/website/issues/7417）。

（追記@2018-05-15）

　kube-proxyにはiptables 1.6.2と組み合わせて使うとiptablesルールを適切に設定できないという不具合がある。Fedora 28のiptablesは1.6.2なので、これに引っかかる。Fedora 28のKubernetesパッケージに含まれているkubeletでは現時点でこれが修正されていない。とりあえずFedora 27用のiptables 1.6.1に置き換えることで問題は回避できそう。

$ wget https://dl.fedoraproject.org/pub/fedora/linux/releases/27/Everything/x86_64/os/Packages/i/iptables-1.6.1-4.fc27.x86_64.rpm
$ wget https://dl.fedoraproject.org/pub/fedora/linux/releases/27/Everything/x86_64/os/Packages/i/iptables-libs-1.6.1-4.fc27.x86_64.rpm
# dnf install iptables-*.rpm

　Debianのmysqlパッケージをアップデートしたら突然mysqlサービスが起動しなくなった。journalctlでエラーメッセージを見ると、次のように出力されている。

# journalctl -u mysql
  ：
  ：
May 07 06:10:09 gate mysqld[3528]: /usr/sbin/mysqld: Error on realpath() on '/var/lib/mysql-files' (Error 2)
May 07 06:10:09 gate mysqld[3528]: 180507  6:10:09 [ERROR] Failed to access directory for --secure-file-priv. Please make sure that directory exists and is accessible by MySQL Server. Supplied value : /var/lib/mysql-files

　この場合、/var/lib/mysql-filesディレクトリを作成すればOKのようだ。問題のパラメータ「–secure-file-priv」についてのドキュメントはここにある。

# mkdir /var/lib/mysql-files
# chown mysql:mysql  /var/lib/mysql-files
# chmod 700 /var/lib/mysql-files

　Raspberry Piを使ってSpotifyを再生できるデバイスを作ったので手順などを備忘録代わりに。使用したデバイスはRaspberry Pi Zero W。OSはRaspbian（Stretch）。なお利用にはSpotifyの有料アカウントが必須。

Spotify Connectデバイスとして使用する

　Spotifyを再生するためには、デバイス側でSpotifyにログインしてプレイリストなどの情報を取得して再生する、という処理を全部行うやり方と、PC/Macやスマートフォン、タブレットなどのSpotifyアプリ側で認証やプレイリスト/楽曲管理などを行い、Spotifyとの通信およびデータダウンロード、再生などのみをデバイス側で行う「Spotify Connect」という機能を使うやり方がある。

　Spotify Connectデバイスとして利用する場合、Raspotifyというソフトウェアを利用すると簡単に実現できる。librespotというオープンソースで開発されているSpotifyクライアントライブラリが使われているが、これらを含有したRaspberry Pi向けのバイナリパッケージが配布されているので、これをインストールし、設定ファイルを編集してサービスを起動するだけで良い。

　設定ファイルは/etc/default/raspotify。変更したのはデバイス名を指定する「DEVICE_NAME」、ビットレートを指定する「BITRATE」といくつかのオプション。オプションについてはlibrespotのドキュメントにまとめられているが、ここでは使用するALSAデバイスを指定する「–device」、Spotifyアプリとの接続に使用するポートを指定する「–zeroconf-port」、キャッシュディレクトリを指定する「–cache」、音量の自動調整を有効にする「–enable-volume-normalisation」、初期音量を指定する「–initial-volume」を使用している。–deviceの引数はALSAの設定によって変わるので適宜適切なものを選択（後述）。ユーザー名などはSpotifyアプリ経由で取得するので設定不要。「–zeroconf-port」は指定しなくても良いのだが、指定するとポートを固定できるためファイアウォールの設定が簡単になる。

# /etc/default/raspotify -- Arguments/configuration for librespot

# Device name on Spotify Connect
#DEVICE_NAME="raspotify"
DEVICE_NAME="5potpy"

# Bitrate, one of 96 (low quality), 160 (default quality), or 320 (high quality)
#BITRATE="160"
BITRATE="320"

# Additional command line arguments for librespot can be set below.
# See `librespot -h` for more info. Make sure whatever arguments you specify
# aren't already covered by other variables in this file. (See the daemon's
# config at `/lib/systemd/system/raspotify.service` for more technical details.)
#
# To make your device visible on Spotify Connect across the Internet add your
# username and password which can be set via "Set device password", on your
# account settings, use `--username` and `--password`.
#
# To choose a different output device (ie a USB audio dongle or HDMI audio out),
# use `--device` with something like `--device hw:0,1`. Your mileage may vary.
#
#OPTIONS="--username <USERNAME> --password <PASSWORD>"
OPTIONS="--device mydev --zeroconf-port 65432"

# Uncomment to use a cache for downloaded audio files. Cache is disabled by
# default. It's best to leave this as-is if you want to use it, since
# permissions are properly set on the directory `/var/cache/raspotify'.
CACHE_ARGS="--cache /var/cache/raspotify"

# By default, the volume normalization is enabled, add another volume argument
# here if you'd like, ie `VOLUME_ARGS=--initial-volume 100`.
VOLUME_ARGS="--enable-volume-normalisation --initial-volume 100"

　設定ファイルを作成したら、systemctlコマンドでサービスを開始できる。

# systemctl start raspotify

　ログはjournalctlコマンドで閲覧できる。

# journalctl -u raspotify

　確認していないが、zeroconfを使っているとのことで別途avahi-daemonも必須かもしれない。

# systemctl start avahi-daemon

Webブラウザ経由で操作できるSpotifyクライアントを使う

　基本的にはSpotify Connect経由での利用で事足りるのだが、Webブラウザ経由で操作できるクライアントについても試しに導入してみた。こちらはMopidyというミュージックサーバーソフトウェアとSpotify用のプラグインを組み合わせて利用することで実現できる・

　Mopidy自体はRaspbian標準でパッケージが提供されているので、これをインストールする。

# apt-get install mopidy

　次に、Spotify用のプラグインをインストールする。必要なのは下記。

• mopidy-mopify：MopidyにSpotify連携用のWeb UIを追加するプラグイン
• mopidy-spotify：MopidyにSpotifyからのストリーミング再生機能を追加するプラグイン
• libspotify：かつてSpotifyが公式に提供していたSpotify連携ライブラリ。すでに開発終了でいつサポートが終了してもおかしくない
• pyspotify：libspotifyのPythonラッパー

　libspotifyとコンパイル済みのpyspotifyはMopidyのaptリポジトリから入手可能（ドキュメント）。自分は次のように直接ダウンロードして使用した。

$ wget http://apt.mopidy.com/dists/jessie/non-free/binary-armhf/libspotify12_12.1.103-0mopidy1_armhf.deb
$ wget http://apt.mopidy.com/dists/jessie/contrib/binary-armhf/python-spotify_2.0.5-0mopidy1_armhf.deb

　いくつか依存するパッケージがあるので、それはapt-getでインストールする。mopidy-spotifyとmopidy-mopifyについてはpipでインストールできる。

# pip install Mopidy-Spotify

# pip install Mopidy-Mopify

　続いて設定ファイルの編集。

[core]
cache_dir = /var/cache/mopidy
config_dir = /etc/mopidy
data_dir = /var/lib/mopidy

[logging]
config_file = /etc/mopidy/logging.conf
debug_file = /var/log/mopidy/mopidy-debug.log

[local]
media_dir = /var/lib/mopidy/media

[m3u]
playlists_dir = /var/lib/mopidy/playlists

[http]
enabled = true
hostname = 192.168.1.210
port = 6680
zeroconf = Mopidy HTTP server on $hostname

[mopify]
enabled = true
debug = false

[spotify]
enabled = true
username = ＜Spotifyのユーザー名＞
password = ＜Spotifyのパスワード＞
client_id = ＜client ID＞
client_secret = ＜client secret＞
bitrate = 320

　hostnameやusername、passwordは各自適切な物を指定する。client_idおよびclient_secertはMopidyのWebサイトにアクセスして「LOG IN WITH SPOTIFY」リンクをクリックしてOAuth認証を行うと、このページにリダイレクトされて設定すべきclient_idおよびcluent_secretが表示される。これをコピペすればOK。

ALSAの設定

　RaspotifyもMopidyもサウンド出力にはALSAを使用する。認識されているデバイスは/proc/asound/cardsファイルで確認できる。たとえば次の例では、デバイス0としてRaspberry Pi内蔵オーディオ（Raspberry Pi Zero Wの場合HDMI経由での出力に相当するはず）、デバイス1としてUSB端子に接続したオーディオIFが認識されている。

# cat /proc/asound/cards
 0 [ALSA           ]: bcm2835 - bcm2835 ALSA
                      bcm2835 ALSA
 1 [USB            ]: USB-Audio - ＜USBサウンドデバイスの情報がここに表示される＞

　ALSAの場合、各アプリケーションが使用するサウンドデバイスに関する設定は/etc/asound.confで行える。今回はデフォルト設定（pcm.!default）に加えて、「pcm.mydev」という設定を作ってこれをRaspotifyで使用するよう指定している（前述）。dmixerの設定ではuidが異なる複数のプロセスからの非排他的音声出力を可能にするため「ipc_key_add_uid 0」「ipc_perm 0660」の2つを指定している。また、「slave」以下で「hw:1」を指定することで、オーディオデバイス1、つまりUSBサウンドデバイスを使用するよう指定している。

# cat /etc/asound.conf 
pcm.mydev {
  type plug
  slave {
    pcm "dmixer"
  }
}

pcm.!default {
  type plug
  slave {
    pcm "dmixer"
  }
}

pcm.dmixer {
  type dmix
  ipc_key 1024
  ipc_key_add_uid 0
  ipc_perm 0660
  slave {
    pcm "hw:1"
  }
}

問題点

　Mopidyでは一部のプレイリストが適切に取得できなかったりする模様。これはlibspotifyがもうdeprecatedであるためらしい。

　また、MopidyとRaspotify両方で発生する問題だが、ネットワークが遅くなる時間帯だとストリームのキャッシュに時間がかかったり、間に合わずに音切れが発生する状況となっている。Spotifyアプリだとこの問題は発生しないのでパケットを調べたりしたのだが、どうもSpotify公式アプリはakamai経由でコンテンツをダウンロードしているため混雑時でも高速にコンテンツをダウンロードできているようだ。この機能はMopidy（libspotify）やlibrespotではサポートされていないようなので、簡単には解決できなさそうである。

　systemdでdocker serviceの起動時に、次のようなエラーが出て起動できない場合がある（このメッセージはjournalctl -xeコマンドで確認）。

-- The result is failed.
 3月 07 18:28:10 fedora25 systemd[1]: docker.service: Unit entered failed state.
 3月 07 18:28:10 fedora25 systemd[1]: docker.service: Failed with result 'start-limit-hit'.

　このエラーは使用しているdockerのバージョンとsystemdのdocker.service設定ファイルの内容が合っていない場合に出るようだ。このエラーが出た環境は、Dockerが配布しているパッケージでDockerをインストール後、そのパッケージを削除してFedora 25標準のパッケージに入れ直したというもの。自分で作成して忘れていたのか、それともパッケージによってインストールされたのか分からないが、/etc/systemd/systemディレクトリ以下にdocker.serviceファイルが残っていたのが原因。

　このファイルを削除し、systemctl daemon-reloadでsystemdの設定を読み直したら復旧した。

　Fedora 25では、httpdをインストールするとデフォルトで自己署名証明書を作成してSSLを有効にする設定になっている模様。そのため、certbotコマンドでLet’s Encryptで証明書を取得しようとすると失敗するようだ。

# dnf install certbot
# certbot --apche
（...ここで設定を入力する）
Failed authorization procedure. test.hylom.net (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to ＜IPアドレス＞:443 for TLS-SNI-01 challenge

　対策としては、まず/etc/httpd/conf.d/ssl.confをssl.conf.orgなどにリネーム後にhttpdを再起動してSSLをいったん無効にした後、certbotコマンドを実行すれば良い。

　Sambaで共有したLinuxマシン上のディレクトリにWindowsからアクセスした際、作成したファイルのパーミッションが755とかになってしまう問題がある。この場合、smb.confで「map archive = no」を指定すると解決する。副作用などについてはググれ。

　Red Hat Enterprise Linux 7（やCentOS 7など）では、iptablesなどによるパケット制御をfirewalldで行うようになった。このfirewalldを使って、ファイアウォールの設定を行う手順メモ。

前提条件

• systemctlコマンドでfirewalldを稼動させておく
• firewalldの設定は「firewall-cmd」コマンドで行う

zone設定

　firewalldには「ゾーン」という概念があり、ゾーンごとに有効なポートなどを指定する。デフォルトで用意されているゾーンには「public」や「home」、「trusted」などが用意されている。

　現在有効なゾーンは「firewall-cmd --list-all」コマンドで確認できる。

# firewall-cmd --list-all
public (default, active)
  interfaces: enp8s0 virbr0 virbr1
  sources:
  services: dhcpv6-client samba ssh
  ports:
  masquerade: no
  forward-ports:
  icmp-blocks:
  rich rules:

　この例では、「enp8s0」および「virbr0」、「virbr1」というインターフェイスが「public」ゾーンに割り当てられている。また、publicゾーンでは「dhcpv6-client」と「samba」、「ssh」というサービスが有効になっている。

サービスの追加

　ゾーンに「サービス」を追加することで、そのサービスを追加できる。定義されているサービスは「firewall-cmd --get-services」コマンドで確認できる。

# firewall-cmd --get-services
amanda-client bacula bacula-client dhcp dhcpv6 dhcpv6-client dns ftp high-availability http https imaps ipp ipp-client ipsec kerberos kpasswd ldap ldaps libvirt libvirt-tls mdns mountd ms-wbt mysql nfs ntp openvpn pmcd pmproxy pmwebapi pmwebapis pop3s postgresql proxy-dhcp radius rpc-bind samba samba-client smtp ssh telnet tftp tftp-client transmission-client vnc-server wbem-https

　特定のゾーンで許可されているサービスは「firewall-cmd --list-service --zone=＜ゾーン名＞」で確認できる。

# firewall-cmd --list-service --zone=public
dhcpv6-client samba ssh

　ゾーンにサービスを追加するには、「firewall-cmd --add-service=＜サービス名＞ --zone=＜ゾーン名＞」コマンドを使用する。下記は「public」ゾーンに「http」サービスを追加する例。

# firewall-cmd --list-service --zone=public
dhcpv6-client mysql samba ssh
# firewall-cmd --add-service=http --zone=public
success
# firewall-cmd --list-service --zone=public
dhcpv6-client http mysql samba ssh

　なお、--add-serviceオプションで追加したサービスは、firewalldの再起動後には保持されない。恒久的にサービスを追加するには、「--permanent」オプションを指定する。この場合、即座にはサービスが追加されないので、その後に「firewall-cmf --reload」コマンドを実行してfirewalldの設定をリロードさせると変更が反映される。

# firewall-cmd --add-service=http --zone=public --permanent
success
# firewall-cmd --list-service --zone=public
dhcpv6-client samba ssh
# firewall-cmd --reload

　また、追加したサービスを削除するには「--remove-service」オプションを使用する。

# firewall-cmd --remove-service=dhcpv6-client --zone=public

　Red Hat Enterprise Linux 7（やCentOS 7など）で導入されたsystemdで、サービスの開始/停止やシステム起動後の自動起動などを設定する手順メモ。

　systemdでは、「systemctl」というコマンドでサービスの制御を行う。サービスを開始/停止するには「start」および「stop」サブコマンドを使用する。また、「status」サブコマンドで稼働状況をチェックできる。

systemctl start ＜サービス名＞
systemctl stop ＜サービス名＞
systemctl status ＜サービス名＞

　システムの起動時にサービスを自動起動させるには「enable」サブコマンドを、自動起動させないように設定するには「disable」サブコマンドを使う。

systemctl enable ＜サービス名＞
systemctl disable ＜サービス名＞

　稼働中のサービスの確認は、「list-units」サブコマンドで行える。サブコマンドを省略すると「list-units」サブコマンドが実行されるので、引数無しでsystemctlコマンドを実行しても同じ結果が得られる。

# systemctl
UNIT                        LOAD   ACTIVE SUB       DESCRIPTION
proc-sys...t_misc.automount loaded active waiting   Arbitrary Executable File Fo
sys-devi...-sda-sda1.device loaded active plugged   VBOX_HARDDISK
  ：
  ：

　このうち、「.service」で終わっているものがサービスとなる。また、「-t service」オプション付きでsystemctlコマンドを実行することでサービスのみを一覧表示できる。

$ systemctl -t service

　また、「list-units」サブコマンドでは「disabled」に設定されているサービスは表示されない。これらも含めて確認するには、「list-unit-files」サブコマンドを実行する。

$ systemctl list-unit-files

　昨年、『米Red Hat、RHELの開発環境をアップデートする「Developer Toolset 2.0」および「Software Collections 1.0」をリリース』という話題がありました。

　Red Hat Enterprise Linux（RHEL）は安定性を重視し、かつ長期にわたって利用されることを想定しているため、ディストリビューションに含まれているソフトウェアは比較的古めのものになっています。そのため、RHELに標準で含まれていない最新のソフトウェアを利用したい場合、自分でソースコードからビルドするか、サードパーティのリポジトリを利用する必要がありました。

　この「Software Collections」（以下SCL）は、そういった背景の下、RHELに含まれていないソフトウェア、もしくはRHELに含まれているものよりもバージョンが新しいソフトウェアを提供するもので、たとえば以下のようなソフトウェアが提供されます。

Ruby 1.9.3 (ruby193)
Python 2.7 (python27)
Python 3.3 (python33)
PHP 5.4 (php54)
Perl 5.16.3 (perl516)
Node.js 0.10 (nodejs010)
MariaDB 5.5 (mariadb55)
MySQL 5.5 (mysql55)
PostgreSQL 9.2 (postgresql92)

　特にRubyにおいては、近年RHELに収録されているRuby 1.8.7をサポートしないライブラリやソフトウェアが増えてきたため、Ruby1.9.3が簡単に導入できるのは便利なところです。

　そして、CentOSがRed Hatの正式プロジェクトとなった影響なのか、このSCLもCentOSで利用できるようになりました（CentOS-announceメーリングリストに流れたアナウンスメール）。

　導入方法は非常に簡単で、「centos-release-SCL」パッケージをインストールするだけです（ドキュメント）。ただし、利用できるのはx86_64のみとなっています。

# yum install centos-release-SCL

　centos-release-SCLパッケージのインストール後は、yumコマンドでそれぞれのパッケージをインストールできるようになります。たとえばruby 1.9.3をインストールするには、以下のようにします。

# yum install ruby193

　ただし、SCLに含まれるソフトウェアは、そのままでは実行できません（ruby193というパッケージをインストールしても、ruby193というコマンドが利用できるようになるわけではない）。実行する二は、sclコマンドを利用する必要があります。sclコマンドは、引数で指定したパッケージを有効にした状態で指定したコマンドを実行するものです。たとえば、以下のようにするとRuby 1.9.3を有効にした環境で「ruby -v」コマンドを実行できます。

$ scl enable ruby193 'ruby -v'
ruby 1.9.3p448 (2013-06-27) [x86_64-linux]

　また、次のように引数にシェルを指定すれば、指定したパッケージが有効になったシェル環境を起動できます。

$ scl enable ruby193 bash
$ ruby -v
ruby 1.9.3p448 (2013-06-27) [x86_64-linux]
$ exit

　ちなみに、この環境でRubyGemをインストールしたい場合はroot権限でsclコマンドを実行してからgemコマンドでインストールする必要があります。

# scl enable ruby193 bash
# gem install ＜インストールしたいパッケージ＞

　そのほかの使い方などはドキュメントをご参照ください。

　パーティションのリサイズをするにはGNU partedを使うのが一般的なようです。partedはファイルシステムのリサイズも同時にやってくれる便利なツールですが、CentOS 6.3のインストールメディアに含まれているpartedはext4には対応していないようで、ext4ファイルシステムのリサイズはできません。ext4ファイルシステムのリサイズ自体はresize2fsを使って簡単に実行できるわけですが、どっちにしろパーティションのリサイズは必要になります。

　ということで、パーティションのリサイズをするためのツールを探したわけですが、なかなか見つからない。パーティション操作の定番といえばfdiskですが、リサイズというコマンドはない。そこではっと気付いたのですが、fdiskはよく考えればパーティションテーブルの操作のみを行うのであって、ファイルシステムには影響を与えません。と言うことで、リサイズしたいパーティションを削除して、そのうえで新たなパーティションを作成すればリサイズと同様の処理になるわけです。これには気付かなかった。ただ、このときパーティションのサイズがファイルシステムのサイズよりも大きくなるように気を付けなければなりません。パーティションを拡大する場合はあまり問題にはなりませんが、縮小する場合はサイズを間違えるとちょっとまずいことになる可能性があります（ただし、ext4の場合はマウント時にチェックが行われてファイルシステムのサイズよりもパーティションサイズが小さい場合はエラーが発生する）。

　ただ、fdiskでのサイズ計算はバイト単位ではなく、ブロック単位でサイズを指定する関係上ちょっと面倒臭い。これについてはまた後日（覚えていれば）。

　CentOS 6のSambaでファイル共有がうまく行かない場合、SELinuxによって各種アクセスがブロックされている可能性がある。詳細はsamba_selinuxドキュメントに記載されている。

$ man samba_selinux

　とりあえず、smbclientでログインには成功するのにホームディレクトリにアクセスできない、という場合、次のコマンドで解決できた。

# setsebool -P samba_enable_home_dirs 1

　CentOSにおいて、複数のNICを搭載しているマシンでNICに対応しているデバイス名を変更したい場合、次のような手順をとれば良い。

　まず、ネットワークを停止させる。

# service network stop

　次に、NICのモジュールをいったんアンロードする。たとえば「e1000e」モジュールを使っている場合、次のようにする。

# rmmod e1000e

　udevの設定ファイルを編集する。ネットワークデバイスについてのMACアドレスとデバイス名の対応付けは、「/etc/udev/rules.d/70-persistent-net.rules」というファイルに記述されている。

　このファイルを適当に編集したら、「/etc/sysconfig/network-scripts/ifcfg-eth?」ファイルの「HWADDR」行を削除する。

　以上で設定完了。この状態で次のようにネットワークを再起動させると、デバイスファイル名とNICの対応が変更されているはず。

# service network start

　64ビットのLinux環境で32ビットのプログラムを動かそうとする場合、32ビット版のライブラリが不足していて実行できない場合がある。

/lib/ld-linux.so.2: bad ELF interpreter: No such file or directory

　と出た場合、次のように32ビット版のlibstdc++をインストールすればOK。

$ sudo yum install libstdc++.i686

　CentOS 6の初期設定メモその1。ユーザーを作成してSSHの設定を行うまで。

ユーザーの作成

# groupadd hylom
# useradd -d /home/hylom -g hylom -m hylom
# chsh -s /bin/bash hylom
# passwd hylom

sudoの設定

　sudoersファイルを編集する。

# yum install sudo
# visudo

　sudoersファイルに次のようにhylomを追加。

## Allow root to run any commands anywhere
root    ALL=(ALL)       ALL
hylom   ALL=(ALL)       ALL

SSH関連の設定

　SSH公開鍵を作成する。

# su hylom
$ ssh-keygen
$ cd ~/.ssh
$ vi authorized_keys 
$ chmod 600 authorized_keys

　authorized_keysにはログインに使用する公開鍵をコピー＆ペーストしておく。

　SSHサーバーの設定。

# vi /etc/ssh/sshd_config

　sshd_configファイルでPermitRootLoginをnoに、PasswordAuthenticationをnoに設定し、rootでのログインを禁止＆認証に公開鍵必須とする。

#PermitRootLogin yes
PermitRootLogin no

#PasswordAuthentication yes
PasswordAuthentication no

ホスト名の設定

# vi /etc/sysconfig/network
# hostname <hostname>

　CentOS 5を使っていると、含まれているソフトウェアのバージョンが古かったり、そもぞもリポジトリにそのソフトウェアがなかったりして困ることがある。さっさとCentOS 6にアップデートすればいい話なのだが、面倒くさいとか、そもそもフルバックアップしないと行けないとか色々と大変だったりするので（CentOS 5からCentOS 6へのアップデートは再インストールが推奨されている）、なんとかまだCentOS 5をこのまま使いたい、そんな時に役立つのがEPEL。

　EPELは「Extra Packages for Enterprise Linux」の略で、Fedora Projectが運営しているRed Hat Enterprise Linuxおよびその互換OS向けのパッケージリポジトリ。同種のものにrpmforgeがあるわけですが、Fedora Projectが運営しているということでEPELのほうがやや信頼感が（個人的には）高いということでこちらを使うことに。

　導入方法は簡単。以下を実行するだけ。

$ sudo rpm -Uvh http://ftp.jaist.ac.jp/pub/Linux/Fedora/epel/5/i386/epel-release-5-4.noarch.rpm

　これでgitとかpython26とかをyumでインストールできるようになります。

　先日MSDNを契約、テスト用に自由にOSを使えるようになったので、テスト用のCore i7マシンにXenを導入して仮想マシン上でテスト環境を作ろう、という話。いままではテスト環境が必要になったら実環境上にインストール→不要になったら削除、を繰り返していたんだけど、仮想環境を使えばスナップショットも取れるし便利だろう、ということで。

　ベースの環境はCentOS 5.6。CentOS 5.6上にXen環境を構築する解説はネット上にたくさんあるわけですが、その多くがGUIを使ったセットアップ方法を解説していて、コンソールベースのCentOS環境でインストールする方法の解説は少なかったので以下に手順をメモしておきます。

　まず、仮想化関連パッケージを導入。

# yum groupinstall Virtualization
# yum install kernel-xen

　Xenを動かすには専用カーネルが必要なので、/boot/grub/menu.lstを確認してXen対応カーネル（2.6.xx-xxx.x.x.el5xen）でブートされるように設定してリブート。また、xendおよびxendomainsサービスを起動するように設定しておく。

# /sbin/chkconfig xend on
# /sbin/chkconfig xendomains on
# /sbin/service xend start
# /sbin/sercice xendomains start

　仮想マシンの作成とOSインストールは「virt-install」コマンドで行える。Fedora 15をインストールするなら下記のような感じに。

# /usr/sbin/virt-install --nographics --prompt
Would you like a fully virtualized guest (yes or no)? This will allow you to run unmodified operating systems. no
 What is the name of your virtual machine? fedora
 How much RAM should be allocated (in megabytes)? 1024
 What would you like to use as the disk (file path)? /var/lib/xen/images/fedora.img
 How large would you like the disk (/var/lib/xen/images/fedora.img) to be (in gigabytes)? 10
 What is the install URL? http://ftp-srv2.kddilabs.jp/Linux/distributions/fedora/releases/15/Fedora/i386/os/
　：
　：
インストールを開始しています...
ファイル .treeinfo を読出中...                             |  906 B     00:00
ファイル vmlinuz-PAE を読出中...                           | 3.7 MB     00:00     TA
ファイル initrd-PAE.img を読出中...                        |  94 MB     00:40     TA
ストレージファイルを作成中...                         |  10 GB     00:00
ドメインを作成中...                                        |    0 B     00:04
Connected to domain fedora
エスケープ文字は  ^] です
[    0.000000] Reserving virtual address space above 0xf5800000
[    0.000000] Initializing cgroup subsys cpuset
　：
　：

　コンソール上で仮想環境上のコンソールが表示され、インストールを行える。

コンソール上でFedoraのインストーラを操作する

　インストール完了語は、Ctrl-]でコンソールを抜けられる。稼働中の仮想マシンは「xm list」コマンドで確認可能。

# /usr/sbin/xm list
Name                                      ID Mem(MiB) VCPUs State   Time(s)
Domain-0                                   0     2012     8 r-----    780.4
fedora                                     2     1024     1 -b----      9.9

　仮想マシンのコンソールに接続するには、「xm console ＜仮想マシン名＞」を実行すればよい。コンソール接続の終了は先と同様Crtl-]。

# /usr/sbin/xm console fedora

　x86_64版CentOS 5.5のFirefoxでのJavaプラグイン導入に軽くハマったのでメモ。

　x86_64版のCentOS 5でFirefoxにJavaプラグインを導入したい場合、ググると「32ビット版Firefox＋32ビット版Javaランタイムを使え」という話がぼちぼちとヒットするわけですが、とりあえずJavaプラグインだけを使いたい場合は64ビット版でも可能なようです。ていうか自分の場合、32ビット版を導入しようとしたらうまくいきませんでした……。

　ということで、手順。まず64ビット版Firefoxをインストール。

$ sudo yum install firefox  # 64ビット版Firefoxをインストール

　続いてjava.comのダウンロードページから「Linux x64 RPM」をダウンロード。

「Linux x86 RPM」をダウンロードする

　RPMと書いてあるが、ダウンロードしたファイルはRPMではなくインストーラなので、root権限で実行してインストール。自動的にRPMがインストールされる。

$ chmod +x jre-6u21-linux-x64-rpm.bin
$ sudo ./jre-6u21-linux-x64-rpm.bin

　続いて設定。インストールしたjreを利用するようalternativesコマンドで指定。

$ sudo /usr/sbin/alternatives --install /usr/bin/java java /usr/java/jre1.6.0_21/bin/java 2
$ sudo /usr/sbin/alternatives --config java

　最後にmozilla用プラグインフォルダにプラグインのシンボリックリンクを張って完了。

$ cd /usr/lib64/mozilla/plugins/
$ sudo ln -sf usr/java/jre1.6.0_21/lib/amd64/libnpjp2.so .

　あとはFirefoxでabout:pluginsを開きプラグインが正しくインストールされているか確認したり、java.comにアクセスして動作を確認するなり適当にどうぞ。

　やや旧聞となるが、PhoronixがLinuxとFreeBSDのベンチマーク比較を行っている（Debian Linux Benchmarked Against Debian GNU/kFreeBSD � FreeBSD）。比較対象はDebian kFreeBSD 7.3、Debian kFreeBSD 8.0、Debian GNU/Linux（カーネル2.6.32）、FreeBSD 7.3、FreeBSD 8.0。

　「Debian kFreeBSD」はカーネルとしてFreeBSD、ユーザーランドとしてDebianを採用したものだ。Debian GNU/LinuxとDebian kFreeBSDはカーネルだけが異なり、またDebian kFreeBSDとFreeBSDはユーザーランドだけが異なる。これらを比較することで、ユーザーランドもしくはカーネルだけの性能比較が行える（と期待できる）点で興味深いベンチマークである。

　ベンチマーク結果であるが、gzipでの圧縮やGnuPGでの暗号化、MAFFT（分子生物学向けの核酸・アミノ酸アライメント作成ツール）、GraphicsMagickによる画像のリサイズ処理、Himeno BenchmarkについてはDebian kFreeBSDやDebian GNU/Linuxが高パフォーマンス、という結果だった。いっぽう、C-Rayでの3DグラフィックレンダリングについてはFreeBSD 7.3/8.0が高速な傾向が見られている。

　また、Debian GNU/LinuxがFreeBSDやDebian kFreeBSDよりも高速だったのはdCrawによるRAW画像の現像処理、Sudokut（数独演算アプリ）、SQLiteのインサート処理。

　このようにベンチマークごとに結果はばらばらであり、DebianのユーザーランドとFreeBSDのユーザーランドのどちらが高速か、またLinuxカーネルとFreeBSDのカーネルのどちらが高速かは単純には言えないという、なんともモヤモヤとした結論となっている。このベンチマークでは実行マシンとしてThinkPad R52とThinkPad T61を使用しているが、マシンによって結果が違うのも微妙なところだ。

ただし、マルチスレッドによるI/O処理ベンチマークについては、特にランダムWriteについてはLinuxカーネルのほうがパフォーマンスを発揮する傾向があるようだ。