突然消失するかもしれないブログ

”とつきえブログ”

カテゴリーアーカイブ: Debian

玄箱ProでDebian squeeze/wheezyのアップデートする際の注意点

2011/03/11の震災で1台目の玄箱Proが故障してしまい、1年近く自宅にサーバーのない生活をしてきましたが、あまりに不便なため、2台目の玄箱Proを引っ張り出すことにしました。

2台目の玄箱ProにはDebian wheezyを自前でインストールしていたのですが、aptitude update; aptitude full-upgradeを実行して最新の状態にアップデートしたところ、悲しいことに正常に起動できなくなってしまいました。。

ブート時のエラーメッセージを見ると、udevが延々とエラーメッセージを吐いており、原因を調べてみたところ、Linuxカーネルが古く、カーネルのコンフィグが足らないせいのようです。

非公式のDebianインストーラを使用している限り、またこのような悲劇が起こるので、何か他の良い方法がないか探してみたところ、Debian本家が正式に玄箱Proに対応していることが判明しました。

玄箱ProでDebianをインストールする公式ガイドがあり、以下のサイトに従ってDebian公式インストーラでDebianをインストールすれば良いようです。

http://www.cyrius.com/debian/orion/buffalo/kuroboxpro/

非公式のDebianインストーラで玄箱ProにDebianをインストールしてしまうと、Debian本家のバージョンアップに追従するのが辛くて挫折しがちになりますが、Debian公式のインストーラでDebianをインストールすれば、安心して最新の状態にバージョンアップすることができるかもしれません。

ということで、近いうちに時間を見つけてセットアップしようと思います。(つづく)

 

広告

ThinkPadT42でDebian:Debian 6の電源管理の謎について

Linuxでの電源管理は、伝統的に、acpid, acpi-support-base, acpi-supportで行われているようですが、Debian 6のグラフィカルログイン環境では、gnome-power-managerによって電源管理が行われるようです。

つまり、acpiの設定をいくら行っても、gnome-power-managerの設定を行わないと反映されないというわけです。

Debian/etch で Gnome Power Managerをつかってサスペンドする の情報によると、

従来の場合は、すべてacpidで電源管理の処理が行われます。

(acpiのイベント)

=> acpid でフック

=> イベント種別から /etc/acpid/events 以下の設定でスクリプトを選択

しかし、グラフィカルログイン環境では、acpidで処理された後、gnome-power-managerで電源管理の処理が行われるようです。

(acpiのイベント)

=> acpid でフック

=> acpi-support パッケージにより、キーイベントに変換され、/dev/inputXに渡される。

=> Xサーバ君がキーイベントを受ける

=> gnome-power-manager がキーイベントを受け取り?、    ディスクトップのユーザ設定に応じて処理を決めて、    サスペンド/ハイバネーションの要求を〜する。

ということで、Debian 6でgnomeのグラフィカルログイン環境での電源管理は、acpidだけではなく、gnome-power-managerでも管理されているということを理解する必要があります。

詳しくは以下をご覧下さい。

ThinkPadT42でDebian:リッドクローズドモードで使う

 

ThinkPadT42でDebian:リッドクローズドモードで使う

Debian 6をインストールしたThinkPad T42はサーバとして使用したいので、液晶画面は閉じた状態でも電源がONの状態で使える、リッドクローズドモードの設定を行います。

Debian 6のグラフィカルログインには落とし穴がある。

Debian 6をグラフィカルログイン環境でインストールすると、ログイン後の状態では液晶画面を閉じてもサスペンドしないのに、ログイン前の状態のログイン画面で液晶画面を閉じるとサスペンドしてしまう、という現象が起きます。

原因は、gnome-power-managerというプロセスです。

ログイン前の状態では、gdm3のユーザIDである、Debian-gdm(UID=106)でgnome-power-managerが実行されますが、ログイン後の状態ですは、ログイン時のユーザIDで実行されます。

gnome-power-managerは、”電源管理の設定”というアプリケーションで設定した設定ファイルを参照しますが、Debian-gdm(UID=106)には、その設定が反映されていないのが原因です。

