ラベル Linux の投稿を表示しています。 すべての投稿を表示
ラベル Linux の投稿を表示しています。 すべての投稿を表示

2016年8月5日金曜日

コミケ90で「Get Started with HTTP/2」を出します(3日目 西4 f-44b)

1年ぶりに帰ってきました!コミケ90の3日目、西4 f-44b に出展します。「低級はっかーズ」です。

今回は前回までとは異なり、HTTP/2のお話です。Nginxを使って「安全で高速な」HTTP/2サーバーを構築するまでのガイドを掲載しています。SSL LabsでももちろんAランクになります。

その他、平文HTTP/1.1とのベンチマーク比較、Cipher suiteの解読方法など、見本には載せきれない内容が詰まってます。会場でお待ちしています!

タイトルは「Get Started with HTTP/2」です。表紙はきのとなおとさんに描いていただきました。

Linux Kernel Updates 2015.08と2014.12も持っていきます。会場でお待ちしています!

コミケが終わったら出せてなかった過去のLinux Kernel Updatesの分も含めてKindle版出します。

2015年8月15日土曜日

コミケ88 - Linux Kernel Updates 2015.08 (東2 P-15a)

コミケ88の3日目(2015年8月16日)に「低級はっかーズ」として出展します!

場所は東2, P-15aです。

今回はLinux Kernel Updates 2015.08として、Linux 3.19~4.1の最新情報、nftablesについての簡単な説明を書いた本を300円で頒布します。

表紙はロジさん(ロジカ+フィジカ)に描いていただきました。ありがとうございます。

その他、過去の既刊(2012.12, 2014.12)も持っていきます。在庫限りです。

当日会場でお目にかかりましょう!

2015年5月14日木曜日

QEMU, KVM, Xenに存在するVENOM脆弱性(CVE-2015-3456)について

VENOM脆弱性(CVE-2015-3456)についての情報をまとめました。

tl;dr

影響範囲は広いのですが、一部のクラウドベンダー以外は心配する必要はありません。一人で仮想環境を使っている場合には実質的な影響は受けません。なお、AWSは影響を受けないとアナウンスされています。

脆弱性の内容

QEMUに存在するフロッピーディスクコントローラー(FDC)にバッファオーバーフローのバグがあり、そのコードを利用するKVM, Xenが影響されます。なお、このコードはコマンドラインでFDの利用を指定しているかなどに影響を受けず、すべての設定で利用されます。詳しい内容については、Red Hat Security BlogのVENOM, don’t get bitten.という記事が参考になります。

この脆弱性を利用すると、本来アクセスができない他のVM、ホストOSへのアクセスが可能になります。

この脆弱性を利用するには、仮想マシン上で管理者権限を持っている必要があります。つまり実質的に問題となるのは、複数のユーザーに仮想マシンを管理者権限付きで貸している場合です。

この脆弱性は2004年に、FDCのコードがQEMUにマージされたときから存在します。

各ベンダーの対応

公式サイトに各ベンダーのアナウンスへリンクがあります。

影響を受けるクラウドベンダーの一覧(一部)

影響を受けないクラウドベンダーの一覧(一部)

調査中のクラウドベンダー一覧(一部)

2014年12月29日月曜日

Linux Kernel Updates 2014.12 をコミケ87に出します!

Linux Kernel Updates 2014.12のお知らせ

直前になりましたが、コミケ87でLinux Kernel Updates 2014.12を頒布します。

スペースは西い-36bです。

今回の内容

  • Linux 3.16 〜 Linux 3.18の新機能
  • OOM Killer 解説
  • Overlayfs を使ってみた

ここのところ小さな変更点が多かった Linux ですが、今回は Overlayfs を初めとして魅力的な機能がいくつか導入されました。

サンプルを掲載します。

今回もソースコードをもとに動作を解説しています。

既刊は、2013.08, 2013.12, 2014.08がそれぞれ若干数ありますので持っていきます。よろしくお願いします。

2014年11月25日火曜日

ssh-keygenがデフォルトで生成する鍵の種類と、安全性

sshの鍵を生成するのにssh-keygenをよく使いますが、無意識的に ssh-keygen -t rsa -b 2048 などと指定していました。ところが最近のバージョンのssh-keygenはオプションなしでもとりあえず動きます。

yuryu@ubuntu:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/yuryu/.ssh/id_rsa): 
Created directory '/home/yuryu/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/yuryu/.ssh/id_rsa.
Your public key has been saved in /home/yuryu/.ssh/id_rsa.pub.
The key fingerprint is:
7f:5a:1d:54:6a:30:dd:5c:ab:0c:8b:c6:9c:d6:3c:b8 yuryu@ubuntu
The key's randomart image is:
+--[ RSA 2048]----+
|            o. o+|
|             o.o+|
|           .  +. |
|        o * +o.  |
|        SO = o.  |
|        o.. .. . |
|         E. o .  |
|           +     |
|          .      |
+-----------------+

よく見ると答えが書いてありますが、デフォルトではどんな種類の鍵を生成しているのでしょうか?

[ RSA 2048]と書いてありますね。 RSAの2048bitsです。この種類の鍵と長さは今のところ安全だと言われているので、普通に使うのであればssh-keygenとオプション無しに実行すれば良いわけです。 DSAは鍵の長さが1024bitsでしか使えず、もはや安全な長さだとは言えないので使うべきではありません。なおECDSAの方が安全で鍵が長くなった場合に破綻しづらいと言われていますが、サポートされたのが比較的最近で例えばOS Xでは動かなかったりするので、まだ広く使えるとは言いがたいようです。

昔の記憶をたどると、-t を指定しない場合にはエラーだったり、標準の鍵長が1024bitsだったりしたことがあったと思うのですが、いつから変わったのでしょうか。コミットログを追ってみました。

年月変更点デフォルトで生成される鍵
1999年9月最初のコミットrsa1 1024
2000年4月DSAをサポートrsa1 1024
2000年11月RSA(SSH2)がサポートrsa1 1024
2001年12月鍵の種類の指定が必須にN/A
2005年6月デフォルトの鍵長が2048bitsに(ただし種類の指定は必須)N/A
2005年12月デフォルトの鍵がRSAにrsa 2048

というわけで、2001年よりも前のシステムはそもそも脆弱なので省くとすると、鍵の指定をしなくても動くシステムでは標準で RSA 2048bits の鍵が生成されるようです。鍵の指定をしなくてはいけない(-tオプションを省くとエラーになる)システムでは鍵長も指定した方が安全でしょう。

