読者です 読者をやめる 読者になる 読者になる

のぴぴのメモ

自分用のLinuxとかの技術メモ

KickStartその1(KickStartによるLinux自動インストール概要)

0.関連記事一覧

1.はじめに

1.1KickStartとは

RHELfedoraなどredhatディストリビューションの、OS自動インストール機能です。*1

1.2ざっくりした使い方

KickStart用のファイルを作成し、インストーラ起動時のオプションで作成ファイルを指定すればOKです。ファイルは、普通にOSインストールするとその時の設定で"/root/anaconda-ks.cfg"ファイルが作成されるので、それを修正して使うのが簡単です。*2

  1. 普通にRHEL/fedoraをインストール
  2. インストール後、"/root/anaconda-ks.cfg"をコピーし編集
  3. 編集したファイルをインストーラから読み込めるよう仕込む。仕込み方法は「3.補足」参照
  4. インストーラでファイルオプション(inst.ks=xxx)を追加して実行
  5. あとは完了するまで待つ。

2.利用手順

2.1ファイル(ks.cfg)の編集

普通にインストールすると、rootのホームディレクトリ直下に"anaconda-ks.cfg"ファイルが作成されているので、このファイルを元に必要な部分を編集します。ファイル名は、特にこだわりがなければKickStartデフォルトの"ks.cfg"にしておくとブート時の設定が少し省けて良いです。*3
■ks.cfgの例(RHELのDVDメディアからインストールする場合の設定例)
設定内容については、こちらの記事を参照して下さい。

#version=DEVEL
# System authorization information
auth --enableshadow --passalgo=sha512
repo --name="Server-HighAvailability" --baseurl=file:///run/install/repo/addons/HighAvailability
repo --name="Server-ResilientStorage" --baseurl=file:///run/install/repo/addons/ResilientStorage

# Use CDROM installation media
cdrom

# Select Install mode. graphical:Use graphical install, text:Use text install.
#graphical
text

# Run the Setup Agent on first boot
firstboot --enable
ignoredisk --only-use=sda
# Keyboard layouts
keyboard --vckeymap=jp --xlayouts='jp'
# System language
lang ja_JP.UTF-8

# Network information
network  --bootproto=dhcp --device=enp0s3 --noipv6 --activate
network  --hostname=testserver

# Root password
rootpw --iscrypted $6$WYz7GsXMGCHrJnw.$BoSTW/Ac9vaVvjwB0NVg3.sccEh2g7eZhU7c7BRRx/d8Dxoo7UE70EYyhPEBiemPLxB.Pq0StVaoDIWTWLCFx/
# System timezone
timezone Asia/Tokyo --isUtc
# System bootloader configuration
bootloader --append=" crashkernel=auto" --location=mbr --boot-drive=sda
# Partition clearing information
clearpart --all --initlabel --drives sda

# Disk partitioning information
part pv.295 --fstype="lvmpv" --ondisk=sda --size=1    --grow
part /boot  --fstype="xfs"   --ondisk=sda --size=500  --label=boot
volgroup rootvg --pesize=4096 pv.295
logvol swap  --fstype="swap" --size=256        --name=swaplv --vgname=rootvg
logvol /home --fstype="xfs"  --size=100        --name=homelv --vgname=rootvg --label="home" 
logvol /     --fstype="xfs"  --size=1   --grow --name=rootlv --vgname=rootvg --label="root" 

%packages
@^infrastructure-server-environment
@base
@compat-libraries
@core
@large-systems
@performance
@security-tools
kexec-tools
telnet
trace-cmd
vim
%end

�don com_redhat_kdump --enable --reserve-mb='auto'

%end

# Reboot after the installation is complete.(eject DVD media before rebooting)
reboot --eject

2.2ファイル検証

作成したファイルは、ksvalidatorコマンドで内容を検証します。
ksvalidatorは通常はインストールされていませんので、yum/dnfコマンドでパッケージを個別にインストールします。

# yum install pykickstart

検証は以下のコマンドで実行します。

$ ksvalidator ks.cfg

KickStartのバージョン毎の構文差異を気にする場合は、インストールするOSバージョンを指定して、検証することもできます。*4

$ ksvalidator -v RHEL7 ks.cfg

2.3インストーラを起動しキックスタートをローディングする

主な方法を以下に列挙します。個人的には、ネットワークが使えるならネット(http/httpsなど)、ネットワークが使えないならフロッピー(判別しやすいから)から設定ファイルを読みこませるのがいいと思っています。

  1. インストーラを起動する。(私はRHELのDVDメディアからブート)
  2. 起動画面で"tabキー"で介入し"ks="、または"inst.ks="オプションでキックスタートファイルの場所を指定する。(下記画面参照)*5
    1. httpの例:"inst.ks=http://192.168.0.1/ks.cfg"
    2. フロッピーの例:"inst.ks=hd:fd0:/ks.cfg"
    3. DVDの例:"inst.ks=cdrom:/ks.cfg"

※ファイルがメディア直下で、ファイル名が"ks.cfg"の場合は、":/ks.cfg"を省略可能です。
f:id:nopipi:20160722080514p:plain

2.4インストール完了

キックスタートファイルが上手く書かれていれば、後は最後まで自動的にインストールされます。

