一台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

因为阿里云和腾讯云调整了免费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了还自己跳转给自己

注释之后...问题消除

项目中用到微信支付，但公众号上已有一个第三方的项目配置过v2版，报文用XML格式的那个旧的支付密钥。没找到接口维护人拿不到旧密钥。

为了不影响已有产品，改写V3接口。本觉得V3用JSON应该是收到拿来，数据方便编辑维护多了。没想到还是埋着不少坑。

腾讯官方的技术支持已经不指望也不想吐槽了，概括四字：依托答辩

没多想，找到文档按部就班开始写了

https://pay.weixin.qq.com/wiki/doc/apiv3/apis/chapter3_1_1.shtml

一开始还挺顺的，觉得接口参数还简化了不少。直到测试提交，下单生成 prepay_id

大意了，来活了。

报错。

{"code":"INVALID_REQUEST","message":"Http头缺少Accept或User-Agent"}

哦，网上搜一下，行~按你要求构造个header补上呗
curl请求的header，定义上

$headers = [
        'Accept: application/json',
        'Content-Type: application/json',
        ];  
curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);

还是错！

{"code":"SIGN_ERROR","message":"Http头Authorization值格式错误，请参考《微信支付商户REST API签名规则》"}

牛B！都是对header的要求，就不能说明放一块，错误提示放一起，非得像有关部门一样踢一脚说半句。

随即发现这 Authorization 坑有点深.. 过程略过.. 大概知道就是把 V2的签名部分挪到了header里
构造数据、签名、加密、编码一通操作下来
报错

{
  "code":"SIGN_ERROR",
  "detail":{
    "detail":{
      "issue":"sign not match"
    },
    "field":"signature",
    ...
  "message":"Authorization不合法"}

忽略掉过程 N个小时 各种无意义的试错

官方文档牛啤！给的演示代码省略了那么多关键步骤！让开发者自己脑补和发掘隐藏BUG！

要自己解决证书文件换行问题；

openssl_sign(): supplied key param cannot be coerced into a private key

要在文档角落找到获得 serial_no 的方法；
要自己猜接口的数据长度单位是字还是字节；

卡在最后一个错误节点，终于错误提示不在变动，仅仅是告知

{"code":"SIGN_ERROR","detail":{"detail":{"issue":"sign not match"} ..."message":"签名错误，请检查后再试"}

像玩悬赏解谜游戏一样，找到隐藏的链接 而且我们还提供签名/验签/加密/解密工具（点击下载）
验证自己生成的签名和用工具验证的签名，我™直接傻了，没有不同啊？！

好家伙，卡在那发呆...又回去检查每个步骤，逐行逐字的看。甚至声明了顺序无关的地方都处女座一样把参数按顺序重排，还是错，直到我看见..

又看了看自己的签名数据

我把 post 改成大写 POST 试试...

我草你大爷的！！！大写这么重要的事情怎么不早说？！