Ubuntu 12.04 + Pligg 2.0.x 完整部署指南：Apache/PHP/MySQL 版本协同配置

1. 这不是“一键安装”，而是一次对Web服务底层逻辑的重新校准

Pligg CMS 2.0.x —— 这个名字在2012年前后曾是社交书签类网站建站圈里的高频词。它不像WordPress那样主打博客，也不像Drupal那样强调模块化扩展，而是专为“用户提交链接+社区投票排序”这一特定交互模型设计的轻量级内容管理系统。它的核心价值在于：用极简的PHP+MySQL架构，实现Digg式首页热榜的实时刷新、用户积分体系、反垃圾投稿过滤和多级权限管理。但正因如此，它对运行环境的“洁净度”要求极高：Apache必须启用mod_rewrite以支持友好的URL重写；PHP版本不能高于5.4（否则mysql_*函数被弃用会导致致命错误）；MySQL需开启InnoDB引擎并配置合适的max_allowed_packet值——这些都不是安装脚本能自动判断的，而是需要你亲手触摸服务器内核的脉搏。

我第一次部署Pligg 2.0.3是在一台甲骨文VPS上，系统镜像正是Ubuntu 12.04 LTS（代号Precise Pangolin）。当时没意识到，这个看似普通的LTS版本，其默认软件源中Apache 2.2.22与PHP 5.3.10的组合，恰恰是Pligg 2.0.x唯一经过官方验证的黄金搭档。后来换用Ubuntu 14.04，PHP升级到5.5.9，结果首页报错Fatal error: Call to undefined function mysql_connect()——这根本不是代码bug，而是时代断层：Pligg 2.0.x的源码里还满是mysql_query()调用，而新PHP已将该扩展标记为deprecated。所以，本文不讲“如何快速装好”，而是带你回到2012年的技术语境里，亲手把Apache、MySQL、PHP这三块砖严丝合缝地砌进Ubuntu 12.04的基座中。你不需要懂所有原理，但必须清楚每一步操作在解决什么具体问题：比如a2enmod rewrite不是为了“启用一个功能”，而是为了让/story/123/title-slug这样的URL能被正确路由到index.php?story=123；mysql_secure_installation也不是走形式，而是直接删除匿名用户、禁用远程root登录、移除test数据库——因为Pligg的安装向导会要求你输入一个有CREATE权限的非root数据库用户，而默认的root账户若允许远程连接，等于把锁孔直接焊死在门上。

如果你正在看这篇文字，大概率是因为：

• 你手头有一台闲置的Ubuntu 12.04 VPS（可能是从老项目迁移下来的，或是图便宜买的长期包年套餐）；
• 你想搭建一个轻量级的UGC聚合站点，不追求WordPress的插件生态，只要核心的投票、分类、用户投稿流程；
• 你试过直接解压Pligg包扔进/var/www，结果打开页面只看到“500 Internal Server Error”或空白页。

那么恭喜，你踩中的不是某个配置错误，而是整个Web服务栈的协同失效。接下来的内容，就是把这根断裂的链条一环一环重新锻打、铆接、淬火的过程。我们不跳过任何看似“多余”的步骤，因为每一个sudo service apache2 restart背后，都藏着Apache主进程是否真正加载了新模块的确认；每一次mysql -u root -p登录，都是在验证MySQL守护进程是否以预期参数启动。这不是教程，这是手术记录。

2. Ubuntu 12.04的底层契约：为什么必须锁定Precise Pangolin的软件源

Ubuntu 12.04 LTS的生命周期虽已结束（官方支持于2017年4月终止），但它在VPS场景下仍有不可替代的价值：内核稳定、内存占用极低、APT源结构清晰。然而，正是这种“稳定”，成了Pligg 2.0.x部署的最大前提。我们来拆解三个关键组件的版本绑定关系：

提示：不要试图通过apt-get install php5.4或add-apt-repository ppa:ondrej/php来升级PHP。Ubuntu 12.04的APT依赖树极其脆弱，强行引入第三方PPA会触发libc6、libssl1.0.0等基础库冲突，最终导致apt-get update命令本身崩溃。我曾因此重装系统三次，直到彻底放弃“升级”思路，转而接受Precise Pangolin的原始契约。

实操中，第一步永远是验证当前系统状态。执行以下命令，逐行比对输出：

# 检查Ubuntu版本（必须为12.04） lsb_release -a | grep "Release" # 检查Apache版本（必须为2.2.22） apache2 -v | head -n1 # 检查PHP版本（必须为5.3.10） php -v | head -n1 # 检查MySQL版本（必须为5.5.54） mysql --version