将来ECDSAが広く使われるようになったらまた状況が変わるのかも知れませんが、randomart image([ RSA 2048]から始まる模様)をちゃんと確認する癖をつけるのが良いかもしれませんね。

2014年9月30日火曜日

Linux Kernel Updates 2014.08のKindle版を出しました

コミケ86で出版したLinux Kernel Updates 2014.08のKindle版を出版しました。

目次

  • What's New in Linux 3.13?
  • What's New in Linux 3.14?
  • What's New in Linux 3.15?
  • Dockerとカーネル
  • ファイル名の入れ替え
  • O_TMPFILEの紹介

Linux Kernel Updates 2014.08の購入はこちらから!

以下は冊子版のプレビューです(Kindle版とはレイアウトが異なります)。

Linux Kernel Updates 2014.08の購入はこちらから!

2014年8月8日金曜日

Linux Kernel Updates 2014.08をコミケ86に出します!

コミケ86に「Linux Kernel Updates 2014.08」を出展します!

8月17日(日) 西“き”-10b 「低級はっかーズ」

目次

  • What's New in Linux 3.13?
  • What's New in Linux 3.14?
  • What's New in Linux 3.15?
  • Dockerとカーネル
  • ファイル名の入れ替え
  • O_TMPFILEの紹介

表紙は毎度おなじみきのとなおとさんに描いていただきました。ありがとうございます。

価格は300円、32ページです。

立ち読み

今回はDocker特集です!

既刊

過去のコミケで出したLinux Kernel Updatesのバックナンバーも持って行きます。在庫限り。

会場でお待ちしています!

2014年8月1日金曜日

Fedora 20でI218Vを認識させる方法

Asus Z97M-Plusのような新しめのAsusマザーボードには、イーサネットコントローラーとしてIntel I218Vが搭載されています。ところがFedora 20のインストールディスクにはこのデバイスドライバは入っていません。インストール方法を記録しておきます。

私は違う環境のFedora 20でビルドしてUSBで運びました。仮想マシンを使うのが楽だと思います。

必要パッケージなど

  • kernel-devel-3.11.10-301.fc20.x86_64 (バージョンも揃えます)
  • "Development Tools" 一式
  • I218V用の新しいドライバ e1000e-x.y.z.w.tar.gz っていうファイル名

ビルド手順

ダウンロードしたe1000eの圧縮ファイルを展開します。私の場合は e1000e-3.1.0.2.tar.gz でしたので tar xf e1000e-3.1.0.2.tar.gz します。

"cd e1000e-3.1.0.2/src; make BUILD_KERNEL=3.11.10-301.fc20.x86_64" します。すると、同じディレクトリにe1000e.koが生成されます。

e1000e.koを何とかして対象のマシンに移動し、"cp e1000e.ko /lib/modules/`uname -r`" して、対象のディレクトリに入れます。

おもむろに "depmod; modprobe e1000e" します。 "ip a" してインタフェースが見えれば成功です。

カーネル更新後

この記事を書いている2014年8月1日現在で手に入る最新カーネルの3.15.6-200.fc20ではI218Vに対応していますので、yum upgradeした後は特に対応不要です。

2014年7月9日水曜日

Systemdコマンド早見表(CentOS 7対応)

CentOS 7ではsystemdが導入されているので、サービスの管理が従来と大きく変わっています。詳しい解説はsystemd徹底入門のスライドを参照するとして、ここでは「前のコマンドはsystemdでどう入力するの?」というのだけ、簡単にまとめてみました。

サービス名にはsshdを指定していますが、もちろん任意のサービスが指定できます。

サービスの起動、終了など

操作SysV InitSystemd
起動/etc/init.d/sshd startsystemctl start sshd
終了/etc/init.d/sshd stopsystemctl stop sshd
強制終了PID探してkill -9systemctl kill -s 9 sshd
再起動/etc/init.d/sshd restartsystemctl restart sshd
設定反映/etc/init.d/sshd reloadsystemctl reload sshd
状態取得/etc/init.d/sshd statussystemctl status sshd
自動起動を有効chkconfig sshd onsystemctl enable sshd
自動起動を無効chkconfig sshd offsystemctl disable sshd
自動起動の状態確認chkconfig --list sshdsystemctl is-enabled sshd(status でも表示される)
サービス一覧の表示ls /etc/init.dsystemctl --type service

追記: SysV Init では service(8) コマンドを利用してサービスの再起動をすることが推奨されていますが、わかりやすさのため /etc/init.d のファイルを直接指定する書き方をしました。

ログのありか

SysV Initを使う場合は、/var/logの下をなんとなく探す、/var/log/messagesをgrepしてみるという使い方が多いと思います。Systemdには専用のjournalctlコマンドが用意されています。

特定のサービスのログを確認
journalctl -u sshd
tail -f
journalctl -f -u sshd
dmesgの代わり
journalctl -k または journalctl --dmesg
ログをJSONで取得
journalctl に -o JSON オプションをつける

その他管理機能

普段は使わないけど、知っておくと緊急時に役に立つかも機能。

シングルユーザーモードに入る
systemctl rescue
マルチユーザーモードに戻る
systemctl default

これで基本的な使い方はばっちり!

DockerをCentOS 7にインストールする方法

CentOS 7ではDockerをフル機能で利用することが可能です。

EPELレポジトリを有効にする

DockerはEPELレポジトリに含まれています。CentOS 7用のEPELレポジトリは現在ベータながら、すでに用意されています。

インストールするコマンドは次の通りです。

$ sudo yum install http://linux.mirrors.es.net/fedora-epel/beta/7/x86_64/epel-release-7-0.2.noarch.rpm

Dockerをインストールする

Dockerのパッケージ名は、docker-ioです。これをyumでインストールします。

$ sudo yum install docker-io

インストールした後に、サービスとして起動させるには systemctl start、ブート時に自動的にサービスを起動させるには systemctl enable を使います。

$ sudo systemctl start docker.service
$ sudo systemctl enable docker.service

これでDockerが利用できる状態になりました。 docker version で確認できます。

$ docker version
Client version: 1.0.0
Client API version: 1.12
Go version (client): go1.2.2
Git commit (client): 63fe64c/1.0.0
Server version: 1.0.0
Server API version: 1.12
Go version (server): go1.2.2
Git commit (server): 63fe64c/1.0.0