3.補足(kickstartファイルを読み込ませるベストプラクティス)

KickStartファイルをどう読み込ませるか以外に悩みましたので、私なりの考え方を整理しました。

(1)ネットワークが利用可能な環境の場合

ネットワークが利用可能であれば、http/httpsあたりでkickstartファイルを読み込ませるのが最も簡単で確実です。

(2)ネットワークが使えない場合

この場合が悩ましいです。私がおすすめと思った順に記載します。

(2)-1 インストーラをカスタマイズする

インストーラのイメージをカスタマイズして、作成したファイルを組み込み自動的に読み込ませるのが一番確実で、全自動化が可能です。ですが、リビジョンや設定を変更都度に、インストールイメージを作りなおさなければならないのが手間なので、OSインストールの頻度が低い場合は逆に非効率かもしれません。

(2)-2 フロッピーから読み取る

RHELドキュメントには詳細な説明が無いのが気になりますが・・・。ですが個人的には、フロッピーが使える環境であればフロッピーから読み込ませるのが、デバイス名が"fd0"で明確なのもあり、一番無難な気がします。*6

(2)-3 KicStartファイル専用のdvd(isoファイル)を準備して差し替える

kickStartのファイルをisoまたはDVDにし、インストーラで差し替えて利用する方法です。(オプションは、"inst.ks=cdrom/ks.cfg"という感じです。)"Plese Insert CDROM containing"というメッセージが表示されたらDVDを差し替えますが、ロックがかかってejectできなかったりするようです。

(2)-4 USBメモリor外付けHDDを利用する

RHELドキュメントを見ると、USBメモリか外付HDDから読み込むのが無難な方法です。ですが、インストールするディスク構成が異なるとデバイス名が変わるのが難点です。UUIDでデバイスを指定する方法もあるのですが、インストールメディアをカスタマイズせず、毎回"ks="オプションを手打ちする場合は長すぎて面倒です。

4.リファレンス(kickstartドキュメント)

必要な情報は大方、利用するRHEL/fedoraバージョンの「インストールガイド」の終盤にある「キックスタートを使ったインストール」という章に載っています。

*1:RHEL/Fedoraインストーラであるanacondaに含まれる機能です。kickStartを含むanacondaは、redhat社の「Red Hat Installer Engineering Team」が開発しており、ソース&ドキュメントはgithub(Red Hat Installer Engineering Team · GitHub)で公開されています。

*2:以前はファイル作成用のGUIがありましたが、今は開発が放置されているので利用は推奨されないようですインストールガイド 23.2. キックスタートを使ったインストールの実行方法の重要を参照

*3:anacondaの中のdracut用モジュールに"fetch-kickstart-disk"というシェルがあり、そこでファイルのパスのデフォルトが"/ks.cfg"と定義されています。

*4:指定できるバージョン一覧は、"ksvalidator -l dummy"コマンドで確認できます。ファイルパスの文字を何かしら入れないとエラーになるあたりが微妙ですが。

*5:どちらでも利用可能ですが、以前の書き方が"ks="で、最近は"inst.ks="が基本のようです。

*6:以前は、ks=floppyで読み込めましたが、今はks=hd:fd0のように指定します。

KickStartその2(ks.cfg設定ファイルの説明)

0.関連記事一覧

1.はじめに

この記事は、RHEL/fedoraのOS自動インストールを行うKickStartの設定ファイル(ks.cfg)の書き方の詳細です。ネットワーク設定、ディスク設定、パッケージ設定、ユーザ設定、を中心に編集頻度が高そうな項目を説明します。

2.ネットワーク設定

(1)スタティック設定例

enp0s3,enp0s8双方をstaticでネットワーク設定する場合の例です。

# Network information
network --bootproto=static --device=enp0s3 --ip=10.0.2.15    --netmask=255.255.255.0 --gateway=10.0.2.2 --nameserver=10.0.2.3  --noipv6 --activate
network --bootproto=static --device=enp0s8 --ip=192.168.0.20 --netmask=255.255.255.0 --noipv6 --activate --nodefroute 
network --hostname=testserve
  • "--bootproto=static"とすることで、静的設定になります。
  • "--device"で、設定するデバイスを指定します。
  • "--ip"、"--netmask="、"--gateway="でIP設定をします。
  • "--nameserver"で、参照先DNSを指定します。DNSが複数ある場合は、"=x.x.x.x,y.y.y.y"とカンマで区切って指定します。
  • "--noipv6"で、ipv6を無効化します。
  • "--activate"を付けることで、boot時にデバイスが有効化されます。
  • "--nodefroute "は、デフォルトGWと通信しないデバイスに設定します。
  • "network --hostname=xxxx"で、ホスト名を設定します。

(2)DHCP設定例

enp0s3をDHCP設定に変更した例です。

# Network information
network --bootproto=dhcp   --device=enp0s3 --noipv6 --activate
network --bootproto=static --device=enp0s8 --ip=192.168.0.20 --netmask=255.255.255.0 --noipv6 --activate --nodefroute 
network --hostname=testserver
  • "--bootproto=dhcp"とすることでDHCP設定となります。
  • ほかは(1)の内容と同じです。