では、どうすれば、Debian-gdm(UID=106)にも電源管理の設定を反映させることができるのかと言うと、”電源管理の設定”のウィンドウの下に「デフォルト値」にする」というボタンがありますので、これをクリックします。

”デフォルト値にする”のボタンの意味は、システム全体で共通の設定値を設定するということです。

NewImage

”電源管理の設定”は、gconfによって設定ファイルを保存しており、システム全体で共通の設定値として保存した場合は、以下のファイルに設定値が保存されます。

○デフォルト値が保存される場所

/etc/gconf/gconf.xml.defaults/%gconf-tree.xml

ちなみに、各ユーザの個別の設定値は、ログインしたユーザIDのホームディレクトリ配下の ~/.gconf/apps/gnome-power-manager/%gconf.xml に保存されます。

NewImage

すると上記のように、”lid_ac”が”blank”、つまり、液晶画面が閉じられた時は、サスペンドせずに液晶画面をブランク(液晶画面の電源をOFFにして真っ暗)にするという設定になります。

これで、ログイン前の状態のログイン画面で液晶画面を閉じてもサスペンドしなくなります。

めでたし、めでたし。

 

 

ThinkPadT42でDebian:Debian 6のインストール

ThinkPad T42に最後の一働きをしてもらうため、Debian 6 squeezeをインストールしてみました。

Pentium-M 1.8GHz、メモリ2GBなのでできることは限られますが、それでも玄箱Pro(ARM9 400MHz, メモリ128MB)に比べれば快適です。

(1)Debian 6のインストールCDイメージ(isoイメージ)をDLする。

ThinkPad T42はUSBメモリからブートすることができないので、Debian 6のインストールCDイメージ(isoイメージ)をDLし、CD-R、ないしは、DVD-Rに焼いて、そのメディアからブートします。

http://www.debian.org/distrib/netinst#smallcd

今回は、上記のネットワークから必要なファイルを適宜DLしながらインストールする”小さなCD”というイメージを使いました。

これならCD-R、あるいは、DVD-R一枚で済みます。焼いたメディアは緊急用のメンテナンスディスクとしても使えるので、インストールが終わったら大事にとっておきましょう。

最近のLinuxのディストリビューションは64bit版がメインになっているため、DLするときは、64bit版(amd64)ではなく、32bit版(i386)のイメージが必要です。(ThinkPad T42のPentium-Mは、32bit CPUです。)

※ちなみに、ThinkPad T42で間違って64bit版(amd64)のイメージでブートしてみたところ、途中まではブートしますが、ハングアップしてしまいます。。

ThinkPad T42のCD/DVDドライブがへたっている場合は、外付けのUSB CD/DVD-ROMドライブからでもブートできます。

(2)光学メディアからブートする。

ThinkPad T42のBIOSの設定で、起動順が、HDDよりも先に、内蔵のCD/DVD-ROMドライブ、外付けUSB CD/DVD-ROMドライブが来ていることを確認して、いよいよインストールを開始します。

(3)インストールする。

ネットワークから必要なファイルを適宜DLしながらインストールするので、通信状況やサーバの状況によって変わってきますが、インストールが完了するのに結構時間がかかるので、気長に待ちましょう。

P.S

玄箱Proでは、開発版の次期Debian 7 wheezyを使用していましたが、アップデートが頻繁に行われるため、追従するのが大変なので、今回はおとなしくリリース版のDebian 6にしています。(^_^;)

 

Debianで「入手不可能なパッケージは修正できません」と表示された場合の対処方法

Debian 6 squeezeのVMwareの仮想マシンイメージを8ヶ月ぶりぐらいに起動して、aptitude full-upgradeもsafe-upgradeを実行したら「入手不可能なパッケージは修正できません」と表示されてアップデートできない状態に陥っていました。


