京瓷 FS – 1025MFP 底灰问题，之前处理过的是由于混用了不同品牌的碳粉导致，或者是碳粉的品质不好导致的。清洁显影后，重新加入质量好的碳粉，之后一直使用该品牌的碳粉就不会出现底灰。由于打印量巨大，感光鼓磨损老化，出现竖线以及底灰现象。更换了国产感光鼓组件之后，竖线问题解决，还有很轻微的底灰，不影响打印质量及使用就没有进一步的处理了。
但是使用了几个月之后，底灰越来越严重，如下图：
解决方法：
登录查看完整内容
京瓷 FS-1025MFP 底灰处理
升级 WordPress5.5 中又遇到建立数据库连接时出错
因为在线升级 WordPress 5.5 出问题，于是手动升级，但还是升级失败，这真的不合常理！硬是浪费了几个小时的时间折腾。不知道是阴差阳错或是什么原因，数据库连接时出错 实质上是没有搞清楚 MySQL8 新密码机制 caching_sha2_password 。但是我之前为何能够一直正常运行直至此次升级，却卡在此次升级里暴露出问题，难道不是奇怪吗！
升级 WordPress 5.5 的失败经历
按照常规的在线升级，登录 WordPress 后台，点击更新，因为国内网络问题，总是无法下载更新文件导致失败。接着继续反复重新操作点击更新，却又提示：另一更新正在进行。
于是就无法操作了，无论怎么点击更新，都提示：另一更新正在进行。
尝试网上的各种方法，结果不用多说，失败告终！我尝试的是这种修改主题 function.php 函数，以达到修改数据库的方法，没用！而且不推荐使用这些修改数据库的方法！
# 没用的方法！不要尝试！
global $wpdb;
$wpdb->query("DELETE FROM wp_options WHERE option_name = 'core_updater.lock'");然后，我把没用的函数方法删除！
放弃在线更新，使用手动更新。以往我是这样手动更新的：保留 wp-content 目录 与 wp-config.php ，.htaccess 文件如果有的话也得保留，删除旧版本的 WordPress 所有文件。然后把最新版本的 WordPress 5.5 下载下来解压后，再通过 WinSCP 上传到服务器。最后打开网站登录 WordPress 后台会提示更新数据库，点击更新即可。但是这一次 升级 WordPress 5.5 ，失败了。
即使是上传最新版本的 WordPress 5.5 ，保留之前的 wp-content 目录，登录后台，没有提示升级数据库，依旧显示运行的是旧的 5.4 版本号，检查更新依旧提示需要更新到最新的 WordPress 5.5 。于是我在后台再次点击更新到5.5，怪事又出现了，可以正常下载更新了，更新文件之后，却还是记录的是旧的 5.4 版本号，再次检查更新，还是提示需要更新到最新的5.5！死循环了！即使是手动上传新版文件，都无法更新。这难道不是数据库出了问题吗？
好吧！反正我有数据库备份，也有 wp-content 目录备份，推倒了再来！！
以 root 身份登录数据库，删除之前旧的 WordPress 数据库以及用户，重新创建新的数据库（wordpress2）与用户（user2）。
然后导入之前备份的数据库到 wordpress2 ，最后配置好 wp-config.php 上的数据库用户等参数，再三确认数据库库名，用户，密码都没有错。打开网站却提示：Error establishing a database connection （建立数据库连接时出错）
这个问题花了不少的时间，最终发现 MySQL8 新密码机制 caching_sha2_password ，导致 WordPress 无法连接到数据库。
解决 WordPress 5.5 连接 MySQL8 数据库时出错的问题
本次遇到的问题是 MySQL8 新密码机制 caching_sha2_password 导致了 WordPress 建立数据库连接时出错。
以下命令是查看 MySQL 数据库用户所使用的加密机制
mysql> select user, plugin from mysql.user;
+------------------+-----------------------+
| user | plugin |
+------------------+-----------------------+
| mysql.infoschema | caching_sha2_password |
| mysql.session | caching_sha2_password |
| mysql.sys | caching_sha2_password |
| root | mysql_native_password |
| user2 | caching_sha2_password |
+------------------+-----------------------+
5 rows in set (0.00 sec)我们需要将 user2 用户修改为旧的加密机制 mysql_native_password ，使用以下命令修改
ALTER USER 'user2'@'localhost' IDENTIFIED WITH mysql_native_password BY '**密码**';修改之后，再次查看 MySQL 数据库用户所使用的加密机制
mysql> select user, plugin from mysql.user;
+------------------+-----------------------+
| user | plugin |
+------------------+-----------------------+
| mysql.infoschema | caching_sha2_password |
| mysql.session | caching_sha2_password |
| mysql.sys | caching_sha2_password |
| root | mysql_native_password |
| user2 | mysql_native_password |
+------------------+-----------------------+
5 rows in set (0.00 sec)修改成功！
那么我们所遇到的所有的问题都解决了！
最后，强烈建议手动升级！升级之前一定要先备份好数据库！
手动升级 NextCloud 19.0.2 的步骤
强烈推荐手动升级，因为由于在国内连接国外的 NextCloud 服务器在线升级，网络问题等原因真的会容易出现各种更新失败的问题，之后解决问题就更麻烦。
升级 NextCloud 之前，首先要考虑备份数据库，除非数据库并不那么重要，可以不用备份数据库。比如我自己使用的 NextCloud 的数据库实际上不是那么的重要。因为现阶段我主要使用的功能是存储文件，PC端也有同步盘，所以只要我的文件还在，没有丢失，数据库实际上并不那么的重要。除非我们的资料文件记录了许多的版本，而且我们重度使用文件版本，就必需备份好数据库。我没有备份数据库的最根本的原因，还是因为懒！并一直认为升级会顺利完成的，存在侥幸的心理。
从 NextCloud 19.0.1 升级到 NextCloud 19.0.2
如果你使用的版本是 NextCloud 19.0.1 的话，强烈建议升级到 NextCloud 19.0.2 。新版本修复了很多问题。我的运行环境是 CentOS7 + Apache + MySQL + PHP
参考官方的步骤方法
https://docs.nextcloud.com/server/19/admin_manual/maintenance/manual_upgrade.html
1、停止服务器和计划任务
停止 httpd
systemctl stop httpd
停止 cron.php 计划任务
查看 apache 执行的计划任务，用 # 注释掉，保存。
crontab -u apache -e
2、备份旧版本文件
重命名 nextcloud 目录为 nextcloud-old
3、上传新版本文件
使用 WinSCP 上传新版 nextcloud 19.0.2 所有文件到服务器 nextcloud 目录。
4、恢复备份文件与应用
从备份目录 nextcloud-old 复制配置文件到 nextcloud 对应目录
cp /var/www/html/nextcloud-old/config/config.php /var/www/html/nextcloud/config/如有安装第三方应用，从备份目录 nextcloud-old 移动第三方应用到 nextcloud 对应目录
mv /var/www/html/nextcloud-old/apps/onlyoffice /var/www/html/nextcloud/apps/从备份目录 nextcloud-old 移动 data 目录到 nextcloud 对应目录
mv /var/www/html/nextcloud-old/data /var/www/html/nextcloud/5、授予权限
进入 html 目录
cd /var/www/html
授予权限
chown -R apache:apache nextcloud
find nextcloud/ -type d -exec chmod 750 {} \;
find nextcloud/ -type f -exec chmod 640 {} \;重启 httpd
systemctl restart httpd
6、执行升级
必需进入 nextcloud 目录进行升级
进入 nextcloud 目录
cd /var/www/html/nextcloud
执行升级
sudo -u apache php occ upgrade
升级完成后，登录管理页面，检查 nextcloud 的版本号是否已经升级成功，以及检查第三方应用。
7、恢复计划任务
查看 apache 计划任务，把 # 注释去掉，保存。
crontab -u apache -e
8、升级完成后删除旧文件
顺利完美升级之后，我们再决定删除 nextcloud-old 目录。
CentOS7 挂载 xfs 磁盘
系统是 CentOS7.6 安装的时候选择集成 GNOME Desktop(GNOME 桌面) 。因为在 Hyper V 虚拟机运行，最新版的 Linux Integration Services v4-3-5 好像不支持 CentOS7.8 以上的版本吧？所以选择了 CentOS7.6
所以我挂载 xfs 磁盘，是在 GNOME桌面 操作配合命令完成的。
首先在 Hyper V 上新建一个 1TB 的 VHDX 格式动态磁盘，然后将其添加至 CentOS7 系统上。
下面进入 CentOS7 桌面环境操作：
桌面环境我们使用的工具是 Disks ，位于：
Applications(应用) → Utilities(实用工具) → Disks(磁盘)
1、初始化新磁盘
选中刚刚添加的 1TB 新磁盘，点击右上角菜单 Format Disk ，如下图
格式化选项，默认（Quick）（GPT）
再次确认 Format
2、创建分区
点击 + 新建分区，如下图
分区默认大小为磁盘最大容量，1TB 只分作一个分区，点击 Next
Volume Name 根据喜好填上。Type 这里我们需要的 xfs 没有列出来，我们选择 Other 然后点击 Next
选择 XFS – Linux Filesystem，点击 Create
点击 齿轮图标 Edit Partition 编辑分区
Type 这里选择 Linux LVM ，Name 根据喜好填上，点击 Change
分区类型 Linux LVM 创建完成，设备路径 Device /dev/sdb1，稍后使用命令挂载。
下面进入命令操作：
我们需要将刚才的 1TB 分区挂载到系统使用，就要创建一个目录，然后将 1TB 的磁盘分区挂载到该目录。
创建 data 目录
mkdir /data
将 1TB 分区挂载到该目录
mount /dev/sdb1 /data
设置开机自动挂载
vi /etc/fstab
#
# /etc/fstab
# Created by anaconda on Sat Aug 8 03:00:28 2020
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/centos-root / xfs defaults 0 0
UUID=16a6f59d-c41b-4cd2-b8ad-234747fe691f /boot xfs defaults 0 0
UUID=4C6E-5A30 /boot/efi vfat umask=0077,shortname=winnt 0 0
/dev/mapper/centos-swap swap swap defaults 0 0
# 使之开机自动挂载
/dev/sdb1 /data xfs defaults 0 0重启系统生效
reboot
请注意 重启系统 之后，设置 data 目录的权限为 755 ，以便之后各种程序的访问。
任务完成！
CentOS7 修改 Apache24 默认网站根目录
淘汰的低端主机搞上 Windows Server2012R2 Hyper-V
虚拟机一：CentOS7 + Apache24 + PHP73 + MySQL80 = NextCloud + WordPress
虚拟机二：LEDE = MWAN + aliyunDDNS + KMS
考虑过使用实体机运行 CentOS 这个系统，但是我 LEDE 难道又要另外一台主机（低功耗平台j1900/N3150等）来搞就不现实了。成本、功耗都不如一台主机来的实际，至于 LEDE 运行在实体机与虚拟机的性能差别，我没有对比过不知道。包括 CentOS 也没有使用实体机长期运行过。一直在使用阿里云 ECS 上面的 CentOS7，对比 Hyper-V 里运行的 CentOS7 ，阿里云 ECS 除了磁盘响应快点，其它都是 Hyper-V 上的性能更强。
可以负责的说 LEDE 运行在 Hyper-V 磁盘 SSD 上已经飞快了！！一块博通双口千兆网卡 + 两块 intel 单口千兆网卡，第二代 Hyper-V 虚拟机。虽然入户只是 100M，内外网都完美识别使用千兆，速度与响应飞快，没有发现任何瓶颈。
虽然有几台垃圾低端淘汰的 PC ，最后还是决定了只用一台主机搞虚拟机，在功耗与成本方面都更有优势。
使用 NextCloud 存储照片、文件、资料等等，并与 PC 客户端同步，这样是否相当于实现了镜像存储？进一步提高数据不会由于硬盘损坏导致突然丢失的风险。而且 NextCloud 可以通过 DDNS 实现外网访问等各种方便，比纯粹的存储池镜像模式存储强多了。
所以 NextCloud 需要一个容量比较大的数据盘，在 Hyper-V 使用 SSD 的性能确实是爽，不过既然是使用淘汰的主机作为家用的低级服务器，就不应该考虑大容量的 SSD 咯。自己主用的 PC 都只是128G SSD + 2TB HDD而已。但是 Hyper-V 使用机械盘 HDD 运行 CentOS 明显比在 SSD 上运行慢了许多，没有对比就没有伤害。 CentOS 一样可以像 Windows 那样，系统装在 SSD ，资料文件需要大容量存储的使用 HDD ！
实际上早就已经是这样搞过了，但是效果并不理想，应该是分区不合理的原因。
最初是这样搞的：
Hyper-V 建立一个 50G 放在 SSD 上的 动态磁盘VHDX 用作 CentOS 系统所有分区但不包括 /var 目录，挂载一个1TB放在 HDD 上的 动态磁盘VHDX 作为 /var 分区。
这个方案运行了一段时间，稳定没有问题，唯一就是速度并不理想。甚至在安装 Nextcloud 与 WordPress 的时候都感觉到还没有单纯使用 HDD 的速度快。
能感觉到的是在启动或重启 CentOS 的时候，确实是快了一点点。
最近又这样搞的：
Hyper-V 建立一个 30G 放在 SSD 上的 固定磁盘VHDX 用作 CentOS 系统，挂载一个1TB放在 HDD 上的 动态磁盘VHDX 作为 /fzdata 目录。
然后修改 apache24 默认网站根目录为 /fzdata/www/html/ 目录。
当然是效果明显好了！才会在这里唧唧歪歪的记录下来的。磁盘读写各方面都提升了，舒服。
修改 Apache24 默认网站根目录的方法
1、修改 httpd.conf 配置文件
vi /etc/httpd/conf/httpd.conf
# DocumentRoot "/var/www/html"
# 注释掉原有的默认网站根目录，添加我们的网站根目录
DocumentRoot "/fzdata/www/html"
# 原有的规则不用修改路径，我们只需增加自己的新路径
<Directory "/var/www">
AllowOverride None
# Allow open access:
Require all granted
</Directory>
# 原有的规则不用修改路径，我们只需增加自己的新路径
<Directory "/var/www/html">
# Options Indexes FollowSymLinks
Options FollowSymLinks
# AllowOverride None
AllowOverride All
Require all granted
</Directory>
# 我们只需增加自己的新路径在这里即可。
<Directory "/fzdata/www">
AllowOverride None
# Allow open access:
Require all granted
</Directory>
<Directory "/fzdata/www/html">
Options FollowSymLinks
AllowOverride All
Require all granted
</Directory>2、修改 ssl.conf 配置文件
vi /etc/httpd/conf.d/ssl.conf
<VirtualHost _default_:443>
# DocumentRoot "/var/www/html"
# 注释掉原有的默认网站根目录，添加我们的网站根目录
DocumentRoot "/fzdata/www/html"
#ServerName www.example.com:443
ServerName www.abcd.com:443
</VirtualHost> 其它的ssl证书等配置，只需按照常规配置即可。
3、一定要注意 /fzdata/ 这个目录的权限
apache 必需有权限访问 /fzdata/ 这个目录
我当时折腾了好久都是失败，总是提示 You don’t have permission to access /xx/xxx/ on this server.
这个目录在创建的时候权限是 755
但是挂载 1TB 的 xfs 分区到 /fzdata/ 目录，重启系统后，权限却变成了 700
没有注意到挂载后会改变目录的权限问题，最后才发现这个问题，将权限改为 755 之后，一切运行都正常了。
OpenWRT/LEDE自带DDNS完美嵌入阿里云脚本
2年前（2018年）已经在Windows系统 实现了阿里云 DDNS ，运行了两年多了，非常稳定，完美。最近想尝试不依赖Windows系统，也能够完美的使用阿里云DDNS，想着如果能在 CentOS 实现的话应该挺香的。
于是关于 CentOS 使用阿里云DDNS的方法我百度了很久，使用 python，Java，…，各种方法来实现，方法太多，都不知道哪些方法是好用，眼花缭乱，也就没有折腾欲望了。但却无意中发现，OpenWRT/LEDE 自带的 DDNS 功能也可以嵌入阿里云DDNS脚本！
这个难道不更香吗！如果能够成功的在 OpenWRT/LEDE 上嵌入阿里云DDNS脚本，那才是真香！我之前在Windows系统里运行的阿里云DDNS服务，就可以列入备用方案了。
在Windows系统稳定运行了2年多的阿里云DDNS服务折腾记录：
无意中发现了一位大神的方案：适用于OpenWRT/LEDE自带DDNS功能的阿里云脚本，完美嵌入
https://www.right.com.cn/forum/thread-267501-1-1.html
这位sensel大神的方法实在太完美了，马上测试。
LEDE自带DDNS完美嵌入阿里云脚本
我现在用的是LEDE17，虽然OpenWRT与LEDE又合并为OpenWRT了。新版本不断发布，现在最新版本OpenWrt 19.07，但我不喜欢新版本，u1s1不想折腾了，折腾太累人。
下面开始记录此次LEDE嵌入阿里云DDNS脚本的折腾过程
1、需要拥有阿里云的域名，并创建 AccessKey （子用户即可）
2、安装sensel大神的 ddns-scripts_aliyun_1.0.0-1_all.ipk （OpenWRT/LEDE全平台适用）
ddns-scripts_aliyun_1.0.0-1_all.ipk 软件依赖：
ddns-scripts（即自带DDNS管理脚本）
luci-app-ddns（可选，自带功能的LUCI界面）
wget（GNU Wget 完成与服务器通信）
openssl-util（openssl工具用于生成签名）
可以网页登录 LEDE 把依赖安装好之后，重启LEDE。
把 ddns-scripts_aliyun_1.0.0-1_all.ipk 使用 WinSCP 上传到 LEDE 的 root 目录
使用 putty 连上 LEDE 执行命令安装：
root@LEDE:~# cd /root/
root@LEDE:~# ls
ddns-scripts_aliyun_1.0.0-1_all.ipk
root@LEDE:~# opkg install ddns-scripts_aliyun_1.0.0-1_all.ipk
Installing ddns-scripts_aliyun (1.0.0-1) to root...
Configuring ddns-scripts_aliyun.安装完成，重启 LEDE
网页登录 LEDE 安装中文包 luci-i18n-ddns-zh-cn
安装一切顺利完成，下面进入参数配置
配置LEDE动态DNS
首先需要注意的是，ddns-scripts_aliyun_1.0.0-1 这个脚本有点点BUG，我们如果不注意或设置不正确，它会覆盖解析记录。如下图：它居然把MX记录给修改覆盖了。
因为当初没有弄明白如何配置 Lookup Hostname 与 Domain 。
在运行 ddns-scripts_aliyun_1.0.0-1 之前，我们必需在域名解析里重新分别新建主机记录：@ 与 www 并且必需把这两个记录排在前面。（避免覆盖已有的解析记录）
网页登录 LEDE → 动态DNS → 总览
分别添加主机记录：@ 与 www （因为单个 PID 只能修改单个记录值）
aliyun_a 主机记录：@ 对应的是 sxxxz.top
aliyun_www 主机记录：www 对应的是 www.sxxxz.top
如下图：
进入 aliyun_a 详细配置 → 基本设置 ，如下图：
注意：用户名（AccessKeyId），密码（AccessKeySecret）
进入 aliyun_www 详细配置 → 基本设置 ，如下图：
为了安全，推荐使用HTTPS。至于CA证书路径，这个没有搞明白，那么必需填上IGNORE
进入 aliyun_a 详细配置 → 高级设置 ，如下图：
DNS服务器 （强烈推荐自己填上，我这里填的是阿里云公共DNS地址）
以下是 aliyun_a 日志文件：
221348 : ************ ************** ************** **************
221348 note : PID '2645' started at 2020-07-09 22:13
221348 : ddns version : 2.7.6-13
221348 : uci configuration:
ddns.aliyun_a.cacert='IGNORE'
ddns.aliyun_a.dns_server='223.5.5.5'
ddns.aliyun_a.domain='@sxxxxz.top'
ddns.aliyun_a.enabled='1'
ddns.aliyun_a.interface='wan2'
ddns.aliyun_a.ip_interface='pppoe-wan2'
ddns.aliyun_a.ip_source='interface'
ddns.aliyun_a.lookup_host='sxxxxz.top'
ddns.aliyun_a.password='Mxxxxxxxxxxxxxxxxxxxxs'
ddns.aliyun_a.service_name='aliyun.com'
ddns.aliyun_a.use_https='1'
ddns.aliyun_a.username='Lxxxxxxxxxxy'
ddns.aliyun_a=service
221348 : verbose mode : 0 - run normal, NO console output
221348 : check interval: 600 seconds
221348 : force interval: 259200 seconds
221348 : retry interval: 60 seconds
221348 : retry counter : 0 times
221348 : No old process
221348 : last update: never
221348 : Verify DNS server '223.5.5.5'
221348 : #> timeout 2 -- /usr/bin/nc 223.5.5.5 53 </dev/null >/var/run/ddns/aliyun_a.dat 2>/var/run/ddns/aliyun_a.err
221348 : Detect registered/public IP
221348 : #> /usr/bin/nslookup sxxxxz.top 223.5.5.5 >/var/run/ddns/aliyun_a.dat 2>/var/run/ddns/aliyun_a.err
221348 : Registered IP '1xx.2x.1xx.x6' detected
221348 info : Starting main loop at 2020-07-09 22:13
221348 : Detect local IP on 'interface'
221348 : #> ip -o addr show dev pppoe-wan2 scope global >/var/run/ddns/aliyun_a.dat 2>/var/run/ddns/aliyun_a.err
221348 : Local IP '1x2.2x.1xx.16' detected on interface 'pppoe-wan2'
221348 : Update needed - L: '1x2.2x.1xx.16' <> R: '1xx.2x.1xx.x6'
221348 : parsing script '/usr/lib/ddns/update_aliyun_com.sh'
221348 : #> /usr/bin/wget-ssl -nv -t 1 -O /var/run/ddns/aliyun_a.dat -o /var/run/ddns/aliyun_a.err --no-check-certificate --no-proxy 'https://alidns.aliyuncs.com/?Action=DescribeSubDomainRecords&SubDomain=%40.sxxxxz.top&Format=JSON&Version=2015-01-09&AccessKeyId=Lxxxxxxxxxxy&SignatureMethod=HMAC-SHA1&Timestamp=2020-07-09T14%3A13%3A48Z&SignatureVersion=1.0&SignatureNonce=88976dd5-4dfd-4811-aefc-390a72788dfd&Signature=222uxnhvKHL0WscEo%2BN7fbzDmv4%3D'
221349 : 获得解析记录ID: 20014243980380160
221349 : 地址或类型需要修改
221352 : #> /usr/bin/wget-ssl -nv -t 1 -O /var/run/ddns/aliyun_a.dat -o /var/run/ddns/aliyun_a.err --no-check-certificate --no-proxy 'https://alidns.aliyuncs.com/?Action=UpdateDomainRecord&RecordId=20014243980380160&RR=%40&Type=A&Value=1x2.2x.1xx.16&Format=JSON&Version=2015-01-09&AccessKeyId=Lxxxxxxxxxxy&SignatureMethod=HMAC-SHA1&Timestamp=2020-07-09T14%3A13%3A52Z&SignatureVersion=1.0&SignatureNonce=1eb82ff4-4f3e-41c0-b91b-0d7ee5389dd4&Signature=2LZVURyMZxGl0N57WF3%2FnO3fBwM%3D'
221352 : 修改解析记录成功
221352 info : Update successful - IP '1x2.2x.1xx.16' send
221352 info : Forced update successful - IP: '1x2.2x.1xx.16' send
221352 : Waiting 600 seconds (Check Interval)以下是 aliyun_www 日志文件
221348 : ************ ************** ************** **************
221348 note : PID '2646' started at 2020-07-09 22:13
221348 : ddns version : 2.7.6-13
221348 : uci configuration:
ddns.aliyun_www.cacert='IGNORE'
ddns.aliyun_www.dns_server='223.6.6.6'
ddns.aliyun_www.domain='www.sxxxxz.top'
ddns.aliyun_www.enabled='1'
ddns.aliyun_www.interface='wan2'
ddns.aliyun_www.ip_interface='pppoe-wan2'
ddns.aliyun_www.ip_source='interface'
ddns.aliyun_www.lookup_host='www.sxxxxz.top'
ddns.aliyun_www.password='Mxxxxxxxxxxxxxxxxxxxxs'
ddns.aliyun_www.service_name='aliyun.com'
ddns.aliyun_www.use_https='1'
ddns.aliyun_www.username='Lxxxxxxxxxxy'
ddns.aliyun_www=service
221348 : verbose mode : 0 - run normal, NO console output
221348 : check interval: 600 seconds
221348 : force interval: 259200 seconds
221348 : retry interval: 60 seconds
221348 : retry counter : 0 times
221348 : No old process
221348 : last update: never
221348 : Verify DNS server '223.6.6.6'
221348 : #> timeout 2 -- /usr/bin/nc 223.6.6.6 53 </dev/null >/var/run/ddns/aliyun_www.dat 2>/var/run/ddns/aliyun_www.err
221348 : Detect registered/public IP
221348 : #> /usr/bin/nslookup www.sxxxxz.top 223.6.6.6 >/var/run/ddns/aliyun_www.dat 2>/var/run/ddns/aliyun_www.err
221348 : Registered IP '1xx.2x.1xx.x6' detected
221348 info : Starting main loop at 2020-07-09 22:13
221348 : Detect local IP on 'interface'
221348 : #> ip -o addr show dev pppoe-wan2 scope global >/var/run/ddns/aliyun_www.dat 2>/var/run/ddns/aliyun_www.err
221348 : Local IP '1x2.2x.1xx.16' detected on interface 'pppoe-wan2'
221348 : Update needed - L: '1x2.2x.1xx.16' <> R: '1xx.2x.1xx.x6'
221348 : parsing script '/usr/lib/ddns/update_aliyun_com.sh'
221348 : #> /usr/bin/wget-ssl -nv -t 1 -O /var/run/ddns/aliyun_www.dat -o /var/run/ddns/aliyun_www.err --no-check-certificate --no-proxy 'https://alidns.aliyuncs.com/?Action=DescribeSubDomainRecords&SubDomain=www.sxxxxz.top&Format=JSON&Version=2015-01-09&AccessKeyId=Lxxxxxxxxxxy&SignatureMethod=HMAC-SHA1&Timestamp=2020-07-09T14%3A13%3A48Z&SignatureVersion=1.0&SignatureNonce=ac0bdb60-be1c-45bf-ae8a-070656cff2d2&Signature=XiWj7HxuIFDh1034%2BJKStNE2R4Y%3D'
221349 : 获得解析记录ID: 20014328286902272
221349 : 地址或类型需要修改
221352 : #> /usr/bin/wget-ssl -nv -t 1 -O /var/run/ddns/aliyun_www.dat -o /var/run/ddns/aliyun_www.err --no-check-certificate --no-proxy 'https://alidns.aliyuncs.com/?Action=UpdateDomainRecord&RecordId=20014328286902272&RR=www&Type=A&Value=1x2.2x.1xx.16&Format=JSON&Version=2015-01-09&AccessKeyId=Lxxxxxxxxxxy&SignatureMethod=HMAC-SHA1&Timestamp=2020-07-09T14%3A13%3A52Z&SignatureVersion=1.0&SignatureNonce=c56cd4ed-95ba-413a-8355-a60b349c7a95&Signature=sQ1d0Um94Grwqg8ga2bGWlUpXGU%3D'
221352 : 修改解析记录成功
221352 info : Update successful - IP '1x2.2x.1xx.16' send
221352 info : Forced update successful - IP: '1x2.2x.1xx.16' send
221352 : Waiting 600 seconds (Check Interval)假如 DNS服务器 此参数不填
就会使用默认DNS服务器（mydns.lan，这个默认dns难道是LEDE里的lan侧dns ？），会导致 Lookup Hostname（已注册的IP地址）更新非常缓慢，慢到可能30至40分钟之后，都没有更新正确的IP地址。我分析这个默认dns，应该就是使用LEDE里的lan侧dns，我这里默认的是电信的dns，更新慢得无法接受。
查看日志发现，如果侦测到 已注册的IP地址 （Registered IP ‘1xx.2x.1xx.x6’ detected）对比 本地公网IP地址不同，就会一直请求修改解析 Update needed – L: ‘1×2.2x.1xx.16’ <> R: ‘1xx.2x.1xx.x6’。
然而登录到阿里云控制台，你会发现实际上解析早已经修改成功。由于使用默认dns侦测到的是之前缓存的旧的IP地址，是错误的已注册的IP地址。所以一而再再而三重复提交给阿里云api修改请求，导致报错修改失败。但不影响第一次已经成功修改的解析，只是重复提交修改被拒绝，日志报错而已。
进入 aliyun_a 详细配置 → 计时器设定 ，如下图：保持默认设置即可
检查时间周期，10分钟，可以了，检查的周期时间没必要再短。
好了，所有设置已完成，已经完美工作了1天，很稳定。
我相信这个运行在 OpenWRT/LEDE 的阿里云脚本，会一直稳定运行下去的。
非常感谢大神级作者：sensel 的无私奉献
Nextcloud18.0.4升级到Nextcloud19.0.0与解决警告
本来不想升级这仅在内网使用的Nextcloud，因为频繁的升级真的好累，只想从Nextcloud18.0.4升级到18.0.5而已就算了，但是升级到Nextcloud18.0.5后，却出现了不可接受的BUG。没有细心去发现更多问题，就仅当前发现的BUG就无法容忍了。
正常情况下：例如我昨天创建保存了一份word文档命名为 X档案 保存，今天修改了该 X档案 中的部分内容并保存。Nextcloud 会保存并展示最新修改的版本，我也可以进入该 X档案 的详细页面查询该文档的修改记录，可以下载昨天最初创建未作修改的版本。
然而 Nextcloud18.0.5 文件版本无法显示在详细页面，文件版本与修改记录无法在网页访问，造成我们无法查看与下载昨天最初创建的那个版本。这BUG实在无法容忍。
干脆不折腾了，降级为原来的 Nextcloud18.0.4 吧。于是除了 data目录与备份 config 内的config.php 外，删除所有文件，重新上传 Nextcloud18.0.4 文件，一顿操作之后，发现这家伙无法降级，这坑不浅啊！如果要降级，只有重新安装旧版本的 Nextcloud18.0.4
算了，不降级了，升级最新版本的 Nextcloud19.0.0 。
保留 data 文件夹及内部的所有文件，备份 config 内的 config.php 文件，删除旧版本的所有文件。（最好升级前备份数据库）
上传好新版本的所有文件，如下步骤操作：
#进入nextcloud目录
[root@localhost nextcloud]# cd /var/www/html
#设置权限
[root@localhost html]# chown -R apache:apache nextcloud
[root@localhost html]# find nextcloud/ -type d -exec chmod 750 {} \;
[root@localhost html]# find nextcloud/ -type f -exec chmod 640 {} \;
#重启服务器
[root@localhost html]# systemctl restart httpd
[root@localhost html]# cd nextcloud
#执行手动升级命令，这步貌似是多余的操作
[root@localhost nextcloud]# sudo -u apache php occ upgrade
Nextcloud is already latest version升级完成。
解决 Nextcloud19.0.0 警告
习惯了，每升级一个版本，随之而来的就是要解决一堆的警告。+
1、Nextcloud19 是最后一个支持 PHP7.2 的版本。Nextcloud20 需要至少 PHP7.3。（这个不用管，有空就升级一下 PHP 吧）
2、数据库丢失了一些索引。由于给大的数据表添加索引会耗费一些时间，因此程序没有自动对其进行修复。您可以在 Nextcloud 运行时通过命令行手动执行 “occ db:add-missing-indices” 命令修复丢失的索引。索引修复后会大大提高相应表的查询速度。
在数据表 “oc_properties” 中无法找到索引 “properties_path_index”。
3、数据库缺少一些可选列。由于在大表上添加列可能会花费一些时间，因此在可以选择时不会自动添加列。通过运行 “occ db:add-missing-columns” ，可以在实例继续运行时手动添加那些缺少的列。添加列后，某些功能可能会提高响应速度或可用性。
表 “oc_comments” 中缺少可选列 “reference_id” 。
4、该实例缺失了一些推荐的 PHP 模块。为提高性能和兼容性，我们强烈建议安装它们。
gmp
解决 第2，第3，第4 个警告如下：
[root@localhost nextcloud]# sudo -u apache php occ db:add-missing-indices
Check indices of the share table.
Check indices of the filecache table.
Check indices of the twofactor_providers table.
Check indices of the login_flow_v2 table.
Check indices of the whats_new table.
Check indices of the cards table.
Check indices of the cards_properties table.
Check indices of the calendarobjects_props table.
Check indices of the schedulingobjects table.
Check indices of the oc_properties table.
Adding properties_path_index index to the oc_properties table, this can take some time...
oc_properties table updated successfully.
[root@localhost nextcloud]# sudo -u apache php occ db:add-missing-columns
Check columns of the comments table.
Adding additional reference_id column to the comments table, this can take some time...
Comments table updated successfully.
[root@localhost nextcloud]# yum install -y rh-php73-php-bcmath rh-php73-php-gmp升级至此完成。
各种搭建的环境都不同，请根据实际情况出发。
爱普生LQ-635K面板指示灯全闪烁故障
爱普生LQ-635K面板3个指示灯全闪烁
故障现象如下图：
初步怀疑主板故障，拆机后通电，准备测量电源板供电电压，发现随着指示灯的有规律闪烁，电源板有规律的发出细微的吱吱响，明显可以判断是电源板故障引起的。随后拆下电源板，发现电源板背面有一直已经电死的蟑螂，在准备清理时不小心碰触了电源板高压侧，左手被电的瞬间麻痹痛斥松手，电源板掉在地上了。
所幸的是，只摔坏了220V输入侧共模电感。
这开关电源400V滤波电容存储的电量，放电速度非常非常缓慢，所以拆下电源板时，应该非常小心。本来我已经很小心的啦，但还是不知怎么就能碰触到。电源板只是蟑螂污染了，清理修复污染后，更换共模电感，测试一切恢复正常了。
奥维地图与CAD关联点导入导出等操作与设置
首先我没有奥维地图的VIP会员，因为奥维地图VIP会员分为很多个等级，而且购买VIP不是永久的，比如购买1年时长或2年时长等。实际上VIP等级低的非常便宜，几十块1年，但是等级低的VIP对于我的应用根本没用。我需要的功能是能够导出18级卫星图，面积有时候比较大，需要的VIP等级最少是VIP5以上，有些面积大的卫星图必需VIP9才能实现。VIP9价格720元/年，感觉有点贵了。因为不是永久的VIP9，所以就不划算，因此要么不买VIP，要买就买VIP9。
后来我没有买VIP。
所以才有了自定义3个关联点，然后截屏（不要问为什么18级卫星图可以大面积截屏，你需要8K分辨率的显示器 ^_~），导入到CAD里做图，计算比例通过缩放CAD所有对象完美与奥维地图1:1的比例做图。可是…..
现在我已经忘记了怎么操作的了（时间已经过去了20多天）…….
都怪我当初没有记录下来，都怪当初没有时间记录下来，都怪当初能挤出时间拿去炒螺、煎鱼、饮B酒，却没有时间好好的做个记录，即使是简单的一个步骤记录。导致现在又得从零开始，重新琢磨其中的设置方法与操作的套路。
废话少说，进入主题 ……
登录查看完整内容
MySQL80定时备份数据库的方法与报错
MySQL5.7备份的数据库文件导入到MySQL80的时候，出现了一些警告，但我不知道这些警告什么意思，反正现在导入的数据都能正常运作。难道之前使用的数据库备份方法有问题？或是其它的原因？这需要时间与测试才能找出原因。
一、MySQL5.7定时备份数据库的方法如下：
创建定时备份脚本backup_mysql_shell.sh
#!/bin/bash
DATE=`date +%Y%m%d%H%M` #年月日时分
DATABASE=wp #数据库名称
BACKUP_PATH=/backup/mysqldata #备份文件的存放目录
#备份命令
/usr/bin/mysqldump -h 127.0.0.1 -R --opt $DATABASE | gzip > ${BACKUP_PATH}\/${DATABASE}_${DATE}.sql.gz
#备份保留5天内的文件
find ${BACKUP_PATH} -mtime +5 -name "${DATABASE}_*.sql.gz" -exec rm -f {} \;备份脚本的大概含义：
DATE 用来命名备份文件的参数，实际使用精确到小时即可。
DATABASE 需要备份的数据库的库名，不能弄错。
BACKUP_PATH 设置备份出来的文件的存放目录，需提前创建好该目录。
命令/usr/bin/mysqldump mysqldump 所在的目录
命令 -h 127.0.0.1 -h 主机名或主机IP地址
命令 -R 官方说明–routines, -R ，在输出中包括转储数据库的存储例程（过程和函数）。此选项需要全局SELECT权限。反正看不懂这参数，与权限相关的参数，决定去掉此参数测试看看。
命令 --opt 官方说明：由于该–opt选项默认情况下处于启用状态，因此您只需指定其反选项 –skip-opt即可关闭该选项。这个参数还是留着吧。
$DATABASE 需要备份的数据库
gzip > ${BACKUP_PATH}\/${DATABASE}_${DATE}.sql.gz 打包压缩存储到指定目录指定文件名。
以上的备份数据库的脚本，还需要配合数据库用户与密码，才能成功备份数据库。其中的数据库用户与密码，我们需要写在mysql配置文件 my.cnf 里面，格式如下：（用户root与root的密码）
[mysqldump]
user=root
# 有特殊字符的密码需要双引号！
password="**密码**"password=”密码”，如果有特殊字符的密码没有加上双引号，会出现
mysqldump: Got error: 1045: Access denied for user ‘root’@’localhost’ (using password: YES) when trying to connect
最后还要配合定时执行脚本的计划任务哟！
在MySQL80导入数据库文件时发出的警告：
备份数据库时使用的备份命令为：
/usr/bin/mysqldump -h 127.0.0.1 -R --opt $DATABASE | gzip > ${BACKUP_PATH}\/${DATABASE}_${DATE}.sql.gz导入数据库使用的命令为：
#选择数据库
use wp; # wp 为数据库名称
#导入数据
source /sqlbak/wp_202006200602.sql; # wp_202006200602.sql 为数据库备份文件名称数据库可以正常导入成功，但是有警告：（如下部分警告示例）
Query OK, 383 rows affected (0.00 sec)
Records: 383 Duplicates: 0 Warnings: 0
Query OK, 0 rows affected (0.01 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected, 1 warning (0.00 sec)
Query OK, 0 rows affected, 5 warnings (0.01 sec)
Query OK, 0 rows affected, 1 warning (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 221 rows affected (0.01 sec)
Records: 221 Duplicates: 0 Warnings: 0是不是由于备份时使用了 -R 的参数造成的，暂时不知道。
二、MySQL80定时备份数据库的方法
MySQL80备份数据库方法与MySQL5.7一样，但是报错如下：
mysqldump: Got error: 1045: Access denied for user ‘root’@’localhost’ (using password: YES) when trying to connect
即使再三确认root用户与root的密码已经正确填写在 my.cnf 配置文件里，却还是报错。最后发现，root用户还是没有权限备份wp数据库，这实在是大坑。（本来wp数据库就是在登录root用户然后再创建出来的，却没有备份的权限）
只有在配置文件 my.cnf 填上wp数据库的用户与密码，备份wp数据库才顺利成功。
难道这也是该数据库备份的时候使用了 -R 参数有关？不知道。
测试去掉 -R 这个备份参数，使用如下的备份参数：
#!/bin/bash
DATE=`date +%Y%m%d%H%M` #年月日时分
DATABASE=wp #数据库名称
BACKUP_PATH=/backup/mysqldata #备份文件的存放目录
#备份命令
/usr/bin/mysqldump -h 127.0.0.1 --opt $DATABASE | gzip > ${BACKUP_PATH}\/${DATABASE}_${DATE}.sql.gz
#备份保留5天内的文件
find ${BACKUP_PATH} -mtime +5 -name "${DATABASE}_*.sql.gz" -exec rm -f {} \;测试去掉 -R 这个备份参数，再次备份数据库，然后用 Notepad++ 打开备份文件，大概发现带 -R 参数的多了一行 — Dumping routines for database ‘wp’，没有详细的再去对比区别，这样对比有点SB。
然后导入到本地环境数据库测试，警告 warning 依旧存在，但好像警告数量比较少了。最后发现这些所有的 warning 全都是 Query OK, 0 rows affected（查询正常），就不去纠结了吧。
测试完毕之后，关与去不去掉 -R 这个参数还是得不到明确的答案，所以就不去纠结了，反正都能正常备份与还原数据库才是最重要的。因此我就不折腾了，继续使用带 -R 的备份参数。