また、docker infoで、device mapperを利用していることが確認できます。

$ docker info
Containers: 3
Images: 1
Storage Driver: devicemapper
 Pool Name: docker-253:1-23349-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 465.8 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 0.9 Mb
 Metadata Space Total: 2048.0 Mb
Execution Driver: native-0.2
Kernel Version: 3.10.0-123.el7.x86_64

以上で、CentOS 7上でDockerを利用できる状態になりました。

参考: インストールのログ

参考のために、Dockerをインストールした時の進み方を貼り付けておきます。

[yuryu@centos7 ~]$ sudo yum install http://linux.mirrors.es.net/fedora-epel/beta/7/x86_64/epel-release-7-0.2.noarch.rpm
Loaded plugins: fastestmirror
epel-release-7-0.2.noarch.rpm                                                                    |  13 kB  00:00:00     
Examining /var/tmp/yum-root-0OMCgR/epel-release-7-0.2.noarch.rpm: epel-release-7-0.2.noarch
Marking /var/tmp/yum-root-0OMCgR/epel-release-7-0.2.noarch.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package epel-release.noarch 0:7-0.2 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

========================================================================================================================
 Package                     Arch                  Version              Repository                                 Size
========================================================================================================================
Installing:
 epel-release                noarch                7-0.2                /epel-release-7-0.2.noarch                 22 k

Transaction Summary
========================================================================================================================
Install  1 Package

Total size: 22 k
Installed size: 22 k
Is this ok [y/d/N]: y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : epel-release-7-0.2.noarch                                                                            1/1 
  Verifying  : epel-release-7-0.2.noarch                                                                            1/1 

Installed:
  epel-release.noarch 0:7-0.2                                                                                           

Complete!
[yuryu@centos7 ~]$ sudo yum install docker-io
Loaded plugins: fastestmirror
base                                                                                             | 3.6 kB  00:00:00     
epel/x86_64/metalink                                                                             |  13 kB  00:00:00     
epel                                                                                             | 3.7 kB  00:00:00     
extras                                                                                           | 2.9 kB  00:00:00     
updates                                                                                          | 2.9 kB  00:00:00     
(1/2): epel/x86_64/group_gz                                                                      | 163 kB  00:00:01     
(2/2): epel/x86_64/primary_db                                                                    | 2.0 MB  00:00:47     
Loading mirror speeds from cached hostfile
 * base: centos-distro.cavecreek.net
 * epel: linux.mirrors.es.net
 * extras: centos-distro.cavecreek.net
 * updates: mirror.supremebytes.com
Resolving Dependencies
--> Running transaction check
---> Package docker-io.x86_64 0:1.0.0-1.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

========================================================================================================================
 Package                      Arch                      Version                           Repository               Size
========================================================================================================================
Installing:
 docker-io                    x86_64                    1.0.0-1.el7                       epel                    4.5 M

Transaction Summary
========================================================================================================================
Install  1 Package

Total download size: 4.5 M
Installed size: 23 M
Is this ok [y/d/N]: y
Downloading packages:
docker-io-1.0.0-1.el7.x86_64.rpm                                                                 | 4.5 MB  00:02:39     
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : docker-io-1.0.0-1.el7.x86_64                                                                         1/1 
  Verifying  : docker-io-1.0.0-1.el7.x86_64                                                                         1/1 

Installed:
  docker-io.x86_64 0:1.0.0-1.el7                                                                                        

Complete!
[yuryu@centos7 ~]$ sudo systemctl start docker.service
[yuryu@centos7 ~]$ sudo systemctl enable docker.service
ln -s '/usr/lib/systemd/system/docker.service' '/etc/systemd/system/multi-user.target.wants/docker.service'

2014年7月8日火曜日

NetworkManagerの設定変更、nmtuiとnmcliについてまとめたよ!

RHEL 7, CentOS 7では、NetworkManager の利用が推奨されています。今まで /etc/sysconfig/network-scripts/ の下や、そのほかのコマンドを利用して行っていた設定が、一元的に設定できるようになっています。

ここでは、よく使うような設定を、実際の利用例とともにまとめてみました。

NetworkManagerをテキストベースで利用するには、大きく分けてnmtuiコマンドとnmcliコマンドがあります。それぞれ、テキストベースのUIと、コマンドラインツールになっています。

nmtui

最も簡単に使えるには、nmtuiコマンドです。実行すると、対話的にネットワークの設定を行うことが可能です。以下にスクリーンショットを掲載します。

いかがでしょうか? 基本的な設定はこのUIから可能です。少し変えてみる、初めて使ってみる場合にはこちらを利用するのが簡単です。

nmcli

nmcliを用いると、nmtuiとは対照的に、コマンドベースで設定変更を行うことができます。

nmcliは最後にhelpと入力すると、ヘルプが表示されます。コマンドごとのヘルプも、たとえば"nmcli connection help"や"nmcli conection up help"などのように入力すると表示されます。悩んだらhelpしましょう。

nmcliのコマンドは、前方一致で利用することが可能です。たとえばglobalはg、connectionはcといった具合です。もし一意に特定できない場合はエラーメッセージが表示されます。

それでは、それぞれの設定項目について、具体例を見ていきましょう。

ホスト名の表示、変更はnmcli global hostnameコマンドを利用します。この変更は、systemdで導入されたsystemctlコマンドと同期しています。

[yuryu@centos70 ~]$ nmcli general hostname 
centos70.local
[yuryu@centos70 ~]$ sudo nmcli general hostname centos7.local
[yuryu@centos70 ~]$ hostname
centos7.local
[yuryu@centos70 ~]$ hostnamectl 
   Static hostname: centos7.local
(省略)

NetworkManagerでは、ほとんどの設定が接続単位で保存されます。IPアドレスの設定なども接続ごとに行います。接続の一覧を表示するには、nmcli cと入力します。

[yuryu@centos7 ~]$ nmcli c
NAME         UUID                                  TYPE            DEVICE      
eno16777736  bf75cf80-fbeb-4b8f-b94c-778731bb2446  802-3-ethernet  eno16777736 

ifup / ifdown は nmcli connection up と nmcli connection down に置き換わります。

[yuryu@centos7 ~]$ sudo nmcli connection down eno16777736
[yuryu@centos7 ~]$ sudo nmcli connection up eno16777736
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/11)

