Google Chrome 59のHeadlessモードを使ってみる

Headless modeを内蔵したGoogle Chrome 59がリリースされたので、Python + Seleniumで使ってみました。

これまでheadlessと言えば、Xvfbを使って仮想的なディスプレイに作画することで実現していました。しかしGoogle Chrome 59以降ではChrome自体にheadless modeが内蔵され、Xvfbを使わなくてもディスプレイを持たないCLI環境でWebページのテストなどをできるようになりました。

そこでUbuntu 17.04上でGoogle ChromeのHeadlessモードを試してみました。

Chromeをインストール

Ubuntu 17.04にはChromeのパッケージがない1ので、まずChromeのダウンロードページからdebパッケージをダウンロードします。

Chromeはいくつか依存パッケージがあるので、それらのパッケージをインストールした後にdpkgコマンドでインストールします。

$ sudo apt install libappindicator1 libindicator7
$ sudo dpkg -i google-chrome-stable_current_amd64.deb
$ which google-chrome-stable
/usr/bin/google-chrome-stable

Seleniumとchromedriverをインストール

Seleniumは問題ありませんが、Ubuntu 17.04にあるchromedriveはChrome 59をサポートしていません。そこで最新のChromeDriverをダウインロードしてインストールします。

$ sudo apt install python3-selenium
$ cd ~/bin
$ unzip ~/Download/chromedriver_linux64.zip
$ ./chromedriver -v
ChromeDriver 2.30.477691 (6ee44a7247c639c0703f291d320bdf05c1531b57)

Headless modeを試してみる。

Pythonで次のようなスクリプトを書いて、Chromeをheadless modeで使えるか試してみました。

#!/usr/bin/python3

import os

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

CHROME_BIN = "/usr/bin/google-chrome-stable"
CHROME_DRIVER = os.path.expanduser('~/bin/chromedriver')

options = Options()
options.binary_location = CHROME_BIN
options.add_argument('--headless')
#options.add_argument('--remote-debugging-port=9222')

driver = webdriver.Chrome(CHROME_DRIVER, chrome_options=options)

#driver.get("chrome://settings/help")
#driver.save_screenshot("/tmp/help.png")
driver.get("https://www.yahoo.co.jp")
driver.save_screenshot("/tmp/yahoo.png")
print(driver.title)
driver.quit()

このスクリプトを実行してYahoo!のページタイトルYahoo! JAPANとスクリーンショットが作成されていれば成功です。

画面のサイズ指定ができない

これまでWindowsサイズをset_window_size()で指定していましたが、これがあると次のようなエラーを引き起こします。

selenium.common.exceptions.WebDriverException: Message: unknown error: cannot get automation extension
from unknown error: page could not be found: chrome-extension://aapnijgdinlhnhlmodcfapnahmbfebeb/_generated_background_page.html
  (Session info: headless chrome=59.0.3071.86)
  (Driver info: chromedriver=2.30.477691 (6ee44a7247c639c0703f291d320bdf05c1531b57),platform=Linux 4.10.0-21-generic x86_64)

解決策がないかとググってChromeDriver error “unknown error: cannot get automation extension”を見つけたのですが、私の環境では

options.add_argument("disable-extensions");
options.add_argument("--start-maximized");

というオプションを追加しても解決せず、set_window_size()を削除する必要がありました。

脚注

  1. UbuntuにはChromeのパッケージはありませんが、オープンソース版のChromiumがあります。 

Gitの対象から外したいけど、ファイル自体は残しておきたい

問題

  • Gitでバージョン管理していたファイルを残したまま追跡の対象外にしたい。
  • 既に管理対象になっているファイルは、後から.gitignoreにファイル名を追加しても変更の追跡が継続される。

対応方法

一旦ファイルを削除したというcommitを作成して、再度加えることで管理の対象外だと認識させる。

$ git rm --cached want-to-ignore-file
# --cachedオプションがあると、ファイル自体は削除されない。

# 追跡を止めたいファイルを.gitignoreに追加する。
$ EDIT .gitignore

# 必要なら.gitignoreをcommitに含める。
$ git add .gitignore

$ git commit

$ git add want-to-ignore-file

参照

USBにドライブが接続されたら自動的にバックアップを作成したい

目的

USB接続のディスクドライブにバックアップを作成するシェルスクリプトbackup.shがあります。USBにディスクドライブが接続されたら、このスクリプトを自動的に実行するようにしてバックアップの手間を減らしたい。

環境

OS
Ubuntu 16.04

解決策

方針

Ubuntu 16.04を含む最近のLinuxは、デバイスの管理にudevを使用しています。そのため適当なruleファイルを作成すると、デバイスが接続されたり取り外された時に決まったプログラムを実行させることができます。

そこでudevにドライブがUSBに接続されたらバックアップ用のシェルスクリプトbackup.shを実行するルールを作成します。

ただしudevのルールから起動できるプログラムは、短時間で終了する必要があります。バックアップなど終了までに時間がかかるプログラムを実行させようとすると、途中で強制的に終了させられてしまいます1

この制限を回避するために、バックアプをsystemdのサービスとして、udevからはそのサービスを開始するようにします。

systemdサービス

まずバックアップを作成するサービスを定義します。

/etc/systemd/system/backup.service

[Unit]
Description=Backup to Removable USB Drive

[Service]
Type=simple
ExecStart=/root/bin/backup.sh

サービスを定義したら次のコマンドでsystemdに登録します。

# systemctl daemon-reload
# systemctl status backup
* backup.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

なおsystemdから起動されたプログラムの標準出力は、syslogに記録されると同時にsystemctl status SERVICE_NAMEで確認できます。

udevルール

サービスを登録したら、そのサービスを起動するルールを作成します。

/etc/udev/rules.d/91-backup.rules

ACTION=="add",ENV{ID_BUS}=="ata",ENV{ID_PART_ENTRY_UUID}=="xxxx-xxxx-xxxx-xxxx",RUN+="/bin/systemctl --no-block start backup.service"

デバイスを識別するENVには、udevが認識している値を設定します。認識している値は、udevadm info --name=XXXコマンドで取得できます。

ルールを作成したら、次のコマンドでudevにルールを登録します。

