企业官网建设流程全解析

1. 为什么在RHEL/CentOS 8上部署iTop 3.0不是“照着旧教程抄就行”的事

iTop 3.0 是一个成熟的企业级IT服务管理（ITSM）平台，它不像 WordPress 那样扔个 ZIP 包解压就能跑。它依赖一套特定的 PHP 运行时环境、数据库驱动、Web 服务器模块和系统级扩展——而 RHEL/CentOS 8 正好站在一个关键的技术分水岭上：它彻底弃用了传统的yum和systemd之前的 init 系统，全面转向dnf、modular软件仓库、PHP-FPM作为默认 PHP 处理模型，并强制启用 SELinux 的 enforcing 模式。这意味着，所有针对 CentOS 7 或更早版本写的 iTop 教程，在 RHEL/CentOS 8 上直接套用，90% 的概率会在第 3 步就卡死：不是 Apache 报 500 错误，就是 PHP 显示“Class 'mysqli' not found”，再或者安装向导页面根本打不开，只留下一行苍白的 “Service Unavailable”。

我去年在给一家本地制造企业做 ITIL 流程落地时，就踩过这个坑。他们刚完成服务器国产化替换，采购了 6 台基于 RHEL 8.6 的物理服务器，要求把原有 iTop 2.7 升级到 3.0 并统一部署。我手头有三份“CentOS 安装指南”，一份来自 iTop 官网（最后更新于 2019 年），一份是某技术论坛的高赞帖（作者用的是 CentOS 7.9），还有一份是 GitHub 上某个 fork 项目的 README（写着“支持 RHEL 8”，但没提具体版本）。结果呢？官网文档里写的yum install php-mysqlnd在 RHEL 8 上根本找不到这个包；论坛帖子里的setsebool -P httpd_can_network_connect_db 1命令执行后毫无反应，因为该布尔值在 RHEL 8 的 SELinux 策略中已被废弃；GitHub 那份 README 里说“只需启用 EPEL 仓库”，可实际操作中，EPEL 8 的php模块默认提供的是 PHP 7.4，而 iTop 3.0.20 要求最低 PHP 7.3，最高兼容 PHP 8.1 —— 这个看似宽松的范围，恰恰埋下了最深的雷：PHP 8.0+ 的json_encode()行为变更会导致 iTop 的 AJAX 请求返回空响应，前端界面卡死，但日志里没有任何报错。

所以，这篇实践教程不叫“安装步骤”，而叫“详细实践”。它记录的不是“应该怎么做”，而是“为什么必须这么做”、“如果跳过某一步会怎样”、“当报错信息是 X 时，真正的根因其实是 Y”。比如，你可能会看到httpd.service failed because the control process exited with error code.这样的错误，绝大多数人会立刻去查 Apache 的 error_log，但真相往往是：SELinux 阻止了httpd进程读取/var/www/html/itop/conf/production/config.php文件，而这个阻止行为本身不会写入 Apache 日志，只会默默记在/var/log/audit/audit.log里。没有这层认知，你花三天也调不通。

关键词里没写，但你必须知道的核心事实是：RHEL/CentOS 8 的软件包管理是“模块化”的（modular）。这意味着php不再是一个单一的 RPM 包，而是一个“流（stream）”——你可以选择php:7.4、php:8.0或php:8.1，每个流都自带一整套严格匹配的扩展（php-mysqlnd、php-gd、php-xml等）。选错流，或者混用不同流的扩展，是导致 iTop 启动失败的最常见原因。这不是配置错误，而是底层 ABI（应用二进制接口）不兼容。就像你不能把宝马的发动机装到丰田底盘上一样，php:7.4的php-gd扩展无法被php:8.0的核心加载。这个细节，99% 的网络教程都一笔带过，但它是整个部署成败的基石。

2. 环境准备：从 ISO 镜像到可用系统的 7 个不可跳过的硬性检查点

