★ FEATURED ARTICLE 接手一个跑了十来年的行业站打开服务器一看根目录里躺着 DedeCMS 5.6PHP 还是 5.3数据库里几十万条文档附件目录按年月分了上百个文件夹后台入口还叫/dede/。这种场面在中小型内容站里并不罕见。客户要求很简单换台新服务器域名顺便从 http 换成 https站点不能停太久链接最好一条都别变。听起来是装个程序、导个库、改个域名三件事真动起手来DedeCMS 5.6 的安装与迁移里埋的坑远比想象的多——字符集、严格模式、伪静态、附件路径、缓存机制每一项都能让你在凌晨两点对着白屏发呆。这篇内容就是把这套流程从头到尾拆开讲DedeCMS 5.6 的安装该在什么环境里做、每一步到底在做什么、装完之后必须补哪几刀迁移的时候数据库、站点文件、系统参数三条线怎么同时对齐切过去之后哪些地方最容易翻车、又该怎么一步步排查。适合手上正维护着老站点、或者需要把老站点搬到新环境的人看也适合想了解早期 PHP CMS 架构的人当一份实践笔记。我会尽量把为什么这么做讲清楚因为老系统的很多设计在今天看来反直觉不理解原理只会照抄步骤出问题时寸步难行。1. 还在跑DedeCMS 5.6的站点究竟是什么处境1.1 5.6这个版本号背后的技术坐标DedeCMS 5.6 是这套系统生命周期里装机量极大的一个分支它的代码骨架定型很早核心特征就是模板标签 数据库驱动 大量可生成静态页。它不是一个现代意义上的框架没有 composer没有命名空间没有 PSR 规范全局函数满街跑include/common.inc.php一引入就把半个系统拉起来了。理解这一点很关键你在后面遇到的绝大多数怪异行为本质上都是这套早期架构的副作用而不是配置写错了。从使用角度看5.6 的优势是成熟栏目模型、文档模型、自定义字段、专题、采集、会员、广告位这些功能在那个年代已经做得很完整后台操作路径也相对清晰。它的劣势同样明显代码里保留了大量 PHP 5 时代的写法对高版本 PHP 的兼容性很差安全模型基本靠目录改名 后台权限放到今天必须自己加一层外部防护。所以先摆正心态这不是一次部署新系统而是一次给老系统续命。目标不是把它变得更先进而是在改动最小、风险最低的前提下让它在可维护的环境里继续跑。想清楚这一点后面所有选型都会变得保守而合理。1.2 环境矩阵PHP、MySQL、扩展三件套环境选择是整件事的地基选错了后面全是补丁。我一般会按够用且不冒进的原则来定实测下来最稳的组合是 PHP 5.6 MySQL 5.6/5.7 Apache 或 Nginx。PHP 5.6 是这套代码能舒服跑起来的上限附近再往上走就会开始撞函数移除的问题。组件推荐版本说明PHP5.6.x兼容性最好绝大多数老插件无需改动MySQL5.6 / 5.75.7 需调整sql_mode否则插入报错Web 服务器Nginx 1.16 或 Apache 2.4静态化站点用 Nginx 性能更好必装扩展mysqli、gd、mbstring、curl、json、zlibgd 缺失会直接导致验证码、缩略图异常如果你手上只有 PHP 7.x 的环境也不是完全不能跑但要提前做好心理准备mysql_*系列函数、each()、create_function()、动态属性这些在老代码里到处都是PHP 7.0 到 7.2 之间大概率能跑但会冒警告7.4 往上很可能直接白屏。真要在高版本 PHP 上跑通常得打一批兼容补丁这是一笔额外成本得提前和需求方说清楚。MySQL 5.7 这里单独提一句因为它是最容易让人栽跟头的地方。5.7 默认sql_mode里带了STRICT_TRANS_TABLES和ONLY_FULL_GROUP_BY而 DedeCMS 5.6 里存在大量字段没给值就插入GROUP BY 字段不全的写法在严格模式下会直接报Field xxx doesnt have a default value或者this is incompatible with sql_modeonly_full_group_by。解决办法有两个要么装 MySQL 5.6要么在my.cnf里放宽[mysqld] sql_mode NO_ENGINE_SUBSTITUTION改完重启数据库用SELECT sql_mode;确认生效。这一步不做你在安装向导最后一步就可能卡住。1.3 源码目录结构速览与关键文件定位拿到压缩包解压之后别急着往服务器上传先在本地把目录结构过一遍。DedeCMS 5.6 的目录职责划分很清楚认下来之后排查问题会快很多。install/安装向导装完必须删掉这是老系统最常见的安全隐患。dede/后台入口目录几乎所有站点都会改名这是必须做的第一件事。data/缓存、配置、会话、模板编译结果必须可写也是最容易出权限问题的地方。data/common.inc.php数据库连接配置迁移时改的就是它。include/核心函数库和公共文件一般不动。templets/模板目录默认模板叫default。uploads/附件和图片按allimg/年月日分子目录存放。plus/独立功能页比如列表页、内容页的动态入口、搜索、评论。html/或自定义目录生成出来的静态文件视站点配置而定。有个细节很多人没注意data/目录下还有cache、config、sessions、tplcache这些子目录它们在运行时会被频繁读写。如果从压缩包直接上传到服务器目录权限往往是压缩包里的原始权限不是 Web 用户可写的这就是后面后台登录白屏验证码不显示的高发原因。2. 全新安装把返工点提前消灭在向导之前2.1 编码选择要在一开始就定死DedeCMS 5.6 历史上发布过 GBK 和 UTF-8 两套包这是两套独立的代码不是简单地换了个字符集。安装包选错后面全是连锁反应模板里中文乱码、数据库导出导入出错、编辑器保存内容变成问号。判断该选哪个原则很简单老站从 GBK 迁过来的如果能一次性转成 UTF-8就转如果历史数据里混了大量 GBK 二进制内容、转码风险高就老实继续用 GBK 包。不要想着两套包混着用那是自找麻烦。转码这件事本身可行但要有完整备份并且能接受验证成本。我的做法是先把数据库用 GBK 导出然后转成 UTF-8再导入新库# 以 GBK 字符集导出 mysqldump -uroot -p --default-character-setgbk dedecms backup_gbk.sql # 转成 UTF-8 iconv -f GBK -t UTF-8 backup_gbk.sql -o backup_utf8.sql # 把文件里的 SET NAMES 声明也改掉否则导入时又按 GBK 解析 sed -i s/SET NAMES gbk/SET NAMES utf8/g backup_utf8.sql转完之后务必抽查随机打开几十篇文档看标题、正文、来源、tags 有没有乱码或截断。中文长标题被截断是很常见的问题因为 GBK 一个汉字占两个字节UTF-8 占三个原来按字节数截断的逻辑会切在字符中间。这个坑我踩过标题后半段变成乱码改起来只能批量修数据非常难受。2.2 上传、解压与目录权限的具体操作上传我一般用scp或者直接在服务器上wget再解压避免本地 FTP 传几万个小文件。解压之后的权限设置是最容易被跳过、又最容易出问题的一步。# 假设站点根目录为 /www/wwwroot/site cd /www/wwwroot tar -zxvf dedecms56.tar.gz -C site # 统一属主为 Web 运行用户Nginx 常见是 www 或 nginxApache 是 apache 或 www-data chown -R www:www /www/wwwroot/site # 目录 755文件 644先把基线打正 find /www/wwwroot/site -type d -exec chmod 755 {} \; find /www/wwwroot/site -type f -exec chmod 644 {} \; # 单独放开必须可写的目录 chmod -R 775 /www/wwwroot/site/data chmod -R 775 /www/wwwroot/site/uploads chmod -R 775 /www/wwwroot/site/html这里有个经验网上很多教程直接教chmod -R 777图省事。在单机、内网测试环境下无所谓但在公网服务器上777 意味着任何被上传的脚本都能被写入并执行配合老系统的上传漏洞这是灾难性的。能接受的最低限度是用正确的属主加 775实在搞不定再退到 777但事后一定要回头收紧。然后是 PHP 的几项基础配置建议写在站点的php.ini或user.ini里date.timezone Asia/Shanghai memory_limit 128M upload_max_filesize 32M post_max_size 32M max_execution_time 120date.timezone不设会有警告且文章发布时间会差 8 小时这在迁移后非常容易被误判成数据出问题了。max_execution_time调大是为了后面批量生成 HTML 时不至于中途断掉。2.3 安装向导逐屏解读与数据库参数填写环境就绪后浏览器访问http://你的地址/install/index.php会出现安装向导。前几屏是协议和目录权限检测重点看第二步的权限检查列表data相关目录必须全部显示可写有红的就回头处理权限不要硬着头皮往下走。数据库填写这一屏注意几个细节数据库地址同机一般填localhost或127.0.0.1。填localhost时 MySQL 走 socket速度更快但前提是 socket 路径一致填127.0.0.1走 TCP稳妥一些。数据库名/用户/密码建议单独建库单独建用户只授予这个库的权限不要图省事用 root。老系统被拖库的风险不低权限收窄是最后一道保险。表前缀默认dede_。如果你要在一个库里放多个站点或者想让表名不那么好猜可以改。但要注意迁移已有站点时不要改前缀改了之后系统参数表、缓存、模板里的硬编码全部要跟着改风险远大于收益。管理员账号不要用admin不要用常见弱密码。这一条不是形式主义老系统的后台是被扫描的重点目标。安装完成后程序会提示你删除install目录。这件事的重要性怎么强调都不过分——没删的install目录可以被重新走一遍安装流程直接接管你的站点。我见过不止一个站点因为这个问题被塞了一堆垃圾内容。2.4 安装完成后的六件事装完能进后台只是个开始。下面这几件事我每次都会做完缺一件后面都可能出状况删除install/目录并顺手删除根目录下不需要的示例文件、测试文件。重命名后台目录dede改成manage_加一段随机字符串之类。改完登录地址随之变化记得更新自己的书签。修改管理员用户名和密码把安装时填的临时账号换掉。关闭调试与错误显示php.ini里display_errors Off避免报错信息暴露物理路径。设置伪静态规则如果站点打算用伪静态现在就把规则配好别等上线再补。做一次全站备份把data/common.inc.php和数据库导出各存一份到本地作为干净基线。第 2 条有个副作用需要提醒改后台目录名之后某些老模板或者插件里可能硬编码了/dede/这个路径比如后台编辑器里插入图片用的相对地址、某些 JS 请求。改完名要去后台各功能页点一遍特别是编辑器、附件管理、图片水印设置这几处看看有没有 404。这个问题很隐蔽往往在编辑文章插入图片时才暴露。3. 站点搬家数据库、文件、配置三条线同时对齐3.1 迁移前的备份清单与版本摸底迁移的第一原则是在动手之前先确认老站能完整还原。没有这个前提任何操作都是在赌。我一般会先摸一遍底老服务器的 PHP 版本、MySQL 版本、站点根目录、数据库名、表前缀、附件存放目录、有没有开启静态化、伪静态规则写在哪儿、有没有在plus/或根目录放过自定义的 PHP 脚本。这些东西都在脑子里过一遍后面才不容易漏。备份清单我会按这个来备份对象方式备注数据库mysqldump全量导出带触发器、存储过程字符集要对站点文件tar打包整个根目录排除缓存和日志减少体积附件目录单独确认如果不在站点根目录要单独找配置文件单独拷data/common.inc.php出问题时能对账Web 服务器配置拷 vhost、伪静态规则换服务器时最容易忘导出命令建议这样写mysqldump -uroot -p \ --default-character-setutf8 \ --single-transaction \ --triggers --routines \ --databases dedecms /backup/dedecms_full.sql--single-transaction对 InnoDB 表能在不锁表的情况下拿到一致快照站点还在运行也能导。如果老表是 MyISAM这个参数不起作用得挑访问低峰期做或者干脆先停一下 Web 服务。打包文件时别把data/cache、data/tplcache、data/sessions里的东西全带上那些是会重新生成的带过去只会让包变大、还可能在切换后引起缓存错乱tar -zcvf /backup/site.tar.gz \ --excludesite/data/cache/* \ --excludesite/data/tplcache/* \ --excludesite/data/sessions/* \ -C /www/wwwroot site3.2 数据库导出导入中的字符集与严格模式数据库这一环是迁移里最容易出问题的部分核心就两件事字符集要一致严格模式要放宽。字符集方面原则是导出用什么、建库用什么、导入用什么三者必须一致。原库是utf8注意不是utf8mb4新库就建utf8原库是gbk新库就建gbk。跨字符集导入是最常见的乱码来源。建库语句建议显式指定字符集CREATE DATABASE dedecms DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; CREATE USER dede_user127.0.0.1 IDENTIFIED BY 一段足够长的随机密码; GRANT ALL PRIVILEGES ON dedecms.* TO dede_user127.0.0.1; FLUSH PRIVILEGES;导入的时候也要带上字符集参数否则 MySQL 客户端可能按默认字符集解析中文全变成问号mysql -uroot -p --default-character-setutf8 dedecms /backup/dedecms_full.sql导入完成后立刻抽查不要等站点上线才发现SELECT id, title FROM dede_archives ORDER BY id DESC LIMIT 5; SELECT COUNT(*) FROM dede_archives; SELECT COUNT(*) FROM dede_addonarticle;看标题是否正常显示中文看文档总数是否和老站一致。如果dede_archives有数据但dede_addonarticle明显少一截说明导入中途出错了看错误日志通常是被严格模式卡住了某个字段。严格模式的问题在 MySQL 5.7 上几乎是必踩的。表现是导入过程中报一堆Incorrect integer value或者doesnt have a default value然后数据缺了一部分。这时候先放宽sql_mode再重新导入一次干净库比逐条修 SQL 效率高得多。还有一种情况是老站表引擎是 MyISAM新库默认 InnoDB。直接导进去功能上不会有问题但要注意全文检索DedeCMS 的搜索功能在某些配置下依赖 MyISAM 的全文索引切到 InnoDB 之后搜索结果可能变少。这个细节很少被提及实测时如果发现搜索数量对不上可以查一下相关表的引擎。3.3 common.inc.php 与后台系统参数的改动点数据库导完、文件传完接下来是配置文件对齐。这一步是两个地方要改很多人只改了前一个结果站点能打开但功能各种不对劲。第一个是data/common.inc.php数据库连接信息?php $cfg_dbhost 127.0.0.1; $cfg_dbpwd 一段足够长的随机密码; $cfg_dbname dedecms; $cfg_dbuser dede_user; $cfg_dbprefix dede_; $cfg_db_language utf8; ?不同小版本的字段名和数量会略有差异以你手上这份文件为准只改值不要改键名。改完之后访问首页能正常打开说明连接通了如果报数据库错误先看用户名密码再看是不是localhost和127.0.0.1的 socket 差异。第二个是后台的系统基本参数。这部分的配置存在数据库里不在文件里所以只改配置文件是没用的。登录后台逐项检查站点根网址换成新域名注意带不带www、是不是https。网页主页链接、CMS 安装目录如果站点从子目录搬到了根目录cfg_cmspath必须清空或改成/否则生成的链接会多一层目录。附件目录、附件 URL 地址如果附件走了独立域名或 CDN这里要同步改。模板目录、默认模板确认目录名和实际文件一致。是否使用伪静态和你的 Web 服务器规则配套。如果不想在后台逐项点也可以直接改数据库改完记得刷新缓存UPDATE dede_sysconfig SET value https://www.example.com WHERE name cfg_basehost; UPDATE dede_sysconfig SET value WHERE name cfg_cmspath; UPDATE dede_sysconfig SET value /uploads WHERE name cfg_upload_dir;注意直接改库之后必须去后台系统 - 更新缓存或者手动删除data/cache下的缓存文件否则前台读的还是旧值你会以为改动没生效。还有一类改动容易被忽略正文里的绝对链接。老站用 http正文里插的图片如果存的是http://old.example.com/uploads/...换域名后这些图片不会自动跟着变。这种情况需要批量替换UPDATE dede_addonarticle SET body REPLACE(body, http://old.example.com, https://new.example.com); UPDATE dede_archives SET litpic REPLACE(litpic, http://old.example.com, https://new.example.com);执行前务必先备份这两张表替换是不可逆的。替换完清缓存、重新生成静态页。3.4 附件、模板与自定义目录的对齐附件是最容易看起来搬完了其实没搬全的部分。DedeCMS 的附件默认在uploads/allimg/下按年月日分目录一个跑了十年的站可能有几万个文件、上百个目录。用rsync增量同步比scp整个覆盖更靠谱也方便断点续传rsync -avz --progress /www/wwwroot/site/uploads/ root新服务器:/www/wwwroot/site/uploads/ rsync -avz --progress /www/wwwroot/site/templets/ root新服务器:/www/wwwroot/site/templets/同步完核对文件数量这是最朴素也最有效的验证方式find /www/wwwroot/site/uploads -type f | wc -l两边数字对得上基本就没漏。对不上就再跑一次rsync它会补差异。模板目录要额外注意如果站点用过自定义模板模板里可能有硬编码的域名、路径、甚至是某个子目录的名字。换域名之后模板里写死的http://old.example.com会让一部分资源加载失败。建议全局搜一遍grep -rn old.example.com /www/wwwroot/site/templets/ grep -rn old.example.com /www/wwwroot/site/plus/除了模板还有几个地方值得搜一下根目录的自定义 PHP 脚本、special专题目录、images静态资源目录里的 CSS有些 CSS 里写了url()绝对路径。这类问题不会导致站点打不开但会让页面样式缺一块很折磨人。3.5 切换后的逐项验收域名解析切过去之后不要急着宣布完成。按下面的顺序逐项过一遍能提前发现 80% 的问题首页能否打开样式是否完整图片是否全部加载。随机点开 5 个栏目页看分页是否正常第二页、最后一页都要点。随机打开 10 篇不同年份的文档看正文、图片、附件下载、相关推荐。搜索功能随便搜一个词看结果数量和分页。后台登录进各功能菜单点一遍特别是更新缓存生成 HTML。会员中心、评论、留言板这些交互功能如果站点开了的话。提交一次测试内容看编辑器、缩略图、自动生成静态页是否正常。如果站点是纯静态化的切换后必须重新生成一遍 HTML。后台路径是生成 - 更新主页 HTML / 更新栏目 HTML / 更新文档 HTML。数据量大的话分批做按栏目逐个生成别一次性全站生成max_execution_time撑不住中途断了还得重来。4. 迁移后最容易翻车的几类故障与排查路径4.1 后台能打开但登录白屏、验证码空白这是迁移后最高频的问题症状是后台登录页能出来但验证码是个空白框或者输入账号密码点登录后变成一片白。排查顺序我一般这样走。第一步看验证码因为验证码依赖 GD 库和会话写入。先确认 PHP 装了 gd 扩展php -m | grep -i gd没装就装上再重启 PHP-FPM。装了还是空白就看data/sessions目录权限会话文件写不进去验证码自然出不来。这个目录经常因为是新建的、属主不对而不可写。第二步看白屏。白屏通常意味着 PHP 致命错误被display_errors Off藏起来了。临时打开错误显示或者去 PHP 错误日志里找tail -n 100 /var/log/php-fpm/error.log换服务器之后白屏的常见原因是 PHP 版本不一致。老服务器 PHP 5.3新服务器 PHP 7.x代码里用了被移除的函数一个致命错误直接白屏。这种情况要么把 PHP 降回 5.6要么逐个函数打补丁前者成本低得多。第三步看会话配置。有些老站在php.ini里配了session.save_path换服务器后这个路径不存在PHP 写会话失败但不一定报错。检查一下php -i | grep session.save_path路径不存在就建出来并给写权限。4.2 中文乱码与标题截断乱码分两种一种是打开就全是问号或方块一种是部分内容乱码。整站乱码基本可以断定是数据库字符集不匹配。检查三处是否一致数据库本身字符集、表字符集、页面 HTML 的charset声明。用 SQL 查一下SHOW VARIABLES LIKE character_set_database; SHOW CREATE TABLE dede_archives;如果原库是 gbk新库建成了 utf8再导入 utf8 数据双重转换之下内容必然坏掉。这种情况只能重新导按原库字符集建库用原字符集导入确认数据正常后再决定要不要整体转码。部分内容乱码通常是转码过程中被截断的产物。比如原来的 GBK 数据转 UTF-8 时某个字段长度不够汉字被切了一半剩下半个字节就是乱码。这种只能逐条找出来修没法批量解决。所以我在第 2.1 节里强调转码之后一定要抽样检查。还有一种看起来不像乱码但也不对的情况中文标题显示成#xxx;这样的 HTML 实体。这是编辑器或采集时转义造成的不是字符集问题改起来要批量做 HTML 实体解码。4.3 伪静态失效导致的404站点切过来首页正常栏目页和内容页全 404八成是伪静态规则没带过来。先确认后台系统基本参数里伪静态是开着的然后看 Web 服务器配置。Apache 需要mod_rewrite模块和.htaccess文件注意AllowOverride必须允许读取.htaccess否则文件放那儿也不生效——这个点在换服务器时特别容易漏。Nginx 的规则大致是这样具体路径格式以后台生成的链接为准rewrite ^/list_([0-9])_([0-9])\.html$ /plus/list.php?tid$1PageNo$2 last; rewrite ^/list_([0-9])\.html$ /plus/list.php?tid$1 last; rewrite ^/view_([0-9])\.html$ /plus/view.php?aid$1 last;Apache 侧写在.htaccessRewriteEngine On RewriteBase / RewriteRule ^list_([0-9])_([0-9])\.html$ plus/list.php?tid$1PageNo$2 [L] RewriteRule ^list_([0-9])\.html$ plus/list.php?tid$1 [L] RewriteRule ^view_([0-9])\.html$ plus/view.php?aid$1 [L]配完先测一条具体链接看是 404 还是 500。404 说明规则没匹配上500 说明重写目标路径不对。Nginx 里last和break的区别也要注意用错了会死循环。如果站点是静态化模式栏目页实际是.html物理文件那 404 就是文件没生成跟伪静态无关。先看html/目录下有没有对应文件没有就去后台重新生成。这个判断顺序能省很多时间。4.4 图片附件全部变成裂图前台所有图片都裂开先按 F12 看图片请求的实际地址。三种情况对应三种改法。地址指向老域名说明后台系统参数里的附件 URL 没改或者正文里存了绝对地址。前者去后台改后者按 3.3 节的 SQL 批量替换。地址对但返回 404说明附件没同步过去。用rsync再补一次然后核对文件数量。这里有个细节Linux 文件系统区分大小写如果老服务器是 Windows某些图片文件名的大小写可能和数据库里存的不一致换到 Linux 之后就会 404。这种情况要写脚本比对数据库里的路径和磁盘上的实际文件。地址返回 403说明文件存在但没读权限。检查uploads目录的属主和权限以及 Web 服务器有没有配置对静态资源的访问限制。还有一种不太常见但很坑的图片能加载但全是小尺寸的缩略图点开大图 404。这是缩略图文件缺失需要后台重新生成缩略图或者用工具批量处理。数据量大的话这个操作会跑很久建议放后台任务里做。4.5 改了配置却没生效的缓存链路DedeCMS 5.6 的缓存层级比想象的多改了一个地方没生效往往是缓存没清。第一层是系统参数缓存存在data/cache下的文件里后台改完参数一般会自动更新但如果权限不对写不进去就还是读旧值。手动删掉这个目录下的缓存文件最稳。第二层是模板编译缓存存在data/tplcache。改了模板文件但前台没变化多半是这里。删掉缓存后第一次访问会重新编译页面会慢一下属正常。第三层是静态 HTML。如果站点开了静态化你改模板、改参数都不会影响已经生成的.html文件必须重新生成对应页面。这一点最容易搞混——明明后台显示参数已经是新值了前台就是不认因为前台读的根本不是数据库。第四层是浏览器和 CDN 缓存。这个不用多说调试时用无痕窗口加禁用缓存能排除一大类幽灵问题。我一般会在改动之前先清一遍全部缓存改完再清一遍然后重新生成相关页面。顺序别搞反先改后清、清完再生成这样每一步的状态都是确定的。5. 老系统的安全底线与日常维护节奏5.1 目录层的执行权限封锁DedeCMS 5.6 的代码年龄摆在那儿指望它自己防住今天的攻击不现实。既然改不动代码那就在外围加一层最有效也最省事的手段是禁止上传目录和缓存目录执行 PHP。Nginx 的写法location ~* ^/(data|uploads|templets)/.*\.(php|php5|phtml)$ { deny all; return 403; }Apache 可以在对应目录下放一个.htaccessFilesMatch \.(php|php5|phtml)$ Require all denied /FilesMatch这两条规则拦住了绝大多数通过上传文件拿权限的路子。我在实际维护的站点上都会加上成本几乎为零收益极大。同一个思路还可以扩展把install目录直接删掉把member、special这些如果不用的功能目录连同入口一起禁用把后台目录名改成一个足够长的随机串并且限制访问来源 IP如果运维环境固定的话。5.2 后台入口与管理账号的收敛后台是整站权限的入口值得单独花点时间收紧。账号层面只保留一个超级管理员其他编辑账号按最小权限分配。所有账号密码长度不低于 16 位不要用站点名123这种。管理员表里的密码是 MD5 存储的本身强度不高所以密码的复杂度就是最后一道防线。入口层面除了改目录名还可以在 Web 服务器上加一层基础认证让访问后台需要两次验证location /manage_xxxx/ { auth_basic Restricted; auth_basic_user_file /etc/nginx/htpasswd; location ~ \.php$ { fastcgi_pass unix:/run/php/php5.6-fpm.sock; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } }这样即使后台路径被人摸到了没有第二层密码也进不去。配置稍微复杂一点但一次配好长期受益。还有个细节后台的日志功能要开着定期看一眼登录记录。老系统的后台日志不算详细但至少能看到谁在什么时间登录过异常登录能及时发现。5.3 备份策略与要不要升级的现实取舍最后聊聊备份和升级这两个绕不开的话题。备份我的习惯是分三层数据库每天全量导一次保留最近 14 天站点文件每周增量同步一次附件目录单独做配置文件在每次改动前手动存一份。数据库备份脚本大概是这样#!/bin/bash DATE$(date %Y%m%d) BACKUP_DIR/backup/mysql mkdir -p $BACKUP_DIR mysqldump -uuser -ppassword --default-character-setutf8 \ --single-transaction --triggers --routines \ --databases dedecms | gzip $BACKUP_DIR/dedecms_$DATE.sql.gz # 只保留 14 天 find $BACKUP_DIR -name dedecms_*.sql.gz -mtime 14 -delete配合 crontab 每天凌晨跑一次。备份文件一定要定期做还原演练只备不验等于没备这个道理谁都懂真做到的没几个。至于要不要把 5.6 升级到更新的版本我的看法比较务实如果站点还在正常产出、流量稳定、没有新的功能需求就不要动。跨大版本升级涉及数据结构和模板体系的变更风险和成本都很高收益却不明显。真正该做的是把外围防护做扎实、把备份做可靠、把访问层的问题挡在外面。只有当站点确实需要新功能或者现有的安全风险已经无法通过外围手段控制时才考虑重构或者换系统。那时候的决策依据就不是新版本更好而是维护成本已经超过迁移成本。我在实际操作中的体会是这类老站点的运维七分靠流程、三分靠技术。迁移前把清单列全迁移中按顺序走、每一步都验证迁移后按故障树排查而不是凭感觉猜绝大多数问题都能在半小时内定位。真正让人头疼的从来不是技术难点而是以为搬完了的那份自信——多核对一次文件数量多抽查几篇文章多清一遍缓存能省掉的通宵远比想象中多。
阅读完成 · 觉得有帮助？
