それマグで!

知識はカップより、マグでゆっくり頂きます。 takuya_1stのブログ

習慣に早くから配慮した者は、 おそらく人生の実りも大きい。

tcpdump で icmp (ping)のパケットを表示する

icmp で ping の受信を見たい

tcpdump を使って届いてるパケットを見ることが出来る。 ping の応答が返ってこないしとしても、応答パケットのルーティング設定が間違っている可能性もある。

そのため、ping の宛先でパケットがちゃんと届いているかチェックするとルーティングテーブルの問題を切り分けやすい。

tcpdump icmp

これで、ping パケットを見ることが出来る。

icmp を送信元で絞る

ping パケットが指定したホストから送信されているかどうかを見るには、tcpdump のフィルタリング機能で、フィルタすると便利。

tcpdump src 192.168.1.123 and icmp

and 条件で送信元を絞ることが出来る。

知っておくとネットワークトラブルでパニクらずに住む

関連資料

tcpdump でパケットをのぞき見る方法まとめ。10分で僕にも出来た。tcpdumpの使い方 - それマグで!

initramfs の本体 init.rd を展開して、busybox をみたり、起動設定を見直してみる。

init.rd を展開してみる

init.rd は initramfs を起動するためもの。/boot のパーティションに存在している。

update-initramfs で起動する。grub から起動される最小限のlinux

展開してみる・・・?

initrd ファイルはcpio なので 、cpio で展開しようとしてみる。

あれれ

cd `mktemp -d` && sudo cat /boot/initrd.img-`uname -r` | cpio -ivd
.
kernel
kernel/x86
kernel/x86/microcode
kernel/x86/microcode/AuthenticAMD.bin
62 ブロック

1ファイルしかない?そんな馬鹿な

takuya@d001:/tmp/tmp.On03d1x9GP$ tree . 
.
└── kernel
    └── x86
        └── microcode
            └── AuthenticAMD.bin

3 directories, 1 file

調べてみたら、このcpio ファイルはいくつかの組み合わせなのでうまく行かない。

linux - Why is it that my initrd only has one directory, namely, 'kernel'? - Unix & Linux Stack Exchange

そうだね。cpio ってtar みたいなもんだもんな

binwalk コマンドをいれて、中身を見てみると。。。末尾にgzip 圧縮されたものがある。

takuya@d001:/tmp/tmp.On03d1x9GP$ binwalk /boot/initrd.img-`uname -r` 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             ASCII cpio archive (SVR4 with no CRC), file name: ".", file name length: "0x00000002", file size: "0x00000000"
112           0x70            ASCII cpio archive (SVR4 with no CRC), file name: "kernel", file name length: "0x00000007", file size: "0x00000000"
232           0xE8            ASCII cpio archive (SVR4 with no CRC), file name: "kernel/x86", file name length: "0x0000000B", file size: "0x00000000"
356           0x164           ASCII cpio archive (SVR4 with no CRC), file name: "kernel/x86/microcode", file name length: "0x00000015", file size: "0x00000000"
488           0x1E8           ASCII cpio archive (SVR4 with no CRC), file name: "kernel/x86/microcode/AuthenticAMD.bin", file name length: "0x00000026", file size: "0x00007752"
31184         0x79D0          ASCII cpio archive (SVR4 with no CRC), file name: "TRAILER!!!", file name length: "0x0000000B", file size: "0x00000000"
31744         0x7C00          ASCII cpio archive (SVR4 with no CRC), file name: "kernel", file name length: "0x00000007", file size: "0x00000000"
31864         0x7C78          ASCII cpio archive (SVR4 with no CRC), file name: "kernel/x86", file name length: "0x0000000B", file size: "0x00000000"
31988         0x7CF4          ASCII cpio archive (SVR4 with no CRC), file name: "kernel/x86/microcode", file name length: "0x00000015", file size: "0x00000000"
32120         0x7D78          ASCII cpio archive (SVR4 with no CRC), file name: "kernel/x86/microcode/.enuineIntel.align.0123456789abc", file name length: "0x00000036", file size: "0x00000000"
32284         0x7E1C          ASCII cpio archive (SVR4 with no CRC), file name: "kernel/x86/microcode/GenuineIntel.bin", file name length: "0x00000026", file size: "0x0024CC00"
2443952       0x254AB0        ASCII cpio archive (SVR4 with no CRC), file name: "TRAILER!!!", file name length: "0x0000000B", file size: "0x00000000"
2444288       0x254C00        gzip compressed data, from Unix, last modified: 2019-10-18 08:19:18

