@qiayue #1 我也觉得这种方式比较直观。但是不知道有没有什么一次就能更新的方式，而不是这样先删再增。

软件也有个保修期吧，你这算是召回。

我曾经遇到过相同的问题，方法就是 @iamverylovely 说的，找个正常的机器把权限导出来，然后在目标机器上恢复权限。

我还记了笔记：

修复方法：复制另外一台机器的权限过来

getfacl -R / > /tmp/permission.bak 得到 / 下的所有文件和目录的权限表文件.

cd /

setfacl --restore=/tmp/permission.bak 恢复 / 下的所有文件和目录的权限

我也经常遇到，就是整个界面卡死，只能按电源键关机。一般在看视频直播的时候卡死。

我之前也是这样的情况，后来换了充电器就好了。应该是接头坏了。

满屏的繁体字密密麻麻的看着眼睛疼。

@ihwbunny 一般如果有几十几百个机器要管理，用没有 session 管理功能的终端就不好用了。一般也不会同时打开上百个连接，但是同时打开十几个连接执行同一个命令的情况还是会有的。

@Chingim #32 比如连接 100 个服务器。

似乎是早年为了兼容 IE 做的图片。

我用 10.14.6 也在看直播的时候卡死过好几次了，用的是 Edge Beta 浏览器，直播是虎牙。我比较怀疑是 Edge 的问题，因为用 Edge 以前从来没有卡死过。

keycloak +1

keycloak 功能挺全面的。

CoreDNS

@icris #297 业务代码在 try 内部很正常。区别是我们对于业务代码中失败的请求（ code 不是 0 ）这部分的理解，我是认为成功的请求应该是 HTTP 200 在前端放到 try 处理，失败的请求是 HTTP 4xx 或者 5xx 在前端放到 catch 或者全局拦截器处理，网关 /网络错误是 HTTP 5xx 放到全局拦截器处理。catch 也不是只能弹窗，try 能做的事情 catch 也能做。

说什么业务码多 http code 不够，其实 http code 是一种归纳分类，你的业务码最好放到对应的分类下面，我认为这个做法对于 rest 风格很重要。只用 200 状态码的业务最好不要宣称自己是 restful，这可能达不到及格线。

@icris 4xx 和 200 并没有区别，也是可以像 200 在 catch 里面写逻辑的，5xx 也是多种类型的，有些是 api 系统可以处理的问题，有些不是来自 api 而是来自网关。

说到底，我的观点是用 http status code 给业务 code 分组，而且这个分组还挺有用的。

我算是看明白了，这里很多人根本就不打算在前端处理 HTTP Status Code。

他们认为全部都可以放到 200 下处理，正常按 Restful 风格的应该放到 401、403 的错误也放 200 下处理。但是 5xx 错误你们怎么办呢，5xx 错误很可能就没有 HTTP Body，又去哪里看业务 code 呢。话说回来，如果你为处理 5xx 错误开了一个 if 分支了，为什么不能为 4xx 错误开一个 if 分支呢。


我的做法是这样的：

API 方面，业务状态正常的放到 HTTP 200 状态码下返回，直接返回数据，不包一层；业务状态异常的放到 HTTP 4xx 状态码下返回，使用固定的数据结构返回，固定的结构包含 code、message 等字段；能处理的 HTTP 5xx 状态一般使用和 4xx 一样的固定结构返回。


前端方面，收到数据之后线判断 HTTP 状态码，如果是 200，就一切正常处理；如果是 4xx 错误，再根据返回的业务 code 处理，或者直接显示 message，或者根据业务 code 执行预定义逻辑；如果是 5xx 错误，可以尝试读取 HTTP Body 了，如果读取到数据了，就和 4xx 错误一样处理，如果没有读取到数据，就显示默认错误。