nkjmkzk.net

powered by Kazuki Nakajima

Archive for the ‘linux’ tag

lsコマンドのあまり使わないオプション

多くの人はlsを叩くときに定説となっているオプションがあると思います。

ls -lとか、

ls -aとか、

ls -laとか、はたまたそもそも、

llとか。僕は大抵このあたりで収まっている小市民です。

惰性で生きているとあまりman lsとかする機会がないのですが、今日たまたま必要に迫られてman lsしました。

やりたかったのは、シンボリックリンクから何らかオリジナルファイルの情報を得る、というものです。単純に考えるとls -lして一番右のカラム(オリジナルファイルへのパス)をcutとかawkとかで引っこ抜けばいいのですが、なんとなく納得いかなかったので少し調べました。すると、シンボリックリンクをlsしたときにオリジナルファイルの情報を返す-Lオプションを発見。例えば、通常-iオプションはinodeを表示します。シンボリックリンクのinodeはオリジナルのファイルのinodeを共有しているわけではなく、それぞれがユニークなinodeを持っています。なので通常、

ls -i [シンボリックリンク]

するとそのシンボリックリンクのinodeが表示されますが、

ls -iL [シンボリックリンク]

すると、そのシンボリックリンクが指し示すファイルのinodeを表示してくれます。

用例がないと何に使えるのかサッパリですが、とりあえず今書いているツールには使えそうなオプションなので自己満足的に紹介してみました。

without comments

Written by 中嶋 一樹

11月 12th, 2009 at 10:20 pm

Posted in Uncategorized

Tagged with

ZFSのiSCSI TargetをLinuxから利用するときのアクセス制御設定

仮想化環境でゲストOSにネットワーク経由(iSCSI)で直接ストレージを認識させる場合、ストレージ側で何らかの接続制御を行う必要に迫られます。何も制御してないと、ゲストOS: NKJMからゲストOS:SUZUKI用のボリュームに接続できてしまったりと、意図的であろうとなかろうと本来接続するボリュームとは違うボリュームに接続してしまう可能性があるからです。

ちなみにゲストOSから直接ストレージを認識させる形式ではなく、一旦ホストOS(dom0)に認識させてからゲストOSに貸し出すような形であればホストOS側で制御できるのでそこまでデリケートになる必要はないでしょう。

今回はiSCSIストレージにZFS、ゲストOSにLinux(Oracle Enterprise Linux 5.x, Redhat Enterprise Linux 5.x, CentOS 5.x)を使用しているときのアクセス制御についてまとめておきます。

「オペレーションミスを予防する」という目的であればInitiator IQNでアクセス制御する程度がシンプルでいいでしょう。しかしInitiator IQNは簡単に詐称できるので、セキュリティを真に確保しなければいけないPublicな環境であればより強固な認証を実施することが求められるでしょう。

それぞれの制御方法について順に紹介していきます。

Initiator IQNで認証

特定のTargetにアクセスできるInitiator IQNをあらかじめ定義しておき、アクセス時のInitiator IQNをベースに制御を行うものです。

Initiator側(Linux)

特に設定は必要ありませんが、Initiator IQNの情報だけ取得しておく必要があります。

[root@initiator1]# cat /etc/iscsi/initiatorname.iscsi
InitiatorName=iqn.1994-05.com.redhat:123456

Target側(OpenSolaris)

まず接続を許可するInitiator IQNのオブジェクトを作成します。オブジェクト名は何でも構いませんが今回はinitiator1としています。

[root@target]# iscsitadm create initiator -n iqn.1994-05.com.redhat:123456 initiator1

次にそのInitiatorオブジェクトと、アクセスを許可したいTargetを紐づけます。

[root@target]# iscsitadm modify target -l initiator1 [TARGET_NAME]

これでTARGET_NAMEはinitiator1,つまりiqn.1994-05.com.redhat:123456からのアクセスのみを許可するようになります。

CHAP認証

CHAP認証ではInitiator IQNの検査に加えusername/passwordによる認証を行います。

Initiator側(Linux)