なお、それぞれ nmcil c d, nmcli c u と省略することが可能です。ほかのコマンドも同様です。

接続の情報を取得するには nmcli connection show を使います。

[yuryu@centos7 ~]$ nmcli connection show eno16777736
connection.id:                          eno16777736
connection.uuid:                        bf75cf80-fbeb-4b8f-b94c-778731bb2446
connection.interface-name:              --
connection.type:                        802-3-ethernet
connection.autoconnect:                 yes
(ずらずら)

特定の設定のみを表示するには --fields オプションを追加します。

[yuryu@centos7 ~]$ nmcli --fields dhcp4 connection show eno16777736
DHCP4.OPTION[1]:                        requested_domain_search = 1
DHCP4.OPTION[2]:                        requested_nis_domain = 1
DHCP4.OPTION[3]:                        requested_time_offset = 1
(ずらずら)

設定を書き換えるには、nmcli connection modify コマンドを利用します。 書き換えた設定は一度接続を down / up させないと反映されません。

ここの例は、DHCPを無効にして、手動でアドレスを設定する例を示しています。ipv4.addressesは、"アドレス/プレフィックス長 デフォルトゲートウェイ"という形で指定します。

[yuryu@centos7 ~]$ sudo nmcli connection modify eno16777736 ipv4.method manual ipv4.addresses "172.16.105.201/24 172.16.105.2"
[yuryu@centos7 ~]$ # con mod は connection modify の省略形です
[yuryu@centos7 ~]$ sudo nmcli con mod eno16777736 ipv4.dns "8.8.8.8 8.8.4.4"
[yuryu@centos7 ~]$ sudo nmcli con mod eno16777736 ipv4.dns-search "local"
[yuryu@centos7 ~]$ nmcli --fields ipv4 connection show eno16777736
ipv4.method:                            manual
ipv4.dns:                               8.8.8.8, 8.8.4.4
ipv4.dns-search:                        local
ipv4.addresses:                         { ip = 172.16.105.201/24, gw = 172.16.105.2 }
ipv4.routes:                            
ipv4.ignore-auto-routes:                no
ipv4.ignore-auto-dns:                   no
ipv4.dhcp-client-id:                    --
ipv4.dhcp-send-hostname:                yes
ipv4.dhcp-hostname:                     --
ipv4.never-default:                     no
ipv4.may-fail:                          yes
[yuryu@centos70 ~]$ # connection down, connection up をそれぞれ c d, c u と省略できます
[yuryu@centos70 ~]$ sudo nmcli c d eno16777736 ; sudo nmcli c u eno16777736
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/14)
[yuryu@centos7 ~]$ cat /etc/resolv.conf 
# Generated by NetworkManager
search local
nameserver 8.8.8.8
nameserver 8.8.4.4

設定の一部を消去したり、追加したりするには、フィールド名の前に -, + をつけます。

[yuryu@centos7 ~]$ sudo nmcli con mod eno16777736 -ipv4.dns 1
[yuryu@centos7 ~]$ nmcli --fields ipv4.dns con show eno16777736
ipv4.dns:                               8.8.8.8
[yuryu@centos7 ~]$ sudo nmcli con mod eno16777736 +ipv4.dns 8.8.4.4
[yuryu@centos7 ~]$ nmcli --fields ipv4.dns con show eno16777736
ipv4.dns:                               8.8.8.8, 8.8.4.4

DHCPに戻すには次のようににします。

[yuryu@centos7 ~]$ sudo nmcli con mod eno16777736 ipv4.method auto
[yuryu@centos7 ~]$ sudo nmcli con mod eno16777736 ipv4.dns '' ipv4.dns-search '' ipv4.addresses ''

デバイスの一覧を表示するには nmcli deviceと入力します。

[yuryu@centos7 ~]$ nmcli device
DEVICE       TYPE      STATE      CONNECTION  
eno16777736  ethernet  connected  eno16777736 
lo           loopback  unmanaged  --  

また、このデバイスに紐付いている情報を表示するには、nmcli device showコマンドを利用します。

[yuryu@centos7 ~]$ nmcli device show eno16777736
GENERAL.DEVICE:                         eno16777736
GENERAL.TYPE:                           ethernet
GENERAL.HWADDR:                         00:0C:29:00:00:00
GENERAL.MTU:                            1500
GENERAL.STATE:                          100 (connected)
GENERAL.CONNECTION:                     eno16777736
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/ActiveConnection/15
WIRED-PROPERTIES.CARRIER:               on
IP4.ADDRESS[1]:                         ip = 172.16.105.141/24, gw = 172.16.105.2
IP4.DNS[1]:                             172.16.105.2
IP4.DOMAIN[1]:                          localdomain
IP6.ADDRESS[1]:                         ip = fe80::20c:29ff:feb3:34dd/64, gw = ::

NetworkManagerとは関係ありませんが、従来ifconfigで見れていた、インタフェースごとの通信量を見るには、ipコマンドを使うと可能です。

[yuryu@centos7 ~]$ ip -s l 
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    RX: bytes  packets  errors  dropped overrun mcast   
    340        4        0       0       0       0      
    TX: bytes  packets  errors  dropped carrier collsns 
    340        4        0       0       0       0      
2: eno16777736:  mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
    link/ether 00:0c:29:00:00:00 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast   
    7926980    13565    0       0       0       0      
    TX: bytes  packets  errors  dropped carrier collsns 
    1143281    7208     0       0       0       0      

新規の接続の追加はconnection addコマンドで行います。typeでイーサネットを示すethを、ifnameでインタフェース名を、con-nameで新しく追加する接続名を追加します。

# nmcli c add type eth ifname eth1 con-name eth1
# nmcli c mod eth1 ipv4.method manual ipv4.addresses "192.168.122.69/24 192.168.122.1"
# nmcli c down eth1
# nmcli c up eth1

いかがでしょうか。対応さえわかれば、ここ一カ所で操作することが可能で、あっちこっち見なくてよくなるので、意外と簡単ということがわかります。是非disableにせず、使ってみましょう。

CentOS 7 がリリースされたので、情報をまとめてみたよ!

CentOS の新しいメジャーリリース、 CentOS 7がリリースされました!

お断り:ここの情報は非公式なもので、ベストエフォートで提供されています。

国内ミラー状況

公式サイトには掲載されていませんが、国内の有力ミラーサイトがすでにミラーを終えています。

バージョン番号の変更

