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年10月12日日曜日

C言語で理解する英語の冠詞(aとtheの使い分け)

英語の冠詞は、実はプログラマーにはとてもわかりやすいんです。

変数宣言はa, 参照はthe

int i;

i = 100;

1行目のint iは宣言なので「a」です。"Declare an integer variable."

次の i = 100 はその変数を参照しているので「the」です。 "Assign 100 to the integer variable."

仮引数と戻り値はa

int func(int v)
{
    return v * 2;
}

関数の仮引数と戻り値は「a」です。"This function takes an integer argument and returns an integer value."

もちろん、その引数を関数内で使う場合は「the」になります。"Double the first argument and return the result."

まとめ

特定の変数についてだけ会話するときは「the」ですが、それ以外は「a」です。日常会話もそんな感じです。

2014年9月30日火曜日

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

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

目次

  • 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年9月21日日曜日

RubyKaigi 2014で、多様性の話とRails Girlsの紹介をしました

RubyKaigi 2014に3日間参加し、2日目に"Rails Girls: Not Only for Girls"というタイトルで、発表してきました。

Tech companyと呼ばれるUSの会社でも、女性技術者の割合は2割程度にとどまっていて、各社技術者の確保に苦労しているようです。日本での私の経験では、分野にもよりますがおおむね1割程度で、USよりもさらに女性技術者が少ないと感じています。

プレゼン中でも触れた次の動画に象徴されるように、文化的・社会的な要素と深く結びついていて、一朝一夕に変わるものではありません。もちろん車輪の両輪として、公平な採用、職場での性差別をなくすということは進めていく必要があります。

そんな中、長期的な目線で状況を改善していこうと、いくつもの活動が立ち上がっています。Rails Girls もその一つです。

Rails Girls だけでなく、世界中でいろんな人が様々な活動に取り組んでいます。 GoogleのWomen Techmakersというページに様々なコミュニティ活動へのリンクがあります。また、学会でもACM-WIEEE Women in Engineeringなどに代表されるような活動があります。ぜひ身近な活動に参加してみてください。

非常に難しい問題ではありますが、一歩ずつ良くなっていくことを願っています。

PS: RubyKaigi 2014では私の知る限り、昨年のような問題もなく、非常に良かったと思いました。関係者の皆様はじめ、参加者すべての方の尽力に感謝します。

2014年8月26日火曜日

無線LANを暗号化すればのぞき見されないという誤解

今日のニュースに次のようなものがありました。

無線LANのメール丸見え 成田、関西、神戸の3空港

成田、関西、神戸の3空港が提供する無料の公衆無線LANサービスでインターネットを利用した場合、送信したメールの宛先や中身、閲覧中のウェブサイトのURLを他人がのぞき見できる状態になることが26日、神戸大大学院の森井昌克教授(情報通信工学)の実地調査で確認された。

無線LANを暗号化すればのぞき見を防止できるが、パスワードの入力などが必要となり、3空港は利便性を考慮し暗号化していないという。

無線LANのメール丸見え 成田、関西、神戸の3空港 - 47NEWS(よんななニュース)より引用

「無線LANを暗号化すればのぞき見を防止できる」というのは、誤解です。

無線LANの暗号化方式には複数あり、WEP, TKIP, CCMP(AES)の3種類が使われています。これらは暗号化の方式を定めただけで、鍵交換(パスフレーズの認証)は別の規格です。それぞれ WEP, WPA2-Personal(PSK), WPA2-Enterprise の3種類です。WEPだけは暗号化方式、鍵交換の両方を定めていて、WPA2は暗号化と鍵交換の方式を組み合わせて使うことができます。

WEPWPA2-Personal(PSK)WPA2-Enterprise
WEP危険--
TKIP-危険危険
CCMP(AES)-事前共有鍵を持っている人は、他人の通信内容を見れる一人一人認証鍵が違うので、他人の通信を見れない

まず、WEP、WPA、TKIPを使うWPA2は危険なので使わないようにしましょう。これらには脆弱性が見つかっています。使っていいのはWPA2-CCMP(AES)の組み合わせのみです。表には掲載していませんが、WPAもWPA2と同様に組み合わせを選ぶことができますが、WPA2に置き換わっているので使わないようにしましょう。

