Linuxの最近のブログ記事

2015年1月13日

samba を複数起動する

ちょっと事情がありまして、1台のサーバーで samba サーバーを複数起動する方法を調べてました。

ネットワークインターフェイス毎に1台のサーバーでそれぞれ別の SMB ファイルサーバーサービスを提供したいなどに便利です。

まずは、すでに起動している samba の設定ファイルとは別の smb.conf を用意します。

# cp -ar /etc/samba/smb.conf /etc/samba/smb_srv2.conf 

新しく作成した設定ファイルの内容を変更します。まずは、ネットワーク周り。interfaces、host allow、bind interfaces only、socket address などを公開したネットワーク向けに明示的に設定します。

interfaces = 192.168.1.123/24
bind interfaces only = yes
socket address = 192.168.1.123
hosts allow = 127. 192.168.1.0/24
log file = /var/log/samba/log_srv.%m

smb ports = で別のポートを指定するのもいいかもしれません。

次に、認証関係。このままでは、デフォルトの samba サーバーと同じユーザー認証情報をみてしまうので追加の samba サーバーが別のユーザー DB を持てるように、passdb の位置を新たに指定します。

passdb backend = tdbsam:/var/lib/samba/private/passdb_srv2.tdb

smb.conf の Share Definitions セクションを追加の samba サーバー用に設定したら pdbedit でユーザーを追加します。-b オプションで DB タイプとそのパスを渡すことで、デフォルトの samba サーバーとは別の db に操作が可能です。

# pdbedit -b tdbsam:/var/lib/samba/private/passdb_srv2.tdb -a -u USERNAME

ここまできたら、一度起動してみます。

# smbd -D -s /etc/samba/smb_srv2.conf

確認

# netstat -antp | grep smb
tcp        0      0 192.168.0.200:445            0.0.0.0:*                   LISTEN  4336/smbd
tcp        0      0 192.168.1.123:445            0.0.0.0:*                   LISTEN  14669/smbd

192.168.1.123:445 が samba_srv2 です。クライアントから、192.168.1.123 へ SMB で接続し、さっき追加したユーザーでログインできることが確認できればOK。

右に出ているプロセスID でいったん samba_srv2 を停止。

# kill -9 11454

samba の起動スクリプトをコピーして samba srv2 向けのものを作成するといいと思いますが、一時的な利用なので今回はここまで。

2013年2月19日

CentOS で Air Video Server らへんについて

以前にCentOS で Air Video Server (alpha6) をつくるという記事を書いて、そこで rc スクリプトをでっち上げたのですが、いくつかの他の Blog さんでも利用されているようでした。

嬉しいやら恥ずかしいやら。ただ、あれは root で AirVideoServerLinux.jar を叩きますので、AirVideoServerLinux.jar や JAVA にセキュリティの問題があるととんでもないことなりかねません。特にグローバルIPで運用の場合は十分注意してご利用ください。

自分が記事にした時から AirVideo もバージョンが上がってますし、スクリプトも JAVA のインストール Path 指定をスマートに記載されていたりと内容が新しくなっているのでごらんくださいませ。

JAVA=`which java`

monitでAirVideo Server for Linuxを監視する。とかステキです。

そのうち最新版の AirVideo での記事をまた書きたいな。最新版はとてもパフォーマンスが良くなっていますよ。

2012年10月 3日

iCloud + SSH + dns-sd で自宅の iTunes へ接続

前回の記事、iCloud を利用して自宅の Mac へ SSH するの応用編です。

iCloud を利用して自宅の Mac へ SSH ができるなら、SSH の Port forwarding を利用して WAN 越しに自宅の iMac の iTunes 共有へアクセスできるんじゃないか?という実験です。結果から言うと、あっけなく出来ました。

続きを読む: iCloud + SSH + dns-sd で自宅の iTunes へ接続

iCloud を利用して自宅の Mac へ SSH する

結構有名ネタですが、次に書くネタの基礎になるのでメモ。iCloud で「どこでも My Mac」を有効にしていると、Apple から独自のグローバルのホスト名と IPv6 アドレスが割り当てられます。

これを利用すれば、自宅の Mac や遠隔地の iCloud に登録してある Mac へ SSH が可能というわけです。これは地味に便利です。

続きを読む: iCloud を利用して自宅の Mac へ SSH する

2011年5月16日

CentOS で Air Video Server (alpha6) をつくる

iPhone / iPad アプリの Air Video がかなり便利です。いつでもどこでも自宅のビデオをみれるのが最高。どんなアプリなのかは Google で検索してもらうとして、Linux 向けの Air Vide Server がリリースされていたのでインストールしてみました。