今回からバージョン番号が 7.0-1406、というように、末尾に数字がつくようになりました。 7.0 は upstream である Red Hat Enterprise Linux 7 (RHEL 7)に対応、RHEL 7にupdateが出ると、対応するように 7.1, 7.2 と増加します。1406はリリースされた年月を表します。これは、更新されたメディアイメージをクラウドやコンテナに持って行きやすくするために付いています。ですので、同じ7.0ベースでも、末尾の年月が新しい方は新しいパッケージを含んでいるということになります。

CentOS 7の変更点

RHEL 7にほぼ準拠しますが、リリースノートには以下の項目が示されています。

  • カーネルが 3.10.0 に更新
  • Linuxコンテナのサポート
  • Open VMware Toolsと3Dグラフィックドライバが標準装備
  • OpenJDK 7が標準のJDKに
  • 6.5から7.0にそのまま更新可能
  • ext4とXFSでLVM snapshotが利用可能
  • systemd, firewalld, GRUB2の採用
  • XFSが標準のファイルシステムに
  • iSCSIとFCoEがカーネル空間に移動
  • PTPv2, 40GbE, 互換性のあるハードウェアでのUEFI Secure bootのサポート

あわせて読みたい: Red Hat Enterprise Linux 7 の新機能

FAQ

なぜか公式のFAQ一覧にリンクが張られていませんが、CentOS 7用のFAQが既に存在します。詳しくはそちらを参照していただくとして、結構重要そうなものを軽くピックアップ。

  • boot.iso は netinstall.iso に名前が変わりました
  • イーサネットのネットワークインタフェースは標準では有効になりません
  • /etc/sysconfig/network-scripts/ を直接編集するのではなく、NetworkManagerを使いましょう(追記: 基本的な設定方法をまとめました)
  • ネットワークインタフェースの名前が変わってます。慣れましょう
  • 32bit CPUは切り捨てられました
  • IPv6 を無効にするのは時代遅れのテクです

既知の問題

リリースノートに書かれている既知の問題は次の通り(2014年7月8日現在)。

  • ネットワークインタフェースが標準では有効にならない。これはRHEL 7での変更によるもので、仕様変更である。詳しくはFAQを参照(英語)
  • インストーラーは最低406MBのメモリを要求する。CentOS 7の必要メモリ量は 512MB である
  • VirtualBoxのUEFIモードで、ファイルシステムの暗号化を有効にした状態でインストールすると、システムが起動しない。バグレポートを参照のこと
  • 画面の解像度が800x600より小さい場合に、インストール画面の下部のボタンが途切れる
  • .isoイメージのルートディレクトリにあるEULAが古く、テスト用のまま。正しいEULAはインストール後に /usr/share/centos-release/EULA で参照可能

UpstreamであるRHEL 7のknown issuesも参照のこと(英語)

2014年6月10日火曜日

x86 Linux上で sysenter 命令を使ってシステムコールを呼び出す方法

x86(32bit)環境で、どのようにシステムコールが呼ばれているのかを調べてみました。

int 80h

昔からあるシステムコールの呼び方で、eax レジスタにシステムコールの番号をセットした後、ソフトウェア割り込みの int 80h をコールするとシステムコールが呼ばれます。これはどのバージョンの Linux でも使えます。ただし、ソフトウェア割り込みは遅いのが欠点です。

sysenter

最近のIntelのプロセッサはすべて sysenter というシステムコール専用の命令が用意されています。この命令は int 80h に比べるとかなりシンプルで、予め設定されたシステムコールハンドラのアドレスをCS:EIPとSS:ESPにセットして、特権モードに切り替えて実行を再開するのみです。詳しくは「64ビットCPU(AMD64+EM64T)でアセンブラ int 2E/sysenter/syscall考察」が参考になります。

さてここでのポイントは、sysenter命令はユーザーモード空間での実行アドレスをスタックやレジスタに退避しないということです。通常の call 命令や int 80h 命令の場合は、スタックに CS:EIP を push してから jmp します。sysenter ではどこにも保存されません。ではsysexitはどのように戻っているのでしょうか。sysexitは

  1. ESP ← ECX
  2. EIP ← EDX
  3. CS ← (MSR に書かれたセレクタ + 16) OR 3
  4. SS ← CS + 8

的なことをやって ring 3 に戻ります。

さてここで疑問ですが、sysenterで保存しないのにどうやってsysexitでESPとEIPを復元しているのでしょうか。不思議ですよね。

答えは、「sysenterを呼び出すのは決められたサブルーチンに限る」です。少なくとも Linux ではユーザープログラムから直接 sysenter を呼び出すことはありません。戻るときは、カーネルがその「決められたサブルーチン」の値を直接指定して戻ります。そこから改めてユーザープログラムに ret します。

ここで、アセンブリで直接 syscall を呼び出すサンプルプログラムを見てみましょう。

実行例は次のようになります。

$ ./a.out 
syscall point = 0xb775a414
pid = 13734, pid10 = 13734
08048000-08049000 r-xp 00000000 fd:00 812670     /home/yuryu/src/a.out
08049000-0804a000 r--p 00000000 fd:00 812670     /home/yuryu/src/a.out
0804a000-0804b000 rw-p 00001000 fd:00 812670     /home/yuryu/src/a.out
09370000-09391000 rw-p 00000000 00:00 0          [heap]
b7568000-b7569000 rw-p 00000000 00:00 0 
b7569000-b7721000 r-xp 00000000 fd:00 391110     /usr/lib/libc-2.18.so
b7721000-b7723000 r--p 001b8000 fd:00 391110     /usr/lib/libc-2.18.so
b7723000-b7724000 rw-p 001ba000 fd:00 391110     /usr/lib/libc-2.18.so
b7724000-b7727000 rw-p 00000000 00:00 0 
b7738000-b773b000 rw-p 00000000 00:00 0 
b773b000-b775a000 r-xp 00000000 fd:00 397102     /usr/lib/ld-2.18.so
b775a000-b775b000 r-xp 00000000 00:00 0          [vdso]
b775b000-b775c000 r--p 0001f000 fd:00 397102     /usr/lib/ld-2.18.so
b775c000-b775d000 rw-p 00020000 fd:00 397102     /usr/lib/ld-2.18.so
bfed0000-bfef1000 rw-p 00000000 00:00 0          [stack]

