accomplish nothing

2011年11月28日現在、LevelDBのMakefileはまだ共有ライブラリの生成に対応してないので、それについてのworkaround。何度も同じことを考えるのを防ぐための備忘用。

まず、元になるオブジェクトコードを作る。

CFLAGS="-I$HOME/opt/snappy-1.0.4/include" \
gmake CC="g++ -m64" OPT="-O2 -DNDEBUG -fPIC" \
SNAPPY_CFLAGS="-I$HOME/opt/snappy-1.0.4/include -DSNAPPY"          

各指定の簡単な解説。

最初のCFLAGSはSnappyのヘッダの位置をプリプロセッサに伝える。標準の位置にあるならこの指定は不要。build_detect_platformでのみ有効で、MakefileでCFLAGSは上書きされる。SNAPPY_CFLAGSでも同じ指定をしているのはそのため。

今回は64ビットのライブラリを作りたい（Clozure CLの64ビットバイナリからFFI経由で使いたくなった）ので、CCはg++ -m64で。GCC 4.7より前のバージョンでは、GCCをビルドするときに設定しない限り、Solaris/x86-64でもデフォルトで64ビットコードを作らない。Solaris 11の標準のGCC 4は4.5.2。

効率的に動作して欲しいので、-fPICを付ける。適当な場所が見当たらなかったので、OPTに追加。

SNAPPY_CFLAGSは上に書いているように、ヘッダの位置の指定を追加。

次に、共有ライブラリを作る。