# udevadm control --reload

これでxxxx-xxxx-xxxx-xxxxというUUIDを持つディスクパーティションがataに接続されたらbackup.serviceが起動されます。

参照と脚注

  1. 終了までに時間がかかるプログラムをudevから起動すると途中で強制終了させられる問題を回避するためにバックグラウンドで処理させるようにしても終了させられてしまいます。この問題は、setsidコマンドでセッションIDを変えて、自分がセッションリーダーとなれば終了させられないという記述を見たことがあります。

SATAのリンク速度を制限

症状

ドライブの交換が簡単かと思って、ホットスワップ対応のマウンタを使ってハードディスクをパソコンに取り付けました。

ハードディスクはSATA3.0対応なので、SATAのリンク速度は最高6.0Gbpsです。しかし激しくディスクにアクセスするとたまにエラーが出たり、次のようなログが記録される。

Apr 21 20:00:38 pool kernel: [  891.836436] ata2: limiting SATA link speed to 3.0 Gbps

このログが記録された後は、エラーが出ることはありません。

目的

そこでSATAのリンク速度を自動的に決定しないで、リンク速度を制限(指定)してディスクを接続したい。

対応

SATAのリンク速度は、Linuxのカーネルパラメータlibataで指定することができます。具体的には、/etc/default/grubを編集してカーネルの起動オプションとしてlibataを加えます。

/etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="libata.force=3.0Gbps"

ファイルを編集したらupdate-grubコマンドを実行して編集した内容をgrubに反映させます。

再起動すると、次のように指定した3.0Gbpsでディスクに接続していることがわかります。

$ demesg|grep 'SATA link'
[    1.118975] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
[    1.119005] ata6: SATA link down (SStatus 0 SControl 320)
[    1.119038] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
[    1.119065] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
[    1.119090] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
[    1.119116] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 320)

参照

ディスクイメージを簡単にマウント

目的

ディスクイメージのファイルがある。このファイルをマウントして中身を確認・変更したい。

loopデバイスを使ってmountできることは知っているけど、offsetを調べるとか面倒くさい。

方法

kpartxコマンドを使用すると、面倒なoffsetの値をfdiskコマンドなどで調べる必要がなくなる。

kpartxのインストール

kpartxは、Ubuntuではパッケージになっているのでaptコマンドを使ってインストールします。

$ sudo apt install kpartd

ディスクイメージをマウント

まずディスクイメージの各パーティションをkpartxコマンドを使ってloopデバイスに割り当てます。ここでは読み込み専用にしたいので-rオプションを加えています。

$ sudo kpartx -avr disk.img 
add map loop0p1 (252:6): 0 8396800 linear 7:0 2048
add map loop0p2 (252:7): 0 2 linear 7:0 8400894
add map loop0p5 (252:8): 0 8382464 linear 7:0 8400896

次に割り当てたloopデバイスを通して、目的のパーティションをマウントします。

$ sudo mount /dev/mapper/loop0p1 /mnt
mount: /dev/mapper/loop0p1 is write-protected, mounting read-only

$ ls /mnt/
bin   home	      lib64	  opt	sbin  tmp      vmlinuz.old
boot  initrd.img      lost+found  proc	snap  usr
dev   initrd.img.old  media	  root	srv   var
etc   lib	      mnt	  run	sys   vmlinuz

アンマウント

使い終わったらアンマウントしておきます。

$ sudo umount /mnt

$ sudo kpartx -d disk.img 
loop deleted : /dev/loop0

意外と忘れやすいのが、loopデバイスの後片付けです。アンマウントしたら、忘れずにkpartx -dしておきます。

DHCPv6-PDでIPv6のサブネットワークを作成

フレッツ光ネクストは、ひかり電話契約をすると/64よりも小さなプレフィックスを使用できます。このプレフィックスを使用すると、ひかり電話ルータの下に別のルータを置いて自分のネットワークを持つことができます。今回はこの方法で自分のネットワークをIPv6の世界に接続してみます。

ひかり電話契約をしていない場合は、IPv6とIPv4のデュアルスタックで接続のようにNAPT(マスカレード)を使用してネットワークを接続します。

ここでの設定は、ZOOT NATIVE (DS-Lite)でネット接続の状態になっている前提での説明です。追加で必要なradvdのインストール方法は、IPv6とIPv4のデュアルスタックで接続を参照して下さい。

サイト構成

Raspberry Piのインターフェイスは、次のように使用します。

インターフェイス ネットワーク アドレス
eth0 自分のネットワーク/64 DHCPv6-PDで自動設定
eth1 Internet(IPoE) DHCPv6で自動設定

自分のネットワーク内の端末は、Raspberry Piが送信するRAで自動的にIPv6アドレスやデフォルトルータが設定されます。

DHCPv6-PDによるプレフィックスの委譲

自分のネットワークを上位のネットワークへ接続するためには、プレフィックス委譲を受けます。この委譲を受けるのに使われるのがDHCPv6-PDです。上位のルータは、DHCPv6-PDによるやりとりでプレフィックスの払い出しと同時に、払い出したプレフィックスに相当するIPv6パケットをどこに送ったらよいかを記録しています。

DHCPはIPv4でIPアドレスなどネット接続に必要な情報を自動設定する時にお馴染みですが、IPv6用のDHCP(DHCPv6)は名前は同じでも全く別のプロトコールです。もっともIPv4で使ったDHCPクライアントは、DHCPv6クライアントとしても機能します。

DHCPv6対応クライアントには何種類かありますが、今回はRaspbian(jessie)に標準でインストールされているdhcpcdを使用します。他のDHCPv6クライアントを使用してプレフィックスの委譲を受ける時は、IPv6 プレフィックス委譲 (DHCPv6-PD) – Archlinuxを参照して下さい1

dhcpcdを有効に

dhcpcdは、ZOOT NATIVE (DS-Lite)でネット接続で無効にしているので、次のコマンドでシステムが起動時する時に自動的に実行開始されるようにします。

$ sudo systemctl enable dhcpcd.service

dhcpcdの設定

dhcpcdの設定は、/etc/dhcpcd.confに書きます。

# この上はデフォルトのまま

