Ubuntu-serverを運用しています。
サーバを構築したときのUbuntuバージョンは確か 8.04 。その後LTSの意味を理解せず 8.10 にバージョンアップしてしまったため、現行バージョンの 10.04 まではリリースの度にバージョンアップしてきました。

ところがどうも不安定です。
導入当時は今よりさらに初心者だったため設定方法がよくわからず、不要な設定もいろいろ行なったと思います。カーネルのコンパイルをしたこともありました。
今思えばこういった一連の操作が不安定の原因かと…。

ともかく変ないじり方をしているせいで、何かあっても障害切り分けが難しくなっていて色々難儀するようになりました。
そこで先日、思い切ってバージョン 10.04 をクリーンインストールしました。そのせいでまた別の思いがけない不具合がポツポツ出てきています。

ということで、クリーンインストール後の不具合の解消を順に記録していきます。

---

このサーバの主な目的はデータストレージです。週に1度、システムのダンプとデータを外付けHDDに自動でバックアップするようにしています。一連のバックアップをスクリプトにし、cronで自動実行しています。

またターミナルでの日本語出力が見づらいと思っていたため、ロケールは en_US.UTF-8 でインストールしました。この状態でも日本語ファイルは正常に扱うことができています。

さて自動バックアップの際、rsync の標準出力を専用ファイルにリダイレクトしていますが、この中の日本語ファイル名が全て記号に置き換わっている事に気づきました。化けているのではなく、ちょうどHTMLエンティティをかけた様な感じです。

スクリプトの頭には、

export LANG=ja_JP.UTF-8

と記述しており、これまでは日本語で記録されていました。インストール時に英語を選択したことが原因であると思われますが、通常のターミナル操作(コマンドls等)では日本語も表示されます。

少し考えましたが、理由は簡単でした。ターミナルで

$ LANG=ja_JP.UTF-8
$ locale

としても en_US.UTF-8 のままです。
何のことは無く、日本語ロケールが入っていないだけでした。

ということで日本語環境をインストールおよび設定。

# apt-get install language-pack-ja
# dpkg-reconfigure locales
# update-locale LANG=en_US.UTF-8

あっさりと設定終了です。
最後の一行は不要かもしれません。

これで通常は英語環境、必要なときには日本語環境も使用可能、となりました。

lsコマンド等では日本語表示されるため気づいてなかったんですね。
以前の環境は日本語でインストールしていて、この場合は後からロケールを英語に設定してもうまくいきませんでした。

とりあえず、ひとつ解決。

---

静音、省電力サーバに最適。

さて先日やらかした失態。
WINSサーバとして運用している機体をうっかり再起動してしまい、さらに何故か起動に10分以上の時間がかかり、その間名前解決ができず…というもの。

まあ営業時間中に再起動すること自体がダメダメなんですが、障害の可能性も含め対策して於いた方が良いかと思い、WINSサーバの二重化を試みます。 

そもそもVPNでネットワーク同士を繋いでいるためにWINSサーバが必要でした。このとき同時にDMBも必要と思い、VPNのこっち側とあっち側にそれぞれSambaをたてており、そのうちこっち側のみがWINSサーバとして稼働しています。
あっち側はDMBの同期の為だけに稼働していましたが、最近になって、そもそもDMBは不要だったのではないか…と感じているのは内緒。＾＾

ともかく、ちょうど2台目のWINSサーバに最適な機体がありますので、これを設定していきたいと思います。

(備忘録ですから簡潔に書いていますが、正常稼働までには何気に苦労しています。＾＾)

参考文献：
http://wiki.samba.gr.jp/mediawiki/index.php?title=WINS-replication
http://www.osstech.co.jp/techinfo/samba/wins-push

---

まずwinzsendを試しましたが、私の知識ではうまく動かすことができませんでした。
CPANというものも(Google先生のおかげで一応操作できましたが)初めて見るものだったこともあって、うまく動かない時の障害切り分けができないため、少しいじくって早々にあきらめました。

で、wins-pushの方でうまくいきましたので、そのメモ。

---

まずwins-pushを解説に従って設定していきます。

現WINSサーバにインストール

# mkdir /usr/local/sbin/wins-push
# chmod 755 /usr/local/sbin/wins-push
# wget http://www.osstech.co.jp/_media/techinfo/samba/wins-push.pl /usr/local/sbin/wins-push/.

2台目WINSサーバを指定するための設定ファイル作成

# echo "wins servers = 192.168.???.???" >/etc/samba/wins-push.conf
(???は2台目WINSサーバのアドレスを指定)

状態保持用ディレクトリを作成

# mkdir /var/cache/samba/wins-push