ここから、bs がわかるので、それを取り出してみる。

takuya@d001:/tmp/tmp.On03d1x9GP$ dd if=/boot/initrd.img-`uname -r`  bs=2444288 skip=1 | gunzip | cpio -tdv | head
drwxr-xr-x  13 root     root            0 Oct 18 17:19 .
drwxr-xr-x   2 root     root            0 Oct 18 17:19 bin
-rwxr-xr-x   1 root     root         9424 Feb  1  2019 bin/cpio
-rwxr-xr-x   1 root     root         5751 Feb 14  2019 bin/cryptroot-unlock
-rwxr-xr-x   1 root     root       108760 Jan 14  2019 bin/date
-rwxr-xr-x   1 root     root         9624 Feb  1  2019 bin/dd
-rwxr-xr-x   1 root     root         8792 Feb  1  2019 bin/dmesg
-rwxr-xr-x   1 root     root         9992 Feb  1  2019 bin/fstype
-rwxr-xr-x   1 root     root         8920 Feb  1  2019 bin/halt
-rwxr-xr-x   1 root     root        19872 Feb  1  2019 bin/ipconfig

お、ファイルが見えるぞ。

それではこのファイルを取り出してみる

takuya@d001:/tmp/tmp.IrvVwlLK99$ dd if=/boot/initrd.img-`uname -r`  bs=2444288 skip=1 of=img.cpio.gz
takuya@d001:/tmp/tmp.IrvVwlLK99$ gunzip img.cpio.gz 
takuya@d001:/tmp/tmp.IrvVwlLK99$ cpio -idv < img.cpio 
takuya@d001:/tmp/tmp.IrvVwlLK99$ ll 
合計 194292
drwx------ 13 takuya takuya      4096 10月 18 17:35 ./
drwxrwxrwt 21 root   root        4096 10月 18 17:35 ../
drwxr-xr-x  2 takuya takuya      4096 10月 18 17:35 bin/
drwxr-xr-x  3 takuya takuya      4096 10月 18 17:35 conf/
drwxr-xr-x  2 takuya takuya      4096 10月 18 17:35 cryptroot/
drwxr-xr-x 11 takuya takuya      4096 10月 18 17:35 etc/
-rw-rw-r--  1 takuya takuya 198891008 10月 18 17:34 img.cpio
-rwxr-xr-x  1 takuya takuya      7077 10月 18 17:35 init*
drwxr-xr-x 10 takuya takuya      4096 10月 18 17:35 lib/
drwxr-xr-x  2 takuya takuya      4096 10月 18 17:35 lib64/
drwxr-xr-x  2 takuya takuya      4096 10月 18 17:35 run/
drwxr-xr-x  2 takuya takuya      4096 10月 18 17:35 sbin/
drwxr-xr-x 10 takuya takuya      4096 10月 18 17:35 scripts/
drwxr-xr-x  7 takuya takuya      4096 10月 18 17:35 usr/
drwxr-xr-x  4 takuya takuya      4096 10月 18 17:35 var/

取り出せました。

chroot してみる

takuya@d001:/tmp/tmp.IrvVwlLK99$ sudo chroot . /bin/sh


BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu7) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# 

更に単純な方法

takuya@d001:/tmp/tmp.gTlrfnehcs$ unmkinitramfs /boot/initrd.img-`uname -r`  . 

systemd.path で path(パス) を監視する。

systemd でパス監視機能を使う

systemd.path を試していきます。

はじめに

systemd でパスを監視することができる。

xxxx.path と xxxx.service をペアで作成し登録すればオッケ。

制限事項

再帰的(recursive)なパス監視はできない。

inotify を使っているので、 nfsなどネットワーク越しでは使えない。