# IPv4は設定しない
ipv6only

# LANのIPv4用
# /etc/network/interfacesで設定される。
interface eth0
noipv6

# https://wiki.archlinuxjp.org/index.php/IPv6#.E3.83.97.E3.83.AC.E3.83.95.E3.82.A3.E3.83.83.E3.82.AF.E3.82.B9.E5.A7.94.E8.AD.B2_.28DHCPv6-PD.29
duid
noipv6rs
waitip 6

# WANのIPv6用 DHCPv6-DP
interface eth1
ipv6rs
iaid 1
# use the interface connected to your LAN
ia_pd 1 eth0

ひかり電話ルータはIPv4のDHCPサーバ機能を持っているので、ip6only(noipv4)をしないとDHCPによりIPv4のアドレスがeth1に割り当てられます。

interface設定を削除

dhcpcdでインターフェイスを設定するので/etc/network/interfacesにあるeth1の設定は不要です。そこでeth1に関する部分は全て削除してしまいます。

eth0もdhcpcdで設定できるので不要な気がしますが、これを削除するとシステムを起動する時にDHCPサーバがエラーで実行開始できなくなってしまいます。またDHCPv6-PDでプレフィックスの委譲を受ける時に/etc/resolv.confの内容がひかり電話ルータからのものになってしまいます。そのためeth0はinterfacesで設定します。

ufwの設定

プレフィックス委譲を使って自分のネットワークを接続すると、ネットワーク内の全ての端末にグローバルなIPv6が割り振られます。そのためアドレスが分かればほとんど何の制限もなしに世界中からアクセスすることが可能となります。

その裏返しとして想定外の端末が世界に公開されてしまうなど、NAPT(マスカレード)を使ったIPv6とIPv4のデュアルスタックで接続より各端末がより危険な状態に置かれ、世界中から自分のネットワーク内の端末が攻撃される危険性にさらされます。

この危険性を少しでも小さくするには、ルータを通過するパケットの選別が非常に大切です。

と言っても今回は実験なので必要最小限の制限とし、次のような一般的な最小限のポリシーとしました。

  • 自分のネットワークから外へは無制限に出ていける。
  • 自分のネットワークへは、出て行ったパケットに関連するパケットのみが入れる。

そこで/etc/default/ufwを次のように変更し、許可されたパケット以外は全て破棄するようにします。

DEFAULT_FORWARD_POLICY="DROP"
DEFAULT_INPUT_POLICY="DROP"
DEFAULT_OUTPUT_POLICY="ACCEPT"

許可するパケットのルールは、ufwの設定ファイルに追加します。

/etc/ufw/before.rules(IPv4用)

# 以下を追加する。
# accept all from LAN and returned RELATED or ESTABLISHED packets
-A ufw-before-forward -i eth0 -j ACCEPT
-A ufw-before-forward -m state --state RELATED,ESTABLISHED -j ACCEPT

/etc/ufw/before6.rules(IPv6用)

# 以下を追加する。
# https://www.cert.org/downloads/IPv6/ip6tables_rules.txt
# accept from LAN
-A ufw6-before-input -i eth0 -j ACCEPT

# allow DHCPv6-PD
#-A ufw6-before-input -p udp -s fe80::/10 --sport 547 -d fe80::/10 --dport 546
 -j ACCEPT
-A ufw6-before-input -p udp -s fe80::/10 -d fe80::/10 --dport 546 -j ACCEPT

-A ufw6-before-input -p icmpv6 -s fe80::/10 --icmpv6-type 130 -j ACCEPT

# accept all from LAN and returned RELATED or ESTABLISHED packets
-A ufw6-before-forward -i eth0 -j ACCEPT
-A ufw6-before-forward -m state --state RELATED,ESTABLISHED -j ACCEPT

ufwに元からあったルールを少し緩めて宛先ポート番号だけで許可するようにしているのは、DHCPv6-PDによるプレフィックスの委譲を受けるためです。

DHCPv6の通信を許可するルールがbefore6.rulesに入っていたので大丈夫だと思ったのですが、最初はDHCPv6-PDによるプレフィックスの委譲を受けることができませんでした。そこで原因を探るために捨てているパケットを見ていたら、ひかり電話ルータのDHCPv6サーバから送られてくるパケットのポート番号が547ではありませんでした。このため送信元のポート番号を無視して宛先のポート番号だけを見るようにしました。

IPv6の転送を許可

IPv4をトンネルするためにIPv4の転送を許可していましたが、加えてIPv6も転送するように設定します。

/etc/ufw/sysctl.conf

# 追加する
net/ipv6/conf/default/forwarding=1
net/ipv6/conf/all/forwarding=1

radvdの設定

radvdを使ってRA送信します。自分のネットワークに接続された端末は、このRAを受信することで自動的にIPv6の設定します。

radvdが配布するRAの設定は/etc/radvd.conf/radvd.confに書きます。

interface eth0 {
  AdvSendAdvert on;
  #MaxRtrAdvInterval 30;
  prefix ::/64 {
    AdvRouterAddr on;
  };
};

ここで指定しているプレフィックス::/64は、マジックワードです。このアドレスを指定すると、指定されたinterfaceの全グローバルアドレスからプレフィックスを決定してRAを送り出してくれます。今回のようにDHCPv6-PDで指定されるアドレスが何になるかわからない場合に便利な指定方法です。

IPv6での通信確認

以上でルータの設定は完了です。ここで再起動して自分のネットワーク内の端末からIPv6で通信できるか試してみます。

確認方法とトラブルシューティングは、IPv6とIPv4のデュアルスタックで接続のIPv6での通信確認を参照して下さい。

設定に間違いがないのに通信できない

今回どこにも間違いはないのに外と通信できないことがありました。自分のルータとひかり電話ルータの間に置いた端末とは通信できるのでルータの設定に問題はないはずですが、なぜかひかり電話ルータを越えて外に出られませんでした。

ひかり電話ルータにWebブラウザで接続してDHCPv6-PDによるプレフィックスの払い出し状況を確認するとなぜかRaspberry PiのLAN側のMACアドレスが登録されていました。そこから推測するとひかり電話ルータは外からの通信を接続されていないRasPiのLAN側宛に送ってしまっているのではないかと推測しました。