現WINSサーバのSambaの設定を変更

# vi /etc/samba/smb.conf
[global]
wins hook = /usr/local/sbin/wins-push

2台目のSambaも設定変更

# vi /etc/samba/smb.conf
[global]
wins support = yes

これでそれぞれのSambaを再起動したところ、2台目のwins.datにきちんと情報が追加され行くことを確認しました。
(Sambaの再起動に手間取りましたが…)

---

次にWindwosに渡しているWINSサーバの情報に、両サーバのアドレスを渡すようにしました。(アドレスは渡せましたが、障害時にうまく動いてくれるかは判りません)

各PCのIPアドレスは管理の都合上DHCPで取得させています。DHCPサーバはルータ(YAMAHA RT-58i)を利用し、配布するIPアドレスはMACアドレスを基に固定となってています。
従って、ルータの設定を少し変えるだけで全PCのWINSサーバ情報が(次回接続時より)更新されます。

設定はルータGUIの「コマンドの実行」に

wins server 192.168.???.??? 192.168.???.???
(1台目2台目それぞれのIPを指定)

とするだけです。

---

ここで注意事項。

winssendの方で、双方向にデータのやりとりができるスクリプトであると説明がありました。

(引用)

双方向レプリケーション

　ver 0.02 までは片方向レプリケーションしか出来ませんでした。ある1つのマスタとなるwinsサーバを立ち上げておいて、ここから他のwinsサーバに対してデータを配信することしか出来ませんでした。

　ver 0.13からは双方向(pushのみ)のレプリケーションが出来るようになりました。それぞれのwinsサーバにwinssend.plを設定することで、互いに他のwinsサーバに対してデータを供給できるようになりました。ただ、そのままでは他のwinsサーバから登録要求があったデータもwinssend.plを起動して、また他のwinsサーバにデータを送り込んでしまいます。そこで、winssend.plでは自分自身が所属しているネットワーク以外からのデータは送り出さないようにしています。これで、winsデータの白山羊さん黒山羊さん問題を解決できます。

winssendを基にしたとされるwins-pushの方も同様かと思いましたが、当方の環境では双方向ではうまく動いてくれませんでした。
一方通行のみに設定したところ、うまく動いてくれています。

まあ、あくまで非常用ですから現状で問題ありません。
私が「いらんこと」をしなければ、そうそう障害も起こらないでしょうしね…。

 

主にWINSサーバ用としてのSambaを運用しているサーバを、先日Ubuntu10.04にアップデートしました。
その後特に問題もなく稼働していましたが、メンテの際、営業時間中にうっかり再起動をかけてしまいました。

通常であればせいぜい2分ほどで復帰しますので、特に問題は起こらないはずだったんですが、何故かまともに起動せず、WINSサーバ不稼働により業務に紙使用を来してしまいました。

コンソールをのぞいてみたり、強制再起動してみたりしているうちに、10分ほどで正常稼働し大事にはなりませんでしたが、いったい何だったかを備忘録として記述しておきます。

---

判ってしまえば実に簡単な話ですが…。

実はネットワーク内にNASが存在しています。これは管理の都合上市販品を使用しているんですが、この中のネットワークドライブをUbuntuサーバにマウントして使っています。

どうやら、Ubuntuを10.04にアップデートしたことにより起動が速くなり、ネットワークリンクが確立する前に自動マウントを試みている様子。ここでリソースを食うのが、起動途中で立ち往生する原因のようです。

そこで対処として、ネットワーク確立後にマウントを試みるように設定します。

先ずfstabを編集し、オプションに自動マウントしないための"noauto"を追加します。
"noauto"オプションをつけるのは、設定をfstabに残すことにより管理をし易くする為です。

# vi /etc/fstab
//NAS/共有フォルダ  /mnt/NAS.共有フォルダ  cifs  password=********,username=********,iocharset=utf8,ro,noauto  0  0

次に、/etc/network/if-up.d/ の下に適当なファイルを作り、マウント用スクリプトを記述します。

# cd /etc/network/if-up.d/
# vi netowrk.mount.sh

/bin/mount /mnt/NAS.共有フォルダ 

これで再起動すれば、きちんと起動するようになりました。

---

NASの認証に時間がかかるのは、また別の問題。^^

 

サーバ用に本気でお勧め。

iPhone4買いました。Kindleも予約注文しました。
このへんの話もそのうち書くでしょう。^^

---

さて Postfix について。

Linuxサーバ自体から出るシステムのメールや、その他PCから自動で発信するメールのSMTPサーバとしてPostfixを使用しています。ただ、ドメインは所持しているもののDDNSによる運用のためか、Postfixを単純なSMTPサーバとして運用しようとしても誰もリレーしてくれません。
そこでISPのSMTPサーバをリレーホストとしていますが、最近このサーバが送信に認証を求めてくるようになりました。

