Intel EdisonにXenomaiを入れる（ただしWiFiなし...） − (本題)

組込み Linux

前回に続き、EdisonにXenomaiを入れていきます。

Xenomai用のパッチを作成する

まず、コンパイルに必要なEdison用のXenomaiパッチを作成していきます。最初にXenomaiのコードをとってきましょう。以下では、Edison、Linuxのソースコードを展開したディレクトリを基準としています。

$ ls
edison-src                       linux-yocto-3.10-3.10.32.tar.bz2
linux-yocto-3.10-3.10.32         upstream_to_edison.3.10.32.patch
linux-yocto-3.10-3.10.32-edison
$ git clone git://git.xenomai.org/xenomai-3.git
Cloning into 'xenomai-3'...
remote: Counting objects: 120758, done.
remote: Compressing objects: 100% (20429/20429), done.
remote: Total 120758 (delta 98188), reused 119251 (delta 96934)
Receiving objects: 100% (120758/120758), 273.37 MiB | 625.00 KiB/s, done.
Resolving deltas: 100% (98188/98188), done.
Checking connectivity... done.
$ ls
edison-src                       linux-yocto-3.10-3.10.32.tar.bz2
linux-yocto-3.10-3.10.32         upstream_to_edison.3.10.32.patch
linux-yocto-3.10-3.10.32-edison  xenomai-3
$

続いて、元のYocto Projectのカーネル3.10.32に対してXenomaiのパッチを当てます。Xenomaiパッチを当てるにはドキュメントにあるように、スクリプトを実行してやります。パッチを当てたら、分かるようにディレクトリ名を変更しておきましょう。

$ xenomai-3/scripts/prepare-kernel.sh --help
usage: prepare-kernel --linux= --ipipe= [--arch=]
 [--outpatch= [--filterkvers=y|n] [--filterarch=y|n]] [--forcelink] [--def
ault] [--verbose]
$ xenomai-3/scripts/prepare-kernel.sh --linux=linux-yocto-3.10-3.10.32 \
    

        
    

        checking file arch/x86/Kconfig
checking file arch/x86/Kconfig.debug
checking file arch/x86/include/asm/apic.h
...
checking file mm/mmu_context.c
checking file mm/mprotect.c
checking file mm/vmalloc.c
$ mv linux-yocto-3.10-3.10.32 linux-yocto-3.10-3.10.32-ipipe
$ ls
edison-src                       linux-yocto-3.10-3.10.32.tar.bz2
linux-yocto-3.10-3.10.32-edison  upstream_to_edison.3.10.32.patch
linux-yocto-3.10-3.10.32-ipipe   xenomai-3
$ 

    

今度はXenomaiパッチを当てたカーネルソースコードにEdisonパッチを当ててやります。ここで使用するのは、前回作成した3.10.32用のパッチです。


$ cd linux-yocto-3.10-3.10.32-ipipe/
$ patch -p1 < ../upstream_to_edison.3.10.32.patch
patching file Documentation/kernel-parameters.txt
patching file arch/x86/Kconfig
Hunk #1 succeeded at 446 (offset 4 lines).
...
patching file kernel/power/process.c
patching file kernel/printk.c
patching file sound/soc/codecs/sn95031.c
$ find . -name "*.rej"
./arch/x86/kernel/apic/io_apic.c.rej
$ 

このとき、ひとつのファイル(arch/x86/kernel/apic/io_apic.c)でパッチ適用失敗となります。これについては、手動で修正してやります。2656行目から以下のように修正します。


static struct irq_chip ioapic_chip __read_mostly = {
        .name                   = "IO-APIC",
        .irq_startup            = startup_ioapic_irq,
        .irq_mask               = mask_ioapic_irq,
        .irq_unmask             = unmask_ioapic_irq,
        .irq_ack                = ack_apic_edge,
        .irq_eoi                = ack_apic_level,
        .irq_set_affinity       = native_ioapic_set_affinity,
        .irq_retrigger          = ioapic_retrigger_irq,
#ifdef CONFIG_IPIPE
#ifdef CONFIG_SMP
        .irq_move               = move_xxapic_irq,
#endif
        .irq_hold               = hold_ioapic_irq,
        .irq_release            = release_ioapic_irq,
#endif
};

　　　　　　　　↓↓↓↓↓

static struct irq_chip ioapic_chip __read_mostly = {
        .name                   = "IO-APIC",
        .irq_startup            = startup_ioapic_irq,
        .irq_mask               = mask_ioapic_irq,
        .irq_unmask             = unmask_ioapic_irq,
        .irq_ack                = ack_apic_edge,
        .irq_eoi                = ack_apic_level,
        .irq_set_affinity       = native_ioapic_set_affinity,
        .irq_set_wake           = ioapic_set_wake,
        .irq_retrigger          = ioapic_retrigger_irq,
#ifdef CONFIG_IPIPE
#ifdef CONFIG_SMP
        .irq_move               = move_xxapic_irq,
#endif
        .irq_hold               = hold_ioapic_irq,
        .irq_release            = release_ioapic_irq,
#endif
        .flags                  = IRQCHIP_SKIP_SET_WAKE,
};