先に進みますか? [Y/n/?] y
拡張状態情報を書き込んでいます… 完了
エラー http://ftp.us.debian.org squeeze/main openssl 0.9.8o-4
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main cups-ppdc 1.4.4-7
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main libcups2 1.4.4-7
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main python 2.6.6-3+squeeze4
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main notification-daemon 0.5.0-2
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main whois 5.0.10
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main libxmuu1 2:1.0.5-2
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main acpi-support 0.137-5
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main alsa-utils 1.0.23-3
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main libesd0 0.2.41-8
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main ijsgutenprint 5.2.6-1
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main python-imaging 1.1.7-2
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main libhpmud0 3.10.6-1.1
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main libapr1 1.4.2-6
  403  Forbidden
エラー
http://ftp.us.debian.org squeeze/main libaprutil1 1.3.9+dfsg-5
  403  Forbidden
E: http://ftp.us.debian.org/debian/pool/main/o/openssl/openssl_0.9.8o-4_i386.deb を取得で きませんでした: 403  Forbidden
E: 入手不可能なパッケージは修正できません
パッケージリストを読み込んでいます… 完了
依存関係ツリーを作成しています
状態情報を読み取っています… 完了
拡張状態情報を読み込んでいます… 完了
パッケージの状態を初期化しています… 完了
拡張状態情報を書き込んでいます… 完了
タスクの記述を読み込んでいます… 完了

すでにインストール済みのパッケージが、依存するパッケージもアップデートしようとしているが、最新のパッケージでは不要になったため、リポジトリからそれらの依存するパッケージが削除されたのが原因のようです。

では、解決法はというと、上の太い青字の部分を手がかりにしてパッケージ毎に個別にアップデートしながら問題が解決されるまで試行錯誤を繰り返します。

aptitude install libaprutil1
aptitude install libapr1
aptitude install libhpmud0

今回は、上記のようにインストール済みのパッケージの個別のアップデートを繰り返していき、いつの間にかaptitude full-upgrade、safe-upgradeが正常に実行できるようになりました。

ちなみに、Debian 7.0 wheezyのテスト版はリリースされていないみたいですね。

BeagleBoard:(11)Debianインストール2

BeagleBoard上にDebianをインストールする方法についてです。

(1)主な情報源
BeagleBoardDebian – eLinux.org

こちらの手順に従い、ネットインストールでDebianをインストールします。

(2)シリアルコンソールの準備

開発用PCとBeagleBoardをシリアルのクロスケーブルで接続して、BeagleBoardを操作します。

ここでは、開発用PCとしてDebian5、通信用ソフトとしてkermitを使用します。

<kermitの通信設定>

kermitを起動して、以下のコマンドを実行して通信設定を行います。

都度、入力するのは大変なので、~/.kermrcに以下を記述しておけば自動設定されます。

尚、BeagleBoardのシリアルではフロー制御が行われないので、通信データを取りこぼさないように適度にディレイを入れる必要があります。

set line /dev/ttyUSB0
set speed 115200
set flow-control none
set carrier-watch off
set delay 1

上記の通信設定をした後、connectコマンドを実行して、何回かリターンキーを押すと、開発用PCとBeagleBoardの間で同期がとられて、正常に通信できるようになります。

connect

kermitを抜けたい場合は、以下のキーを入力します。

ctrl ¥ c

(3)BeagleBoard用のuImage(Linuxカーネルイメージ)、Debianインストール用のinitrdを取得してmicroSDに書き込む。

microSD上に最低でも3つのパーティションが必要になります。

パーティション1(/dev/mmcblk0p1):VFAT(uImage, initrd)
パーティション2(/dev/mmcblk0p2):Linux swap
パーティション3(/dev/mmcblk0p3):Linux(rootファイルシステム)

インストール時はパーティション1だけ作成すれば、あとはDebianのインストーラが作成してくれます。

ブートローダは、BeagleBoardのNANDに書き込まれているものをそのまま使いますので、microSDに書き込む必要はありません。

パーティション1のルートディレクトリにuImageとuInitrdを書き込みます。

# BeagleBoardにDebianをインストール際に利用できるuImageは若干古いバージョンのLinuxカーネルになりますが、Debianをインストールした後、自由にバージョンアップすることができます。
wget http://rcn-ee.net/deb/kernel/CC-beagle-v2.6.29-58cf2f1-oer44.1.uImage
mv CC-beagle-v2.6.29-58cf2f1-oer44.1.uImage uImage

