第三日
第三天白天主要是带娃在游乐场玩，她在那边儿玩沙子滑滑梯，我在边上，除了负责盯梢和傻笑以外，有空的时候，脑子里就在想Permalinks访问不通，问题可能在哪里？WordPress迁移怎么这么麻烦，还是我自己的做法走偏了？有一刻，突然想起来一个关键问题，在Apache的配置文件里，好像看到过一个叫AllowOverride的东西，想到.htaccess文件可以改变Apache服务器的行为，就在猜，这么NB的超能力，不会是默认关了吧？但是如果默认是关的，为什么所有的方案都没有提到呢？手上没有本子，就只能想想。
晚上回家吃完饭，打开/etc/httpd/conf/httpd.conf，发现了下面这样的配置及注释，才验证了自己的猜想：
# Further relax access to the default document root:
<Directory "/var/www/html">
#
# AllowOverride controls what directives may be placed in .htaccess files.
# It can be "All", "None", or any combination of the keywords:
# Options FileInfo AuthConfig Limit
#
AllowOverride None
</Directory>默认值是None。我改成All了，重启Http服务，刷新页面，permalinks正常工作了。
所以说，程序员的产出呀，和工作时间其实没啥关系，思路对了，解决起来非常简单，思路不对，折腾到半夜也没有用。（注：这里的产出，主要指创造型和解决问题型的产出，按PRD堆砌CRUD页面不在此范畴）
然后在WordPress的后台首页，看到了这样的错误：
这可能就是所谓的模块级服务降级吧。不得不说，WordPress的错误提示还是很友好的，至少一看就知道是有模块没有安装的问题。但是再想想，为啥PHP的模块要分这么细呢？不由得想到，这开源界的洁癖还真是无所不在啊。看看人家.NET，all-in-one，管你要不要用呢。
这个处理起来也很简单，装就是了。
dnf install php-xml php-intl这个问题处理好了之后，在健康检查页面，又看到了这么个错误：
我以为这无非就是再跑一行dnf命令的事儿，然而事实证明我太天真了。
去Google一下install imagick on CentOS 8，会发现有一长串结果，标题差别还很大，这一般不是个好兆头，说明这个事儿比较复杂，而且每个人的做法都不一样。
下面是要按其中一份作业整理出来的小抄摘要笔记：
dnf install epel-release
dnf config-manager --set-enabled PowerTools
dnf install ImageMagick ImageMagick-devel
dnf install php-pear make
pecl install imagick
echo "extension=imagick.so" > /etc/php.d/20-imagick.ini
systemctl restart httpd然后跑到第三步就失败了，失败原因很简单，说是找不到ImageMagick。同时，我还注意到，在命令行的输出里，开始出现了一个新品种的提示信息：
Repository epel is listed more than once in the configuration
这个错误提示就比较让人恼火了，它平静地阐述了一个客观事实，但是又没有解释这个事实有什么不对的地方。就仿佛有人大喊，“下雨啦”，也不知道是在感慨久旱逢甘霖，还是在提醒大家赶快收衣服。
但是，作为职业程序员，这十几年间培养起来的职业素养，在这一刻终于发挥了作用。一眼就看出来，写这个提示的人的意思是，出现多次会有问题，而且背后的意思是，其中只有一个会真正生效。然后，真正的问题是，生效的这个里，没有ImageMagick这个包，然后可以乐观地猜想，没有生效的那个仓库（Repository）里有这个包。我们先假设网上安装步骤是对的，那么就是刚才安装的官方epel-release没有生效，也就是说，系统里自带了一个安装包不全的坑货Repository，名字也叫epel，故意把官方repository给调包了。
脑子里分析到这里，虽然有种推理破案的快感，但是我在心里还是骂了句“操！”，因为这意味着一个更加恐怖的事情：我这台ECS主机的操作系统，不是原生的CentOS，是定制版的OS，而且修改过Repository。意思是，我这几天安装的所有软件，都可能不是官方版本，技术上来讲，可以是私人定制版本。而如果这个Repository是个不正经的Repository，那么他基本上可以在我的这台主机上为所欲为。（比如阿里开发者社区上公开的PyPI镜像下架列表。）
然后我赶紧看了一下操作系统信息（BTW，这里可以了解下Redhat，Fedora和CentOS的关系）：
[user@host ~]# cat /etc/os-release
NAME="Anolis OS"
VERSION="8.5"
ID="anolis"
ID_LIKE="rhel fedora centos"
VERSION_ID="8.5"
PLATFORM_ID="platform:an8"
PRETTY_NAME="Anolis OS 8.5"
ANSI_COLOR="0;31"
HOME_URL="https://openanolis.cn/"Anolis OS是什么鬼？一看这名字就是阿里出的坑货啊。我明明记得下单的时候选的是CentOS啊。我再去看我当时下的订单的详细信息，里面写的居然是“Anolis OS 8.4 RHCK 64位Linux64位”。
那么有两种可能，要么我点错了，要么是阿里为了推广自己的OS搞了鬼，毕竟这个Anolis OS，我看了一下，自称是100%兼容CentOS 8的。但是这种事儿永远没办法求证了。除非有24小时录屏。【此处应有商机】
算了，还是先解决问题吧。反正后面可以换操作系统。
先找出元凶：
[user@host ~]# grep -Rln "\[epel\]" /etc/yum.repos.d
/etc/yum.repos.d/AnolisOS-DDE.repo
/etc/yum.repos.d/epel.repo果然有两个repo都定义了[epel]。然后果然有一个是AnolisOS带的。我看看里面的内容：
[user@host ~]# cat /etc/yum.repos.d/AnolisOS-DDE.repo
[DDE]
name=AnolisOS-$releasever - DDE
baseurl=http://mirrors.cloud.aliyuncs.com/anolis/$releasever/DDE/$basearch/os
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-ANOLIS
gpgcheck=1
[epel]
name=epel
baseurl=http://mirrors.aliyun.com/epel/8/Everything/$basearch/
enabled=0
gpgkey=http://mirrors.aliyun.com/epel/RPM-GPG-KEY-EPEL-8
gpgcheck=1这就非常有意思了。有这么几个问题：
- 名字叫DDE.repo，然后里面定义了两个repo。这不是不行，就是感觉不太规范的样子。
- 一个是aliyun的mirror站，一个是aliyuncs的mirror站。而后者是打不开的。你说你都打到公开售卖的镜像里的URL，打都打不开这像话吗？尽管看上去默认是Disable的。
算了，阿里那边儿的事儿先放放（虽然我后来发现阿里已经有个页面介绍如何配置epel了），先解决这个ImageMagick安装不上的问题，这个对我来说更重要些。解决办法很简单，就是把上面的[epel]这部分注释掉就好了。
#[epel]
#name=epel
#baseurl=http://mirrors.aliyun.com/epel/8/Everything/$basearch/
#enabled=0
#gpgkey=http://mirrors.aliyun.com/epel/RPM-GPG-KEY-EPEL-8
#gpgcheck=1做这个操作的时候，我又在想，要是整个文件系统都放git里，我就不用注释或是备份了，直接删除。
然后，再次运行上面的中断掉的第三步，就顺利完成了。
然而，都安装好了之后，用php命令验证的确貌似安装成功了：
[user@host ~]# php -m | grep magic
imagickWordPress还是说imagick没加载。算了，一个小时都没救回来也算尽力了，反正我也用不到这个功能。等有空了再回来看看PHP或是WP的error log啥的吧。
现在还有更重要的问题要解决，就是WordPress上的ICP备案信息没有了。
当我们安装完中文版的WordPress之后，可以在配置中填写ICP备案号并显示在页面上。然而，新的服务器上，一开始是安装的是英文版，后来切换成了中文。但是这个ICP备案号的配置根本就没有，更不要说显示在页面上了。
据考证，这个功能是WordPress 3.7开始由官方引入。所以理论上应该在WordPress的源代码里可以找到。所以在老服务器上找一下：
[hugo.gu@local htdocs] % grep -R "仅对WordPress" .
./wp-content/languages/zh_CN.php: '<p class="description">仅对WordPress自带主题有效。</p>';
然后下载最新的官方的中文版WordPress。会发现里面没有这个文件：
[hugo.gu@local wordpress] % find . -name "zh_CN.php" -print
[hugo.gu@local wordpress] % 的确也有人猜测，WordPress大概是在某个版本开始放弃了在language包里添加配置的这种做法。有兴趣的同学可以去那个毫无人气的WordPress中文社区去展开进一步的调查。
最终，我也没能在任何官方来源上找到这个文件，只能通过FileZilla，自己上传了一个老版本的zh_CN.php文件上去。然后一刷新，果然就都有了。尽管这个只能在自带主题上使用的配置项其实非常鸡肋，但是WordPress官方的这种，为了不让人顺顺利利地，以开源方式使用他们家的产品，所做的诸多努力，着实让人倍感钦佩。
然而，ICP备案的事儿，还没有结束。现在ICP备案信息显示出来了，但是由于迁移了服务器，IP地址发生了变化，那么之前的ICP备案信息，是否需要提交复核修正或是重新申请呢？