そこでSASLという仕組み(?)を利用して認証することにしました。

先ずPostfixの設定を変更します。

/etc/postfix# vi main.cf

とし、

relayhost = [SMTPサーバ名]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd

を追加(または変更)します。

次に認証情報のファイルを作ります。

/etc/postfix# vi sasl_passwd

とし、

[SMTPサーバ名]:587        アカウント:パスワード

と一行記述します。

最後に認証情報のファイルをdb化し、Postfixを再起動します。

/etc/postfix# postmap ./sasl_passwd
/etc/postfix# /etc/init.d/postfix restart

これで無事にメール送信ができるようになりました。

---

さて、実際には少し手間取りました。
認証情報をdb化しようとしたところでpostmapが使用できないというものです。
(Ubuntu9.04からアップグレードした9.10に於いて)

mailをインストールしろといわれるので試みたところPostfixが削除され、再インストールしてもうまく動かず、いろいろいじったり再起動したりしているうちにちゃんと動くようになりました。
実際にどう復旧したかは今となってはよくわかりません。

一方、Ubuntu10.04をクリーンインストールしたサーバの方では同様の問題は起こりませんでした。

試みる場合、少し注意した方がいいかもしれませんね。

 

忙しさにかまけて暫く放置していたUbuntuサーバ。現行サーバとの交換用に用意しているんですが、いい加減に本運用に移りたいところです。

さて、久しぶりに電源を投入してみたところ…

hda-intel: spurious response 0x0:0x0, last cmd=0x000000
hda-intel: spurious response 0x0:0x1, last cmd=0x000000
・
・

と、メッセージが延々とコンソールに表示され、起動しません。

仕方なく電源長押しで強制終了後、再び電源投入。
すると問題なく起動してきます。

よくわからないままアップデートをし、再起動。
するとまた同じメッセージが延々…。こんどは何度再起動しても正常に起動しません。

ということで、例によってGoogle先生に聞いてみたところ、以下のような情報が。
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/536699

問題の機体はD945GCLF2ですが、まあ同じことでしょう。
英語が面倒ですが、どうもオーディオ関連のバグ、と書いてあるような気がしないでもない…。

ならばと、どうせサーバ用途でオーディオは不要ですからBIOSで切ってしまいました。
というか、オーディオとかパラレルとか、不要なものは切ったつもりだったんだけどなぁ…。全部有効になってました。^^

これらを無効にして起動を試みたところ正常起動。
その後数回再起動をかけましたが、正常に稼働しています。

既に本運用している同構成のもう一台は、BIOS設定きちんとしてたかな…？
あとで確認しとかないと。

 

 

今買うならこちら。
今のところ不具合等ありません。

いつの頃からか、WindowsからSamba共有フォルダを開く際に、ふた呼吸くらい置いてからファイルリストが表示されるようになりました。それまでは瞬時と言っていいくらいの表示でしたので、結構待たされ感があります。
おそらくSambaのアップデートによりシンボリックリンクのフォルダが開けなくなったのと同じタイミングだと思われます。

例によってググってみたところ、空き容量の計算に時間がかかっているのが原因という説を発見しました。
ただその説は、アクセス毎に2回計算している、というもの。私の場合はある程度時間をおいた後のアクセスのみ遅いので、ちょっと違うかと思いますが、一応試してみました。

smb.confに

[global]
dfree cache time = 60

とし、空き容量の計算を60秒ごとに設定してみました。

結果は…
期待通りです。以前のように瞬時に表示されるようになりました。

これでSambaに関する問題はもう残っていないと思います。
ただ、cron-aptによる自動アップデートは見直した方がいいのかもしれませんね。

いつぞやのアップデート以降、Sambaで共有しているフォルダ内にある他フォルダのシンボリックリンクにアクセスできなくなりました。
まあセキュリティーの基本設定が変わったんだろうなぁと何となく納得。

とはいえ不便です。
閉じたネットワーク内でしかアクセスしないサーバですし、以前の状態に戻すことにします。

smb.conf に

[global]
wide links = yes
follow symlinks = yes
unix extensions = no

と設定。
(2010.5.17 Ubuntuを10.04にアップデートしたところ再びシンボリックリンクへアクセスできなくなったため下線部追加。)

めでたしめでたし。

サーバ等で行なう定期作業やエラーを、自動でメール連絡させるようにしています。
最近になって、これらメールのうち幾つかでメールヘッダに「Date:」項目の無いものがあることに気づきました。