如果任一输出不符合上表，说明你的VPS镜像已被手动修改过。此时有两个选择：

1. 重置系统：在VPS控制面板中选择“重装系统”，明确指定Ubuntu 12.04 LTS镜像（注意：部分服务商如DigitalOcean已下架该镜像，需联系客服获取）；
2. 降级修复（仅限高级用户）：从http://archive.ubuntu.com/ubuntu/pool/main/手动下载对应deb包，用dpkg -i --force-downgrade强制覆盖。但此操作风险极高，可能破坏APT数据库，故本文后续步骤均基于纯净的Ubuntu 12.04环境展开。

为什么必须如此苛刻？因为Pligg 2.0.x的源码中存在大量硬编码依赖：

• install/index.php第87行直接调用mysql_get_server_info()并检查返回值是否以5.5.开头；
• .htaccess文件第12行使用RewriteCond %{REQUEST_FILENAME} !-f [OR]，而Apache 2.4.x要求改为RewriteCond %{REQUEST_FILENAME} !-f（去掉[OR]）；
• libs/dbconnect.php第45行使用mysql_real_escape_string()，该函数在PHP 5.4+中已被移除。

这些不是Bug，而是Pligg团队在2012年为Precise Pangolin量身定制的技术契约。理解这一点，才能避免陷入“为什么别人能装好，我却不行”的无解循环。

3. Apache 2.2.22的精准手术：从模块启用到虚拟主机隔离

在Ubuntu 12.04中，Apache的配置结构遵循经典的Debian风格：主配置文件/etc/apache2/apache2.conf负责全局设置，站点配置存放在/etc/apache2/sites-available/目录下，通过符号链接激活到/etc/apache2/sites-enabled/。Pligg的部署成败，70%取决于你能否让Apache以最“原生”的方式处理其请求。我们分三步进行精准干预：

3.1 启用必需模块：rewrite、headers、expires

Pligg依赖URL重写生成SEO友好的路径（如/submit/而非/index.php?op=submit），同时需要mod_headers和mod_expires来控制浏览器缓存策略，避免用户看到过期的投票计数。执行以下命令：

sudo a2enmod rewrite headers expires sudo service apache2 restart

注意：a2enmod命令的本质是创建符号链接。例如a2enmod rewrite会在/etc/apache2/mods-enabled/下创建指向/etc/apache2/mods-available/rewrite.load的链接。你可以用ls -l /etc/apache2/mods-enabled/验证链接是否真实存在。若重启后仍报错Invalid command 'RewriteEngine'，说明链接未生效，需手动检查/etc/apache2/mods-available/rewrite.load内容是否为LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so。

3.2 修改主配置：解除AllowOverride限制

默认情况下，Ubuntu 12.04的Apache禁止在.htaccess中覆盖主配置。而Pligg的.htaccess文件包含37条重写规则，是其URL路由的核心。编辑/etc/apache2/apache2.conf，找到以下段落：

<Directory /var/www/> Options Indexes FollowSymLinks AllowOverride None Require all granted </Directory>

将AllowOverride None改为AllowOverride All。这是最关键的一步。修改后保存，执行：

sudo apache2ctl configtest # 验证配置语法 sudo service apache2 reload # 重新加载配置（比restart更轻量）

提示：apache2ctl configtest是Apache的“安全阀”。它不会重启服务，仅检查语法。若输出Syntax OK，说明修改无误；若报错Invalid command 'AllowOverride'，说明你编辑的是错误的配置文件（常见错误：误改/etc/apache2/sites-available/default而非apache2.conf）。

3.3 创建独立虚拟主机：隔离Pligg运行环境

将Pligg直接放在/var/www根目录是新手常见错误。这会导致：

• 与其他站点共享同一PHP配置（如memory_limit）；
• .htaccess规则被其他应用覆盖；
• 安全风险：Pligg的install/目录若未及时删除，可能被恶意扫描。

创建专用虚拟主机：

# 创建网站根目录 sudo mkdir -p /var/www/pligg # 设置权限（Apache用户www-data必须有读写权） sudo chown -R www-data:www-data /var/www/pligg sudo chmod -R 755 /var/www/pligg # 创建虚拟主机配置文件 sudo nano /etc/apache2/sites-available/pligg

在pligg文件中粘贴以下内容（请逐字核对，尤其注意DocumentRoot路径和ServerName）：

