客户端软件在建立 SSL 连接的时候需要验证对方证书是否在“我认可的”Root CA 链下。这个 Root CA 的列表是储存在本机系统里某个地方的。如果你用的是 Linux 发行版们打包好的软件，通常会改过代码或者编译选项，指定从一个系统默认位置去读。但如果是第三方或者自己编译的，可能软件上游默认并不会去读发行版设置的默认位置，那么 Root CA 列表可能会过时或者缺失。

可以试试这段里提到的 REQUESTS_CA_BUNDLE / CURL_CA_BUNDLE 环境变量 https://requests.readthedocs.io/en/latest/user/advanced/#ssl-cert-verification

把它指到发行版默认的位置去。Arch 我不清楚，deb 系是 /etc/ssl/certs/ca-certificates.crt ，你找找看 Arch 里对应的位置试试看。

这不叫技术好。只是喜欢、好奇而已，甚至可能只是自以为喜欢、好奇。“好”是看结果而不是动机的。

给你举一个技术好的例子：

## Linus 亲手帮英特尔优化 LAM 代码

去年年底英特尔将 LAM （ Linear Address Masking：线性地址掩码） 功能提交到 Linux 6.2 的合并窗口，但该功能受到 Linus 的批评并拒绝合并。在经历了一段时间的代码改进后，Linus 终于同意将 LAM 代码合并到 Linux 6.4 窗口。

但 Linus 似乎仍对英特尔工程师提交的代码不太满意，在合并了 LAM 代码后，先是写了一个使 access_ok () 独立于 LAM 的新补丁，而后又亲手写了多个补丁对 LAM 代码进行了优化。

在最新提交的 LAM 优化补丁中，Linus 解释了自己的动机：

> 我对此版本中的 LAM （“线性地址掩码”）的 “access_ok ()” 的完成方式感到很不爽，而且它实际上也有一些小 Bug ，所以我动手清理了代码。

改动主要集中在以下几方面：

* 使用 __user 指针的符号位而不是屏蔽地址，并根据 TASK_SIZE 范围检查它。 get/put_user () 端做了这部分，但是 'access_ok ()' 做了天真的 “掩码和范围检查”，它不仅生成多余的代码，还意味着 __access_ok 本身的任务做得不好，copy_from_user_nmi () 没有得到正确的检查。
* 将所有 64 位代码仅移动到 64 位版本的头文件中，这样就不会污染共享的 x86 代码，也不会误导用户 LAM 可以在 32 位环境中工作。
* 修复地址掩码中的 Bug （这不重要，只是完全删除了错误的代码）。
* 几个简单的清理，并添加了关于 access_ok () 规则的注释。

Linus 重新编写了约一百行代码来清理 LAM ，这意味着如果测试没问题， 就可以在 Linux 6.4 中顺利启用 LAM 功能。不过这次 Linus 竟然亲自动手为英特尔工程师修改 “有瑕疵的代码”，这种情况相当少见。

除了第三个 System Interpreter 不建议选之外，其它都差不多。不过你既然用 conda 装的那就先 conda 吧。

都在跟你说数据库端口不要对公网开放，你非要坚持说数据库端口不放公网你就没法维护……

别忘了操作系统组件的安全更新。

以上都是 fat jar 的方法。还可以 build 成 war ，用传统的 tomcat 方法启动。

只听田七嘶声道：“李寻欢，你好长的气”

连简称或英文名都不是，只是有关联度……这也算公司域名？你想啥呢？任天堂和迪斯尼都不会这么碰瓷吧。

维护一堆公网可访问系统的各自安全性，成本远大于维护一个访问接入服务的安全性。

如果你们 5 个人够团结，就坚定地一起拍桌子走人，让他们高贵的“研发”王子们自己分化出人做运维去

建议不做。建邮件服务是一项专门且在当代普通互联网运维人员中几乎失传的技能。更不要说很可能连普通运维技能都没有的你了。

@ianEros 我以前有个同事把 Linux 的 libc 上传到远程服务器覆盖了 Solaris 的 libc……

我对 vultr 最大的怨念是登录时的 captcha 字形潦草，又爱用易混淆相近字符，试个三五次错都是少的

你不会真的以为内卷只是单个热门行业吧。

1. 市场份额为 others 的不配挨骂
2. 虽然贵但平替太多的不配挨骂

互联网的主流协议，大多都是底层需要效率和精确控制的用 binary ，上层易于理解和观察的用 text ，有特殊场景需要违背时才做反例。

OP 你猜有几个人能看得懂你在说什么