gvfs/gio でマウントしていると inotifyが発動するはずなので cifs でもつかそう

ユーザー空間にファイルを作って作って試す

今回は、次のファイルを作って試していきます。

~/.config/systemd/user/desktop.service
~/.config/systemd/user/desktop.path

systemd のユーザー空間について、過去の資料を参考に

~/.config/systemd/user/desktop.service

[Unit]
Description=DesktopSample

[Service]
WorkingDirectory=/home/takuya/Desktop
ExecStart=/bin/echo Hello From Service 

[Install]
WantedBy=default.target

~/.config/systemd/user/desktop.path

[Unit]
Description=DesktopSample

[Path]
## PathModified と PathChanged は別物
## 再帰的( recursively ) にパスの監視はできない。
## inotify をベースにしている
PathChanged=/home/takuya/Desktop
#PathModified=/home/takuya/Desktop
[Install]
WantedBy=default.target

ロードする

systemctl --user daemon-reload

起動する

enable して

systemctl --user enable desktop.service
systemctl --user enable desktop.path

restart しておく

systemctl --user restart desktop.service
systemctl --user restart desktop.path

コレで起動するので、あとはログを見ながら、動作する様子を見る

journalctl でログを開いておく

path の監視が起動したときのログ

journalctl --user -f  -u desktop.path

service が起動したときのログ

journalctl --user -f  -u desktop.service

-f をつけているので、ログは tailf と同じく following される。

動作を実験してみる。

いくつか、ファイルを作成したり、ファイルを更新したりして パスを書き換える実験をしておく

cd ~/Desktop/
echo 更新テスト > a 
echo 更新テスト2 > a 
echo 更新テスト3 > a  
echo 更新テスト4 >> a  
echo 更新テスト5 >> a  
rm a 
touch a 
chmod 777 a 
rm a 
mkdir  a 
rmdir a 

あとは、ログを見ながら、このタイミングでイベント発火するとか確認しておけばいい。

再帰的監視はできない

ディレクトリを再帰的に監視する機能は使えないようです。

代わりに、PathChanged を複数書くことができます。

このように複数書くことができます。

[Path]
PathChanged=/home/takuya/Desktop
PathChanged=/home/takuya/Desktop/.hidden
PathChanged=/home/takuya/Desktop/.gitignore
PathChanged=/home/takuya/Desktop/.git

更新について

PathModifiedとPathChanged がある。man systemd.path を見るとあれこれ書いてある。

PathChanged について

PathChanged= may be used to watch a file or directory and activate the configured unit whenever it changes. It is not activated on every write to the watched file but it is activated if the file which was open for writing gets closed.

PathModified については

PathModified= is similar, but additionally it is activated also on simple writes to the watched file.

たぶん、次のようなことだと思う。 - PathChanged は open → close されたら発動 - PathModified append された発動

open されたまま、追記されていくデータファイルやログファイルを追いかけるでもない限り PathChanged で問題ないと思われる。

その他の監視モード

  • パスが存在したらなにかする。
  • パスに変更がアレばなにかする。
  • ディレクトリが空っぽ以外になったらなにかする。
  • ファイルを指定をglob でやる

などがある。それぞれ次の名前で定義されている

PathExists=, PathExistsGlob=, PathChanged=, PathModified=, DirectoryNotEmpty=

簡単に実装できて便利。

「できる」だけであり、痒いところまで手が届くような使い勝手がいいものではない。

ただ、systemd のユーザー空間と組み合わせて、ユーザー空間で独自にぱぱっと関する程度ならお手軽でいいと思う。

細かい部分まで実装したいなどの用途に向かない。

例えば、ファイルが新規作成された、更新された、truncate されたとか、ディレクトリ内部に作成されたファイル名が知りたい。などなど。 細かい点について作業をしたいもののが欲しいなら inotify 系の python や npm/fsevent 系を使って細々書いておき、書いたpython を service 化するほうがずっといいだろうな。

systemd.path はgnome デスクトップなどで作成されるファイルを手軽に監視して同期したいなどで重宝すると思います。

参考資料

  • man systemd.path

関連資料

https://takuya-1st.hatenablog.jp/entry/2019/08/09/004829