<VirtualHost *:80> ServerAdmin webmaster@localhost ServerName pligg.example.com # 替换为你的域名或IP DocumentRoot /var/www/pligg <Directory /var/www/pligg> Options FollowSymLinks AllowOverride All Order allow,deny Allow from all </Directory> ErrorLog ${APACHE_LOG_DIR}/pligg_error.log CustomLog ${APACHE_LOG_DIR}/pligg_access.log combined </VirtualHost>

启用该站点并重启Apache：

sudo a2ensite pligg sudo service apache2 reload

此时，访问http://你的VPS_IP应显示Apache默认页，而访问http://你的VPS_IP/pligg（若DNS未解析）或直接配置/etc/hosts映射ServerName，才能进入Pligg安装流程。这一步的意义在于：你不再是在“修改系统默认行为”，而是在构建一个受控的、可审计的独立容器。

4. MySQL 5.5.54的深度调优：从字符集到查询缓存的全链路适配

Pligg 2.0.x对MySQL的要求远超普通CMS。它不仅需要存储数据，更要支撑高并发的投票计数更新、实时热门文章排序、用户积分瞬时变更。默认的MySQL 5.5.54配置（尤其是my.cnf中的[mysqld]段）在VPS环境下极易成为性能瓶颈。我们不做大而全的优化，只聚焦Pligg实际使用的五个关键参数：

4.1 字符集统一：UTF8MB4的兼容性妥协

Pligg 2.0.x的数据库表定义使用utf8字符集，但MySQL 5.5.54的utf8实际是utf8mb3（最多3字节），不支持emoji等4字节字符。强行升级到utf8mb4会导致Pligg安装向导创建表时失败（因CREATE TABLE语句中指定了CHARSET=utf8）。因此，我们必须保持MySQL默认字符集为utf8，但确保客户端连接使用utf8：

编辑/etc/mysql/my.cnf，在[client]和[mysqld]段分别添加：

[client] default-character-set = utf8 [mysqld] character-set-server = utf8 collation-server = utf8_general_ci

重启MySQL：

sudo service mysql restart

验证是否生效：

mysql -u root -p -e "SHOW VARIABLES LIKE 'character_set%';"

输出中character_set_server和collation_server必须为utf8和utf8_general_ci。

4.2 关键性能参数调优：针对Pligg的读写特征

Pligg的数据库操作具有鲜明特征：

• 读多写少：首页热榜、分类列表、用户个人页均为SELECT密集型；
• 小事务高频：每次投票、收藏、评论都是独立的INSERT/UPDATE；
• 索引依赖强：stories表的date、karma字段，votes表的story_id字段必须有高效索引。

在/etc/mysql/my.cnf的[mysqld]段追加以下配置：

# 缓冲池大小（VPS内存<1GB时设为128M，>1GB设为256M） innodb_buffer_pool_size = 128M # 查询缓存（Pligg大量重复SELECT，开启可提升30%响应速度） query_cache_type = 1 query_cache_size = 32M query_cache_limit = 2M # 连接数（Pligg单次请求可能建立多个连接） max_connections = 100 # 表缓存（Pligg有20+张表，需足够缓存） table_open_cache = 64 # 日志刷盘策略（平衡性能与数据安全） innodb_flush_log_at_trx_commit = 2

注意：innodb_flush_log_at_trx_commit = 2意味着事务提交时仅将日志写入OS缓存而非磁盘，牺牲极小的数据安全性（断电丢失最后1秒事务）换取显著性能提升。对于VPS这类非金融级应用，这是合理取舍。

4.3 创建专用数据库与用户：最小权限原则的实践

Pligg安装向导要求你提供一个有CREATE权限的数据库用户，但绝不应使用root。执行以下SQL（在mysql -u root -p后）：

-- 创建数据库（显式指定字符集） CREATE DATABASE pligg_db CHARACTER SET utf8 COLLATE utf8_general_ci; -- 创建专用用户（密码强度至少8位，含大小写字母+数字） CREATE USER 'pligg_user'@'localhost' IDENTIFIED BY 'YourStrongPass123'; -- 授予最小必要权限 GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON pligg_db.* TO 'pligg_user'@'localhost'; -- 刷新权限 FLUSH PRIVILEGES;

提示：'pligg_user'@'localhost'中的localhost是关键。它表示该用户只能从本机连接MySQL，杜绝了网络嗅探风险。若你在Pligg安装向导中填入127.0.0.1作为主机名，MySQL会将其解析为'pligg_user'@'127.0.0.1'，这是一个不同的用户实体，权限需单独授予。因此，安装时务必填localhost。

5. PHP 5.3.10的精准补丁：扩展加载与安全限制的临界点控制