bonding・vlanと組み合わせた構成は下記記事を参照して下さい。
nopipi.hatenablog.com

3.ディスク設定

インストール時のディスク構成(パーティション、LVM、ファイルシステムなど)を指定します。ディスク設定は、設計したディスク構成になるよう手動で組み直したほうが基本良さそうです。

(1)ブートディスク構成例*1

f:id:nopipi:20160719100545p:plain

(2)上記構成例の場合のKickStart設定
# Specifies used disk for installation 
ignoredisk --only-use=sda

# System bootloader configuration
bootloader --append=" crashkernel=auto" --location=mbr --boot-drive=sda

# Partition clearing information
clearpart --all --initlabel --drives sda

# Disk partitioning information
part pv.295 --fstype="lvmpv" --ondisk=sda --size=1    --grow
part /boot  --fstype="xfs"   --ondisk=sda --size=500  --label=boot
volgroup rootvg --pesize=4096 pv.295
logvol swap  --fstype="swap" --size=256        --name=swaplv --vgname=rootvg
logvol /home --fstype="xfs"  --size=100        --name=homelv --vgname=rootvg --label="home" 
logvol /     --fstype="xfs"  --size=1   --grow --name=rootlv --vgname=rootvg --label="root" 
  1. インストーラが対象とするディスクの指定
    1. "ignoredisk"で"--only-use="オプションを設定すると、指定したディスクのみインストーラの対象になります。
  2. ブートローダの指定
    1. anaconda-ks.cfgから基本編集しませんが、"bootloader"で"--location=mbr"とすることで、MBRブートローダがインストールされます。
  3. ディスクフォーマット(既存パーティション削除)
    1. "clearpart --all --initlabel --device sda"で対象ディスクの既存パーティションを全て削除します。*2
  4. パーティション設定
    1. partコマンドでパーティションを作成します。
    2. パーティション用途指定
      1. ファイルシステムとして利用: "part /boot --fstype="xfs" "と記載します。
      2. スワップとして利用: "part swap --fstype="swap" "と記載します。
      3. LVMとして利用: "part pv.XX --lvmpv" "と記載します。XXは識別番号で任意の数字です。
    3. サイズ指定
      1. 固定サイズ指定:"--size xxx"と記載。xxxはMB単位でサイズ指定します。
      2. 残り容量全て:"--grow"オプションを利用し、"--size 1 --grow"のように記載します。この場合、最低容量1MBで空きがあるだけ確保する設定になります。
    4. その他
      1. "--ondisk="で、パーティションを作成するディスクを指定します。
      2. ファイルシステムにラベル名を指定するときは、"--label=xxxx"で設定します。
  5. LVM
    1. vg作成: "volgroup VG名 --pesize=4096 PVのパーティション"で作成します。
      1. "--pesize":任意のオプションです。LVMのPEサイズをKiBで指定します。
    2. LV作成: "logvol --name=LV名称 --vgname=VG名"で作成します。ファイルシステム、サイズ指定など、他のパラメータはpartコマンドと同じです。
      1. "--name=XXX":作成するLV名称を指定します。
      2. "--vgname=XXX":LVを作成するVGを指定します。

4.インストールパッケージ設定

インストルするパッケージは、下記のように"%packages 〜 %end"のセクションの間で設定します。基本はGUIで設定内容に足りないパッケージを追加するのが簡単です。

%packages
@^infrastructure-server-environment
@base
@compat-libraries
@core
@large-systems
@performance
@security-tools
kexec-tools
telnet
trace-cmd
vim
%end
  1. @で始まるのがインストールするパッケージグループです。
  2. 足りないパッケージを個別に追加します。

5.ユーザ設定

(1)rootユーザのパスワード設定

rootユーザのパスワードは"rootpw"で設定します。パスワードは、(a)平文文字列、または(b)暗号化された文字列で指定できます。

(1)-(a)パスワードを平文で記載する場合

オプション無し、または"--plaintext"オプションを付けることで、平文でrootユーザのパスワードを指定します。その場合、パスワードが丸見えになるので、KickStartファイルの管理には十分注意してください。

rootpw --plaintext "SyokiPass@9999"
(1)-(b)暗号化したパスワードで記載する場合

"--iscrypted"オプションを付けることで、暗号化された文字列でパスワードを指定します。暗号化されたと言っても時間をかければ解読できるので、KickStartファイルの管理はやはり注意してください。

  • "/etc/shadow"に登録する形式で暗号化した文字列で指定します。
  • 暗号化形式は"auth"で指定され形式になります。例えば、"auth --enableshadow --passalgo=sha512"とある場合は、SHA512形式の暗号化になります。
  • 暗号化されたパスワードの作り方は、次項目(2)を参照して下さい。
# Root password
rootpw --iscrypted $6$WYz7GsXMGCHrJnw.$BoSTW/Ac9vaVvjwB0NVg3.sccEh2g7eZhU7c7BRRx/d8Dxoo7UE70EYyhPEBiemPLxB.Pq0StVaoDIWTWLCFx/

(2)指定する暗号文字列をどうするか?

やり方として2例、(a)pythonで生成する、(b)設定したいパスワードが入った"/etc/shadow"ファイルからコピーする、を説明します。なおネットで見るとopensslコマンドで暗号文字列を生成という記事があるのですが、現在主流のSHA512には対応していないので、この方法は取れません。*3

