发布于2019/12/07更新于2024/7/5
给某台VPS配了HE的IPv6 Tunnel Broker,现在被QoS的时候就可以用自己的了,虽然一直都有的用,但是……
之前也给WordPress提交了ticket等着人来修复通过XMLRPC发表的时间问题,看样子时有点困难?哎哎呀……
to log everything here | 死灰复燃的‘noyle’
发布于2019/12/07更新于2024/7/5
给某台VPS配了HE的IPv6 Tunnel Broker,现在被QoS的时候就可以用自己的了,虽然一直都有的用,但是……
之前也给WordPress提交了ticket等着人来修复通过XMLRPC发表的时间问题,看样子时有点困难?哎哎呀……
发布于2019/12/05更新于2024/7/5
OK,好像还是有问题,继续测试…这次确认了PHP已配置date.timezone,同时也正确设置了WordPress后台的时区选项。现在是2019年12月5日2点25分,来自WordPress的Android端。
编辑:经这条测试,确实有问题……站点接收到的时间是“2019/12/05 10:25”。手动更正。
发布于2019/12/05更新于2024/7/5
OK,继续测试…这次在填写了PHP配置里的date.timezone,同时也正确设置了WordPress后台的时区选项。现在是2019年12月5日2点8分,来自WordPress的Android端。
编辑:确实有问题……站点接收到的时间是“2019/12/05 10:07”。手动更正。
发布于2019/12/05更新于2024/7/5
OK,再测试一下,这次填写了PHP配置里的date.timezone。现在是2019年12月5日2点5分,来自WordPress的Android端。
编辑:忘记说了,发表这条之前把WordPress后台的时区设置为了UTC。显示时间是“2019/12/04 18:05”,记录下来,然后手动更正这条的发布时间。
发布于2019/12/05更新于2024/7/5
手动把前面几条时间有问题的状态的发表时间更正了。记录一下,以防以后自己看到相反的情况时,又觉得奇怪。
发布于2019/12/04更新于2024/7/5
现在是2019年12月4日16点15分,发自WordPress的Android端。对,这应用今天更新了,再试试时间。发布于2019/12/04更新于2024/7/5
现在的时间是2019年12月4日3点25分,发自WordPress的Android端。对,我觉得发表时间有问题。发布于2019/12/04更新于2024/7/5
记录一下,用certbot更新已有的Let’s Encrypt证书、并添加/删除SAN(Subject Alt Names),以CN(Common Name)为web.example.com为例,只要再次重新指定本次申请证书所有在SAN中的域名即可(以将sub1.example.com与sub2.example.com加入SAN、并将web.example.com从SAN删除为例),以下命令参考[*]:
sudo certbot certonly --cert-name web.example.com -d sub1.example.com -d sub1.example.com
程序会交互地依次询问验证方式(比如Apache/NGINX安装器、certbot自己的临时web服务器、或指定webroot等[注]),如果该域名web.example.com证书已存在,则会依次提示本次新添加进入SAN的域名与从SAN中删除的域名,然后询问并确认后,会完成证书更新。这比起直接修改域名证书申请的配置文件要安全一些[*]。
[注]:这些安装器、临时服务器及指定webroot的方式实际采用的是“HTTP-01 challenge”,需要将正在申请证书的域名开放80端口;除此之外,还有“DNS-01 challenge”;参考[1,2]。
发布于2019/12/02更新于2024/7/5
原本过了零点就有点困了,想要睡觉了。结果写了前面这文章,接着又逛了会儿论坛,就到现在这点儿了,sigh……