ACI に関しては、ACI How To というページがあり、設定やトラブルシューティング等、一般的な内容についてはそちらの方が充実しています。 設定やトラブルシューティングについては、今後 ACI How To を中心に更新していく予定のため、ACI に関する情報収集はまず、ACI How To を参考にしてください。
このコンテンツも Fault に出力されている path が見つからない時の調べ方 というタイトルで掲載しています。 フォーマットがずれて読みにくい場合、こちらのページをご参照ください。
はじめに
ACI では初期設定時に admin user password を設定し、新たに user を作らない限り、admin user で設定や troubleshooting を行なっていきます。 まれに、troubleshooting や software 不具合の回避策として root access が必要になります (ACI: root アクセスと root パスワードの発行方法) 。 ここでは、admin user と root user の path の違いについて紹介します。
1. chroot
admin user が全ての file に access できる必要はなく、Security の観点から必要な情報のみを表示できることが望ましいです。 そのため、apic に admin login を行なった場合、chroot を行い、root user とは異なる場所を root に変更しています。 user の root と path の root どちらも root で混乱するかもしれないので、一応図を書くと下記のような構造になっています。
[root@apic1 /]# pwd;find . | sort | sed '1d;s/^\.//;s/\/\([^/]*\)$/|--\1/;s/\/[^/|]*/| /g'
/ <<== root の場合、ここが root (起点)
|--"
| |--var
| | |--run
| | | |--bashroot <<== admin の場合、ここが root (起点)
| | | | |--cgroup"
[snip]
そのため、ls / で root の file を確認すると、結果が異なります。 (それぞれ、上記起点となっている directory にある file が表示されます。)
## admin
apic1# ls /
aci bin controller data data2 debug dev etc firmware home lib lib64 mgmt mit opt proc sbin sys tmp usr var
apic1#
## root
[root@apic1 /]# ls /
" MegaSAS.log-20190120-1547971262.gz boot data2 etc fwrepos lib lxc opt root securedata tmp
1 MegaSAS.log-20190122-1548115261.gz cgroup dev firmware gluster lib64 media proc run srv usr
2 MegaSAS.log-20190124-1548259261.gz config dmecores forcefsck home logs mgmt rfs1 sbin sys var
MegaSAS.log bin data efiboot fsckoptions ifabric lost+found mnt rfs2 scratch techsupport
[root@apic1 /]#
ちなみに、login 時の user resource 管理は scriptcontainer process が行なっていて、その log からも、/var/run/bashroot へ chroot していることが確認できます。 下記 command は admin user でも実行できるため、admin user でも、login 時の root(起点) は / ではなく、/var/run/bashroot であることが確認できます。
apic1# ps aux | grep scriptcontainer
admin 2286 0.0 0.0 9056 908 pts/2 S+ 15:40 0:00 grep scriptcontainer
root 14808 0.0 0.0 16920 3004 pts/2 D 10:24 0:00 /mgmt/usr/bin/scriptcontainer -b
admin 14809 0.0 0.0 16920 3004 pts/2 S 10:24 0:00 /mgmt/usr/bin/scriptcontainer -b
root 31418 0.0 0.0 16920 2888 pts/0 D 09:14 0:00 /mgmt/usr/bin/scriptcontainer -b
admin 31419 0.0 0.0 16920 2888 pts/0 S 09:14 0:00 /mgmt/usr/bin/scriptcontainer -b
apic1#
apic1# cd /var/run/mgmt/log
apic1# tail -f scriptcontainer.log
## admin user で login
19-00-25 13:18:29||scriptcontainer||INFO||||../svc/scripthandler/src/container/ScriptContainer.cc||1337||chroot to /var/run/bashroot complete
19-00-25 13:18:29||scriptcontainer||INFO||||../svc/scripthandler/src/container/ScriptContainer.cc||1762||calling shell 1
19-00-25 13:18:29||scriptcontainer||INFO||||../svc/scripthandler/src/container/ScriptContainer.cc||894||Launching zsh...
19-00-25 13:18:29||scriptcontainer||INFO||||../svc/scripthandler/src/container/ScriptContainer.cc||618||Username admin
## exit で logout
19-00-25 13:18:38||scriptcontainer||INFO||||../svc/scripthandler/src/container/ScriptContainer.cc||982||Child1 exited with 0
19-00-25 13:18:38||scriptcontainer||INFO||||../svc/scripthandler/src/container/ScriptContainer.cc||590||Cleaning up
apic が fault を検知しているので、その fault に書かれている path を調べようとすると、下記のように file/directory が存在しないと言われるのは、root が fault を検知し、その path を出力しているためです。
apic1# ls /data/log
ls: cannot access /data/log: No such file or directory
apic1#
[root@apic1 /]# ls /data/log | head -3
access.log
access.log-20190118-1547809261.gz
access.log-20190120-1547964061.gz
[root@apic1 /]#
2. mount
先ほどの章で login した時の起点が違うことは理解できたと思うので、次は、それぞれの user が login した時に disk をどのように mount しているのかを見ていきます。
apic は lvm を使用していますが pvdisplay, vgdisplay, lvdisplay 等、lvm 関連の command は root でしか実行できません。 名前からだいたい想像できると思いますが、名前に ssd がついていないものが HDD で、ssd がついているものが SSD になります。
[root@apic1 /]# lvdisplay | grep Path
LV Path /dev/vg_ifc0/rfs1
LV Path /dev/vg_ifc0/rfs2
LV Path /dev/vg_ifc0/securedata
LV Path /dev/vg_ifc0/logs
LV Path /dev/vg_ifc0/dmecores
LV Path /dev/vg_ifc0/techsupport
LV Path /dev/vg_ifc0/firmware
[snip]
LV Path /dev/vg_ifc0_ssd/data
[root@apic1 /]#
上記は、root user でしか確認できませんが、/etc/fstab は admin user でも確認できるので、admin user であっても、だいたいどの directory がどの logical volume を使用しているのか想像できると思います。
apic1# cat /etc/fstab
/dev/vg_ifc0/logs /logs ext4 defaults 0 0
/dev/vg_ifc0/boot / ext4 defaults 1 1
/dev/vg_ifc0/config /config ext4 defaults 0 2
/dev/vg_ifc0/techsupport /techsupport ext4 defaults 0 0
/dev/vg_ifc0/firmware /firmware ext4 defaults 0 0
/dev/vg_ifc0/scratch /scratch ext4 defaults 0 0
/dev/vg_ifc0_ssd/data /data ext4 defaults 0 0
/dev/vg_ifc0/dmecores /dmecores ext4 defaults 0 0
/dev/vg_ifc0/data2 /data2 ext4 defaults 0 0
tmpfs /tmp tmpfs defaults,size=16G 0 0
apic1#
apic の log の多くは、/data/log 以下 (root) に保存されていますが、一部 file の logrotate を忘れていたために、/data/log の disk 容量が一杯になるという不具合が過去に数件ありました。 CSCvb13193 にも "F1529 - topology/pod-1/node-3/sys/ch/p-[/data/log]-f-[tmpfs] : Storage unit /data/log on Node 3 mounted at /data/log is 90% full" が出力されるという記載があります。
この /data/log は admin user の /var/log/dme/log と同じ場所を mount しています。
いますと言われても、一般 user は root access できないので、調べるのが難しいかもしれませんが、上記 fstab の結果 (admin user で実行可能) と、mount の出力結果 (admin user で実行可能) からおおよその見当をつけることが可能です。
上記 fstab の結果から /data は /dev/vg_ifc0_ssd/data を mount していることが確認できます。 そこで、vg_ifc0_ssd を mount している directory を調べると下記のような結果が表示されます。( lvm の場合、/dev/vg_aaa/bbb と /dev/mapper/vg_aaa-bbb はどちらも、/dev/dm-ccc の symbolic link になっているので、どちらも同じところを mount しています。)
apic1# mount | grep vg_ifc0_ssd
/dev/mapper/vg_ifc0_ssd-data on /data/challenge.plugin type ext4 (ro,relatime,data=ordered)
/dev/mapper/vg_ifc0_ssd-data on /controller/sbin type ext4 (rw,relatime,data=ordered)
/dev/mapper/vg_ifc0_ssd-data on /data/devicescript type ext4 (rw,relatime,data=ordered)
/dev/mapper/vg_ifc0_ssd-data on /data/log.lastupgrade type ext4 (ro,relatime,data=ordered)
/dev/mapper/vg_ifc0_ssd-data on /var/log/dme type ext4 (rw,relatime,data=ordered)
/dev/mapper/vg_ifc0_ssd-data on /var/log/dme/nginx type ext4 (rw,relatime,data=ordered)
/dev/mapper/vg_ifc0_ssd-data on /var/run/mgmt/log type ext4 (rw,relatime,data=ordered)
apic1#
/data/log が一杯ということなので、上記 directory 配下に log directory があるか ls で確認して見ます。 下記出力の結果から /var/log/dme の配下に log directory が存在することが確認できます。 この結果から、/data/log (root) = /var/log/dme/log (admin) ではないかと推測できます。
apic1# mount | grep "vg_ifc0_ssd" | awk '{print $3}' | xargs ls -
ls: cannot access -: No such file or directory
/data/challenge.plugin
/controller/sbin:
acidiag admin.cookie avread category.yaml cluster_health.py collectLocalDbs.py parse.py techsupport-filter trimtechsupport.py
/data/devicescript:
CISCO.ASA.1.2 CISCO.ASA_FI.1.2 F5.BIGIP.1.2.0 F5.iWorkflow.2.0-APIC Fortinet.FGAPIC.1.2 Fortinet.FGAPIC.1.3 cache install upload
CISCO.ASA.1.2_CONT CISCO.ASA_FI.1.2_CONT F5.BIGIP.1.2.0_CONT F5.iWorkflow.2.0-APIC_CONT Fortinet.FGAPIC.1.2_CONT Fortinet.FGAPIC.1.3_CONT images unpack
/data/log.lastupgrade:
/var/log/dme:
core log log.lastupgrade nginx oldlog
/var/log/dme/nginx:
access.log error.log netstat.log nginx.pid
/var/run/mgmt/log:
ishell-13726.error.log ishell-15374.error.log ishell-15374.log.1.gz ishell-15374.log.3.gz ishell-15374.log.5.gz scriptcontainer.log
ishell-13726.log ishell-15374.log ishell-15374.log.2.gz ishell-15374.log.4.gz pam.module.log
apic1#
fault が出力され、よくわからない path が表示された場合、それは root user から見た path の場合があります。 そのときは、上記例のように調べると、admin user で使用している path を見つけることができるかもしれません。
