Linux

2013.01.09

KVMでネットワークをNATにしている場合

KVMでネットワーク環境をBridgeからNATに戻したわけなんですが、思わぬところではまってしまいました・・・。

VM1 192.168.11.201(外部) ⇔ 192.168.101.201(内部)
VM2 192.168.11.202(外部) ⇔ 192.168.101.202(内部)

というようなネットワークを構築していて、192.168.101.201から192.168.101.202に通信を行う場合、VM2からみると、192.168.11.201からアクセスしてきている感じになるんですね。

PostgreSQLの pg_hba.conf などで、接続元IPアドレスを192.168.101.201などに限定していた場合、接続が拒否られてしまうことに・・・。この部分で1時間ほど悩んでいたような・・・。

VM2でifconfigを実行しても、192.168.101.202しか見えない(当然)ので、なかなか気付きませんでした(悩んだ末に、試しに 192.168.0.0/16 でアクセスを許可するようにすると接続出来たので気付きました)。

#KVMをきちんと使っている人からすると当たり前のことなのかもしれませんが。

| | Comments (0) | TrackBack (0)

2012.10.18

snmptrapdでtraphandleが反応しない

snmptrapdで他からのメッセージを受信。
syslogには問題なく出力されているのに、traphandleが反応しない・・・。

例によって、例のごとく(?)、SELinuxの影響でした(苦笑

ただ、SELinuxを有効にした状態でコマンドを実行する方法がわからず、仕方なく、 setenforce 0 でpermissiveモードにして逃げてしまいました・・・(涙)。

# chcon -t snmpd_exec_t test.sh

のようにした場合、test.shそのものは実行出来るようになったのですが、その中で呼び出しているコマンド(例えばmailなど)を実行するタイミングでSELinuxに阻まれてしまいました・・・。

シェルスクリプトはさておき、それ以外の実行ファイルも片っ端からchconするというのは何か間違っているような気がするので、いったん、permissiveモードで逃げることにするかなぁ・・・。

| | Comments (0) | TrackBack (0)

2012.10.08

SSLInsecureRenegotiation

同じSSLクライアント証明書でも、端末によってアクセス出来たり出来なかったり、という現象に遭遇。

サーバーのログを見てみると、

SSL3_ACCEPT:unsafe legacy renegotiation disabled

のメッセージが。

で、調べてみると、IE-Apacheで急にSSLクライアント認証ができなくなった と同じ現象っぽい。

試しに、

SSLInsecureRenegotiation on

の設定を追加すると、一応アクセス出来るようになりました。

おそらく、Windowsのアップデート状況などに起因して現象が出る/出ないがあったのではないかと。

Insecureとあるだけに、可能なら on にしない方がよいのでしょうが、接続元の端末が特定出来ない状況では、 on にするのが現実的なところでしょうね・・・。

| | Comments (0) | TrackBack (0)

2012.10.06

ntlmaps

NTLM認証を行うProxyサーバーを経由する際に、cntlmCntlm Authentication Proxy)を使用していたのですが、微妙に不安定・・・?(時々、接続が強制的に切断される)

まぁ、3年も前にインストールしたものなので、バージョンを上げることで改善するのかもしれませんが、別件で調査中に見かけたNTLM Authorization Proxy Server を使用してみることに。

インストール先は、ReadyNAS NV+ v2
パッケージが提供されていたので、インストールは非常に簡単。ntlmapsはPythonで動作するので、Pythonもあわせてインストールされます。

# apt-get install ntlmaps

インストール完了後、自動的に設定画面が表示されるのですが・・・上位Proxyサーバー(NTLM認証を要求するProxyサーバー)のポート番号を指定することができないなど、ちょっと中途半端な感じ?

設定情報は、/etc/ntlmaps/server.cfgに保管されているので、直接書き換えてしまった方が手っ取り早いかも。以下の5項目の設定を確認すれば、とりあえずはOK。

・PARENT_PROXY
・PARENT_PROXY_PORT
・NT_DOMAIN
・USER
・PASSWORD

後はサービスを開始するのみ。

# /etc/init.d/ntlmaps start

まだ稼働日は短いですが、安定して動いている感じです。

ちなみに、sysv-rc-config で確認したところ、インストールした状態で自動起動は有効になっている模様。

| | Comments (0) | TrackBack (0)

2012.09.30

ReadyNAS NV+ v2 で Subversion

ReadyNASXtrasのところでARM版Subversionのアドオンが公開されていますが、$2.49 となっているようです。

ただ、1.7系列でなくてもよいのであれば、パッケージで提供されているので、今回はそちらをインストール。

まずは、パッケージリストを更新。

# apt-get update

続けて、Subversionをインストール。

# apt-get install subversion

パッケージで提供されているバージョンは1.6.12でしたが、普段使用しているのが1.6系列なので特に問題なし。
svnsyncとcrontabを組み合わせることで、定期的にリポジトリのバックアップを取得する環境を構築出来ます。

もちろん、LAN内で使用するのであれば、ReadyNAS上のApacheと組み合わせてSubversionサーバーとして使用することも可能かと(今回は、その必要はなかったので、設定していません)。