修正したら、パッチ適用時に出来た余計なファイルを削除します。Emacsで編集した場合には、編集時のバックアップファイル（arch/x86/kernel/apic/io_apic.c~）も消しましょう。その後パッチを当てたことを忘れないように、ディレクトリ名も変更しておきましょう。


$ find . -name "*.rej" -exec rm {} \;
$ find . -name "*.orig" -exec rm {} \;
$ cd ..
$ mv linux-yocto-3.10-3.10.32-ipipe linux-yocto-3.10-3.10.32-ipipe-edison
$ ls
edison-src                             linux-yocto-3.10-3.10.32.tar.bz2
linux-yocto-3.10-3.10.32-edison        upstream_to_edison.3.10.32.patch
linux-yocto-3.10-3.10.32-ipipe-edison  xenomai-3
$ 

これで、Edison用のXenomaiパッチを作ることが出来ます。作成したパッチは前回作成したパッチと同じ場所にコピーしましょう。これでパッチの作成が完了です。


$ diff -Narup *-3.10.32-edison *-3.10.32-ipipe-edison > xenomai-3.0-3.10.32.patch
$ cp xenomai-3.0-3.10.32.patch edison-src/device-software/meta-edison/recipes-kernel/linux/files/
$ 




    
コンパイル環境の修正

    カーネルのビルド時に作成したXenomaiパッチが適用できるよう、linux-yocto_3.10.bbappendを修正してやります。修正は以下の赤い部分を追加するだけです。


FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
COMPATIBLE_MACHINE = "edison"
LINUX_VERSION = "3.10.32"
SRCREV_machine = "61dde96f97bb5b1ed4c11caf9a857d55ad8f6e17"
SRCREV_meta = "e46e0e44708e23533f8df904cebf23a352e9053a"

SRC_URI += "file://defconfig"
SRC_URI += "file://upstream_to_edison.3.10.32.patch"
SRC_URI += "file://xenomai-3.0-3.10.32.patch"
do_configure() {
  cp "${WORKDIR}/defconfig" "${B}/.config"
}
do_kernel_configme() {
  cp "${WORKDIR}/defconfig" "${B}/.config"
}
do_patch() {
  cd ${S}
  git apply "${WORKDIR}/upstream_to_edison.3.10.32.patch"
  git apply "${WORKDIR}/xenomai-3.0-3.10.32.patch"
}

次に、WiFi関係を修正します。
EdisonのWiFiおよびBluetoothのカーネルモジュールは、カーネルとは別にedison-src/broadcom_cwsディレクトリに用意されています。カーネルのビルド後、これらのモジュールをビルドして組み込んでいます。
現状、WiFiモジュールはXenomaiカーネル上でそのままでは動作しないため、今回ははずします。
なお、Bluetoothモジュールはかろうじて動作はしますが、不安定です。


WiFiモジュールのビルドをしないようにするには、edison-src/device-software/meta-edison-distro/recipes-core/imagesディレクトリにあるedison-image.bbを修正します。

81行目から以下のように赤い部分をコメントアウトします。Bluetoothモジュールもビルドしない場合はbcm43340-btとbluetooth-rfkill-eventの行もコメントアウトします。


（ちなみに、Edison起動後にWiFiを使わなければ問題ないので、この修正は必須ではありません。）


# Wifi firmware
#IMAGE_INSTALL += "bcm43340-fw"
# Bluetooth Firmware patch for 43340 and its patch utility
IMAGE_INSTALL += "bcm43340-bt"
# service daemon that listens to rfkill events and trigger FW patch download
IMAGE_INSTALL += "bluetooth-rfkill-event"
# Wifi driver built as a kernel module
#IMAGE_INSTALL += "bcm43340-mod"


出来上がったEdisonのイメージをEdisonに書き込んだ時には、次の起動時に一旦全体の設定が行われます。その時WiFiの設定も行われ、その時にモジュールが組み込まれます。Xenomaiを組み込んだカーネルではこのときハングしてしまいますので、以下ではこの設定をしないように修正します。

Edisonへのイメージの更新方法には2通りあり、USB経由でファイルをコピーして"reboot ota"する方法と、dfu-utilを使う方法があります。それぞれ動作するスクリプトが異なり、
前者はedison-src/device-software/meta-edison-distro/recipes-core/ota-update/files/ota-update.sh
後者はedison-src/device-software/meta-edison-distro/recipes-core/first-install/files/first-install.sh
となります。

それぞれファイルの最後から9行目付近の「# Setup Access Point SSID and passphrase」以下2行をコメントアウトします。

# Setup Access Point SSID and passphrase
#setup_ap_ssid_and_passphrase
#fi_assert $? "Generating Wifi Access Point SSID and passphrase"

これでひとまず修正は完了です。






    
カーネルとイメージのビルド

    あとはカーネルをビルドし、Edisonのイメージを構築します。

念のため、カーネルをcleanしてからビルドします。


$ cd edison-src/build
$ bitbake virtual/kernel -c clean
$ bitbake virtual/kernel