RaspPiを何度再起動してDHCPv6-PDをしなおしても登録されているMACアドレスは変わりません。

そこで/etc/dhcpcd.duid/etc/dhcpcd.secretを削除して再起動してみました。するとひかり電話ルータに登録されているMACアドレスは変化ありませんでしたが問題なく外と通信できるようになりました。

DS-Liteによるトンネル作成

IPv6に関する設定は以上ですが、interfacesからeth1に関する設定を全て削除してしまったのでIPv4をトンネルするインターフェイスが作成されません。そこでdhcpcdが設定のフェーズ毎に実行する/etc/dhcpcd.enter-hook2にスクリプトを書いておいてトンネルを作成します。スクリプトが実行される時に設定される変数については、dhcpcd-run-hooksのマニュアルを参照して下さい。

/etc/dhcpcd.enter-hook

#!/bin/sh
# http://techlog.iij.ad.jp/contents/dslite-raspi

REMOTE='2404:8e01::feed:101'

WAN_IF='eth1'
TUN_IF='ip6tnl1'

dig_tunnel()
{
    #  already tunnel exist?
    ip addr show | grep $TUN_IF > /dev/null
    if [ $? -eq 0 ] ; then
	return
    fi

    LOCAL=`ip -6 addr show $WAN_IF scope global |grep inet6 | awk '{print $2}'`
    if [ "$LOCAL" = '' ]; then
	return
    else
	logger dig DS-Lite tunnel $WAN_IF $LOCAL === $REMOTE
    fi

    # IPIP6 tunnel linkup
    ip -6 tunnel add $TUN_IF mode ip4ip6 remote $REMOTE local $LOCAL dev $WAN_IF
    ip link set dev $TUN_IF up

    # IPv4 routing
    route delete default
    route add default dev $TUN_IF
}

delete_tunnel()
{
    ip addr show | grep $TUN_IF > /dev/null
    if [ $? -ne 0 ] ; then
	return
    fi

    logger delete DS-Lite tunnel
    # delete DS-Lite tunnel
    ip -6 tunnel delete $TUN_IF

    # delete default route
    route delete default
}


if [ "$interface" = $WAN_IF ] ; then
    if $if_up ; then
	case "$reason" in
	    BOUND6|REBIND6)
		dig_tunnel
		;;
	esac
    else
	if [ "$reason" = EXPIRE6 ] ; then
	    delete_tunnel
	fi
    fi
fi

参照と脚注

  1. 今回使ったdhcpd以外にもIPv6用のDHCPクライアントはいくつかありますが、dibblerWIDE-DHCPv6では上手くプレフィックスの委譲を受けることができませんでした。委譲はしてもらえていたのかも知れませんが、インターフェイスにアドレスが設定されませんでした。自分で設定する必要があったのかも知れません。

  2. dhcpcdは、/etc/dhcpcd.enter-hookだけでなく/etc/dhcpcd.exit-hookも実行します。しかし今回順番は関係ないので、トンネルの作成と破棄の両方共/etc/dhcpcd.enter-hookに書いています。

IPv6とIPv4のデュアルスタックで接続

ZOOT NATIVE (DS-Lite)でネット接続では、DS-Liteを使ってIPv4通信できることを確認しました。今回は、せっかくZOOT NATIVEがIPv6のIPoEなので、IPv4だけでなくIPv6でも通信できるようにします。

フレッツ光のひかり電話契約なしの場合は/64のプレフィックスしかもらえなので、自分のルータの下に自分のネットワークを置くにはこの方法しかありません。

ひかり電話契約ありの場合は、DHCPv6-PDによりもっと普通に自分のネットワークを置けます。このDHCPv6-PDを使った方法は、DHCPv6-PDでIPv6のサブネットワークを作成を参照して下さい。

Raspbianの設定は、ZOOT NATIVE (DS-Lite)でネット接続での状態になっている前提での説明です。

サイト構成

IPv6は事実上無限の数のIPアドレスを持つので、IPv6に接続したどんな機械でもユニークなIPアドレスを持つことができInternetから接続できます。ということなのですが、ひかり電話契約がない場合は、フレッツ光のひかり電話ルータがRAで配布するプレフィックスは/64となっています。そのためさらに下に別なネットワークを作る事ができません1

そこで今回は、IPv4と同じようにルータでNAPT(マスカレード)してルータ以下のネットワークを隠してIPv6の世界に接続します。このためInternetから自分のネットワーク内の端末へ簡単には接続できません2

自分のネットワーク内では、IPv4のプライベートアドレスに相当するユニークローカルアドレス(ULA)を使用します。今回はfd00::/64を自分のネットワークに使用することにしました。

Raspberry Piのインターフェイスは、次のように使用します。

インターフェイス ネットワーク アドレス
eth0 自分のネットワーク/64 fd00::1/64
eth1 Internet(IPoE) RAで自動設定

自分のネットワーク内の端末は、Raspberry Piが送信するRAで自動的にIPv6アドレスやデフォルトルータが設定されます。

ルータのアドレス指定

自分のネットワークへ入るルートを登録するため、eth0にIPv6のアドレスを割り当てます。

/etc/network/interfaces

# 追加する
iface eth0 inet6 static
 address fd00::1
 netmask 64

radvdをインストール

IPv4のDHCPサーバと同じように、IPv6ではルータ広告(RA)によって端末をネットワークに接続しただけで自動的にアドレスやデフォルトルートが設定されます。このためのサーバソフトがradvdです。

$ sudo apt-get install radvd

radvdが配布するRAの設定は/etc/radvd.conf/radvd.confに書きます。

interface eth0 {
  AdvSendAdvert on;
  #MaxRtrAdvInterval 30;
  #prefix ::/64 { でもOK?
  prefix fd00::/64 {
    AdvRouterAddr on;
  };
};

必要であればDNSの情報をRAで配布することも可能3ですが、今回はIPv4のDHCPに依存することにしました。

どんな内容のRAを送っているか(受信しているか)は、ルータ上で次のコマンドを実行することで確認できます。

$ sudo radvdump

ufwの設定

