これは何？

Linuxサーバのトラブルシューティング問題集 SadServers の解法メモ。
使用したコマンドなどについて書き残します。
完全にネタバレなので問題を見ていない人はブラウザバックを推奨します。

Linux初学者なのでところどころ理解が怪しい部分などがあります。ご指摘歓迎です。

1. what is writing to this log file?

ログに書き込み続けているプロセスを特定し、killコマンドで終了する。

ps

プロセス一覧の表示。
ps auxfやps -efで確認するのが主流らしい。
ps auxfの方が情報量が多いが、ps -ef はPPID(親プロセスID)を表示できる。

lsof

ファイルを開いているプロセスを確認できる。

ubuntu@ip-172-31-32-108:/$ lsof /var/log/bad.log 
COMMAND   PID   USER   FD   TYPE DEVICE SIZE/OFF  NODE NAME
badlog.py 632 ubuntu    3w   REG  259,1    19541 67701 /var/log/bad.log

さらにプロセスIDを指定することで、cwdなどが調べられる。

ubuntu@ip-172-31-32-108:/$ lsof -p 632
COMMAND   PID   USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
badlog.py 632 ubuntu  cwd    DIR  259,1     4096 258156 /home/ubuntu
...

3. counting IPs

ファイル内で登場頻度が一番多い単語を特定する。

awk

スペースやタブで区切られた文字列の、1つ目の要素を取り出す

awk '{print $1}'

Fオプションで区切り文字を指定可能

awk -F'[:]' '{print $1}'

uniq -c

各要素を出現回数と一緒に表示できる

    482 66.249.73.135
    364 46.105.14.53
    357 130.237.218.86
    273 75.97.9.59
    113 50.16.19.13

4. can't serve web file

ファイアウォールの修正。

root@ip-172-31-21-14:/# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
DROP       tcp  --  anywhere             anywhere             tcp dpt:http

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

設定を確認すると、httpのINPUTをすべてDROP(パケットを破棄)する設定になっている。
また、Chain INPUT (policy ACCEPT)とあることから、ルールが指定されていないパケットについては一律でACCEPT(パケットを許可)する状態。

このため、当該設定を削除すれば良い。

root@ip-172-31-21-14:/# iptables -D INPUT 1
root@ip-172-31-21-14:/# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

ついでにChain INPUTの設定をpolicy DROPに変更して問題を解いてみる。

root@ip-172-31-21-14:/# iptables -P INPUT DROP

コマンドを打った瞬間プロンプトが動かなくなった。
policy DROPにしたのでこの瞬間にサーバーへの接続が弾かれてしまったらしい（それはそう）。
policyをDROPに変更するときは先にACCEPTの設定を行わないといけない。

ACCEPTにSSHとか入れればpolicy DROPにしても動くのでは…？と考えたが、これ以上リトライして問題サーバを起動するのは無作法なので、一旦ここまで。

5. can't write data into database.

PostgreSQLが立ち上がらないエラーの解消。

df

ディスクの空き領域のサイズを表示する。(disk freeの略)

root@ip-172-31-46-78:/# df -h
Filesystem       Size  Used Avail Use% Mounted on
udev             224M     0  224M   0% /dev
tmpfs             47M  1.5M   46M   4% /run
/dev/nvme1n1p1   7.7G  1.2G  6.1G  17% /
tmpfs            233M     0  233M   0% /dev/shm
tmpfs            5.0M     0  5.0M   0% /run/lock
tmpfs            233M     0  233M   0% /sys/fs/cgroup
/dev/nvme1n1p15  124M  278K  124M   1% /boot/efi
/dev/nvme0n1     8.0G  8.0G   28K 100% /opt/pgdata

さらにlsコマンドで/opt/pgdataを見ると、7GBのバックアップファイルが幅を利かせている。

root@ip-172-31-46-78:/# ls -lh /opt/pgdata
total 8.0G
-rw-r--r--  1 root     root       69 May 21 22:20 deleteme
-rw-r--r--  1 root     root     7.0G May 21 22:06 file1.bk
-rw-r--r--  1 root     root     923M May 21 22:17 file2.bk
-rw-r--r--  1 root     root     488K May 21 22:23 file3.bk
drwx------ 19 postgres postgres 4.0K May 21 22:24 main

これを削除して再起動する。
問題文からbkファイルの要不要は判断できないけれど、ディレクトリ一番上のファイルにdeletemeと書いてあるので消して良い。

6. Borked Nginx

/etc/systemd/system配下にあるnginxの設定ファイルを修正する。