このとき、ビルドエラーが発生します。これは使用したカーネルの設定ファイル（.config）が元のEdisonオリジナルのものであり、この中にはXenomai関連の設定項目がないためです（内部的にmake oldconfigを行い、新しい項目では入力を求めているため）。

ここでは明示的にカーネルの設定を行います。


$ bitbake virtual/kernel -c menuconfig

この中では、以下の設定を行います。


    

  • [General setup]--->[Local version - append to kernel release]

      

    • "-poky-edison"となってますので、Xenomaiだと分かるように設定しましょう。たとえば"-poky-edison-ipipe"など。
      • 

    • 

  • [Xenomai/cobalt]

      

    • 有効にします。
      • 

    • 

  • [Processor type and features]--->[Interrupt pipeline]

      

    • 有効にします。（[Xenomi/cobalt]が有効だと、ここもすでに有効になっています。）
      • 

    • 

  • [Power management and ACPI options]--->[CPU Frequency scaling]--->[CPU Frequency scaling]

      

    • 無効にします。
      • 

    • 

  • [Power management and ACPI options]--->[CPU idle PM support]

      

    • 無効にします。
      • 

    • 

  • [Device Drivers]--->[Network device support]--->[Wireless LAN]

      

    • 無効にします。（WiFiモジュールのビルドのところと同様、Xenomai上で使用しなければ無効にしなくてもいいけど…）
      • 

    • 


さて、後はもう一度カーネルのビルドとEdisonイメージの作成です。


$ bitbake virtual/kernel
...
$ bitbake edison-image
...
$ ../device-software/utils/flash/postBuild.sh

以上で、Edison用のXenomaiカーネルのビルドが出来ました。出来上がったtoFlashディレクトリ内のファイルをEdisonに転送し、Edison上で"reboot ota"で再起動すると、Xenomaiカーネルで起動するはずです。






    
さいごに

    現状、以下の課題が残っています。

    

  • Xenomai用のプログラムを作成するためのビルド環境を整える
    • 

  • Bluetoothモジュールが不安定なので、修正が必要。
    • 

  • WiFiモジュールを動作できるよう、修正が必要。
    • 

いつになるか分かりませんが、少しずつやっていこうと思います。


何か情報がありましたら、教えていただけるとありがたいです。

ではでは。

Intel EdisonにXenomaiを入れる（ただしWiFi, BlueToothなし...） − (準備編)

組込み Linux

お久しぶりです。
とーっっっっても久しぶりに書きます（4年9ヶ月ぶりくらいですね）。編集方法忘れてましたwww


Intel Edisonという、SDカードサイズで組込みLinuxの動作する機器がありますが、そこにLinuxのリアルタイム拡張であるXenomaiを導入してみます。ただし、Broadcomのカーネルドライバ（WiFiとBlueTooth）についてはXenomaiに対応できなかったので、現状では外しています。あしからず。


Edison では、Yocto ProjectのLinuxが使われており、Edison用の環境のソースコードはここからダウンロードでき、このドキュメントの通りにすれば、自分でビルドできます。
まずは一旦、ビルドしてみてください。

EdisonのKernelバージョンを変更する

さて、Edison上のLinux kernelは、Yocto Projectの3.10.17をベースにEdison用のパッチを適用してビルドしています。
一方、XenomaiはVanilla kernelの3.10.32に対するパッチが最も近いものになります。
なので手順としては、Edison上で3.10.32が動作する環境をまず作ってみて、その後Xenomaiパッチを作成・適用してビルドしていきます。
そこで、まずはEdison用のkernel 3.10.32を準備しましょう。

Yoctoの3.10.32のソースコードダウンロード

Yoctoの3.10.32のソースコードは、Yocto Projectのリポジトリ内のここからダウンロードできます。

3.10.32のEdison用パッチの作成

ダウンロードしたら展開し、Edison用パッチを当ててみます。ここでEdisonのソースを展開したディレクトリにダウンロードしたカーネルを展開するものとします。

$ ls
edison-src  linux-yocto-3.10-3.10.32.tar.bz2
$ tar jxf linux-yocto-3.10-3.10.32.tar.bz2
$ ls
edison-src  linux-yocto-3.10-3.10.32  linux-yocto-3.10-3.10.32.tar.bz2
$ cd linux-yocto-3.10-3.10.32
$ patch -p1 < ../edison-src/device-software/meta-edison/recipes-kernel/linux/files/upstream_to_edison.patch

すると以下のように2回ほどリバースパッチを検出して入力を求められますので、すべてリターンキーを押してやり過ごします。

...
patching file kernel/cgroup.c
Reversed (or previously applied) patch detected!  Assume -R? [n]               <--- Return
Apply anyway? [n]                                                              <--- Return
Skipping patch.
3 out of 3 hunks ignored -- saving rejects to file kernel/cgroup.c.rej
...
patching file kernel/trace/trace.c
Reversed (or previously applied) patch detected!  Assume -R? [n]               <--- Return
Apply anyway? [n]                                                              <--- Return
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file kernel/trace/trace.c.rej
patching file sound/soc/codecs/sn95031.c
$