Date:項目がないと、メールソフトがメールを取り込んだ日時でタイムスタンプを押す様子。
これは色々と問題があるので、ちょっと調べてみました。

これら連絡メールは Linux サーバの「Postfix」をSMTPサーバとして発信させています。
以前はメール送信の際にDate:項目がない等、ヘッダ部に不備があるとPostfixが補完してくれていたんですが、これがうまく働いていない様子。
ググってみると、どうもバージョンアップでデフォルト設定が変わった様です。

ということで、「ヘッダ部の不備は補完しなさい」と明示的に指示してあげなければなりません。
設定ファイル ( /etc/postfix/main.cf ) に次の一文を追加してやります。

always_add_missing_headers = yes

これでメールヘッダがちゃんと補完されるようになりました。

 

D945GCLF2のNICに正しいドライバを充てようというお話、の続き。

1. RTL8111用のドライバをインストールする。
2. 再起動しても正しいドライバを使用するように設定する。  <--今日はここ
3. カーネルアップデートがあっても正しいドライバを使用するように設定する。

本日のカーネルアップデート(2.6.31-19)で、実は 3. がうまくいかないことが発覚しましたが、とりあえず続けます。

---

(2) 再起動しても正しいドライバを使用するように設定する。

1. まずは r8169 を使用しないようにOSに指示します。
   

   # vi /etc/modprobe.d/blacklist.conf

   とし、

   blacklist r8169
   alias eth0 r8168

   を追加します。
   
   
2. initramfs を作り直します。
   

   # mkinitramfs -o /boot/initrd.img-`uname -r` /lib/modules/`uname -r`

これで再起動してもきちんと r8168 が使用されるはずです。

再起動後、前回と同じように確認します。

# lsmod | grep r816

r8169 が表示され、かつ r8169 が表示されなければOKです。

---

一応正しいドライバで動くようになりました。しかしカーネルアップデートの際に r8168 を再インストールする必要が生じます。
問題はそれがNICであると言うことす。NICが動いてくれないとターミナルが使えません。

次回はその辺をどうするかというお話。

D510MOがなかなか良いので、Linuxサーバ側も入れ替えようかと考えています。

現在はD945GCLF2を使用していますが、オンボードNICでエラーが頻発するためPCIにIntel製NICを挿して使用していました。
http://blog.livedoor.jp/abm55608/archives/704695.html

ただファンレスのマザーに交換するにあたっては排熱が心配どころ。少しでもケース内の障害物は取り除いておきたいところです。
そこでオンボードNICをきちんと使用できるようにしようと挑戦し、うまくいきましたのでメモです。

手順は、

1. RTL8111用のドライバをインストールする。
2. 再起動しても正しいドライバを使用するように設定する。
3. カーネルアップデートがあっても正しいドライバを使用するように設定する。

といった感じになります。

なお、Ubuntu8.04からアップデートしながら使用しているサーバと、Ubuntu9.10を新たにインストールしたものとの両方でうまくいったことを補足しておきます。
本日のカーネルアップデートを適用したところ、うまくいきませんでした。(2010.2.5)

---

(1) RTL8111用のドライバをインストールする。

1. まずはRealtekのサイトからドライバのソースを落としてきます。
   
   トップページ > ダウンロードセンター > ネットワーク向けIC >  Network Interface Controllers > 10/100/1000M Gigabit Ethernet > PCI Express > Software と辿り、LINUX driver for kernel 2.6.x and 2.4.x (Support x86 and x64)（ファイル名r8168-8.016.00.tar.bz2）をダウンロードしてきます。
   （今日現在のバージョンは 8.016.00 です。）
   
   
2. 開発環境を整えます。
   
   現在使用しているカーネルバージョンを確認し、必要なものをインストールしていきます。
   私の場合は 2.6.31-17 の pae 版でした。
   

   # apt-get install build-essential
   # apt-get install kernel-package
   # apt-get install linux-headers-2.6.31-17-generic-pae

3. 落としてきたドライバを解凍してインストール。
   

   # tar xvf r8168-8.016.00.tar.bz2
   # cd r8168-8.016.00
   # make clean modules
   # make install

4. 間違って使用されているr8169を削除し、インストールしたr8168を認識させます。

   # depmod -a
   # rmmod r8169 mii
   # modprobe r8168

5. ネットワークを再起動します。

   # /etc/init.d/networking restart

これで正しいドライバ r8168 が使用されているはずです。確認します。

# lsmod | grep r816

で r8168 が表示され、かつ r8169 が表示されなければOKです。

---

「Ubuntuで、D945GCLF2オンボードNICを正しく認識させる (2)」に続く。
……はず。