7. Docker container won't start.

Dockerfileの修正。

ポート8888でexposeをする必要があるが、8888は既に別のアプリが使っている。ポートを使用しているプロセスを特定して削除する。

netstat

ホストのネットワーク接続状態を確認できる。
pオプションをつけるとそれぞれの接続を使っているプロセスが表示できる。

admin@ip-172-31-41-254:~/app$ sudo netstat -pa | grep 8888
tcp        0      0 0.0.0.0:8888            0.0.0.0:*               LISTEN      617/nginx: master p 
tcp6       0      0 [::]:8888               [::]:*                  LISTEN      617/nginx: master p

8. it's always DNS.

/etc/nsswitch.confで名前解決の設定を修正する。
（DNS周りのエラーなのでresolv.confに問題があるのか…？と色々調べていたが不正解。そもそもDNSサーバに問い合わせができていないので見当違いだった）

9. Docker web container can't connect to db container.

WORDPRESS_DB_HOSTがデフォルト値の'mysql'のままになっているので、これを修正する。

inspectでIPAddressを確認。

admin@ip-172-31-19-232:/$ sudo docker inspect mariadb | grep IPAddress
            "SecondaryIPAddresses": null,
            "IPAddress": "172.17.0.2",
                    "IPAddress": "172.17.0.2",

mariadbコンテナは3306番ポートをexposeしているので、このIPアドレスを指定すればDBへの接続ができる。

ここからどう対処するか考える。
wp-config.phpには

define( 'DB_HOST', getenv_docker('WORDPRESS_DB_HOST', 'mysql') );

とあるので、以下のように環境変数WORDPRESS_DB_HOSTを追加してコンテナを再起動すれば、コンテナ間の通信は通るようになる。

admin@ip-172-31-19-232:/$ sudo docker ps
CONTAINER ID   IMAGE            COMMAND                  CREATED        STATUS         PORTS                    NAMES
6ffb084b515c   wordpress:sad    "docker-entrypoint.s…"   3 months ago   Up 3 minutes   0.0.0.0:80->80/tcp       wordpress
0eef97284c44   mariadb:latest   "docker-entrypoint.s…"   3 months ago   Up 3 minutes   0.0.0.0:3306->3306/tcp   mariadb

admin@ip-172-31-19-232:/$ sudo docker rm -f 6ffb084b515c
6ffb084b515c

admin@ip-172-31-19-232:/$ sudo docker run -d -e WORDPRESS_DB_HOST=172.17.0.1 --name wordpress -p 80:80 wordpress:sad
e38fcd8eae5b629898d8d72b7ef539669d7bf60098f958e2a31573e74bef5659

admin@ip-172-31-19-232:/$ sudo docker exec wordpress env | grep WORDPRESS_DB_
WORDPRESS_DB_HOST=172.17.0.2
WORDPRESS_DB_PASSWORD=password
WORDPRESS_DB_USER=root

しかし、この設問は以下のテストが通ることを要求している。

Test: sudo docker exec wordpress mysqladmin -h mysql -u root -ppassword ping . The wordpress container is able to connect to the database in the mariadb container and returns mysqld is alive.

テストでホスト名に -h mysql を指定しているので、このままではテストが通らない。
これを通すために、/etc/hostsに一行追加する。

admin@ip-172-31-19-232:/$ sudo docker exec -ti wordpress bash
root@da9ad9f3ad05:/var/www/html# echo "172.17.0.1 mysql" >> /etc/hosts

これでテストも通る。

admin@ip-172-31-19-232:/$ sudo docker exec wordpress mysqladmin -h mysql -u root -ppassword ping
mysqld is alive

10. Docker and Kubernetes web app not working.

ImagePullBackOffでPodが立ち上がらない状態なので、プライベートのDocker Registryにイメージをpushする。
また、curl localhost:8888 のリクエストを成功させるためにPodのポートフォワーディングを行う必要がある。

admin@ip-10-0-0-64:~$ kubectl port-forward deployments/webapp-deployment 8888 -n web
Forwarding from 127.0.0.1:8888 -> 8888
Forwarding from [::1]:8888 -> 8888

11. WTFIT – What The Fun Is This?

wtfitという名前の謎のファイルがあるので、どうにか実行できるようにする。
（CTFチックな問題だ）

admin@ip-172-31-36-138:~$ file wtfit 
wtfit: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=_iHDgQr9_DkcDPzFkdEV/KeopbEbY41Cs4Jx-plaD/bLd_UQ3kiokG80g9hhbY/qtKkikMAZmQbLl9qoMCF, not stripped