# Debianは安定版のlennyをインストールして、lennyをインストールした後、Squeezeなどにバージョンアップすることができます。
wget http://ftp.debian.org/debian/dists/lenny/main/installer-armel/current/images/versatile/netboot/initrd.gz
gzip -d initrd.gz
dd if=initrd of=uInitrd ibs=8388608 conv=sync

(4)BeagleBoardのu-Bootを設定する。

Debianインストール時は、u-Bootの画面で以下のように設定、実行します。

setenv bootcmd ‘mmc init; fatload mmc 0:1 0x80300000 uImage; fatload mmc 0:1 0x81600000 uInitrd; bootm 0x80300000’
setenv bootargs ‘console=ttyS2,115200n8 ramdisk_size=8192 root=/dev/ram0 rw rootfstype=ext2 initrd=0x81600000,8M’
saveenv
boot

Debianインストール後は、上記の設定のうち以下のように変更します。

setenv bootargs ‘console=ttyS2,115200n8 root=/dev/mmcblk0p3 rootwait rootfstype=ext3 ro’
saveenv

Debianインストール後に、BeagleBoardのHDMI端子経由でHDMI/DVI出力したい場合は、上記の設定のうち、以下のように変更します。

<解像度が1280×720、色深度が16bitの場合>
setenv bootargs ‘console=ttyS2,115200n8 root=/dev/mmcblk0p3 rootwait rootfstype=ext3 ro omapfb.mode=dvi:1280x720MR-16@60’

<解像度が1280×720、色深度が24bitの場合>
setenv bootargs ‘console=ttyS2,115200n8 root=/dev/mmcblk0p3 rootwait rootfstype=ext3 ro omapfb.mode=dvi:1280x720MR-24@60’

<解像度が1440×900、色深度が16bitの場合>
setenv bootargs ‘console=ttyS2,115200n8 root=/dev/mmcblk0p3 rootwait rootfstype=ext3 ro omapfb.mode=dvi:1440x900MR-16@60’

<解像度が1440×900、色深度が24bitの場合>
setenv bootargs ‘console=ttyS2,115200n8 root=/dev/mmcblk0p3 rootwait rootfstype=ext3 ro omapfb.mode=dvi:1440x900MR-24@60’

(5)Debianインストーラを起動する。

上記で用意したmicroSDをBeagleBoardにセットしてリセットするだけで、Debianインストーラが起動し、画面の指示に従って行けば、必要最小限のDebianがインストールされます。

尚、DHCPでUSBイーサネットアダプタにIPアドレスが割り振られるはずなのですが、なぜかうまくいかないので手動で設定する必要があるようです。

<参考:BeagleBoardのu-Bootの工場出荷時の設定>

bootcmd=if mmc init; then if run loadbootscript; then run bootscript; else if run loaduimage; then run mmcboot; else run nandboot; fi; fi; else run nandboot; fi
bootdelay=10
baudrate=115200
loadaddr=0x82000000
console=ttyS2,115200n8
vram=12M
dvimode=1024x768MR-16@60
defaultdisplay=dvi
mmcroot=/dev/mmcblk0p2 rw
mmcrootfstype=ext3 rootwait
nandroot=/dev/mtdblock4 rw
nandrootfstype=jffs2
mmcargs=setenv bootargs console=${console} vram=${vram} omapfb.mode=dvi:${dvimode} omapfb.debug=y omapdss.def_disp=${defaultdisplay} root=${mmcroot} rootfstype=${mmcrootfstype}
nandargs=setenv bootargs console=${console} vram=${vram} omapfb.mode=dvi:${dvimode} omapfb.debug=y omapdss.def_disp=${defaultdisplay} root=${nandroot} rootfstype=${nandrootfstype}
loadbootscript=fatload mmc 0 ${loadaddr} boot.scr
bootscript=echo Running bootscript from mmc …; source ${loadaddr}
loaduimage=fatload mmc 0 ${loadaddr} uImage
mmcboot=echo Booting from mmc …; run mmcargs; bootm ${loadaddr}
nandboot=echo Booting from nand …; run nandargs; nand read ${loadaddr} 280000 400000; bootm ${loadaddr}
stdin=serial
stdout=serial
stderr=serial
bootargs=console=ttyS2,115200n8 vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapfb.debug=y omapdss.def_disp=dvi root=/dev/mtdblock4 rw rootfstype=jffs2

