Nexentaをファイル/IMAPサーバにする

OpenSolarisカーネルのNexentaOS Alpha 7をファイル(Samba・NFS)/IMAPサーバにすることにします。

つい先日Debian/GNU Linux 4.0に移行したばかりですが、Linux以外のも使っていた方が視野が広がるかな、と。
言い訳ですけど。

あいかわらずよく分からずにやっていますので、信用しないでください。


○ NFSの設定
/share/shareをNFS共有にします(参考)。
/share/shareはzfsコマンドで作成したZFSファイルシステムです。

zfsコマンドを使用して次のコマンドを叩いただけです。
/share/shareを共有ディレクトリにします。

root@julie:~# zfs set sharenfs=rw share/share

○ Sambaの設定
NexentaOS Alpha 7に用意されている3.0.24を使用することにしました。

$ dpkg -l|grep samba
ii  samba   3.0.24-2nexenta2   a LanManager-like file and printer server fo
ii  samba-common   3.0.24-2nexenta2   Samba common files used by both the server a
ii  samba-doc   3.0.24-2nexenta2   Samba documentation

smb.confはDebian/GNU Linux 4.0のsmb.confをほぼそのまま使おうと思ったのですが、なぜかSambaがコアダンプしてしまいます。

コアダンプの件は後で調べるとして、取り急ぎNexentaに入っていたsmb.confを基に必要なところだけ修正して使用することにしました。
使用していないプリンタの設定が残っていたりしますので、後で見直します。

[global]
## Browsing/Identification ###
# Change this to the workgroup/NT-domain name your Samba server will part of
  workgroup = Windowsグループ名

# server string is the equivalent of the NT Description field
  server string = %h server (CIFS, Nexenta)

  unix charset = UTF-8
  dos charset = CP932

# This will prevent nmbd to search for NetBIOS names through DNS.
  dns proxy = no

#### Debugging/Accounting ####
# This tells Samba to use a separate log file for each machine
# that connects
  log file = /var/log/samba/log.%m

# Put a capping on the size of the log files (in Kb).
  max log size = 1000

# We want Samba to log a minimum amount of information to syslog. Everything
# should go to /var/log/samba/log.{smbd,nmbd} instead. If you want to log
# through syslog you should set the following parameter to something higher.
  syslog = 0

# Do something sensible when Samba crashes: mail the admin a backtrace
  panic action = /usr/share/samba/panic-action %d


####### Authentication #######

# "security = user" is always a good idea. This will require a Unix account
# in this server for every user accessing the server. See
# /usr/share/doc/samba-doc/htmldocs/Samba3-HOWTO/ServerType.html
# in the samba-doc package for details.
;   security = user

# You may wish to use password encryption.  See the section on
# 'encrypt passwords' in the smb.conf(5) manpage before enabling.
  encrypt passwords = true

# If you are using encrypted passwords, Samba will need to know what
# password database type you are using. 
  passdb backend = tdbsam

  obey pam restrictions = yes

;   guest account = nobody
  invalid users = root

# For Unix password sync to work on a Debian GNU/Linux system, the following
# parameters must be set (thanks to Ian Kahan < for
# sending the correct chat script for the passwd program in Debian Sarge).
  passwd program = /usr/bin/passwd %u
  passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n *password\supdated\ssuccessfully* .


############ Misc ############
# Most people will find that this option gives better performance.
# See smb.conf(5) and /usr/share/doc/samba-doc/htmldocs/Samba3-HOWTO/speed.html
# for details
# You may want to add the following on a Linux system:
#         SO_RCVBUF=8192 SO_SNDBUF=8192
  socket options = TCP_NODELAY

#======================= Share Definitions =======================
[printers]
  comment = All Printers
  browseable = no
  path = /var/spool/samba
  printable = yes
  public = no
  writable = no
  create mode = 0700

# Windows clients look for this share name as a source of downloadable
# printer drivers
[print$]
  comment = Printer Drivers
  path = /var/lib/samba/printers
  browseable = yes
  read only = yes
  guest ok = no

[share]
  comment = Julie share
  path = /share/share
  browseable = no

# By default, the home directories are exported read-only. Change next
# parameter to 'yes' if you want to be able to write to them.
;   writable = no
  writable = yes

一番のキモは

   unix charset = UTF-8
  dos charset = CP932

でしょうか(参考記事)。


