[Linux] SadSevers 解题思路

VMware虚拟机安装

暂且记录一下安装的东西是啥意思

基本信息
- 全名：这是计算机名字，在命令行终端显示
- 用户名：默认用户名，在命令行终端显示
虚拟机名字和安装位置
- 虚拟机名称：指VMware管理虚拟机用的
最大磁盘大小
- 最大磁盘大小：虚拟机占用宿主机的最大容量，这个可以调整大一些，因为虚拟机实际占用大小是慢慢增加的，而不是一开始就是指定值大小，并且这个值后期可以修改。
自定义硬件
- 不一定给的配置越高虚拟机越流畅，因为一方面会导致宿主机的资源太少，另一方面宿主机调动这么多虚拟机资源也会有负担。这个配置虚拟机创建好之后也可以再更改
- 三种网络适配器：
  - 桥接模式：
    - 虚拟机直接连接到主机的物理网络，就像是网络中的一个独立主机。
    - 虚拟机将会获得与物理网络相同的IP地址（通常通过DHCP分配），因此它可以与网络中的其他物理设备进行直接通信。
    - 适用于需要虚拟机与外部网络设备进行完全交互的场景，例如测试网络服务和配置。
  - NAT模式：
    - 允许虚拟机通过主机的IP地址访问外部网络。
    - 虚拟机在一个虚拟的内部网络中运行，具有独立的私有IP地址，通过主机的网络连接进行地址转换。
    - 限制了外部网络直接访问虚拟机，但虚拟机可以主动访问外部网络。适合需要访问互联网但不需要被外部设备访问的场景。
  - 仅主机模式：
    - 虚拟机与主机之间建立一个隔离的网络，不与外部网络相连。
    - 虚拟机可以与主机以及同一模式下的其他虚拟机进行通信，但不能直接访问外部网络。
    - 适用于需要隔离测试环境或模拟内部网络的情况，不需要与外部设备通信。
  - 综上，要上网选择 NAT

快照

虚拟机快照用于记录虚拟机在特定时间点的状态，包括虚拟机的内存状态、硬盘数据以及相关的设置。当你创建一个快照时，相当于给当前的虚拟机做了一个“备份”，可以在需要时恢复到此状态。我们在刚创建好虚拟机时创建一个快照方便后续恢复到这个最“纯净”的时候。
恢复快照可以让虚拟机恢复到拍摄快照对应的时刻。比如可以在进行某个危险操作之前先拍摄快照，如果操作出错那么就可以通过恢复快照回到出错之前的状态，就不再需要重新安装虚拟机了。

SadServers场景

因为是初学者，可能某些理解不太对。以下仅为个人理解。

“Saint John”: what is writing to this log file?

Description: A developer created a testing program that is continuously writing to a log file /var/log/bad.log and filling up disk. You can check for example with tail -f /var/log/bad.log. This program is no longer needed. Find it and terminate it. Do not delete the log file.

Solution：

找到进程：fuser -v /var/log/bad.log
kill 进程号

“Saskatoon”: counting IPs.

Description: There’s a web server access log file at /home/admin/access.log. The file consists of one line per HTTP request, with the requester’s IP address at the beginning of each line.

Find what’s the IP address that has the most requests in this file (there’s no tie; the IP is unique). Write the solution into a file /home/admin/highestip.txt. For example, if your solution is “1.2.3.4”, you can do echo "1.2.3.4" > /home/admin/highestip.txt

Test: The SHA1 checksum of the IP address sha1sum /home/admin/highestip.txt is 6ef426c40652babc0d081d438b9f353709008e93 (just a way to verify the solution without giving it away.)

Solution：

提取IP文件的地址，统计次数，并排序后打印第一个
- awk '{print $1}' /home/admin/access.log | sort | uniq -c | sort -rn | head -1 | awk '{print $2}'
  - {print $1} ：每行的第一个字段（IP地址）
  - sort ：将 IP 地址按字母顺序排序
  - uniq -c ：统计每个唯一 IP 地址的出现次数，-c ：在每行前面显示该 IP 出现的次数
  - sort -rn ：按次数降序排序，-r：降序排序，-n：按数值排序
  - head -1：只取第一行
  - awk '{print $2}'：从格式 次数 IP地址 中提取 IP 地址（第二列）
用echo写入home/admin/highestip.txt

“Bucharest”: Connecting to Postgres

Description: A web application relies on the PostgreSQL 13 database present on this server. However, the connection to the database is not working. Your task is to identify and resolve the issue causing this connection failure. The application connects to a database named app1 with the user app1user and the password app1user.

Credit PykPyky

Test: Running PGPASSWORD=app1user psql -h 127.0.0.1 -d app1 -U app1user -c '\q' succeeds (does not return an error).

Solution：

执行命令PGPASSWORD=app1user psql -h 127.0.0.1 -d app1 -U app1user -c '\q'

1- psql: error: FATAL:  pg_hba.conf rejects connection for host "127.0.0.1", user "app1user", database "app1", SSL on
2- FATAL:  pg_hba.conf rejects connection for host "127.0.0.1", user "app1user", database "app1", SSL off