Environment size: 1310/131068 bytes

Debian Squeezeの最新状況(2010/05/16)

数日ほど前にDebian Squeezeが大幅にアップデートされました。

今回のアップデート内容から、Debian Squeezeの正式リリース時は、IPv6がデフォルトで有効になるのかもしれません。

確認できた大きなアップデート内容は以下の通りです。

(1)netatalk2.1

netatalkが2.1にバージョンアップされました。

ii  netatalk                          2.1-1                      AppleTalk user binaries

netatalk 2.1 (安定版) 対応状況:HAT:So-net blog

Snow Leopardのバグにより、netatalk 2.0.xに接続すると問題が発生するので、2.1をおすすめします。

詳細は、HATさんのエントリーを参照していただくとして、Snow Leopardからnetatalk2.1の共有フォルダへのアクセス速度がかなり改善されたような気がします。

アップデート後に注意が必要なのが、Mac OS X Snow Leopardでafpdサーバに接続できない(解決編) « 突然消失するかもしれないブログの「(2-2).AppleDBディレクトリ以下をすべて削除する。」の作業が必要です。でないと、Snow LeopardからアクセスするとFinderがフリーズしてしまいます。

・共有フォルダの「.AppleDB」以下を削除する。

# find “afpdの公開フォルダとして指定しているディレクトリ” –name “.AppleDB” –print –exec rm –rf {} \;

・/etc/netatalk/AppleVolumes.defaultを再設定する。

:DEFAULT: maccharset:MAC_JAPANESE volcharset:UTF8 options:usedots,upriv dperm:0700 fperm:0600 cnidscheme:dbd

 

(2)squid3.1.1

squid3が3.1.1にバージョンアップされましたが、IPv6が有効になっていない環境ではsquid3.1.1が正常に動作しません。

原因は、Debian Squeezeのデフォルトの設定ではIPv6が無効にされているのに対して、squid3.1.1のパッケージがIPv6のオプションを有効にしてビルドされているためです。

当面、squid2.xかsquid3.0を使用することをオススメします。

具体的には、

Re: [squid-users] Squid-3.1: comm_open: socket failure : (97) Address fa

You have IPv6 disabled in your system somehow.

Squid opens IPv4/IPv6 hybrid sockets to receive and send both v4 and v6
traffic in one socket for simplicity and ease of transition. If that fails
like in your case it falls back to IPv4-only sockets.

I recommend re-enabling IPv6 socket capability in your OS.

squid3.1からIPv6がサポートされるようになり、IPv4/IPv6のハイブリッドソケットにより、IPv4とIPv6の通信を送受信するようになりました。

squid3.1はデフォルトではIPv6サポートが有効になった状態でビルドされるため、IPv6サポートを無効にするには、ビルド時のconfigureのオプションで、以下のオプションを指定する必要があります。

–disable-ipv6          Disable IPv6 support

BeagleBoard:(10)USBが不安定な原因が判明

以前、BeagleBoard Rev C4のUSBが不安定だと書きましたが、電力供給不足が原因だったようです。HighSpeed USB2.0 EHCIポートは不安定ですが、mini-USBポートであれば安定して使用できることがわかりました。

BeagleBoard:(8)USBが不安定? « 突然消失するかもしれないブログ

BeagleBoardのACコネクタに5V/1Aの電源を供給してみたところ、嘘のようにmini-USBポート、HighSpeed USB2.0 EHCIともにを使用してみたところ、USBが安定して使用できるようになり、快適にDebian Squeezeが動作するようになりました。