このとき、パッチ適用に失敗したファイルは3個ほどになります。

$ find . -name "*.rej"
./drivers/hwmon/coretemp.c.rej
./kernel/trace/trace.c.rej
./kernel/cgroup.c.rej
$

このうち、kernel/trace/trace.cとkernel/cgroup.cについては無視してかまいません。3.10.17から3.10.32にバージョンが変わった間に適用された修正がEdisonパッチにも含まれていただけですので。

drivers/hwmon/coretemp.cに対する失敗は手動で修正します。
54行目から以下のように修正します。

#define BASE_SYSFS_ATTR_NO      2       /* Sysfs Base attr no for coretemp */
#define NUM_REAL_CORES          32      /* Number of Real cores per cpu */
#define CORETEMP_NAME_LENGTH    19      /* String Length of attrs */
#define MAX_CORE_ATTRS          4       /* Maximum no of basic attrs */
#define TOTAL_ATTRS             (MAX_CORE_ATTRS + 1)
#define MAX_CORE_DATA           (NUM_REAL_CORES + BASE_SYSFS_ATTR_NO)

　　　　　　　　↓↓↓↓↓

#define BASE_SYSFS_ATTR_NO      2       /* Sysfs Base attr no for coretemp */
#define NUM_REAL_CORES          32      /* Number of Real cores per cpu */
#define CORETEMP_NAME_LENGTH    33      /* String Length of attrs */
#define MAX_CORE_ATTRS          5       /* Maximum no of basic attrs */
#define MAX_THRESH_ATTRS        4       /* Maximum no of threshold attrs */
#define TOTAL_ATTRS             (MAX_CORE_ATTRS + MAX_THRESH_ATTRS)
#define MAX_CORE_DATA           (NUM_REAL_CORES + BASE_SYSFS_ATTR_NO)

あとはパッチ時に出来た余計なファイルを消します。Emacsで編集した場合には、編集時のバックアップファイル（drivers/hwmon/coretemp.c~）も消しましょう。

$ find . -name "*.rej" -exec rm {} \;
$ find . -name "*.orig" -exec rm {} \;

あとはもとの3.10.32カーネルと差分をとってパッチを作成します。

$ cd ..
$ mv linux-yocto-3.10-3.10.32 linux-yocto-3.10-3.10.32-edison
$ tar jxf linux-yocto-3.10-3.10.32.tar.bz2
$ diff -Narup linux-yocto-3.10-3.10.32 linux-yocto-3.10-3.10.32-edison > upstream_to_edison.3.10.32.patch

これを元のパッチがあった場所に配置して3.10.32用のEdisonパッチの作成はひとまず完了です。

$ cp upstream_to_edison.3.10.32.patch edison-src/device-software/meta-edison/recipes-kernel/linux/files/
bitbakeの設定ファイルの修正

bitbakeで3.10.32カーネルをコンパイルするためには、ディレクトリ edison-src/device-software/meta-edison/recipes-kernel/linux/ にある
linux-yocto_3.10.bbappend を修正する必要があります。

このファイルの中身は以下のようになっています。

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
COMPATIBLE_MACHINE = "edison"
LINUX_VERSION = "3.10.17"
SRCREV_machine = "c03195ed6e3066494e3fb4be69154a57066e845b"
SRCREV_meta = "6ad20f049abd52b515a8e0a4664861cfd331f684"

SRC_URI += "file://defconfig"
SRC_URI += "file://upstream_to_edison.patch"
do_configure() {
  cp "${WORKDIR}/defconfig" "${B}/.config"
}
do_kernel_configme() {
  cp "${WORKDIR}/defconfig" "${B}/.config"
}
do_patch() {
  cd ${S}
  git am "${WORKDIR}/upstream_to_edison.patch"
}

このなかで分かりにくいのは、SRCREV_machineとSRCREV_meta です。
SRCREV_machineには、Yocto Project内のGitリポジトリにある、3.10.32カーネルのcommit IDです。3.10.32は"61dde96f97bb5b1ed4c11caf9a857d55ad8f6e17"です。
SRCREV_metaは、ここから探すことが出来ます。3.10.32の最も新しいもの（3.10.34に変わる直前）のcommit IDは、"e46e0e44708e23533f8df904cebf23a352e9053a"となります。
またこの中には先ほど作成したパッチを適用するように修正する必要があります。ただし、diffコマンドを用いたパッチですので、「git am 〜」ではなく「git apply 〜」に変更します。
修正は以下のようになります。

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
COMPATIBLE_MACHINE = "edison"
LINUX_VERSION = "3.10.32"
SRCREV_machine = "61dde96f97bb5b1ed4c11caf9a857d55ad8f6e17"
SRCREV_meta = "e46e0e44708e23533f8df904cebf23a352e9053a"

SRC_URI += "file://defconfig"
SRC_URI += "file://upstream_to_edison.3.10.32.patch"
do_configure() {
  cp "${WORKDIR}/defconfig" "${B}/.config"
}
do_kernel_configme() {
  cp "${WORKDIR}/defconfig" "${B}/.config"
}
do_patch() {
  cd ${S}
  git apply "${WORKDIR}/upstream_to_edison.3.10.32.patch"
}

