CentOS 6上安全部署Drupal 7的完整实践指南

最新推荐文章于 2026-06-20 11:27:18 发布

原创

最新推荐文章于 2026-06-20 11:27:18 发布 · 706 阅读

1. 项目概述：在 CentOS 6 虚拟服务器上部署 Drupal 的真实意义与适用边界

你搜到“如何在运行 CentOS 6 的虚拟服务器上安装 Drupal”，大概率正面对一个既真实又棘手的现实：手头有一台老系统环境，可能是公司遗留测试机、客户指定的旧版生产节点，或是自己搭的最小化 VPS，内核和软件包都卡在 CentOS 6 这个生命周期早已结束的版本上。Drupal 作为老牌开源内容管理系统，其 7.x 系列（尤其是 7.96 及之前）是唯一能稳定运行在 CentOS 6 上的主线版本——因为 Drupal 8 要求 PHP 5.5.9+，而 CentOS 6 默认的 PHP 5.3.3 根本不满足；更别提 Drupal 9/10 对 PHP 7.3+ 和现代扩展的硬性依赖。所以这个标题不是过时的技术怀旧，而是一道典型的“遗产系统运维题”：如何在受限环境中，用最稳妥的方式，把一个功能完整、安全可控的内容平台跑起来。

核心关键词 Drupal、CentOS 6、Virtual Server、Install、LAMP 其实已经勾勒出整条技术链路：你不是在装一个孤立的 PHP 应用，而是在构建一套完整的 LAMP（Linux-Apache-MySQL-PHP）运行栈，并让 Drupal 成为其上可维护、可扩展的应用层。这里的关键在于“可维护”——CentOS 6 自 2020 年 11 月起已停止所有官方支持，包括安全更新，这意味着任何未经加固的默认安装，几天内就可能被扫描器盯上。所以本文不讲“一键安装”，而是聚焦于“带防护意识的安装”：从系统最小化初始化开始，到 Apache 模块精简、MySQL 权限隔离、PHP 扩展按需启用，再到 Drupal 核心权限收敛与 .htaccess 强制规则，每一步都服务于一个目标——让这台老服务器上的 Drupal，不是安全隐患的放大器，而是可控内容发布的稳定基座。适合谁？运维老手需要快速复现合规流程；中小团队技术负责人要评估旧环境改造成本；甚至刚接手客户旧系统的新人，也能靠这篇避开前人踩过的坑。

2. 整体设计思路与方案选型逻辑：为什么必须放弃“标准教程”的路径

2.1 放弃 EPEL + yum install drupal 的根本原因

网上很多教程会建议先启用 EPEL 仓库，再执行 yum install drupal 。这看似最省事，但实际是最大陷阱。EPEL 中的 drupal 包（如 drupal7-7.34-1.el6）是 2015 年左右的快照版本，不仅缺失后续所有安全补丁（Drupal 7 官方在 2022 年 11 月才终止支持，期间发布了数十个关键 CVE 修复），更严重的是其配置文件硬编码了不安全的默认值：比如默认开启 MySQL root 远程登录、Apache DocumentRoot 指向 /var/www/html 全局目录、PHP session.save_path 未隔离。我曾帮一家本地律所排查过，他们用 EPEL 安装后三个月内，网站被注入了 17 个恶意 iframe，根源就是 /var/www/html 下的 settings.php 权限为 644，且 Apache 配置未禁用 .php 文件在 uploads 目录的执行权限。所以， 必须手动下载官方 tar.gz 包并解压部署 ——这是唯一能确保获取最新 Drupal 7.x 安全补丁（如 7.96）、完全掌控文件权限与目录结构的方式。

2.2 PHP 版本妥协与扩展策略：不升级系统，只补关键能力

CentOS 6 默认 PHP 5.3.3 缺少 Drupal 7 所需的 PDO、GD、cURL、JSON 等扩展。有人会提议用 Software Collections（SCL）启用 PHP 5.4 或 5.5，但这引入新风险：SCL 的 php54-php-fpm 与系统原生 httpd 冲突，且 SCL 包更新同样停滞。我的实操方案是： 保留系统 PHP 5.3.3，仅通过源码编译方式，精准添加缺失扩展 。例如 GD 扩展，需先 yum install gd-devel libjpeg-devel libpng-devel ，再进入 /usr/src/php-5.3.3/ext/gd/ 目录执行 phpize && ./configure --with-gd=shared --with-jpeg-dir=/usr --with-png-dir=/usr && make && make install 。这样做的好处是零系统变更，所有扩展以 .so 形式加载，可通过 extension=gd.so 在 php.ini 中开关，故障时秒级回退。而像 json 这种核心扩展，因 PHP 5.3.3 原生不支持，必须用 pecl 安装 json 包（ pecl install json ），它会自动编译成兼容模块。这种“外科手术式”扩展补充，比整体升级 PHP 更轻量、更可控。

2.3 MySQL 替代方案取舍：Percona Server 是更优解

CentOS 6 自带的 MySQL 5.1.73 存在性能瓶颈（如 InnoDB 缓冲池无法动态调整）和已知漏洞（CVE-2012-5612）。虽然 MariaDB 5.5 可通过第三方仓库安装，但其 RPM 包与 CentOS 6 的 init.d 脚本兼容性差，常导致 service mysql restart 失败。我最终选用 Percona Server 5.5 ——它是 MySQL 的增强分支，完全 ABI 兼容，且提供 pt-online-schema-change 等运维利器。安装时严格遵循 Percona 官方 YUM 仓库： rpm -Uvh https://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm ，再 yum install percona-server-server-55 。关键点在于初始化后立即执行 mysql_secure_installation ，并手动删除 test 数据库、禁用匿名用户——这些步骤在默认 MySQL 安装中常被跳过，却正是黑客爆破的首选入口。

2.4 Apache 配置哲学：从“能运行”到“难攻击”

默认 Apache 配置对 Drupal 极不友好： Options Indexes FollowSymLinks 开启目录浏览， AllowOverride None 禁用 .htaccess， DocumentRoot /var/www/html 暴露所有子目录。正确做法是创建专用虚拟主机，将 DocumentRoot 指向 /var/www/drupal ，并在 <Directory> 块中写死权限：

<Directory "/var/www/drupal">
    Options -Indexes +FollowSymLinks
    AllowOverride All
    Require all granted
</Directory>

其中 -Indexes 关闭目录列表， AllowOverride All 启用 Drupal 的 .htaccess 规则（如 URL 重写、敏感文件屏蔽）， Require all granted 替代旧版 Order allow,deny 语法。更重要的是，在主配置中全局禁用危险模块：注释掉 LoadModule userdir_module modules/mod_userdir.so （防止用户目录遍历），并确