g++ -m64 -shared -Wl,-h,libleveldb.so.0 \
db/*.o port/*.o table/*.o util/*.o \
-Wl,-R,$HOME/opt/lib -L$HOME/opt/snappy-1.0.4/lib \
-lsnappy -lpthread -lrt -o libleveldb.so.0.0

64ビットのライブラリを作るため、-m64を指定するのは同じ。

-sharedで共有ライブラリを作ると指定し、-Wl,-hでsonameを指定するためのオプションをリンカに渡す。Solarisのldでは-sonameではなく-h。あるいは--soname。

材料のオブジェクトファイルは上の例のように指定すればすべて揃う。不安ならmakeしたときにarに渡されているファイルと照らし合わせれば確認できる。

リンクするライブラリは、Snappyと、環境に依存するライブラリ。これは、makeするときにできるbuild_config.mkを見れば分かる。PLATFORM_LDFLAGSに指定されているもの。Snappyも64ビットとしてビルドされていないと、当然リンクできないので注意。Snappyが標準の場所にないので、-Wl,-RでRUNPATHも指定する。

以上。あとは適当にサーチパスに放り込んで、libleveldb.so.0とlibleveldb.soという名前のシンボリックリンクをlibleveldb.so.0.0に張れば終わり。

SXCE b95へGNU Binutils 2.18をインストールした。特に躓くこともなく、configureスクリプトを実行してから、makeをすることで、素直にビルドできた。以下は操作手順。

% ./configure --prefix=/opt/binutils-2.18 --program-prefix=g
% gmake
# gmake install
# cd /opt/bin
# for i in ../binutils-2.18/bin/*
>do
>ln -s $i
>done

configureに--program-prefix=gを渡しているのは、Sunのasやldなどと区別するため。SXCEに付属のGNU Binutilsもそういう設定になっているので、合わせたというのもある。それと、makeにはGNU makeを使った。Sunのmakeでは、configureが作ったMakefileを上手く処理できないようだ。

正確に言うとAutoconf 2.61の問題なんだけど、GCCを使っていても、CCの値が（/opt/pkgsrc/bin/gccのように）パスを含む場合、configureスクリプトが使っているコンパイラを誤判定する。これにより、リンカに間違ったオプションが渡され、libgauche.soのリンクに失敗してしまう。

このくらい良きに計らってくれよ、と目眩がする思いだが、現時点の最新版のAutoconf 2.62では直っているのだろうか。

もう一度詳しく調べたところ、Gauche 0.8.13のconfigure.acに問題があった。Autoconf関係者の方々、ごめんなさい。

SXCEにはb90の現時点で、Solaris Secure Shellが含まれている。これは、SunがOpenSSHをベースに開発したSSHの実装のひとつ。SSHサーバのsshdがインストール直後から起動しているため、きちんと設定をすれば、すぐにSSHプロトコルで通信できるようになる。

今回設定するサーバにはLANの中の特定のPCからしか接続しないので、ホストに基づく認証を使って接続する。作業手順は以下の通り。

• /etc/ssh/sshd_configの編集
• /etc/ssh/shosts.equivの編集
• /etc/ssh/ssh_known_hostsへ接続を許すホストの公開鍵を追加
• ~/.shostsの編集
• sshdの再起動

Solaris Secure Shellの設定ファイルは、/etc/sshディレクトリにまとまって入っている。まずは、その中の/etc/ssh/sshd_configを編集。最初に、

HostbasedAuthentication yes

という行を追加。ホストに基づく認証を行うという意味。標準ではホストに基づく認証は使えないようになっている。次に、

IgnoreRhosts yes

という部分を、

IgnoreRhosts no

と変更。ホストに基づく認証で~/.shostsを使うようになる。ホストに基づく認証をするだけなら不要だが、ユーザの名前が接続元と接続先で違う場合には必要。今回はまさにそのケース。

/etc/ssh/shosts.equivの設定。rshが使う/etc/hosts.equivと書式は同じ。一行ごとに、接続を許すホスト名を書く。

client-host

/etc/ssh/shosts.equivに接続を許すホストを列挙したら、今度は/etc/ssh/ssh_known_hostsに、接続を許すそれぞれのホストの公開鍵を追加する。ssh_host_dsa_key.pubが公開鍵だとすると、

# (echo -n "client-host "; cat ssh_host_dsa_key.pub) >> /etc/ssh/ssh_known_hosts

のように、ファイルの終わりに公開鍵を書き込む。

~/.shostsの設定。接続を許すユーザのホームディレクトリに.shostsというファイルを作り、

client-host client-user

のように、ホスト名に続けてユーザ名を書く。

設定がすべて終わったので、最後にsshdの再起動。

# svcadm restart ssh

Solaris Secure ShellもSMFで管理されているサービスなので、こういう操作は簡単。

Nevada b83aでpkgsrcのgmakeをビルドするとき、GMAKE_LOCALE=noを指定しないと、gettextやgcc経由で回り回ってgmakeに戻ってきて、循環参照のエラーと共に失敗する。笑えない。

# GMAKE_LOCALE=no; export GMAKE_LOCALE
# bmake
# bmake install

Nevadaでのソフトウェアの管理の手間を省くために、NetBSDで主に利用されているパッケージシステムのpkgsrcを、Nevada b83a（以下b83a）に導入する。流れとしては次のようになる。

1. 一番新しいpkgsrcのアーカイブをダウンロードする
2. pkgsrcのアーカイブを展開する
3. pkgsrcを最新の状態に更新する
4. bootstrapスクリプトを実行する
5. mk.confでpkgsrcの設定をする

以下詳細。まず、一番新しいpkgsrcのアーカイブを、NetBSDのFTPサーバからダウンロードする。gzipとbzip2の二種類あるが、b83aにはGNU tarもbzip2も標準で付いてくるので、どちらを選んでも構わない。

# cd /tmp
# curl ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.bz2 > pkgsrc.tar.bz2
# md5sum pkgsrc.tar.bz2
# curl ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.bz2.MD5

チェックサムの一致を確認したら、アーカイブを展開する。NetBSDでは、pkgsrcを/usr/pkgsrcに置くが、Solarisではユーザアプリケーションを/optにインストールする慣習があるようなので、/opt/pkgsrc/pkgsrcに展開する。/opt/pkgsrcにはpkgsrcで管理するソフトウェアをインストールし、/opt/pkgsrc/pkgsrcにはpkgsrc自体を置く。

# mkdir /opt/pkgsrc; cd /opt/pkgsrc
# bzcat /tmp/pkgsrc.tar.bz2 | tar xof -

次にpkgsrcの更新。ダウンロードしてきたアーカイブも、最新と言ってほぼ差し支えないが、pkgsrcは常に更新され続けているため、アーカイブと最新のバージョンの間には差がある場合が多い。できるだけ新しい方が都合が良いので、CVSでpkgsrcを更新する。b83aにCVSは収録されていないので、Solaris Operating System - Freewareからパッケージ化されたCVSをダウンロードし、インストールする。

# bzip2 -d SFWcvs.pkg.bz2
# pkgadd -d SFWcvs.pkg

CVSのインストールが済んだら、CVSでpkgsrcを更新する。

# CVSROOT=anoncvs@anoncvs.NetBSD.org:/cvsroot; export CVSROOT
# CVS_RSH=ssh; export CVS_RSH
# cd /etc/pkgsrc/pkgsrc; cvs update -dP

bootstrapスクリプトを実行し、pkgsrcに必要なツールをコンパイルする。gccは/usr/sfw/binにあるので、パスを通しておく。

# PATH=$PATH:/usr/sfw/bin
# cd bootstrap
# ./bootstrap --prefix=/opt/pkgsrc --sysconfdir=/opt/pkgsrc/etc --pkgdbdir=/var/opt/pkgsrc/db/pkg --varbase=/var/opt/pkgsrc

あとは、libtoolで/bin/kshがクラッシュする問題を避けるために、mk.confを編集して終わり。

CONFIG_SHELL=   /usr/bin/bash
WRAPPER_SHELL=  /usr/bin/bash

セキュリティ上の理由から、不要なサービスを停止する。

# svcs | grep online

で有効になっているサービスを確認して、要らないサービスを見付ける。サービスの概要は-lで確認できる。Solaris のシステム管理 (基本編)に詳しい。Solarisはこういったオフィシャルな情報が充実していて快適。

Nevada Build 77では、telnetやFTPなどはデフォルトで無効になっているようなので、sendmailだけ無効に。

# svcadm disable sendmail

Solarisはrootのホームディレクトリが/でビビる。/にドットファイルが溜まっていくのは嫌じゃないのか。何という俺様root。うっかりrootでJava Desktop Systemを使ったら、/にいっぱい設定ファイルを作られた。

調べてみると、結構rootのホームディレクトリが/なことに抵抗がある人は多いらしい。Solarisをセキュアな設定にする作業を自動化してくれるSolaris Security Toolkitというツールがあって、Solaris Security Toolkit 4.2 リファレンスマニュアルでも、

多くの Solaris セキュリティー強化スクリプトおよび手順では、root アカウントにシングルスラッシュ (/) 以外のホームディレクトリを与えることを推奨しています。Solaris OS の root アカウントのホームディレクトリを変更すると、次のように、セキュリティーとシステム管理の点で利点があり、また Solaris OS とそのほかの UNIX システム (Linux/*BSD を含む) との互換性が高くなります。

Sun Microsystems, Inc. 2005. Solaris Security Toolkit 4.2 リファレンスマニュアル. <http://docs.sun.com/source/819-3793-10/index.html>. Accessed 2007 Dec 4.

と書いてる。だったら初めからそうしとけよ、とも思うけど、後方互換性が問題になったりするのかもしれない。

# mkdir /root
# chmod 700 /root
# usermod -d /root root

suでrootになって/rootを作り、ホームディレクトリを/rootに。後はドットファイルなどを/rootに移動すれば良い。

Build 77時点でのNevadaのインストーラでは、インストール時にユーザアカウントを追加できないので、インストールが終わったら、まず自分のアカウントを追加しないといけない。管理ツールかコマンドラインの、ふたつの選択肢がある。ここではコマンドラインについて。

# groupadd newuser
# useradd -g newuser -m -d /export/home/newuser newuser

groupaddでグループを作り、useraddでユーザを追加する。上の例ではユーザ名と同じグループをまず作り、次にそのグループに属したユーザを作っている。-gでプライマリグループ、-dでホームディレクトリを指定している。-mはホームディレクトリが存在しなかったときに新しくディレクトリを作るオプション。逆に言えば、このオプションを付けなければホームディレクトリは自動的に作られない。

UNIXでホームディレクトリと言えば/homeだけど、上の例では/export/home/newuserとなっている。これには理由がある。

Solarisでは、/homeはautofsで管理され、ネットワーク上での共有に最適化されているそうだ。複数の端末を前提としている辺り、OSとしての性格が出ていると思う。あるいは、エンタープライズにフォーカスしているOSというのは、みんなこういうものなんだろうか。

さておき、autofsの管理によって、/homeには直接ホームディレクトリを置けなくなっている。Solarisでは、/export/homeにホームディレクトリの実体を置き、/homeに/export/homeを自動的にマウントするのが慣例らしい。

郷に入れば、ということで、Solarisのシステム管理を参考に設定する。ホームディレクトリを参照するときに$HOMEを使ったり、シンボリックリンクを相対パスで作るとポータビリティの観点から良いらしい。納得。

自分のユーザアカウントができたら、rootから作ったユーザに切り替え、必要なときだけsuでrootでの作業をする。

Nevada Build 77をVMware Server 1.0.4にインストールした。

インストールについては、Solaris 10なども含めて、結構な量の情報があって助かる。意外にまだSolarisは人気があるらしい。Linuxとかに比べれば雀の涙だろうけど。

とりあえず、本来の目的である備忘を兼ねて、以下インストール後の設定について記録。ちなみに、ユーザを追加して、ログインし直すまでは、コンソールからログインした方が良い。rootでJava Desktop Systemを使ったりすると、/に設定ファイルなどがいっぱい作られてしまう。