CHAPのusername/passwordを設定します。これには設定ファイルを編集する方法と、TargetをDiscoveryして登録し、登録されたTargetのプロファイルを設定する方法があります。前者はグローバルなデフォルト設定になるので、新しく登録されたTargetにはすべてこの設定ファイルに記載されているusername/passwordでログインしにいくようになります。Target個別に認証方法やusername/passwordを設定する場合は後者の方法で設定する必要があります。以下では前者の設定ファイルの編集を解説します。

[root@initiator1]# vi /etc/iscsi/iscsid.conf
node.session.auth.authmethod = CHAP
node.session.auth.username = user1
node.session.auth.password = zfszfszfszfs (12文字以上16文字以内)

編集が完了したら設定を反映させるためにiscsidをリスタートします。

[root@initiator1]# service iscsi restart

以上でInitiator側の設定は完了です。

Target側(OpenSolaris)

まず接続を許可するInitiator IQNのオブジェクトを作成します。オブジェクト名は何でも構いませんが今回はinitiator1としています。

[root@target]# iscsitadm create initiator -n iqn.1994-05.com.redhat:123456 initiator1

次にそのInitiatorにusername/passwordを設定します。これはInitiator側で設定したusername/passwordと一致しなければなりません。

まずはusernameです。

[root@target]# iscsitadm modify initiator -H initiator1 user1

次にpasswordです。

[root@target]# iscsitadm modify initiator -C initiator1
*プロンプトが表示され、パスワード(今回はzfszfszfszfs)を2度入力します。

次にそのInitiatorオブジェクトと、アクセスを許可したいTargetを紐づけます。

[root@target]# iscsitadm modify target -l initiator1 [TARGET_NAME]

これでTARGET_NAMEはinitiator1,つまりiqn.1994-05.com.redhat:123456からのアクセスのみを許可し、さらにCHAPの認証が通った場合だけアクセスできるようになります。以下のようにInitiator側から登録とログインを行ってみてください。

[root@initiator1]# iscsiadm -m discovery -t st -p [TARGET_IP]
[root@initiator1]# iscsiadm -m node --login

なお、すでにInitiator側でTargetを登録した状態でiscsid.confを編集してservice iscsi restartしてもログインは成功しません。すでにそのTargetのプロファイルはCHAP認証なしということで作成されているからです。この場合は一度プロファイルをiscsiadm -m node -o deleteとして削除してdiscoverからやり直すか、Targetのプロファイルを個別に設定してやる必要があります。その方法を以下に記載しておきます。

[root@initiator1]# iscsiadm -m node -T [TARGET_IQN] -o update -n node.session.auth.authmethod -v CHAP
[root@initiator1]# iscsiadm -m node -T [TARGET_IQN] -o update -n node.session.auth.username -n user1
[root@initiator1]# iscsiadm -m node -T [TARGET_IQN] -o update -n node.session.auth.password -n zfszfszfszfs

という感じです。

without comments

Written by 中嶋 一樹

9月 19th, 2009 at 6:12 pm

Posted in Uncategorized

Tagged with , , ,

OpenSolaris vs Linuxの超約

最近TuxRadarのOpenSolaris vs Linuxという記事が話題です。

内容はもちろんOpenSolarisとLinuxを比較する記事ですが、細かくスペックを比較するようなコンテンツではなくOpenSolarisの特徴的な機能/制約に言及することで客観的に両者を理解できる簡潔で読みやすいコンテンツになっています。その内容を以下に大雑把にまとめておきます。

広範囲なハードウェアサポートはLinuxに一日の長がある

今日のLinuxカーネルはデバイスドライバがその大部分を占めると言われるだけあって広範囲に及ぶデバイスのカバレージはLinuxに一日の長がある。ただしLinuxは「とにかくサポートするデバイスを増やす」ことに注力しており、そのためにはデバイスドライバ用のカーネルインターフェース仕様を変えることもいとわないというスタンス。それに対してOpenSolarisは互換性重視。今開発したドライバは10年後にも使えるというスタンス。

ZFS

名実ともに今のSolarisの人気を引っ張っているのはこのZFSといっても過言ではない。Linuxの事実上標準ファイルシステムであるext3はext2との互換性を重視したもので、ZFSはそれに比べてかなり先進的な機能が搭載されいている。

