よろず環境設定  
  HOME Next

よろず環境設定

移転しました

独自ドメインサイトへ移行しました。5秒後に

https://straypenguin.winfield-net.com/

へジャンプします。

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 に変更するわけだ。

Systemd に牛耳られたシステムでのデフォルトモードの変更は、runレベル3相当への変更なら、

root# systemctl set-default multi-user.target

runレベル5相当への変更は、

root# systemctl set-default graphical.target

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 が日本語環境で立ち上がるようになる。

Gnomeセッションの自動起動アプリを無効にする

インターネットに接続できないサーバでの puplet (更新チェックアプリ) や Red Hat Network ログインアプリ、サウンドカードを搭載していないサーバでのボリュームアイコンなど、X にログインする度に無駄なアプリが起動して困る。特定のユーザに対してのみ無効にするなら、システム メニュー -> 設定 -> 他の個人設定 -> セッション の 自動起動するプログラム タブで無効にすることができる。しかし、たくさんのシステムユーザを作らなければならないサーバの場合、ユーザ毎にいちいちこれをやるのは大変だ。

全てのユーザで自動起動アプリを無効にするには、

/etc/xdg/autostart/
及び
/usr/share/gnome/autostart/

にある *.desktop ファイルの拡張子を変える (例えば *.disabled) か、無効にしたい *.desktop ファイル内に、

X-GNOME-Autostart-enabled=false

を書き加えておけばいい。しかし、これにしても、たくさんの *.desktop ファイルを手で編集するのは疲れる。そこで、こんなシェルスクリプトを作った；

disable-autostart6.sh

冒頭付近の uzap 配列には /etc/xdg/autostart/ にある Uzaいアプリを列挙しておく。これらは X-GNOME-Autostart-enabled=false にされる。uzap2 は /usr/share/gnome/autostart/ にあるもので、こちらはファイル名を *.disable にリネームするようにした。ついでに、ESXi 5 のゲストOSとして稼働させている RHEL6 のために、VMware Tools の vmware-user というデスクトップサービスも停止するようにした。vmware-user は、RHEL6 上で起動されると、VNCサーバが機能不全に陥るという害があるからだ。RHEL5 では悪さはしないようなので vmware-user に関する部分は取り除いて使っていただきたい。なお、このシェルスクリプトは複数回実行しても害のない作りになっているので、パッケージのアップデートや VMware Tools の入れ直しの度に実行したほうがいいだろう。

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