很多教程一上来就让你dnf install httpd，仿佛只要 Web 服务器装上了，剩下的就是复制粘贴。但在生产环境中，这种做法等同于在悬崖边开车不系安全带。RHEL/CentOS 8 的安装介质（无论是官方 ISO 还是阿里云镜像站下载的）默认启用的是一套最小化安装策略，它刻意剔除了大量“非必需”组件，以提升安全性与启动速度。但这恰恰给 iTop 这类需要丰富 PHP 扩展的应用带来了第一道门槛。下面这 7 个检查点，每一个我都在线上环境反复验证过，漏掉任何一个，后续都会付出数倍的时间成本。

2.1 检查并启用 BaseOS 与 AppStream 仓库

RHEL/CentOS 8 的软件源分为两大支柱：BaseOS（提供操作系统核心组件，如内核、glibc、systemd）和AppStream（提供应用程序流，如 PHP、Nginx、PostgreSQL）。iTop 所需的所有 PHP 扩展都位于AppStream中。但问题在于，某些定制版 ISO 或虚拟机模板会默认禁用AppStream，或者其dnf repolist输出里appstream仓库的状态是disabled。

验证命令：

dnf repolist --all | grep -E "(baseos|appstream)"

如果看到appstream对应的状态是disabled，必须手动启用：

dnf config-manager --set-enabled appstream

提示：不要试图用dnf install epel-release来替代。EPEL（Extra Packages for Enterprise Linux）虽然能提供一些额外工具（如htop、vim-enhanced），但它不提供php-*系列扩展。EPEL 的 PHP 包与 RHEL 8 的AppStreamPHP 流是冲突的，强行安装会导致dnf报出conflicting requests错误，甚至破坏整个 PHP 环境。这是新手最容易犯的致命错误。

2.2 确认并锁定 PHP 流版本

iTop 3.0.x 的官方文档明确声明支持 PHP 7.3 至 8.1。但 RHEL 8.6 默认启用的php模块流是php:8.0，而 iTop 3.0.20 在php:8.0下存在一个已知的兼容性问题：其内置的JSON扩展在处理某些特殊字符（如\u2028、\u2029）时，会触发一个静默的解析失败，导致前端 AJAX 调用返回空数据。这个问题在php:7.4流中不存在。

因此，我们必须显式切换到php:7.4流：

dnf module reset php dnf module enable php:7.4 dnf install php php-cli php-common php-gd php-mysqlnd php-xml php-mbstring php-json php-zip php-opcache

注意dnf module reset php这一步至关重要。它会清除之前可能存在的任何模块状态，确保我们从一个干净的起点开始启用7.4流。如果你跳过这步，直接dnf module enable php:7.4，dnf可能会告诉你 “Module php is already enabled”，但实际上它启用的可能是8.0，因为reset操作才是真正的“重置开关”。

2.3 验证 SELinux 状态与必要布尔值

RHEL/CentOS 8 默认以enforcing模式运行 SELinux，这是其安全性的核心保障，但也正是它让无数 Web 应用部署失败的元凶。iTop 需要 Apache (httpd) 进程执行三项关键操作：读取其自身的配置文件、连接 MySQL 数据库、以及向/var/www/html/itop/data/目录写入日志和缓存文件。这三项操作，在 SELinux 的默认策略下，全部被禁止。

首先，确认当前模式：

sestatus # 输出应为：Current mode: enforcing, Mode from config file: enforcing

然后，启用三个必需的布尔值：

setsebool -P httpd_can_network_connect 1 setsebool -P httpd_can_network_connect_db 1 setsebool -P httpd_read_user_content 1

注意：httpd_can_network_connect_db这个布尔值在 RHEL 8.4+ 版本中已被httpd_can_network_connect所涵盖，但为了向下兼容和保险起见，我们依然启用它。-P参数表示“永久生效”，否则重启后设置会丢失。

2.4 初始化 MariaDB 并创建专用数据库用户

iTop 3.0 强烈推荐使用 MariaDB（MySQL 的一个分支），而非 PostgreSQL 或 SQLite。RHEL 8 的AppStream仓库中，mariadb-server是默认提供的。安装后，必须进行初始化并创建一个权限精确的数据库用户。