プールという概念

ZFSは今までのようにファイルシステム毎にディスクを区切って容量を分配するのではなく、容量はみんなで共有、ファイルシステムは管理上の独立性のために作成という仕様になっている。

注釈> Linuxでは100Gのディスクがひとつ在って、その上に4つのファイルシステムを作成するということはディスクを1/4づつに区切ることを意味する(均等分割すれば)。一方SolarisのZFSでは4つのファイルシステムすべてが100Gを共有するという仕様。より効率的なディスクリソースの使用が可能になる。ディスクはプールに追加され、そのプールをファイルシステムみんなで共有する。そのプールにはオンラインでディスクを抜き差し可能というのも大きなポイント。

スナップショット/リストア

ZFSではスナップショットとそれをリストアするという操作が可能。これらはコマンドラインでも可能だが、OpenSolaris 2009.06では洗練されたGUIが利用可能。中でも「タイムスライダー」は必見。つまみを左右することでタイムマシーンのようにファイルを過去の任意の時点に戻すことができる。

*詳しくは別サイトのこの動画でみてほしい。

TIme Slider Screencast

仮想化テクノロジー

OpenSolarisではxVMというXenベースの仮想化機構に加え、Zoneという仮想化も使用することができる。

注釈> 最近ZoneについてXenやVMwareにくらべて未熟な仮想化技術と思っている人をしばしば見かけますがそうではありません。Zoneは同じOSを高密度に動かすという要件であればXenやVMwareよりも優れた仮想化技術です。なので集約密度が命のVPSホスティングサービス業者はXenやVMwareよりもVirtuozzoというZoneに似た方式の仮想化ソフトを採用していることが多い。

コマンドの違いまとめ

これは優劣の問題ではないが、LinuxユーザがSolarisをつかったときに、「あれ、/var/log/にあんまりログないな」みたいなことがよくありますがそういうときに役に立つTipsです。

e38394e382afe38381e383a3-1

これも詳しくはオリジナルページでみてみてください。

あとはインストール時の注意事項についてもまとめられていますが、あんまり面白い話でもないので割愛。

特徴と言えばあとDTraceがありますが、これには触れられてないですね。

without comments

Written by 中嶋 一樹

9月 17th, 2009 at 11:11 pm

Posted in Uncategorized

Tagged with , ,

dhcpクライアントのタイムアウトを短くする

Oracle VMの仮想マシンテンプレートは基本的に初期状態ではネットワーク設定はDHCP参照となっています。しかしながらDHCPを使用していない環境では当然リクエストしてもタイムアウトになります。そんなとき、このタイムアウトがちょっとばかし長いのが気になります。特に害はないのですが何回もやっているとストレスが溜まりますし、デモをしているときにここでひっかかると冷や汗モンです。ということでdhclientの設定ファイルを編集してタイムアウト時間を短くしておきます。

# vi /etc/dhclient.conf
timeout 3

これだけです。お粗末様でした。

*ちなみにこの設定ファイルはデフォルトでは存在しないかもしれません。なかった場合はそのまま作成してしまいましょう。

without comments

Written by 中嶋 一樹

3月 23rd, 2009 at 1:12 pm

Posted in Uncategorized

Tagged with ,

OSが認識するメモリ容量を制限したいとき

特にパフォーマンステストをやってるといろいろとOSの環境を変えて結果を見比べたくなるときがあります。その中で「メモリ容量を変えたらどうなるか?」というときがしばしばあります。パワープレイでこれを実現するには、よっこらしょ、とラックからサーバを引き出し、ケースをパカッと開けてメモリを引っこ抜くという技が最初に思いつきます。しかしデュアルチャネル構成の場合短絡的にそんなことをしちゃうとサーバが起動しなくなってしまう可能性がありますし、そもそも現場まで言って作業するというのが原始的です。

簡単な方法は、カーネルの起動パラメータ「mem」でOS(カーネル)が認識するメモリ容量を指定してあげるやり方です。これは/boot/grub/grub.confを直接編集して静的に設定してもいいですし、起動時にgrubメニューで都度設定してもOKです。