(3)-(a)pythonで生成する

端的に例を説明すると、"SyokiPass@9999"というパスワードをSHA512形式で暗号化する場合は以下のコマンドになります。

# python -c 'import crypt; print(crypt.crypt("SyokiPass@9999", crypt.METHOD_SHA512))'

sha512は、暗号をより強固なものにするため「暗号したい文字列」と「salt(ソルト)」と呼ばれる文字列を組み合わせ暗号化します。上の例では、"crypt.METHOD_SHA512"の部分がSHA512形式のsalt文字列を生成&入力している部分になります。さらにこの例ではsalt文字列を乱数生成しています。*4

(3)-(b)"/etc/shadow"からコピーする

pythonから生成すればいいので、このやり方は実質不要ですが、一旦インストールした後または、適当なユーザを作成してパスワードを設定しshadowファイルから文字列を抜き出します。":"がフィールドの区切り文字になり、第2フィールドが暗号化された文字列のフィールドになるので、ここをコピーして利用します。

#grep '^root' /etc/shadow
root:$6$WYz7GsXMGCHrJnw.$BoSTW/Ac9vaVvjwB0NVg3.sccEh2g7eZhU7c7BRRx/d8Dxoo7UE70EYyhPEBiemPLxB.Pq0StVaoDIWTWLCFx/::0:99999:7:::

6.その他

(1)GUI/textモードの指定

KickStartファイルの動作確認をする場合はグラフィカルのほうが使いやすいかもしれないですが、最終的に何台ものマシンにセットアップする場合は、textモードが早くて良いと思います。

  • グラフィカル(GUI)モードにする場合
graphical
  • テキストモードにする場合
text

(2)selinux設定

selinuxの設定。無効化(--disabled)、有効化(--enforcing)、警告出力(--permissive)を選択します。

selinux [--disabled|--enforcing|--permissive]

(3)サービス設定

サービスの有効・無効設定を行います。カンマ区切りで複数サービスを指定する場合は、スペースを入れるとそれ以降は認識されません。

  • サービスの有効化
services --enabled=SERVICE1,SERVICE2,SERVICE3
  • サービスの無効化
services --disabled=SERVICE1,SERVICE2,SERVICE3

(4)KickStart完了後の挙動

  • リブートする場合:"reboot --eject" ※"-eject"はdvdを排出するオプション
  • 電源OFFする場合:"poweroff"
  • 一時停止する場合:"halt"

7.設定ファイル例

ks.cfgの設定例です。

#version=DEVEL
# System authorization information
auth --enableshadow --passalgo=sha512
repo --name="Server-HighAvailability" --baseurl=file:///run/install/repo/addons/HighAvailability
repo --name="Server-ResilientStorage" --baseurl=file:///run/install/repo/addons/ResilientStorage

# Use CDROM installation media
cdrom

# Select Install mode. graphical:Use graphical install, text:Use text install.
#graphical
text

# Run the Setup Agent on first boot
firstboot --enable
ignoredisk --only-use=sda
# Keyboard layouts
keyboard --vckeymap=jp --xlayouts='jp'
# System language
lang ja_JP.UTF-8

# Network information
network  --bootproto=dhcp --device=enp0s3 --noipv6 --activate
network  --hostname=testserver

# Root password
rootpw --iscrypted $6$WYz7GsXMGCHrJnw.$BoSTW/Ac9vaVvjwB0NVg3.sccEh2g7eZhU7c7BRRx/d8Dxoo7UE70EYyhPEBiemPLxB.Pq0StVaoDIWTWLCFx/
# System timezone
timezone Asia/Tokyo --isUtc
# System bootloader configuration
bootloader --append=" crashkernel=auto" --location=mbr --boot-drive=sda
# Partition clearing information
clearpart --all --initlabel --drives sda

# Disk partitioning information
part pv.295 --fstype="lvmpv" --ondisk=sda --size=1    --grow
part /boot  --fstype="xfs"   --ondisk=sda --size=500  --label=boot
volgroup rootvg --pesize=4096 pv.295
logvol swap  --fstype="swap" --size=256        --name=swaplv --vgname=rootvg
logvol /home --fstype="xfs"  --size=100        --name=homelv --vgname=rootvg --label="home" 
logvol /     --fstype="xfs"  --size=1   --grow --name=rootlv --vgname=rootvg --label="root" 

%packages
@^infrastructure-server-environment
@base
@compat-libraries
@core
@large-systems
@performance
@security-tools
kexec-tools
telnet
trace-cmd
vim
%end

�don com_redhat_kdump --enable --reserve-mb='auto'

%end

# Reboot after the installation is complete.(eject DVD media before rebooting)
reboot --eject

*1:このレイアウトはRHELの推奨構成とはことなります。例えばswapが小さかったりするので注意してください。

*2:"--initlabel"は廃止されたようですが、anacondaが自動生成したanaconda-ks.cfgではオプションが付いているので、そのままにしています。参考→32.4. キックスタートのオプション

*3:opensslコマンドがSHA512で使えない件の参考:sha512でハッシュされたsaltつきパスワードを生成するには – Nobwak's Lair

