LNMP 源码编译与 DVWA 靶场部署：一堂课踩完的所有坑

之前写过 phpStudy 搭 DVWA 和双靶场踩坑，这篇是课堂版：源码编译路线的 LNMP。坑比一键面板多得多，但正因为源码装，才把 Linux 服务管理的底层机制讲透了。

0x01 SSH 连不上：由底向上的排查链

远程连接失败时的标准排查顺序（网络 → 服务 → 策略）：

ping <IP>                    # 1. 网络通不通
systemctl status sshd        # 2. 服务起没起
ss -tlnp | grep 22           # 3. 端口听没听（没装 net-tools 用 ss）

逐层拆弹：

服务没装：apt install ssh / openssh-server；
起不来：先怀疑防火墙（Ubuntu ufw disable）和 SELinux（setenforce 0 临时关闭验证）——这两个”拦路虎”占一半的疑难杂症；
root 登不上：默认禁止 root 远程，改 /etc/ssh/sshd_config 的 PermitRootLogin yes 后重启服务。

还有一个隐蔽坑：MySQL 曾因注册表/服务文件里服务名拼接错误多了非法参数导致自启动失效——现象像端口问题，根因是配置文件，遇到”服务莫名起不来”要去看服务定义本身。

# 依赖先行：gcc / make / pcre / zlib
./configure --prefix=/usr/local/nginx
make && make install

源码安装绕过了包管理器，也绕过了系统服务管理——/usr/lib/systemd/system/ 里根本没有它的 service 单元文件。课堂由此引出了 systemctl 的运行机制（这是本篇最值钱的知识点）：

systemctl start nginx 的本质是：systemd 读取 xxx.service 单元文件里的 ExecStart 路径，替你拉起进程；
没有 service 文件 → systemctl 无从下手 → 只能手动执行 /usr/local/nginx/sbin/nginx 启动；
反过来，想纳入 systemd 管理就自己写一个 service 文件（课上后面用 Podman 跑服务时就现场写了一个）；
验证启动成功的标准永远是看端口：ss -tlnp | grep 80。

配置改完必须 reload：./nginx -s reload——改完不重启等于白改。

Nginx 只分发静态内容，PHP 请求要转发给 PHP-FPM：

后来 Docker 环境里 PHP 版本不对，就是靠改回这里把流量从容器切回本地 9000 的——/usr/local/nginx/conf/nginx.conf 里指向哪个 9000，决定了 PHP 跑在谁身上。

apt install mariadb-server
mysql_secure_installation    # root 初始化

DVWA 部署三步：源码放 Web 根目录 → 改 config/config.inc.php 的数据库连接 → 访问 setup 页初始化。课堂现场踩的坑：

文件权限导致访问失败（Web 目录属主要对 www-data 可读）；
版本兼容性地狱：Ubuntu 仓库 PHP 版本过高/过低都会让 DVWA 报 500——课堂从 phpStudy 低版本试到 MySQL 8.0 高版本来回横跳，最后结论是用 Docker 打包低版本 PHP 镜像最干净：环境不兼容时，把”降级环境”打成镜像，宿主机只留端口映射；
MariaDB 与 MySQL 语法有差异，DVWA 初始化 SQL 报错时直接定位 database/ 下对应语句改写（先分析后动手，别让 AI 盲改）；
部署前给虚拟机拍快照——环境玩崩了能回滚，这是省命的教训。

课程对容器的定位很务实：大三大二按需掌握，先会用再理解。

把这篇的底层逻辑串起来：Linux 上一切服务 = 一个可执行文件 + 一份描述它的配置。

这个模型后面在 CS 服务端部署（Ubuntu + JDK + 手动启动 teamserver）、提权（服务路径劫持）里全都复用到了。