Ubuntu 14.04 LAMP环境搭建实战：Apache+PHP5+MySQL5.5一键部署

1. 项目概述：在 Ubuntu 14.04 上亲手搭起一套能跑起来的 LAMP 环境

“¿Cómo instalar Linux, Apache, MySQL, PHP (LAMP) en Ubuntu 14.04?”——这个西班牙语标题直译过来就是“如何在 Ubuntu 14.04 上安装 Linux、Apache、MySQL、PHP（LAMP）？”。虽然它用的是西语，但背后指向的是一套全球开发者、运维人员、学生和自学爱好者最常接触、也最常卡壳的基础技术栈：LAMP。Linux 是操作系统底座，Apache 是老牌 Web 服务器，MySQL 是关系型数据库，PHP 是动态网页脚本语言。四者组合，构成了一个能运行 WordPress、Drupal、自建后台系统甚至小型 SaaS 原型的最小可行环境。

你可能正坐在一台刚装好 Ubuntu 14.04 的物理机或虚拟机前，终端窗口开着，光标在闪烁，心里却没底：敲完 sudo apt-get install 后，Apache 能不能监听 80 端口？浏览器输 http://localhost 是显示 “It works!” 还是 404？PHP 文件会不会直接被下载而不是执行？MySQL 的 root 密码到底设在哪一步？这些不是理论问题，而是你按下回车后立刻要面对的真实反馈。我当年第一次配 LAMP，就在 /var/www/html/ 下放了个 info.php ，结果浏览器里一片空白，查日志发现 Apache 根本没加载 mod_php 模块——这种细节，文档里往往一笔带过，但实操中就是拦路虎。

这篇内容专为“想动手、怕出错、需要闭环答案”的人而写。它不讲抽象架构图，不堆砌术语定义，只聚焦 Ubuntu 14.04 这个特定版本下的完整链路：从系统初始化检查，到 Apache 启动验证；从 MySQL 安全加固的三步操作，到 PHP 模块启用与 php.ini 关键参数调优；再到最后用一个带数据库连接的真实 PHP 页面做端到端测试。所有命令都经过 Ubuntu 14.04.6 LTS（最终维护版）实测，所有路径、配置文件位置、默认行为均基于该发行版的官方包管理逻辑。如果你用的是更新的 Ubuntu 版本（如 20.04 或 22.04），本文仍具参考价值，但需注意 systemd 替代 upstart 、 mysql 包默认替换为 mariadb 等关键差异——这些我会在对应环节明确标注，避免你照搬命令后一头雾水。

它适合三类人：一是刚接触 Linux 服务部署的新手，需要一份“每一步都有回显、每一步都能验证”的操作手册；二是正在备考 LPIC 或 RHCSA 的学习者，LAMP 是必考场景，本文覆盖了考试中高频出现的权限、日志、模块加载等得分点；三是需要快速搭建测试环境的开发者，比如你要本地跑通一个老版本的 ThinkPHP 3.2.3（标题热词里明确提到了），它的依赖就是 PHP 5.4+ 和 MySQL 5.5+，而 Ubuntu 14.04 的仓库正好提供 PHP 5.5.9 和 MySQL 5.5.62，天然匹配。别被“14.04”这个年份吓退——它不是古董，而是经过七年长期支持验证的稳定基线，很多遗留系统、教学实验、CTF 靶场（比如 Apache Shiro 漏洞复现环境）依然以它为蓝本。我们不是在怀旧，是在夯实地基。

2. 整体设计思路与方案选型逻辑：为什么坚持用 apt-get 而非源码编译？

2.1 选择官方仓库安装而非手动编译的核心原因

在 Ubuntu 14.04 上部署 LAMP，第一道决策关就是：用系统包管理器 apt-get 安装，还是去官网下源码自己 ./configure && make && make install ？我的答案非常明确： 无特殊需求，一律首选 apt-get 。这不是偷懒，而是基于稳定性、安全性和可维护性的综合判断。

先说稳定性。Ubuntu 14.04 的 trusty 仓库中， apache2 版本是 2.4.7， mysql-server 是 5.5.62， php5 是 5.5.9。这三个版本在 2014–2019 年间被数百万台服务器验证过兼容性。它们之间的 ABI（应用二进制接口）、配置文件结构、服务启动脚本（ /etc/init.d/apache2 ）都是深度对齐的。而如果你自己编译 Apache 2.4.39（热词里提到的版本），再手动编译 PHP 5.6，很可能遇到 libapr 版本冲突、 mod_ssl 加载失败、或者 PHP 的 mysqlnd 扩展找不到 MySQL 头文件等问题。我试过一次——编译成功，但 Apache 启动时报 Cannot load /usr/local/apache2/modules/libphp5.so ，查了三小时才发现是 libxml2 的 .so 文件路径没加进 LD_LIBRARY_PATH 。这种底层依赖问题，在 apt-get 方案里根本不存在，因为 dpkg 在安装时已自动处理所有 Depends: 和 Pre-Depends: 关系。

再说安全性。Ubuntu 官方仓库的每个包都经过 Canonical 安全团队签名，并持续接收 CVE 修复。例如，2017 年爆出的 Apache HTTP Server mod_proxy SSRF 漏洞（CVE-2017-3167），Ubuntu 在 48 小时内就发布了 apache2 的安全更新包（版本号升至 2.4.7-1ubuntu4.18）。你只需执行 sudo apt-get update && sudo apt-get upgrade ，就能一键打补丁。而源码编译的环境，补丁得你自己找、自己打、自己测试，稍有疏忽，服务器就裸奔在公网。更关键的是， apt-get 安装的 MySQL 默认禁用远程 root 登录、强制设置密码、并移除匿名用户——这三步安全加固，在 mysql_secure_installation 脚本里是标准化流程；你自己编译，就得一行行写 SQL 去删 mysql.user 表里的空用户，稍有不慎就锁死自己。

最后是可维护性。 apt-get 安装的软件，其配置文件统一放在 /etc/ 下（ /etc/apache2/ , /etc/mysql/ , /etc/php5/ ），日志统一在 /var/log/ （ /var/log/apache2/ , /var/log/mysql/ ），Web 根目录默认是 /var/www/html/ 。这种强约定让任何熟悉 Debian/Ubuntu 的运维都能快速接手。而源码安装，你可能把 Apache 装在 /usr/local/apache2/ ，PHP 装在 /opt/php5/ ，MySQL 数据目录挪到 /data/mysql/ ——路径碎片化，交接成本陡增。我在一家公司见过一个源码部署的 LAMP 环境，因原管理员离职，新同事花两天才搞清 PHP 的 extension_dir 指向哪个绝对路径。 apt-get 的价值，就体现在这种“无需解释的共识”上。

提示：唯一需要源码编译的场景，是你必须使用某个特定补丁版本（比如某次 CTF 靶场要求 Apache 2.4.39 + 特定 Shiro 漏洞 PoC），或你需要启用某个 apt 包未包含的非标准模块（如 mod_evasive ）。但即便如此，我也建议：先用 apt-get 装好基础环境，再单独编译那个模块，用 a2enmod 启用，而非全盘推翻重来。

2.2 为什么锁定 Ubuntu 14.04？它和新版 Ubuntu 的本质区别在哪？

Ubuntu 14.04 是一个分水岭版本。它发布于 2014 年 4 月，是最后一个使用 upstart 作为默认 init 系统的 LTS（长期支持）版本；2016 年的 16.04 则全面切换到 systemd 。这个底层差异，直接决定了服务管理命令的写法：在 14.04 上，你用 sudo service apache2 restart ；在 16.04+ 上，则是 sudo systemctl restart apache2