Air Vide には新しめの x264 が必要なので、Cenr OS 5系列 なら最新版を持ってきて make します。Cent OS 6 なら rpmforge の x264 が割と新しいんでそのままでいいと思います。

他にも Air Video 向けのパッチのあたった ffmpeg をインストールするので、ffmpeg x264 使っているソフトを利用しているなら、レポジトリでインストールした ffmpeg と x264 は残して、AirVideo Server 用に入れる ffmpeg と x264 は configure --prefix/foobar して make & make install するのがおすすめです。

以下の例では、/opt/airvide/ 配下にインストールしています。かなり変態的な入れ方です(chroot なイメージ)が /usr/ や /usr/local を汚さずに済みます。

続きを読む: CentOS で Air Video Server (alpha6) をつくる

2010年11月 4日

CentOS 5.5 へ kvm を導入-その4

CentOS 5.5 へ kvm を導入-その1 で、ブリッジインターフェイスをつくって eth0 のリンクアップを mii-tool で確認すると 100baseTx になっていた件。

ハブのリンクアップランプはちゃんと 1000baseTx になっている。おや?と思い ethtool で確認してみた。

# ethtool eth0
Settings for eth0:
	Supported ports: [ TP ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Advertised auto-negotiation: Yes
	Speed: 1000Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHYAD: 1
	Transceiver: internal
	Auto-negotiation: on
	Supports Wake-on: g
	Wake-on: g
	Current message level: 0x000000ff (255)
	Link detected: yes

ちゃんと、Speed: 1000Mb/s となっていた。mii-tool で確認したのがまずかった。
mii-tool は古いコマンドなので、ギガビットなNICに対応してないそうだ。

Linux で SATA のリンクアップ速度を確認する

Linux で SATA のリンクアップ速度を確認しようとしたが、イイ方法が見つからない。lshal コマンドでわかるかと思ったが、ダメだった。そういうときは、dmesg。

# dmesg | grep "SATA link"
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

チップセット的にも ML115 G1 のオンボードは SATA II (SATA 300) に対応しているコトがわかってひと安心。

2010年9月15日

CentOS 5.5 へ kvm を導入-その3

VM のインストールが終わって、ある程度環境を作ったらせっかくなのでスナップショットを作っておくことにする。

ちなみに、CentoS には qemu-img コマンドは2種類ある。qemu パッケージに入っている qemu-img コマンドではスナップショットを作ったりできない。また、後述する CoW (Copy on Write) 用のイメージ作ろうとするとイメージが壊れた。必ず kvm-qemu-img パッケージの qemu-img コマンドを使おう。

こういう混乱を避けるためにも他のディストリビューションでは kvm-qemu-img の qemu-img コマンドを kvm-img コマンドとしてるみたい。

まずは、シンプルにディスクイメージに対してスナップショットを作ってみる。

# qemu-img snapshot -c 20100915#1 Windows_XP.img

スナップショットの確認。

# qemu-img snapshot -l Windows_XP.img
Snapshot list:
ID        TAG                 VM SIZE                DATE       VM CLOCK
1         20100915#1                0 2010-09-15 09:12:50   00:00:00.000

スナップショットに書き戻す場合は以下の用に通り。

# qemu-img  snapshot -a 20100915#1 Windows_XP.img

スナップショットを削除するには以下の通り。

# qemu-img  snapshot -d 20100915#1 Windows_XP.img

さて、問題なくスナップショットが取れたのはいいけどスナップショットを作るのも、戻すのもかなり時間がかかる。それぞれ、15分以上待たされた。

それじゃあということで、CoW (Copy on Write) によるスナップショットを試すことに。

CoW (Copy on Write) はマスターのディスクイメージは読み込み専用になり、そのディスクイメージへの書き込みは別の差分ファイルに対して行われるというもの。

差分ディスクイメージを用意してあげれば、マスターディスクイメージに手を加えず、ディスクイメージへの変更は、差分ディスクイメージファイルに対して行われるようになる。

差分ディスクイメージを指定して起動すれば、変更は差分ディスクに記録されてマスターイメージを指定して起動すれば、すぐに戻れるという寸法。

複数のスナップショットを取りたい場合には向かないが、こちらの方が自分の使い方には向いている気がする。

差分ディスクイメージは qemu-img で作る。

# qemu-img create -b Windows_XP.img -f qcow2 Windows_XP.diff.img

/etc/libvirt/qemu/Windows_XP.xml の ブートディスクのパスを差分ディスクイメージに書き換える。

<source file="/var/lib/libvirt/images/Windows_XP.diff.img">

設定反映させればおしまい。

# virsh define /etc/libvirt/qemu/Windows_XP.xml

差分をマスターディスクにマージするには、以下のようにする。

qemu-img commit -f qcow2 Windows_XP.diff.img

しばらくコレで運用してみようと思います。

CentOS 5.5 へ kvm を導入-その2

ブリッジ接続している eth0 が 100baseTx になっているのは、とりあえずおいといてバーチャルマシンを作ることにする。

virt-manager で VM を作ると、ディスクのフォーマットが raw 形式になる。raw 形式のイメージは取り回しも便利でいいのだけど、qcow2 形式のディスクイメージの方がディスクの圧縮されるし、スナップショットが使えたりと便利。

なので、あらかじめ qcow2 形式のイメージを用意しておくか、virt-manager で VM 作成した後に変換しておく。

あらかじめ作っておく場合ならこんな感じで。

# qemu-img create -f qcow2 Windows_XP.img 32G

あとから変換するなら、こんな感じ。

# mv Windows_XP.img Windows_XP.img.tmp
# qemu-img convert Windows_XP.img.tmp -O qcow Windows_XP.img # rm Windows_XP.img.tmp

あとは、virt-manager で VM に OS のインストールなど実施。インストールが終わったら外部から VNC で接続できるように設定を変更。/etc/libvirt/qemu/Windows_XP.xml の graphics セクションを

<graphics type='vnc' port='-1' autoport='auto' listen='127.0.0.1' keymap='ja'/>

以下のように書き換える。

<graphics type='vnc' port='5950' autoport='no' listen='0.0.0.0' keymap='en-us'/>

これで、外部からホストOSの 5950番ポートへ VNC で接続すると VM が見れる。ウチはUSキーボードなのでキーマップも en-us へ書き換えておいた。xml を書き換えたら virsh define で設定を反映させる。

# virsh define  /etc/libvirt/qemu/Windows_XP.xml

VNC クライアントから接続するときの注意として、VNC クライアントの Encoding で Hextile を使わないこと。ウチの環境では Encoding に Hextile の指定があると画面ぐちゃぐちゃ。VNC クライアントも落ちたりした。

CentOS 5.5 へ kvm を導入-その1

VMware Server が色々とアレで先がないことがわかってきたので、どうしようか悩んだ結果知人の勧めもあって、kvm を本格的に導入し始めるコトにした。

まず、前提条件として現在 VMware Server 1.x で VM がいくつか稼働しているがこれらはマイグレーションせずに全部破棄。ただ、すぐには止められないので VMware Server 稼働したまま kvm をインストールしてみた。結果共存可能だった。

まぁ、まずはお約束の yum で必要なものをインストール。

# yum install install kvm kmod-kvm kvm-qemu-img libvirt virt-manager
<略>
# modprobe kvm
# modprobe kvm_amd
# lsmod | grep kvm
kvm_amd                69416  1
kvm                   226336  2 ksm,kvm_amd

これでまずは OK。ブリッジインターフェイスを作る。まずは、既存の eth0 をベースにするので、eth0 を br0 としてコピー。

# cd /etc/sysconfig/network-scripts
# cp ifcfg-eth0 ifcfg-br0

ifcfg-br0 を編集して、DEVICE= br0 に変更。TYPE=Bridge を追記。
次に、ifcfg-eth0 を編集して必要ない項目を削除して、ブリッジへ接続する。

DEVICE=eth0
HWADDR=XX:XX:XX:XX:XX:XX
ONBOOT=yes
BRIDGE=br0

ここらへんちょっとわかってないので、後日ちゃんと調べようと思う。

# /etc/init.d/network restart

ネットワークを再起動して、ifconfig してちゃんと動いているか確認したらオッケー。
最後に次にホストOSで自分以外のパケットも受け取るためにeth0をpromiscモードに設定する。

# ifconfig eth0 promisc

これで、OKのはず。なのだけど、ちょっと気になって eth0 のネゴシエーションされたリンク速度とリンク状態が気になったので確認してみた。

# mii-tool 
eth0: negotiated 100baseTx-FD flow-control, link ok

100baseTx になってるぞ?あれ?

ちゃんと確認したところ、1000baseTX になっていました。

mii-tool は古いコマンドなので、ギガビットなNICに対応してないそうだ。

このアーカイブについて

このページには、過去に書かれたブログ記事のうちLinuxカテゴリに属しているものが含まれています。

前のカテゴリはiOSです。

次のカテゴリはMacです。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。