さて、そういうわけで 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へのバージョンアップで、ネットワーク周りの変更が入っていたため、その変更を取り込む手順を確認した。
他にも変更が入っているかもしれないが、分かり次第取り込むことにしよう。
2018年3月10日土曜日
あれっ！？IPv6アドレスが…。
知らないうちに、うちのマシンにIPv6グローバルアドレス(2001:で始まるアドレス)が振られてる。
知らないうちに、プロバイダがIPv6のサービス始めたのか？
まだIPv6の準備出来てないのにー。
知らないうちに、プロバイダがIPv6のサービス始めたのか？
まだIPv6の準備出来てないのにー。
登録:
投稿 (Atom)