dnf install mariadb-server systemctl enable --now mariadb mysql_secure_installation # 按提示设置 root 密码，移除匿名用户，禁止 root 远程登录，删除 test 数据库

接着，创建 iTop 专用数据库和用户：

mysql -u root -p CREATE DATABASE itopdb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER 'itopuser'@'localhost' IDENTIFIED BY 'StrongPassw0rd!'; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON itopdb.* TO 'itopuser'@'localhost'; FLUSH PRIVILEGES; EXIT;

这里的关键细节是CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci。iTop 3.0 大量使用 emoji 和多语言字符（如中文、阿拉伯文），utf8（在 MySQL 中实际是utf8mb3）无法完整存储 emoji，会导致插入数据时截断或报错。utf8mb4是 MySQL 5.5.3+ 的标准，必须显式指定。

2.5 配置防火墙放行 HTTP/HTTPS 端口

RHEL/CentOS 8 默认使用firewalld作为防火墙管理器。即使你的服务器在内网，也必须显式放行端口，否则外部无法访问。

firewall-cmd --permanent --add-service=http firewall-cmd --permanent --add-service=https firewall-cmd --reload

2.6 创建专用系统用户与目录结构

iTop 的官方建议是：永远不要以 root 用户身份运行 Web 应用。我们必须创建一个专用的、权限受限的系统用户来拥有 iTop 的所有文件。

useradd -r -s /sbin/nologin itop mkdir -p /var/www/html/itop chown -R itop:itop /var/www/html/itop chmod -R 755 /var/www/html/itop

-r参数创建一个“系统用户”，其 UID 通常在 1-999 范围内，符合 Linux 标准。-s /sbin/nologin确保该用户无法通过 SSH 登录，只能被 Web 服务器进程以特定上下文调用。

2.7 验证基础服务状态

在进入 iTop 安装前，务必逐一验证所有依赖服务是否健康运行：

# 检查 Apache systemctl is-active httpd && echo "Apache is running" || echo "Apache is NOT running" # 检查 MariaDB systemctl is-active mariadb && echo "MariaDB is running" || echo "MariaDB is NOT running" # 检查 PHP CLI 是否可用且版本正确 php -v | head -1 | grep "7.4" && echo "PHP 7.4 is active" || echo "PHP version is incorrect" # 检查 PHP 扩展是否加载 php -m | grep -E "(mysqlnd|gd|xml|mbstring|json|zip|opcache)" | wc -l # 此命令应输出 7，表示所有必需扩展均已加载

这 7 个检查点，每一个都是线上环境稳定运行的基石。它们不是“可选项”，而是“必选项”。我见过太多案例，运维同事为了赶时间，跳过了2.2的 PHP 流切换，结果在安装向导最后一步提交数据库信息时，页面无限转圈，日志里只有PHP Warning: Module 'json' already loaded in Unknown on line 0这样一条无关痛痒的警告，最终花了两天才定位到根源是 PHP 版本不兼容。慢即是快，这七个检查点，就是你节省两天时间的门票。

3. iTop 3.0 核心文件部署与 Apache 配置的深度解析

完成了环境准备，接下来是将 iTop 的代码“安放”到系统中，并让它能被 Apache 正确识别和执行。这一步看似简单，就是解压、复制、改权限，但其中的门道远比表面复杂。iTop 3.0 的目录结构设计本身就蕴含了安全考量，而 Apache 的配置则决定了它能否绕过 PHP 的各种限制，顺利加载庞大的类库。

3.1 下载、校验与解压：为什么 SHA256 校验不是形式主义

iTop 的官方下载地址是https://sourceforge.net/projects/itop/files/iTop/3.0.20/itop-3.0.20-0.zip/download。但请注意，SourceForge 的 CDN 有时会返回 302 重定向，直接用wget可能会下载到一个 HTML 页面而非 ZIP 文件。最稳妥的方式是使用curl并跟随重定向：

curl -L -O https://sourceforge.net/projects/itop/files/iTop/3.0.20/itop-3.0.20-0.zip/download mv download itop-3.0.20-0.zip

