よろず環境設定  
  HOME  

よろず環境設定

Linux を出来る限り健康な状態で、快適に使うための小技を取り扱う。かなり RedHat 系に偏った内容になっているきらいはあるが、他のディストリビューションでも何かの手掛かりになるかも知れない。

Table of Contents

RedHat 系 多言語インストール時のコツ

情報古い。今ではあまり有効な手立てではない。

いきなり「環境設定」とは言い難い項目になってしまうが、WEB サーバに使うにしろ何にしろ、やはり日本語環境は必要だ。しかし、インストーラの手順の中で、プライマリランゲージをいきなり日本語にしてしまうと、コンソールは変なフォントになるわ、X のデスクトップには日本語のアイコンはできるわで、非常に扱いづらいOSになってしまう。いざという時には X を経ない通常の仮想コンソールが頼みの綱だが、様々なエラーメッセージまで日本語になるので、文字化けして内容が読み取れない。

そこで、インストール途中の言語選択の部分では、English (US) と日本環境にチェックを入れて、プライマリには US のほうを選択しておく。こうすれば、パッケージを少々乱暴に選択しても、日本語に必要なパッケージはあらかたインストールされる。インストールが終わり、一度英語環境のまま起動してから、言語選択ツールで日本語に移行すれば、日本語名の付いた事物は最低限で済む。そもそも、自分の場合は、日本語環境関係のインストールはするが、デスクトップも英語のまま使う。日本語ファイルを読む必要に迫られたら、そのままの環境で kon や kterm を使えば済むことだ。日本語を入力する気はないので、canna や wnn も止めてしまう。

なお、 Fedora Core 4 のインストーラでは、明白な言語の選択ステップがなくなってしまった。 Fedora Core 4 の場合には、主言語を English (US) にした上で、インストールジャンルで「カスタム」を選び、パッケージの選択で Language Support グループの中の Japanese-support にチェックを付ける。しかしそれだけではまだダメで、インストール完了後に、 /etc/sysconfig/i18n ファイルの編集も必要だ。

SUPPORTED="en_US.UTF-8:en_US:en"

となっている行を、

SUPPORTED="en_US.UTF-8:en_US:en:ja_JP.UTF-8:ja_JP:ja"

と日本語関係を付け加える。こうしてやっと、グラフィカルログイン画面の Language 選択画面と X 上での Select Language ユーティリティに Japanese が表示されるようになり、切り替えが可能になる。

X でのグラフィカルログインをやめる

今時は、インストールしたままの状態では、どうしても直接 X-Window へログオンさせたがるOSが多い。通常のテキストコンソールで間に合うのであれば、非グラフィカルログインをデフォルトにするといい。メモリの節約にもなる。

グラフィカルログインをやめたい場合は、INIT プロセスへの指示書である /etc/inittab ファイルを編集する。冒頭附近にある：

id:5:initdefault:

を

id:3:initdefault:

に変える。デフォルト run レベルを、 X ログインである 5 から、通常のマルチユーザレベルである 3 に変更するわけだ。

Runレベルを 3 にすると X-Window 環境が英語になる

Fedora Core 7, 8 では、GDM (グラフィカルスタートアップ) を標準に考えているようだ。これらのディストリビューションリリースでは、X-Window がスタートする時に環境変数 LANG の値を読み取って言語環境を決定するようになった。元来、OS の LANG が日本語になっていると、日本語を表示する能力のないノーマルのテキストコンソールではメッセージが文字化けしていた。その方策として、Fedora Core 7, 8 では、テキストコンソール環境ではわざわざ LANG=C が設定されるようになっている。テキストコンソールからそのまま startx すれば、このふたつのことが作用して、X-Window 環境は当然英語になる。

筆者としてはこれは歓迎すべき変化なのだが、X を日本語環境にしたい人は、したい時だけ、 X 起動の際に環境変数を与えてやる；

user$ env LANG=ja_JP.UTF-8 startx

こうしたことをいちいちやりたくない御仁は、当該の UNIX ユーザのホームディレクトリにある .bashrc に下記の定義を加えておけばいい；

alias startx='env LANG=ja_JP.UTF-8 startx'