ここまでくれば、あとはコンパイルです。

もし、bitbakeが使える環境になっていなければedison-srcディレクトリで、以下のように使えるようにしてやります。

$ cd edison-src
$ source poky/oe-init-build-env

### Shell environment set up for builds. ###

You can now run 'bitbake '

Common targets are:
    core-image-minimal
    core-image-sato
    meta-toolchain
    adt-installer
    meta-ide-support

You can also run generated qemu images with a command like 'runqemu qemux86'
$

そしてビルドしてやります。

$ bitbake virtual/kernel
...
$ bitbake edison-image
...
$ ../device-software/utils/flash/postBuild.sh

以上で、Edison用の3.10.32カーネルのビルドが出来ました。出来上がったtoFlashディレクトリ内のファイルをEdisonに転送し、Edison上で"reboot ota"で再起動すると、3.10.32カーネルで起動するはずです。


とりあえず、今日はここまで。

Xenomaiパッチの適用については、次回書きますね。


追記：Bluetoothは使えそうですね。

DRBDを動かしてみた備忘録

参考サイト

いつものように、ゲストOS 2台で構築。OSはCentOS 5.4です。
1台目のホスト名を"drbd_prim"、IPアドレスを192.168.1.96、2台目のホスト名を"drbd_second"、IPアドレスを192.168.1.97とします。
また、DRBDデバイスは/dev/drbd0とします。

まず、ゲストOS一つを準備してその後それをコピーします。

1台目

先日作っておいた素のCentOS 5.4（先日の「ゲストOSのインストール（CentOS）」のところまでのもの）をコピー。

# virt-clone -o centos.base -n drbd_prim -f /var/lib/libvirt/images/drbd_prim.img

で、ハードディスクを追加。virt-manager等で追加してください。
ここでは、/dev/hdbに16Gを作っています。

起動してパッケージインストール

ゲストを起動して、必要なパッケージのインストールをしていきます。
まずはアップデート。

# yum -y update

DRBDのビルドに必要なパッケージをインストール

# yum -y install make gcc flex kernel-devel rpm-build
DRBDのビルドとインストール

適当なディレクトリでDRBDのソースを取得して展開します。

# mkdir work
# cd work/
# wget http://oss.linbit.com/drbd/8.3/drbd-8.3.7.tar.gz
# tar zxf drbd-8.3.7.tar.gz 
# cd drbd-8.3.7
#

で、続いてrpmをビルド

# ./configure
# make rpm
# make km-rpm
#

/usr/src/redhat/RPMS/*/ 以下にrpmパッケージが8個作成されるので、これらをインストール。

# rpm -ivh /usr/src/redhat/RPMS/*/drbd-*
準備中...                ########################################### [100%]
   1:drbd-utils             ########################################### [ 13%]
   2:drbd-bash-completion   ########################################### [ 25%]
   3:drbd-heartbeat         ########################################### [ 38%]
   4:drbd-pacemaker         ########################################### [ 50%]
   5:drbd-udev              ########################################### [ 63%]
   6:drbd-xen               ########################################### [ 75%]
   7:drbd                   ########################################### [ 88%]
   8:drbd-km-2.6.18_164.15.1########################################### [100%]
#
DRBDの設定

DRBDの設定は、/etc/drbd.d/に、*.resとして作成します。（/etc/drbd.confを直接編集してもいいですが。）

# cat /etc/drbd.d/test.res 
resource test {
    device /dev/drbd0;
    disk /dev/hdb1;
    meta-disk internal;
    on drbd_prim {
        address 192.168.1.96:7789;
    }
    on drbd_second {
        address 192.168.1.97:7789;
    }
}
#

因みに設定ファイルの例は、ソースコードの scripts/drbd.conf.example にあります。

続いて、追加したハードディスクはfdiskでパーティション(/dev/hdb1)を作成しておきます。

# fdisk -l /dev/hdb

Disk /dev/hdb: 17.1 GB, 17179868672 bytes
255 heads, 63 sectors/track, 2088 cylinders
Units = シリンダ数 of 16065 * 512 = 8225280 bytes

デバイス Boot      Start         End      Blocks   Id  System
/dev/hdb1               1        2088    16771828+  83  Linux
#

ネットワーク設定は、以下のように赤いところを編集し、また、ifcfg-eth0.bakは削除します。

# cat /etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=drbd_prim  ← ホスト名
# rm /etc/sysconfig/network-scripts/ifcfg-eth0.bak
# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none  ← 固定IPアドレス
ONBOOT=yes
HWADDR=00:16:36:4d:6f:90
IPADDR=192.168.1.96
NETMASK=255.255.255.0
GATEWAY=192.168.1.1
#

一旦ここまで完了したら、シャットダウンし、2台目のゲストを作成します。

2台目のゲスト作成

virt-cloneコマンドを使ってdrbd_primをdrbd_secondとしてコピーします。