*4:rhelインストールガイドにpythonの例が改定あるのですが、saltの説明が雑なので、しょうがなくKickstartのコードを参考にしています。anaconda/users.py at master · rhinstaller/anaconda · GitHubの"def cryptPassword(password, algo=None):"を参考にしています。

Macbook Air(2010/A1370)にUbuntu16.04 LTS(Xenial Xerus)を入れてみた

1.はじめに

この記事は下記記事の焼き直しで、MacbooAir3.1(2010年:A1370)にUbuntu16.04をインストールした記録です。
nopipi.hatenablog.com

前提は以下の通りです。

  • 入れる箱(Mac)
    • Macbook Air A1370(2010年モデル)
      • 機種名/Model: MacBookAir3.1 / A1370
      • 液晶サイズ 11.6
      • CPU/Mem/HDD】Core2Duo 1.4GHz / 2GB / SSD
  • 入れるもの
    • Ubuntu16.04 LTS(Xenial Xerus) ※今回は日本語Remix版を利用
  • インストールメディア(USBブート)作成環境
    • Windows10
    • USBブートメディア作成ツール: "Universal-USB"

2.準備(インストールメディア)

ubuntuのインストール用メディアのisoをUSBメモリに突っ込んで、USBメモリブートでインストールします。

インストールメディアを用意

ubuntuからダウンロード

USBメモリブートメディア作成

今回は、"Universal-USB"というツールを利用しました。
Universal USB Installer - Easy as 1 2 3 | USB Pen Drive Linux
手順は、下記サイトを参考にしています。

3.インストール

  1. 作成したUSBメモリMacbookに差し、「オプションキー」を押しながら起動します。
  2. ブート可能なメディア一覧がでるので、USBメモリを選択(下記画像参照)

f:id:nopipi:20160604001041p:plain

  1. 後は普通にインストール
    1. キーボード設定は、「日本語」->「日本語(Macintosh)」を選択。
    2. それ以外は、Macbook固有で悩むところはないです。

4.MacBook用のubuntu設定

ファンクションキーの反転

初期状態では、ファンクションキーは音声や液晶の明るさ調整がメインで、F1やF2とかファンクションキーとして利用する場合は、fnキーと組み合わせる必要があります。ですが、日本語変換の時面倒なので機能を反転させます。
以下のページを参考にしました。

$ sudo vi /etc/rc.local 
下記の行を追加
echo 2 > /sys/module/hid_apple/parameters/fnmode

マウス変更

2本指で操作の設定。→デフォルトでONのため設定不要。
設定は、左バーの「システム設定」→「マウスとタッチパッド」を選択して設定。
f:id:nopipi:20151122165023p:plain

5.使いやすくするために

ランチャーへの登録

デフォルトではターミナルが、左メニューバー(Launcher)にないので追加します。

  1. ランチャーの一番上のボタンを押し検索画面を出す
  2. 検索ボックスから「Ter・・・」と入力すると、ターミナルが表示されるので実行する。
  3. 実行するとlauncherに実行アプリのボタンが追加されるので、右クリックして「Launcherに登録」を実行

アップデート

立ち上げて暫くするとアップデートを促するメニューが出てそれを実行すればよいですが、手動実行する場合は以下の通り実行します。

GUIから実行
  1. 検索から「update」と入力し、アプリを実行
CLIで実行

ターミナルから以下を実行します。

sudo apt-get upgrade

パッケージの追加インストール

sudo apt-get install vim
sudo apt-get install openssh-server
sudo apt-get install gimp 

ntpサーバ設定

ntpの接続先サーバを国内の"ntp.nict.jp"に変更する。

●/etc/systemd/timesyncd.conf

[Time]
NTP=ntp.nict.jp  <<="ntp.nict.jp"を追加する
#NTP=
#FallbackNTP=ntp.ubuntu.com
サービスの再起動と状態確認
$ sudo systemctl -l restart systemd-timesyncd
$ sudo systemctl -l status systemd-timesyncd
● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
  Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
           └─disable-with-time-daemon.conf
   Active: active (running) since 月 2016-06-06 17:01:54 JST; 2s ago
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 2948 (systemd-timesyn)
   Status: "Synchronized to time server 133.243.238.164:123 (ntp.nict.jp)."
   CGroup: /system.slice/systemd-timesyncd.service
           └─2948 /lib/systemd/systemd-timesyncd

 6月 06 17:01:54 xxx systemd[1]: Starting Network Time Synchronization...
 6月 06 17:01:54 xxx systemd[1]: Started Network Time Synchronization.
 6月 06 17:01:54 xxx systemd-timesyncd[2948]: Synchronized to time server 133.243.238.164:123 (ntp.nict.jp).

その他Tips

  • 日本語変換の切り替え
    • 「Control+Space」で切り替え。

gccのインラインアセンブラで使えるx86系の汎用レジスタの制御子(Constraints)

一覧

インラインアセンブラ
制御子
レジスタ名称
x86(32bit)x86_64(64bit)
aeaxrax
bebxrbx
cecxrcx
dedxrdx
Sesirsi
Dedirdi
r8-r8
r9-r9
r10-r10
r11-r11
r12-r12
r13-r13
r14-r14
r15-r15