家庭や無線LANのホットスポットで利用されるのは WPA2-Personal と言われるタイプで、事前にPSK(Pre-shared key, 事前共有鍵)を決めてパスワードにします。これはこの事前共有鍵を知らない人には内容は読まれないのですが、鍵を持っている人には内容が見えます。つまり、不特定多数で同じパスワード(PSK)を使い回すような環境では、WPA2-Personalで保護されていたとしても、パスワード(PSK)を知っている人には内容が見えてしまいます。

WPA2-Personalでは、接続時にPSKを元に暗号化に使うセッション鍵を決定します。このセッション鍵は無線LANの端末ごとに割り当てられ、お互いに知ることはできません。ところが、PSKと、接続時の鍵交換の情報があればセッション鍵が計算されてしまいます。鍵交換は平文で行われます。そして、無線LANでは「切断する」というパケットは暗号化されないので、第三者が他人になりすまして「切断する」というパケットを送れてしまいます。端末は切断されたことを知ると再接続しようとしますが、そのときには鍵交換の内容を盗み見られるので、セッション鍵を入手され、その後の通信は盗み放題となってしまいます。

ということで、無線LANの暗号化は「パスワードを知らない人からは守られるけど、パスワードを知っている人には他人であっても通信内容が見えている」というものです。

WPA2-Enterpriseでは、一人一人に違う鍵(パスワードや証明書)を割り当てるので、このような問題は起こりません。

追記: WPA2-Personalは、家庭内のように全員が信頼できる環境で安全な無線LANを構築するには十分なもので、有線LANに近い水準のセキュリティが実現できます。不特定多数がPSKを知っている環境では意味が無いよ、ということです。

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月21日月曜日

成長したいので本棚を載せてみる

成長したいエンジニアは良いエンジニアの本棚を真似るといいんじゃない? - Lean Baseballという記事があって、その中で

「本棚を真似る」エンジニアから「本棚を真似られる」エンジニアへ

というお話がありました。確かに本棚を共有するのは、私がどんなことに興味があるのかわかってもらうとても良い方法だと思うので、家の本棚写真を一挙公開です!

なお、ここにある本の他に、実家にあるもの、会社の本棚にあるもの、Kindleで読んでいるものなどあります。これでおすすめ&必読本すべてを網羅しているわけではないですが、比較的最近購入した、またはいただいた本が並んでいるので、興味の反映としてはかなり正確です。マンガ棚は省略しています。

みなさまはどんな本が本棚に並んでいるでしょうか。見てみたいです!

なお、元記事で触れられている「リーン・スタートアップ」は、amazonのwishlistに入ったまま購入には至っておりません...

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年3月28日金曜日

WebScaleSQLとは何か(まとめと想像)

WebScaleSQLが公開されました。 これはFacebook, Google, LinkedInそしてTwitterのMySQLエンジニアが、大規模環境で使用する際に必要な変更点をまとめて、違う名前をつけてリリースしたものです。

MySQLとの違い

FAQにまとまってるものと、GitHubのcommitsを見ればなんとなくわかります。

  • 変更点それぞれについて全部のテストを自動で走らせるようなフレームワークを追加
  • ストレステストと自動化された性能テストを追加
  • テストを整理して、安全な変更が余計なテストを壊さないようにした
  • NUMA interleave、innodb バッファプールフラッシュの最適化、いくつかのクエリに対する最適化など性能改善
  • super_read_onlyと、1秒以下の精度でタイムアウトを指定するといった、web scaleで必要な変更

super_read_only とは、SUPER な権限を持った人でも read only にしてしまう機能のようです。

なぜ独立のブランチなのか

WebScaleSQLと新しく名前がついた割にはそこまで大きな変更点はなく、なぜリリースされたのかと疑問に思いました。私の想像ですが次のような感じなのかなぁと思っています。根拠なしなので間違ってたらごめんなさい。

  • お互いにエンジニア同士が交流する中、「それウチも困ってる!」というのが増えた
  • Oracle にパッチを投げるには少し面倒な手続きが必要
  • もう少し身軽に、様々な機能を取り込んで速いペースで試せる共通基盤がほしい
  • そうだ、名前をつけて公開してしまえば開発も加速できるしライセンスもはっきり