前回はIPv4のみだったのでDEFAULT_FORWARD_POLICYをACCEPTとして何でも転送を許可していましたが、今回は少し安全にするため通過できるパケットを制限します。制限するポリシーは次のとおりです。

  • 自分のネットワークから外へは無制限に出ていける。
  • 自分のネットワークへは、出て行ったパケットに関連するパケットのみが入れる。

そこで/etc/default/ufwを次のように変更し、許可されたパケット以外は全て破棄するようにします。

DEFAULT_FORWARD_POLICY="DROP"
DEFAULT_INPUT_POLICY="DROP"
DEFAULT_OUTPUT_POLICY="ACCEPT"

許可するパケットのルールは、ufwの設定ファイルに追加します。

/etc/ufw/before.rules

# 以下を追加する。
# accept all from LAN and returned RELATED or ESTABLISHED packets
-A ufw6-before-forward -i eth0 -j ACCEPT
-A ufw6-before-forward -m state --state RELATED,ESTABLISHED -j ACCEPT

/etc/ufw/before6.rules

# 以下を追加する。
# accept from LAN
-A ufw6-before-input -i eth0 -j ACCEPT

# accept all from LAN and returned RELATED or ESTABLISHED packets
-A ufw6-before-forward -i eth0 -j ACCEPT
-A ufw6-before-forward -m state --state RELATED,ESTABLISHED -j ACCEPT

さらにIPv6のパケットをNAPT(マスカレード)するための設定を/etc/ufw/before6.rulesに追加します。追加は、ファイルの最初または最後、要するに*filterとCOMMITに挟まれていない場所にします。

/etc/ufw/before6.rules

*nat
:POSTROUTING ACCEPT [0:0]

# Forward traffic through eth1
-A POSTROUTING -s fd00::/64 -o eth1 -j MASQUERADE

COMMIT

IPv6の転送を許可

IPv4だけでなく、IPv6も転送するように設定します。

/etc/ufw/sysctl.conf

# 追加する
net/ipv6/conf/default/forwarding=1
net/ipv6/conf/all/forwarding=1

net/ipv6/conf/eth1/accept_ra=2
net/ipv6/conf/eth1/accept_ra_pinfo=1
net/ipv6/conf/eth1/autoconf=1

forwardingを有効にすると上流ルータからのRAを無視してしまいます。そこで外につながっているeth1はaccept_raなどを有効にして、RAを受信して自動的にアドレスを設定するようにしています。

IPv6はインターフェイスのMACアドレスからアドレスが決定されます。そのためこのまま外のサイトに接続するとIPv6アドレスからどのメーカのネットワークカードまたはアダプタを使っているがバレてしまいます。これが嫌な時は、プライバシー機能を有効にして隠すことが可能です。

IPv6での通信確認

IPv6で通信するための設定は以上で終わりです。一度再起動して設定を反映させます。

IPv6とIPv4の両方で通信できているかは、次のサイトへWebブラウザでアクセすることで確認できます。

IPv6 test – IPv6/4 connectivity and speed test
IPv4とIPv6の両方で接続できるか調べられる。
あなたの IPv6 をテストしましょう。
IPv6で通信できているかを確認できる。
IIJmio IPv6スピードテスト(β)
IPv6での通信速度を測定できる。
The KAME project
IPv6で接続すると亀が動きます。

トラブルシューティング

接続できない時は、まずIPv6アドレスが割り振られているか確認します。Windowsでは、ipconfigコマンドを使用します。

$ ip -6 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2409::xxx:xxxx:xxx:xxx/64 scope global temporary dynamic 
       valid_lft 86165sec preferred_lft 14165sec
    inet6 2409::xxx:xxxx:xxx:xxx/64 scope global mngtmpaddr noprefixroute dynamic 
       valid_lft 86165sec preferred_lft 14165sec
    inet6 fe80::xxx:xxxx:xxx:xxx/64 scope link 
       valid_lft forever preferred_lft forever

IPv6アドレスが割り当てられていることが確認できたら、デフォルトルートが登録されていることを確認します。

$ netstat -rn6
カーネルIPv6 経路テーブル
Destination                    Next Hop                   Flag Met Ref Use If
2409:xxx:xxxx:xxx::/64        ::                         Ue   256 2     7 enp0s25
fe80::/64                      ::                         U    256 0     0 enp0s25
::/0                           fe80::xxx:xxx:xxx:xxx  UG   100 1     1 enp0s25
# 省略

ここで::/0で始まる行がデフォルルートで、送り先がわからない時はパケットをNext Hopのfe80::xxx:xxx:xxx:xxxに送ってどうにかしてもらいます。このアドレスがルータのものか確認します。

参照と脚注

ZOOT NATIVE (DS-LITE)でネット接続

  1. さらに下にネットワークを作らないでも、ひかり電話ルータに直接接続するだけでIPv6で通信することが可能です。ただこれだとパケットの制限をこのルータに依存するのが嫌だな…と。

  2. NAPTでも外から自分のネットワーク内の端末に接続で可能です。その時は、IPv4の時と同じように特定ポートへの通信を特定の端末に転送させるように設定します。これで外部にサーバを公開する事が可能です。

  3. RAでDNSの情報を配布する場合は、RDNSSとDNSSLの設定をradvd.confに追加します。

ZOOT NATIVE (DS-Lite)でネット接続

インターリンク(Interlink)がZOOT NATIVEというIPv6 IPoEサービスを開始しました。この方式にするとIPv4のPPPoEよりも速くなる(遅くならない)という話なので試してみました。

ZOOT NATIVEは基本的にIPv6のサービスですが、今回はトンネルを作成してIPv4でInternetに接続してみます。

IPv6で通信するための設定方法は、IPv6とIPv4のデュアルスタックで接続にあります。この方法は、ひかり電話契約のないユーザにオススメの方法です。ひかり電話契約がある場合は、DHCPv6-PDでIPv6のサブネットワークを作成のように素直にネットワークを接続する方法もあります。

環境

  • フレット光ネクスト ファミリー・ハイスピードタイプ(NTT西日本)
  • ひかり電話オプション契約あり
  • Raspberry Pi B+ Raspbian(Debian jessei)