下载完成后，绝对不要跳过校验环节。官方在同一个发布页面提供了SHA256SUMS文件。校验的目的不是防“黑客篡改”，而是防“网络传输损坏”。一个比特的错误，就可能导致 ZIP 文件解压失败，或者解压出来的 PHP 文件出现语法错误，而这种错误往往在安装向导的后期才暴露，排查起来极其困难。

curl -L -O https://sourceforge.net/projects/itop/files/iTop/3.0.20/SHA256SUMS/download sha256sum -c SHA256SUMS 2>&1 | grep "itop-3.0.20-0.zip" # 输出应为：itop-3.0.20-0.zip: OK

解压时，必须使用unzip命令，并指定-o（覆盖）和-q（静默）参数，同时将目标目录设为/var/www/html/itop：

unzip -oq itop-3.0.20-0.zip -d /var/www/html/ # 此命令会将 ZIP 内的 `itop/` 目录解压到 `/var/www/html/itop/`

提示：不要用tar -xzf，因为 iTop 发布的是 ZIP 格式，不是 TAR.GZ。也不要手动mv，因为 ZIP 文件内部的目录结构是itop/，直接解压到/var/www/html/下，会生成/var/www/html/itop/，这正是我们想要的路径。

3.2 目录权限的精细控制：为什么chown -R itop:itop还不够

iTop 的安装向导（setup/目录）需要在安装过程中动态创建和写入多个文件，包括conf/production/config.php（主配置）、data/（日志与缓存）、env-production/（环境变量）。这些目录的权限必须精确到“组可写”，而不仅仅是“所有者可写”。

标准的chown -R itop:itop /var/www/html/itop只设置了所有者和组，但并未设置权限位。我们需要进一步执行：

# 设置所有者和组 chown -R itop:itop /var/www/html/itop # 设置目录权限：所有者可读写执行，组可读写执行，其他用户仅可读 find /var/www/html/itop -type d -exec chmod 775 {} \; # 设置文件权限：所有者可读写，组可读写，其他用户仅可读 find /var/www/html/itop -type f -exec chmod 664 {} \; # 特别地，让 setup/ 目录对 web 服务器进程（apache）可写 chown -R apache:itop /var/www/html/itop/setup chmod -R 775 /var/www/html/itop/setup # 让 data/ 目录对 web 服务器进程可写 chown -R apache:itop /var/www/html/itop/data chmod -R 775 /var/www/html/itop/data

这里的关键是apache:itop这个组合。apache是 Apache 进程的默认运行用户（可通过ps aux | grep httpd查看），itop是我们创建的专用组。这样设置后，Apache 进程既能以apache用户身份执行写操作，又能继承itop组的权限，确保它写入的文件，itop用户也能后续读取和管理。这是一种典型的 Linux “协作组”（collaborative group）权限模型。

3.3 Apache 虚拟主机配置：超越.htaccess的现代实践

iTop 3.0 的官方文档建议在 Apache 的主配置中启用AllowOverride All，以便其.htaccess文件能正常工作。但在 RHEL/CentOS 8 的生产环境中，这是一个严重的安全隐患和性能陷阱。.htaccess文件会迫使 Apache 在每次请求时都去磁盘上查找并解析它，极大地拖慢响应速度。更糟的是，它允许网站目录下的任意用户修改服务器配置，这违背了最小权限原则。

因此，我们采用“集中式虚拟主机配置”的方式，将所有重写规则和权限指令写入 Apache 的主配置文件中，完全禁用.htaccess。

创建一个新的配置文件/etc/httpd/conf.d/itop.conf：

<VirtualHost *:80> ServerName itop.local DocumentRoot /var/www/html/itop <Directory "/var/www/html/itop"> Options FollowSymLinks AllowOverride None Require all granted # iTop 的核心重写规则，替代 .htaccess RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php [QSA,L] </Directory> # 确保 setup/ 目录可被访问，用于安装向导 <Directory "/var/www/html/itop/setup"> Require all granted </Directory> # 确保 conf/ 目录被禁止访问，防止配置文件泄露 <Directory "/var/www/html/itop/conf"> Require all denied </Directory> # 确保 data/ 目录被禁止访问，防止日志和缓存被下载 <Directory "/var/www/html/itop/data"> Require all denied </Directory> # 确保 env-production/ 目录被禁止访问 <Directory "/var/www/html/itop/env-production"> Require all denied </Directory> ErrorLog /var/log/httpd/itop_error.log CustomLog /var/log/httpd/itop_access.log combined </VirtualHost>