# virt-clone -o drbd_prim -n drbd_second
What would you like to use as the cloned disk (file path) for '/var/lib/libvirt/
images/drbd_prim.img'? /var/lib/libvirt/images/drbd_second.img
 What would you like to use as the cloned disk (file path) for '/var/lib/libvirt
/images/drbd_prim_sync.img'? /var/lib/libvirt/images/drbd_second_sync.img
Cloning /var/lib/libvirt/ 100% |=========================|  16 GB    01:34     
Cloning /var/lib/libvirt/ 100% |=========================|  16 GB    01:39     
 
Clone 'drbd_second' created successfully.
#

で、2台とも起動します。（2台目はこの後ネットワークなどの設定をします。）

# virsh start drbd_prim
# virsh start drbd_second
#
1台目の続き

1台目にログインし、カーネルモジュールを読み込みます。

# modprobe drbd
# cat /proc/drbd  ← 確認
version: 8.3.7 (api:88/proto:86-91)
GIT-hash: ea9e28dbff98e331a62bcbcc63a6135808fe2917 build by root@drbd_prim, 2010-04-05 23:10:16
#

drbdのメタデータを作ります。

# drbdadm create-md test
md_offset 17174347776
al_offset 17174315008
bm_offset 17173790720

Found ext3 filesystem
      104388 kB data area apparently used
    16771280 kB left usable by current configuration

Even though it looks like this would place the new meta data into
unused space, you still need to confirm, as this is only a guess.

Do you want to proceed?
[need to type 'yes' to confirm] yes  ← ここで"yes"を入力

Writing meta data...
initializing activity log
NOT initialized bitmap
New drbd meta data block successfully created.
success
#

次にDRBDのデーモンを開始します。

# /etc/init.d/drbd start
Starting DRBD resources: [ d(test) n(test) ]..........
 **************************************************************
 DRBD's startup script waits for the peer node(s) to appear.
 - In case this node was already a degraded cluster before the
   reboot the timeout is 0 seconds. [degr-wfc-timeout]
 - If the peer was available before the reboot the timeout will
   expire after 0 seconds. [wfc-timeout]
   (These values are for resource 'test'; 0 sec -> wait forever)
 To abort waiting enter 'yes' [  13]:yes  ← "yes"を入力

.
#

/proc/drbdを確認すると"Secondary/Unknown"になっているのが分かります（2台目はまだ未設定なのでUnknownです）。

# cat /proc/drbd 
version: 8.3.7 (api:88/proto:86-91)
GIT-hash: ea9e28dbff98e331a62bcbcc63a6135808fe2917 build by root@drbd_prim, 2010-04-05 23:10:16
 0: cs:StandAlone ro:Secondary/Unknown ds:Inconsistent/DUnknown   r----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:16771280
#

これをPrimaryにしてやります。

# drbdsetup /dev/drbd0 primary -o
# cat /proc/drbd  ← 確認すると"Primary/Unknown"になりました。
version: 8.3.7 (api:88/proto:86-91)
GIT-hash: ea9e28dbff98e331a62bcbcc63a6135808fe2917 build by root@drbd_prim, 2010-04-05 23:10:16
 0: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown   r----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:16771280
#

これでDRBDデバイスが使えるようになったので、/dev/drbd0 をフォーマットしてやります。

# mkfs.ext3 /dev/drbd0
mke2fs 1.39 (29-May-2006)
Filesystem label=
OS type: Linux
＜中略＞

This filesystem will be automatically checked every 38 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
#

マウントすれば使えるようになっています。

# mount /dev/drbd0 /mnt/
# df
Filesystem           1K-ブロック    使用   使用可 使用% マウント位置
/dev/mapper/VolGroup00-LogVol00
                      15109112   2679456  11649780  19% /
/dev/hda1               101086     19114     76753  20% /boot
tmpfs                   255024         0    255024   0% /dev/shm
/dev/drbd0            16508024    176244  15493216   2% /mnt
#

2台目