gs:[10h]に保存されているアドレスに対して call すると、システムコールが実行されます。この例の場合、0xb775a414 が保存されていますが、これはちょうど "vdso" と呼ばれている領域が該当します。この vdso というのは、カーネルがユーザープログラムから使えるように、共有ライブラリとして自動的にリンクしている領域です。

gs:[10h] に含まれているコードを見てみましょう。

レジスタを保存して sysenter しているコードが見つかりました。EDXと ECXを保存しているのは、上述の通り sysexit で使用するからです。ebp を保存しているのは、システムコールからユーザースタックにアクセスすることがあるからです。 nop の後に int 80h が見えますが、これはシステムコールをリスタートする時に使うもので、通常はここを通らずその後の pop ebp から実行が再開されます。

このvdsoのアドレスはカーネルが知っているので、カーネルは決め打ちでEDXとECXをセットすることができます。どこに戻るかの情報は

thread_info 構造体の sysenter_return に入ってます。これがシステムコールハンドラでECXにセットされます。

最後の謎は gs:[10h] って何?というところですが、Linux の x86 では gs は thread local storage を指しているそうです。で、ここに glibc が起動時に vdso のこのアドレスを探してきて保存しているようでした。

というわけで sysenter って int 80h のようなノリで使うものじゃ無いっぽいですね。 Windows も同じような仕組みだったのでしょうか。 x64 で使用している syscall 命令は、RCX に RIP を保存するので、ユーザープログラムのどこからでも syscall できるみたいです。

参考文献

2014年5月8日木曜日

LinuxでTCP_DEFER_ACCEPTが有効でもaccept後readできない理由

listen()のbacklogが不足した際のTCP_DEFER_ACCEPTの動作について - blog.nomadscafe.jpという記事の中で、listen backlog があふれた後に accept(2) すると、その後の read(2) が EAGAIN を返したり、接続が不安定になるという事象が説明されていました。気になったので調べてみたことをまとめます。

結論から言うとこれはLinuxの仕様です。manのtcp(7)を見ると、

TCP_DEFER_ACCEPT (since Linux 2.4)

Allow a listener to be awakened only when data arrives on the socket. Takes an integer value (seconds), this can bound the maximum number of attempts TCP will make to complete the connection. This option should not be used in code intended to be portable.

「TCP_DEFER_ACCEPTで指定した秒数を過ぎるまではacceptを遅らせるよ!」と書いてあります。つまりこれを過ぎると、データが到着していなくてもacceptできてしまう場合があります。

なんでこんなことになっているのか、パッチを見てみましょう。tcp: accept socket after TCP_DEFER_ACCEPT periodというパッチにヒントがあります。要約すると

タイムアウトでSYN-ACKを再送するたびにACKを返してくるクライアントに対しては、TCP_DEFER_ACCEPTで指定した秒数を過ぎたらESTABLISHEDにしたほうが良い。そうしたらサーバープログラムがもっと待つか、エラーとして接続を閉じるか選ぶことができる。副作用としてはaccept(2)したら必ずデータがあると思ってるアプリケーションに対しては副作用があるけど、もともとTCP_DEFER_ACCEPTが有効でも無効でも動作するように設計するほうが良いよね。

とあります。

そもそもTCP_DEFER_ACCEPTはどのような動作になっているのでしょうか? tcp_minisocks.c の tcp_check_req() を見ると、単にACKを落とすだけの処理になっています。

    /* While TCP_DEFER_ACCEPT is active, drop bare ACK. */
    if (req->num_timeout < inet_csk(sk)->icsk_accept_queue.rskq_defer_accept &&
        TCP_SKB_CB(skb)->end_seq == tcp_rsk(req)->rcv_isn + 1) {
        inet_rsk(req)->acked = 1;
        NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPDEFERACCEPTDROP);
        return NULL;
    }   

この状態でクライアントが次にデータを送ってくると、そのままSYN_RECVからESTABLISHEDにしてしまうようになっています。言い換えると、SYN_RECVの状態のソケットでもデータを受信する場合があり、ESTABLISHEDな状態になるということです。ここでaccept backlogがいっぱいだとlisten overflowになり、だまってパケットが落とされます。この時サーバーはSYN_RECVのままですが、クライアントはESTABLISHEDという奇妙なことになります。サーバー側はタイムアウトを迎えSYN+ACKを再送します。クライアント側はそれに対応するACKを返送しますが、やっぱり無視されます。そのうちクライアントは再送タイムアウトを迎えデータを再送します。それでもaccept backlogがいっぱいだと再びパケットが落ちます。そのうち指定秒数過ぎた後にSYN+ACKがサーバー側から再送(この時点ではソケットの状態はSYN_RECV)されてきてクライアントがACKを返し、さらにそのタイミングでaccept backlogに空きがあった場合にデータの存在しないソケットができる事になります。クライアントは再送タイムアウトを迎えた後データを送信します。

追記: ブコメの指摘で、頻繁にSYN+ACK を再送するのは古い動作だということがわかりました。Patch: tcp: reduce SYN-ACK retrans for TCP_DEFER_ACCEPT この場合、SYN+ACKが最初に再送されるのはTCP_DEFER_ACCEPTでの指定秒数が経過してからとなります。

というわけで、 TCP_DEFER_ACCEPT はあくまで「遅らせる」だけなので、accept(2)すれば必ずread(2)できるということを保証しないということでした。

2014年1月28日火曜日

somaxconnの上限値は65535

Linuxのネットワークパラメータの一つに、net.core.somaxconnというのがあります。これはlisten(2)の第二引数backlogの上限値となっています。このsomaxconnは一見intに見えますが、実はunsigned shortの範囲の数値しか受け付けません。それを超える数値を入れると黙って切り捨てられます。つまり

  • -1→65535
  • 0→0
  • 65535→65535
  • 65536→0
  • 65537→1

と同じような動作を内部的にします。なので、この値は絶対に0~65535の範囲を超えてはいけません。以下、詳しい説明です。

おことわり: この仕様はLinux 3.11以降変更されており、範囲外の数値を設定できないようになっています。ここに書いてある内容が再現するのは、Linux 3.10以前の古いカーネルのみです。

まずsysctlの定義ですが

net/core/sysctl_net_core.c

static struct ctl_table netns_core_table[] = {
 {
  .procname = "somaxconn",
  .data  = &init_net.core.sysctl_somaxconn,
  .maxlen  = sizeof(int),
  .mode  = 0644,
  .proc_handler = proc_dointvec
 },

include/net/netns/core.h

struct netns_core {
        /* core sysctls */
        struct ctl_table_header *sysctl_hdr;