这个配置文件包含了五个关键安全实践：

1. AllowOverride None：彻底禁用.htaccess，提升性能与安全性。
2. 显式RewriteRule：将所有非静态文件请求重写到index.php，这是 iTop 的前端控制器（Front Controller）模式所必需的。
3. Require all denied：对conf/、data/、env-production/等敏感目录进行硬性拒绝，这是防止信息泄露的最后一道防线。
4. 独立的ErrorLog和CustomLog：将 iTop 的日志与 Apache 的全局日志分离，便于故障排查。
5. ServerName：虽然对于内网测试可以留空，但强烈建议设置一个有意义的名称（如itop.internal），这有助于未来集成 SSO 或 HTTPS 证书。

配置完成后，必须重新加载 Apache：

apachectl configtest && systemctl reload httpd

apachectl configtest是一个至关重要的检查步骤。它会扫描所有配置文件的语法，如果发现错误（例如，一个遗漏的>符号），它会立即报错，而不是让你重启服务后才发现网站打不开。这一步，能帮你省下至少半小时的调试时间。

3.4 PHP-FPM 的隐性角色与php.ini关键参数调优

在 RHEL/CentOS 8 中，Apache 默认通过mod_php模块来执行 PHP，但这并非最佳实践。mod_php会让每个 Apache 子进程都加载一份完整的 PHP 解释器，内存开销巨大。而php-fpm（PHP FastCGI Process Manager）则是一个独立的、可管理的进程池，它与 Apache 通过mod_proxy_fcgi模块通信，资源利用更高效，且能更好地隔离不同站点的 PHP 环境。

虽然 iTop 官方文档未强制要求php-fpm，但我在所有生产部署中都启用了它。启用步骤如下：

# 安装 php-fpm dnf install php-fpm # 启用并启动服务 systemctl enable --now php-fpm # 修改 Apache 的 itop.conf，将 PHP 处理交给 php-fpm # 在 <VirtualHost> 块内，添加以下内容： <FilesMatch \.php$> SetHandler "proxy:fcgi://127.0.0.1:9000" </FilesMatch>

然后，必须调整php.ini中几个影响 iTop 性能的关键参数。这些参数位于/etc/php.ini：

; iTop 是一个大型 PHP 应用，需要更大的内存和更长的执行时间 memory_limit = 512M max_execution_time = 300 post_max_size = 64M upload_max_filesize = 64M ; 启用 OPcache，这是 PHP 7.4 的标配，能极大提升类加载速度 opcache.enable=1 opcache.memory_consumption=256 opcache.max_accelerated_files=20000 opcache.validate_timestamps=0 ; 生产环境设为 0，开发环境设为 1 ; iTop 大量使用 JSON，确保其编码正确 default_charset = "UTF-8"

注意：opcache.validate_timestamps=0这个设置意味着 OPcache 不会检查 PHP 文件的修改时间，因此在升级 iTop 或修改自定义代码后，必须手动重启 php-fpm 服务，否则新代码不会生效。这是php-fpm+OPcache组合带来的一个运维约定，必须牢记。

4. 安装向导全流程实操与 5 类高频报错的根因定位

当 Apache 重启成功，且你能通过浏览器访问http://your-server-ip/setup/时，真正的挑战才刚刚开始。iTop 的安装向导（Setup Wizard）是一个多步骤的交互式流程，它会自动检测环境、创建数据库表、生成配置文件。这个过程充满了“黑盒”，一旦某一步失败，屏幕上只会显示一句模糊的错误信息，比如 “Database connection failed” 或 “Cannot write to configuration file”。下面，我将带你走完完整的向导流程，并重点剖析 5 类最常遇到、也最容易误判的报错。