例えばgrub.confを編集する場合はこんな感じです。

title Fedora (2.6.27.5-117.fc10.x86_64)
    root (hd0,0)
    kernel /vmlinuz-2.6.27.5-117.fc10.x86_64 ro root=UUID=5352e3d6-e0d6-4e6e-9e9f-f3e7e054bfdd rhgb quiet mem=389M
    initrd /initrd-2.6.27.5-117.fc10.x86_64.img

起動時に設定する場合はコンソールにgrubメニューが表示されたときに「e」を入力して編集モードに入ることで設定できます。

*余談ですがOracle VM Serverではdom0_memというオプションでdom0に割り当てるメモリ容量を制限しています。

しかし、grub.confっていつから/etc/grub.confからリンクが張られてたんだろう。

without comments

Written by 中嶋 一樹

2月 1st, 2009 at 8:41 pm

Posted in Uncategorized

Tagged with

LinuxでiSCSIを利用する

LinuxでiSCSIのストレージを利用するにはカーネルでiSCSIのドライバが有効になっていて、iSCSIイニシエータのソフトウェアがインストールされている必要があります。ドライバはディストリビューション付属のカーネルであれば大抵有効になっていると思いますので、iSCSIイニシエータのセットアップから開始します。Redhatであればiscsi-initiator-utilsとしてRPMが用意されていますのでこれをインストールします。

# yum install iscsi-initiator-utils

次にiscsiデーモンを起動します。

# service iscsi start

ここからイニシエータの設定を行っていきます。イニシエータの情報はデータベース管理されており、iscsiadmコマンドを用いてこのデータベースを参照、更新できます。
最初にターゲットの情報を取得してデータベースに登録します。

# iscsiadm -m discovery -t sendtargets -p 192.168.12.146
192.168.12.146:3260,1 iqn.1994-04.jp.co.hitachi:rsd.d7h.t.11799.1a000
192.168.12.143:3260,1 iqn.1994-04.jp.co.hitachi:rsd.d7h.t.11799.0a000

-pオプションで指定したストレージのコントローラで接続可能なターゲットの情報一覧が表示されます。同時にデータベースへの登録も行われています。

次に接続したいターゲットを指定してログインします。

# iscsiadm -m node -T iqn.1994-04.jp.co.hitachi:rsd.d7h.t.11799.1a000 -p 192.168.12.146 --login

dmesgをみるとストレージが/dev/sdaとして認識されたことが確認できます。

# dmesg
scsi0 : iSCSI Initiator over TCP/IP
Vendor: HITACHI Model: DF600F Rev: 0000
Type: Direct-Access ANSI SCSI revision: 04
SCSI device sda: 503316480 512-byte hdwr sectors (257698 MB)
sda: Write Protect is off
sda: Mode Sense: 77 00 00 08
SCSI device sda: drive cache: write through
SCSI device sda: 503316480 512-byte hdwr sectors (257698 MB)
sda: Write Protect is off
sda: Mode Sense: 77 00 00 08
SCSI device sda: drive cache: write through
sda: unknown partition table
sd 0:0:0:0: Attached scsi disk sda

この後は通常どおりのブロックデバイスの操作です。
普通にパーティションを作成するにはfdisk等を用います。

# fdisk /dev/sda

あるいはLVMを使用しているのであればpvcreateで物理ボリュームとして登録します。

# pvcreate /dev/sda

基本的なセットアップは完了です。
ターゲットについての設定情報を参照するには以下のようにします。