BeagleBoardは、mini-USBからの電力供給だけでは電力が不足するらしく、セルフパワーのUSB-HUBを使用していてもUSB機器を安定して使用することができないようです。

BeagleBoardは、状況によって1Aくらいの電流を要求するのかもしれません。

遠回りしましたが、ようやく安定してBeagleBoardが使用できるようになりました。大きな山を1つ越えたかなという感じです。

<追記:2010/05/01

半日ほど負荷試験を兼ねてHighSpeed USB 2.0 EHCIのポートを使ってみたのですが残念ながら死んでしまいました。シールド対策が不十分なのが原因なのでしょうか。。。

一応、連続して安定して使用できる時間が数分から数時間に伸びたので若干改善したことにはなるのですが。

現在、mini-USBのポートに切り替えて負荷試験中です。

ハードの問題なのか、ソフト(Linuxカーネル)の問題なのかよくわからなくなってきました。

追記:2010/05/01>

<追記:2010/05/02

apache benchを使用して、BeagleBoardに接続されたUSB-Ethernetのネットワーク負荷試験を数時間しかけてみましたが、mini-USBのポートが死ぬことはありませんでした。

BeagleBoardのHighSpeed USB2.0 EHCIポート周りは、やはり設計不良があるのかもしれません。

追記:2010/05/02>

 

BeagleBoard:(8)USBが不安定?