2台目はまずネットワークを設定してやります(赤いところを編集、ifcfg-eth0.bakは削除）。

# cat /etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=drbd_second  ← ホスト名
# rm /etc/sysconfig/network-scripts/ifcfg-eth0.bak
# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none  ← 固定IPアドレス
ONBOOT=yes
HWADDR=00:16:36:0f:62:75
IPADDR=192.168.1.97
NETMASK=255.255.255.0
GATEWAY=192.168.1.1
# reboot  ← 再起動

あとは、再起動後にDRBDのメタデータの作成とデーモンを起動するだけ。

# drbdadm create-md test
md_offset 17174347776
al_offset 17174315008
bm_offset 17173790720

Found ext3 filesystem
      104388 kB data area apparently used
    16771280 kB left usable by current configuration

Even though it looks like this would place the new meta data into
unused space, you still need to confirm, as this is only a guess.

Do you want to proceed?
[need to type 'yes' to confirm] yes  ← "yes"を入力

Writing meta data...
initializing activity log
NOT initialized bitmap
New drbd meta data block successfully created.
success
# /etc/init.d/drbd start
Starting DRBD resources: [ d(test) ].
# cat /proc/drbd 
version: 8.3.7 (api:88/proto:86-91)
GIT-hash: ea9e28dbff98e331a62bcbcc63a6135808fe2917 build by root@drbd_prim, 2010-04-05 23:10:16
 0: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C r----
    ns:0 nr:3200 dw:3200 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:16768080
        [>....................] sync'ed:  0.1% (16372/16376)M
        finish: 11:38:40 speed: 352 (352) K/sec
#

勝手に同期が始まります。

Hadoopのインストール

Hadoopのインストールに手間取ったので、備忘録。

前提条件

以下の環境で動作させています。

また、Hadoopのマスターノードのホスト名を「hmaster」、スレーブを「hslave1, hslave2, ...」とします。

ゲストOSのインストール（CentOS）

KVM上で動作するCentOSのイメージを一つ作成します。各ノードはこのイメージのコピーを使用します。
再起動後の最初の設定では、FirewallとSELinuxを無効にしておきます。
その他のCentOSのインストール自体の説明はここでは省略しますので、あしからず。
ログイン後、ホスト側から扱い易いように、コンソールの設定をしておきます。/etc/inittabに、"co:2345:respawn:/sbin/agetty ttyS0 115200 vt100-nav"を追加しておけば良いです。これでホスト側から「virsh console ＜ホスト名＞」でアクセスできます。
また、OSをアップデートしておきましょう。

共通項目のインストール・設定

SunのJavaをインストール

ここからJDK（現在はJDK 6 Update 18）をダウンロードし、インストールします。（インストールの詳細は略）

Hadoopのインストール

yumリポジトリを登録して、「hadoop-0.20」をインストールします。（rootで作業します。）

# cd /etc/yum.repos.d/
# wget http://archive.cloudera.com/redhat/cdh/cloudera-testing.repo
# yum -y install hadoop-0.20

この後、仮想マシンを終了させます。

マスターノードの設定

マスターノード用の仮想マシンの準備

まずホスト上で、作成した仮想マシンイメージをコピーしてマスターノード用の仮想マシンイメージを作成します。次のコマンドを使います。

virt-clone -o 元のゲスト名 -n 新しいゲスト名 -f ディスクイメージ名

例えば、

$ sudo virt-clone -o centos54 -n hmaster -f /var/lib/libvirt/images/hmaster.img

とします。

その後、マスターノードの仮想マシンを起動し、コンソールで接続します。

$ virsh start hmaster
$ sudo virsh console hmaster

一般ユーザでログインした後、suコマンドでrootにスイッチします。

ネットワークの設定

まず、ネットワーク関連を設定します。
仮想マシンをコピーした際に作成される ifcfg-eth0.bak は削除し、ifcfg-eth0 に、ダイナミックDNSにホスト名を登録するための設定をします。

# rm /etc/sysconfig/network-scripts/ifcfg-eth0.bak
# echo 'DHCP_HOSTNAME=hmaster' >> /etc/sysconfig/network-scripts/ifcfg-eth0

また、/etc/sysconfig/network に書かれたホスト名を編集します。

# cat /etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=hmaster
#

あと、/etc/hosts 内の127.0.0.1は、「localhost.localdomain localhost」だけになるようにします。
（インストール時にホスト名を設定したりすると、ここに追記されたりするので）

ここで一旦ネットワークを再起動しましょう。

# /etc/init.d/network restart
Hadoopの設定

ここでは、/etc/hadoop/conf/ 以下のファイルを編集します。

  • core-site.xml

  
    fs.default.name
    hdfs://hmaster:8020
  



  
    dfs.replication
    3　　← スレーブノードの数（ここでは3つ）
  • mapred-site.xml

  
    mapred.job.tracker
    hmaster:8021
  • masters
hmaster
  • slaves
hslave1
hslave2
hslave3

次にHDFSのフォーマットを行います。

# sudo -u hadoop hadoop-0.20 namenode -format

最後に、起動時にHadoopのデーモンを開始出来るように設定します。

# chkconfig --add hadoop-0.20-namenode
# chkconfig --add hadoop-0.20-jobtracker
NFSの設定

/etc/hadoop/ 以下をスレーブと共有できるよう、NFSの設定を行います。
まず、/etc/exports を編集します。

/etc/hadoop     hslave*(rw,no_all_squash,sync)

その後、NFSデーモンを起動し、起動時に開始できるようにします。

# /etc/init.d/nfs start
# chkconfig nfs on

ここまで完了したら再起動し、スレーブの設定に進みましょう。

スレーブノードの設定

ここではhslave1のスレーブノードについて説明します。他のhslave2, hslave3は、ホスト名を変更して作業してください。
マスターノードと同様、仮想マシンイメージをコピーします。

$ sudo virt-clone -o centos54 -n hslave1 -f /var/lib/libvirt/images/hslave1.img

その後、スレーブノードの仮想マシンを起動し、コンソールで接続します。

$ virsh start hslave1
$ sudo virsh console hslave1

一般ユーザでログインした後、suコマンドでrootにスイッチし、マスターノードと同じようにネットワーク関連を設定します。

# rm /etc/sysconfig/network-scripts/ifcfg-eth0.bak
# echo 'DHCP_HOSTNAME=hslave1' >> /etc/sysconfig/network-scripts/ifcfg-eth0

/etc/sysconfig/network に書かれたホスト名を修正します。

# cat /etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=hslave1
#

そして一旦ネットワークを再起動します。

# /etc/init.d/network restart
NFSの設定

起動時にマスターノードの/etc/hadoopをスレーブの/etc/hadoopにマウントするようにします。

# rm -rf /etc/hadoop/*
# echo 'hmaster:/etc/hadoop /etc/hadoop nfs defaults 0 0' >> /etc/fstab
Hadoopのデーモンの設定

起動時にHadoopのデーモンを開始出来るように設定します。

# chkconfig --add hadoop-0.20-datanode
# chkconfig --add hadoop-0.20-tasktracker

そしてリブートし、他のマスターノードについても同じ設定を行います。

確認

Web経由でマスターノードにアクセスし、確認します。

スレーブノードの追加

  1. まず /etc/hadoop/conf/hdfs-site.xml で設定した数を必要な分だけ増やす。
  2. /etc/hadoop/conf/slaves にスレーブノードを追加する。
  3. スレーブノードを上記のとおりに作成し、リブートする。

TOMOYO GUI on Mandriva Linux 2010

セキュアOS

TOMOYO Linuxがつぶやき始めましたが、その中に「Mandriva Linux 2010 is Finally Out with TOMOYO Linux」と言うのがありました。

「ふ〜ん。」と思ってそこにあるリンク先を見てみると、

Mandriva Control Center also bring improvements in tools: new netprofile management tool, gui for Tomoyo security framework, and parental control.

とあるではないですか。「以前作っていたEclipseベースのGUIかな？」と思ってもう少し調べてみるとこんな記事が見つかり、どうもEclipseベースではないようです。


ということで、Mandriva Linux 2010を動かして試してみます。

Mandriva Linux 2010のインストール

公式サイトから、インストールDVDのイメージをダウンロードします。
後は略。

TOMOYO GUIのインストール

デフォルトでは、TOMOYO GUIはインストールされていませんので、インストールから始めます。


まずメインメニューから「ツール」→「システムツール」→「コンピュータを設定」を選択（もしくはパネルの「コンピュータを設定」アイコンをクリック）してコントロールセンターを開きます。


そして「RPMをインストール／アンインストール」を選ぶと「ソフトウェアの管理」が開きます。


左上のプルダウンメニューが「GUIのあるパッケージ」となっていれば、「すべて」に変更してやります。


右の「検索対象」に「tomoyo-gui」と入力して検索すると、パッケージが表示されます。


後は、パッケージを選択して「適用」ボタンを押すと、関連するパッケージも一緒にインストールされます。


インストール完了後は、一旦コントロールセンターを終了します。

TOMOYO GUIを使ってみる（初期化）

再度、コントロールセンターを起動し、左のメニューから「セキュリティ」を選択すると、「Configure TOMOYO Linux policy」という項目が追加されているので、それを選択します。


コントロールセンター内でTOMOYO GUIが動作しますが、ポリシーはまだないので、初期化するかどうか聞いてきます。


初期化が完了すると、再起動するように促されるので、再起動してやります。

TOMOYO GUIを使ってみる（ポリシー設定）

ふたたびTOMOYO GUIを起動すると、こんどはドメインが出来上がっています。


また、例外ポリシーも出来上がってます。


「Help」のタグを開いてみると、誇らしげなTOMOYOペンギンがあらわれます。いいですね〜。


「All domains」のタグでドメインを選択（ShiftキーやCtrlキーを使って複数選択も可能）すると、各ドメインの詳細が表示されます。


右端にはドメインのプロファイルがプルダウンメニューで選択できるようになっています。


以下は、いくつかをLearningモードにして再起動した結果で、Disabledモード以外のドメインが強調表示され、学習した結果が下に表示されます。（強調されているドメインは、「Active domains」タブで見ることが出きるようになります）


学習した結果にマウスを持っていくとアンダーラインが表示され、

そこをクリックすると、「編集」か「削除」を選べます。

「編集」を選ぶと編集画面が表示され、そこで修正することができます。

使ってみて

GUIでTOMOYO Linuxのポリシー編集作業が行えるのはいいですね。ccs-editpolicyは便利ですが、初めての人にはGUIであるというだけで抵抗感は少なくなると思います。
ただ、ポリシーの修正や削除はできても、追加ができないのはちょっとやりにくいですね。
まあ、そのうち改善されるんでしょうが。

TOMOYO Linux 1.7.1がリリース

セキュアOS

昨日、TOMOYO Linux 1.7.1がリリースされました。
このTOMOYO LinuxがOSSとしてリリースされたのが4年前の11月11日です。
私がこのはてぶを開始したのがその次の日の11月12日で、その日にTOMOYO Linuxに触れています。その時はここまでTOMOYO Linuxに関わるとは思ってもいませんでしたね。