ただし、内蔵メモリが256MBしか存在しないことなどが影響し、svnsyncの最初のうちは結構大変かもしれません。私のところでは、結構頻繁に Cannot allocate memory というエラーが出て、hook-scriptの実行に失敗してしまいます(^^;
まぁ、数十~数百程度のリビジョンの同期程度であればまず大丈夫な感じではありますが(数千のリビジョンを同期すると、ほぼ確実にエラーが発生する)。

ちなみに、topで見ていると、多数のリビジョンを処理して行くうちに、swapも含めてメモリ使用量が300~400MB程度まで達しているようです。

| | Comments (0) | TrackBack (0)

2012.09.29

ReadyNAS NV+ v2 で SSH

まずは、sshで接続出来るようにするためのアドオンをインストール。

Enable Root SSH アクセス(日本語ページ)にはARM版がないのですが、Enable Root SSH Access(英語ページ)にはARM版も公開されています。

ReadyNAS NV+ v2はARMなので、ARM版のアドオンをインストール。再起動が要求されるので、再起動させると、sshで接続出来るようになります(【ReadyNas Duo】 ssh設定のページに詳しい内容が載っています)。

環境によっては、root以外でもログイン出来るようにし、rootログインを禁止するようにした方がよいでしょうね。

| | Comments (0) | TrackBack (0)

2012.09.28

ReadyNAS NV+ v2

NETGEAR社のNASの1つ です。
カテゴリー的には、「ホーム向けのスタンダードタイプ」。

さらっと使ってみたところ、やはり「ホーム向けのスタンダード」タイプのことはあるなぁ・・・と思うところもちらほら。

一番実感するのは、ユーザーのグループ管理を行うことができないこと?
人数や、公開する共有フォルダが少ないと特に問題となることはないと思いますが、ある程度の人数になってきて、しかも、共有フォルダ数が増えてくると、グループ管理できないとちょっと大変かもしれませんね。

あとは、クォータの設定を行うことができない(と思われる)ところでしょうか。
ユーザーを追加すると、各ユーザー専用のフォルダ(管理者以外の他のユーザーはアクセスできないフォルダ)が準備されるのですが、クォータを設定できないので、油断するとディスク容量が・・・ってことになりそう。
(もしかすると、何か設定する方法があったり、あるいは、各ユーザー専用のフォルダは自動的に制限があったりするのかもしれませんが)

1Gbpsの環境で、約50MB/s程度のスループットとのこと(参考:パフォーマンスもアップした「ReadyNAS NV+ v2/DUO v2」 )。これを「充分」と考えるか「足りない」と考えるかは人それぞれかとは思いますが、ネットワーク帯域として400Mbps程度を使用していることになるので、まぁ、検討しているところではないでしょうか。

ちなみに、この製品を選んだポイントは、

・NAS上で、Subversionを動作させることができること。
・NAS上で、その他、ある程度のアプリを動作させることができること。
・HDDの選択肢が多い(メーカーによっては専用のHDDが必要となるケースも)。
・安い(アマゾンで2万円台前半)わりに、最大4台のHDDを搭載することができる。

といったところでしょうか。

Subversionは、サーバーとして使うのではなく、svnsyncを用いて別のところで動作させているSubversionのバックアップ取得が目的。他に、wgetである公開フォルダーの内容を定期的に自動取得(更新)させることができれば良いなぁ~・・・というのが背景にあります。

このあたりの設定などに関しては、また後日。

| | Comments (0) | TrackBack (0)

2012.09.21

KVMでネットワーク環境をBridgeからNATに戻す

ネットワーク構成の都合で、KVMのネットワーク環境をBridgeからNATに戻すことに(外部のネットワーク環境(セグメント等)が変わっても、KVM上で動作させている仮想マシン上のIPアドレスを変更しなくても済むようにしたかった)。

もちろん、その仮想マシンにアクセスしていた端末側は、アクセスするIPアドレスの変更が必要となりますが、まぁ、ネットワーク環境の変更が必要になった時点で、どのみち変更が必要になるので、そのあたりは許容範囲。

defaultのネットワークを復活させる
Bridgeにする際に、KVMのNAT用インタフェースを停止してしまっているので、それを復活させる必要があります。

# virsh net-start default
# virsh net-autostart default

開始するのに合わせて、自動起動の設定も行っておきます。

なお、仮想マシンのIPアドレスのセグメントを変更する場合は、 /var/lib/libvirt/network/default.xml および /etc/libvirt/qemu/networks/default.xml ファイルを編集します(おそらく、どちらかのファイルの設定を変更すると他方に設定が反映されると思うのですが、そこまで確認出来なかったので両方編集)。
仮想マシン側でDHCPサーバーを使用しない(全て固定IPアドレスを割り当てる)場合は、dhcp要素およびその内部のrange要素を削除。セグメントなどを変更する場合は、 <ip address="192.168.101.1" netmask="255.255.255.0"> のように修正します。


ゲストOSの定義を編集
/etc/libvirt/qemu ディレクトリ内にあるゲストOSに定義ファイルを編集します。

<interface type='bridge'>
  <mac address='52:54:00:e5:ea:5a'/>
  <source bridge='br0'/>
  <model type='virtio'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>

のように定義されている部分を書き換えます。
<interface type='network'>
  <mac address='52:54:00:e5:ea:5a'/>
  <source network='default'/>
  <model type='virtio'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>

編集内容を反映しておきます。
# virsh define (guest-name)

Bridge用の定義を元に戻す
/etc/sysconfig/network-scripts/ifcfg-br0 を削除(あるいは別のフォルダに待避)し、 /etc/sysconfig/network-scripts/ifcfg-eth0 の内容を修正(bridgeの設定を削除し、適切なIPアドレスを付与)。
あわせて、以下のような感じで仮想マシンに紐付けるIPアドレスを定義します。

IPADDR2="192.168.11.201"
NETMASK2="255.255.255.0"
GATEWAY2="192.168.11.254"

複数のNAT変換を定義する場合は、IPADDR3、IPADDR4 のように順番に定義していけばOKです。

NATの設定を行う
/etc/sysctl.conf を編集してIP転送を有効にします。

net.ipv4.ip_forward = 1

iptablesの設定を行い、IPアドレスの紐付けを行います。
# iptables -F
# iptables -F -t nat
# iptables -A INPUT -p all -j ACCEPT
# iptables -A FORWARD -p all -d 192.168.101.0/24 -j ACCEPT
# iptables -A FORWARD -p all -s 192.168.101.0/24 -j ACCEPT
# iptables -t nat -A POSTROUTING -s 192.168.101.221 -j SNAT --to 192.168.11.201
# iptables -t nat -A PREROUTING -d 192.168.11.201 -p tcp -j DNAT --to 192.168.101.221
# iptables -t nat -A PREROUTING -d 192.168.11.201 -p icmp -j DNAT --to 192.168.101.221
# /etc/rc.d/init.d/iptables save

再起動
設定諸々を反映させるため、ホストOSの再起動を行います。
なお、再起動後、iptablesの再起動を行わないと、外部からのアクセスに失敗してしまうことがあるような・・・?(滅多に再起動しないので、そのまま放置してしまっていますが)

その他
仮想マシン側のiptablesなどで、接続を許可するIPアドレスを制限している場合は、その部分を設定変更する必要があります(pg_hba.conf(PostgreSQLを使用している場合)など)。

参考:KVM/nat接続(CUI)

| | Comments (0) | TrackBack (0)

2012.09.14

Linuxで7zファイルを作成/展開する

何らかの事情で、gzipなどよりも高圧縮率の7zで処理を行いたいような場合。CentOS6.2の標準パッケージには7zを扱うものは含まれていないようなので、ソースからビルドすることに。

1)p7zipから、ソースをダウンロード。今回ダウンロードしたのは、9.20.1(2011/03/16リリース)。