もう一度書きますが根拠レスです。あとはテストが彼らの求める水準としてはcommunity版には含まれていなくて、そういうのをもうちょっと気軽にメンテしておきたいんじゃないかとも思いました。

今後の見通し

しばらくはMySQLの最新プロダクションリリースに対するパッチセットのような感じで、"fork"と言わず"branch"と名乗って開発を続けるようです。コミットを見ていると1年以上前のコミットも多くて、とりあえずまとめてみました、ここからスタートですという感じに受け止めました。

最近また新しい機能の追加がぽつぽつ行われているようなので、しばらくするともう少し変わったものになるのかもしれません。

蛇足

きちんとかっこいいWebを作って、プレスリリースも出して、ニュースにもなってというのはすごいなぁと思いました。

2014年3月17日月曜日

JAWS Days 2014 で「最強のAWS」について発表しました

JAWS Days 2014に登壇させていただき、「最強のAWS」というテーマで発表しました。

モデレーターの@con_mameさんからは「AWSのここが良くなればいいのに」とか「この機能が無いのはどうよ」みたいな話をしてほしいと言われてました。でもAWSの怖いところは、「この機能があれば良いのに」と思っていると気づかないうちに実装されていたり、あまりに機能が多いので「実は存在した」というオチがありそうなところ。話題の選定には気を遣いましたが、結果的にAWSの中の人に「いいね!」と言ってもらえてよかったです。

今回の話題は大きく2つ。ひとつは「レイテンシ」、もうひとつは「テスト」です。レイテンシは、やはりクラウドや仮想技術につきものというか、どうしても物理環境よりも長くなってしまうので「もうひと押し!」のような考えで書きました。発表後に聞いたのですが、c3インスタンスでplacement groupを有効にすると非常にレイテンシが小さくなるとのこと。試してみたいですね。

もう一つの話題は「テスト」です。AWSのWeb Consoleはすごく充実しているけど、実はWebインタフェースで作業するのって"Infrastructure as Code"に反していると思うんですよね。再利用できないし、事前のレビューもできない。そこで多くの利用者はSDKを使って自動化していると思うんですけど、もう少し中間的な、お手軽に"Code"っぽいことができたらなぁという発想です。

発表に用いたスライドは以下です。

当日の参加者の皆様と関係者の皆様、ありがとうございました。

See also

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の購入はこちらから!

2014年1月9日木曜日

VMware Fusionの中からPXE Bootする方法

VMware Fusionで仮想マシンを立ち上げた時に、外にあるサーバーからPXE Bootしたいと思いました。ところが普通にやってもfilenameやnext-serverが取れないので、起動できません。いろいろググったところ、下記のようにするのがよさそうでした。

dhcpd.confを編集

/Library/Preferences/VMware Fusion/vmnet8/dhcpd.conf を編集します。vmnet8というのは使っているネットワークのインタフェースになります。設定ファイルをのぞいてみて、IPのレンジが現在使っているものと一致すればいいと思います。私の環境にはvmnet1とvmnet8がありました。

dhcpd.confを開くと

###### VMNET DHCP Configuration. Start of "DO NOT MODIFY SECTION" #####

という行がありますから、その手前

allow booting;
filename "pxelinux.0";
next-server 192.168.123.45;

という3行を追加します。 next-server の右側はPXE用のサーバーのアドレスです。

dhcpdを再起動

一番簡単な方法はOSを再起動することです。もし何らかの理由で再起動できない時は、psすると

root              581   0.0  0.0  2467008    468   ??  Ss    7:36PM   0:00.00 /Applications/VMware Fusion.app/Contents/Library/vmnet-dhcpd -s 7 -cf /Library/Preferences/VMware Fusion/vmnet8/dhcpd.conf -lf /var/db/vmware/vmnet-dhcpd-vmnet8.leases -pf /var/run/vmnet-dhcpd-vmnet8.pid vmnet8

というようなプロセスがいるので、これを kill して同じパラメータで起動しなおせば動くと思います。

まとめ

以上の手順でVMware Fusion上の仮想マシンからPXE Bootすることができました。