Ubuntu 12.04的PHP 5.3.10默认安装了php5-mysql、php5-gd、php5-curl等扩展，但Pligg 2.0.x有三项特殊需求，必须手动干预：

5.1 强制启用mysql扩展：绕过Ubuntu的“现代化”陷阱

Ubuntu 12.04的/etc/php5/apache2/php.ini中，extension=mysql.so这一行默认被注释。更隐蔽的是，/etc/php5/conf.d/目录下存在20-mysql.ini文件，其内容为：

; configuration for php mysql module ; priority=20 extension=mysql.so

注意分号;——它使该行失效。必须删除该分号：

sudo sed -i 's/;extension=mysql.so/extension=mysql.so/' /etc/php5/conf.d/20-mysql.ini sudo service apache2 restart

验证是否生效：

php -m | grep mysql

输出必须包含mysql（而非mysqli或pdo_mysql）。因为Pligg 2.0.x的全部数据库操作都基于mysql_*函数族。

5.2 调整PHP运行时限制：匹配Pligg的内存与超时模型

Pligg的submit.php在处理大图上传时，memory_limit需至少64M；install/index.php的数据库导入可能耗时较长，max_execution_time需设为300秒。编辑/etc/php5/apache2/php.ini：

; 内存限制（Pligg图片处理、模板渲染需更多内存） memory_limit = 128M ; 最大执行时间（安装向导导入SQL可能超时） max_execution_time = 300 ; POST数据大小（支持大图上传） post_max_size = 32M ; 文件上传大小 upload_max_filesize = 32M ; 会话有效期（Pligg用户登录态需持久） session.gc_maxlifetime = 14400

提示：upload_max_filesize和post_max_size必须同时调整，且post_max_size应略大于upload_max_filesize（因POST数据包含表单字段）。若只改前者，上传大图时会静默失败。

5.3 禁用危险函数：堵住Pligg代码中的潜在漏洞

Pligg 2.0.x的部分旧版代码（如libs/functions.php）存在exec()、system()等函数调用，若PHP未禁用，可能被恶意利用。在/etc/php5/apache2/php.ini末尾添加：

disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source

重启Apache使配置生效。此举会禁用所有外部命令执行能力，但Pligg核心功能（投票、投稿、评论）完全不依赖这些函数，属于安全加固的零成本操作。

6. Pligg 2.0.x安装向导的实战通关：从文件解压到生产环境封禁

完成前述所有环境配置后，真正的安装才刚刚开始。这里没有“下一步”按钮的魔法，只有对每个环节的精确掌控。

6.1 文件部署：权限与路径的双重校验

下载Pligg 2.0.3（官方最后稳定版）：

cd /tmp wget http://downloads.sourceforge.net/project/pligg/Pligg%20CMS/2.0.3/pligg_2.0.3.zip unzip pligg_2.0.3.zip sudo cp -r pligg_2.0.3/* /var/www/pligg/ sudo chown -R www-data:www-data /var/www/pligg/

关键检查点：

• /var/www/pligg/install/目录必须存在且可读；
• /var/www/pligg/libs/下的config.php必须是空文件（安装向导会自动写入）；
• /var/www/pligg/templates_c/目录必须存在且www-data用户有写权限（用于Smarty模板编译）。

6.2 安装向导全流程：避开三个致命陷阱

访问http://你的域名/install/，按向导步骤操作。重点规避以下陷阱：

陷阱1：数据库主机名填错

• 错误填法：127.0.0.1→ 导致MySQL拒绝连接（因用户权限为'pligg_user'@'localhost'）
• 正确填法：localhost（纯文本，无端口）

陷阱2：表前缀滥用

• 错误做法：填pligg_→ 导致Pligg创建pligg_stories等表，但后续升级脚本可能找不到原表
• 正确做法：留空（使用默认前缀pligg_，但向导内部已固化）

陷阱3：管理员邮箱格式错误

• 错误格式：admin@domain（缺少TLD）
• 正确格式：admin@example.com（必须含@和.）

安装成功后，向导会提示“请立即删除/var/www/pligg/install/目录”。这不是建议，是强制指令：

sudo rm -rf /var/www/pligg/install/

否则，任何人均可通过访问/install/重新初始化数据库，覆盖你的全部数据。

6.3 生产环境封禁：从调试模式到安全加固

安装完成后，Pligg默认处于调试模式，会暴露敏感信息。编辑/var/www/pligg/libs/config.php，找到：

define('DEBUG', true);

改为：

define('DEBUG', false);