        int     sysctl_somaxconn;

        struct prot_inuse __percpu *inuse;
};

以上のようにしっかりと"int"と書かれています。

さて、この値がどう使われているかというと、listen(2)でbacklogの最大値として利用された後inet_listenに引き渡されます。

net/ipv4/af_inet.c

int inet_listen(struct socket *sock, int backlog)
{
        struct sock *sk = sock->sk;
        unsigned char old_state;
        int err;
(途中省略)
        sk->sk_max_ack_backlog = backlog;
        err = 0;

out:
        release_sock(sk);
        return err;
}

という感じで、socket.sk_max_ack_backlogに渡されています。この値の宣言を見ると

include/net/sock.h

struct sock {
(途中省略)
        unsigned short          sk_ack_backlog;
        unsigned short          sk_max_ack_backlog;

unsigned shortとなっています。intをunsigned shortにそのまま代入してますね。なので、一番上に書いたようにオーバーフローします。黙ってオーバーフローします。net.core.somaxconnの値は正しくセットされるのが余計にたちが悪いですね。

ところでbacklog=0ってなんでしょうか?全くacceptできないように思えますが、実はキューの長さは

include/net/sock.h

static inline bool sk_acceptq_is_full(const struct sock *sk)
{
        return sk->sk_ack_backlog > sk->sk_max_ack_backlog;
}

という感じで不等号で比較されているので、最低一つはaccept待ちのソケットが使用できます。

これはTCPのコードですが、unix domain socketでも似たような事象が起こります。

あと何年かすれば役に立たなくなる感じの知識ではありますが、今のところsomaxconnは16bitです。

2014年1月22日水曜日

ssh で id_rsa と違うキーの id_rsa.pub が置いてあるとログイン出来ない

sshでログインする際にローカルホストで使用する鍵は.ssh/id_rsaですが、この時このid_rsaと異なる鍵の公開鍵がid_rsa.pubとして置かれていると、そちらを参照してしまいログインできないという状況が発生しました。

再現手順は以下のとおり。

  1. ssh-keygen -t rsa -b 2048 で適当に鍵を作る
  2. mv .ssh/id_rsa .ssh/id_rsa2 としてバックアップ
  3. ssh-keygen -t rsa -b 2048 でもう一つ鍵を作る
  4. mv .ssh/id_rsa2 .ssh/id_rsa として秘密鍵を戻す

これで正しい秘密鍵を見ているはずなのに、ログインできなくなります。デバッグ出力には

debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/yuryu/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/yuryu/.ssh/id_dsa
debug1: Trying private key: /home/yuryu/.ssh/id_ecdsa
debug1: Next authentication method: password

と出力されています。この「Offering RSA public key」が、.pubを見ているという出力です。 もし.pubが存在しないと

debug1: Next authentication method: publickey
debug1: Trying private key: /home/yuryu/.ssh/id_rsa
debug1: read PEM private key done: type RSA

といったログ出力になります。

この公開鍵がなぜ使われているのかまでは調べていませんが、おそらく公開鍵の計算をサボるために、公開鍵がすでに存在したら読み込むといった感じで使っているのではないかと思います。

ぐぐってもパーミッションの設定を間違えているケースばかりで、このハマり方をしている人はいませんでした。無駄に2時間ぐらい悩みました...

2014年1月15日水曜日

Linux Kernel Updates Vol.2013.12 の Kindle版を出しました

コミケ85で頒布した、Linux Kernel Updates Vol.2013.12 の Kindle版を出しました。

Linux Kernel Updates 2013.12の購入はこちらから!

以下は冊子版のプレビューです

目次

  • What's New in Linux 3.11?
  • What's New in Linux 3.12?
  • TCP/IPチューニング特集

TCP/IPチューニング特集はsysctlで設定できるパラメーターについて詳しく説明しています。紛らわしい設定、間違えやすい設定についてカーネルコードを参照しながら正確な説明を心がけました。

Linux Kernel Updates 2013.12の購入はこちらから!

2013年12月26日木曜日

コミケ85にLinux本を出します(3日目西せ18a)

コミケ85に「低級はっかーズ」として出展します。3日目(火曜日)西せ18aです。

今回の新刊は "Linux Kernel Updates 2013.12" です。価格は300円です。内容は

  • What's New in Linux 3.11?
  • What's New in Linux 3.12?
  • TCP/IPチューニング特集
です。下にプレビューを掲載します!

TCP/IPチューニング特集は主にsysctlのパラメータを解説しています。自称日本語で一番詳しい解説になっています!

表紙は毎度おなじみきのとなおとさんに描いていただきました。

前回までの既刊2冊も持っていきます。こちらも一冊300円です。よろしくお願いします!

2013年11月28日木曜日

Fedora最新技術情報&Systemd勉強会に参加してきました

Linux女子部主催のFedora最新技術情報&Systemd勉強会に参加してきました。

Fedora最新技術情報

講師は藤田稜さん

Fedora最新技術情報といいつつRHEL7のお話でした。いくつか気になった点をピックアップします。

xfsがデフォルトになるかも

RHEL7ではxfsをデフォルトファイルシステムにしたいそうですが、まだ安定性やメモリ消費量に難があり、技術的な観点から決定はしていないそうです。

「RHEL 4, 5, 6 の初期出荷でファイルシステムの破損バグを仕込んだ実績があるので、今からxfsに切り替えたら絶対何か踏む」という声も。

iptablesからfirewalldへ

今までファイアウォールはiptablesを使っていましたが、標準でfirewalldを使うように変更します。従来のiptablesとは排他利用になります。戻すことはできますが、基本的にはfirewalld推奨とのこと。設定を読み込み直すときにreloadしてもセッションが切れなくなっているそうです。

またそれに伴いNetworkManagerが必須となるようで、今まで殺していた人はうまく付き合ってくださいとのことでした。

OpenLMI導入

OpenLMIという管理系機能の共通インタフェースがあるそうなんですが、それがRHEL 7.0GAには入るんじゃないかということ。従来例えばファイルシステムだけ取っても fdisk, gparted, lvm, mkfs など様々なコマンドがバラバラにあったものが、整理され統合されるんだとか。

その他

その他は、systemd入りますよ(後述)、Linux Containerのフルサポート、pNFSのクライアントサポート、実はSELinux enforcedでしかQAしてないので、permissive/disabledはテストしていませんというお話などが聞けました。

大きくはやはり管理系の仕組みがsystemd, OpenLMI, firewalld, NetworkManagerというものに置き換わるのが大きな変更点のようです。「カーネルランドは同じだけどユーザーランドは違うOSと言っても良いほどの変更」と言われていました。

Systemd徹底入門

講師は中井悦司さん

今回のお話のスライドはslideshareにアップロードされていて、時間の都合で省略されたところも含めて詳しく解説されています。ここで細かい話を書いても実際スライドのほうが詳しいので、私が疑問に思った点や補足を中心に記述します。

SysV Init から systemdへ

従来は SysV Init が /sbin/init に存在して最初にpid=1として起動していましたが、代わりに/usr/bin/systemdが起動します。今までは単なるシェルスクリプトが/etc/inittabに定義された順に実行されていたので、シリアルにしか実行できず性能も悪かったものが、systemdではそれぞれのタスクを細かくunitという単位に定義して依存関係と前後関係に基づいて並列的に実行し、起動速度を高速化します。

systemdを作ったのはレナートさんで、彼のblogにどうしてsystemdを作ったのかが載っているので、英語ですがぜひ読んでみてくださいとのこと。systemd の大きな目的は4つあって、