# iscsiadm -m node -T iqn.1994-04.jp.co.hitachi:rsd.d7h.t.11799.1a000 -p 192.168.12.146
node.name = iqn.1994-04.jp.co.hitachi:rsd.d7h.t.11799.1a000
node.transport_name = tcp
node.tpgt = 1
node.active_conn = 1
node.startup = automatic
node.session.initial_cmdsn = 0
node.session.auth.authmethod = None
node.session.auth.username = 
node.session.auth.password = 
node.session.auth.username_in = 
node.session.auth.password_in = 
node.session.timeo.replacement_timeout = 120
node.session.err_timeo.abort_timeout = 10
node.session.err_timeo.reset_timeout = 30
node.session.iscsi.InitialR2T = No
node.session.iscsi.ImmediateData = Yes
node.session.iscsi.FirstBurstLength = 262144
node.session.iscsi.MaxBurstLength = 16776192
node.session.iscsi.DefaultTime2Retain = 0
node.session.iscsi.DefaultTime2Wait = 0
node.session.iscsi.MaxConnections = 1
node.session.iscsi.MaxOutstandingR2T = 1
node.session.iscsi.ERL = 0
node.conn[0].address = 192.168.12.146
node.conn[0].port = 3260
node.conn[0].startup = manual
node.conn[0].tcp.window_size = 524288
node.conn[0].tcp.type_of_service = 0
node.conn[0].timeo.logout_timeout = 15
node.conn[0].timeo.login_timeout = 15
node.conn[0].timeo.auth_timeout = 45
node.conn[0].timeo.active_timeout = 5
node.conn[0].timeo.idle_timeout = 60
node.conn[0].timeo.ping_timeout = 5
node.conn[0].timeo.noop_out_interval = 10
node.conn[0].timeo.noop_out_timeout = 15
node.conn[0].iscsi.MaxRecvDataSegmentLength = 65536
node.conn[0].iscsi.HeaderDigest = None,CRC32C
node.conn[0].iscsi.DataDigest = None
node.conn[0].iscsi.IFMarker = No
node.conn[0].iscsi.OFMarker = No

これらの設定情報を編集するには同じくiscsiadmコマンドをアップデートモード実行します。

# iscsiadm -m node -T iqn.1994-04.jp.co.hitachi:rsd.d7h.t.11799.1a000 -p 192.168.12.146 -o update -n node.startup -v manual

* -o update : 操作モードをアップデートモードに指定
* -n : 設定項目を指定
* -v : 設定項目の値を指定

with one comment

Written by 中嶋 一樹

12月 6th, 2008 at 7:07 pm

Posted in Uncategorized

Tagged with ,

マルチプロセッサー環境でKernelをビルドする

最近Linuxカーネルに傾倒しています。
いろいろ調べているうちにカーネルを何通りかでビルドしてテストすることになりました。カーネルのビルドは一度やってしまえばなんてことはない作業なのですが、調べていると何かと知らなかったことがわんさか出てきます。今回は手短に最近のマルチプロセッサ環境でのカーネルビルドHow Toをまとめてみます。

・カーネルソースをダウンロードする。
当然kernel.orgにあるわけですが、我々日本人は国際回線の帯域幅節約に貢献すべく日本国内のミラーサイトから手に入れるのがよいでしょう。僕はいつも理研さんに御世話になっています。
理研のミラーサイト

・展開

# tar xvfj linux-2.6.22.tar.bz2
# cd linux-2.6.22

・設定
ここはカーネルのバイナリを自分の環境に最適化させる上でもっとも重要な手順です。とはいえここに懲りだすと日が暮れるので今回はデフォルト設定を適用します。
カーネルビルドの設定は展開したトップディレクトリに.configとして用意します。当然自分でガリガリ書くのではなく、用意されている便利なツールを利用します。デフォルト設定の設定ファイル(.config)は以下のようにして作成します。

# make defconfig

ちなみにこの設定はLinusのメイン開発マシンとほぼ同じ設定だそうです。ほんまかな。

・ビルド
さて、カーネルをコンパイルしていきます。通常は以下のようにmakeを実行するだけでOKです。

# make

ここで実はなかなかに便利、というかマルチプロセッサー・オーナーにはもはや必須なオプションがあります。

# make -j2

この-jオプションはコンパイルのスレッド数を指定できるもので、例えばCore 2 Quadが搭載されているマシンであれば、-j4と指定するとマッハでコンパイルできるのではないかと思います。

実際にCore 2 Duoのプロセッサーが搭載されているThinkpad T60でビルド時間を計測してみました。

[-jオプションなし]

real 5m22.791s
user 4m56.123s
sys 0m23.153s

[-j2]

real 3m24.712s
user 5m0.723s
sys 0m24.834s

[-j4]

real 3m20.628s
user 5m3.811s
sys 0m25.606s