編集後、一旦 X-Window からもテキストコンソールからもログアウトすれば、.bashrc が再読込されて、以後 X が日本語環境で立ち上がるようになる。

コンソールフォントが大きすぎる！

前項に関連するが、デフォルトの仮想コンソールフォント (X-Window 上のではない) はでかすぎる。もう少したくさんの文字を一度に表示させたいものだ。コンソールフォントの変更には、 /etc/sysconfig/i18n ファイルを少しいじる (かつて Slackware では、/etc/rc.d/rc.font だった)。

SYSFONT="xxx-xx"

が仮想コンソールフォントの指定なので、好みのフォントを指定する。フォント自体は /lib/kbd/consolefonts/ (あるいは /usr/lib/kbd/consolefonts/ など) に、gzip された状態で置かれている。いろいろ試して無難だったのは lat0-10 と default8x9 だ。筆者はほとんど lat0-10 を使っている。ちなみに i18n とは、多国語化パッケージ。ブラウザにしろOSにしろ、多国語化することを i18n と総称するようだ。"internationalization" という語は長すぎるので "i + 18文字 + n" と変形したのが名前の由来だという。

なお、RedHat 系では、言語切替ツールで言語を切り替えると、せっかく設定しなおしたフォントもデフォルトのものに戻ってしまう。

キーボードマップの変更

通常はこんなことをする必要はないが、(X-Window でなく) テキストコンソールで使用するキーマップは、/etc/sysconfig/keyboard で：

KEYTABLE="jp106"

といった具合に定義されている。キーテーブル自体は /lib/kbd/keymaps/i386/ (あるいは頭に /usr/ が必要かも知れない) ディレクトリの下に gzip 形式で格納されている。

一時的にマップを変更するには loadkeys というコマンドがあり、CD や フロッピーから直接ブートして使うディストリビューションで、ラテンキーボードになってしまっていた時などに便利だ。マップファイルが収録されていればだが。

RHEL6にVNC接続するとキーマップがめちゃくちゃになる

RedHat Enterprise Linux Server 6 及び CentOS 6 に VNCサーバを設定し、ノートPCから接続すると、英字キーボードでも日本語キーボードでもない得体の知れないキーボード配列となり、文字入力に困難を極める。たまらずいろいろ調べていたら、setxkbmap というコマンドの man にヒントがあった。次のようなシェルスクリプトを /etc/profile.d/ に 何とか.sh (例えば fixvnckbd.sh) として置いておけば、とりあえず使える状態になる。