Raspberry Piの内蔵Ethernet(eth0)にLANを接続し、USB 2.0接続の100BASE-TX Ethernetアダプター(eth1)にフレッツ光ネクストのルータ(PPPoEブリッジ機能を有効)を接続しています。

パソコンのUbuntu 16.04でも、ここで紹介した方法で接続できました。

ZOOT NATIVEの申し込み

申し込みは、インターリンクのWebページから簡単に行えました。ただし事前に次のものを準備しておく必要があります。

  • クレジットカード
  • フレッツ光のお客様IDとアクセスキー1

4月5日の朝に申し込んで、翌4月6日の朝に使用できるようになったというメールが届きました。

設定方法

Raspberry Piを通信の中継だけでなく一般的な市販ルータが持つDNS機能とアドレスの自動割当機能を持たせます。そのためIPv6上でIPv4を使うDS-Liteトンネルの作成以外に、DNSやDHCPサーバ用の設定が入っています。

DNS(unbound)をインストール

まず最初にLANのDNS(キャッシュ)となるunboundをインストールします。ISPのDNSを使用できるならば、このステップは不要です。

$ sudo apt-get install unbound

unboundは、/etc/unbound/unbound.conf.d/にある*.confを起動時に設定ファイルとして読み込みます。そこでunbound-local.confというファイルを作成して設定を書き込みます。

/etc/unbound/unbound.conf.d/unbound-local.conf

server:
    #interface: 0.0.0.0
    interface: 127.0.0.1
    interface: 10.0.0.254
    access-control: 10.0.0.0/24 allow

IPv6のアドレスにはbindしないで、LANと自分自身からの問い合わせにのみ答えるようにしました。

ルータのアドレスを固定

ルータのIPv4アドレスは、LAN内のデフォルトルートとなるので固定されている必要があります。そこでDHCPクライアントを停止して、LANに接続しているeth0のIPv4アドレスを指定します。

まずはDHCPクライアントを停止します2

$ sudo systemctl stop dhcpcd.service
$ sudo systemctl disable dhcpcd.service

固定アドレスは、/etc/network/interfacesに設定ます。アドレスと同時にルータ自身が参照するDNS(自分自身)を指定します。

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
 address 10.0.0.254
 netmask 255.255.255.0
 dns-nameservers 127.0.0.1
 dns-search example.jp

これで再起動してもアドレスは変わらず、常に同じIPv4アドレスを使うようになります。

トンネルの出口確認

IPv4で通信できるようにするDS-Liteトンネルの設定には、トンネルの出口に当たるゲートウェイ(AFTR3)のIPv6アドレスが必要です。

AFTRのIPv6アドレスは、NVR510の設定マニュアルに書かれていました。ただしこのアドレスは固定ではなく予告なく変更されることがあるそうなので、接続できなくなった場合は設定を変更する必要があります4

私はNTT西日本を使っているので、AFTRとして2404:8e01::feed:100または2404:8e01::feed:101を使用します。

実際にAFTRと通信できるかping6コマンドで確認しておきます。

$ ping6 -c 2 2404:8e01::feed:100
PING 2404:8e01::feed:100(2404:8e01::feed:100) 56 data bytes
64 bytes from 2404:8e01::feed:100: icmp_seq=1 ttl=58 time=5.26 ms
64 bytes from 2404:8e01::feed:100: icmp_seq=2 ttl=58 time=4.97 ms

--- 2404:8e01::feed:100 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 4.978/5.120/5.262/0.142 ms

ufwをインストール

ルータなので不要な通信を制限します。そのため通信を制限するufwをインストールします。ufwを使用しない場合は、IPv4をインターフェイス間で転送するように/etc/sysctl.confを編集してIPv4をルーティングするようにします。

$ sudo apt-get install ufw

/etc/ufw/ufw.conf

ENABLED=yes

# allow ssh connection
# これがないとRaspberry PiにLANからsloginできなくなる。
ufw allow 22/tcp

IPv4をルーティングするように設定します。また必要ならば不要な通信を制限する設定を追加します。

/etc/ufw/sysctl.conf

net/ipv4/ip_forward=1

/etc/default/ufw

DEFAULT_FORWARD_POLICY="ACCEPT"
DEFAULT_INPUT_POLICY="DROP"
DEFAULT_OUTPUT_POLICY="ACCEPT"

転送ルーティングのポリシーをACCEPTにすることは通常危険ですが、トンネル出口でアドレス変換が行われていて外から入ってくる通信はないので良いことにしました5

ufwの自分宛ルーティングポリシーはDROPとなっています。そこで/etc/ufw/before.rulesを編集して、LANからDNS(port 53)への通信を許可する次のルールを最後のCOMMITの前に追加します。

# 以下を追加する。
# Accpet for DNS from LAN
-A ufw-before-input -i eth0 -p udp --dport 53 -j ACCEPT
-A ufw-before-input -i eth0 -p tcp --dport 53 -j ACCEPT

ufwの設定がすんだら、DS-LiteでIPv4をトンネルするために必要なモジュールを起動時に読み込むように設定ます。

/etc/modules

ip6_tunnel

ここまできたら、一旦再起動して設定を反映させておきます。

DS-Liteトンネルを作成

DS-Liteトンネルは、DS-Lite(RFC6333)対応ルータをLinux (Raspberry Pi) で作るのシェルスクリプトを使って作成します。

/etc/network/dig-tunnel.sh

#!/bin/bash
# Ref. http://techlog.iij.ad.jp/contents/dslite-raspi

# gw.transix.jp
REMOTE='2404:8e01::feed:100'

#IFACE='eth1'
IFACE=$1

# get my IPv6 address
for i in $(seq 0 9); do
 LOCAL=`ip -6 addr show $IFACE scope global |grep inet6 | awk '{print $2}'`
 if [[ $LOCAL != '' ]]; then
  break
 fi

 sleep 1
done

if [[ $LOCAL == '' ]]; then
 exit
else
 echo $LOCAL
fi

# IPIP6 tunnel linkup
ip -6 tunnel add ip6tnl1 mode ip4ip6 remote $REMOTE local $LOCAL dev $IFACE
ip link set dev ip6tnl1 up