前項に関連するが、デフォルトの仮想コンソールフォント (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

条件文の部分は、VNCコンソールの時だけコマンドが流れたほうがいいのか、逆にローカルの Xコンソールの時だけ流したほうがいいのか、ケースバイケースなので各自調整していただきたい。例えば、ディスプレイナンバー 0～9 では流れないようにすると、こんな感じになる： fixvnckbd.sh

その後、さらに調べていたら、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" を削除してみるといい。

ところがこれまた、VNC で配列が直ったと思ったら、今度はローカルの Xコンソールがダメになったり...困ったものだ。結局、前出の fixvnckbd.sh みたいなものの出番は多い。

ブートディスクの作成

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

現今の肥大化したカーネルイメージでは、ついに「ブートフロッピーの作成」は不可能となってきた。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 7 Update 111 を Oracle (Sun) からダウンロードした rpm パッケージで /usr/java/jdk1.7.0_111/ にインストールしたとすると、以下のようにコマンドすれば新しい Java 環境を標準にできる。alternatives 定義セットは非常に長ったらしいので、使い回しがきくようシェルスクリプトにしておくといい。仮にファイル名を alternatives-install.sh とする。その一部だけを下記に示す。

#!/bin/sh
MANDIR=/usr/share/man
JDKHOME=/usr/java/jdk1.7.0_111
JDKMANDIR=${JDKHOME}/man
JREHOME=/usr/java/jdk1.7.0_111/jre
PREFER=1700111
 
alternatives --install /usr/bin/javac javac ${JDKHOME}/bin/javac $PREFER \
 --slave /usr/bin/appletviewer appletviewer ${JDKHOME}/bin/appletviewerr \
 --slave /usr/bin/apt apt ${JDKHOME}/bin/apt \
 --slave /usr/bin/extcheck extcheck ${JDKHOME}/bin/extcheck \
 --slave /usr/bin/idlj idlj ${JDKHOME}/bin/idlj \
 --slave /usr/bin/jar jar ${JDKHOME}/bin/jar \
 --slave /usr/bin/jarsigner jarsigner ${JDKHOME}/bin/jarsigner \
 --slave /usr/bin/javadoc javadoc ${JDKHOME}/bin/javadoc \
 --slave /usr/bin/javah javah ${JDKHOME}/bin/javah \
 --slave /usr/bin/javap javap ${JDKHOME}/bin/javap \
 --slave /usr/bin/jcmd jcmd ${JDKHOME}/bin/jcmd \
 --slave /usr/bin/jconsole jconsole ${JDKHOME}/bin/jconsole \
 --slave /usr/bin/jdb jdb ${JDKHOME}/bin/jdb \
 --slave /usr/bin/jhat jhat ${JDKHOME}/bin/jhat \
 --slave /usr/bin/jinfo jinfo ${JDKHOME}/bin/jinfo \
 --slave /usr/bin/jmap jmap ${JDKHOME}/bin/jmap \
 --slave /usr/bin/jps jps ${JDKHOME}/bin/jps \
 --slave /usr/bin/jrunscript jrunscript ${JDKHOME}/bin/jrunscript \
 --slave /usr/bin/jsadebugd jsadebugd ${JDKHOME}/bin/jsadebugd \
 --slave /usr/bin/jstack jstack ${JDKHOME}/bin/jstack \
 --slave /usr/bin/jstat jstat ${JDKHOME}/bin/jstat \
 --slave /usr/bin/jstatd jstatd ${JDKHOME}/bin/jstatd \
 --slave /usr/bin/native2ascii native2ascii ${JDKHOME}/bin/native2ascii \
 --slave /usr/bin/policytool policytool ${JDKHOME}/bin/policytool \
 --slave /usr/bin/rmic rmic ${JDKHOME}/bin/rmic \
 --slave /usr/bin/schemagen schemagen ${JDKHOME}/bin/schemagen \
 --slave /usr/bin/serialver serialver ${JDKHOME}/bin/serialver \
 --slave /usr/bin/wsgen wsgen ${JDKHOME}/bin/wsgen \
 --slave /usr/bin/wsimport wsimport ${JDKHOME}/bin/wsimport \
 --slave /usr/bin/xjc xjc ${JDKHOME}/bin/xjc \
 --slave /usr/lib/jvm/java java_sdk ${JDKHOME} \
 --slave /usr/lib/jvm-exports/java java_sdk_exports ${JDKHOME}/lib \
 --slave ${MANDIR}/man1/appletviewer.1 appletviewer.1 ${JDKMANDIR}/man1/appletviewer.1 \
 --slave ${MANDIR}/man1/apt.1 appt.1 ${JDKMANDIR}/man1/apt.1 \
 --slave ${MANDIR}/man1/extcheck.1 extcheck.1 ${JDKMANDIR}/man1/extcheck.1 \
 --slave ${MANDIR}/man1/idlj.1 idlj.1 ${JDKMANDIR}/man1/idlj.1 \
 --slave ${MANDIR}/man1/jar.1 jar.1 ${JDKMANDIR}/man1/jar.1 \
 --slave ${MANDIR}/man1/jarsigner.1 jarsigner.1 ${JDKMANDIR}/man1/jarsigner.1 \
 --slave ${MANDIR}/man1/javac.1 javac.1 ${JDKMANDIR}/man1/javac.1 \
 --slave ${MANDIR}/man1/javadoc.1 javadoc.1 ${JDKMANDIR}/man1/javadoc.1 \
 --slave ${MANDIR}/man1/javah.1 javah.1 ${JDKMANDIR}/man1/javah.1 \
 --slave ${MANDIR}/man1/javap.1 javap.1 ${JDKMANDIR}/man1/javap.1 \
 --slave ${MANDIR}/man1/jcmd.1 jcmd.1 ${JDKMANDIR}/man1/jcmd.1 \
 --slave ${MANDIR}/man1/jconsole.1 jconsole.1 ${JDKMANDIR}/man1/jconsole.1 \
 --slave ${MANDIR}/man1/jdb.1 jdb.1 ${JDKMANDIR}/man1/jdb.1 \
 --slave ${MANDIR}/man1/jhat.1 jhat.1 ${JDKMANDIR}/man1/jhat.1 \
 --slave ${MANDIR}/man1/jinfo.1 jinfo.1 ${JDKMANDIR}/man1/jinfo.1 \
 --slave ${MANDIR}/man1/jmap.1 jmap.1 ${JDKMANDIR}/man1/jmap.1 \
 --slave ${MANDIR}/man1/jps.1 jps.1 ${JDKMANDIR}/man1/jps.1 \
 --slave ${MANDIR}/man1/jps.1 jps.1 ${JDKMANDIR}/man1/jps.1 \
 --slave ${MANDIR}/man1/jrunscript.1 jrunscript.1 ${JDKMANDIR}/man1/jrunscript.1 \
 --slave ${MANDIR}/man1/jsadebugd.1 jsadebugd.1 ${JDKMANDIR}/man1/jsadebugd.1 \
 --slave ${MANDIR}/man1/jstack.1 jstack.1 ${JDKMANDIR}/man1/jstack.1 \
 --slave ${MANDIR}/man1/jstat.1 jstat.1 ${JDKMANDIR}/man1/jstat.1 \
 --slave ${MANDIR}/man1/jstatd.1 jstatd.1 ${JDKMANDIR}/man1/jstatd.1 \
 --slave ${MANDIR}/man1/native2ascii.1 native2ascii.1 ${JDKMANDIR}/man1/native2ascii.1 \
 --slave ${MANDIR}/man1/policytool.1 policytool.1 ${JDKMANDIR}/man1/policytool.1 \
 --slave ${MANDIR}/man1/rmic.1 rmic.1 ${JDKMANDIR}/man1/rmic.1 \
 --slave ${MANDIR}/man1/schemagen.1 schemagen.1 ${JDKMANDIR}/man1/schemagen.1 \
 --slave ${MANDIR}/man1/serialver.1 serialver.1 ${JDKMANDIR}/man1/serialver.1 \
 --slave ${MANDIR}/man1/wsgen.1 wsgen.1 ${JDKMANDIR}/man1/wsgen.1 \
 --slave ${MANDIR}/man1/wsimport.1 wsimport.1 ${JDKMANDIR}/man1/wsimport.1 \
 --slave ${MANDIR}/man1/xjc.1 xjc.1 ${JDKMANDIR}/man1/xjc.1

`--install' の最後の引数として $PREFER 変数で与えている "1700111" は候補の「お勧め度」。数字が大きいほど推奨となる。デフォルトの OpenJDK の採番ルールに倣った。上記スクリプトでは上記 javac (JDK javaコンパイラ) の他に、java (JRE java)、java_sdk_1.7.0、java_sdk_1.7.0_sun、jre_1.7.0、jre_1.7.0_sun という alternatives も設定している。

RHEL標準パッケージでインストールしたにしろ、Oracle の rpm でインストールしたにしろ、以下を実行して、インストールしたJDK/JRE をデフォルトにしてやる。 

# alternatives --config javac
# alternatives --config java_sdk_1.7.0
# alternatives --config java
# alternatives --config jre_1.7.0

"_sun" 付きの候補の対象は Oracle Java しかないので、`--install' した途端にリンクが張られる。

また、上記の alternatives-install スクリプトを使った場合は、定義に失敗してやり直したい時やインストールしたJDKをアンインストールした時のために、下記のような定義削除スクリプトも用意しておくと便利だ。alternatives-remove.sh としよう。 

#!/bin/sh
JDKHOME=/usr/java/jdk1.7.0_111
JREHOME=/usr/java/jdk1.7.0_111/jre
 
alternatives --remove javac ${JDKHOME}/bin/javac
alternatives --remove java_sdk_1.7.0 ${JDKHOME}
alternatives --remove java_sdk_1.7.0_sun ${JDKHOME}
alternatives --remove java ${JREHOME}/bin/java
alternatives --remove jre_1.7.0 ${JREHOME}
alternatives --remove jre_1.7.0_sun ${JREHOME}

alternatives の調整に加えて、環境変数 JAVA_HOME/JRE_HOME の登録と PATH への追加、CLASSPATH のエクスポートを行う。下記シェルスクリプトの $JAVA_HOME と $JRE_HOME は alternatives によって張られるリンクであるため、のちに別バージョンの JDK をインストールしたとしても、その度にこのシェルスクリプトを直す必要はない。これを /etc/profile.d/ に置いておけば、各ユーザのログインの際に、~/.bashrc -> /etc/bashrc -> /etc/profile.d/*.sh という具合に連鎖的に読み込まれて環境変数がエクスポートされる。ファイル名は何でもいいが、拡張子は .sh にしないと読み込んでもらえない。

j_pathmunge () {
    if ! echo $PATH | /bin/egrep -q "(^|:)$1(:|\$)" ; then
        if [ "$2" = "after" ] ; then
            PATH=$PATH:$1
        else
            PATH=$1:$PATH
        fi
    fi
}
 
JAVA_HOME=/usr/lib/jvm/java
JRE_HOME=/usr/lib/jvm/jre
export JAVA_HOME JRE_HOME
 
j_pathmunge ${JAVA_HOME}/bin
j_pathmunge ${JRE_HOME}/bin
export PATH
 
export CLASSPATH=.:${JRE_HOME}/lib:${JAVA_HOME}/lib:${JAVA_HOME}/lib/tools.jar

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

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

Sun JDK 1.5.0 の時代には手動で、

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

のようにやったものだが、最近ではこれも alternatives で行われるようになった。候補名は libjavaplugin.so.x86_64 という(長い!)。それに倣い、Oracle からダウンロードしたJDK用の定義設定/定義削除スクリプトを作ると、下記のようなものになる。この例は CentOS 6 または 7 x86_64 プラットフォームへの JDK1.7.0 インストール用だが、わずかに修正すれば他のケースにも対応できる。

alternatives-javaplugin-install.sh

#!/bin/sh
JREHOME=/usr/java/jdk1.7.0_111/jre
PREFER=1700111
 
alternatives --install /usr/lib64/mozilla/plugins/libjavaplugin.so libjavaplugin.so.x86_64 ${JREHOME}/lib/amd64/libnpjp2.so $PREFER \
 --slave /usr/bin/javaws javaws ${JREHOME}/bin/javaws

alternatives-javaplugin-remove.sh

#!/bin/sh
JREHOME=/usr/java/jdk1.7.0_111/jre
 
alternatives --remove libjavaplugin.so.x86_64 ${JREHOME}/lib/amd64/libnpjp2.so

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

Windows 2003 Server や XP で、ホスト名にプライマリドメインサフィックスを指定してある時、Windows のリゾルバは TCP/IPの常識とはかけ離れた非常に困った動きをする。ブラウザなどからインターネットホスト名を指定して接続することができなくなるだけでなく、イントラローカル用のドメイン名をDNSクエリというかたちでインターネットへ垂れ流す、これは立派な情報漏洩であり、且つネットトラフィック公害でもある。

結論から言えば、これを抑え込むには 「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番目に、プライマリドメインサフィックスと同じものを加えておくと、それらしい動きとなる。
  TOP Next
  HOME よろず環境設定 2