とりあえず実行可能ファイルではあるらしい。

admin@ip-172-31-36-138:~$ ls -l
total 6236
drwxr-xr-x 2 admin admin    4096 Sep 13 18:18 agent
-rw-r--r-- 1 admin admin 6381234 Sep 13 18:17 wtfit

実行権限がないのでchmodする。

admin@ip-172-31-36-138:~$ chmod 755 wtfit 
bash: /usr/bin/chmod: Permission denied

ええ…
chmodをカレントディレクトリにinstallする。

admin@ip-172-31-36-138:~$ install -m 755 /usr/bin/chmod .
admin@ip-172-31-36-138:~$ ./chmod 755 wtfit
admin@ip-172-31-36-138:~$ ls -l
total 6300
drwxr-xr-x 2 admin admin    4096 Sep 13 18:18 agent
-rwxr-xr-x 1 admin admin   64448 Nov  6 16:57 chmod
-rwxr-xr-x 1 admin admin 6381234 Sep 13 18:17 wtfit

chmodできた。
再実行。

admin@ip-172-31-32-154:~$ /home/admin/wtfit
ERROR: can't open config file

config fileが開けないとだけ出力されている。
straceで再確認。

admin@ip-172-31-36-138:~$ strace /home/admin/wtfit
...
openat(AT_FDCWD, "/home/admin/wtfitconfig.conf", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
write(1, "ERROR: can't open config file\n", 30ERROR: can't open config file
) = 30
exit_group(1)                           = ?
+++ exited with 1 +++

wtfitconfig.confを開こうとしているが、ファイルが存在していない。
空ファイルを作成して再実行。

admin@ip-172-31-36-138:~$ touch /home/admin/wtfitconfig.conf
admin@ip-172-31-36-138:~$ /home/admin/wtfit 
ERROR: can't connect to server

サーバーに接続できないらしい。
tcpdump -i loを実行し、自分自身へのパケットをキャプチャする。

admin@ip-172-31-36-138:~$ sudo tcpdump -i lo
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on lo, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:05:12.868414 IP localhost.34996 > localhost.7777: Flags [S], seq 534663709, win 65495, options [mss 65495,sackOK,TS val 383227227 ecr 0,nop,wscale 6], length 0
17:05:12.868426 IP localhost.7777 > localhost.34996: Flags [R.], seq 0, ack 534663710, win 0, length 0
17:05:12.868414 IP localhost.34996 > localhost.7777: Flags [S], seq 534663709, win 65495, options [mss 65495,sackOK,TS val 383227227 ecr 0,nop,wscale 6], length 0
17:05:12.868425 IP localhost.7777 > localhost.34996: Flags [R.], seq 0, ack 534663710, win 0, length 0

ポート7777に何らかのリクエストを送っている。
問題文に書いてあった wtfit needing to communicate to a service in order to start の処理らしい。

ポート7777で適当なサーバーを立ち上げる。

admin@ip-172-31-36-138:/$ python3 -m http.server 7777
Serving HTTP on 0.0.0.0 port 7777 (http://0.0.0.0:7777/) ...

admin@ip-172-31-36-138:/$ /home/admin/wtfit
OK.

何がOKなのかはよく分からないけれど、題意は満たせたらしい。

12. can't write data into database.

/etc/fstab

マウントするファイルシステムを管理するファイル。

# /etc/fstab: static file system information
UUID=5db68868-2d70-449f-8b1d-f3c769ec01c7 / ext4 rw,discard,errors=remount-ro,x-systemd.growfs 0 1
UUID=72C9-F191 /boot/efi vfat defaults 0 0
/dev/xvdb /opt/pgdata xfs defaults,nofail 0 0

この設定だと「/dev/xvdb」デバイスを「/opt/pgdata」ディレクトリにマウントする。

root@ip-172-31-25-11:/# lsblk -f
NAME         FSTYPE LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINT
nvme0n1      xfs          9a2e1bf9-50e8-41a9-9f8c-5dd837869c50                
nvme1n1                                                                       
├─nvme1n1p1  ext4         5db68868-2d70-449f-8b1d-f3c769ec01c7      6G    16% /
├─nvme1n1p14                                                                  
└─nvme1n1p15 vfat         72C9-F191                             123.5M     0% /boot/efi

lsblkでnvme0n1がunmountになっていることが分かるので、「/dev/xvdb」を「/dev/nvme0n1」に書き換えてsystemctl daemon-reloadで設定を反映する。