同时，禁用Pligg的内置调试工具（位于/var/www/pligg/admin/debug.php）：

sudo mv /var/www/pligg/admin/debug.php /var/www/pligg/admin/debug.php.disabled

最后，设置/var/www/pligg/.htaccess的最终形态（确保RewriteBase /正确）：

RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

至此，Pligg 2.0.x已在Ubuntu 12.04 VPS上完成全链路部署。首页将显示默认的“Welcome to Pligg”热榜，后台地址为http://你的域名/admin/（默认账号admin，密码admin，首次登录后必须修改）。

7. 故障排查的黄金四象限：从500错误到投票失效的归因路径

即使严格遵循上述步骤，生产环境中仍可能出现异常。以下是我在20+台Ubuntu 12.04 VPS上部署Pligg积累的故障归因框架，按发生频率排序：

7.1 500 Internal Server Error：Apache与PHP的协同失效

现象：访问首页或后台显示空白页，Apache错误日志（/var/log/apache2/pligg_error.log）中出现Premature end of script headers或Segmentation fault。

归因路径：

1. 检查/var/log/apache2/error.log是否有PHP Fatal error（如Allowed memory size exhausted）→ 调高memory_limit；
2. 检查/var/log/apache2/pligg_error.log是否有PHP Warning: Module 'mysql' already loaded→ 说明mysql.so被重复加载，检查/etc/php5/conf.d/下是否有多个mysql配置文件；
3. 检查/var/log/apache2/pligg_error.log是否有PHP Parse error→ 说明Pligg文件损坏，重新解压覆盖。

实战案例：某次部署后首页500，日志显示PHP Fatal error: Call to undefined function imagecreatefromjpeg()。原因是php5-gd扩展未启用。执行sudo a2enmod php5-gd并重启Apache即解决。

7.2 投票计数不更新：MySQL事务与缓存的隐性冲突

现象：用户点击“Up Vote”后页面跳转，但故事下方的投票数不变，刷新后仍为旧值。

归因路径：

1. 检查/var/www/pligg/libs/dbconnect.php中数据库连接是否使用mysql_pconnect()（持久连接）→ 改为mysql_connect()；
2. 检查MySQL查询缓存是否命中旧结果 → 在/etc/mysql/my.cnf中临时关闭query_cache_type = 0，重启MySQL测试；
3. 检查/var/www/pligg/templates_c/下是否有损坏的编译模板 → 删除该目录全部内容，让Smarty重新生成。

7.3 后台登录失败：Session与Cookie的跨域失联

现象：输入正确账号密码，页面刷新后仍停留在登录页，无错误提示。

归因路径：

1. 检查/var/www/pligg/libs/config.php中COOKIE_DOMAIN是否设置为'.yourdomain.com'（带前导点）→ 应设为'yourdomain.com'；
2. 检查/etc/php5/apache2/php.ini中session.cookie_httponly是否为On→ 若为Off，可能导致Cookie被JavaScript窃取，但不影响登录；
3. 检查浏览器是否禁用第三方Cookie → 尝试Chrome隐身窗口访问。

7.4 图片上传失败：PHP上传限制与文件系统权限的双重枷锁

现象：投稿时选择图片，点击“Submit”后页面无响应，或提示“File upload failed”。

归因路径：

1. 检查/var/log/apache2/pligg_error.log是否有PHP Warning: POST Content-Length of XXX bytes exceeds the limit→ 调高post_max_size；
2. 检查/var/www/pligg/uploads/目录权限 →sudo chown www-data:www-data /var/www/pligg/uploads/；
3. 检查/var/www/pligg/uploads/目录是否存在 → 若不存在，手动创建并赋权。

最后分享一个小技巧：Pligg 2.0.x的/var/www/pligg/admin/后台有一个隐藏功能——在URL后添加?debug=1（如http://yourdomain.com/admin/?debug=1），可查看当前页面的SQL查询、执行时间、内存占用。这是诊断性能瓶颈的终极武器，但切记上线后删除?debug=1参数，避免泄露敏感信息。

我在实际操作中发现，90%的部署失败源于对Ubuntu 12.04与Pligg 2.0.x这对“老搭档”的敬畏不足。人们总想用新工具（如PHP 7.4、MySQL 8.0）去跑老系统，却忘了技术栈的演进如同生物进化——每个物种都只适应其诞生时的环境。当你亲手敲下sudo service apache2 restart，看着http://your-vps-ip终于显示出Pligg的蓝色首页时，你收获的不仅是可用的网站，更是对Web服务底层逻辑的一次深刻握手。