UbuntuでethXとMACを静的に対応付ける

ネットワーク Linux

3つNICのあるUbuntuサーバを再起動したら、eth1とeth2が入れ替わってしまった。

1ヶ月半ほど前にも同じことがあって、そのときは、その場しのぎでIPの付け替えをしただけだったのですが、再発するとさすがに面倒なので、今回はちゃんとMACアドレスと各インタフェイスの対応を設定しました。

普段はCentOSを使っているので、たまに社内にあるUbuntu(もしくはDebian)を触ると、設定ファイルがどこにあるのかとか、設定ファイルの書き方が微妙に違ったりとで、悩ましいです。社内のサーバは全部CentOSにしてくれないかなぁと思ってしまうことが多々ありますね。RedHat系ならいいから、Fedoraでもいいんですけど。

さて、本題のインターフェイスとMACアドレスの対応を設定する方法ですが、/etc/network/interfacesというファイルに以下のように記述します。例はeth0とeth1の設定例です。

auto eth0
iface eth0 inet static
	address 192.168.X.Y *1
	netmask 255.255.255.0 *2
	network 192.168.X.0 *3
	broadcast 192.168.X.255 *4
	gateway 192.168.X.1 *5
	hwaddress ether 00:AA:BB:CC:DD:EE *6

iface eth1 inet static
	address 192.168.A.B
	netmask 255.255.255.0
	network 192.168.A.0
	broadcast 192.168.A.255
	gateway 192.168.A.1
	hwaddress ether 00:AA:BB:CC:DD:FF

すぐに確認するには、

/etc/init.d/networking restart

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

今までは、hwaddressの指定がなかったので、起動のたびにeth1とeth2入れ替わってしまっていました。たしか前回も原因は分かっていたけど、調べるのが面倒で場当たり的なことをしてしまったという記憶があります。

やっぱり、分からなくてもちゃんと調べて設定しておくべきですね。反省、反省。

Ubuntuは、社内のある一派が良く使うので、最低限の設定方法は覚えておかないといけないな。。。

*1:設定したいIPアドレス

*2:サブネットマスク

*3:ネットワーク開始アドレス

*4:ブロードキャストアドレス

*5:ゲートウェイ

*6:そのIPを設定したいインタフェイスのMACアドレス

メモ＠2008/12/16

http://monkey.org/~marius/pages/?page=trickle

trickle is a portable lightweight userspace bandwidth shaper. It can run in collaborative mode (together with trickled) or in stand alone mode.

trickle works by taking advantage of the unix loader preloading. Essentially it provides, to the application, a new version of the functionality that is required to send and receive data through sockets. It then limits traffic based on delaying the sending and receiving of data over a socket. trickle runs entirely in userspace and does not require root privileges.

これを使えば、以前「サーバへのアップロード帯域を制限したい - Wait at a Street corner」で行っていたことが解決できるかも。使ってみます。

リアルタイムミラーリングツール導入(lsyncd+rsyncd) - Fedoraで自宅サーバー構築

lsyncdを使用してマシン間でリアルタイムにディレクトリのミラーリングを行う。
lsyncdはLinuxカーネルのinotify機能を利用して、ファイルの更新時にミラー先のrsyncサーバーへrsyncを実行することにより、リアルタイムにディレクトリのミラーリングを行う。

忘れてた。

lsyncd = rsync + inotify

試してみないと。DRBDがブロックデバイス単位でのミラーリングであるのに対して、こちらはファイル単位でのミラーリング。用途に応じて使い分けることができれば、冗長化構成を考えるときの1つの解になりますね。

http://www.linux.or.jp/JM/html/LDP_man-pages/man7/inotify.7.html

notify API はファイルシステムイベントを監視するための機構を提供する。 inotify は個々のファイルやディレクトリを監視するのに使える。ディレクトリを監視する場合、inotify はディレクトリ自身とディレクトリ内のファイルのイベントを返す。

後で読む＠2008/12/16

減り続ける利用可能メモリ……そしてついにリブート！ (1/3)：Linuxトラブルシューティング探偵団 番外編（2） - ＠IT

メモリ管理とかちゃんと勉強しようと思いつつ、なあなあにしていることのひとつ。だめですね、はい。

簡易帯域制限 on Linux

技術 Linux ネットワーク

割と便利な帯域制限方法(Linux編): sanonosa システム管理コラム集を参照しました。

# ethtool eth

でNICの対応している通信速度と全/半二重などの通信方式を確認する。

以下のようにして、対応している通信速度と通信方式を設定して、最後にオートネゴシエーションをOFFにする。

# ethtool -s eth0 speed 10
# ethtool -s eth0 duplex full
# ethtool -s eth0 autoneg off

ただし、使用しているNICのドライバがMII (Media Independent Interface) に対応していなければ、ethtoolを使っても状態の確認はできない上に、設定変更もできません。

というわけで、XenのdomUではできませんでした。本番環境でやるのは怖いから、開発環境で試してみたかっただけなのに。。。

VMWareのゲストでも同じのようですね。仮想化環境のNICではダメだということですね。仮想化のゲストにとっては必要のないことといわれてしまえば、そのとおりなのですが、動作テストをするためにはあってもいいのかなと思います。

というわけで、社内の2NICサーバで、使ってない方のポートを使って試しましたｗ
ちゃんと設定できましたので、本番機でも使ってみたいと思うのですが、いきなり制限しちゃっても大丈夫なのだろうか。

[追記]
ちゃんと、カーネルモジュールにshaperってのがあるんですね。勉強不足ですいません。

Firefox3でファイルのアップロードをすると、ファイルがロックされたままになる

つぶやき Firefox

どうやらこれは、Live HTTP Headerが原因らしい。「http://d.hatena.ne.jp/callee/20080715/p1」によると、これに対する解決策は、

現在(Ver0.14)のところ、「普段は LiveHttpHeaders を無効にして、必要なときだけ有効化する」のがよさそうだと思います。
(略)
また、アップロードを行ったページを含むタブを一度閉じて再度開く事でロックを解除したり、 Live HTTP Headers のウインドウを開きっぱなしにする事で現象を回避できるとも書いてあります。（未検証です）

とのことです。

必要なときにだけ有効化ってのは激しく面倒ですね。だれかパッチを宛ててくれないかな。

[追記]
あ、↑で書かれているとおり、Live HTTP Headersのウインドウを開いておけばファイルのロックが解除されますね。

[追記の追記@20081215]
あれ、今日やってみたらロックが解除されないです。。。どういうことだ？