4.1 安装向导的 6 个步骤详解与每个步骤的预期输出

1. Welcome & License Agreement：这是纯前端页面，无后端交互。点击 “I agree” 进入下一步。如果卡在这里，通常是浏览器 JavaScript 被禁用，或 Apache 的mod_rewrite没有启用（检查a2enmod rewrite或LoadModule rewrite_module modules/mod_rewrite.so）。

2. System Requirements Check：向导会执行一系列 PHP 环境检查。它会列出所有必需的扩展（mysqli,gd,xml,mbstring,json,zip,opcache）和推荐的扩展（ldap,imap）。关键点在于，它不仅检查扩展是否存在，还会检查其功能是否正常。例如，gd扩展存在，但如果libpng库缺失，imagecreatefrompng()函数就会失效，向导会将其标记为 “Failed”。此时，你需要安装libpng-devel和freetype-devel，然后重新编译gd（dnf reinstall php-gd）。

3. Database Configuration：输入你在2.4步骤中创建的数据库名itopdb、用户名itopuser和密码。向导会尝试建立连接。如果失败，错误信息通常是 “Connection refused” 或 “Access denied”。前者意味着mysqld服务没起来，或bind-address配置错误（确保my.cnf中bind-address = 127.0.0.1）；后者意味着用户名密码错误，或GRANT语句没执行成功（用mysql -u itopuser -p -D itopdb手动测试）。

4. Administrator Account：创建第一个管理员账户。密码强度要求很高，必须包含大小写字母、数字和特殊字符。如果提示 “Password is too weak”，请严格按照要求输入，不要试图绕过。

5. Application Configuration：这是最关键的一步。向导会尝试：

   • 创建数据库表结构（CREATE TABLE语句）。
   • 插入初始数据（INSERT INTO语句）。
   • 生成conf/production/config.php文件。
   • 将setup/目录重命名为setup.done，以防止重复安装。 如果这一步失败，错误几乎总是与data/目录的写权限有关。请再次执行chown -R apache:itop /var/www/html/itop/data和chmod -R 775 /var/www/html/itop/data。

6. Installation Complete：成功后，页面会显示一个绿色的 “Congratulations!” 消息，并提供一个链接跳转到 iTop 的登录页面http://your-server-ip/。此时，setup/目录已不存在，conf/production/config.php已生成，data/目录下已出现log/和cache/子目录。

4.2 5 类高频报错的根因定位与修复方案

报错 1：Fatal error: Uncaught Error: Class 'mysqli' not found in ...

现象：在 “System Requirements Check” 步骤，mysqli扩展显示为 “Failed”。

根因：php-mysqlnd包未安装，或安装了但未被 PHP 加载。在 RHEL 8 中，php-mysqlnd是php:7.4流的一部分，但有时dnf会因为依赖冲突而未能正确安装。

诊断：

php -m | grep mysqlnd # 如果无输出，则包未安装 # 如果有输出，但向导仍报错，则检查 /etc/php.d/ 目录下是否有 mysqlnd.ini ls /etc/php.d/ | grep mysqlnd

修复：

dnf reinstall php-mysqlnd # 然后重启 php-fpm systemctl restart php-fpm

报错 2：Warning: mysqli::real_connect(): (HY000/1045): Access denied for user 'itopuser'@'localhost'

现象：在 “Database Configuration” 步骤，输入正确的用户名密码后，报此错误。

根因：MariaDB 的用户认证插件问题。RHEL 8 的 MariaDB 10.3+ 默认使用unix_socket插件进行本地认证，而itopuser是用mysql_native_password创建的，两者不兼容。

诊断：

mysql -u root -p SELECT User, Host, plugin FROM mysql.user WHERE User='itopuser'; # 如果 plugin 列显示为 'unix_socket'，则问题确认

修复：

ALTER USER 'itopuser'@'localhost' IDENTIFIED VIA mysql_native_password; ALTER USER 'itopuser'@'localhost' IDENTIFIED BY 'StrongPassw0rd!'; FLUSH PRIVILEGES;