-jオプション有と無しでは1.7倍程度の差が出ました。もう-jオプション無しではビルドできません。ちなみにとある書物には「プロセッサ数 x 2」の値を-jオプションに与えるのがよいとされていましたが今回は-j2と-j4ではそれほど差異はありませんでした。

・インストール
あとは以下のようにすれば新しいカーネルのインストールは完了です。

# make modules_install
# make install

上記手順でインストールを行うにはmkinitrdが必要です。最近のディストリビューションにはほぼインストールされていると思います。上記コマンドを実行するとビルドしたカーネルを/bootにコピーし、grubのmenu.lstの追記やinitrdの作成も同時に行ってくれます。何て便利な世の中なのでしょうか。ただ、menu.lstの設定でデフォルトのカーネルにはなっていないと思いますので、menu.lstの「default」の値を編集するか、起動時にメニュー画面で今作成したカーネルを指定して下さい。

without comments

Written by 中嶋 一樹

12月 6th, 2008 at 7:04 pm

Posted in Uncategorized

Tagged with ,

最近のRedhat系OSのrc.dをみておく

Linuxは起動時にinittabで指定されたランレベルnに応じて/etc/rc.d/rc[n].dの中のスクリプトを順次実行してサービスを開始していきます。

しなしながらこの中には各ユーザ環境によっては不要なものも含まれており、このようなサービスを全て起動させておくのはシステム資源の無駄であると同時に意図しないネットワークポートが開くこととなり、セキュリティ上も潜在的な穴が増えます。

さらに不要なサービスをそのままにしておくと起動にえらく時間がかかります。
Linuxの起動は以下の3つのステップで行われます。

1.Biosブート
2.カーネルブート
3.システムinit

このなかで「3.システムinit」は相当な時間を占めており、つまりはここを圧縮すればシステムの起動時間全体の圧縮に大きく寄与します。 あとは「1.Biosブート」でのメモリ検査等のシステム診断プロセスも相当な時間を要します。なのでH/W不良がこわくないヤンキーな人はこのあたりもオフってしまうのも手です。

というわけで前置きが長いわけですが、自分が基本的にRedhat系Linuxを使用するときにいるもの、いらないものを整理しておこうと思います。 僕は大体いつもサーバOSをインストールするとデフォルトのランレベルを4に切替えて、rc4.dのみをいじるようにしています。
rc.d内のスクリプトは全て/etc/rc.d/init.dへのシンボリックリンクになています。
直接このリンクを消したりしても目的は達成できますが、あとでまたサービスを復活させたいときに面倒なのでchkconfigコマンドを使って以下のようにするのが本道でしょう。

chkconfig --level [ランレベル] [サービス名] off

さて、本題のいらないサービスを網羅していきます。
いるいらいないの基準は僕の勝手によりXen環境を運用する上で最小限のもの、ということにします。

ーー仕事中なので続きはまた今度ーー

without comments

Written by 中嶋 一樹

12月 6th, 2008 at 7:00 pm

Posted in Uncategorized

Tagged with

タイムゾーンの直し方

タイムゾーンがうっかりアメリカ時間になってました。

% mv /etc/localtime /etc/localtime.org
% ln -s /usr/share/zoneinfo/Japan /etc/localtime

としておきました。

without comments

Written by 中嶋 一樹

12月 6th, 2008 at 6:59 pm

Posted in Uncategorized

Tagged with

昔やったことがあるシリーズ 先頭に「-」(ハイフォン)のついたファイルを作ってしまった。

うっかり先頭に「-」(ハイフォン)のついたファイルを作ってしまうと厄介です。 かなりがんばっても消せません。 

# rm "-miss"
rm: invalid option -- m
詳しくは `rm --help' を実行して下さい.
# rm '-miss'
rm: invalid option -- m
詳しくは `rm --help' を実行して下さい.
# rm -miss
rm: invalid option -- m
詳しくは `rm --help' を実行して下さい.

そんなときはこのように。

# rm -- -miss

またはこのように。

# rm ./-miss

without comments

Written by 中嶋 一樹

12月 6th, 2008 at 6:51 pm

Posted in Uncategorized

Tagged with