一台ubuntu的主板的电源模块故障了。因为硬盘内的资料和环境重新部署太繁琐了，取巧想把硬盘挪到另一台机器上继续用。

以上是事情的背景。

买不到同型号的准系统了，买了个同系的接近的型号（还是用相代的cpu和ram）可以把旧机器上的零件拆过去用。

一切都顺利，本地操作时系统能启用。
直到尝试联网和SSH远程管理的时候发现没网。网线插上了后面水晶头的两个灯，绿灯常亮，橙色灯有规律的每秒短亮一次。

跟着网上查到的对 eth0 一通操作，无用

尝试重启网络服务，无效

netplan --debug apply

报 enp3s0 not found ，大概猜到它的意思，说这个网络设备（网卡）没找到

列出网络设备

ip link

有 lo 和 eno1 , 前者忽略，后者有 MAC ADDRESS，我猜就是网卡了。

把/etc/netplan/ 里的 yaml 配置文件 的 enp3s0 改成了 eno1 ，在重启网络。

成了！

总结

正常安装的ubuntu不会遇到这样的情况，因为在安装的时候会自动生成正确名称默认的 netplan 配置文件
这次是更换了硬件，所以设备名称变动了配置没有赋给新网卡，所以导致配置无效。

项目有存储图像、需要。单靠云主机的弱鸡带宽肯定是撑不住的，所以考虑用对象储存服务。主打弹性成本带宽也管饱，还有一些额外的好处，下文説。下文流水账记录快速部署到可用的状态。其实官方文档已经有足够的信息只是版本有点杂，我需要多出相互比对测试了一番。所以下面这个也可以说是速通教程。

- 阅读剩余部分 -

前端看没有报错，但file_get_contents()返回了 null， 看服务端日志才发现这个提示。

以前也遇到过，备忘一下。当然改用 curl 也是不错的选择。

//$json_token = file_get_contents($url_accesstoken); //ssl报错
//修改方案，构造一个context参数，不验证ssl
$context = stream_context_create([
    'ssl' => [
        'verify_peer'      => false,
        'verify_peer_name' => false
        ]
]);
$json_token = file_get_contents($url_accesstoken,false,$context); //忽略报错，正确返回内容

参考来源：https://qiita.com/mindwood/items/fd23ddcb94fb4eefa99c

两个原因，一是没养成每天写日记的习惯。二来怕立FLAG，对什么鱼笔墨浓重一点会被我写死了。

最近也确实忙，忙到视力下降眼睛没法聚焦了。以后偶尔想起来了或者真有什么感悟了不定期记录一下吧。

关于水草虾

• 我依然说不出它和黑壳虾的区别。
• 确实不攻击其他鱼，包括刚出生的小鱼苗。但是，如果鱼有病有伤就不好说了，虾总会试探性地骚扰伤口。直到鱼力竭不再躲避反抗之后就会被虾群生吞活剥。

• 得注意控制一下密度，一开始打算小米鱼缸下50尾。手一抖往里扔了至少80，可能更多没法数清楚。

  • 好处是，除藻、清理残余饲料，死鱼效率极高。缸底基本保持着整洁没有任何肉眼可见的残渣粪便。
  • 缺点是，密度太高会对其他鱼造成滋扰让鱼始终保持应激..容易累死鱼。食物不足的时候它们啃噬一切活物，包括浮萍和水草。
• 总结下来，给我的印象水草虾像秃鹫和蟑螂，不会直接威胁其他物种生命，但密度不能高。目前保持在20只左右正好。

关于泰国斗鱼

现在缸里放了8条母鱼，有了之前的经验。没有直接丢入缸里。过温的时间稍微延长，让它们隔着塑料袋互相认识，所谓对鱼。
入缸之后果然极少激烈的打斗，有追逐但没有伤亡。

不同鱼性格区别真的大。据观察，刚入缸的一天之后。体格较大的会显露出优势会追逐驱离其他斗鱼，幸好最大那条并不特别凶，只追不咬。

也有一条颜色像牛仔裤的，性格孤僻喜欢一条鱼躲在水草里面，遇到其他鱼经过会有很强的攻击性。甚至让我有点怀疑是不是判断错它的性别。

不用担心小体格的鱼会有心理健康的问题，鱼缸里的鄙视链是大鱼揍小鱼，小鱼揍虾米。斗鱼战斗力明显比孔雀鱼强，目击到有虾被斗鱼啄死，吃剩的虾头还被斗鱼叼着游。不过情况不严重，斗鱼不会很针对性地狩猎虾。食物链底层是这样的。。。狭缝中生存吧。

斗鱼是真的很喜欢榄仁叶，喜欢到当被子当抱枕的程度。

还有3条公鱼在住单间，情况稳定。但最近没有时间给它们相亲和配对。等忙完这阵子再说。

原来在缸里的孔雀鱼和斗鱼

孔雀生了两窝，但折损了一大半，多数是体质虚弱的时候被虾吃了。斗鱼也被过密度的虾惊吓到伤了，虽然捞出来静养，但还是回天乏术。没了。剩下的孔雀鱼和鱼苗还有半数的虾我捞出来放到阳台暂养水草的周转箱了。周转箱的水是空调的冷凝水活水..基本可以算免维护状态。能不能活...通常我不去干预的东西可能活得比我鞍前马后照顾的要好，但愿吧。

因为阿里云和腾讯云调整了免费SSL证书政策从1年有效期改成90日。寻找替代方案，看到cloudflare提供15年的证书，但条件是要使用它们家的DNS/CDN服务。验证是在dns过程中接管的。

跟着别人分享的教程一步步操作下来，证书是申请好配置到位了。同时也出现了标题的问题。请求PHP的响应正确，但如果是静态资源 例如加载 js html css png之类浏览器就会报错 301 提示重定向次数过多。

网上搜了一圈基本在说的是 http强制绑定https，当用户访问http时自动重定向到https的情况，设置在nginx conf 的http的 server{} 部分。这显然和我的项目情况不同，我只配置了443 ssl服务。我并不需要约束http。也没有往nginx的方向去想。

以为是cloudflare这种形式的ssl的问题，一直在CF的设置上去研究。

最后实在被搞烦了...决定弃坑，部署个脚本在服务端每90日自动续签ssl。

发现还是一样的问题，php正常打开，html 提示重定向次数过多

脑子被轰了...回头检查 nginx 的 vhost 配置文件。在 443 server{} 的最底部发现这段东西

location / {
    return 301 https://$host$request_uri;
}

WTF?

搞什么飞机... 为什么lnmp会生成这样奇怪的配置。已经是443了还自己跳转给自己

注释之后...问题消除