2)bzip2を展開&tarを展開。

# bzip2 -d p7zip_9.20.1_src_all.tar.bz2
# tar xvf p7zip_9.20.1_src_all.tar
# cd p7zip_9.20.1

3)Makefileを準備。どのmakeファイルを使用すれば良いのかわからなかったので、無難そうなものを(^^;

# cp makefile.linux_x86_asm_gcc_4.X makefile.linux

4)ビルド&インストール。

# make
# make install

 なお、環境によっては、 gcc および gcc-c++ のパッケージをインストールしておく必要があります。

これで、7zaコマンドで7zファイルを扱うことが出来るようになりました。
圧縮対象となるファイルにもよりますが、今回はgzipでの圧縮に比べると2~3割コンパクトに。これを「2~3割も」ととらえるか、「2~3割しか」ととらえるかは人それぞれ。

今回は、「2~3割も」と言ったところでしょうかね~。

| | Comments (0) | TrackBack (0)

2012.09.13

muttを使って添付ファイルを送信

muninが生成したtarファイル を、メールで送信したいなぁ~~と。

mailコマンド(CentOS6.2の場合、実態はmailx)だと、どうもバイナリの添付ファイルの取り扱いが難しいっぽい。で、いろいろと調べてみると、muttJapanese Edition)というテキストベースのメールクライアントだと、シェルから手軽に添付ファイルを送ることが出来るらしい。

幸い、CentOS6.2には、標準でパッケージが提供されているので、まずはインストール。

# yum install mutt

添付ファイルを送る場合、

# mutt -s "Title" -a "filename" hoge@example.com < /dev/null

でいけるとのことなのですが、どうにもこうにもエラーになってしまう・・・(hoge@example.com を添付ファイルとして認識しまっているっぽい)。

いろいろと試したところ、添付ファイルの指定を最後に行えば、メールを送信することが出来ました。

# mutt -s "Title" hoge@example.com -a "filename" < /dev/null

う~ん・・・まぁ、結果的に目的を果たせたから良しとしますか・・・??

#ただ、現実的に、サーバー台数(あるいは監視項目)が増えてくると、muninの結果ファイル(画像ファイル)等のファイルサイズの都合上、添付ファイルで送信するのは難しくなってしまいますが・・・。

| | Comments (0) | TrackBack (0)

より以前の記事一覧