# IPv4 routing
route delete default
route add default dev ip6tnl1

それでは実際にスクリプトを起動してトンネルを掘ってみます。

$ sudo ifconfig up eth1
$ sudo /etc/network/dig-tunnel.sh eth1

トンネルが掘れているか確認します。

$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.254/24 brd 10.0.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link 
       valid_lft forever preferred_lft forever
3: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN group default qlen 1
    link/tunnel6 :: brd ::
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet6 2409:xxx::xxxx/64 scope global mngtmpaddr dynamic 
       valid_lft 14125sec preferred_lft 12325sec
    inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link 
       valid_lft forever preferred_lft forever
5: ip6tnl1@eth1: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1452 qdisc noqueue state UNKNOWN group default qlen 1
    link/tunnel6 2409::xxx peer 2404:8e01::feed:100
    inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link 
       valid_lft forever preferred_lft forever

$ netstat -r
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
default         *               0.0.0.0         U         0 0          0 ip6tnl1
10.0.0.0        *               255.255.255.0   U         0 0          0 eth0

$ ping -c 2 www.yahoo.co.jp
PING edge.g.yimg.jp (183.79.248.252) 56(84) bytes of data.
64 bytes from 183.79.248.252: icmp_seq=1 ttl=59 time=4.35 ms
64 bytes from 183.79.248.252: icmp_seq=2 ttl=59 time=4.92 ms

--- edge.g.yimg.jp ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1003ms
rtt min/avg/max/mdev = 4.357/4.640/4.924/0.291 ms

トンネルの自動作成

問題なく接続できることを確認したら、起動した時に自動的にトンネルを掘ってルータとして機能するようにします。

トンネル作成は、/etc/network/interfacesに設定ます。

# これまでの設定に追加
auto eth1
iface eth1 inet manual
 pre-up /sbin/ifconfig eth1 up
 post-up /etc/network/dig-tunnel.sh eth1

ここで再起動して自動的にトンネルが掘れているか確認します。

DHCPサーバをインストール

最後にLAN内の端末を自動設定できるようにDHCPサーバをインストールします。

$ sudo apt-get install isc-dhcp-server

/etc/default/isc-dhcp-server

# eth0(LAN)にのみDHCPサーバとして働く。
#INTERFACES=""
INTERFACES="eth0"

/etc/dhcp/dhcpd.conf

#option domain-name "example.org";
#option domain-name-servers ns1.example.org, ns2.example.org;
option domain-name "example.jp";
option domain-name-servers 10.0.0.254;
option routers 10.0.0.254;

subnet 10.0.0.0 netmask 255.255.255.0 {
  pool {
    range 10.0.0.1 10.0.0.10;
  }
}

通信速度を測定

Raspberry Pi B+をルータとしたDS-Lite接続でどのくらいの速度が出るかBNRスピードテストでテストしてみました。

Ras Pi Ubuntu 16.04 IPv4 PPPoE
22.53Mbps(n=3) 91.02Mbps(n=6) 88.54Mbps(n=2)

テストは一番スピードが出ると予想される早朝に測定しました。Ras PiとUbuntu 16.04はZOOT NATIVEで、IPv4 PPPoEはZOOT NEXTの結果です。

Raspberry Pi B+をルータにした場合は、USB 2.0接続のEthernetアダプターが100BASE-TXのためかCPUの性能が律速なのか、DS-Liteトンネルの性能をフルには発揮できていないようです。

フレッツ光ネクストのハイスピードタイプはPPPoEの通信速度に制限がかけられているという話で、DS-Liteにするとその制限がなくなり本来のIPv6による通信速度に近づくという話でした。しかし今回は、DS-Liteによる通信では、期待されたPPPoEを大きく越えるような高速な通信はできませんでした。

DS-LiteトンネルとPPPoEであまり差がなかった原因は、ルータにしているパソコンの性能が律速になっている可能性はあります。しかしこのパソコンはCore 2 Duoマシンで、速度測定中の負荷を見てもそれほど忙しくしているようには見えません。

ZOOT NATIVEはオススメ?

スピード命で固定のIPv4アドレスが不要ならば、ZOOT NATIVEオススメかな。でも積極的にZOOT NEXTから乗り換えるという程でもないかな。

ゴールデンタイムはZOOT NATIVEの圧勝

残念ながら私の環境ではPPPoEを大きく越える通信速度は見られませんでした。ただしDS-Liteによるトンネルのメリットは、最高速度だけでなくゴールデンタイムでも通信速度が低下しないという点です。

多くの人がネットを使うだろう土曜日の夜にZOOT NEXT(PPPoE)とZOOT NATIVE(IPoE + DS-Lite)で通信速度を測定してみました。なおルータにはRaspberry Piではなく、Ubuntu 16.04マシンを使用しています。

回線 平日の早朝 土曜日の夜
ZOOT NEXT 98.6Mbps(n=3) 3.37Mbps(n=8)
ZOOT NATIVE 83.4Mbps(n=3) 86.8Mbps(n=8)

このようにPPPoEであるZOOT NEXTに見られた夜間の速度低下が全く見られませんでした。信じられなくて、NETXとNATIVEを交互に8回も測定してしまいました。ただし速度低下が見られなかったのは、まだサービス開始から時間が経っていないのユーザが少ないからという可能性があります。

ZOOT NEXTのままで十分

ZOOT NATIVEの欠点は、IPv4の固定アドレスオプションが無いことです。また接続料金が倍になります。

ZOOT NEXT ZOOT NATIVE
1,080円 2,160円

現在の通信速度に問題があるならば、料金が倍になったとしてもこれよりも高い設定のISPは普通にあるので乗り換える価値は非常にあります。しかし夜間に通信速度が低下するとは言っても、Huluなどで動画を見るのに全く支障がありません6。今回測定してみて初めてこんなに速度が低下するのかと気がついたくらいです。

そうすると普通に使える速度なら満足でIPv6の通信が不要なうちは、積極的にZOOT NATIVEに切り替える理由は見当たらない気がします。ZOOT NATIVEは常にフルスピードを求めるユーザ向けということでしょうか。せっかく2ヶ月の無料体験期間を設けてくれているのにごめんなさい。

