一、背景
上班后，需要登录集群做些优化。与往常一样，打开页面，开始使用github.com账号登录。结果无效。
这个集群是2016年建成的，与kubernetes同时期的容器平台，只是团队选择了dcos，没有选择k8s。
dcos mesos集群采用oauth0.com的登录服务器，可以通过google、github、microsoft的账号登录，后台通过email对比验证。一旦无法验证，将丢失对集群的管理。当然，只是无法管理，容器还是在跑着。
二、过程
2.1 重启master节点
依旧无效,而且，重启后，需要等好一会，直到systemctl -l | grep dcos的服务都已经起来了。
2.2 查看操作系统日志
通过日志定位到服务dcos-auth
2.3 查看dcos-oauth服务日志
该服务与dcos.auth0.com通信异常。
2.4 使用curl验证
依旧无效。可以ping，可以访问80，但是无法访问443。
2.5 使用us的vps测试正常
2.6 检查dcos-oauth运行状态
好在dcos-oauth等服务不是使用的容器，可以直接在虚拟机里面配置hosts指向us vps，然后us vps使用rinetd跳转到auth0.com服务。
2.7 部署实现
三、总结
这种hosts+rinetd方案可行，但是有点消耗资源，rinetd服务所在机器的443端口是废了。
还有没有其他方案呢。
四、使用自建证书+反向代理
4.1 生成根证书
openssl genrsa -out myCA.key 2048
4.2 使用私钥创建根证书（自签名）
openssl req -x509 -new -nodes -key myCA.key -sha256 -days 1024 -out myCA.pem
4.3 为你的域名创建证书签名请求（CSR）
openssl genrsa -out dcos.auth0.com.key 2048
4.4 创建一个证书请求
openssl req -new -key dcos.auth0.com.key -out dcos.auth0.com.csr
4.5 使用你的根CA签发域名证书
（1）创建一个dcos.auth0.com.ext来定义证书的使用
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = dcos.auth0.com
DNS.2 = *.auth0.com
DNS.3 = auth0.com
（2）使用你的CA和CSR来签发证书
openssl x509 -req -in dcos.auth0.com.csr -CA myCA.pem -CAkey myCA.key -CAcreateserial -out dcos.auth0.com.crt -days 500 -sha256 -extfile dcos.auth0.com.ext
（3）最终获得的文件
myCA.key：你的根CA的私钥。
myCA.pem：你的根CA证书。
dcos.auth0.com.key：你的域名的私钥。
dcos.auth0.csr：你的域名的证书签名请求。
dcos.auth0.crt：你的域名的由你自己的CA签发的证书。
你可以在服务器配置中使用dcos.auth0.com.key（私钥）和dcos.auth0.com.crt（签发的证书）来启用HTTPS。注意，因为这个CA不是一个公认的权威机构，用户首次访问使用这个证书的网站时，他们的浏览器可能会显示一个警告。你可以通过将你的根CA证书（myCA.pem）导入到用户的浏览器来解决这个问题，以避免警告信息，但这通常只适用于内部网络或测试环境。
4.6 部署部署到WEB服务器
在hk的bt面板，部署dcos.auth0.com站点，配置刚刚生成的相关证书。
4.7 验证
（1）验证的时候，虽然curl通过，但是dcos-oauth服务访问的时候，还是会报错
（2）查看dcos-oauth服务程序配置
[root@localhost ~]# systemctl status dcos-oauth
● dcos-oauth.service - DC/OS Authentication (OAuth): authenticates DC/OS users using OpenID Connect and Auth0
Loaded: loaded (/opt/mesosphere/packages/dcos-oauth--0079529da183c0f23a06d2b069721b6fa6cc7b52/dcos.target.wants_master/dcos-oauth.service; enabled; vendor preset: disabled)
Active: active (running) since Fri 2024-03-08 09:41:49 CST; 3h 29min ago
Process: 5787 ExecStartPre=/opt/mesosphere/bin/bootstrap dcos-oauth (code=exited, status=0/SUCCESS)
Main PID: 5851 (dcos-oauth)
Memory: 16.3M
CGroup: /system.slice/dcos-oauth.service
└─5851 /opt/mesosphere/bin/dcos-oauth serve --addr=127.0.0.1:8101 --zk-addr=127....
（3）果然，dcos自带了jre，
cd /opt/mesosphere/packages/java--cd5e921ce66b0d3303883c06d73a657314044304/usr/java/jre/bin
./java -version
（4）导入证书到jre的cacerts文件
cd /opt/mesosphere/packages/java--cd5e921ce66b0d3303883c06d73a657314044304/usr/java/jre/lib/security/
../../bin/keytool -import -trustcacerts -alias myCA -file myCA.pem -keystore cacerts -storepass changeit
systemctl restart dcos-oauth
（5）可以登录了
（6）日志显示正常
（7）画张拓扑
五、后记
（1）这次行动将之前准备的ssl证书、jdk相关的知识全都用上了。
（2）自签名证书对于对抗互联网中的一些异常服务还是有效果的。对于docker容器，github这种，如果我们可以采用自签名证书的方式，将docker.io和github.com相关的域名全都解析到我们的服务器，然后本地导入我们的自建CA证书，就可以提升使用效果了。
（3）如果加上自建DNS，将这些域名解析到我们自己的服务器，就更好了。
（4）如果加上VPN，分配给终端自己的DNS服务器，效果也会进一步提升。
（5）最后，增加了uptime+kuma实现对oauth0.com的监控。等待是否可以恢复正常。
追加
当时后来又加入了uptime-kuma针对auth0.com的监控，发现时断时续。
