さて、そういうわけで sagittarius を18.04LTS(リリース前バージョンだが)にバージョンアップしよう。
とりあえず、バージョンアップ直後にネットワーク関連の設定をいじる必要があるため、先にその設定を用意しておこう。
まずは sagittarius 上で netplan の設定ファイルを作っておこう。
ホームディレクトリ上に用意しておく。
(sagittarius) $ cd
(sagittarius) $ vi extsw.yaml
(IPアドレスやデバイス名は各自に合わせて設定するように)
--以下のように新規作成--
network:
version: 2
renderer: networkd
ethernets:
enp0s31f6:
match: {name: "enp0s31f6"}
wakeonlan: On
bridges:
extsw:
interfaces: [enp0s31f6]
dhcp4: false
addresses:
- 192.168.55.130/24
gateway4: 192.168.55.1
nameservers:
addresses: [192.168.55.1]
--ココまで--
準備が出来たら、16.04の状態で最新版にアップデートしておこう。
(カーネル類のバージョンアップがあったら、dist-upgrade でアップグレードしてしまおう)
(sagittarius) $ sudo apt-get update
(sagittarius) $ sudo apt-get --simulate upgrade
(sagittarius) $ sudo apt-get upgrade
アップデート出来たら、一旦再起動して、(現時点で)問題無いことを確認しておく。
(この段階で問題ないことを確認しておかないと、バージョンアップ後に問題が出ても、それがバージョンアップによる問題なのか、元々抱えていた問題なのか判断出来ないためだ。)
(合わせて、仮想マシンが稼働していたら全て落としておくこと)
(sagittarius) $ virsh list --all
(sagittarius) $ sudo systemctl reboot
(sagittarius) $ systemctl status
問題無ければ、バックアップを取っておく。
(sagittarius) $ sudo -i
(sagittarius) # cd backup/bin
(sagittarius) # ./0000_backup
(sagittarius) # exit
バックアップは、YYYYMMDDhhmmss という14桁の数字ディレクトリになっている。
バックアップツールは、この14桁のディレクトリの中で古いものを自動削除する設定にしている。
逆に言えば、このディレクトリ名を変更しておけば、自動削除対象から外れる、というわけだ。
今後のことを考えて、ディレクトリ名を変えておこう。
(sagittarius) $ sudo mount /media/backup
(sagittarius) $ cd /media/backup
(sagittarius) $ ls
最新のバックアップディレクトリを確認しておこう
(sagittarius) $ sudo mv (最新のバックアップディレクトリ名) (最新のバックアップディレクトリ名).1604fin
(sagittarius) $ ls
(sagittarius) $ cd
(sagittarius) $ sudo umount /media/backup
さて、いよいよバージョンアップだ。
ココからはコンソールから実行しよう。
(sagittarius) $ LANG=C sudo do-release-upgrade -d -c
(sagittarius) $ LANG=C sudo do-release-upgrade -d
途中で「/etc/default/libvirt-guests ファイルが、パッケージメンテナ版と違うけど、そのまま維持するか、パッケージ版を入れるか？」という質問が出てきた。
ホストOS(今回の場合、sagittarius)を停止させる時、その上のゲストOSにシャットダウンシグナルを送るか？という設定を加えていたため、その分の警告のようだ。
ココで書き加えている。
ON_SHUTDOWN=shutdown という行を書き加えているだけなので、今回は「パッケージメンテナの設定を採用する」として、後から ON_SHUTDOWN=shutdown を書き加えることにしよう。
続いて、sshd_config (/etc/ssh/sshd_config) についても同様に問い合わせが来た。
どうやら、16.04版と18.04版では大きく差があるようだ。
こちらも、パッケージメンテナ版を採用し、後ほどココで書き換えた内容を反映させることにしよう。
更に、/etc/apt/atp.conf.d/50unattended-upgrades というファイルで同様の問い合わせだ。
これも、ココで書き換えている。
こちらは「do a 3-way merge between available versions」というのが選択できる。
バージョン差異を上手いこと取り込んでくれる仕組みのようだ。
何をどう書き換えたかは、記録残してあるので、こちらはこの 3-way merge を選んでみよう。
次は /etc/lvm/lvm.conf だ。
新バージョンはコメントが大量に追加されている。この手のコメントは非常に重要なので取り込んでおきたい。
差分をよく見てみたら、
locking_type = 3 <-> locking_type = 1
use_lvmetad = 0 <-> use_lvmetad = 1
ぐらいが意味のある差異か。
lvmconf --enable-cluster を実行した時に出来た差異だ。
これも、一旦はパッケージメンテナのバージョンを導入し、後から必要な部分を変更することにしよう。
後は、不要なパッケージの削除だ。こちらも y で削除してしまう。
System upgrae is complete.
Restart required
To finish the upgrade, a restart is required.
If you select 'y' the system will be restarted.
Continue [yN]
終わったようだ。最後に y を押してリブートしよう。
さて…無事に起動してくるかな？
OSは何とか起動してきたが、networking.service と open-iscsi.service の起動に失敗しているようだ。
ネットワークの起動に失敗しているので、iscsi関連が失敗するのは当然。
う～ん。どうやら、openvswitch との兼ね合いのようだ。
この辺りは実は予想していた。
そもそも、openvswitchを起動する処理に手を加えて、 /etc/systemd/system/openvswitch-switch.service というファイルで配置していたからだ。と言っても、6秒の sleep を入れただけだったと思う。
バージョンアップによって、パッケージに入っている起動スクリプト(/lib/systemd/system/openvswitch-switch.service)も大きく変わっていて、起動処理に影響が出ている。
一旦、 /etc/systemd/system/openvswitch-switch.service の方は削除して、再度起動処理を見てみることにしよう。
(sagittarius) $ sudo rm /etc/systemd/system/openvswitch-switch.service
(sagittarius) $ sudo systemctl daemon-reload
(sagittarius) $ sudo systemctl reboot
再起動後、サービスを確認してみたら、networking.service は失敗しているがネットワークにはつながったようだ。
そして、openiscsi-service ではなく、corosync.service と lvm2-pvscan@*.service が失敗している。
恐らく、lvm2-pvscan の方はネットワークの起動に関連して失敗したのだろう。
まずは、networking.service の部分を修正する。
予め用意しておいた netplan 用の設定ファイルを配置しよう。
(sagittarius) $ ls -l /etc/netplan
(sagittarius) $ sudo cp extsw.yaml /etc/netplan/
(sagittarius) $ ls -l /etc/netplan
(sagittarius) $ sudo systemctl stop networking.service
(sagittarius) $ sudo systemctl disable networking.service
(sagittarius) $ sudo mkdir /etc/network/interfaces.d.bk
(sagittarius) $ sudo mv /etc/network/interfaces.d/* /etc/network/interfaces.d.bk/
(sagittarius) $ sudo netplan --debug generate
(sagittarius) $ sudo netplan apply
合わせて、名前解決の部分も systemd に直しておく。
(sagittarius) $ systemctl status resolvconf-pull-resolved.path
(sagittarius) $ sudo systemctl stop resolvconf-pull-resolved.path
(sagittarius) $ sudo systemctl disable resolvconf-pull-resolved.path
(sagittarius) $ systemctl status resolvconf-pull-resolved.path
(sagittarius) $ sudo systemctl daemon-reload
(sagittarius) $ sudo rm /etc/resolv.conf
(sagittarius) $ sudo ln -s ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
(sagittairus) $ ls -l /etc/resolv.conf
これで再起動をかけて確認してみよう。
(sagittarius) $ sudo systemctl reboot
(sagittarius) $ systemctl status
(sagittarius) $ dig www.yahoo.co.jp
(sagittarius) $ systemd-resolve --status
ネットワーク関連は問題無さそうだ。
ただし、corosync、dlm、lvm2-cluster-activation、lvm2-pvscan の4つが起動に失敗している。
ちょっと長くなってしまったので、この辺りは次のページで対処することにする。
おっといけない。
このままでは、外部から ssh でパスワード認証が通ってしまう。
セキュリティ的によろしく無いため、ssh だけは対処しておこう。
ココに合わせて設定しておこう。
(sagittarius) $ sudo vi /etc/ssh/sshd_config
--ココから
56行目付近
#PasswordAuthentication yes
↓
#PasswordAuthentication yes
PasswordAuthentication no
最終行に以下を追加(192.168.55.0/24は各自の環境に合わせること)
Match Address 192.168.55.0/24
PasswordAuthentication yes
Match Address 127.0.0.0/8
PasswordAuthentication yes
--ココまで
(sagittarius) $ sudo systemctl reload sshd
これで、外部からパスワード認証が通らなければOKだ。
さて、続きは次回。
2018年3月31日土曜日
2018年3月30日金曜日
Ubuntu1804検証
Ubuntu の 18.04 が、4月末にリリースされる。
今使っている16.04は既に2年程経っているから、18.04が出たらバージョンアップをしたいと思っている。
が、いきなり18.04にバージョンアップしようとしても大きく変更が入っているはずなので、色々トラブるはず。
そこで、まずは単純に、16.04→18.04のバージョンアップ検証をしてみたいと思う。
まずは、仮想環境にUbuntu16.04を導入し、openvswitch 導入と固定IP化、最新16.04へupgradeしておく。
その後、本来ならバックアップを取得しておくべきだが、今回は仮想環境を使用した検証なので、スナップショットを作っておくことにする。
新しいバージョンにアップグレードするコマンドは do-release-upgrade だが、まだ正式リリース版ではなく開発版のため、-d のオプションが必要になる。
sshでログインしての実行は、N/Wダウンなどのリスクがある。出来ればコンソールから実施しよう。(仮想マシンなら、virt-viewer 等を使用する。)
特に、今回の構成は ssh でログインするポートが openvswitch を経由する。openvswitch のアップデート等で ssh が切断される可能性もあるため、コンソールから作業しよう。
$ sudo apt-get update
$ sudo do-release-upgrade -d -c
$ LANG=C sudo do-release-upgrade -d
＃ssh でログインして実行している場合、安全のために追加で ssh を起動する、という確認が入る。そのまま y で継続して構わない。
パッケージ更新の確認で、いくつのパッケージが削除されるか？等の確認が入る。こちらもそのまま y で継続しよう。
途中で、/etc/default/grub の差分について確認の画面が入ることもある。そのままエンターでも、一つ上の「パッケージメンテナのバージョンをインストール(install the package maintainer's version)」でも構わない。
この後、暫く時間がかかる。数十分～数時間。ボーッとモニタを眺めていよう。
アップグレード後、不要なパッケージ(18.04では削除もしくは置き換えられたパッケージ)の削除をするか？と聞いてくる。HDDが無駄になるだけなので、削除してもいいだろう。
というか、どうせ後から削除するので、このタイミングで削除してしまおう。
作業が終わったら、再起動するか聞いてくる。再起動して反映させよう。
開発中のバージョンにアップデートしたため、まだ不具合が残っているかもしれない。
とりあえず、サービスだけは確認しておこう。
$ systemctl status
問題無ければ、念のために最新版にアップデートしておく。
(最新版を入れたはずなので、この数十分の間にパッケージが更新されて無ければ、何も更新は無いはずだ。)
$ sudo apt-get update
$ sudo apt-get --simulate upgrade
$ sudo apt-get upgrade
今回知ったのだが、パッケージ更新時にパッケージに含まれる設定ファイルのファイル名が変わる場合、古い(削除された)設定ファイルは残ってしまうようだ。
例えば、/etc/init/openvswitch-switch.conf。
このファイル、新しい openvswitch-switch パッケージには含まれていないが、16.04時代の openvswitch-switch パッケージには含まれている。
アップグレードすると、このファイルは削除されず、残ってしまう。
但し、「パッケージに含まれるファイル」という扱いではあるので、openvswitch-switch パッケージを削除する時には、一緒に削除してくれる。
つまり、素で18.04をインストールした時と、16.04から18.04にアップグレードした時とで、同じパッケージ構成にしていても、微妙にファイル数が異なる、ということだ。
害は無いが、ちょっと気にはなる。
まぁ対処しなくていいだろう。
さて、無事にアップデート出来たら、ちょっと手を出しておきたいところがある。
16.04の時、ネットワーク設定は ifupdown によって行われていた。
(/etc/network/interfaces 等を使用していた。)
どうやら、17.04か17.10から、ネットワーク設定はnetplan方式に変わったようだ。
(/etc/netplan ディレクトリが設定用ディレクトリ。)
アップグレード後でも、ifupdown 方式は使えるが、デフォルトが netplan 方式に変わったし、ifupdown 方式がいつ使えなくなるか(削除されるか)分からないので、今のうちにnetplan 方式に切り替えておこう。
＃他にも、デフォルトが変わったものがあるかもしれないが、今の所ネットワーク関連だけ分かっている。
ちなみにこの netplan、systemd に組み込まれているようで、systemd-networkd というサービスによって起動されるようだ。
というわけで、今までの ifupdown 方式から、 netplan 方式に切り替える。
切り替える前にもう一度バックアップ取っておこう。(仮想環境なので、スナップショットを取っておく。停止してからスナップショットを取るのが安全だ。)
netplan の設定ファイルは、/etc/netplan/*.yaml というファイルで、中身は yaml 形式とか。manをよく読んで作ってみる。
$ sudo vi /etc/netplan/extsw.yaml
--以下のように作成--
--ens3の部分は、物理I/Fのデバイス名だ--
--とりあえず、暫定仮想マシンで作っているのでens3になっている--
--IPアドレスも含めて、各自の環境に合わせてみて欲しい--
network:
version: 2
renderer: networkd
ethernets:
ens3:
match: {name: "ens3"}
bridges:
extsw:
interfaces: [ens3]
dhcp4: false
addresses:
- 192.168.55.143/24
gateway4: 192.168.55.1
nameservers:
addresses: [192.168.55.1]
--ココまで--
出来たらチェックしてみる。
$ sudo netplan --debug generate
特にエラーっぽいメッセージが出て無ければ、反映させてみよう。
ネットワークを一時的に止めるので、コンソールから実施すること。
まずは、今までの networking を止める。
$ sudo systemctl disable networking
$ sudo systemctl stop networking
$ sudo systemctl status networking
$ ip address show
そしたら、systemd-networkd からnetplanを起動してみる。
$ sudo systemctl status systemd-networkd
$ sudo systemctl start systemd-networkd
$ sudo systemctl enable systemd-networkd
$ sudo systemctl status systemd-networkd
$ ip address show
これでネットワークにつながったはずだ。
念のために、古い方の設定で起動しないように、古いファイルは退避しておこう。
$ sudo mkdir /etc/network/interfaces.d.bk
$ sudo mv -i /etc/network/interfaces.d/* /etc/network/interfaces.d.bk
再起動して確認してみる。
$ sudo systemctl reboot
$ ip address show
上手く行っているようだが…
$ systemctl status
$ systemctl --state=failed
どうやら、resolvconf-pull-resolved.serviceというサービスが起動に失敗しているようだ。
$ systemctl status resolvconf-pull-resolved.service
調べてみると、resolvconf関連はこのサービスの他にsystemd-resolved.serviceというのがある。
このサービスは、systemdパッケージに含まれているようだ。
どうやら、16.04にも含まれていて、他のサービスとの兼ね合いで無効化されていたっぽい。
networkingを無効にし、systemd-networkd を有効にしたことで、systemd-resolvedが有効化され、今までしようしていたresolvconf-pull-resolvedとバッティングしているようだ。
というわけで、resolvconf-pull-resolvedを無効化して再起動してみる。
$ sudo systemctl stop resolvconf-pull-resolved
っと、どうやらこのサービスは、resolvconf-pull-resolved.pathを止める必要があるようだ。
$ systemctl status resolvconf-pull-resolved.path
$ sudo systemctl stop resolvconf-pull-resolved.path
$ sudo systemctl disable resolvconf-pull-resolved.path
$ systemctl status resolvconf-pull-resolved.path
$ sudo systemctl reboot
$ systemctl status
一応、問題無さそうだ。
ところがこの状態では、名前解決に失敗する。
$ host www.yahoo.co.jp
/etc/hosts に記載されていない名前解決には、/etc/resolv.conf に記載されているネームサーバが使用される。
Debian / Ubuntu は、この /etc/resolv.conf は自動作成されるようになっている(厳密には、別のファイルが出来て、/etc/resolv.conf はそのファイルに対するシンボリックリンクだ)が、resolvconf-pull-resolvdを停止させたことで、/etc/resolv.conf の中身が空っぽになってしまった。
$ cat /etc/resolv.conf
$ ls -l /etc/resolv.conf
$ cat /run/resolvconf/resolv.conf
新しく稼働したsystemd-resolvedは、どうやら/run/systemd/resolveの下に、resolv.conf と stub-resolv.conf という2つのファイルを生成するようだ。
そして、/etc/resolv.conf は /run/systemd/resolve/stub-resolv.conf を指すようにすればいいらしい。
バージョンアップではなく、ダイレクトに18.04をインストールした環境を見たら、そのようになっていた。
(現在、18.04はまだ開発中で、インストール自体がうまくいかない可能性もある。この場合は、ちょっと古いインストールイメージを使用すると良い。)
このことから、/etc/resolv.conf を作り直してみる。
$ sudo rm /etc/resolv.conf
$ sudo ln -s ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
$ ls -l /etc/resolv.conf
$ cat /etc/resolv.conf
ネームサーバとして、127.0.0.53 を指していると思う。
この辺り、ちょっと特殊な作りになっていて、ローカルでネームサーバが起動、127.0.0.53で待受しているようだ。
そして、各クライアントアプリ(リゾルバ)は、ローカルのネームサーバに対して問い合わせを行う仕組みのようだ。
とりあえず、名前解決が出来るか確認してみよう。
$ host www.yahoo.co.jp
無事に名前解決出来たと思う。
再起動しても問題ないか、確認しておこう。
$ sudo systemctl reboot
$ systemctl status
$ host www.yahoo.co.jp
問題ないはずだ。
あと、networking.service と resolvconf-pull-resolvd は不要になったはずだ。
削除しておこう。
それぞれ、どのパッケージに入っているか再確認。
$ systemctl status networking.service
サービス定義ファイルが /lib/systemd/system/networking.service だということが確認できる。
$ dpkg -S /lib/systemd/system/networking.service
ifupdown に所属しているファイルだということが分かる。
一応、パッケージに所属しているファイルを一応見ておこう。
$ dpkg -L ifupdown
resolvconf-pull-resolvedについても同様に確認。
$ systemctl status resolvconf-pull-resolved
$ dpkg -S /lib/systemd/system/resolvconf-pull-resolved.service
$ dpkg -L resolvconf
削除してみよう。
削除に不安があるのなら、一度バックアップを取得しておけばいいだろう。(仮想環境なのでスナップショットをとっておく。)
では削除してみる。
$ sudo apt-get --simulate remove ifupdown resolvconf
一緒に ifenslave というパッケージも削除されるようだ。(パッケージの導入状態によっては、他にも削除されるものがあるかもしれない。)
bonding関連のようだが、netplanではteamingにて実現しているので、必要ないということだろう。
サクッと削除してみる。
$ sudo apt-get remove ifupdown resolvconf
再起動を促す画面が出てきた。
一応、再起動してからもう一度名前解決を確認しておく。
$ sudo systemctl reboot
$ systemctl status
$ host www.yahoo.co.jp
問題無ければ、不要となった設定情報も削除しておく。
$ sudo apt-get purge ifupdown resolvconf ifenslave
今回、16.04から18.04へのバージョンアップで、ネットワーク周りの変更が入っていたため、その変更を取り込む手順を確認した。
他にも変更が入っているかもしれないが、分かり次第取り込むことにしよう。
今使っている16.04は既に2年程経っているから、18.04が出たらバージョンアップをしたいと思っている。
が、いきなり18.04にバージョンアップしようとしても大きく変更が入っているはずなので、色々トラブるはず。
そこで、まずは単純に、16.04→18.04のバージョンアップ検証をしてみたいと思う。
まずは、仮想環境にUbuntu16.04を導入し、openvswitch 導入と固定IP化、最新16.04へupgradeしておく。
その後、本来ならバックアップを取得しておくべきだが、今回は仮想環境を使用した検証なので、スナップショットを作っておくことにする。
新しいバージョンにアップグレードするコマンドは do-release-upgrade だが、まだ正式リリース版ではなく開発版のため、-d のオプションが必要になる。
sshでログインしての実行は、N/Wダウンなどのリスクがある。出来ればコンソールから実施しよう。(仮想マシンなら、virt-viewer 等を使用する。)
特に、今回の構成は ssh でログインするポートが openvswitch を経由する。openvswitch のアップデート等で ssh が切断される可能性もあるため、コンソールから作業しよう。
$ sudo apt-get update
$ sudo do-release-upgrade -d -c
$ LANG=C sudo do-release-upgrade -d
＃ssh でログインして実行している場合、安全のために追加で ssh を起動する、という確認が入る。そのまま y で継続して構わない。
パッケージ更新の確認で、いくつのパッケージが削除されるか？等の確認が入る。こちらもそのまま y で継続しよう。
途中で、/etc/default/grub の差分について確認の画面が入ることもある。そのままエンターでも、一つ上の「パッケージメンテナのバージョンをインストール(install the package maintainer's version)」でも構わない。
この後、暫く時間がかかる。数十分～数時間。ボーッとモニタを眺めていよう。
アップグレード後、不要なパッケージ(18.04では削除もしくは置き換えられたパッケージ)の削除をするか？と聞いてくる。HDDが無駄になるだけなので、削除してもいいだろう。
というか、どうせ後から削除するので、このタイミングで削除してしまおう。
作業が終わったら、再起動するか聞いてくる。再起動して反映させよう。
開発中のバージョンにアップデートしたため、まだ不具合が残っているかもしれない。
とりあえず、サービスだけは確認しておこう。
$ systemctl status
問題無ければ、念のために最新版にアップデートしておく。
(最新版を入れたはずなので、この数十分の間にパッケージが更新されて無ければ、何も更新は無いはずだ。)
$ sudo apt-get update
$ sudo apt-get --simulate upgrade
$ sudo apt-get upgrade
今回知ったのだが、パッケージ更新時にパッケージに含まれる設定ファイルのファイル名が変わる場合、古い(削除された)設定ファイルは残ってしまうようだ。
例えば、/etc/init/openvswitch-switch.conf。
このファイル、新しい openvswitch-switch パッケージには含まれていないが、16.04時代の openvswitch-switch パッケージには含まれている。
アップグレードすると、このファイルは削除されず、残ってしまう。
但し、「パッケージに含まれるファイル」という扱いではあるので、openvswitch-switch パッケージを削除する時には、一緒に削除してくれる。
つまり、素で18.04をインストールした時と、16.04から18.04にアップグレードした時とで、同じパッケージ構成にしていても、微妙にファイル数が異なる、ということだ。
害は無いが、ちょっと気にはなる。
まぁ対処しなくていいだろう。
さて、無事にアップデート出来たら、ちょっと手を出しておきたいところがある。
16.04の時、ネットワーク設定は ifupdown によって行われていた。
(/etc/network/interfaces 等を使用していた。)
どうやら、17.04か17.10から、ネットワーク設定はnetplan方式に変わったようだ。
(/etc/netplan ディレクトリが設定用ディレクトリ。)
アップグレード後でも、ifupdown 方式は使えるが、デフォルトが netplan 方式に変わったし、ifupdown 方式がいつ使えなくなるか(削除されるか)分からないので、今のうちにnetplan 方式に切り替えておこう。
＃他にも、デフォルトが変わったものがあるかもしれないが、今の所ネットワーク関連だけ分かっている。
ちなみにこの netplan、systemd に組み込まれているようで、systemd-networkd というサービスによって起動されるようだ。
というわけで、今までの ifupdown 方式から、 netplan 方式に切り替える。
切り替える前にもう一度バックアップ取っておこう。(仮想環境なので、スナップショットを取っておく。停止してからスナップショットを取るのが安全だ。)
netplan の設定ファイルは、/etc/netplan/*.yaml というファイルで、中身は yaml 形式とか。manをよく読んで作ってみる。
$ sudo vi /etc/netplan/extsw.yaml
--以下のように作成--
--ens3の部分は、物理I/Fのデバイス名だ--
--とりあえず、暫定仮想マシンで作っているのでens3になっている--
--IPアドレスも含めて、各自の環境に合わせてみて欲しい--
network:
version: 2
renderer: networkd
ethernets:
ens3:
match: {name: "ens3"}
bridges:
extsw:
interfaces: [ens3]
dhcp4: false
addresses:
- 192.168.55.143/24
gateway4: 192.168.55.1
nameservers:
addresses: [192.168.55.1]
--ココまで--
出来たらチェックしてみる。
$ sudo netplan --debug generate
特にエラーっぽいメッセージが出て無ければ、反映させてみよう。
ネットワークを一時的に止めるので、コンソールから実施すること。
まずは、今までの networking を止める。
$ sudo systemctl disable networking
$ sudo systemctl stop networking
$ sudo systemctl status networking
$ ip address show
そしたら、systemd-networkd からnetplanを起動してみる。
$ sudo systemctl status systemd-networkd
$ sudo systemctl start systemd-networkd
$ sudo systemctl enable systemd-networkd
$ sudo systemctl status systemd-networkd
$ ip address show
これでネットワークにつながったはずだ。
念のために、古い方の設定で起動しないように、古いファイルは退避しておこう。
$ sudo mkdir /etc/network/interfaces.d.bk
$ sudo mv -i /etc/network/interfaces.d/* /etc/network/interfaces.d.bk
再起動して確認してみる。
$ sudo systemctl reboot
$ ip address show
上手く行っているようだが…
$ systemctl status
$ systemctl --state=failed
どうやら、resolvconf-pull-resolved.serviceというサービスが起動に失敗しているようだ。
$ systemctl status resolvconf-pull-resolved.service
調べてみると、resolvconf関連はこのサービスの他にsystemd-resolved.serviceというのがある。
このサービスは、systemdパッケージに含まれているようだ。
どうやら、16.04にも含まれていて、他のサービスとの兼ね合いで無効化されていたっぽい。
networkingを無効にし、systemd-networkd を有効にしたことで、systemd-resolvedが有効化され、今までしようしていたresolvconf-pull-resolvedとバッティングしているようだ。
というわけで、resolvconf-pull-resolvedを無効化して再起動してみる。
$ sudo systemctl stop resolvconf-pull-resolved
っと、どうやらこのサービスは、resolvconf-pull-resolved.pathを止める必要があるようだ。
$ systemctl status resolvconf-pull-resolved.path
$ sudo systemctl stop resolvconf-pull-resolved.path
$ sudo systemctl disable resolvconf-pull-resolved.path
$ systemctl status resolvconf-pull-resolved.path
$ sudo systemctl reboot
$ systemctl status
一応、問題無さそうだ。
ところがこの状態では、名前解決に失敗する。
$ host www.yahoo.co.jp
/etc/hosts に記載されていない名前解決には、/etc/resolv.conf に記載されているネームサーバが使用される。
Debian / Ubuntu は、この /etc/resolv.conf は自動作成されるようになっている(厳密には、別のファイルが出来て、/etc/resolv.conf はそのファイルに対するシンボリックリンクだ)が、resolvconf-pull-resolvdを停止させたことで、/etc/resolv.conf の中身が空っぽになってしまった。
$ cat /etc/resolv.conf
$ ls -l /etc/resolv.conf
$ cat /run/resolvconf/resolv.conf
新しく稼働したsystemd-resolvedは、どうやら/run/systemd/resolveの下に、resolv.conf と stub-resolv.conf という2つのファイルを生成するようだ。
そして、/etc/resolv.conf は /run/systemd/resolve/stub-resolv.conf を指すようにすればいいらしい。
バージョンアップではなく、ダイレクトに18.04をインストールした環境を見たら、そのようになっていた。
(現在、18.04はまだ開発中で、インストール自体がうまくいかない可能性もある。この場合は、ちょっと古いインストールイメージを使用すると良い。)
このことから、/etc/resolv.conf を作り直してみる。
$ sudo rm /etc/resolv.conf
$ sudo ln -s ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
$ ls -l /etc/resolv.conf
$ cat /etc/resolv.conf
ネームサーバとして、127.0.0.53 を指していると思う。
この辺り、ちょっと特殊な作りになっていて、ローカルでネームサーバが起動、127.0.0.53で待受しているようだ。
そして、各クライアントアプリ(リゾルバ)は、ローカルのネームサーバに対して問い合わせを行う仕組みのようだ。
とりあえず、名前解決が出来るか確認してみよう。
$ host www.yahoo.co.jp
無事に名前解決出来たと思う。
再起動しても問題ないか、確認しておこう。
$ sudo systemctl reboot
$ systemctl status
$ host www.yahoo.co.jp
問題ないはずだ。
あと、networking.service と resolvconf-pull-resolvd は不要になったはずだ。
削除しておこう。
それぞれ、どのパッケージに入っているか再確認。
$ systemctl status networking.service
サービス定義ファイルが /lib/systemd/system/networking.service だということが確認できる。
$ dpkg -S /lib/systemd/system/networking.service
ifupdown に所属しているファイルだということが分かる。
一応、パッケージに所属しているファイルを一応見ておこう。
$ dpkg -L ifupdown
resolvconf-pull-resolvedについても同様に確認。
$ systemctl status resolvconf-pull-resolved
$ dpkg -S /lib/systemd/system/resolvconf-pull-resolved.service
$ dpkg -L resolvconf
削除してみよう。
削除に不安があるのなら、一度バックアップを取得しておけばいいだろう。(仮想環境なのでスナップショットをとっておく。)
では削除してみる。
$ sudo apt-get --simulate remove ifupdown resolvconf
一緒に ifenslave というパッケージも削除されるようだ。(パッケージの導入状態によっては、他にも削除されるものがあるかもしれない。)
bonding関連のようだが、netplanではteamingにて実現しているので、必要ないということだろう。
サクッと削除してみる。
$ sudo apt-get remove ifupdown resolvconf
再起動を促す画面が出てきた。
一応、再起動してからもう一度名前解決を確認しておく。
$ sudo systemctl reboot
$ systemctl status
$ host www.yahoo.co.jp
問題無ければ、不要となった設定情報も削除しておく。
$ sudo apt-get purge ifupdown resolvconf ifenslave
今回、16.04から18.04へのバージョンアップで、ネットワーク周りの変更が入っていたため、その変更を取り込む手順を確認した。
他にも変更が入っているかもしれないが、分かり次第取り込むことにしよう。
2017年6月6日火曜日
cancer の IP固定化＆OpenvSwtich
続いて、cancer の IP を固定化する。
これ、ついでに OpenvSwitch も設定してしまう予定だ。
過去に何度か実施しているので、その辺りを探してみればいいけど、一応コマンド入れておく。
(cancer) $ ip link show
(cancer) $ sudo ovs-vsctl show
(cancer) $ sudo ovs-vsctl add-br extsw
(cancer) $ sudo ovs-vsctl show
(cancer) $ sudo vi /etc/default/networking
--ココから
1行編集
#EXCLUDE_INTERFACES=
↓
EXCLUDE_INTERFACES=extsw
--ココまで
(cancer) $ sudo vi /etc/network/interfaces.d/0110.ens3
--ココから
auto ens3
allow-extsw
iface ens3 inet manual
ovs_bridge extsw
ovs_type OVSPort
--ココまで
(cancer) $ sudo vi /etc/network/interfaces.d/0010.extsw
--ココから
auto extsw
allow-ovs extsw
iface extsw inet static
address 192.168.55.137
network 192.168.55.0
netmask 255.255.255.0
broadcast 192.168.55.255
gateway 192.168.55.1
ovs_type OVSBridge
ovs_ports ens3
dns-nameservers 192.168.55.1
--ココまで
(cancer) $ sudo ifdown ens3
(cancer) $ sudo vi /etc/network/interfaces
--ココから
2行コメント化
auto ens3
iface ens3 inet dhcp
↓
#auto ens3
#iface ens3 inet dhcp
--ココまで
(cancer) $ sudo ovs-vsctl add-port extsw ens3
(cancer) $ sudo ovs-vsctl show
(cancer) $ sudo ifup ens3
(cancer) $ sudo ifup extsw
(cancer) $ ip address show
(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl reboot
(cancer) $ ip address show
これで IP アドレスは元通りになったけど、ssh ホスト鍵が異なるので、ssh クライアントから接続する時にエラーになると思う。
クライアント側の known_hosts をいじることになるので、各クライアント毎に対処しよう。
あ、忘れてた。
合わせて、ssh鍵認証出来るように設定しておこう。
gemini の ~/.ssh/authorized_keys と同じ内容のファイルを、cancer 側の同じパスに作っておくだけでいいぞ。
これ、ついでに OpenvSwitch も設定してしまう予定だ。
過去に何度か実施しているので、その辺りを探してみればいいけど、一応コマンド入れておく。
(cancer) $ ip link show
(cancer) $ sudo ovs-vsctl show
(cancer) $ sudo ovs-vsctl add-br extsw
(cancer) $ sudo ovs-vsctl show
(cancer) $ sudo vi /etc/default/networking
--ココから
1行編集
#EXCLUDE_INTERFACES=
↓
EXCLUDE_INTERFACES=extsw
--ココまで
(cancer) $ sudo vi /etc/network/interfaces.d/0110.ens3
--ココから
auto ens3
allow-extsw
iface ens3 inet manual
ovs_bridge extsw
ovs_type OVSPort
--ココまで
(cancer) $ sudo vi /etc/network/interfaces.d/0010.extsw
--ココから
auto extsw
allow-ovs extsw
iface extsw inet static
address 192.168.55.137
network 192.168.55.0
netmask 255.255.255.0
broadcast 192.168.55.255
gateway 192.168.55.1
ovs_type OVSBridge
ovs_ports ens3
dns-nameservers 192.168.55.1
--ココまで
(cancer) $ sudo ifdown ens3
(cancer) $ sudo vi /etc/network/interfaces
--ココから
2行コメント化
auto ens3
iface ens3 inet dhcp
↓
#auto ens3
#iface ens3 inet dhcp
--ココまで
(cancer) $ sudo ovs-vsctl add-port extsw ens3
(cancer) $ sudo ovs-vsctl show
(cancer) $ sudo ifup ens3
(cancer) $ sudo ifup extsw
(cancer) $ ip address show
(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl reboot
(cancer) $ ip address show
これで IP アドレスは元通りになったけど、ssh ホスト鍵が異なるので、ssh クライアントから接続する時にエラーになると思う。
クライアント側の known_hosts をいじることになるので、各クライアント毎に対処しよう。
あ、忘れてた。
合わせて、ssh鍵認証出来るように設定しておこう。
gemini の ~/.ssh/authorized_keys と同じ内容のファイルを、cancer 側の同じパスに作っておくだけでいいぞ。
2017年5月16日火曜日
networking.service の設定変更
さて、今度は sagittarius / aquarius の networking.service の設定変更だ。
構築中に色々いじっていて、2台の間で設定が合っていないかもしれないけど、とりあえずは networking.service が無効化されている前提で書く。
sagittarius / aquarius のどちらも同じ作業なので、合わせて書く。
再起動が入るので、仮想マシンは停止しておく。
$ virsh list --all
起動している仮想マシンがあったら停止しておく。
自動起動ネットワークの一部無効化。
$ sudo vi /etc/default/networking
--ココから
#EXCLUDE_INTERFACES=
↓
EXCLUDE_INTERFACES=extsw
--ココまで
$ sudo systemctl daemon-reload
$ sudo systemctl is-enabled networking.service
$ sudo systemctl enable networking.service
$ sudo systemctl is-enabled networking.service
$ sudo systemctl reboot
これで終了。
次は、シャットダウン時に刺さる問題(OpenvSwitch と open-iscsi の起動停止順の制御)だ。
構築中に色々いじっていて、2台の間で設定が合っていないかもしれないけど、とりあえずは networking.service が無効化されている前提で書く。
sagittarius / aquarius のどちらも同じ作業なので、合わせて書く。
再起動が入るので、仮想マシンは停止しておく。
$ virsh list --all
起動している仮想マシンがあったら停止しておく。
自動起動ネットワークの一部無効化。
$ sudo vi /etc/default/networking
--ココから
#EXCLUDE_INTERFACES=
↓
EXCLUDE_INTERFACES=extsw
--ココまで
$ sudo systemctl daemon-reload
$ sudo systemctl is-enabled networking.service
$ sudo systemctl enable networking.service
$ sudo systemctl is-enabled networking.service
$ sudo systemctl reboot
これで終了。
次は、シャットダウン時に刺さる問題(OpenvSwitch と open-iscsi の起動停止順の制御)だ。
2017年3月14日火曜日
iSCSIボリュームのLVMが有効化されるまで(その3：多分完結)
--2017/04/20追記ココから--
ここで出ている問題は、前回分に追記した内容で解消したっぽい。
なので、無駄な記事になってしまった。
--2017/04/20追記ココまで--
悩んで悩んで悩んで、どうやら見当違いのところを調査していたらしい…。
まず、ネットワーク設定のディレクトリに、geminiを作成した時の設定情報が残っていた。
そのファイルがまず不要だったので削除する。
(gemini/cancerを作る時の基本的な手順は省略してしまっているが、ココのタイミングで作ったと思われるファイルだ…。)
(gemini) $ cd /etc/network/interfaces.d
(gemini) $ ls -l ens3
(gemini) $ sudo cat ens3
(gemini) $ sudo rm ens3
(gemini) $ ls -l
それから、ココやココではOpenvSwitchのブリッジにIPアドレスを付与しているように見えるが、どうやらこれは正しく無いようだ。
実際にはやはり、NICやNICから作るbondingに対して、IPを付与するようだ。
(確かに、違和感はあった。)
というわけで、ブリッジのIP定義ファイルとNICのIP定義ファイルを書き換える。
まずは、NICのIP定義ファイル。
(gemini) $ sudo vi 0110.ens3
--以下のように行を追加＆修正
auto ens3
allow-br-external
iface ens3 inet manual
ovs_bridge br-external
ovs_type OVSPort
↓(下線行を追加＆修正)
auto ens3
allow-br-external ens3
iface ens3 inet static
address 192.168.55.136
network 192.168.55.0
netmask 255.255.255.0
broadcast 192.168.55.255
gateway 192.168.55.1
ovs_bridge br-external
ovs_type OVSPort
dns-nameservers 192.168.55.1
--ココまで
続いて、ブリッジのIP定義ファイル
(gemini) $ sudo vi 0010.br-external
--以下のように修正＆行削除
auto br-external
allow-ovs br-external
iface br-external inet static
address 192.168.55.136
network 192.168.55.0
netmask 255.255.255.0
broadcast 192.168.55.255
gateway 192.168.55.1
ovs_type OVSBridge
ovs_ports ens3
dns-nameservers 192.168.55.1
↓
auto br-external
allow-ovs br-external
iface br-external inet manual
ovs_type OVSBridge
ovs_ports ens3
--ココまで
更に、ココの最後に無効化したnetworking.serviceはやはり必要なようなので、有効化しておく。
(gemini) $ systemctl is-enabled networking.service
(gemini) $ sudo systemctl enable networking.service
(少し時間かかってエラーになるかもしれないけど我慢だ)
(gemini) $ systemctl is-enabled networking.service
そうしたら再起動してみる。
(gemini) $ sudo shutdown -r now
起動してきたら確認。
(gemini) $ systemctl status
Failedが無くなった！
(gemini) $ sudo vgs
ちゃんと表示される…。
(gemini) $ sudo iscsiadm -m session
ログインできてる。
そうか…OpenvSwitchの設定をミスってただけなのか…。
やっと、長いこと悩んでいた原因が分かって修正方法も分かった…。
次回は、これにそってaquariusの修正を行う。
--2017/03/24追記
根本的に間違えていた。今はまだ調査を続行しているけど、↑の設定は根本的に誤り。
まだ対応方法は不明だけど、↑のやり方は間違いなので、元に戻しておいた方がいい。
ここで出ている問題は、前回分に追記した内容で解消したっぽい。
なので、無駄な記事になってしまった。
--2017/04/20追記ココまで--
悩んで悩んで悩んで、どうやら見当違いのところを調査していたらしい…。
まず、ネットワーク設定のディレクトリに、geminiを作成した時の設定情報が残っていた。
そのファイルがまず不要だったので削除する。
(gemini/cancerを作る時の基本的な手順は省略してしまっているが、ココのタイミングで作ったと思われるファイルだ…。)
(gemini) $ cd /etc/network/interfaces.d
(gemini) $ ls -l ens3
(gemini) $ sudo cat ens3
(gemini) $ sudo rm ens3
(gemini) $ ls -l
それから、ココやココではOpenvSwitchのブリッジにIPアドレスを付与しているように見えるが、どうやらこれは正しく無いようだ。
実際にはやはり、NICやNICから作るbondingに対して、IPを付与するようだ。
(確かに、違和感はあった。)
というわけで、ブリッジのIP定義ファイルとNICのIP定義ファイルを書き換える。
まずは、NICのIP定義ファイル。
(gemini) $ sudo vi 0110.ens3
--以下のように行を追加＆修正
auto ens3
allow-br-external
iface ens3 inet manual
ovs_bridge br-external
ovs_type OVSPort
↓(下線行を追加＆修正)
auto ens3
allow-br-external ens3
iface ens3 inet static
address 192.168.55.136
network 192.168.55.0
netmask 255.255.255.0
broadcast 192.168.55.255
gateway 192.168.55.1
ovs_bridge br-external
ovs_type OVSPort
dns-nameservers 192.168.55.1
--ココまで
続いて、ブリッジのIP定義ファイル
(gemini) $ sudo vi 0010.br-external
--以下のように修正＆行削除
auto br-external
allow-ovs br-external
iface br-external inet static
address 192.168.55.136
network 192.168.55.0
netmask 255.255.255.0
broadcast 192.168.55.255
gateway 192.168.55.1
ovs_type OVSBridge
ovs_ports ens3
dns-nameservers 192.168.55.1
↓
auto br-external
allow-ovs br-external
iface br-external inet manual
ovs_type OVSBridge
ovs_ports ens3
--ココまで
更に、ココの最後に無効化したnetworking.serviceはやはり必要なようなので、有効化しておく。
(gemini) $ systemctl is-enabled networking.service
(gemini) $ sudo systemctl enable networking.service
(少し時間かかってエラーになるかもしれないけど我慢だ)
(gemini) $ systemctl is-enabled networking.service
そうしたら再起動してみる。
(gemini) $ sudo shutdown -r now
起動してきたら確認。
(gemini) $ systemctl status
Failedが無くなった！
(gemini) $ sudo vgs
ちゃんと表示される…。
(gemini) $ sudo iscsiadm -m session
ログインできてる。
そうか…OpenvSwitchの設定をミスってただけなのか…。
やっと、長いこと悩んでいた原因が分かって修正方法も分かった…。
次回は、これにそってaquariusの修正を行う。
--2017/03/24追記
根本的に間違えていた。今はまだ調査を続行しているけど、↑の設定は根本的に誤り。
まだ対応方法は不明だけど、↑のやり方は間違いなので、元に戻しておいた方がいい。
2017年3月7日火曜日
実はちょっと問題が
今のウチの構成は、KVMホストとして使っている物理マシンが2台ある。
Intel NUCを使った弁当箱サイズのaquariusと、いわゆる自作マシンのミドルタワーサイズのsagittariusだ。
このマシンにUbuntu16.04を導入し、iSCSIイニシエータ、OpenvSwitch、KVM等を導入して運用している。
で、このマシン、実はシャットダウンやリブートで詰まる事象が起きている。
ファイルシステムアンマウント・ボリュームディアクティベートあたりで発生しているようで、多分「gfs2マウントについて(その1:自動マウント)」辺りと似たような問題だと睨んでいる。
ただ、仮想マシンではなく物理マシンのため、今までは見て見ぬふりをしていた。
再起動を伴う設定変更・確認は、物理マシンを相手にする場合は、物理マシンの直ぐ側にいないとリスキーなので。
ただ、仮想マシンでiSCSIが利用できることも確認できたので、仮想マシンで現象の再現、対応方法の確立をしようと思う。
とりあえず、gemini/cancer上でKVMを動かしたいので、一旦停止してgemini/cancerのCPU定義と割当メモリを変更する。
まずは停止。
(gemini) $ sudo shutdown -h now
(cancer) $ sudo shutdown -h now
停止しているのを確認して、両仮想マシンを編集。
(sagittarius) $ virsh list --all
(sagittarius) $ virsh edit gemini
(sagittarius) $ virsh edit cancer
gemini/cancerともに同じ修正を施す。
--ココから
4～5行目付近
<memory unit='KiB'>1048576</memory>
<currentMemory unit='KiB'>1048576</currentMemory>
↓(割当サイズを4GBにする)
<memory unit='KiB'>4194304</memory>
<currentMemory unit='KiB'>4194304</currentMemory>
17～18行目付近
<cpu mode='custom' match='exact'>
<model fallback='allow'>core2duo</model>
↓(CPUモデルをhost-modelに)
<cpu mode='host-model'>
<model fallback='allow'/>
--ココまで
ココまで出来たらgemini/cancerともに起動する。
(sagittarius) $ virsh start gemini
(sagittarius) $ virsh start cancer
後は、過去の内容を参照しながら作り込んでいく。(とりあえずgeminiに対してのみ更新。)
ざっとコマンド羅列。
(gemini) $ sudo apt-get update
(gemini) $ sudo apt-get install qemu-kvm
(gemini) $ sudo shutdown -r now
(gemini) $ grep kvm /etc/group
(gemini) $ id
(gemini) $ sudo adduser (自分のユーザ名) kvm
(gemini) $ grep kvm /etc/group
(一旦exitで抜けて、再度ログイン)
(gemini) $ id
(gemini) $ lsmod | grep kvm
(gemini) $ sudo apt-get install virtinst
(gemini) $ sudo apt-get install libosinfo-bin
再ログイン
(gemini) $ virsh list --all
(gemini) $ sudo apt-get install virt-manager
(gemini) $ sudo apt-get install fonts-ipafont
(gemini) $ sudo apt-get install openvswitch-switch
(gemini) $ sudo ovs-vsctl show
(gemini) $ sudo ovs-vsctl list-br
(gemini) $ sudo ovs-vsctl add-br br-external
(gemini) $ sudo ovs-vsctl show
(gemini) $ sudo ovs-vsctl list-br
(gemini) $ sudo vi /etc/network/interfaces.d/0110.ens3
ファイルの新規作成
--ココから--
auto ens3
allow-br-external
iface ens3 inet manual
ovs_bridge br-external
ovs_type OVSPort
--ココまで--
(gemini) $ sudo vi /etc/network/interfaces.d/0010.br-external
ファイルの新規作成
--ココから--
auto br-external
allow-ovs br-external
iface br-external inet static
address 192.168.55.136
network 192.168.55.0
netmask 255.255.255.0
broadcast 192.168.55.255
gateway 192.168.55.1
ovs_type OVSBridge
ovs_ports ens3
dns-nameservers 192.168.55.1
--ココまで--
--2017/04/14追記
ネットワークセッションが切れてしまうので、コンソールで作業しよう。
(gemini) $ sudo ifdown ens3
(gemini) $ sudo rm /etc/network/interfaces.d/ens3
(gemini) $ sudo ovs-vsctl add-port br-external ens3
(gemini) $ sudo ovs-vsctl show
(gemini) $ sudo ifup ens3
(gemini) $ sudo ifup br-external
--2017/04/14追記ココまで
--2017/04/20追記
このまま再起動させると、 OpenvSwitch/corosync/dlm/lvm2-cluster-activation の起動関連が上手く行かず、ハングしてしまう。
そのため、起動順の制御と、OpenvSwitchの起動時に、少しsleepを置くことにする。
(gemini) $ cd /lib/systemd/system
(gemini) $ sudo cp -pi corosync.service corosync.service.orig
(gemini) $ sudo cp -pi openvswitch-switch.service openvswitch-switch.service.orig
(gemini) $ sudo vi corosync.service
--ココから
Requires=network-online.target
After=network-online.target
↓(前提条件に openvswitch-switch.service を追加する)
Requires=network-online.target openvswitch-switch.service
After=network-online.target openvswitch-switch.service
--ココまで
(gemini) $ sudo vi openvswitch-switch.service
--ココから
ExecStart=/bin/true
↓(何も実行しない処理を、6秒待機に変更する)
ExecStart=/bin/sleep 6
--ココまで
変更内容を取り込む。
(gemini) $ sudo systemctl daemon-reload
(gemini) $ cd
--2017/04/20追記ココまで
(gemini) $ sudo shutdown -r now
(gemini) $ ip address show
(gemini) $ dig www.blogger.com
(gemini) $ sudo ovs-vsctl show
(gemini) $ virsh net-list --all
(gemini) $ vi ovsbridge.xml
ファイルの新規作成
--ここから
<network>
<name>ovsbridge</name>
<forward mode='bridge'/>
<bridge name='br-external'/>
<virtualport type='openvswitch'/>
</network>
--ここまで
(gemini) $ virsh net-define ovsbridge.xml
(gemini) $ virsh net-list --all
(gemini) $ virsh net-autostart ovsbridge
(gemini) $ virsh net-list --all
(gemini) $ virsh net-start ovsbridge
(gemini) $ virsh net-list --all
(gemini) $ sudo apt-get install ovmf
-------------------------------------------------------------
がーっと作ってしまったが、iSCSIのボリューム以外はだいたいホストOSと同じになったはず。
この状態で再起動が上手くいくか確認。
(gemini) $ sudo shutdown -r now
特に問題無さそうだ。
iSCSIストレージ装置で、新しくiSCSIターゲットを作成、100GBのLUNを新たに繋いで、geminiにのみ接続させておく。
/dev/sdb として認識された。
そのディスクを、ホストOSと同じように領域確保＆ファイルシステム作成する。
(gemini) $ sudo parted /dev/sdb print
(gemini) $ sudo parted /dev/sdb mklabel gpt
(gemini) $ sudo parted /dev/sdb mkpart primary ext4 0% 100%
(gemini) $ sudo parted /dev/sdb toggle 1 lvm
(gemini) $ sudo parted /dev/sdb print
(gemini) $ sudo pvcreate /dev/sdb1
(gemini) $ sudo vgcreate vg-kvm /dev/sdb1
(gemini) $ sudo vgchange -c n vg-kvm
(gemini) $ sudo vgdisplay -v vg-kvm
(gemini) $ sudo lvcreate -L 32M -n lv-etc-libvirt vg-kvm
(gemini) $ sudo lvcreate -L 50G -n lv-var-lib-libvirt vg-kvm
(gemini) $ sudo lvcreate -L 2G -n lv-var-log-libvirt vg-kvm
(gemini) $ sudo mkfs.ext4 /dev/vg-kvm/lv-etc-libvirt
(gemini) $ sudo mkfs.ext4 /dev/vg-kvm/lv-var-lib-libvirt
(gemini) $ sudo mkfs.ext4 /dev/vg-kvm/lv-var-log-libvirt
続いて、中身のコピー。
(gemini) $ sudo mkdir /tmp/libvirt
(gemini) $ sudo mount /dev/vg-kvm/lv-etc-libvirt /tmp/libvirt
(gemini) $ df /tmp/libvirt
(gemini) $ sudo -i
(gemini) # cd /etc
(gemini) # tar cSf - libvirt | ( cd /tmp ; tar xSf - )
(gemini) # ls -l /tmp/libvirt
(gemini) # ls -ld /tmp/libvirt /etc/libvirt
(gemini) # exit
(gemini) $ sudo umount /tmp/libvirt
(gemini) $ sudo rm -rf /etc/libvirt
(gemini) $ sudo mkdir /etc/libvirt
(gemini) $ sudo mount /dev/vg-kvm/lv-etc-libvirt /etc/libvirt
(gemini) $ df /etc/libvirt
(gemini) $ sudo mount /dev/vg-kvm/lv-var-lib-libvirt /tmp/libvirt
(gemini) $ df /tmp/libvirt
(gemini) $ sudo -i
(gemini) # cd /var/lib
(gemini) # tar cSf - libvirt | ( cd /tmp ; tar xSf - )
(gemini) # ls -l /tmp/libvirt
(gemini) # ls -ld /tmp/libvirt /var/lib/libvirt
(gemini) # exit
(gemini) $ sudo umount /tmp/libvirt
(gemini) $ sudo rm -rf /var/lib/libvirt
(gemini) $ sudo mkdir /var/lib/libvirt
(gemini) $ sudo mount /dev/vg-kvm/lv-var-lib-libvirt /var/lib/libvirt
(gemini) $ df /var/lib/libvirt
(gemini) $ sudo mount /dev/vg-kvm/lv-var-log-libvirt /tmp/libvirt
(gemini) $ df /tmp/libvirt
(gemini) $ sudo -i
(gemini) # cd /var/log
(gemini) # tar cSf - libvirt | ( cd /tmp ; tar xSf - )
(gemini) # ls -l /tmp/libvirt
(gemini) # ls -ld /tmp/libvirt /var/log/libvirt
(gemini) # exit
(gemini) $ sudo umount /tmp/libvirt
(gemini) $ sudo rm -rf /var/log/libvirt
(gemini) $ sudo mkdir /var/log/libvirt
(gemini) $ sudo mount /dev/vg-kvm/lv-var-log-libvirt /var/log/libvirt
(gemini) $ df /var/log/libvirt
(gemini) $ sudo rmdir /tmp/libvirt
fstabを更新
(gemini) $ sudo vi /etc/fstab
以下の行を追加
--ココから
/dev/mapper/vg--kvm-lv--etc--libvirt /etc/libvirt ext4 _netdev 0 0
/dev/mapper/vg--kvm-lv--var--lib--libvirt /var/lib/libvirt ext4 _netdev 0 0
/dev/mapper/vg--kvm-lv--var--log--libvirt /var/log/libvirt ext4 _netdev 0 0
--ココまで
(gemini) $ sudo umount /etc/libvirt
(gemini) $ sudo umount /var/log/libvirt
(gemini) $ sudo umount /var/lib/libvirt
(gemini) $ sudo mount -a
(gemini) $ df
自動アクティベート対象にする。
(gemini) $ sudo vi /etc/lvm/lvm.conf
--ココから
1156行目付近
auto_activation_volume_list = [ "gemini-vg" ]
↓項目追加
auto_activation_volume_list = [ "gemini-vg", "vg-kvm" ]
--ココまで
もう1つ、KVMホストは実はcifsマウントもしている。
(OSのisoメディアを配置するディスクはcifsにした。これなら別のWindowsマシンからも利用が可能だからだ。)
cifsマウント用のパッケージの導入
(gemini) $ sudo apt-get install cifs-utils
そのマウントポイントを作成する。
(gemini) $ sudo mkdir /mnt/iso-os
fstabに追記する。
(gemini) $ sudo vi /etc/fstab
以下の行を追記
--ココから
//(cifsのIPアドレス)/(cifsのディレクトリ) /mnt/iso-os cifs guest,_netdev 0 0
--ココまで
マウント確認
(gemini) $ sudo mount /mnt/iso-os
(gemini) $ df /mnt/iso-os
(gemini) $ sudo umount /mnt/iso-os
再起動してマウント状態の確認
(gemini) $ sudo shutdown -r now
(gemini) $ df
これでgeminiは、KVMホストのaquarius/sagittariusとほぼ同じ環境になったはずだ。
あれ…何度再起動しかけても、KVMホストマシンで発生している現象が起きない…な…。
そういえば、ココでnetworking.serviceを無効にしてたんだった。
それも適用してみよう。
(gemini) $ sudo systemctl stop networking.service
(gemini) $ sudo systemctl is-active networking.service
(gemini) $ sudo systemctl disable networking.service
(gemini) $ sudo systemctl is-enabled networking.service
--2017/04/20追記--
そもそも、 networking.service が failed になる理由だけど…。
今回、 OpenvSwitch で br-external という仮想スイッチ(仮想デバイス)を作成している。物理デバイスは存在しないデバイスだ。
networking.service は、 /etc/network/interfaces と /etc/network/interfaces.d/* で auto に指定されているデバイスは起動時に有効にしようとするが、 br-external は物理デバイスが無いため、 networking.service では有効に出来ない。(openvswitch-nonetwork.service にて有効にされる。)
networking.service が failed になる理由は、起動時に br-external を有効化しようとしてコケるからだ。
というわけで、 br-external は networking.service からは有効化されないように設定しよう。
(gemini) $ sudo cp -pi /etc/default/networking /etc/default/netwoking.orig
(gemini) $ sudo vi /etc/default/networking
--ココから
8行目付近
#EXCLUDE_INTERFACES=
↓(br-externalを指定)
EXCLUDE_INTERFACES=br-external
--ココまで
(gemini) $ sudo systemctl daemon-reload
networking.service は有効化しておこう。
(gemini) $ sudo systemctl enable networking.service
(gemini) $ sudo systemctl is-enabled networking.service
これで、再起動しても networking.service が failed になることは無いはずだ。
--2017/04/20追記ココまで--
--2017/04/20削除ココから--
これで再起動してみると…。再現した！というか、状況はもっと悪くて、vg-kvmがアクティベートされてない！？
なるほど、networking.serviceを無効にしたら停止や再起動で刺さったような状態になるのか…。
実際にaquariusで停止を実行しようとすると、cifsアンマウントやiSCSI領域のアンマウント前にOpenvSwitchが停止しているように見える。
cifsやiSCSIは、OpenvSwitchのネットワークを経由して接続している。これらの停止前にOpenvSwitchが停止してはマズいのだ。
しかし、networking.serviceを有効にすると、systemctlでFaild:1unitsになってしまう。
これはこれで問題だ。
どうすりゃいいんだろうか。
「gfs2マウントについて(その1:自動マウント)」辺りと同じように、x-systemd.requiresを設定して対応するのではないだろうか？
ちょっと長いのと、調査に時間がかかるので、ここで一旦記事を切ろう。
--2017/04/20削除ココまで--
Intel NUCを使った弁当箱サイズのaquariusと、いわゆる自作マシンのミドルタワーサイズのsagittariusだ。
このマシンにUbuntu16.04を導入し、iSCSIイニシエータ、OpenvSwitch、KVM等を導入して運用している。
で、このマシン、実はシャットダウンやリブートで詰まる事象が起きている。
ファイルシステムアンマウント・ボリュームディアクティベートあたりで発生しているようで、多分「gfs2マウントについて(その1:自動マウント)」辺りと似たような問題だと睨んでいる。
ただ、仮想マシンではなく物理マシンのため、今までは見て見ぬふりをしていた。
再起動を伴う設定変更・確認は、物理マシンを相手にする場合は、物理マシンの直ぐ側にいないとリスキーなので。
ただ、仮想マシンでiSCSIが利用できることも確認できたので、仮想マシンで現象の再現、対応方法の確立をしようと思う。
とりあえず、gemini/cancer上でKVMを動かしたいので、一旦停止してgemini/cancerのCPU定義と割当メモリを変更する。
まずは停止。
(gemini) $ sudo shutdown -h now
(cancer) $ sudo shutdown -h now
停止しているのを確認して、両仮想マシンを編集。
(sagittarius) $ virsh list --all
(sagittarius) $ virsh edit gemini
(sagittarius) $ virsh edit cancer
gemini/cancerともに同じ修正を施す。
--ココから
4～5行目付近
<memory unit='KiB'>1048576</memory>
<currentMemory unit='KiB'>1048576</currentMemory>
↓(割当サイズを4GBにする)
<memory unit='KiB'>4194304</memory>
<currentMemory unit='KiB'>4194304</currentMemory>
17～18行目付近
<cpu mode='custom' match='exact'>
<model fallback='allow'>core2duo</model>
↓(CPUモデルをhost-modelに)
<cpu mode='host-model'>
<model fallback='allow'/>
--ココまで
ココまで出来たらgemini/cancerともに起動する。
(sagittarius) $ virsh start gemini
(sagittarius) $ virsh start cancer
後は、過去の内容を参照しながら作り込んでいく。(とりあえずgeminiに対してのみ更新。)
ざっとコマンド羅列。
(gemini) $ sudo apt-get update
(gemini) $ sudo apt-get install qemu-kvm
(gemini) $ sudo shutdown -r now
(gemini) $ grep kvm /etc/group
(gemini) $ id
(gemini) $ sudo adduser (自分のユーザ名) kvm
(gemini) $ grep kvm /etc/group
(一旦exitで抜けて、再度ログイン)
(gemini) $ id
(gemini) $ lsmod | grep kvm
(gemini) $ sudo apt-get install virtinst
(gemini) $ sudo apt-get install libosinfo-bin
再ログイン
(gemini) $ virsh list --all
(gemini) $ sudo apt-get install virt-manager
(gemini) $ sudo apt-get install fonts-ipafont
(gemini) $ sudo apt-get install openvswitch-switch
(gemini) $ sudo ovs-vsctl show
(gemini) $ sudo ovs-vsctl list-br
(gemini) $ sudo ovs-vsctl add-br br-external
(gemini) $ sudo ovs-vsctl show
(gemini) $ sudo ovs-vsctl list-br
(gemini) $ sudo vi /etc/network/interfaces.d/0110.ens3
ファイルの新規作成
--ココから--
auto ens3
allow-br-external
iface ens3 inet manual
ovs_bridge br-external
ovs_type OVSPort
--ココまで--
(gemini) $ sudo vi /etc/network/interfaces.d/0010.br-external
ファイルの新規作成
--ココから--
auto br-external
allow-ovs br-external
iface br-external inet static
address 192.168.55.136
network 192.168.55.0
netmask 255.255.255.0
broadcast 192.168.55.255
gateway 192.168.55.1
ovs_type OVSBridge
ovs_ports ens3
dns-nameservers 192.168.55.1
--ココまで--
--2017/04/14追記
ネットワークセッションが切れてしまうので、コンソールで作業しよう。
(gemini) $ sudo ifdown ens3
(gemini) $ sudo rm /etc/network/interfaces.d/ens3
(gemini) $ sudo ovs-vsctl add-port br-external ens3
(gemini) $ sudo ovs-vsctl show
(gemini) $ sudo ifup ens3
(gemini) $ sudo ifup br-external
--2017/04/14追記ココまで
--2017/04/20追記
このまま再起動させると、 OpenvSwitch/corosync/dlm/lvm2-cluster-activation の起動関連が上手く行かず、ハングしてしまう。
- OpenvSwitchが完全に起動
- corosync起動
- dlm起動
- lvm2-cluster-activation起動
そのため、起動順の制御と、OpenvSwitchの起動時に、少しsleepを置くことにする。
(gemini) $ cd /lib/systemd/system
(gemini) $ sudo cp -pi corosync.service corosync.service.orig
(gemini) $ sudo cp -pi openvswitch-switch.service openvswitch-switch.service.orig
(gemini) $ sudo vi corosync.service
--ココから
Requires=network-online.target
After=network-online.target
↓(前提条件に openvswitch-switch.service を追加する)
Requires=network-online.target openvswitch-switch.service
After=network-online.target openvswitch-switch.service
--ココまで
(gemini) $ sudo vi openvswitch-switch.service
--ココから
ExecStart=/bin/true
↓(何も実行しない処理を、6秒待機に変更する)
ExecStart=/bin/sleep 6
--ココまで
変更内容を取り込む。
(gemini) $ sudo systemctl daemon-reload
(gemini) $ cd
--2017/04/20追記ココまで
(gemini) $ sudo shutdown -r now
(gemini) $ ip address show
(gemini) $ dig www.blogger.com
(gemini) $ sudo ovs-vsctl show
(gemini) $ virsh net-list --all
(gemini) $ vi ovsbridge.xml
ファイルの新規作成
--ここから
<network>
<name>ovsbridge</name>
<forward mode='bridge'/>
<bridge name='br-external'/>
<virtualport type='openvswitch'/>
</network>
--ここまで
(gemini) $ virsh net-define ovsbridge.xml
(gemini) $ virsh net-list --all
(gemini) $ virsh net-autostart ovsbridge
(gemini) $ virsh net-list --all
(gemini) $ virsh net-start ovsbridge
(gemini) $ virsh net-list --all
(gemini) $ sudo apt-get install ovmf
-------------------------------------------------------------
がーっと作ってしまったが、iSCSIのボリューム以外はだいたいホストOSと同じになったはず。
この状態で再起動が上手くいくか確認。
(gemini) $ sudo shutdown -r now
特に問題無さそうだ。
iSCSIストレージ装置で、新しくiSCSIターゲットを作成、100GBのLUNを新たに繋いで、geminiにのみ接続させておく。
/dev/sdb として認識された。
そのディスクを、ホストOSと同じように領域確保＆ファイルシステム作成する。
(gemini) $ sudo parted /dev/sdb print
(gemini) $ sudo parted /dev/sdb mklabel gpt
(gemini) $ sudo parted /dev/sdb mkpart primary ext4 0% 100%
(gemini) $ sudo parted /dev/sdb toggle 1 lvm
(gemini) $ sudo parted /dev/sdb print
(gemini) $ sudo pvcreate /dev/sdb1
(gemini) $ sudo vgcreate vg-kvm /dev/sdb1
(gemini) $ sudo vgchange -c n vg-kvm
(gemini) $ sudo vgdisplay -v vg-kvm
(gemini) $ sudo lvcreate -L 32M -n lv-etc-libvirt vg-kvm
(gemini) $ sudo lvcreate -L 50G -n lv-var-lib-libvirt vg-kvm
(gemini) $ sudo lvcreate -L 2G -n lv-var-log-libvirt vg-kvm
(gemini) $ sudo mkfs.ext4 /dev/vg-kvm/lv-etc-libvirt
(gemini) $ sudo mkfs.ext4 /dev/vg-kvm/lv-var-lib-libvirt
(gemini) $ sudo mkfs.ext4 /dev/vg-kvm/lv-var-log-libvirt
続いて、中身のコピー。
(gemini) $ sudo mkdir /tmp/libvirt
(gemini) $ sudo mount /dev/vg-kvm/lv-etc-libvirt /tmp/libvirt
(gemini) $ df /tmp/libvirt
(gemini) $ sudo -i
(gemini) # cd /etc
(gemini) # tar cSf - libvirt | ( cd /tmp ; tar xSf - )
(gemini) # ls -l /tmp/libvirt
(gemini) # ls -ld /tmp/libvirt /etc/libvirt
(gemini) # exit
(gemini) $ sudo umount /tmp/libvirt
(gemini) $ sudo rm -rf /etc/libvirt
(gemini) $ sudo mkdir /etc/libvirt
(gemini) $ sudo mount /dev/vg-kvm/lv-etc-libvirt /etc/libvirt
(gemini) $ df /etc/libvirt
(gemini) $ sudo mount /dev/vg-kvm/lv-var-lib-libvirt /tmp/libvirt
(gemini) $ df /tmp/libvirt
(gemini) $ sudo -i
(gemini) # cd /var/lib
(gemini) # tar cSf - libvirt | ( cd /tmp ; tar xSf - )
(gemini) # ls -l /tmp/libvirt
(gemini) # ls -ld /tmp/libvirt /var/lib/libvirt
(gemini) # exit
(gemini) $ sudo umount /tmp/libvirt
(gemini) $ sudo rm -rf /var/lib/libvirt
(gemini) $ sudo mkdir /var/lib/libvirt
(gemini) $ sudo mount /dev/vg-kvm/lv-var-lib-libvirt /var/lib/libvirt
(gemini) $ df /var/lib/libvirt
(gemini) $ sudo mount /dev/vg-kvm/lv-var-log-libvirt /tmp/libvirt
(gemini) $ df /tmp/libvirt
(gemini) $ sudo -i
(gemini) # cd /var/log
(gemini) # tar cSf - libvirt | ( cd /tmp ; tar xSf - )
(gemini) # ls -l /tmp/libvirt
(gemini) # ls -ld /tmp/libvirt /var/log/libvirt
(gemini) # exit
(gemini) $ sudo umount /tmp/libvirt
(gemini) $ sudo rm -rf /var/log/libvirt
(gemini) $ sudo mkdir /var/log/libvirt
(gemini) $ sudo mount /dev/vg-kvm/lv-var-log-libvirt /var/log/libvirt
(gemini) $ df /var/log/libvirt
(gemini) $ sudo rmdir /tmp/libvirt
fstabを更新
(gemini) $ sudo vi /etc/fstab
以下の行を追加
--ココから
/dev/mapper/vg--kvm-lv--etc--libvirt /etc/libvirt ext4 _netdev 0 0
/dev/mapper/vg--kvm-lv--var--lib--libvirt /var/lib/libvirt ext4 _netdev 0 0
/dev/mapper/vg--kvm-lv--var--log--libvirt /var/log/libvirt ext4 _netdev 0 0
--ココまで
(gemini) $ sudo umount /etc/libvirt
(gemini) $ sudo umount /var/log/libvirt
(gemini) $ sudo umount /var/lib/libvirt
(gemini) $ sudo mount -a
(gemini) $ df
自動アクティベート対象にする。
(gemini) $ sudo vi /etc/lvm/lvm.conf
--ココから
1156行目付近
auto_activation_volume_list = [ "gemini-vg" ]
↓項目追加
auto_activation_volume_list = [ "gemini-vg", "vg-kvm" ]
--ココまで
もう1つ、KVMホストは実はcifsマウントもしている。
(OSのisoメディアを配置するディスクはcifsにした。これなら別のWindowsマシンからも利用が可能だからだ。)
cifsマウント用のパッケージの導入
(gemini) $ sudo apt-get install cifs-utils
そのマウントポイントを作成する。
(gemini) $ sudo mkdir /mnt/iso-os
fstabに追記する。
(gemini) $ sudo vi /etc/fstab
以下の行を追記
--ココから
//(cifsのIPアドレス)/(cifsのディレクトリ) /mnt/iso-os cifs guest,_netdev 0 0
--ココまで
マウント確認
(gemini) $ sudo mount /mnt/iso-os
(gemini) $ df /mnt/iso-os
(gemini) $ sudo umount /mnt/iso-os
再起動してマウント状態の確認
(gemini) $ sudo shutdown -r now
(gemini) $ df
これでgeminiは、KVMホストのaquarius/sagittariusとほぼ同じ環境になったはずだ。
あれ…何度再起動しかけても、KVMホストマシンで発生している現象が起きない…な…。
そういえば、ココでnetworking.serviceを無効にしてたんだった。
それも適用してみよう。
(gemini) $ sudo systemctl stop networking.service
(gemini) $ sudo systemctl is-active networking.service
(gemini) $ sudo systemctl disable networking.service
(gemini) $ sudo systemctl is-enabled networking.service
--2017/04/20追記--
そもそも、 networking.service が failed になる理由だけど…。
今回、 OpenvSwitch で br-external という仮想スイッチ(仮想デバイス)を作成している。物理デバイスは存在しないデバイスだ。
networking.service は、 /etc/network/interfaces と /etc/network/interfaces.d/* で auto に指定されているデバイスは起動時に有効にしようとするが、 br-external は物理デバイスが無いため、 networking.service では有効に出来ない。(openvswitch-nonetwork.service にて有効にされる。)
networking.service が failed になる理由は、起動時に br-external を有効化しようとしてコケるからだ。
というわけで、 br-external は networking.service からは有効化されないように設定しよう。
(gemini) $ sudo cp -pi /etc/default/networking /etc/default/netwoking.orig
(gemini) $ sudo vi /etc/default/networking
--ココから
8行目付近
#EXCLUDE_INTERFACES=
↓(br-externalを指定)
EXCLUDE_INTERFACES=br-external
--ココまで
(gemini) $ sudo systemctl daemon-reload
networking.service は有効化しておこう。
(gemini) $ sudo systemctl enable networking.service
(gemini) $ sudo systemctl is-enabled networking.service
これで、再起動しても networking.service が failed になることは無いはずだ。
--2017/04/20追記ココまで--
--2017/04/20削除ココから--
--2017/04/20削除ココまで--
2017年2月17日金曜日
networking.service停止
ちょっと前のお話。
詳細は把握してないんだけど、ネットワークをOpenvswitchで管理するようにしたら、networking.serviceが起動しない状態になった。
これ、正しい状態だと思う。(ネットワークの管理がnetworkingサービスじゃなくなったってことで。)
なので、networking.serviceは停止しておいた方がいいだろう。
(sagittarius) $ systemctl status networking.service
(sagittarius) $ sudo systemctl stop networking.service
(sagittarius) $ sudo systemctl disable networking.service
(sagittarius) $ systemctl status networking.service
(aquarius) $ systemctl status networking.service
(aquarius) $ sudo systemctl stop networking.service
(aquarius) $ sudo systemctl disable networking.service
(aquarius) $ systemctl status networking.service
KVMホスト2台分だけ実施したけど、KVMゲストでも必要に応じて停止しておこう。
ただ何となく、ネットワークインターフェースを増やしたり、管理方法変えていくと、networking.serviceもまた起動しないといけない気がする…。
--2017/04/20追記ココから--
ココで対処しているけど、実際は networking.service を停止させるのではなく、 /etc/default/networking ファイルを書き換えて対応するのが正のようだ。
--2017/04/20追記ココまで--
詳細は把握してないんだけど、ネットワークをOpenvswitchで管理するようにしたら、networking.serviceが起動しない状態になった。
これ、正しい状態だと思う。(ネットワークの管理がnetworkingサービスじゃなくなったってことで。)
なので、networking.serviceは停止しておいた方がいいだろう。
(sagittarius) $ systemctl status networking.service
(sagittarius) $ sudo systemctl stop networking.service
(sagittarius) $ sudo systemctl disable networking.service
(sagittarius) $ systemctl status networking.service
(aquarius) $ systemctl status networking.service
(aquarius) $ sudo systemctl stop networking.service
(aquarius) $ sudo systemctl disable networking.service
(aquarius) $ systemctl status networking.service
KVMホスト2台分だけ実施したけど、KVMゲストでも必要に応じて停止しておこう。
ただ何となく、ネットワークインターフェースを増やしたり、管理方法変えていくと、networking.serviceもまた起動しないといけない気がする…。
--2017/04/20追記ココから--
ココで対処しているけど、実際は networking.service を停止させるのではなく、 /etc/default/networking ファイルを書き換えて対応するのが正のようだ。
--2017/04/20追記ココまで--
2016年10月5日水曜日
sshのエージェント転送を使おう！
ゲストOSのpisces/ariesは、物理的にはホストOSであるaquariusの中に入っているけど、Open vSwitchのブリッジのお陰でネットワーク的にはaquariusや他のPCとフラットな関係にある。
そのため、作業用の端末を家のLANに繋いでいる場合、pisces/ariesへは直接sshログインが出来る。
ところが、外から接続する場合、今はルータの設定上、一度aquariusにログインした後、pisces/ariesへログインするという、sshを多段に通す必要がある。
ルータの設定で、pisces/ariesへポート転送すれば、外からも直接アクセス出来るようになるんだが、あまり穴を空けすぎるのも危険なので、外から接続する時は、aquariusを経由しなければならない制約は我慢することにする。
で、sshの鍵の配置について考えてみよう。
作業用端末を家のLANに直接繋いでいる状態で、pisces/ariesへ直接ログインする場合、作業用端末のssh公開鍵をpisces/ariesへ登録しておけばいい。
これは、sshで接続＠鍵認証で行った公開鍵の登録と同じ作業を行うということだ。
作業用端末が外にあって、外からaquariusにsshログインし、そのセッションからpisces/ariesへsshログインする場合は？
普通に考えれば、aquariusで鍵ペアを作成し、その公開鍵をpisces/ariesに登録すればいいと思う。
この場合、作業端末で作成した鍵ペアと、aquariusで作成した鍵ペア、両方を管理しないといけなくなる。
今はまだいいが、将来増えてくると、ちょっと管理しきれなくなる。
そこで出て来るのが「エージェント転送」という機能だ。
エージェント転送は、sshで接続＠Agent認証その2の最後に名前だけ出している。ようやく、解説と実装する機会が来た、というわけだ。
エージェント転送とは…
sshの鍵認証のやり取り部分を、もう一つ手前のsshセッションに任せる、という感じの仕組みとなる。
文章だと分かりにくいが以下の図を見ればわかると思う。
つまり、踏み台になっているaquariusで鍵ペアを作る必要はなく、作業用端末で持っている秘密鍵で認証が出来るわけだ。
これなら、複数の鍵ペアを管理する必要は無い、だけでなくpisces/ariesへ直接ログインする時も、aquariusを経由してログインする時も、同じ鍵を使って認証出来る。
これを実現するためには、条件が2つある。
一つは、言うまでもなく、最終接続先であるpisces/ariesに、作業端末の公開鍵が登録されていることだ。
もう一つは、作業端末→aquariusの接続で、エージェント転送を許可していることだ。
それぞれ実装しよう。
まずは、pisces/ariesに公開鍵を登録する。
これは、sshで接続＠鍵認証と同じ手順でいいのだが、既にaquariusに登録されている鍵を、そのままpisces/ariesへ持っていって登録すればいい。
以下の手順で実施しよう。
piscesへ登録
(aquarius)$ scp .ssh/authorized_keys 192.168.55.133:~/authorized_keys.aquarius
(aquarius)$ ssh 192.168.55.133
(pisces)$ mkdir .ssh
(pisces)$ chmod 700 .ssh
(pisces)$ cat authorized_keys.aquarius >> .ssh/authorized_keys
(pisces)$ rm authorized_keys.aquarius
(pisces)$ exit
ariesへ登録
(aquarius)$ scp .ssh/authorized_keys 192.168.55.134:~/authorized_keys.aquarius
(aquarius)$ ssh 192.168.55.134
(aries)$ mkdir .ssh
(aries)$ chmod 700 .ssh
(aries)$ cat authorized_keys.aquarius >> .ssh/authorized_keys
(aries)$ rm authorized_keys.aquarius
(aries)$ exit
次は、作業端末→aquariusの接続でエージェント転送を許可、だ。
これは、teratermからのsshログイン時、ユーザ名を入力するダイアログにある「エージェント転送する(O)」にチェックボックスを入れておくだけでいい。
一旦ログアウトして、再度ログインする時にチェックを入れよう。
そこまで準備が整ったら、エージェント転送の確認だ。
既にaquariusへはログインしていると思うので、そこからpisces/ariesへログインしてみよう。
(aquarius)$ ssh 192.168.55.133
もしくは
(aquarius)$ ssh 192.168.55.134
「エージェント転送要求を受け入れますか？」というダイアログが出てきたと思う。
このダイアログに対して、「はい(Y)」を選択してみよう。
パスワードを入力することもなく、ログインすることが出来たはずだ。
これによって、鍵ペアを複数管理する必要もなく、ログインパスワードを入力する必要もなく、多段ログインが出来るようになった。
更に、作業端末を家のLANに直結して、pisces/ariesへ直接ログインする時も、パスワード認証をせずにログインが出来るようになったぞ。
というところで、今回のsshエージェントに関してはオシマイ。
そのため、作業用の端末を家のLANに繋いでいる場合、pisces/ariesへは直接sshログインが出来る。
ところが、外から接続する場合、今はルータの設定上、一度aquariusにログインした後、pisces/ariesへログインするという、sshを多段に通す必要がある。
ルータの設定で、pisces/ariesへポート転送すれば、外からも直接アクセス出来るようになるんだが、あまり穴を空けすぎるのも危険なので、外から接続する時は、aquariusを経由しなければならない制約は我慢することにする。
で、sshの鍵の配置について考えてみよう。
作業用端末を家のLANに直接繋いでいる状態で、pisces/ariesへ直接ログインする場合、作業用端末のssh公開鍵をpisces/ariesへ登録しておけばいい。
これは、sshで接続＠鍵認証で行った公開鍵の登録と同じ作業を行うということだ。
作業用端末が外にあって、外からaquariusにsshログインし、そのセッションからpisces/ariesへsshログインする場合は？
普通に考えれば、aquariusで鍵ペアを作成し、その公開鍵をpisces/ariesに登録すればいいと思う。
この場合、作業端末で作成した鍵ペアと、aquariusで作成した鍵ペア、両方を管理しないといけなくなる。
今はまだいいが、将来増えてくると、ちょっと管理しきれなくなる。
そこで出て来るのが「エージェント転送」という機能だ。
エージェント転送は、sshで接続＠Agent認証その2の最後に名前だけ出している。ようやく、解説と実装する機会が来た、というわけだ。
エージェント転送とは…
sshの鍵認証のやり取り部分を、もう一つ手前のsshセッションに任せる、という感じの仕組みとなる。
文章だと分かりにくいが以下の図を見ればわかると思う。
つまり、踏み台になっているaquariusで鍵ペアを作る必要はなく、作業用端末で持っている秘密鍵で認証が出来るわけだ。
これなら、複数の鍵ペアを管理する必要は無い、だけでなくpisces/ariesへ直接ログインする時も、aquariusを経由してログインする時も、同じ鍵を使って認証出来る。
これを実現するためには、条件が2つある。
一つは、言うまでもなく、最終接続先であるpisces/ariesに、作業端末の公開鍵が登録されていることだ。
もう一つは、作業端末→aquariusの接続で、エージェント転送を許可していることだ。
それぞれ実装しよう。
まずは、pisces/ariesに公開鍵を登録する。
これは、sshで接続＠鍵認証と同じ手順でいいのだが、既にaquariusに登録されている鍵を、そのままpisces/ariesへ持っていって登録すればいい。
以下の手順で実施しよう。
piscesへ登録
(aquarius)$ scp .ssh/authorized_keys 192.168.55.133:~/authorized_keys.aquarius
(aquarius)$ ssh 192.168.55.133
(pisces)$ mkdir .ssh
(pisces)$ chmod 700 .ssh
(pisces)$ cat authorized_keys.aquarius >> .ssh/authorized_keys
(pisces)$ rm authorized_keys.aquarius
(pisces)$ exit
ariesへ登録
(aquarius)$ scp .ssh/authorized_keys 192.168.55.134:~/authorized_keys.aquarius
(aquarius)$ ssh 192.168.55.134
(aries)$ mkdir .ssh
(aries)$ chmod 700 .ssh
(aries)$ cat authorized_keys.aquarius >> .ssh/authorized_keys
(aries)$ rm authorized_keys.aquarius
(aries)$ exit
次は、作業端末→aquariusの接続でエージェント転送を許可、だ。
これは、teratermからのsshログイン時、ユーザ名を入力するダイアログにある「エージェント転送する(O)」にチェックボックスを入れておくだけでいい。
一旦ログアウトして、再度ログインする時にチェックを入れよう。
そこまで準備が整ったら、エージェント転送の確認だ。
既にaquariusへはログインしていると思うので、そこからpisces/ariesへログインしてみよう。
(aquarius)$ ssh 192.168.55.133
もしくは
(aquarius)$ ssh 192.168.55.134
「エージェント転送要求を受け入れますか？」というダイアログが出てきたと思う。
このダイアログに対して、「はい(Y)」を選択してみよう。
パスワードを入力することもなく、ログインすることが出来たはずだ。
これによって、鍵ペアを複数管理する必要もなく、ログインパスワードを入力する必要もなく、多段ログインが出来るようになった。
更に、作業端末を家のLANに直結して、pisces/ariesへ直接ログインする時も、パスワード認証をせずにログインが出来るようになったぞ。
というところで、今回のsshエージェントに関してはオシマイ。
2016年9月30日金曜日
piscesとariesのIPを固定化しよう
とりあえず、piscesとariesが、aquariusやその他のマシンとフラットなネットワークに接続されるようになった。
aquariusや別途動かしているWindows機(コレ、将来作り変えてOSも変えるツモリだけど)は固定IPにして運用している。
piscesやariesは、今後の検証作業でサーバとしてかなりガッツリ稼働してもらうことになるので、固定IPにしておいた方が色々便利だ。
そのため、IPアドレスを固定にする。
それぞれ、以下のアドレスを割り当てる予定だ。
2環境とも、OSはubuntu 14.04 LTSのため、その流儀に従うことになる。
OSがubuntu 16.04のaquariusとは若干異なる。
というわけで設定。
まずはpiscesから。
(pisces)$ sudo vi /etc/network/interfaces
末尾、primary network interfaceの宣言部を、以下のように更新しよう。
--ココから
# The primary network interface
auto eth0
iface eth0 inet dhcp
↓
# The primary network interface
auto eth0
#iface eth0 inet dhcp
iface eth0 inet static
address 192.168.55.133
netmask 255.255.255.0
network 192.168.55.0
broadcast 192.168.55.255
gateway 192.168.55.1
dns-nameservers 192.168.55.1
--ココまで
ファイルが作成し終わったら、piscesを再起動して確認だ。
(pisces)$ sudo shutdown -r now
(pisces)$ ip address show
(pisces)$ dig news.google.co.jp
上手く反映されていたら、同じ作業をariesにも実施だ。
設定ファイル(/etc/network/interfaces)のaddress宣言だけ、192.168.55.134にするだけで、後の作業は全く同じはずだ。
pisces、ariesともに固定IP化出来たら、今回はおしまい。
aquariusや別途動かしているWindows機(コレ、将来作り変えてOSも変えるツモリだけど)は固定IPにして運用している。
piscesやariesは、今後の検証作業でサーバとしてかなりガッツリ稼働してもらうことになるので、固定IPにしておいた方が色々便利だ。
そのため、IPアドレスを固定にする。
それぞれ、以下のアドレスを割り当てる予定だ。
| ホスト名 | IPアドレス |
|---|---|
| pisces | 192.168.55.133/24 |
| aries | 192.168.55.134/24 |
2環境とも、OSはubuntu 14.04 LTSのため、その流儀に従うことになる。
OSがubuntu 16.04のaquariusとは若干異なる。
というわけで設定。
まずはpiscesから。
(pisces)$ sudo vi /etc/network/interfaces
末尾、primary network interfaceの宣言部を、以下のように更新しよう。
--ココから
# The primary network interface
auto eth0
iface eth0 inet dhcp
↓
# The primary network interface
auto eth0
#iface eth0 inet dhcp
iface eth0 inet static
address 192.168.55.133
netmask 255.255.255.0
network 192.168.55.0
broadcast 192.168.55.255
gateway 192.168.55.1
dns-nameservers 192.168.55.1
--ココまで
ファイルが作成し終わったら、piscesを再起動して確認だ。
(pisces)$ sudo shutdown -r now
(pisces)$ ip address show
(pisces)$ dig news.google.co.jp
上手く反映されていたら、同じ作業をariesにも実施だ。
設定ファイル(/etc/network/interfaces)のaddress宣言だけ、192.168.55.134にするだけで、後の作業は全く同じはずだ。
pisces、ariesともに固定IP化出来たら、今回はおしまい。
2016年9月28日水曜日
Open vSwitchのREADME
Open vSwitchを調べていた時、どうも情報量が少なく感じた。
それもあって、中々設定が出来なかった。
で、よくよく考えてみたら、UbuntuのベースであるDebian GNU/Linuxは、ドキュメント類もある程度揃っていることを思い出した。
なので、そのドキュメントをチェックしてみればヨカッタ。
ドキュメントは、以下のpathに存在している。(パッケージはopenvswitch-switch(2.5.0-0ubuntu1)のものを見ている。)
/usr/share/doc/openvswitch-switch/README.Debian.gz
で、コイツは英語で書かれているので、以下にメモとして記載するのと併せて、超意訳しておくことにする。
--ココから
README.Debian for openvswitch-switch
---------------------------------
The Linux kernel 3.3 or later has an integrated Open vSwitch kernel module. Theis Linux kernel module lacks a few features that are in the third-party module. For details, please see the FAQ, "What features are not available in the Open vSwitch kernel datapath that ships as part of the upstream Linux kernel?". If you need the additional features, you will need to build and install a Linux kernel module by hand from the openvswitch source package.
Linuxカーネル3.3以降の便利なOpen vSwitchのカーネルモジュールがあります。これらのLinuxカーネルモジュールは、サードパーティのモジュールにあるいくつかの機能を欠いています。詳細については、「What features are not available in the Open vSwitch kernel datapath that ships as part of the upstream Linux kernel?」というFAQをご覧ください。これらの機能が必要な場合は、openvswitchソースパッケージからLinuxカーネルモジュールの構築とインストールする必要があります。
Debian network scripts integration
----------------------------------
This package lets a user to optionally configure Open vSwitch bridges and ports from /etc/network/interfaces. Please refer to the interfaces(5) manpage for more details regarding /etc/network/interfaces.
Open vSwitchのブリッジとポート設定を、どのように/etc/network/interfacesへ記載するのか、そのオプションについて記述しています。その他の/etc/network/interfacesの記載内容については、interfaces(5)のman pageを参照してください。
The stanzas that configure the OVS bridges should begin with "allow-ovs" followed by name of the bridge. Here is an example.
allow-ovs br0
OVSブリッジを設定をするには、"allow-ovs"で始まり、対象ブリッジの名前が続く記述が必要です。こちらは一例です。
allow-ovs br0
The stanzas that configure the OVS ports should begin with "allow-${bridge-name}" followed by name of the port. Here is an example.
allow-br0 eth0
OVSポートを設定するには、"allow-ブリッジ名"で始まり、ポートの名前が続く記述になります。こちらは一例です。
allow-br0 eth0
The following OVS specific "command" options are supported:
これらの定義には、以下に記載するコマンドオプションがあります。
- ovs_type: This can either be OVSBridge, OVSPort, OVSIntPort, OVSBond, OVSPatchPort or OVSTunnel depending on whether you configure a bridge, port, an internal port, a bond, a patch port or a tunnel. This is a required option.
- ovs_type: 設定する対象を指定します。設定したい内容に応じてOVSBridge、OVSPort、OVSIntPort、OVSBond、OVSPatchPortまたはOVSTunnelのいずれかを指定します。これは必須です。
- ovs_ports: This option specifies all the ports that belong to a bridge.
- ovs_ports: このオプションでは、ブリッジに属するすべてのポートを指定します。
- ovs_bridge: This options specifies a bridge to which a port belongs. This is a required option for a port.
- ovs_bridge: このオプションは、ポートが所属するブリッジを指定します。これは、ポートの必須オプションです。
- ovs_bonds: This option specifies the list of physical interfaces to be bonded together.
- ovs_bonds: このオプションは、複数の物理インターフェイスをbondする場合に使用します。複数の物理インターフェースを指定することで、結合された1つのインターフェースに出来ます。
- ovs_patch_peer: For "OVSPatchPort" interfaces, this field specifies the patch's peer on the other bridge.
- ovs_patch_peer: ovs_typeが"OVSPatchPort"の場合、このフィールドは、他のbridgeを指定することで、そのスイッチと結合出来ます。
- ovs_tunnel_type: For "OVSTunnel" interfaces, the type of the tunnel. For example, "gre", "vxlan", etc.
- ovs_tunnel_type: ovs_typeが"OVSTunnel"の場合、"gre"、"vxlan"など、そのトンネルの種類を指定します。
- ovs_tunnel_options: For "OVSTunnel" interfaces, this field should be used to specify the tunnel options like remote_ip, key, etc.
- ovs_tunnel_options: "OVSTunnel"の場合、このフィールドはREMOTE_IP、キーなどのようなトンネルオプションを指定します。
- ovs_options: This option lets you add extra arguments to a ovs-vsctl command. See examples.
- ovs_options: このオプションは、ovs-vsctlコマンドに追加の引数を追加することができます。例を参照してください。
- ovs_extra: This option lets you run additional ovs-vsctl commands, separated by "--" (double dash). Variables can be part of the "ovs_extra" option. You can provide all the standard environmental variables described in the interfaces(5) man page. You can also pass shell commands.
- ovs_extra: このオプションにより、"--"(ハイフン2つ)で区切られた、追加のOVS-vsctlコマンドを実行することができます。変数は"ovs_extra"オプションの一部とすることができます。interfaces(5)のマニュアルページに記載されているすべての標準環境変数を提供することができます。また、シェルコマンドを渡すことができます。
More implementation specific details can be seen in the examples.
いくつかの例を挙げておきます。
Examples:
--------
ex 1: A standalone bridge.
(単純なブリッジの例。物理インターフェースへの接続が無いローカルブリッジになります。)
allow-ovs br0
iface br0 inet static
address 192.168.1.1
netmask 255.255.255.0
ovs_type OVSBridge
ex 2: A bridge with one port.
(単純なブリッジの例。物理インターフェース:eth0が接続されています。)
allow-ovs br0
iface br0 inet dhcp
ovs_type OVSBridge
ovs_ports eth0
allow-br0 eth0
iface eth0 inet manual
ovs_bridge br0
ovs_type OVSPort
ex 3: A bridge with multiple physical ports.
(複数の物理インターフェースを接続したブリッジの例。bondingではありません。)
allow-ovs br0
iface br0 inet dhcp
ovs_type OVSBridge
ovs_ports eth0 eth1
allow-br0 eth0
iface eth0 inet manual
ovs_bridge br0
ovs_type OVSPort
allow-br0 eth1
iface eth1 inet manual
ovs_bridge br0
ovs_type OVSPort
ex 4: A bridge with an OVS internal port.
(VLANタグを持ったスイッチの例。)
allow-ovs br1
iface br1 inet static
address 192.168.1.1
netmask 255.255.255.0
ovs_type OVSBridge
ovs_ports vlan100
allow-br1 vlan100
iface vlan100 inet manual
ovs_bridge br1
ovs_type OVSIntPort
ovs_options tag=100
ovs_extra set interface ${IFACE} external-ids:iface-id=$(hostname -s)
ex 5: Bonding.
(bonding例。eth2とeth3でbondingを組んだ形になります。)
allow-ovs br2
iface br2 inet static
address 192.170.1.1
netmask 255.255.255.0
ovs_type OVSBridge
ovs_ports bond0
allow-br2 bond0
iface bond0 inet manual
ovs_bridge br2
ovs_type OVSBond
ovs_bonds eth2 eth3
ovs_options bond_mode=balance-tcp lacp=active
ex 6: Patch ports.
(Patch portを使用した例。br0のpatch0ポートと、br1のpatch1ポートが接続されています。)
allow-ovs br0
iface br0 inet manual
ovs_type OVSBridge
ovs_ports patch0
allow-br0 patch0
iface patch0 inet manual
ovs_bridge br0
ovs_type OVSPatchPort
ovs_patch_peer patch1
allow-ovs br1
iface br1 inet manual
ovs_type OVSBridge
ovs_ports patch1
allow-br1 patch1
iface patch1 inet manual
ovs_bridge br1
ovs_type OVSPatchPort
ovs_patch_peer patch0
ex 7: Tunnel.
(トンネルモードの例)
allow-ovs br1
iface br1 inet static
address 192.168.1.1
netmask 255.255.255.0
ovs_type OVSBridge
ovs_ports gre1
allow-br1 gre1
iface gre1 inet manual
ovs_bridge br1
ovs_type OVSTunnel
ovs_tunnel_type gre
ovs_tunnel_options options:remote_ip=182.168.1.2 options:key=1
ex 8: Create and destroy bridges.
(ブリッジを作成・削除するコマンド例。)
ifup --allow=ovs $list_of_bridges
ifdown --allow=ovs $list_of_bridges
-- Ben Pfaff <pfaffben@debian.org>, Tue, 19 Aug 2014 08:29:32 -0700
Notes on dependencies:
---------------------
openvswitch-switch depends on $network, $named $remote_fs and $syslog to start. This creates some startup dependency issues.
openvswitchスイッチは$network、$named、$remote_fs、$syslogに依存します。これらは、起動時に問題が発生する要因となりえます。
* Since openvswitch utilities are placed in /usr and /usr can be mounted through NFS, openvswitch has to start after it. But if a user uses openvswitch for all his networking needs and hence to mount NFS, there will be a deadlock. So, if /usr is mounted through NFS and openvswitch is used for all networking, the administrator should figure out a way to mount NFS before starting OVS. One way to do this is in initramfs.
* Open vSwitchコマンド類は、/usr 以下に配置されます。そのため、/usr がNFSマウントの場合にデッドロック等の問題を引き起こします。それらの問題を回避するには、/usr がNFSマウントされてから Open vSwitchを起動する方法を検討する必要があります。initramfs等を使用することで回避が可能になります。
* Since openvswitch starts after $network, $remote_fs and $syslog, any startup script that depends on openvswitch but starts before it, needs to be changed to depend on openvswitch-switch too.
* openvswitchは$network、$remote_fs、$syslog、openvswitch及び各種スタートアップスクリプトに依存します。Open vSwitchは任意の起動スクリプトの後に起動するようにすべきかもしれません。
* Ideally, an admin should not add openvswitch bridges in the 'auto' section of the 'interfaces' file. This is because, when ifupdown starts working on bridges listed in 'auto', openvswitch has not yet started.
* 基本的に、管理者は、"interfaces"ファイルのautoセクションにopenvswitchブリッジを追加してはいけません。 Open vSwitchがまだ起動していないタイミングで、ifupdownが開始されてしまいます。
But, if the admin wants to go down this route and adds openvswitch bridges in the 'auto' section, openvswitch-switch will forcefully be started when ifupdown kicks in. In a case like this, the admin needs to make sure that /usr has already been mounted and that a remote $syslog (if used) is ready to receive openvswitch logs.
Open vSwitchをautoセクションに入れた場合、ifupdownが起動するときにOpen vSwitchが強制的に起動されます。このようにしたい場合は、/usr が先にマウントされるように構成する必要があります。また、syslogサーバを使用している場合、そのサーバがsyslogメッセージを受け入れるように構成する必要があります。
それもあって、中々設定が出来なかった。
で、よくよく考えてみたら、UbuntuのベースであるDebian GNU/Linuxは、ドキュメント類もある程度揃っていることを思い出した。
なので、そのドキュメントをチェックしてみればヨカッタ。
ドキュメントは、以下のpathに存在している。(パッケージはopenvswitch-switch(2.5.0-0ubuntu1)のものを見ている。)
/usr/share/doc/openvswitch-switch/README.Debian.gz
で、コイツは英語で書かれているので、以下にメモとして記載するのと併せて、超意訳しておくことにする。
--ココから
README.Debian for openvswitch-switch
---------------------------------
The Linux kernel 3.3 or later has an integrated Open vSwitch kernel module. Theis Linux kernel module lacks a few features that are in the third-party module. For details, please see the FAQ, "What features are not available in the Open vSwitch kernel datapath that ships as part of the upstream Linux kernel?". If you need the additional features, you will need to build and install a Linux kernel module by hand from the openvswitch source package.
Linuxカーネル3.3以降の便利なOpen vSwitchのカーネルモジュールがあります。これらのLinuxカーネルモジュールは、サードパーティのモジュールにあるいくつかの機能を欠いています。詳細については、「What features are not available in the Open vSwitch kernel datapath that ships as part of the upstream Linux kernel?」というFAQをご覧ください。これらの機能が必要な場合は、openvswitchソースパッケージからLinuxカーネルモジュールの構築とインストールする必要があります。
Debian network scripts integration
----------------------------------
This package lets a user to optionally configure Open vSwitch bridges and ports from /etc/network/interfaces. Please refer to the interfaces(5) manpage for more details regarding /etc/network/interfaces.
Open vSwitchのブリッジとポート設定を、どのように/etc/network/interfacesへ記載するのか、そのオプションについて記述しています。その他の/etc/network/interfacesの記載内容については、interfaces(5)のman pageを参照してください。
The stanzas that configure the OVS bridges should begin with "allow-ovs" followed by name of the bridge. Here is an example.
allow-ovs br0
OVSブリッジを設定をするには、"allow-ovs"で始まり、対象ブリッジの名前が続く記述が必要です。こちらは一例です。
allow-ovs br0
The stanzas that configure the OVS ports should begin with "allow-${bridge-name}" followed by name of the port. Here is an example.
allow-br0 eth0
OVSポートを設定するには、"allow-ブリッジ名"で始まり、ポートの名前が続く記述になります。こちらは一例です。
allow-br0 eth0
The following OVS specific "command" options are supported:
これらの定義には、以下に記載するコマンドオプションがあります。
- ovs_type: This can either be OVSBridge, OVSPort, OVSIntPort, OVSBond, OVSPatchPort or OVSTunnel depending on whether you configure a bridge, port, an internal port, a bond, a patch port or a tunnel. This is a required option.
- ovs_type: 設定する対象を指定します。設定したい内容に応じてOVSBridge、OVSPort、OVSIntPort、OVSBond、OVSPatchPortまたはOVSTunnelのいずれかを指定します。これは必須です。
- ovs_ports: This option specifies all the ports that belong to a bridge.
- ovs_ports: このオプションでは、ブリッジに属するすべてのポートを指定します。
- ovs_bridge: This options specifies a bridge to which a port belongs. This is a required option for a port.
- ovs_bridge: このオプションは、ポートが所属するブリッジを指定します。これは、ポートの必須オプションです。
- ovs_bonds: This option specifies the list of physical interfaces to be bonded together.
- ovs_bonds: このオプションは、複数の物理インターフェイスをbondする場合に使用します。複数の物理インターフェースを指定することで、結合された1つのインターフェースに出来ます。
- ovs_patch_peer: For "OVSPatchPort" interfaces, this field specifies the patch's peer on the other bridge.
- ovs_patch_peer: ovs_typeが"OVSPatchPort"の場合、このフィールドは、他のbridgeを指定することで、そのスイッチと結合出来ます。
- ovs_tunnel_type: For "OVSTunnel" interfaces, the type of the tunnel. For example, "gre", "vxlan", etc.
- ovs_tunnel_type: ovs_typeが"OVSTunnel"の場合、"gre"、"vxlan"など、そのトンネルの種類を指定します。
- ovs_tunnel_options: For "OVSTunnel" interfaces, this field should be used to specify the tunnel options like remote_ip, key, etc.
- ovs_tunnel_options: "OVSTunnel"の場合、このフィールドはREMOTE_IP、キーなどのようなトンネルオプションを指定します。
- ovs_options: This option lets you add extra arguments to a ovs-vsctl command. See examples.
- ovs_options: このオプションは、ovs-vsctlコマンドに追加の引数を追加することができます。例を参照してください。
- ovs_extra: This option lets you run additional ovs-vsctl commands, separated by "--" (double dash). Variables can be part of the "ovs_extra" option. You can provide all the standard environmental variables described in the interfaces(5) man page. You can also pass shell commands.
- ovs_extra: このオプションにより、"--"(ハイフン2つ)で区切られた、追加のOVS-vsctlコマンドを実行することができます。変数は"ovs_extra"オプションの一部とすることができます。interfaces(5)のマニュアルページに記載されているすべての標準環境変数を提供することができます。また、シェルコマンドを渡すことができます。
More implementation specific details can be seen in the examples.
いくつかの例を挙げておきます。
Examples:
--------
ex 1: A standalone bridge.
(単純なブリッジの例。物理インターフェースへの接続が無いローカルブリッジになります。)
allow-ovs br0
iface br0 inet static
address 192.168.1.1
netmask 255.255.255.0
ovs_type OVSBridge
ex 2: A bridge with one port.
(単純なブリッジの例。物理インターフェース:eth0が接続されています。)
allow-ovs br0
iface br0 inet dhcp
ovs_type OVSBridge
ovs_ports eth0
allow-br0 eth0
iface eth0 inet manual
ovs_bridge br0
ovs_type OVSPort
ex 3: A bridge with multiple physical ports.
(複数の物理インターフェースを接続したブリッジの例。bondingではありません。)
allow-ovs br0
iface br0 inet dhcp
ovs_type OVSBridge
ovs_ports eth0 eth1
allow-br0 eth0
iface eth0 inet manual
ovs_bridge br0
ovs_type OVSPort
allow-br0 eth1
iface eth1 inet manual
ovs_bridge br0
ovs_type OVSPort
ex 4: A bridge with an OVS internal port.
(VLANタグを持ったスイッチの例。)
allow-ovs br1
iface br1 inet static
address 192.168.1.1
netmask 255.255.255.0
ovs_type OVSBridge
ovs_ports vlan100
allow-br1 vlan100
iface vlan100 inet manual
ovs_bridge br1
ovs_type OVSIntPort
ovs_options tag=100
ovs_extra set interface ${IFACE} external-ids:iface-id=$(hostname -s)
ex 5: Bonding.
(bonding例。eth2とeth3でbondingを組んだ形になります。)
allow-ovs br2
iface br2 inet static
address 192.170.1.1
netmask 255.255.255.0
ovs_type OVSBridge
ovs_ports bond0
allow-br2 bond0
iface bond0 inet manual
ovs_bridge br2
ovs_type OVSBond
ovs_bonds eth2 eth3
ovs_options bond_mode=balance-tcp lacp=active
ex 6: Patch ports.
(Patch portを使用した例。br0のpatch0ポートと、br1のpatch1ポートが接続されています。)
allow-ovs br0
iface br0 inet manual
ovs_type OVSBridge
ovs_ports patch0
allow-br0 patch0
iface patch0 inet manual
ovs_bridge br0
ovs_type OVSPatchPort
ovs_patch_peer patch1
allow-ovs br1
iface br1 inet manual
ovs_type OVSBridge
ovs_ports patch1
allow-br1 patch1
iface patch1 inet manual
ovs_bridge br1
ovs_type OVSPatchPort
ovs_patch_peer patch0
ex 7: Tunnel.
(トンネルモードの例)
allow-ovs br1
iface br1 inet static
address 192.168.1.1
netmask 255.255.255.0
ovs_type OVSBridge
ovs_ports gre1
allow-br1 gre1
iface gre1 inet manual
ovs_bridge br1
ovs_type OVSTunnel
ovs_tunnel_type gre
ovs_tunnel_options options:remote_ip=182.168.1.2 options:key=1
ex 8: Create and destroy bridges.
(ブリッジを作成・削除するコマンド例。)
ifup --allow=ovs $list_of_bridges
ifdown --allow=ovs $list_of_bridges
-- Ben Pfaff <pfaffben@debian.org>, Tue, 19 Aug 2014 08:29:32 -0700
Notes on dependencies:
---------------------
openvswitch-switch depends on $network, $named $remote_fs and $syslog to start. This creates some startup dependency issues.
openvswitchスイッチは$network、$named、$remote_fs、$syslogに依存します。これらは、起動時に問題が発生する要因となりえます。
* Since openvswitch utilities are placed in /usr and /usr can be mounted through NFS, openvswitch has to start after it. But if a user uses openvswitch for all his networking needs and hence to mount NFS, there will be a deadlock. So, if /usr is mounted through NFS and openvswitch is used for all networking, the administrator should figure out a way to mount NFS before starting OVS. One way to do this is in initramfs.
* Open vSwitchコマンド類は、/usr 以下に配置されます。そのため、/usr がNFSマウントの場合にデッドロック等の問題を引き起こします。それらの問題を回避するには、/usr がNFSマウントされてから Open vSwitchを起動する方法を検討する必要があります。initramfs等を使用することで回避が可能になります。
* Since openvswitch starts after $network, $remote_fs and $syslog, any startup script that depends on openvswitch but starts before it, needs to be changed to depend on openvswitch-switch too.
* openvswitchは$network、$remote_fs、$syslog、openvswitch及び各種スタートアップスクリプトに依存します。Open vSwitchは任意の起動スクリプトの後に起動するようにすべきかもしれません。
* Ideally, an admin should not add openvswitch bridges in the 'auto' section of the 'interfaces' file. This is because, when ifupdown starts working on bridges listed in 'auto', openvswitch has not yet started.
* 基本的に、管理者は、"interfaces"ファイルのautoセクションにopenvswitchブリッジを追加してはいけません。 Open vSwitchがまだ起動していないタイミングで、ifupdownが開始されてしまいます。
But, if the admin wants to go down this route and adds openvswitch bridges in the 'auto' section, openvswitch-switch will forcefully be started when ifupdown kicks in. In a case like this, the admin needs to make sure that /usr has already been mounted and that a remote $syslog (if used) is ready to receive openvswitch logs.
Open vSwitchをautoセクションに入れた場合、ifupdownが起動するときにOpen vSwitchが強制的に起動されます。このようにしたい場合は、/usr が先にマウントされるように構成する必要があります。また、syslogサーバを使用している場合、そのサーバがsyslogメッセージを受け入れるように構成する必要があります。
--ココまで
Open vSwitch試してみよう
とりあえず、Open vSwtichを試してみる。
Open vSwitchは、どうやらNetworkManagerでは管理出来ないっぽい。
まだNetworkManagerが対応していないようなのだ。
IPを付与している物理NICも、Network Managerではなく、旧来の管理方法(/etc/network/interfaces)を用いる必要があるようだ。
せっかく、IPアドレスの固定化でNetworkManagerを使用したのに、元に戻すことになってしまう。
大きな流れは以下の通りだ。
この間、何度かOS再起動をしながら確認することになるため、コンソールから作業することになる。
以下、上記流れに沿って実施してみる。
piscesやariesを起動、Remote Viewerからログインして、IPアドレスを確認してみて欲しい。
今までは、DHCPで192.168.122.xのIPアドレスが付与されていたと思うが、今はDHCPで192.168.55.xのアドレスが付与されているはずだ。
そのアドレスに向かって、aquarisや他の(192.168.55.xネットワーク上の)マシンからsshログインが出来ることも併せて確認して欲しい。
以後、仮想マシン作成時に、接続するネットワークをovsbridgeにすれば、ホストOS側と同じネットワークにフラットに接続できる。
本来、Open vSwitchは、SDN(Software Defined Network)に使うような高機能仮想スイッチだが、今回は単純スイッチとして使っている。(勿体無いが)
いずれ、SDNスイッチとして色々実験していくことになると思うが、当面やりたいことは実現出来た。
今回は以上。
Open vSwitchは、どうやらNetworkManagerでは管理出来ないっぽい。
まだNetworkManagerが対応していないようなのだ。
IPを付与している物理NICも、Network Managerではなく、旧来の管理方法(/etc/network/interfaces)を用いる必要があるようだ。
せっかく、IPアドレスの固定化でNetworkManagerを使用したのに、元に戻すことになってしまう。
大きな流れは以下の通りだ。
- Open vSwitchをインストールする。
- NetworkManagerから旧来の/etc/network/interfacesに切り替える。
- Open vSwitchのブリッジを作成する。
- /etc/network/interfacesの設定を書き換え、物理NICのIPアドレスを削除(ブリッジに接続)し、ブリッジにIPアドレスを付与する設定にする。
- KVMに新しいネットワークを作成する。(Open vSwitchで作成したブリッジを認識させる。既存のdefaultをOpen vSwitchに切り替えるやり方もアリ。)
- 既存の仮想マシンの接続先を、新しいネットワークに変更する。
この間、何度かOS再起動をしながら確認することになるため、コンソールから作業することになる。
以下、上記流れに沿って実施してみる。
- Open vSwitchをインストールする。
(aquarius)$ sudo apt-get update
(aquarius)$ sudo apt-get --simulate install openvswitch-switch
(aquarius)$ sudo apt-get install openvswitch-switch
- NetworkManagerから旧来の/etc/network/interfacesに切り替える。
今回は、interfacesに直接記載するのではなく、/etc/network/interfaces.dの下にNICの名前のファイルを作って、そちらに定義してみることにする。
(aquarius)$ sudo vi /etc/network/interfaces.d/enp0s25
----以下の内容で作成----
auto enp0s25
iface enp0s25 inet static
address 192.168.55.131
netmask 255.255.255.0
network 192.168.55.0
broadcast 192.168.55.255
gateway 192.168.55.1
dns-nameservers 192.168.55.1
#dns-nameservers 8.8.8.8
----ココまで----
あくまで、192.168.55.131/24のIPアドレスを付与する時の設定で、ルータのアドレスが192.168.55.1であることを想定して書いている。
各自、自分のネットワーク環境に合わせて欲しい。
また、最後の行は意味が無い行だ。ネームサーバを複数指定可能な環境の人向けのサンプルと思ってくれぃ。
これを設定したら、一度OSを再起動して、正しく反映されるか確認しておこう。
(aquarius)$ sudo shutdown -r now
(aquarius)$ ip address show
(aquarius)$ nmtui
nmtuiで「接続をアクティベートする」を選び、enp0s25にマーク(*)が付いていなければ、NetworkManager管理下に無い(interfaces管理下)ので成功だ。
ネームサーバの設定も行われているか確認しておこう。
(aquarius)$ dig www.yahoo.co.jp
- Open vSwitchのブリッジを作成する。
(ここでは、br-external という名前にしている)
(aquarius)$ sudo ovs-vsctl show
5070b377-4ad8-4ede-9ab5-d69ccfa820cb
ovs_version: "2.5.0"
(aquarius)$ sudo ovs-vsctl list-br
(aquarius)$ sudo ovs-vsctl add-br br-external
(aquarius)$ sudo ovs-vsctl show
5070b377-4ad8-4ede-9ab5-d69ccfa820cb
Bridge br-external
Port br-external
Interface br-external
type: internal
ovs_version: "2.5.0"
(aquarius)$ sudo ovs-vsctl list-br
br-external
(aquarius)$ sudo ovs-vsctl list-ports br-external
(aquarius)$ sudo ovs-vsctl list-ifaces br-external
(aquarius)$ sudo ovs-vsctl get-controller br-external
(aquarius)$ sudo ovs-vsctl get-aa-mapping br-external
(aquarius)$ sudo ovs-vsctl get-manager
こんなんでいいのかな…？
- /etc/network/interfacesの設定を書き換え、物理NICのIPアドレスを削除(ブリッジに接続)し、ブリッジにIPアドレスを付与する設定にする。
今度は、物理NIC(enp0s25)のIPアドレスを削除して、ブリッジI/Fを作成、IPアドレスをそちらに付与する。
よく分かっていないのだが、ブリッジ側にIPを付与しないと、ホストマシン(aquarius)のネットワークが使えなくなるのだ。
まずは、先に作成した設定ファイルを別の場所に移動しておく。(そのためのディレクトリも作っておく。)
(aquarius)$ sudo mkdir /etc/network/interfaces.d.old
(aquarius)$ ls -al /etc/network/interfaces.d.old
(aquarius)$ sudo mv /etc/network/interfaces.d/enp0s25 /etc/network/interfaces.d.old/
(aquarius)$ ls -al /etc/network/interfaces.d.old
続いて、物理NICのIPを削除。(IP未設定とする)
物理NIC設定と、ブリッジ設定で順番があるかもしれないので、ファイル名に数字を付与しておく。
(aquarius)$ sudo vi /etc/network/interfaces.d/0110.enp0s25
--ココから--
auto enp0s25
allow-br-external
iface enp0s25 inet manual
ovs_bridge br-external
ovs_type OVSPort
--ココまで--
ブリッジへのIP付与だ
(aquarius)$ sudo vi /etc/network/interfaces.d/0010.br-external
--ココから--
auto br-external
allow-ovs br-external
iface br-external inet static
address 192.168.55.131
network 192.168.55.0
netmask 255.255.255.0
broadcast 192.168.55.255
gateway 192.168.55.1
ovs_type OVSBridge
ovs_ports enp0s25
dns-nameservers 192.168.55.1
--ココまで--
ここまで出来たら、一度OSを再起動し、設定が反映されるか確認しよう。
(aquarius)$ sudo shutdown -r now
(aquarius)$ ip address show
(aquarius)$ dig www.blogger.com
(aquarius)$ sudo ovs-vsctl show
ip address showを実行したら、今までIPが付与されていたenp0s25には直接IPは付与されておらず、master ovs-sysytemとなっていることが確認できる。
(IPv6アドレスは特に変更していないため、リンクローカルアドレスは付与されているが…)
そして、br-externalにIPが付与されているはずだ。
- KVMに新しいネットワークを作成する。(Open vSwitchで作成したブリッジを認識させる。既存のdefaultをOpen vSwitchに切り替えるやり方もアリ。)
新しいネットワーク定義を作成するので、既存の定義を確認しておく。
(aquarius)$ virsh net-list --all
新しいネットワーク定義用のxmlファイルを作成する。
(aquarius)$ vi ovsbridge.xml
--ここから
<network>
<name>ovsbridge</name>
<forward mode='bridge'/>
<bridge name='br-external'/>
<virtualport type='openvswitch'/>
</network>
--ここまで
作成した定義ファイルを取り込もう。
(aquarius)$ virsh net-define ovsbridge.xml
(aquarius)$ virsh net-list --all
定義が取り込めたら、自動起動に設定する。
(aquarius)$ virsh net-autostart ovsbridge
(aquarius)$ virsh net-list --all
併せて、ネットワーク定義を起動しておこう。
(aquarius)$ virsh net-start ovsbridge
(aquarius)$ virsh net-list --all
- 既存の仮想マシンの接続先を、新しいネットワークに変更する。
piscesもariesも同じ作業なので、同じ手順で設定できる。
まずは、今の状態を出力しておく。
(aquarius)$ virsh dumpxml pisces
内容を確認したら、仮想マシンのネットワーク接続先をdefaultからovsbridgeに書き換える。
(aquarius)$ virsh edit pisces
<interface type='network'>という定義を探して、その中にある<source network='default'/>を<source network='ovsbridge'/>に書き換えよう。
終わったら、設定が反映されているか確認だ。
(aquarius)$ virsh dumpxml pisces
piscesやariesを起動、Remote Viewerからログインして、IPアドレスを確認してみて欲しい。
今までは、DHCPで192.168.122.xのIPアドレスが付与されていたと思うが、今はDHCPで192.168.55.xのアドレスが付与されているはずだ。
そのアドレスに向かって、aquarisや他の(192.168.55.xネットワーク上の)マシンからsshログインが出来ることも併せて確認して欲しい。
以後、仮想マシン作成時に、接続するネットワークをovsbridgeにすれば、ホストOS側と同じネットワークにフラットに接続できる。
本来、Open vSwitchは、SDN(Software Defined Network)に使うような高機能仮想スイッチだが、今回は単純スイッチとして使っている。(勿体無いが)
いずれ、SDNスイッチとして色々実験していくことになると思うが、当面やりたいことは実現出来た。
今回は以上。
登録:
投稿 (Atom)