32bitアプリの2038年問題に対してglibc介さずシステムコールを直接呼べば何とかなるかなという浅はかな考えがやっぱり浅はかだった件

はじめに

ラノベのようなタイトルの通り、
ですが。。。。

「そりゃそうだろ、うまく行ってしまったら32bitアプリとの互換性が維持できないだろうさ」という冷やかな視線を感じますが(><)、せっかく試したのでまとめます。

32bitアプリの2038年問題回避方法

2038年問題とは、32bitアプリケーションでは通常"符号ありlong int"で扱うため、2038年でオーバフローする問題です。
その回避策として一般的なのが、独自に"long long int"で64bitの変数を作るか、"符号なしlong int"で処理という方法らしいです。(wikipediaによると)

標準のCライブラリ(glibcとか)は当然"符号ありlong int"なので、この回避策をするためには、時刻処理を何らかの形で独自実装するしかありません。
例えば下記のような方法で、補正をかけるラップ関数を実装する方法などです。(結論から言うと下記リンク先の対応が現実解だったのですが・・・)

今回の実験の安直な発想

ところで、昨今のlinuxサーバ(RHEL)は64bitが普通になっており、その場合カーネル内部では時刻処理も64bitで処理されています。(long変数は、32bit環境の場合は32bit、64bit環境の場合は64bitのため)
そこでカーネルから時刻情報を取得する場合は、32bit環境で、直接カーネル内部の64bit時刻を取得することはできないかなぁ~と思い、安直にCライブラリを使わずアセンブラで直接呼びだしてみたら何かできないかなと思った次第です。

実験のコード

コードの説明

カーネルから時刻取得するためには、clock_gettimeのシステムコールを利用します。比較で普通にglibc関数を利用する方法と、アセンブラで呼びだす両方を実行してみます。
具体的には下記コードでは、32bit/64bit環境それぞれで、下記処理をしています。

  1. glibcのclock_gettime()関数を利用して時刻取得する(普通の方法)
  2. (実験メイン)アセンブラで直接clock_gettimeシステムコールを呼びだし時刻取得する
    1. 32bitの場合、(a)32bitのtimespec構造体、(b)64bitのtimespec構造体(long long int)それぞれで取得する
    2. 64bitの場合、(a)64bitのtimespec構造体で取得する。
    3. なおアセンブラで呼びだす場合のtimespec構造体は、32/64bit環境のbit長差異をないことを明確にするため、32bit長ではint型、64bitでは"long long int"で独自定義している

なお、いろいろぐちゃぐちゃやっていたので、余計なコードが入っていますが、ご容赦ください。

コード(time.c)

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#define _GNU_SOURCE
#include <unistd.h>
#include <sys/syscall.h>
#include <sys/types.h>

#define SYS_clock_gettime32 20
#define SYS_clock_gettime64 228


struct timespec32_test {
	int tv_sec;
	int tv_nsec;
};

struct timespec64_test {
	long long int tv_sec;
	long long int tv_nsec;
};


void printf_timespec(struct timespec *tp, int ret, char *mes)
{

	printf("%-40s " ,mes);
	printf("tv_sec=%-12ld ",tp->tv_sec);
	printf("tv_nsec=%-12ld ",tp->tv_nsec);
	printf("ret=%d\n",ret);

}

void printf_timespec32_test(struct timespec32_test *tp, int ret, char *mes)
{

	printf("%-40s ",mes);
	printf("tv_sec=%-12d ",tp->tv_sec);
	printf("tv_nsec=%-12d ",tp->tv_nsec);
	printf("ret=%d\n",ret);

}

void printf_timespec64_test(struct timespec64_test *tp, int ret, char *mes)
{
	printf("%-40s ",mes);
	printf("tv_sec=%-12lld ",tp->tv_sec);
	printf("tv_nsec=%-12lld ",tp->tv_nsec);
	printf("ret=%d\n",ret);
}

int main()
{
	struct timespec tp;
	struct timespec64_test tp64;
#if defined(__i386__) || defined(__ILP32__)
	struct timespec32_test tp32;
#endif
	pid_t  pid;
	int ret;
	char *mes;

	/* info */
	pid=getpid();
	printf("PID=%d\n",pid);

	mes = "glibc clock_gettime-long int";	
	tp.tv_sec=tp.tv_nsec=0;
	ret = clock_gettime(CLOCK_REALTIME,&tp);
	printf_timespec(&tp, ret, mes);

#if defined(__i386__) || defined(__ILP32__)
	/* 32bit application */
	mes = "Assemble=>i386 int 0x80-timespec-32bit";
	tp32.tv_sec=tp32.tv_nsec=0;
	__asm__ volatile(
	        "int $0x80;"
	        :"=a"(ret)
	        :"0"(SYS_clock_gettime),
	         "b"(CLOCK_REALTIME),
	         "c"(&tp32)
	);
	printf_timespec32_test(&tp32, ret, mes);

	mes = "Assemble=>i386 int 0x80-timespec-64bit";
	tp64.tv_sec=tp64.tv_nsec=0;
	__asm__ volatile(
	        "int $0x80;"
	        :"=a"(ret)
	        :"0"(SYS_clock_gettime),
	         "b"(CLOCK_REALTIME),
	         "c"(&tp64)
	);
	printf_timespec64_test(&tp64, ret, mes);

#else
	/* 64bit application */
	mes = "Assemble=>x86_64 syscall-timespec-64bit";
	tp64.tv_sec=tp64.tv_nsec=0;
	__asm__ volatile(
	        "syscall;"
	        :"=a"(ret)
	        :"0"(SYS_clock_gettime),
	         "D"(CLOCK_REALTIME),
	         "S"(&tp64)
	        :"memory"
	);
	printf_timespec64_test(&tp64, ret, mes);
#endif

	return(EXIT_SUCCESS);
}