BeagleBoard Rev C4にLinux2.6.28.9(http://rcn-ee.net/deb/kernel/CC-v2.6.28.9-79d042a-oer17)、Debian lenny(最新にアップデート)をインストールした環境で、しばらく使用していると、突然、ネットワークの通信速度が遅くなり、全く通信できなくなるという症状が発生します。

シリアルは生きているのでシリアル経由で確認してみると、以下のメッセージが延々と出力され続けます。こうなるとrebootするしかなくなります。

この投稿の続きを読む

Mac OS X Snow Leopardでafpdサーバに接続できない(解決編)

Mac OS X Snow Leopardでafpdサーバに接続できない(未解決編) « 突然消失するかもしれないブログ」で書きましたが、原因が明らかになり、解決しましたのでメモ。

(1)原因

原因は大きく2つあります。

原因1:

Debian Squeezeにおいて、2010年2月に入ってからのバージョンアップにより、netatalkのパッケージ、

ii  netatalk                          2.0.5-3                    AppleTalk user binaries

が依存するファイル群と整合がとれなくなり、暗号化パスワード認証(DHX2)でのPAM認証が正常に行えないため、ユーザ認証が失敗してしまいます。

Debian Squeezeのパッケージのバグのようです。

Bug#568601: netatalk: PAM DHX2: libgcrypt versions mismatch

原因2:

ユーザ認証に成功しても、CNIDデータベース(.AppleDB)のバージョンの不整合が発生しているため、Mac OS X Snow LeopardのFinderの接続が失敗してしまいます。

尚、CNIDが何かについては、HATさんのHPにある「CNIDの管理」が参考になります。

netatalk and samba

MacOSの為に作られたHFS+というファイルシステムでは、ファイルやフォルダにCNID (Catalog Node ID)と呼ばれる番号を付けて管理しています。これはAFPの場合も同様です。
netatalkでは、Berkeley DBを使って .AppleDB/というディレクトリでCNIDのデータベースを管理しています。 何らかの理由でこのディレクトリの中のファイルが壊れると、クライアントからうまく接続出来ないといったトラブルが発生します。

で、HFS+の拡張属性(EA:Extended Attribute)とアクセスコントロールリスト(Access Control List)に関する情報は以下が詳しいです。

Undocumented Mac OS X:第11回 HFS Plus独自の機能【後編】 (2/2) – ITmedia エンタープライズ

Tigerで追加されたのが、拡張属性(Extended Attribute)とアクセスコントロールリスト(Access Control List)だ。

簡単に説明すると、ファイル名やパーミッション、作成日時や更新日時、所有者とグループといった、あらかじめ決められた属性以外に、ファイルの内容により即した属性をユーザーやアプリケーションが自由に割り振れるようにするというのがEAである。また、これまでの所有者、グループ、それ以外に読み、書き、実行を割り振るという大雑把なパーミッションに対して、指定ユーザーやグループに対して個々にアクセス権を割り振るという、より詳細なアクセスコントロールを実現するのがACLだ。

(2)解決方法

(2-1)netatalkのパッケージをソースコードから再ビルドして再インストールする

以下の手順を参考に作業をしていきます。

APT HOWTO (Obsolete Documentation) – ソースパッケージでの作業

apt-get を使ってソースから deb パッケージを作成してインストールする – make world

1.  build-essential のインストール(初回のみ)
2. 依存関係の確認
3. 依存関係にあるパッケージの用意
4. インストールするパッケージのソースを取得する
5. ソースコードから生成された deb パッケージをインストールする

具体的な手順は以下の通りです。

## まず、インストール済みのnetatalkのパッケージをアンインストールします。purgeすると設定ファイルもすべて削除されるのでバックアップを忘れずに。
# apt-get purge netatalk

## 開発環境のインストール
# apt-get install build-essential

## 依存するパッケージをインストールする
# apt-get build-dep netatalk

## インストールするパッケージのソースを入手してビルドする。玄箱Proのセルフビルド環境だとビルドするのに結構時間がかかりますので、ビルドが終わるのを気長に待ちましょう。
# apt-get -b source netatalk

## 生成されたdebパッケージをインストールする
# dpkg -i netatalk_2.0.5-3_armel.deb

(2-2).AppleDBディレクトリ以下をすべて削除する。

afpdの公開フォルダとして指定しているディレクトリにある.AppleDBディレクトリ以下をすべて削除します。

自動で一気に削除したい場合は、以下を実行します。

尚、findのオプションの指定方法を間違えると、.AppleDB以外の重要なファイルまできれいさっぱり消えてしまうこともありますので、実行するときはしっかり確認してから、慎重に行ってください。(あくまで自己責任で)

# find “afpdの公開フォルダとして指定しているディレクトリ” –name “.AppleDB” –print –exec rm –rf {} \;

また、おまけですが、HATさんのnetatalk and sambaを参考にして、

/etc/netatalk/AppleVolumes.defaultに以下を追記します。

:DEFAULT: maccharset:MAC_JAPANESE volcharset:UTF8 options:usedots,upriv dperm:0700 fperm:0600 cnidscheme:dbd

これにより、「cnidscheme:dbdを指定するとnetatalkの信頼性(.AppleDBの信頼性)が高まります。」とのことです。

尚、「maccharset:MAC_JAPANESE」については、afpdにパッチがあたっていない場合は指定できないので、ディストリビューションの状況に応じて調整します。
(Debian SqueezeではOK、Ubuntu9.0.4ではNGでした。)

更に、/etc/default/netatalkの設定を以下のように変更します。

CNID_METAD_RUN=yes

というのは、HATさんのnetatalk and sambaにあるとおり、CNIDデータベース(.AppleDB)の管理をcnid_metadデーモンに一元的にまかせてしまうと、信頼性が上がるようです。(BerkeleyDBって複数のプロセスから同時アクセスがあった場合、きちんと排他制御していないのでしょうか?)

cnidscheme:dbd
かなり安定している。cnid_metadデーモンがデータベースを一括管理する。各afpdはcnid_metadと通信するだけ。

(3)まとめ

netatalkは、需要と供給の問題のせいか、sambaほど開発が活発ではないような印象を受けますし、Debianプロジェクトでもあまり重視されているとは思いがたいので、よほど特別な理由がないかぎり本番環境では、sambaを使った方が無難そうです。特に、Windows環境とMac OS X環境との相互運用を考えるとsambaが無難ですかね。

最近では、Finderからsambaも快適に使えるようになってきているので、古いMac製品を持っている方は別としても、netatalkを使用する強い理由も見あたらないような気がします。

それでも、腕に覚えがあって、労力を惜しまない方は、netatalkとsambaを併用するのも悪くはないかなと思います。

%d人のブロガーが「いいね」をつけました。