  • システム起動時間の短縮
  • システム構成の動的変更に対応
  • プロセス停止処理を標準機能として提供
  • デーモンの実行環境を制御

です。

依存関係と前後関係

SystemdではRequire/WantedByという依存関係と、Before/Afterという前後関係にもとづいてunitの実行順が決定されます。ここで依存関係というのは単に必要だということを記述するだけで、実際にはその中では平行にunitが実行されていきます。そのため、例えばhttpdが起動する前にDNSが起動しておいてほしい、というようなことはすべて前後関係として記述するようです。

アプリケーションサービスなどもsystemd管理下へ

init だとクラッシュした時の再起動がないので、よくアプリケーションサービスなどを supervisord や daemontools を使って別に起動させていた方も多いと思いますが、基本的には systemd がこれらも含めてすべて見るようにするのが理想的ということです。cgroupを使ってプロセスツリー全体のリソースも管理でき、ログ管理機能もあるのでsystemd管理下に置くほうがシステム全体として整合性も取れるような印象です。

また従来はdaemonizeすることが多かったところsystemdではdaemontoolsのようにforegroundで実行するのが基本的なスタイルになるようです。Typeを変えればforkするデーモンにも対応可能です。

便利そうなコマンド

systemctl status (unit名)すると、関連するプロセスの一覧やログの抜粋が表示される。

systemctl list-units すると、現在有効なunitの一覧が表示され、起動に失敗しているものもひと目でわかる。

systemctl list-dependencies (unit名) すると、依存関係がツリー状に表示される。

manページを読もう

作者のレナートさんがドキュメント魔らしく、manページが大変充実しているので、困っても困らなくてもmanページを読めば良いとのことでした。

感想

systemdという巨大な仕様のものを入れることにRed Hat社内でも議論があったそうですが、結局のところ SysV Init がイケてないし置き換えることは必要で、より良いデーモン管理のため導入することにしたそうです。話を聞くと使う分にはちゃんと動きそう、だけども何でもsystemdにやらせるのは「Unixぽくない」と感じます。

浸透のためにはDebianやGentooもsystemdに移る必要があると思うし、もし今後initが複数使われるのであればソフト作者はsystemd用、upstart用というふうにわけて起動スクリプトを用意しなければいけなくなるかもしれません。そういうのは望ましくないので、なんとか一本化してほしいなぁと思いました。

2013年10月26日土曜日

献本御礼: 独習Linux専科 サーバ構築/運用/管理

著者の中井悦司さんから「独習Linux専科」サーバ構築/運用/管理をいただきました。ありがとうございます。僭越ながら書評を書きました。

Linuxを始める人にぴったり

初心者のかたで、これからLinuxを初めて使おうという方には非常におすすめできる本です。インストールの仕方から基本的なコマンドライン操作、システムの概念が解説されています。そして最後にはSamba, PostgreSQL, Ruby on Railsのサーバーを構築する手順まで書かれています。特にWindowsから入ると馴染みのないパッケージ管理(yum/rpm)やシェルの文法などには多くの紙面が割かれています。

最近はインターネットを検索すると多くの入門記事を見つけることができますが、それでもOSの入門書籍は役に立つと思います。ネットで検索するとディストリビューションが微妙に違ったり、バージョンが微妙に違ったりで「自分の環境に適用出来るか?」を考えなければなりませんが、この本は非常に網羅的に書かれていますので順序立てて学習することができます。

さらに、Fedora 17という比較的最近の2012年5月にリリースされたOSに準拠していることも特徴です。実はネット上の記事の多くはこのバージョンに追いつけていません。Fedoraは最近になって、プロセス管理がinitからsystemdに変更になりましたが、その新しい方法を説明しているのは非常に限られています。もし仕事でLinuxを使うならば、Red Hat Enterprise Linux や CentOS などを使う可能性がありますが、次のバージョン 7 では同じくsystemdが採用されるので、その予習にもなります。

Red Hat系Linuxを学習する最初の一冊としておすすめです。

Linuxのことは知ってる、という方へ

少しLinuxを知っている人がこの本を読んだ場合は、知識の網羅性の確認になると思います。

前述のとおりsystemdの解説はネット上にもほとんどありません。Systemd入門(1) - Unitの概念を理解するというのが日本語で書かれた数少ない記事ですが、実はこの記事を書いた方がこの本の著者です。systemdの解説は7ページほどしかありませんので、あくまで他の記事と合わせて、になります。

他にもSELiunx, setuid/setgid/sticky ビット、find -mtime の -2, 2, +2 の違いなど中級者が「少し自信がないかも」というような内容もカバーされてます。意外とググりながら勉強していく方式だと、自分が直面した課題以外は見過ごされがちなので、そういう方にも使っていただけると思います。逆に今上げたキーワードはわかってるよ、というレベルの方には物足りないと思います。

また、50ページ程度がSamba, PostgreSQL, Railsのインストールと設定に割かれているので、OSのインストールは出来たけれどこのあたりをやったことがないよーという人にも役に立つと思います。

まとめ

  • Linux初学者のために最適
  • 学んだ内容は次のRHEL7にも生きる