参照と脚注

  1. フレッツ光のお客様IDとアクセスキーは、フレッツ光を申し込んだ時の書類に記載されていました。

  2. 単純に固定アドレスを使いたいだけの場合は、DHCPクライアントを停止する必要はありません。/etc/dhcpcd.confに固定アドレスを使用するための設定を加えるだけで十分です。今回は、トンネルを掘るシェルスクリプトを起動したかったのでこのようにしました。

  3. AFTRは、Address Family Transition Routerの略。

  4. AFTRのIPv6のアドレスが変わった時、IPv6での通信だけで新しいAFTRを探せるのかな?

  5. 外から入ってくる通信は、全て出て行った通信への返信なのでルータを通過させて問題はない。

  6. ZOOT NEXTとAsahiNetは問題ありませんが、WakWakを使っていた時は非常に通信速度が落ちて動画配信サービスをまともには使えませんでした。

WindowsパソコンでもCapsLockキーをCtrlキーに

目標

WindowsパソコンのCapsLockキーをCtrlキーとして使いたい。CapsLockキーとCtrlキーは交換しないで、これまでのCtrlキーもそのままCtrlキーとする。

すなわちCapsLockキーとCtrlキーの両方をCtrlキーとして、CapsLockキーの機能は不要。

方法

CapsLockキーをCtrlキーにする方法にはレジストリを編集する方法もありますが、Ctrl2capというソフトを使用するのが簡単です。

  1. Ctrl2capをWindows Sysinternalsからダウンロードする。
  2. ダウンロードしたファイルを展開(解凍)する。
  3. コマンドプロンプトを開いて展開したフォルダーに移動する。
  4. ctrl2cap /installコマンドを実行する。
  5. システムを再起動する。
C:\Users\username>cd C:\Users\username\Desktop\Ctrl2Cap

C:\Users\username\Desktop\Ctrl2Cap>ctrl2cap /install

Ctrl2cap Installation Applet
Copyright (C) 1999-2006 Mark Russinovich
Sysinternals - www.sysinternals.com

Ctrl2cap successfully installed. You must reboot for it to take effect.

CapsLockキーを元に戻す

CtrlキーにしたCapsLockキーを元に戻すには、ctrl2cap /uninstallコマンドを実行してCtrl2capを削除して再起動します。

参照

UBUNTUでCAPSLOCKキーをCONTROLキーに

LVM上のファイルシステムを拡張する

状況

  • ルートファイルシステムの残り容量が10%を切ってしまった。
  • ルートファイルシステムはLVM上にあり未割当のブロックはまだ残っている。
  • ルートファイルシステムはext4。
$ df -h
Filesystem                Size  Used Avail Use% Mounted on
/dev/mapper/fs-root      11G  9.7G  486M  96% /
none                      4.0K     0  4.0K   0% /sys/fs/cgroup
udev                      1.9G  4.0K  1.9G   1% /dev
tmpfs                     382M  592K  382M   1% /run
none                      5.0M     0  5.0M   0% /run/lock
none                      1.9G     0  1.9G   0% /run/shm
none                      100M     0  100M   0% /run/user
/dev/sda1                 228M   60M  157M  28% /boot

$ sudo lvdisplay /dev/fs/root
  --- Logical volume ---
  LV Path                /dev/fs/root
  LV Name                root
  VG Name                fs
  LV UUID                jLrK9R-W1PT-zzmx-ep27-IdPY-H2Tf-jcyMXC
  LV Write Access        read/write
  LV Creation host, time , 
  LV Status              available
  # open                 1
  LV Size                10.97 GiB
  Current LE             2809
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:0

$ sudo pvdisplay
  --- Physical volume ---
  PV Name               /dev/sda5
  VG Name               fs
  PV Size               37.03 GiB / not usable 1.00 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              9480
  Free PE               3106
  Allocated PE          6374
  PV UUID               z34vz3-0aVt-wFjy-s81b-c88D-XIOc-Kxqgti

pvdisplayコマンドの結果から未割当のブロック(Free PE)が3106残っていることが分かります。PEのサイズが4MiBなので、3106のPEは約12GiBです。

対応

未割当のブロックが12GiBあるので、この一部(3GiB)をROOT FSのLVに追加します。

$ sudo lvextend -L +3G /dev/mapper/fs-root
  Extending logical volume root to 13.97 GiB
  Logical volume root successfully resized
$ sudo lvdisplay /dev/fs/root
  --- Logical volume ---
  LV Path                /dev/fs/root
  LV Name                root
  VG Name                fs
  LV UUID                jLrK9R-W1PT-zzmx-ep27-IdPY-H2Tf-jcyMXC
  LV Write Access        read/write
  LV Creation host, time , 
  LV Status              available
  # open                 1
  LV Size                13.97 GiB
  Current LE             3577
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:0

これでROOT FSのLVサイズが約14GiBに増えました。しかしこのままでは、ファイルシステムは増加した部分を使用できません。

ファイルシステムがLVM上で拡張した部分を使えるようにファイルシステム自体を拡張します。通常ならばシステムを停止またはアンマウントしてファイルシステムを拡張する必要がありますが、ext4ファイルシステムはライブリサイズに対応しているのでこのまま進めます。

$ sudo resize2fs /dev/fs/root
resize2fs 1.42.9 (4-Feb-2014)
Filesystem at /dev/fs/root is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/fs/root is now 3662848 blocks long.

$ df -h
Filesystem                Size  Used Avail Use% Mounted on
/dev/mapper/fs-root      14G  9.7G  3.3G  75% /
none                      4.0K     0  4.0K   0% /sys/fs/cgroup
udev                      1.9G  4.0K  1.9G   1% /dev
tmpfs                     382M  596K  382M   1% /run
none                      5.0M     0  5.0M   0% /run/lock
none                      1.9G     0  1.9G   0% /run/shm
none                      100M     0  100M   0% /run/user
/dev/sda1                 228M   60M  157M  28% /boot

これでROOT FSの容量が最初の11GiBから14GiBに増え、その結果使用量が75%になりました。

参照

論理ボリュームを拡大するには – Linux Tips @IT