実行結果

64bit環境

何も細工していないので、アセンブラで呼びだしても普通に応答が帰ってきます。

$ gcc -m64 -o time64 -g3 -Wall -O0  time.c
$ ./time64 
PID=5434
glibc clock_gettime-long int             tv_sec=1452509660   tv_nsec=790867319    ret=0
Assemble=>x86_64 syscall-timespec-64bit  tv_sec=1452509660   tv_nsec=790892879    ret=0

32bit環境

32bitの時刻構造体のポインタを渡したときは普通ですが、64bitの時刻構造体のポインタを無理やり渡しても、当然おかしな結果になっているのがよく分かります(^^;

$ gcc -m32 -o time32 -g3 -Wall -O0  time.c
$ ./time32
PID=5426
glibc clock_gettime-long int             tv_sec=1452509515   tv_nsec=540033119    ret=0
Assemble=>i386 int 0x80-timespec-32bit   tv_sec=1452509515   tv_nsec=540054759    ret=0
Assemble=>i386 int 0x80-timespec-64bit   tv_sec=2319584530896488779 tv_nsec=0            ret=0

カーネル挙動を確認する

当然といえば、当然の結果ですが。。。
念のための裏付けで、カーネル内部で32bitのシステムコールが呼ばれた場合どのような挙動をするのかを、ftraceでカーネル内部でどの様な関数が呼びだされているか確認してみました。

ftrace(trace-cmd)での確認方法

以下のコマンドでカーネルトレースを取得します。最後の実行コマンドをそれぞれ"./time64"、"./time32"とすることで32/64bit両環境のトレースを取得します。

$ sudo trace-cmd record -p function_graph -g SyS_clock_gettime -g compat_SyS_clock_gettime ./time64 
$ trace-cmd report

trace-cmdコマンドの詳細は(ftrace)trace-cmdでfunction_graphを使ってみる - のぴぴのメモを参照。

トレース結果

64bitと32bitを比較すると、32bitアプリから呼びだした場合は、cpmpat_sys_clock_gettime()なる関数でラップされているのが分かります。(blogの横幅の関係で、関数部分のみ記載しています)。なおカーネルは、ubuntu 14.04の"Linux version 3.19.0-43-generic (buildd@lgw01-16)"になります。

64bitアプリからのカーネルトレース(抜粋)
 |  sys_clock_gettime() {
 |    posix_clock_realtime_get() {
 |      getnstimeofday64() {
 |        __getnstimeofday64() {
 |          read_hpet();
 |        }
 |      }
 |    }
 |  }
32bitアプリからのカーネルトレース(抜粋)
 |  compat_sys_clock_gettime() {
 |    sys_clock_gettime() {
 |      posix_clock_realtime_get() {
 |        getnstimeofday64() {
 |          __getnstimeofday64() {
 |            read_hpet();
 |          }
 |        }
 |      }
 |    }
 |    compat_put_timespec() {
 |      __compat_put_timespec();
 |    }
 |  }

では、compat_sys_clock_gettime()ではどんな事をしているのでしょうか。

  • compat_sys_clock_gettime()は、/kernel/compat.cに実装
  • まず、sys_clock_gettime()を呼び出し(この時はtimespecは64bit。下記コードでts)
  • その後、copmpat_put_timespec()で、システムコールの引数に渡すデータを、カーネル空間からユーザ空間の所定位置にコピーする。(下記コードでtp)
  • で、そのcopmpat_put_timespec()内部で、64bitから32bitにデータを落としているらしい。
 740 long compat_sys_clock_gettime(clockid_t which_clock,
 741                 struct compat_timespec __user *tp)
 742 {
 743         long err;
 744         mm_segment_t oldfs;
 745         struct timespec ts;
 746 
 747         oldfs = get_fs();
 748         set_fs(KERNEL_DS);
 749         err = sys_clock_gettime(which_clock,
 750                                 (struct timespec __user *) &ts);
 751         set_fs(oldfs);
 752         if (!err && put_compat_timespec(&ts, tp))
 753                 return -EFAULT;
 754         return err;
 755 }

実際にデータ変換(64bit->32bit)をしているのはinlineアセンブラっぽい

  • arch/x86/include/asm/uaccess.h
 411 #define __put_user_asm(x, addr, err, itype, rtype, ltype, errret)       \
 412         asm volatile(ASM_STAC "\n"                                      \
 413                      "1:        mov"itype" %"rtype"1,%2\n"              \
 414                      "2: " ASM_CLAC "\n"                                \
 415                      ".section .fixup,\"ax\"\n"                         \
 416                      "3:        mov %3,%0\n"                            \
 417                      "  jmp 2b\n"                                       \
 418                      ".previous\n"                                      \
 419                      _ASM_EXTABLE(1b, 3b)                               \
 420                      : "=r"(err)                                        \
 421                      : ltype(x), "m" (__m(addr)), "i" (errret), "0" (err))

ということで、カーネル内部のcpmpat_XXXXXXX関数で、32bitアプリ向けに64bit→32bitのデータ変換が行われているため、どうやっても32bitアプリでカーネルから64bitの時刻データを取得するのは難しそうです。

(linux)x86(32bit)でアセンブラでシステムコールを呼び出す方法。

はじめに

標準Cライブラリ(Linuxではglibc)に頼らず、システムコールを呼びして見たいなとの思いから、勉強がてらアセンブラシステムコールを呼びだす方法をまとめてみました。

2015.12.28追記

x86(32bit)とx86_64(64bit)はシステムコールの呼び方が全然違いますし、レジスタx86の32bit長のものでした。

詳細はこちら→--Syscall Number for x86-64 linux (A)
そのようなわけで、この記事は32bitアプリ前提で書き直しました。

アセンブラシステムコールを呼びだす方法

まとめると、以下の通りです。

  1. eaxレジスタに呼び出したいシステムコールの番号を登録する。
  2. システムコールに指定する番号は、"/usr/include/asm/unistd.hを参照。
    • asm/unistd.hから、
      • 32bitコンパイル時はasm/unistd_32.hが取り込まれる。(今回はこちら)
      • (参考までに)、64bit時は、asm/unistd_64.hが取り込まれる。
  3. システムコールに渡す引数は順番に、ebx, ecx, edxレジスタにコピーする。
  4. "int 0x80"で0x80割り込みを発生させることで、システムコールを発行する。
  5. リターンコードは、exaに格納されるので、そのレジスターをmovでコピーする。

サンプルコードです。

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>

int main()
{
	pid_t pid;

	/* call by assembly language */
	pid=0;
	__asm__("mov $20,  %%eax;"  //"$20"がgetpidのシステムコール番号
		"int $0x80;"        //80番で割り込みを発生させる
                "mov %%eax, %0;"    //返り値をpid変数にコピー
		:"=r"(pid)
	);
	printf("assembly: pid=%d\n",pid);

	/* call by glibc getpid function */
	pid=0;
	pid=getpid();
	printf("glibc   : pid=%d\n",pid);

	return(EXIT_SUCCESS);
}

実行結果です。

$ gcc -m32 -o test syscall_test.c 
$ ./test 
assembly: pid=3970
glibc   : pid=3970

32bitと64bitプロセスのtime_tのbitsを実機確認してみる

32bitプロセスと64bitプロセスで、glibcのtime_t変数のビット数がどう違うのか確認してみました。

サンプルプログラム

#include <stdio.h>
#include <stdlib.h>
#include <sys/time.h>

#define sizeof_bits(x) (int)sizeof(x)*8

int main()
{

      printf("char      size:= bits\n",sizeof_bits(char));
      printf("int       size:= bits\n",sizeof_bits(int));
      printf("long      size:= bits\n",sizeof_bits(long));
      printf("long long size:= bits\n",sizeof_bits(long long));

      printf("struct timeval {        ->size:= bits\n",sizeof_bits(struct timeval));
      printf("   time_t      tv_sec;  ->size:= bits\n",sizeof_bits(time_t));
      printf("   suseconds_t tv_usec; ->size:= bits\n",sizeof_bits(suseconds_t));
      printf("}\n");

      return(EXIT_SUCCESS);
}

実機確認

(1)コンパイル、(2)fileコマンドで32bitのバイナリ形式であることを確認、(3)実行してビット数を確認の流れです。
time_tが32bitプロセスの場合は32bit、64bitプロセスの場合は64bitであることが解ります。
ちなみに、32/64bitプロセスで、char、int、long long型は差異が無く、long型が32/64bitでそれぞれ差異がある事も確認できます。

32bitプロセスの場合

  1. long変数が、32bitである。
  2. time_tも、32bitである。
$ gcc -m32 -o time-32 time.c
$ 
$ file time-32
time-32: ELF 32-bit LSB  executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=e4d3d5ef99b4f5178372ff254729b284fc429946, not stripped

$ ./time-32 
char      size:  8 bits
int       size: 32 bits
long      size: 32 bits
long long size: 64 bits
struct timeval {        ->size: 64 bits
   time_t      tv_sec;  ->size: 32 bits
   suseconds_t tv_usec; ->size: 32 bits
}

64bitプロセスの場合

  1. long変数が、64bitである。
  2. time_tも、64bitである。
$ gcc -m64 -o time-64 time.c
$
$ file time-64
time-64: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=dc935a4fb6c31c98544e90fc740d59cd4b9db081, not stripped

$ ./time-64
char      size:  8 bits
int       size: 32 bits
long      size: 64 bits
long long size: 64 bits
struct timeval {        ->size:128 bits
   time_t      tv_sec;  ->size: 64 bits
   suseconds_t tv_usec; ->size: 64 bits
}

蛇足

glibcのコード上からも裏付けとろうと思ったのですが、時間がないのでやめました。