○ IMAPの設定
Nexentaにはcyrus-imapd-2.2というのがあり、使おうとして設定までしたのですが、今まで使っていたuw-imapdの方が私には分かりやすかったためこちらを使うことにしました。

ftp://ftp.cac.washington.edu/imap/からimap-2006j2.tar.Zをもらってきて展開しmakeしました。

make時にOpenSSL関係と思われるエラーが出てmakeに失敗しました。

$ make gso

〜 省略 〜

In file included from tcp_unix.c:29,
                from osdep.c:63:
ip_unix.c: In function 'ip_nametoaddr':
ip_unix.c:165: warning: pointer targets in passing argument 1 of 'lcase' differ in signedness
ip_unix.c:165: warning: pointer targets in passing argument 1 of 'gethostbyname' differ in signedness
osdep.c:246:20: error: x509v3.h: No such file or directory
osdep.c:247:17: error: ssl.h: No such file or directory
osdep.c:248:17: error: err.h: No such file or directory
osdep.c:249:17: error: pem.h: No such file or directory
osdep.c:250:20: error: buffer.h: No such file or directory
osdep.c:251:17: error: bio.h: No such file or directory
osdep.c:252:20: error: crypto.h: No such file or directory
osdep.c:253:18: error: rand.h: No such file or directory

〜 省略 〜