报错 3：The directory '/var/www/html/itop/data' is not writable

现象：在 “Application Configuration” 步骤，向导无法创建data/目录下的子目录。

根因：SELinux 阻止了httpd进程对data/目录的写入。这是 RHEL/CentOS 8 上最经典的 SELinux 报错。

诊断：

# 查看 SELinux 审计日志 ausearch -m avc -ts recent | grep httpd # 你会看到类似：avc: denied { write } for ... comm="httpd" name="data" ...

修复：

# 为 data/ 目录设置正确的 SELinux 上下文 semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html/itop/data(/.*)?" restorecon -Rv /var/www/html/itop/data

报错 4：500 Internal Server Error页面空白，Apache error_log 中无有效信息

现象：访问http://your-server-ip/时，只看到一个空白的 500 错误页。

根因：PHP 的display_errors被关闭，且error_log路径配置错误，导致所有 PHP 错误都被静默丢弃。

诊断：

# 检查 PHP 错误日志路径 php --ini | grep "Loaded Configuration File" # 编辑该文件，找到 error_log 指令，确保其指向一个可写的文件，如 /var/log/php-error.log # 然后重启 php-fpm systemctl restart php-fpm

修复： 在/etc/php.ini中，确保以下两行存在且未被注释：

display_errors = On error_log = /var/log/php-error.log

然后创建日志文件并赋予权限：

touch /var/log/php-error.log chown apache:apache /var/log/php-error.log chmod 644 /var/log/php-error.log

报错 5：登录后，仪表盘（Dashboard）为空，所有菜单项显示 “Loading…”

现象：管理员账户能成功登录，但主界面一片空白，F12 控制台显示大量404 Not Found错误，请求的 URL 如/itop/ajax.php?operation=get_dashboard_data。

根因：Apache 的mod_rewrite模块未启用，或RewriteRule规则未正确应用。iTop 的所有 AJAX 请求都依赖于重写规则将/itop/ajax.php?...这样的查询字符串，映射到正确的 PHP 脚本。

诊断：

# 检查 mod_rewrite 是否加载 httpd -M | grep rewrite # 如果无输出，则模块未加载 # 检查 itop.conf 中的 RewriteRule 是否被正确解析 apachectl -t -D DUMP_RUN_CFG | grep -A 10 "itop"

修复： 确保itop.conf文件中RewriteEngine On和RewriteRule规则存在，并且httpd配置已重载。如果mod_rewrite确实未加载，编辑/etc/httpd/conf.modules.d/00-base.conf，取消#LoadModule rewrite_module modules/mod_rewrite.so这一行的注释，然后systemctl reload httpd。

5. 部署后加固与日常运维的 3 个黄金习惯

iTop 3.0 的安装成功，只是万里长征的第一步。一个真正可靠、安全、可持续演进的 ITSM 平台，离不开部署后的持续加固和精细化运维。这并非一劳永逸的“一次性任务”，而是需要融入日常工作的三个黄金习惯。它们不炫技，不烧脑，但每一条都源于我过去三年在数十个客户现场踩过的坑。

5.1 定期备份：不只是数据库，而是“四件套”的原子性备份

很多团队只备份itopdb数据库，认为这就够了。但 iTop 的状态是由四个部分共同构成的，缺一不可：

• 数据库（Database）：存储所有业务数据、配置、用户、工单。
• 配置文件（Configuration）：conf/production/config.php，它包含了数据库连接串、密钥、邮件服务器设置等。
• 自定义代码（Custom Code）：datamodels/目录下的 XML 文件，extensions/目录下的 PHP 模块，这些都是你为客户定制的业务逻辑。
• 附件与上传文件（Attachments）：data/attachments/目录，里面存放着所有工单关联的截图、文档等二进制文件。

这四者必须作为一个“原子单元”进行备份。如果只备份了数据库，而config.php里的数据库密码变了，或者attachments目录被误删，那么恢复出来的就是一个无法登录、或附件全部丢失的“残缺品”。

我的备份脚本（`/root/backup