SELinuxてなに?
今回はSELinuxについてです。
SELinuxはファイルやプロセスにラベルを付けることでアクセス制御を行います。ラベルはプロセスとファイルにふることができます。ラベルの種類には次のようなものがあり、
- ユーザ(_u):誰(SELinux独自のユーザ)
- ロール(_r):役割、グループ
- タイプ(_t):アクセス先
(対象はプロセスかファイルで、プロセスの場合はドメインということもある。) - セキュリティレベル(sX,cX):機密のレベル
これらを組み合わせて
”誰(SElinuxUser/role)に何(type)に対してどんな制限をする”
という文脈をコンテキストlとして記述しておいて、SELinuxのサービスがセキュリティのポリシーとして適用します。
SElinuxの状態は、sestatus (-vは詳細表示)コマンドで確認できます。
[root@host1 ~]# sestatus -v
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 28
Process contexts: ...プロセスのコンテキスト
Current context: unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Init context: system_u:system_r:init_t:s0
/usr/sbin/sshd system_u:system_r:sshd_t:s0-s0:c0.c1023
File contexts: ...ファイルのコンテキスト
Controlling terminal: unconfined_u:object_r:user_devpts_t:s0
/etc/passwd system_u:object_r:passwd_file_t:s0
/etc/shadow system_u:object_r:shadow_t:s0
/bin/bash system_u:object_r:shell_exec_t:s0
/bin/login system_u:object_r:login_exec_t:s0
/bin/sh system_u:object_r:bin_t:s0 -> system_u:object_r:shell_exec_t:s0
/sbin/agetty system_u:object_r:getty_exec_t:s0
/sbin/init system_u:object_r:bin_t:s0 -> system_u:object_r:init_exec_t:s0
/usr/sbin/sshd system_u:object_r:sshd_exec_t:s0
[root@host1 ~]#
また通常のユーザとは別にSELinuxのユーザが存在しまして、次のコマンドでそれらのマッピング状態を書くにできます。
[root@host1bynmtui ~]# semanage login -l
Login Name SELinux User MLS/MCS Range Service
__default__ unconfined_u s0-s0:c0.c1023 *
root unconfined_u s0-s0:c0.c1023 *
system_u system_u s0-s0:c0.c1023 *
ここで、SELnuxの動き方を、rootユーザでpasswdコマンドを実行している状況を例に説明してみたいと思います。
idコマンドから現在のユーザ(root)のSELinuxのUserは、unconfined_uとになっていることが確認できます。
※ちなみに、隣のunconfined_rはロールで、通常のユーザで言うとGroupみたいな感じです。
[root@host1 ~]# id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[root@host1 ~]#
passwdコマンドを実行するプロセスのラベル(ドメイン)は、psコマンドで確認できます。ここではpasswd_tがドメインとなります。
[root@host1 ~]# ps -eZ | grep passwd
unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 14894 pts/1 00:00:00 passwd
[root@host1 ~]#
passwdコマンドが実行されたときにアクセスするファイルのラベル(タイプ)は、lsコマンドから、それぞれ以下の通りになっています。
[root@host1 ~]# ls -Z /usr/bin/passwd
-rwsr-xr-x. root root system_u:object_r:passwd_exec_t:s0 /usr/bin/passwd
[root@host1 ~]#
[root@host1 ~]# ls -Z /etc/shadow
----------. root root system_u:object_r:shadow_t:s0 /etc/shadow
[root@host1 ~]#
上記の例はこちらを参考にいたしました。
第2章 SELinux コンテキスト - Red Hat Customer Portal
図にするとこんな感じになりますが、SELinuxが有効なときはこのようなラベル付がバックグラウンドで行われています。
- ユーザ(unconfined_u)はpasswdを実行するときに、プロセスのコンテキストの影響を受けて、
- passwardコマンドも(system_uのユーザで)ファイルにアクセスしに行く際はファイルのコンテキストの制限を受けます。
そんなSELinuxですが、基本パッケージでインストールしたRHEL7.xではOSの起動とともに有効になり、2つのモードで切り替えることができます。
- Enforcing モード:
デフォルトのモードで、SElinuxのポリシーが強制されてアクセス制御が行われます。ポリシー違反の場合はアクセスの拒否が行われます。 - Permissive モード:
ポリシーは読み込まれてラベルの作成も行われますが、ポリシー違反によるアクセス拒否は行わません。ただログには記録されるのでトラシューやデバッグで使用できます。
SELinuxのモードを確認するにはgetenforceコマンドを使用します。デフォルトではEnforcingになります。
[root@host1 ~]# getenforce
Enforcing
[root@host1 ~]#
続いて、permissiveモードに切り替えてみます。
[root@host1 ~]# setenforce 0
もう一度getenforceを実行するとpermissiveと表示されます。
[root@host1 ~]# getenforce
Permissive
[root@host1 ~]#
enforcingモードに戻すには、パラメータに1を指定します。
[root@host1 ~]# setenforce 1
上記の手順は一時的にモードを切り替えるだけなので、SELinuxがrestartするとデフォルトのenforcingに戻ってしまいます。なので起動時のモードを永続的に変更したい場合は、SELinuxのConfigファイルを編集する必要があります。
[root@host1 ~]# vim /etc/selinux/config
ファイルの更新を適用させるためには、OSを再起動します。
[root@host1 ~]# reboot
上記のSELINUX=の項目に設定できる値としては、
enforcing - SELinux security policy is enforced.
permissive - SELinux prints warnings instead of enforcing.
の他に
disabled - No SELinux policy is loaded.
もありまして、こちらを選ぶとSELinux自体を無効にできますが、無効になっている間に作成したファイルにはラベルが付きませんので注意が必要です。RHELではpermissiveやenforcingに変更した際に、自動で再ラベルが行われるみたいですが、/etc/selinux/configを編集してSELinuxを有効にしたあとは、
# touch /.autorelabel
を実行して、明示的に再ラベルしておくようにしたほうが安心かと思います。
<参考資料>
1.4. SELinux の状態とモード - Red Hat Customer Portal
4.4. SELinux の状態とモードの永続的変更 - Red Hat Customer Portal
Default Boot targetの設定
RHEL7をインストールするときに、Install with GUIのオプションを選択した場合、OSが起動してきたときはGUIのログイン画面が表示されてきますが、使っていくうちに慣れてきて最近CUIしか使わないなぁと言うときに、デフォルトで起動するモードをCUIに変更する方法をご紹介します。
RHEL6のときはrunlevelといっていましたが、RHEL7では.targetという形に変更されてしまいました。やりたいことは一緒なんですけどね。
内容 | RHEL 6/ RunLevel |
RHEL 7/ .target |
システム停止 | 0 | poweroff.target |
シングルユーザモード | 1 | rescue.target |
マルチユーザモード CUI |
3 | multi-user.target |
グラフィカルモード GUI |
5 | graphical.target |
再起動 | 6 | reboot.target |
緊急モード | - | emergency.target |
でもって、boot modeの変更の仕方も変わりました。
変更内容 | RHEL 6 | RHEL 7 |
一時的なBoot Modeの変更 | telinit runlevel | systemctl isolate target_name |
デフォルトのBoot Modeの変更 | /etc/inittabを更新 |
systemctl set-default |
というので、デフォルトのBoot MoodをGUI(graphical.target)から、CUI(multi-user.target)に変えてみたいと思います。
まずは、今のDefault Boot Modeを確認から。
[root@host1 ~]# systemctl get-default
graphical.target
[root@host1 ~]#
CUI(multi-user.target)へ変更します。
[root@host1 ~]# systemctl set-default multi-user.target
Removed symlink /etc/systemd/system/default.target.
Created symlink from /etc/systemd/system/default.target to /usr/lib/systemd/system/multi-user.target.
[root@host1 ~]#
上の出力結果から、/usr/lib/systemd/system/配下のtarget指定のファイルを/etc/systemd/system/default.targetのシンボリックリンクとして貼り付けていることがわかります。timezoneと同様に手動でやってもいいんでしょうけどね。
変更後のDefault Boot Modeを確認すると、multi-user.targetに変更されています。
[root@host1 ~]# systemctl get-default
multi-user.target
[root@host1 ~]#
以上でした。
hostname変更のあれこれ
一般的にホスト名を変更するときは、/etc/hostnameを編集しますが、
nmtuiとかnmcliでも変更できたりします。。
まずは、現状のhostnameを確認するコマンドのご紹介から。。
[root@host1 ~]# cat /etc/hostname
host1.example.com
※このファイルの値はhostnamedのサービスが読み込んで初めてOSに適用されるので、必ずしもOSで使われているとは言えないですが。。
[root@host1 ~]# hostname
host1.example.com
[root@host1 ~]#
[root@host1 ~]# hostnamectl |grep hostname
Static hostname: host1.example.com
[root@host1 ~]#
[root@host1 ~]# uname -n
host1.example.com
[root@host1 ~]#
[root@host1 ~]# nmcli gen hostname
host1.example.com
[root@host1 ~]#
続いて、hostnameの変更方法です。
## /etc/hostnameファイルを書き換えるパターン
[root@host1 ~]# vi /etc/hostname
書き換えたあと、catで見ると変更されていますが
[root@host1 ~]# cat /etc/hostname
host1updatedFile.example.com
OSのキャッシュ上はまだ反映されないので、
[root@host1 ~]# hostname
host1.example.com
hostnamedのサービスを再起動する必要があります。
[root@host1 ~]# systemctl restart systemd-hostnamed
[root@host1 ~]#
[root@host1 ~]# hostname
host1updatedFile.example.com
## hostnameコマンドでの変更
hostnameコマンドを使用するとOSのキャッシュ上は変更されますが。。。
[root@host1 ~]# hostname host1byHostname.example.com
[root@host1 ~]# hostname
host1byHostname.example.com
[root@host1 ~]#
/etc/hostnameの内容は更新されないため、rebootすると元の名前に戻ってしまいます。
[root@host1 ~]# cat /etc/hostname
host1updatedFile.example.com
[root@host1 ~]#
## hostnamectlでの変更
こちらは、OSのキャッシュもファイルも両方変更されます。^^
[root@host1 ~]# hostnamectl set-hostname host1byHstnctl.example.com
[root@host1 ~]#
[root@host1 ~]# hostname
host1byhstnctl.example.com
[root@host1 ~]# cat /etc/hostname
host1byhstnctl.example.com
[root@host1 ~]#
## nmcliでの変更
nmcliでのhostnameの変更もOSキャッシュ、ファイルともに変更されます。
[root@host1 ~]# nmcli gen hostname host1bynmcli.example.com
[root@host1 ~]#
[root@host1 ~]# hostname
host1bynmcli.example.com
[root@host1 ~]# cat /etc/hostname
host1bynmcli.example.com
[root@host1 ~]#
ただ、今回はRHEL7.3を使用していますが、リファレンスを見るところによるとRHEL7でもVersion次第ではhostnamedの再起動が必要かもしれません。
3.4. nmcli を使ったホスト名の設定 - Red Hat Customer Portal
## nmtuiでの変更
ラスト、nmtuiです。
[root@host1 ~]# nmtui
Set system hostnameを選択して
hostnameのダイヤログで入力します。
丁寧に確認画面も表示。
Main MenuでQuitして完了です。
OSキャッシュもファイルも更新されていましたが、nmcliベースなのでバージョン次第では、hostnamedの再起動が必要か?というところです。
[root@host1 ~]# hostname
host1bynmtui.example.com
[root@host1 ~]# cat /etc/hostname
host1bynmtui.example.com
[root@host1 ~]#
いろいろと選択肢はありますが、お好きなものをSelectしていただければと思います。
RedHatのパスワードリセット方法
今回は、インストールするときにキーボードが英語配列になっていたりとかして、実際ログインしようとしたら入れないよ!という場合のパスワードリセット方法をご紹介します。
まずは、Gestのシャットダウンから。。
でもって、電源ONしてブートメニューのところで、eを押します。
GRUBのパラメーター設定の画面が開くので、linix16の行のを→で移動していって末尾のUTF-8あとに続けて、systemd.unit=emergency.targetを追記します。またの名をレスキューモードとも言います。Windowsのセーフモードみたいな感じでしょうか。
Ctrl+xでこの画面を抜けてレスキューモードを起動します。
起動した!と思ったらパスワードを聞かれてしまうということでこれは使えませんでした。
すみません。無駄足を。。
気を取り直して、もう一度GRUBの設定を開きます。
今度は、linix16の行の末尾にinit=/sysroot/bin/shを追記してCtrl+xしました。
すると今度は、:/#のプロンプトが表示されてパスワード無しで操作できます。
ルートディレクトリを/sysrootに変更しまして、
# chroot /sysroot
Read/Writeでマウントしなおします。※最後の"/"(スラッシュ)を忘れずに。
# mount --o remount,rw /
その後、passwordコマンドで自分が設定したいパスワードへ変更します。
# passwd
mountコマンドを実行したあと改行がたくさん出てきてしまいましたが。。私の環境依存かと思います。
あとは、通常のtargetでOSが起動しますとSE Linuxも有効になりますが、今回SELinuxが上がっていない緊急targetでパスワードを変ていますので、更新された/etc/shadowファイでのSELinux的な不整合が発生することを回避するために、ラベルの再発行(リラベル)をするコマンドを実行します。
# touch /.autorelabel
ご覧の通り、/(ルート)直下に隠しファイルを作るだけですが、次回起動時にラベルを再作成してくれます。
あとは、
# exit
をした後に
# reboot
して、ログインできるかを確認します。
リラベル処理のため、一回立ち上がったあともう一度再起動がかかります。
OS起動後は、無事ログインを通過して使えるようになりました。
以上です。
nmtuiを使ったNetwork Interfaceの管理
今日はnmtuiについてです。
前回は、nmcli con addコマンドでVM上に追加したDeviceに対するifcfg-ethXのファイルを生成して使えるようにしたのですが、Network ManagerではTesxt User Interface (TUI)も提供されているとのことで今度はこちらを使ってみました。TUIとは、TeraTermとかPuttyみたいなCLI環境でもGUIのように使えるテキストベースのインターフェースです。
というので、またVMにNetwork Adapterを追加した状態に戻しまして
[root@host1 ~]# nmcli con
NAME UUID TYPE DEVICE
eth0 c483566c-f533-4af5-8a7c-d59fadc321f1 802-3-ethernet ens192
virbr0 29f32794-10ea-46a2-9f37-08ff95153c69 bridge virbr0
[root@host1 ~]#
Network ManagerのConnectionがない。
[root@host1 ~]# ls -l /etc/sysconfig/network-scripts/
total 232
-rw-r--r--. 1 root root 383 Oct 30 15:56 ifcfg-ens192
-rw-r--r--. 1 root root 254 Sep 12 2016 ifcfg-lo
:
ifcfg-xxのファイルもない。
というところからスタートします。
nmtuiの起動は、nmtuiコマンドを入力します。
[root@host1 ~]# nmtui
画面いっぱいに昔のファミコンのメニューのような画面が表示されます。
オプションは、↑↓ボタンで選択、項目はTabキーで移動できます。
まずは"Edit a connection”を選択(Enter)します。
eth0しかみえてないので、<Add>で新しいAdapterを追加します。
ConnectionのTypeを聞かれますので、Ethernetを選びEnterします。
Connectionのプロパティが表示されてきますので、Profile NameとDeviceを入力します。Device名がわからないときは、ifconfigコマンドで確認できます。
IPv4 CONFIGURATIONの横にある<Show>を開くとIPアドレスやGatewayなどが入力できます。入力が終わったらTabキーで<OK>まで移動してEnterします。
eth1が追加されたことを確認して、<Back>でMain Menu戻ります。
Main MenuでActivate a connectionを選択します。
eth1を選んで、<Activate>します。
Connecting...の表示が数秒続いたあと。。
あろうことか、失敗で終了しまいました。。。
もう一度、Edit Cnnection画面を確認すると。
IPaddressを設定するときに入力するのを忘れていたPrefixのところに/32 (つまりNetmaskが255.255.255.255)が補完されておりましたので、24に修正しまして。
Activateをリベンジ(いったんDeactivateしないとActivateの表示になりません。)するもまたもや失敗。
結局、ちゃんと動いている方のeth0の設定と見比べたところ、
IPv4 CONFIGURATIONの項目の横のところを、Manual(Static)にしておかないといけなかったということに気づきまして。。Manualに修正して再Activateを実施。
今度はConnecting....の画面も、Errorも表示されずあっさりActivate表示がDeactivateへ。。
nmtuiを抜けて、ifconfigをしたところしっかりとUPになっておりました。
[root@host1 network-scripts]# ifconfig
ens192: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
:
ens224: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.251 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::d2fd:497a:cc6e:dced prefixlen 64 scopeid 0x20<link>
ether 00:50:56:ff:ff:63 txqueuelen 1000 (Ethernet)
RX packets 17369 bytes 2892179 (2.7 MiB)
RX errors 0 dropped 108 overruns 0 frame 0
TX packets 822 bytes 134227 (131.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
他のコマンドの実行結果も問題なさそうでした。
[root@host1 network-scripts]# nmcli con
NAME UUID TYPE DEVICE
eth0 c483566c-f533-4af5-8a7c-d59fadc321f1 802-3-ethernet ens192
eth1 58d1f618-722a-4bdd-a9d6-59ca6b158a57 802-3-ethernet ens224
virbr0 29f32794-10ea-46a2-9f37-08ff95153c69 bridge virbr0
[root@host1 network-scripts]#
[root@host1 network-scripts]# nmcli dev
DEVICE TYPE STATE CONNECTION
virbr0 bridge connected virbr0
ens192 ethernet connected eth0
ens224 ethernet connected eth1
lo loopback unmanaged --
virbr0-nic tun unmanaged --
[root@host1 network-scripts]#
[root@host1 network-scripts]# ls -l
total 236
-rw-r--r--. 1 root root 383 Oct 31 10:59 ifcfg-ens192
-rw-r--r--. 1 root root 362 Oct 31 10:56 ifcfg-eth1
-rw-r--r--. 1 root root 254 Sep 12 2016 ifcfg-lo
:
ではでは。。
Network ManagerとUUIDについて
Network Managerですが基本的にCnnectionごとにUUIDが使われているみたいなんですけど、どんな動きをするのかちょっと不思議だったので試してみました。
手始めに現状の確認ということで、どのConnectionでどのUUIDが使用されているかを、次のコマンドで確認しました。eth1は、前回
VM上で追加したAdapterをRHELで使うために有効にしたConnectionなので今回もこれを使います。
[root@host1 ~]# nmcli con
NAME UUID TYPE DEVICE
eth0 c483566c-f533-4af5-8a7c-d59fadc321f1 802-3-ethernet ens192
eth1 58d1f618-722a-4bdd-a9d6-59ca6b158a57 802-3-ethernet ens224
virbr0 29f32794-10ea-46a2-9f37-08ff95153c69 bridge virbr0
[root@host1 ~]#
Network ManagerはどのDeviceがどのConnectionに割り当てられているというのをUUIDで識別しているというのがわかったところで、前回の作業で自動で作成されたConfigファイルを開いてみるとこちらにもUUIDの記載がありました。Network Managerが起動するときにConfigファイルを読み込んだときに対応するDeviceを確認してIPなどを設定しているみたいです。
[root@host1 ~]# cd /etc/sysconfig/network-scripts/
[root@host1 network-scripts]# cat /ifcfg-eth1
TYPE=Ethernet
BOOTPROTO=none
:
NAME=eth1
UUID=58d1f618-722a-4bdd-a9d6-59ca6b158a57
DEVICE=ens224
ONBOOT=yes
IPADDR=192.168.0.251
PREFIX=24
GATEWAY=192.168.0.1
:
このときふと手動でConfigファイルを作成したときってUUIDってどうしたらいいのか?と疑問に思ったので、試しに、上のファイルのUUDIをコメントアウトして、Network Managerをrestartしてみました。。
[root@host1 network-scripts]# vim ifcfg-eth1
[root@host1 network-scripts]# systemctl restart network.service
[root@host1 network-scripts]#
[root@host1 network-scripts]# nmcli con
NAME UUID TYPE DEVICE
eth0 c483566c-f533-4af5-8a7c-d59fadc321f1 802-3-ethernet ens192
eth1 9c92fad9-6ecb-3e6c-eb4d-8a47c6f50c04 802-3-ethernet ens224
virbr0 29f32794-10ea-46a2-9f37-08ff95153c69 bridge virbr0
[root@host1 network-scripts]#
上のように、Deviceは正常に立ち上がってきてUUIDは新たに設定されます。
コメントアウトしたファイルには新たなUUIDがUpdateされてはいないようですが、ConfigファイルにUUIDが明記されてなくても、なきゃないで自動で割り振ってくれるものみたいです。
もう一度、UUIDのコメントアウトを外して有効にした状態で、Network Managerをrestartしてみます。
[root@host1 network-scripts]# nmcli con
NAME UUID TYPE DEVICE
eth0 c483566c-f533-4af5-8a7c-d59fadc321f1 802-3-ethernet ens192
eth1 58d1f618-722a-4bdd-a9d6-59ca6b158a57 802-3-ethernet ens224
virbr0 29f32794-10ea-46a2-9f37-08ff95153c69 bridge virbr0
[root@host1 network-scripts]#
UUIDはもとから書かれていたものに戻りました。UUIDがあればそれを使うということですね。
今度は、Configファイルを複製してUUID有りとUUID無しの同時に2つが存在する環境で、Network Managerを起動してみました。
[root@host1 network-scripts]# cp ifcfg-eth1 ifcfg-eth1-1
[root@host1 network-scripts]#
[root@host1 network-scripts]# vim ifcfg-eth1 ...※UUIDをコメントアウト
[root@host1 network-scripts]#
[root@host1 network-scripts]# diff ifcfg-eth1 ifcfg-eth1-1
12c12
< #UUID=58d1f618-722a-4bdd-a9d6-59ca6b158a57
---
> UUID=58d1f618-722a-4bdd-a9d6-59ca6b158a57
[root@host1 network-scripts]#
diffコマンドで確認したとおり元のifcfg-eth1はUUID無しで、Copyのifcfg-eth1-1がUUDI有りです。
[root@host1 network-scripts]#
[root@host1 network-scripts]# systemctl restart network.service
[root@host1 network-scripts]#
[root@host1 network-scripts]# nmcli con
NAME UUID TYPE DEVICE
eth0 c483566c-f533-4af5-8a7c-d59fadc321f1 802-3-ethernet ens192
eth1 9c92fad9-6ecb-3e6c-eb4d-8a47c6f50c04 802-3-ethernet ens224 ...①
virbr0 29f32794-10ea-46a2-9f37-08ff95153c69 bridge virbr0
eth1 58d1f618-722a-4bdd-a9d6-59ca6b158a57 802-3-ethernet -- ...②
[root@host1 network-scripts]#
Network ManagerのRestartのあとに、eth1のConnectionが2つ見えてきまして、①のConnectionにens224が割り当てられて、新たにUUIDが割り当てられています。②の方は、Configに記載されているUUIDで読み込まれていますが、Deviceは割り当てられていません。
Network ManagerはConfigのファイル名をABC順に読み込んでいって先に読み込んだeth1のCofigにUUIDがなかったので、新たにUUIDを発行したようです。
また、いらない方のConnectionはnmliコマンドからUUDIを指定して削除できます。
[root@host1 network-scripts]#
[root@host1 network-scripts]# nmcli con delete 58d1f618-722a-4bdd-a9d6-59ca6b158a57
Connection 'eth1' (58d1f618-722a-4bdd-a9d6-59ca6b158a57) successfully deleted.
[root@host1 network-scripts]#
[root@host1 network-scripts]# nmcli con
NAME UUID TYPE DEVICE
eth0 c483566c-f533-4af5-8a7c-d59fadc321f1 802-3-ethernet ens192
eth1 9c92fad9-6ecb-3e6c-eb4d-8a47c6f50c04 802-3-ethernet ens224
virbr0 29f32794-10ea-46a2-9f37-08ff95153c69 bridge virbr0
[root@host1 network-scripts]#
Connectionのエントリーが消えて、Configファイルのifcfg-eth1-1も削除されます。
[root@host1 network-scripts]# ls -l
total 236
-rw-r--r--. 1 root root 383 Oct 31 10:59 ifcfg-ens192
-rw-r--r--. 1 root root 363 Oct 31 13:05 ifcfg-eth1
:
検証とかでいろいろやりすぎて、Network ManagerがStartするときにErrorとかが出るときには、ConfigファイルのDevice名とUUIDを見直せばいいのかなぁと言うのがわかりました。。
RHEL7.xのVMでNetwork Adapterを追加したあとは。
素朴すぎる内容ですが、意外と面倒なLinuxのNetwork Interfaceの管理についての話題です。とくにも、Network Managerが導入されてからはなかなか手ごわいですね。
今回は、VMでNetwork Adapterを追加したんだけどどうすれば使えるようになるんでししたっけ?というのをやってみました。
当然ではありますが、VM上でAdapterを追加しただけでは、HostのOSでは勝手には有効になりません。
いちおう、ifconfigで見るとどうやら追加したAdapterはens244で見えてきています。
[root@host1 ~]# ifconfig
ens192: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.10.0.125 netmask 255.255.255.0 broadcast 10.10.0.255
inet6 fe80::4421:2193:962d:5218 prefixlen 255 scopeid 0x20<link>
ether 00:50:56:ff:ff:ff txqueuelen 1000 (Ethernet)
RX packets 4953 bytes 683258 (667.2 KiB)
RX errors 0 dropped 65 overruns 0 frame 0
TX packets 2303 bytes 418471 (408.6 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ens224: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether 00:50:56:ff:ff:63 txqueuelen 1000 (Ethernet)
RX packets 13 bytes 1344 (1.3 KiB)
RX errors 0 dropped 5 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
:
闇雲に、Iinterfaceをupしてみたところで、上がりませんね。
[root@host1 ~]# ifup ens224
/usr/sbin/ifup: configuration for ens224 not found.
Usage: ifup <configuration>
[root@host1 ~]#
上の出力結果でも出ているように、おなじみのifcfgのConfigfファイルもないから仕方がないのですが。。。
[root@host1 ~]# cd /etc/sysconfig/network-scripts/
[root@host1 network-scripts]# ls -l
total 232
-rw-r--r--. 1 root root 382 Oct 30 11:57 ifcfg-ens192
-rw-r--r--. 1 root root 254 Sep 12 2016 ifcfg-lo
lrwxrwxrwx. 1 root root 24 Oct 27 16:37 ifdown -> ../../../usr/sbin/ifdown
:
さてどうしたものかと言うところですが。。
RHEL7ではNetwork Managerで管理するということで、nmcliというコマンドで現在のDeviceの状態を確認してみました。
2.3. NetworkManager のコマンドラインツール nmcli の使用 - Red Hat Customer Portal
Network Manager のCLIということで、nmcliですね。
[root@host1 network-scripts]# nmcli dev
DEVICE TYPE STATE CONNECTION
virbr0 bridge connected virbr0
ens192 ethernet connected eth0
ens224 ethernet disconnected --
lo loopback unmanaged --
virbr0-nic tun unmanaged --
とりあえず、追加したens224は、disconnectedであることはわかりました。
まずはconnectedにしないことには始まらないようなので、Connectionを追加するコマンドを実行。Network ManagerはConnectionという単位でNetwork Interfaceを管理するみたいですね。
[root@host1 network-scripts]# nmcli con add type ethernet ifname ens224 con-name eth1
Connection 'eth1' (77a2073d-a654-4f8e-a2b0-0668c40ed77d) successfully added.
[root@host1 network-scripts]#
Con-nameは適当な名前でいいみたいなので、馴染みのある"ethなんとか"で設定してみました。
UUIDが設定されてsuccessfullyで完了!UUIDはNetwork Managerが使う識別子とのこと。
deviceのリストもconnectingの状態に。IPの設定を取得しようとしているみたいなのでおそらくデフォルトでDHCPが設定されているんでしょうね。
[root@host1 network-scripts]# nmcli dev
DEVICE TYPE STATE CONNECTION
virbr0 bridge connected virbr0
ens192 ethernet connected eth0
ens224 ethernet connecting (getting IP configuration) eth1
lo loopback unmanaged --
virbr0-nic tun unmanaged --
[root@host1 network-scripts]#
このタイミングでnetwork scriptsのフォルダには、Configファイルが作成されてました。
[root@host1 network-scripts]# ls -l
total 236
-rw-r--r--. 1 root root 382 Oct 30 11:57 ifcfg-ens192
-rw-r--r--. 1 root root 310 Oct 30 14:54 ifcfg-eth1
:
中を開くと、やっぱりDHCPで設定されていました。。
[root@host1 network-scripts]# cat ifcfg-eth1
TYPE=Ethernet
BOOTPROTO=dhcp
DEFROUTE=yes
PEERDNS=yes
:
このままファイルを編集するという手もあるかとは思うのですが、せっかくなのでnmcliでIPをふってみようということで、192.168.0.251/24のIPと、192.168.0.1のDefault Gatewayで設定してみることに。
connectionに対して設定するので、対象としてはCon-Name(eth1)を指定しないとエラーになります。あと、RHEL7.0と7.1以降でNetwork Managerのバージョンが違うようで、私が使用していた7.3環境では7.0のシンタックスで設定しようとするとエラーになりました。
ちなみにこちらが7.0のです。ipv4.addresses "192.168.0.251/24 192.168.0.1"
[root@host1 network-scripts]# nmcli connection modify eth1 ipv4.method manual ipv4.addresses 192.168.0.251/24 ipv4.gateway 192.168.0.1
[root@host1 network-scripts]#
この状態で、ifcfg-eth1のファイルを開くとちゃんとIPアドレスとDG/Wが設定されています。
[root@host1 network-scripts]# cat ifcfg-eth1
TYPE=Ethernet
:
ONBOOT=yes
IPADDR=192.168.0.251
PREFIX=24
GATEWAY=192.168.0.1
:
[root@host1 network-scripts]#
もちろん、DeviceもConecctedに!
[root@host1 network-scripts]# nmcli dev
DEVICE TYPE STATE CONNECTION
virbr0 bridge connected virbr0
ens192 ethernet connected eth0
ens224 ethernet connected eth1
lo loopback unmanaged --
virbr0-nic tun unmanaged --
私の場合は、ここでifconfig上も有効になっておりましたが、有効になっていない場合はNetwork Managerのrestartとかすることになるかと思います。
[root@host1 network-scripts]# systemctl restart network.service
[root@host1 network-scripts]#
また、nmcliからもinterfaceのdown/upすることもできました。
[root@host1 network-scripts]# nmcli connection down eth1 && nmcli connection up eth1
Connection 'eth1' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/38)
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/39)
[root@host1 network-scripts]#
以上です。