sslstdio.c:163: error: request for member 'sslstream' in something not a structure or union
sslstdio.c:163: error: request for member 'obuf' in something not a structure or union
sslstdio.c:164: error: request for member 'octr' in something not a structure or union
sslstdio.c:166: error: request for member 'optr' in something not a structure or union
sslstdio.c:166: error: request for member 'obuf' in something not a structure or union
sslstdio.c:167: error: request for member 'octr' in something not a structure or union
make[3]: *** [osdep.o] Error 1
make[3]: Leaving directory `/export/home/xxx/Source/imap-2006j/c-client'
make[2]: *** [gso] Error 2
make[2]: Leaving directory `/export/home/xxx/Source/imap-2006j/c-client'
make[1]: *** [OSTYPE] Error 2
make[1]: Leaving directory `/export/home/xxx/Source/imap-2006j'
make: *** [gso] Error 2

OpenSSL関連のパスが正しくないようです。
Makefileでパスを指定している箇所はすぐ見付かりました。そもそも"gso"の指定が間違っているのかもしれません。

対処方法としてはSSLTYPE=noneを指定することにしました。
SSLは今のところ使う予定が無いためです。

$ make gso SSLTYPE=none

uw-imapdのインストールは、make後に出来たimapdを/usr/local/sbinの下にコピーしただけです。

c-client.cf, cram-md5.pwdの作成し/etc/inetd.confに記述を追加しました。

# cat /etc/c-client.cf
I accept the risk for IMAP toolkit 4.1.
set new-folder-format mbx
set mail-subdirectory Mail
set disable-plaintext 0

# cat /etc/cram-md5.pwd
ユーザ名        パスワード

# cat /etc/inetd.conf |grep imap
imap   stream  tcp     nowait  root    /usr/sbin/tcpd   /usr/local/sbin/imapd

そして、inetdを再起動しました。

# pkill -HUP inetd

サーバOS変更と文字コードについて

以前書いたとおり、我が家でファイルサーバ・IMAPサーバとして使っているOSをPlamo Linux 4.2.1からDebian GNU/Linux 4.0に変更しました。


懸念事項として、Plamo Linux 4.2.1からDebian GNU/Linux 4.0の変更に伴い、日本語ファイル名やフォルダ名の文字コードに変更があったことです。
EUC-JPからUTF-8になりました。

2007年7月31日現在においては、保存される日本語ファイル名はPlamo Linux 4.2.1の環境で使用していたEUC-JPとなっています。
その環境で、クライアントで文字化けしないようにするための文字コードの変換作業については下記のとおりとなっています。
多分。

NFSでSambaと同様に文字コードの変換って出来ないのでしょうか？
「[linux-users:99504] NFSサーバーでEUCをShift-JISに変換してエクスポートできますか？」を読んだ感じでは出来なさそうですが・・・。
ちょっと調べてみたいです。

また、OSのデフォルトの文字コードが変わることによりどこまで影響が出るのか分かっていないので、こちらもちびちび調べたいと思います。

Zaurusファイルマネージャ

Zaurusのファイルマネージャの「Tree!Explorer QT Plus+」というのがあります。
シェアウェアで1,250円です。
これを購入してしまいした。


私は以前書いたとおりZaurusをクライアントとしてSambaサーバのフォルダをマウントしています。

Zaurus標準のファイルマネージャはシステム中のかなり限定された部分しか閲覧できませんので、Zaurus標準のファイルマネージャでSambaファイルシステムを参照するために/mnt以下にマウントポイントを作成し、/hdd3/Document以下にマウントポイントのリンクを作っていました。

しかし、そうすると何らかのタイミングでZaurusが勝手にSambaファイルシステム中のファイル(全体？)にアクセスしてしまう現象が発生していました。

動いているプロセスを見てみると、gzipとかが延々と動いており、killしてもまた別のgzipプロセスが動き出していました。

gzipを起動しているプロセスを特定すればなんとかなるのかも知れませんけど、そもそもPDAで"ps ax"して問題のプロセスを見つけ"kill"するなんて、普通の使いかたとはとても・・・。


もちろん上記の問題は私の操作や設定に問題があり、回避する方法もあるのかもしれませんが、別のファイルマネージャの導入も検討することにしました。


ネットで調べていたら「Tree!Explorer QT」というなかなかよさそうなのがありました。

これはシェアウェア版だけではなくフリー版もあったためちょっといじってみたところSambaファイルシステム中の日本語も問題なく表示出来ていました。

フリー版だと機能が限定されており、ファイルを選択して実行してもプラス版を買えみたいなメッセージが出てしまうため、シェアウェア版を購入しました。


下の画像はSambaファイルシステム領域を参照中のスクリーンショットです。

Zaurusの/hdd3/Document以下にあるファイルをSambaファイルシステム領域にコピーしてみましたが、普通にできました。
当り前ですけど。

ZaurusをNFSクライアントに

そういえばZaurusでNFSファイルシステムって使えるのかなと疑問に思い、確認してみた。

まずZaurus(SL-C3000)でNFSファイルシステムをサポートしているか確認する。
ちなみにスペシャルカーネルになっています。

[root@zaurus: zaurus]# cat /proc/filesystems
nodev   rootfs
nodev   bdev
nodev   proc
nodev   sockfs
nodev   tmpfs
nodev   shm
nodev   pipefs
        ext3
        ext2
        cramfs
nodev   ramfs
        minix
        vfat
        iso9660
nodev   nfs
nodev   smbfs
        ntfs
        jffs2
nodev   devpts

サポートしているみたい。

ところでJFSもサポートしているんだ。
使ってみようかな。


Zaurusの/etc/fstabに次の2行を追加。

xxx.xxx.xxx.xxx:/mnt/share/xxx  /mnt/julie  nfs  \ 実際は一行
     users,noauto,rw,hard,intr,nosuid  0 0
xxx.xxx.xxx.xxx:/mnt/share3/xxx  /mnt/elie  nfs  \ 実際は一行
     users,noauto,ro,hard,intr,nosuid  0 0

追加したのはVine Linux 4.1とまったく同じ内容。


マウントポイントとするディレクトリを作成。

[root@zaurus: zaurus]# mkdir /mnt/julie
[root@zaurus: zaurus]# mkdir /mnt/elie

そして、マウント。

[root@zaurus: zaurus]# mount /mnt/julie
unknown nfs mount option: users
mount: nfsmount failed: Success
mount: Mounting xxx.xxx.xxx.xxx:/mnt/share/xxx
   on /mnt/julie failed: Invalid argument

ものの見事に失敗。

usersオプションが無いということなので、/etc/fstabの記述をusersを取り除いたものに変更。

xxx.xxx.xxx.xxx:/mnt/share/xxx  /mnt/julie  \ 実際は一行 
     nfs  noauto,rw,hard,intr,nosuid  0 0
xxx.xxx.xxx.xxx:/mnt/share3/xxx  /mnt/elie  \ 実際は一行 
     nfs  noauto,ro,hard,intr,nosuid  0 0

で、マウント。

[root@zaurus: zaurus]# mount /mnt/julie
[root@zaurus: zaurus]#

今度は成功。


使ってみた感想ですが、SL-C3000標準のファイルマネージャーでNFS領域に入って移動していると、すぐにフリーズしてしまう気が・・・。
設定が悪いのかな。

NFS領域の日本語フォルダ名が含まれる箇所で落ちてしまうのです。
もちろん日本語フォルダはたまたまかも知れません。
まだ検証できていません。

PCからtelnetでZaurusにログインした場合は、問題なく日本語読めているのですけど。

[zaurus@zaurus: WallPaper2]$ ls
008-m.jpg  kekkonn_dekinai_otoko  nestle             soranokiseki
Zaurus     koushien                satomihakkenndenn  ファルコム

もともとNFS領域をファイルマネージャーで参照する気はなかったですし、telnet接続してコマンドラインでの作業は問題なく出来ているので、とりあえずはいいのですけど。

後でもうちょっと検証してみます。

NFSについて調べる(セキュリティ)

「NFSについて調べる(クライアント側)」の続きです。

サーバ側
・NFSは賢くない
JFの文書には次のようにあります。

再び例を: bob はサーバでユーザ ID 9999 にマップされているとしましょう。 ボブはサーバでユーザのみがアクセスできるファイル を作ります (chmod 600 filename と入力するのと同じです)。 そのファイルが保存されたドライブへのアクセスを、 あるクライアントが許可されました。 そのクライアントでは、ユーザ ID 9999 には mary がマップされています。 この場合、bob が自分にしかアクセスできないようにしたファイルに対して、 そのクライアントでのユーザ mary がアクセスできてしまいます。 さらに悪いことに、そのクライアントで誰かがスーパーユーザになってしまうと、 その誰かは su - username によって どんな ユーザにもなれてしまうのです。 NFS は賢いとは言えません。

・クライアントのrootは信用するな
root_squashオプションを使う。

これはデフォルトで有効であり、うちのNFSサーバ(JULIE)でも有効になっている。

julie:~# exportfs -v
/mnt/share3/xxx
    xxx.xxx.xxx.xxx/xxx.xxx.xxx.xxx(ro,wdelay,root_squash)
/mnt/share/xxx
    xxx.xxx.xxx.xxx/xxx.xxx.xxx.xxx(rw,wdelay,root_squash)

JFの記述から。

root_squash の状態では、クライアントで UID 0 (root のユーザ番号) のユーザがファイルにアクセス (read, write, delete) しようとすると、 サーバは UID をサーバにおける 'nobody' アカウントのものと置き換えます。 つまりサーバの root だけにアクセスや変更が許されているファイルに対して、 クライアントの root がアクセスや変更を行うことができなくなるのです。

実験。
クライアントの操作。
カレントディレクトリはNFSファイルシステム上。

$ su
パスワード(P):
# touch aaa
# ls -l aaa
-rw-r--r-- 1 65534 65534 0  7月19日 01:27 aaa

サーバで確認。

# ls -l aaa
-rw-r--r--  1 nobody nogroup 0 Jul 19 01:27 aaa
# id nobody
uid=65534(nobody) gid=100(users) groups=100(users)
# cat /etc/group|grep nogroup
nogroup::65534:

重要なバイナリやファイルの所有者はbinなどではなくrootにすることが重要らしい。
root以外にすると、クライアント側のrootがサーバ側のバイナリやファイルの所有者idのユーザになって書き換えることが出来るから。


クライアント側
・suidプログラムを動作させない
nosuidオプションを使う。

JFの文書には次のようにある。

こうするとサーバの root ユーザが件のファイルシステムに suid-root プログラムを作り、クライアントに一般ユーザとしてログインし、 その suid-root プログラムを使ってクライアントでも root になる、 ということができなくなります。 さらに noexec オプションをつければ、 マウントしたファイルシステムでのファイルの実行を禁止することもできます。

noexecオプションを使えば、マウントしたファイルシステムのファイルを実行することができなくなるらしい。

NFSについて調べる(クライアント側)

「NFSについて調べる(サーバ側)」の続きです。

クライアント側のことを調べます。

・サポートしているファイルシステムを調べる
/proc/filesystemを見ればいいみたいです。

$ cat /proc/filesystems
nodev   sysfs
nodev   rootfs
nodev   bdev
nodev   proc
nodev   binfmt_misc
nodev   sockfs
nodev   usbfs
nodev   pipefs
nodev   futexfs
nodev   tmpfs
nodev   inotifyfs
nodev   eventpollfs
nodev   devpts
        reiserfs
        ext3
        ext2
        cramfs
        squashfs
nodev   ramfs
nodev   hugetlbfs
        iso9660
nodev   mqueue
        vfat
nodev   autofs
nodev   rpc_pipefs
nodev   nfs
nodev   nfs4

NFSクライアント(SALIE)ではNFSをサポートしてようです。

ちょっと気になっていたのですが、Vine Linux 4.1のデフォルトカーネルは、/proc/filesystemを見る限りではJFSやXFSをサポートしていないように思えます。
多分。


NFSクライアント側の/etc/fstabにはNFSマウントように次の行を追加しています。

xxx.xxx.xxx.xxx:/mnt/share/xxx /mnt/julie
    nfs     users,noauto,rw,hard,intr  0 0 (実際は一行)

使用しているマウントオプション(hard)は、JFには次のようにありました。

hard

NFS マウントされたファイルシステム上のファイルにアクセスしている プログラムは、サーバがクラッシュすると宙ぶらりんになります。 これらのプロセスは intr を一緒に指定していない場合は、中断することも kill することもできなくなります ("sure kill" を使えば別)。 NFS サーバが復活すると、プログラムはそれぞれ何もなかったかのように再開します。 おそらくこちらが望ましい場合が多いでしょう。全ての NFS マウントには、hard,intr を用いることをお勧めします。

intrはNFSのマニュアルに次のようにありました。

intr

NFS へのファイル操作がメジャータイムアウトとなり、かつその NFS 接続が hard マウントされている場合、シグナルによるファイル操作の中断を許可 し、中断された場合には呼び出したプログラムに対して EINTR を返す。
デフォルトではファイル操作の中断を許さない。

「NFSについて調べる(セキュリティ)」に続く。

NFSについて調べる(サーバ側)

JFの「Linux NFS-HOWTO」を読んで、NFSについて調べてみたことのメモ。

まずはサーバ側のこと。

・NFS が動作しているか確認する

julie:~# rpcinfo -p
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100005    1   udp    729  mountd
    100005    1   tcp    732  mountd
    100005    2   udp    729  mountd
    100005    2   tcp    732  mountd
    100005    3   udp    729  mountd
    100005    3   tcp    732  mountd
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100021    1   udp   1026  nlockmgr
    100021    3   udp   1026  nlockmgr
    100021    4   udp   1026  nlockmgr
    100021    1   tcp   1079  nlockmgr
    100021    3   tcp   1079  nlockmgr
    100021    4   tcp   1079  nlockmgr
    900101    1   udp    834
    900101    2   udp    834
    900101    1   tcp    837
    900101    2   tcp    837

また、rpcinfoコマンドと引数"-p"はマニュアルには次のようにあります。

rpcinfo は、 RPC サーバに対して RPC 呼び出しを行い、得られた情報を表示する。

-p
host の portmapper を検出し、そこに登録されている全ての RPC プログラムの一覧を表示する。 host が指定されていない場合、 hostname(1) で返される値がデフォルトになる。

うちのNFSサーバ(JULIE)ではversion 2〜4のNFSが動いているみたいです。

・/etc/exports をあとから変更する
nfsd に /etc/exports ファイルを読み直させるために"exportfs -ra"コマンドを実行する。

exportfsコマンドのマニュアルには次のようにあります。

exportfs コマンドは、現在 NFS でエクスポートしているファイルシステムのテーブルを管理するために使うコマンドである。このリストは /var/lib/nfs/xtab という名前のファイルに保存される。

また、オプション"r"と"a"は次のようにあります。

-a
全てのディレクトリをエクスポート・アンエクスポートする。

-r
全 てのディレクトリを再エクスポートする。 /var/lib/nfs/xtab を /etc/exportsと同期させる。 /etc/exports から削除されたエントリを /var/lib/nfs/xtab からも削除し、既に無効になったエントリをカーネルのエクスポートテーブルから削除する。

「NFSについて調べる(クライアント側)」に続く。

日本語文字化けをどうにかする その４

「日本語文字化けをどうにかする　その３」の続きです。

前回まででNFSクライアントであるVine Linux 4.1では文字化けを解消できましたが、Windows PCからのアクセスを確認していません。

SambaサーバのPlamo Linux(ホスト名 JULIE)がマウントしているReiserFS領域をWindowsで参照する際に文字化けするか確認し、問題があれば対応したいと思います。


「日本語文字化けをどうにかする　その１」で行ったのはNTFSファイルシステムをLinuxでマウントする際のオプションを変更しただけでファイルやフォルダをいじった訳ではないので問題ありません。

気になるのは、「日本語文字化けをどうにかする　その２」で行ったファイル名やフォルダ名をShift-JISからEUC-JPに変更してしまっている点です。

これをSambaでWindowsから参照できるようにした場合に、正常に読むことができるのでしょうか？


確認のため、「日本語文字化けをどうにかする　その２」で行った手順を再度行います。

(1) SALIE(NFSクライアント)からNFSマウントしたReiserFSファイルシステム上のファイル名・フォルダ名が文字化けしているのを確認。
Konquerorで確認します。

(2) convmvコマンドを使用してファイル名・フォルダ名をShift-JISからEUC-JPに変換。

$ convmv -r -f sjis -t euc-jp * --notest
mv "xxx/PDF/gZ"    "xxx/PDF/トラ技"
mv "xxx/Docs/Zaurus/J�txt"        "xxx/Docs/Zaurus/開発環境.txt"
mv "xxx/Pictures/WallPaper/t@R"    "xxx/Pictures/WallPaper/ファルコム"
mv "xxx/Movie/O/コピー ～ multimodal_arm.tar"
mv "ubN}[N/C莅lzh"      "ubN}[N/お気に入り.lzh"
mv "./ubN}[N"   "./ブックマーク"
Ready!

(3) SALIE(NFSクライアント)で文字化けしていないことを確認。
Konquerorで確認します。
化けていたのは「ブックマーク」というフォルダでした。

(4) Windows(Sambaクライアント)で文字化けしているかを確認。
やっぱり化けてました。


文字化けが発生していたため、JULIE(Sambaサーバ)の設定を変更することにより解決できないか検討します。

(5) Sambaの設定を変更。
smb.confの[global]に以下の記述を追加。

coding system = euc
client code page = 932

各設定値の説明はマニュアルにありました
マニュアルのcoding systemの項からの引用です。

coding system (G)

このパラメータは、 Samba が受けとった Shift-JIS の日本語文字を、 クライアントが使っているclient code pageから UNIX ファイルシステムのファイル名にどのように対応づけるかを指定する。 このパラメータは、client code page が932(日本語 Shift-JIS)の時のみ有効である。オプションは以下のとおり:

次にclient code pageの項からの引用です。

client code page (G)

このパラメータは、Samba にアクセスするクライアントが利用している DOS コードページを指定する。 Windows や DOS クライアントで利用されているコードページを確認するには、 DOS コマンドプロンプトを開いて、chcpコマンドを入力する。 これによりコードページが表示される。 USA 版の MS-DOS、Windows 95、Windows NT のデフォルトは 437 である。 西ヨーロッパ版のこれら OS のデフォルト値は 850 である。

(6) Sambaを再起動。
JULIE(Sambaサーバ)のsmbdとnmbdの両方を再起動しました。
両方再起動したのは念のためです。

(7) Windows(Sambaクライアント)で文字化けしているかを確認。

文字化けは解消されています。

(8) Windows(Sambaクライアント)が作成した日本語ファイル名・フォルダ名の確認。
Windows(Sambaクライアント)で作った日本語名のフォルダをJULIE(Sambaサーバ)へコピー。

(9) SALIE(NFSクライアント)でWindowsで作成した日本語名のフォルダを確認。
Konquerorで確認します。

OK!

文字化け対策はとりあえず一通り出来たかなと思います。
何か忘れていることはないかな？

日本語文字化けをどうにかする その３

「日本語文字化けをどうにかする　その２」の続きです。
ReiserFSファイルシステムでの文字化けについてです。

なお、多分重要な点として「Vine Linux 4.1はEUC-JPがデフォルトになっているらしい」ということがあります。
$ echo $LANG ja_JP.eucJP


NFSサーバのPlamo Linux(ホスト名 JULIE)がマウントしているReiserFS領域をVine Linux(ホスト名 SALIE)でNFSマウントした際の文字化けをなんとかしたいと思います。

私が使用しているのはReiserFSですが、ext2やext3でも同じではないでしょうか。
多分。
JFSやXFSはどうかな？


SALIE(NFSクライアント)のKonquerorでは次のように文字化けしていました。
ひどいありさまです。

行った対策は次の通りです。
・保存されているファイル名・フォルダ名の文字コードがShift-JISであるので、EUC-JPに変更する。
・ファイル名・フォルダ名の変更にはconvmvというツールを使用する。

convmvはSALIE(NFSクライアント)にインストールしました。
Vine Linuxにはconvmvが見つからなかったため、Fedora-JPのサイトからconvmv-1.10-2.fc6.src.rpmをいただいて、それをrpm --rebuildしました。

convmvはNFSサーバとクライアントのどちらにインストールして大丈夫ですが、書き込み権限は必要かと思います。


変換する際のコマンドは次の通りです。

$ convmv -r -f sjis -t euc-jp * --notest
mv "ﾙ@ﾙ@ﾙ~@/ﾙ~@.mdi"    "ﾙ~@/資産設計(2) 戦術編　10 万円ではじめる方法.mdi"
mv "ﾙ~@/ﾙ~@.pdf"        "ﾙ~@/資産設計(2) 戦術編　10 万円ではじめる方法.pdf"

～以下略～

この結果、SALIE(NFSクライアント)のKonquerorで正常に表示できるようになりました。



「日本語文字化けをどうにかする　その４」に続く。

日本語文字化けをどうにかする その２

「日本語文字化けをどうにかする　その１」の続きです。
まずはNTFSの方です。

なお、多分重要な点として「Vine Linux 4.1はEUC-JPがデフォルトになっているらしい」ということがあります。

$ echo $LANG
ja_JP.eucJP

NFSサーバのPlamo Linux(ホスト名 JULIE)がマウントしているNTFS領域をVine Linux(ホスト名 SALIE)でNFSマウントした際の文字化けをなんとかしたいと思います。

SALIE(NFSクライアント)のKonquerorでは次のように文字化けしていました。

行った対策は次の通りです。
・JULIE(NFSサーバ)でNTFSファイルシステムをマウントする際に文字コードを考慮する


文字化けしている際のJULIE(NFSサーバ)側のfstabの記述は次のようになっていました。

・変更前の/etc/fstabの記述

/dev/hda1  /mnt/share3  ntfs  defaults,umask=000  0  0

文字化け対策として、次のように記述しました。
オプションのroは、書き込み禁止を明示的に指定したくてついでに書いておきました。
・変更後の/etc/fstabの記述

/dev/hda1  /mnt/share3  ntfs  umask=000,nls=euc-jp,ro  0  0

mountのマニュアルのntfsの項には次のように書いてあります。

iocharset=name
ファイル名を返すときに用いる文字セット。 VFAT とは異なり、NTFS は変換できない文字を含む名前を抑制する。このオプションは推奨されない。

nls=name
以前は iocharset という名前であったオプションの新しい名前。

mountのマニュアルのvfatのオプションはfatと同様のものが多く、fatの項には次のように書いてありました。

iocharset=value
8ビットの文字を 16 ビットの Unicode 文字に変換する (あるいはその逆)ときに用いる文字セット (character set)。デフォルトはiso8859-1である。長いファイル名は、ディスクには Unicode フォーマットで保存されている。

JULIE(NFSサーバ)のfstabを変更後にSALIEでマウントすると、文字化けはとりあえず解消されたようです。
文字化けしていたのは「ファルコム」というディレクトリでした。


「日本語文字化けをどうにかする その３」に続く

日本語文字化けをどうにかする その１

最近はノートPCにインストールしたVine Linux 4.1でKDEを使っていることが多いです。

その際はWindowsXPマシンも同時に立ち上げ、WindowsXPのVMWareにインストールしてあるPlamo LinuxもWindowsXP起動と同時に立ち上げ、ファイルサーバなどとして使用することもあります。
(うちのネットワーク環境についてはこちら)

起動しているVineとPlamoのホスト名は次のようになっています。
Plamo Linux： JULIE
Vine Linux： SALIE


JULIEではファイル共有用のハードディスクを2台マウントして、NFSやSambaでローカルネットワーク上に開放しています。

ファイルシステムは1台はNTFS, もう1台はReiserFSです。

この2台のハードディスクに入っている日本語の名前がついたファイルやフォルダがSALIEのKDE Konquerorで見ると文字化けしてしまいます。
(ちなみにGNOMEのNautilusでは、Konquerorでは文字化けしているのに文字化けしないものもありました。)

この文字化けを、今さらながらなんとかしたいと思います。


結論から言うと、問題の対策は次の通りに行いました。

・NTFSファイルシステムの文字化け
　→ マウント時にオプション"nls=euc-jp"を指定する
　(「日本語文字化けをどうにかする その２」で検証)

・ReiserFSファイルシステムの文字化け
　→ ファイル名やフォルダ名をShift-JISからEUCに変更する
　(「日本語文字化けをどうにかする　その３」、「日本語文字化けをどうにかする　その４」で検証)



なお、数年前はPCを使用する際はLinuxを使用することが多かったのに、その際はほとんど問題になりませんでした。

その理由はこんな感じでしょうか。
・Linux上で自分が作ったファイルの名前に日本語でつけることは絶対にない。

・Windowsを使っている際も自分なりのファイル命名規則があった。
　それは、日本語ファイル名は使わないということ。
　しかし、しばらくLinuxを使用していない間に日本語ファイル名を使ってしまっていた。

・iTunesで作成した音楽ファイルに日本語名がついていることが多い。
　Linuxを常用している頃はcdparanoia + LAMEでMP3ファイルを作成していた。


NTFSとReiserFSでは行った対策が異なりました。
分けて記述しておきます。


「日本語文字化けをどうにかする　その２」に続く。

NFSの設定

VMwareで動かしているPlamo LinuxをNFSサーバにした時の設定手順です。
設定はJFのドキュメントを参考にしました。

本当はもっと詳細にドキュメントを読んでから設定を行わなければならないとは思いますが、とりあえずは使えるようにすることを目標にします。
マネしないでください。

(1) サーバ側(Plamo Linux on VMware)の設定
・/mnt/share/hoge をNFS共有ディレクトリとする
サーバのIPアドレスはxxx.xxx.xxx.xxxと仮定する。

(a) /etc/exportsに以下を追加
mnt/share/hoge xxx.xxx.xxx.0/255.255.255.0(rw,sync)

(b) /etc/hosts.deny に以下を追加
portmap:ALL
lockd:ALL
mountd:ALL
rquotad:ALL
statd:ALL

(c) /etc/hosts.allow に以下を追加
portmap: xxx.xxx.xxx.0/255.255.255.0
lockd: xxx.xxx.xxx.0/255.255.255.0
mountd: xxx.xxx.xxx.0/255.255.255.0
rquotad: xxx.xxx.xxx.0/255.255.255.0
statd: xxx.xxx.xxx.0/255.255.255.0

古いnfs-utilsを使っていた場合でも、lockd, mountd, rquotad, statdを追加しても問題にならないらしいのでとりあえず追加しておきました。
いいかげんです。

(d) nfsd に /etc/exports ファイルを読み直させる
# exportfs -ra


(2) クライアント側の設定
・/mnt/fugaにマウントする

(a)とりあえずmountコマンドで試してみる
# mount xxx.xxx.xxx.xxx:/mnt/share/hoge /mnt/fuga
# df
中略
xxx.xxx.xxx.xxx:/mnt/share/hoge 244188576 97894944 146293632 41% /mnt/fuga

成功しているらしい。

(b) (a)でマウントしたディレクトリをアンマウント
# umount /mnt/fuga

(c) /etc/fstab に以下を追加
xxx.xxx.xxx.xxx:/mnt/share/hoge /mnt/fuga nfs noauto,rw,hard,intr 0 0

(d) mountコマンドを実行
# mount /mnt/fuga
# df
中略
xxx.xxx.xxx.xxx:/mnt/share/hoge 244188576 97894944 146293632 41% /mnt/fuga

成功。

我が家のネットワーク

2007年7月14日現在の、我が家のネットワーク環境です。

うちでは2台のPCで3つのOSを同時に使用しています。

以下の括弧中はホスト名です。
PC
(a) タワー型PC
　OS: WindowsXP Professional (ELIE)

(b) ノートPC (WindowsとLinuxのデュアルブート)
　OS: WindowsXP Home Edition (SHIRO)
　OS: Vine Linux 4.1 (SALIE)

(a)のELIEではVMWare Serverを使用しております。

VMWareゲストOS
　OS: Plamo Linux (JULIE) Samba/NFS/IMAP

(a)のタワー型PCにはハードディスク3台を接続してます。
その内2台はWindowsXP(ELIE)で使用しておりますが、もう1台は全ての領域をReiserFSでフォーマットしており、JULIEでマウントしています。

このReiserFSの領域の多くはSamba/NFSを使用して開放され、JULIEはファイルサーバとなっています。


また、JULIEはプロバイダからfetchmailを利用してPOP3でメールを定期的に受信し、それを今度はIMAPサーバとしてローカルネットワーク上で公開しています。

おかげで(b)にインストールしてあるWindows(SHIRO)やLinux(SALIE)だけではなく、ZaurusやWindows Mobileマシンからでもメールを参照することが出来ます。