sudo -u postgres psql -t -P format=unaligned -c 'SHOW hba_file;'
- 找到这个文件的位置，进入目录
查看pg_hba.conf
发现reject
- 最前面两条“全拒绝”规则把任何 TCP/IP 连接都挡掉了，reject 行按顺序匹配，只要客户端走 TCP（含 127.0.0.1），还没轮到后面的
注释两条规则或移到最后
保存后重载配置
- sudo systemctl reload postgresql

Reason：

pg_hba.conf 文件中最前面两条规则使用了 reject 方法，无条件拒绝了所有 TCP/IP 连接（包括 localhost 的 127.0.0.1）
- pg_hba.conf 是 PostgreSQL 的主机基认证（Host-Based Authentication）配置文件，它控制谁（user）、从哪里（host）、连接哪个数据库（database）、用什么方式（local 或 host）可以访问，以及采用何种认证方法（md5、trust、reject 等）。
- 文件中的规则按从上到下的顺序逐一匹配：PostgreSQL 会从第一行开始检查，找到第一条匹配的规则就立即应用它，后面的规则不会再看（官方文档明确强调顺序的重要性）。
通常是人为误配置或安全加固时遗留的问题：
- 有人想阻止外部远程连接，把 reject 规则加在前面作为“默认拒绝”，但忘记或没意识到 localhost 的 TCP 连接（127.0.0.1）也会被挡。
- 正常情况下，localhost TCP 连接应该有单独的允许规则，如
```
1host    all             all             127.0.0.1/32    md5
2host    all             all             ::1/128         md5
```

“Alexandria”: The Vanishing Backups

Description: A critical backup cron job has silently stopped working 3 days ago. The backup script is located at /opt/backup/backup.sh and should create daily backups in /var/backups/daily/, but no new backups have been created recently.

Looking at the backup directory, you can see old backup files from a few days ago, proving the system used to work. However, there are no error emails, no obvious error logs, and the cron service appears to be running normally.

Fix ALL issues preventing the backups from running, so that backups are created successfully and reliably.

Test directory: /var/backups/daily/ Backup script: /opt/backup/backup.sh

Test: The solution will be validated by checking if a backup file has been created in the last 10 minutes.

The “Check My Solution” button runs the script /home/admin/agent/check.sh, which you can see and execute.

Solution：

手动运行脚本 sudo /opt/backup/backup.sh 发现锁文件：

1admin@i-0866e3e49c14825af:~$ sudo /opt/backup/backup.sh
2Error: Backup already running (lock file exists)

查看cron服务状态 systemctl status cron.service：

 1admin@i-0866e3e49c14825af:~$ systemctl status cron.service
 2● cron.service - Regular background program processing daemon
 3     Loaded: loaded (/usr/lib/systemd/system/cron.service; enabled; preset: enabled)
 4     Active: active (running) since Sat 2025-12-27 07:29:23 UTC; 1min 25s ago
 5 Invocation: b0a20ceeebc04b07ae9aa0519b46a888
 6       Docs: man:cron(8)
 7   Main PID: 763 (cron)
 8      Tasks: 1 (limit: 503)
 9     Memory: 496K (peak: 1.8M)
10        CPU: 23ms
11     CGroup: /system.slice/cron.service
12             └─763 /usr/sbin/cron -f
13Dec 27 07:29:23 i-0866e3e49c14825af systemd[1]: Started cron.service - Regular background program pro>
14Dec 27 07:29:23 i-0866e3e49c14825af cron[763]: (CRON) INFO (pidfile fd = 3)
15Dec 27 07:29:23 i-0866e3e49c14825af cron[763]: (CRON) INFO (Running @reboot jobs)
16Dec 27 07:30:01 i-0866e3e49c14825af CRON[1469]: pam_unix(cron:session): session opened for user root(>
17Dec 27 07:30:01 i-0866e3e49c14825af CRON[1471]: (root) CMD (/opt/backup/old_backup.sh > /dev/null 2>&>
18Dec 27 07:30:01 i-0866e3e49c14825af CRON[1469]: pam_unix(cron:session): session closed for user root

Dec 27 07:30:01 ... CRON[1471]: (root) CMD (/opt/backup/old_backup.sh > /dev/null 2>&1) 说明crontab里配置的仍然是 old_backup.sh，而不是正确的backup.sh。

编辑root的**crontab ** sudo crontab -e
- old_backup.sh 改为 backup.sh
查看ls /opt/backup/ 并删除锁文件 sudo rm -f /opt/backup/backup.lock
重新启动 sudo /opt/backup/backup.sh

Reason：

crontab 配置的脚本路径错误
- root 的 crontab 里写的仍然是旧脚本：/opt/backup/old_backup.sh
- 正确的、当前正在使用的备份脚本是 /opt/backup/backup.sh
- 很可能之前有人把脚本重命名或替换成了新版本，但忘记更新 cron 配置
残留的锁文件导致手动测试也失败
- 正确的 backup.sh 脚本内部有锁机制：会检查 /opt/backup/backup.lock 是否存在。
- 如果锁文件存在，就认为“上一次备份还在运行”，直接报错退出： Error: Backup already running (lock file exists)
- 很可能是几天前备份异常中断（比如机器重启、进程被杀等），导致锁文件没被正常删除，残留了下来。