#!/bin/sh
DISPNO=${DISPLAY#*:}
if [ -n "$DISPNO" -a "${DISPNO%%.*}" != 0 ]; then
    /usr/bin/setxkbmap jp -print |/usr/bin/xkbcomp - $DISPLAY &>/dev/null
fi
unset DISPNO

その後、さらに調べていたら、RedHat のナレッジベースにそれらしい記事を見つけた ("AltGr and other keys do not work as expected when logging in over VNC and GDM"- 読むには Red Hat Network アカウントが必要)。その手順を実際に RHEL6 で試したところ、上のような環境設定ファイルを作ることなしに、確かにキーボードマップはまともになった。手順とは；

  1. VNCでログインしている場合はログアウトする。
  2. 目的のユーザでローカルログインを始める (仮想化ゲストの場合はローカル相当である Xen や KVM の直接VNCコンソールかSPICEコンソールログイン)。その際、GDMログイン画面下端のキーボード選択ドロップダウンメニューで "USA" を選択してからログインする。
  3. ログアウトする。
  4. VNCで当該のユーザでログインを開始する。キーボード選択メニューは "USA" のまま放置、特に選択してはいけない。

これで、当該ユーザの ~/.dmrc ファイルがリセットされ、自動的に正しいキーボードマップが選択されるというわけだ。CentOS の場合は、GDMログイン画面にキーボード選択メニューがないので、上記 2 でログインしたら Gnome メニューバーの システム -> 設定 -> キーボード の レイアウト タブを開き、USA をデフォルトにしてログアウトすれば、同様の効果が得られる。それでもダメな場合は レイアウト タブにある "日本語" あるいは "Japanese" を削除してみるといい。

ブートディスクの作成

情報古い。最近のディストリビューションでは試していない。

現今の肥大化したカーネルイメージでは、ついに「ブートフロッピーの作成」は不可能となってきた。initrd イメージだけで 1.2M 前後あり、さらに vmlinuz が 200K や 300K あったりするので、mkbootdisk の最中に：

cp: writing `/tmp/mkbootdisk.xxxx/initrd.img': No space left on device

とか

cat: write error: No space left on device

というエラーが出て、まともなブートディスクができない。 mkbootdisk は、実は /sbin/mkbootdisk ファイルに書かれた巧妙なシェルスクリプトなのでじっくり眺めれば分かるのだが、/tmp フォルダに、--size オプションで指定したサイズ (デフォルトでは 1440K) のカラのファイルを mktemp と dd を使って作り、 dos フォーマットする。次にそれをループバックマウントして、/boot ディレクトリにある必要なファイルをコピーする。アンマウントすれば、これがフロッピーイメージになり、最終的には実際のフロッピーにもう一度 dd で書き出されることになるのだが、必要ファイルを土台のフロッピーイメージへコピーする段階で、すでに容量オーバーになっているのだ。

さんざん試行錯誤した挙げ句、やっと方法が見つかった。フロッピーでなく、ブートCD を作れば良い。作成は、今までと同じく mkbootdisk スクリプトを使用する。コマンドはこうだ：

root# mkbootdisk --device bootcd.img --iso --size 2880 `uname -r`

従来では --device /dev/fd0 `uname -r` などとして直接フロッピーデバイスに書き込んでいたが、bootcd.img (名前は何でも良い) という ISO9660 の ブータブルCDイメージファイル に、ブートイメージ部分を 2.88M にして書き出させるわけだ。こうして書き出した ISO イメージを Linux 上の cdrecord ででも WINDOWS 上のライティングソフトででも、とにかく CD に焼き上げれば一丁上がり。

Fedora Core 4 の 64ビット版ではもうひとつ厄介な問題が見つかった。こうしたブートディスク作成のためのパッケージが、変なことをしないとインストールできないのだ。必要なパッケージは、

のふたつ。 syslinux は x86_64 用のインストール CD や yum レポジトリにあるが、特に問題なのが mkbootdisk パッケージ。 x86_64 用 CD/レポジトリに含まれていないのだ。そこで yum のために以下のような設定ファイルを作って、ゲットできるようにする；

fedora.i386.repo

[base-compat]
name=Fedora Core $releasever - i386 - Base-Compat
failovermethod=priority
baseurl=http://ring.riken.jp/archives/linux/fedora/linux/core/$releasever/i386/os
        http://ftp.kddilabs.jp/Linux/packages/fedora/core/$releasever/i386/os
gpgcheck=1
enabled=0

ポイントは赤の部分。普通なら $basearch となるところを敢えて i386 と決め打ちし、定義名なども正規の Base と重複しないようにする (上記では -compat とした)。また、普段は有効にならないよう enable=0 とし、今回の mkbootdisk のような特殊な場合だけ、 yum のコマンドラインオプションで活性化する -- 下のようなコマンドだ；

root# yum install --enablerepo=base-compat mkbootdisk

こうして取ってこれるようにさえなれば、パッケージ自体に互換性の問題はないらしく、インストール時の依存性チェックにも引っ掛からないし、実際に正常な起動 CD を作ることができた。

ユーザのデスクトップをリセットしたい

おかしなカスタマイズをしてデスクトップやランチャーがメチャクチャになってしまった時や、OS 自体をリリースアップグレードした際に新しいデフォルト設定を反映させたくなった場合などに、セッティングを一度ご破算にしたいことがある。それには、ホームディレクトリにあるデスクトップ環境関係の諸ファイルを削除すればいい。必要なファイルは次回の X ログインか startx の際に自動的に作られる。 X11R6 で RedHat 系デフォルトである Gnome デスクトップ環境を使用している場合、以下のファイル/ディレクトリを削除する。ただし、人によっては Desktop ディレクトリと .Trash ディレクトリには重要な書類が残っているかも知れないので、そういう場合はこのふたつは削除でなくリネームする。

.config
Desktop
.eggcups
.esd_auth
.gconf
.gconfd
.gnome
.gnome2
.gnome2_private
.gstreamer-0.8
.gtkrc-1.2-gnome2
.ICEauthority
.metacity
.nautilus
.recently-used
.rhn-applet
.rhn-applet.conf
.Xauthority
.Trash

どんなウィンドウマネージャを使っているかやバージョンによって、ファイルやディレクトリは多少違うはずなので、本来であれば、新しいシステムユーザを 2 人作って、一方のユーザだけは一度 X にログインさせ、ホームディレクトリの構成ファイルを比べてみるのが本筋だ。名前付きパイプを使った簡単な比較コマンド例を挙げておこう；

root# diff <(ls /home/test) <(ls /home/test2) >xcreated.txt

FATAL: ... inserting acpi_cpufreq エラー (Fedora Core 4)

OS のインストール直後には出ていなかったのだが、パッケージの総アップデートを行った後、気が付いたらスタートアップの過程でこういうエラーが出力されるようになっていた。筆者が経験したのは Fedora Core 4 の x86_64 smp (マルチプロセッサ) カーネルでのことだった。海外のメーリングリストなどを google してみたところ、多数のユーザが 「カーネルを 2.6.14-x にアップデートした後に」 同じ現象に悩まされていることが分かった。エラーはマルチプロセッサでない方のカーネルで起動しても解消されないし、もう一度初期の 2.6.11-x カーネルに戻しても解決しない。ただし、ただエラーが出るだけで、見かけ上 OS は正常に動いているように見える。 `inserting acpi_cpufreq' の後には `modules/kernel-x.x.x/kernel/arch/x86_64/kernel/cpufreq/acpi-cpufreq.ko がない' というメッセージが続く。

acpi-cpufreq.ko カーネルモジュールは、実際には無いわけでなく、機能しない (ロードできない) だけのようだった。もがき苦しんだ挙げ句、とりあえず Grub に `acpi=off' カーネルパラメータを渡すことでメッセージが出なくなることが分かる。しかし、その副作用として PCI デバイスの IRQ 割り当てが騙し騙しになるし、shutdown しても OS が終わるだけで電源はスイッチボタンを押さないと切れない、一昔前のコンピュータに戻ってしまった。

と、前振りが長くなったが、結論はあまりにあっけない。よく観察すると、このエラーが出るのはカーネルがロードされ、ファイルシステムもマウントされてからで、デーモン類のロードの序盤だ。実は、この恐ろしげなメッセージを出している張本人は cpuspeed というデーモンである。 acpi-cpufreq.ko 自体にに問題がある可能性は否定できないが、 cpuspeed デーモンを無効にしてしまえば、このエラーは起こらなくなる。もちろん、smp カーネルで起動しようが `acpi=off' カーネルパラメータを取り除こうが問題ない。 cpuspeed は、SpeedStep に類するもので、つまり、軽作業時に CPU の周波数を落として消費電力を抑える「省エネ」プログラムらしいことが分かった。デスクトップやラックマウントサーバではそもそも無くても困らないサービスなのだ。

telnetdをtcpserver経由で起動する

tcpserverのページへ移動しました。

Sun Java (J2SE) を上手にインストールする法

気を付ける点

インストール後の環境設定

RedHat系には、デフォルトプログラム切替の仕組み、alternatives (オルターナティブズ) が導入されている。Debian から移入されたフレームワークで、Windows で言えば 「プログラムのアクセスと規定の設定」といったところだろうか。比較的よくこいつで設定を換えるものに mta があるが、java もそのひとつとなっている (※1)。代替えプログラムの定義や変更は、alternatives コマンドを通じてシンボリックリンクを操ることによって行われている。

※1 どんなものが alternatives でコントロールされているかは /var/lib/alternatives/ にある設定ファイルの名前を見れば分かる。ちなみに、alternatives は chkconfig パッケージの一部だ。

現在の設定がどうなっているか調べるには；

root# alternatives --display java

JDK 5 Update 15 を Sun の rpm パッケージで /usr/java/jdk1.5.0_15/ にインストールしたとすると、以下のようにコマンドすれば新しい Java ランタイム環境を標準にできる。使い回しがきくようシェルスクリプトにしておくといい；

#!/bin/bash
# Register an alternative for java runtime environment.
JDKHOME=/usr/java/jdk1.5.0_15
 
alternatives \
--install /usr/bin/java java ${JDKHOME}/bin/java 1515 \
--slave /usr/bin/keytool keytool ${JDKHOME}/bin/keytool \
--slave /usr/bin/rmiregistry rmiregistry ${JDKHOME}/bin/rmiregistry \
--slave /usr/lib/jvm/jre jre ${JDKHOME}/jre \
--slave /usr/lib/jvm-exports/jre jre_exports ${JDKHOME}/jre/lib

`--install' の最後の引数 `1515' は候補の「お勧め度」。数字が大きいほど推奨となる。デフォルトの GNU Java に対する設定で gcj のバージョンが 1.4.2 なら `1420' という具合になっていることから、その規則にほぼ従った。不勉強で、定義名 jre_exports の意義はよく分からない。上記のシェルスクリプトで登録を行うと、推奨度が元の GNU Java より高いため、自ずと規定として選択される (つまり敢えて `alternatives --auto java' を実行する必要はない)。

alternatives の調整に加えて、環境変数 JAVA_HOME の登録と、$JDKHOME/bin の PATH への追加も行う。ただし、PATH 変数で $JDKHOME/bin を /usr/bin より前に置くと前述の alternatives の調整がほとんど無意味になってしまうため、「どうしても見つからなかったら使ってよ」程度の意味合いで PATH 変数の最後に追加する。この処理もシェルスクリプトにして、/etc/profile.d/ に置いておけば、~/.bashrc -> /etc/bashrc -> /etc/profile.d/*.sh という具合に連鎖的に読み込まれる。ファイル名は何でもいいが、拡張子は .sh にしないと読み込んでもらえない。

#!/bin/bash
JDKHOME=/usr/java/jdk1.5.0_15
 
if [ -z "$JAVA_HOME" ]; then
    export JAVA_HOME=$JDKHOME
fi
 
if grep -qwv $JDKHOME <<<$PATH; then
    PATH=$PATH:${JDKHOME}/bin
    export PATH
fi

新環境変数を反映するには、全てのコンソールから一旦ログアウトするかマシンを再起動するのが一番確実だが、事情が許さない場合には、現在ログインしているコンソールで `source ~/.bashrc' するだけでもとりあえず反映が行える。

Mozilla 及び Firefox への Java plug-in インストール

root# cd /usr/lib/mozilla/plugins
root# ln -s /usr/java/jdk1.5.0_15/jre/plugin/i386/ns7/libjavaplugin_oji.so

最近の RHEL や Fedora Core, CentOSでは、mozilla のところは firefox-x.x.x.x といった名前。CentOS 5.2 では Firefox が 3.0 beta になってしまって plugins ディレクトリがないなぁと戸惑ったが、/usr/lib/mozilla/plugins に入れたところ、ちゃんと Firefox 3 で動いた (つまり mozilla は共有ライブラリ的に機能している模様)。先にも書いたが、Linux x86_64 環境の場合、Sun JRE/JDK は未だもって 64bit 版プラグインを提供していないので、どうしても必要なら Firefox や Mozilla のほうを 32bit 版にダウンしなければならない (動作実績あり)。

Windows のけしからんリゾルバ挙動を抑え込む

Windows 2003 Server や XP で、ホスト名にプライマリドメインサフィックスを指定してある時、Windows のリゾルバは TCP/IPの常識とはかけ離れた非常に困った動きをし、ブラウザなどからインターネットホスト名を指定して接続することができなくなる狂った仕様がある。

結論から言えば、これを抑え込むには 「TCP/IPの詳細設定」 画面 (左下図) で、プライマリおよび接続専用のDNSサッフィックスを追加する と プライマリDNSサフィックスの親サフィックスを追加する をオフにし、以下のDNSサフィックスを順に追加する に `.' だけを入れておく。

解説のため、例として、左上図のように、この Windows マシンのコンピュータ名はsv1 で、プライマリドメインサフィックスに sub.hoge.com が指定してあるとする。この状態で他の設定はデフォルトのまま `nslookup sv2' すると、プライマリドメインサフィックスが補完されて、sv2.sub.hoge.com の名前解決が試みられる。ここまではいい。では、www.yahoo.co.jp を牽いたらどうなるか -- ここからがメチャクチャなのだ。実験するならば、nslookup を引数なしで起動しておいて、`set debug' でメッセージを冗長にしてからクエリを行なってみるといい。

Windows のリゾルバは、最初に

www.yahoo.co.jp.sub.hoge.com

を解決しようとする。当然そんなホストやサブドメインやドメインはないので失敗 (NXDOMAIN回答) となる。そうするとリゾルバは次に、

www.yahoo.co.jp.hoge.com

を探そうとする。そんなホストネームはあるわけがないので、最終的に名前解決は失敗に終わる。Windows 2003 Server の ping をはじめ、多くのプログラムは最初の回答 (www.yahoo.co.jp.sub.hoge.com の問いに対する NXDOMAIN 回答) であきらめてしまうようだ。だいたい、問い合わせているホスト名が FQDN らしきものか省略ホスト名なのか判断しないところがプアだ。Active Directory を使った Windows ドメイン環境ならこの動きに涙を流して感謝したくなるのか、私は知らない。
そこで、最初の「結論」で述べた工作をして逃げることになる。プライマリDNSサフィックスの親サフィックスを追加する とは、上記の動作で述べた、`sub.' を取った一段上層の www.yahoo.co.jp.hoge.com を上乗せで訊いてみるという動きを指す。プライマリおよび接続専用のDNSサッフィックスを追加する は、このマシンのプライマリドメインサフィックス、あるいは 「TCP/IP詳細設定」 の この接続のDNSサフィックス を、問い合わせホスト文字列に補完する働きの ON/OFF。これをオフにして、代わりに 以下のDNSサフィックスを順に追加する にプライマリドメインサフィックスと同じものを指定しておけば、問題はクリアしたように思える。ところが、その状態でも Windows のリゾルバは相変わらず、問いが FQDN か省略ホスト名か判断しないので、やはり www.yahoo.co.jp.sub.hoge.com という狂った DNSクエリは投げ続ける。更に悪いことに、以下のDNSサフィックスを順に追加する ラジオボタンを選んだ場合には、サフィックスリストを空にすることは許されない。そこで、リゾルバでたいては無視される末尾のドット `.' (トップレベルドメインを表す) だけをここに指定して OS を欺くというわけだ。ただし、このトリックには、ブラウザにしろ ping にしろ、ドメイン補完が全く効かなくなりホスト名は常に FQDN で指定しなければならなくなるという副作用がある。とはいえ、Windowsどうしなら勝手に NetBIOS 名が流用されるので、ping や Windows共有やリモートデスクトップをする時にはドメインを省略しても接続は成り立つ。補完なしではどうしても不便だという場合には、以下のDNSサフィックスを順に追加する リストの2番目に、プライマリドメインサフィックスと同じものを加えておくと、それらしい動きとなる。

IPv6の無効化

initscripts のバージョンによって処置内容が少々異なる。主には、RedHat のナレッジベース "How do I disable the IPv6 protocol in Red Hat Enterprise Linux?" を参考にした。以下の 3つの処置が必要だ。

1. modprobe.conf への記述追加

/etc/modprobe.d/ ディレクトリの存在するディストリビューションでは、/etc/modprobe.conf に直に書くのではなく、/etc/modprobe.d/ 下に ipv6 といったファイル (ファイル名は任意) を作成し、下記に述べる内容だけをそこに書く方がスマートだ。以下、「modprobe.conf に」という部分はそう解釈していただきたい。

※ FedoraCore 9 には、デフォルトでは /etc/modprobe.conf ファイルが存在しない。これは、デバイスモジュールのロードの役目が modprobe.conf から udev へとシフトし、OS の装備するハードウェアリストも充実してきたためだ。特殊な場合を除いては modprobe.conf へのモジュール記述が不要になりつつあるらしい。こういったディストリビューションではなおさら /etc/modprobe.d/ 配下のファイルに書くべきと思われる。

RedHat Enterprise Linux/CentOS 4の場合

modprobe.conf に以下の記述を加える。

alias net-pf-10 off

net-pf-10 は、デフォルトで ipv6 カーネルモジュールのエイリアスとして定義されている (ハードコードされている？) 名前。見てみたければ、

root# modprobe -c |grep net-pf-10

で確認することができる。

RedHat Enterprise Linux/CentOS 5.1 ～ 5.3 の場合

上記に加えて、下記の一文も記述する。

install ipv6 /bin/true

同様の作用をする記述に、`blacklist ipv6' や `alias ipv6 off' もあるが、blacklist による記述では、起動後に `modprove ipv6' とコマンドすれば、ipv6 モジュールはロードできてしまう。つまり、何か他のプログラムや他のモジュールの要求により意図せず ipv6 カーネルモジュールがロードされる可能性が残るということだ ("How to Disable IPv6 in Fedora and CentOS" より)。また、`ipv6 off' の書き方をしてあるシステム上で `modprobe ipv6' を唱えた場合、`FATAL: Module off not found.' というエラーになってイヤラしい。`install ipv6 /bin/true' なら、何かが ipv6 モジュールをロードしようとした際には必ず /bin/true が実行されるだけ、つまり何も起こらない。

RedHat Enterprise Linux/CentOS 5.4 以降の場合

net-pf-10 の記述と、下記の一文を記述する。

options ipv6 disable=1
FedoraCore 9 以降の場合

上記のどれが正解なのか不明。そういった場合は、とりあえず 3つとも書いておいても害はないようだ。

2. network への記述追加

/etc/sysconfig/network ファイルに以下の記述を加える。厳密には initscripts のバージョンに依存するのだろうが、余計な変数を定義たとしても /etc/sysconfig/network-scripts/ifup シェルスクリプトとそこから呼ばれる ifup-eth などで無視されるだけなので、共通と考えていいだろう。もっと調べたければ、initscripts パッケージ付属のドキュメント <share>/doc/initscripts-x.x.x/sysconfig.txt を読むといいだろう。

NETWORKING_IPV6=no
IPV6INIT=no
IPV6_AUTOCONF=no

下のふたつは、各インターフェイスファイル (/etc/sysconfig/network-scripts/ifcfg-*) で個別に指定することもできるものだが、sysconfig/network ファイルに書いておくと、全てのネットワークインターフェイスに対するグローバルな指示となる。これを確実にするため、各インターフェイスファイルにこれらを打ち消すような記載がないことも確認しておかなくてはならない。なお、最後の IPV6_AUTOCONF=no は、前出の "How do I disable the IPv6 protocol in Red Hat Enterprise Linux?" では触れられていないが、実際にネットワークinitスクリプトを見てみると IPv6 モジュールをロードするかしないかの重要なトリガーになっている様子なので、念のため記述することにしている。

3. ip6tables の停止

IPv6 版 iptables がスタートアップしないようにする。

root# chkconfig ip6tables off
root# chkconfig --list ip6tables

手順 1 ～ 3 が全て完了したら、システムをリブートする。起動後、`lsmod |grep ipv6' と `lsmod |grep net-pf-10' をコマンドして何も出力されないことを確認する。

ローカルでしか開かないGUIツールをリモートから使うには

例えば、RedHat系の system-config-* などシステム管理系 GUI ツールの中には、VNCでリモート接続している時や、root 以外の一般ユーザでローカルの X Window にログインしている時には使えないものがある。そういう時には、ssh の X Forwarding 機能を活用するとたいていのものは動かすことができる。この機能を使うためには、サーバ (接続先) の sshd_config で X11Forwarding が yes に設定してある必要がある。例えば、

リモートマシンの virt-manager をクライアント端末 (操作端末) から開くには、クライアント端末の X Window 上のターミナルで、下記のようにコマンドする；

ssh -Y root@server virt-manager

リモートマシンへの一般ユーザでのVNC接続中に、リモートマシンの virt-manager を開くには、VNCセッション上のターミナルで、下記のようにコマンドする；

ssh -Y root@localhost virt-manager

これでも開けない場合は、上記コマンドの前に下記のコマンドを発行しておく；

xhost +localhost

 

  TOP  
  HOME