🐛 一些问题。。。 | [Bug] 备份数据库恢复之后同步到LDAP各种报错。。。
ixiaoyi93 opened this issue · comments
您使用的版本？ | Your usage version?
前端镜像版本：
dockerproxy.com/eryajf/go-ldap-admin-ui:2023-11-12_05-57
后端镜像版本：
dockerproxy.com/eryajf/go-ldap-admin-server:2023-11-15_15-33
您使用的场景？ | Your usage scenarios?
模拟数据以外删除进行恢复的操作。
您做了什么操作？ | What did you do?
根据文档 如何备份。现在已经将MySQL备份数据恢复到新的数据库，在Web页面也能够查看到相应的数据，在【人员管理】-【用户管理】-点击用户右侧“同步”按钮，提示如下问题：
向Ldap添加用户到分组关系失败：LDAP Result Code 20 "Attribute Or Value Exists": modify/add: uniqueMember: value #0 already exists
如下图所示：
通过去LDAP查看用户，确实又同步过去了（点击同步又能同步过去），但是前端页面依旧报错且同步按钮依旧存在。如果我同时选中多个需要同步用户，则会失败。目前测试，只能单个用户进行同步，如果恢复的用户较多，官方文档的备份和恢复是否需要待完善。
您遇到了什么问题？ | What are your problems?
1.不能同时选择多个用户进行同步到LDAP；
2.点击同步MySQL到LDAP，用户虽然同步到LDAP，但是前端页面依旧返回报错信息；
您期望的结果是怎样的？ | What is your expected outcome?
同步从MySQL恢复用户，能够多选且能够正常同步到，前端无报错。
您好 @ixiaoyi93👋，我已收到您的反馈，我将安排时间考虑您提交的信息并进行回复。-- 这条信息是由自动回复的机器人发出的。
Hello @ixiaoyi93. I have received your feedback, and I will arrange time to consider the information you submitted and reply. -- This message is sent by an automatic reply robot.
同步的时候，先同步分组，再同步用户试试
同步的时候，先同步分组，再同步用户试试
嗯，有这个操作。组的信息也同步到了LDAP当中，还有需要再说明一下的就是，我是从老版本的go-ldap-admin，恢复到以上的新版本（不知道是否有影响）。
我大概找到问题了，待我验证一下。
@eryajf 找到问题了。我从MySQL备份过来的数据，同步到LDAP之后，我发现某些用户关联到分组。也就是某些分组已经包含部分用户，再同步的时候就会报错。如下：
目前解决办法就是先删除LDAP分组内关联的用户，然后在同步即可。有什么办法避免这个问题吗？
某些分组已经包含部分用户
这句我没太理解，这些分组包含的用户是怎么过去的呢，是先同步分组的时候，用户跟着过去了吗，还是什么
找到这块儿的原因，应该就能规避这个问题
这句我没太理解，这些分组包含的用户是怎么过去的呢，是先同步分组的时候，用户跟着过去了吗，还是什么
应该就是原分组内就有这些成员信息了，通过备份恢复的时候也把这个恢复了。我通过在备份端的 go-ldap-admin的【分组管理】-【分组成员】是包含成员信息的，在恢复到新部署的go-ldap-admin时候也把这个恢复了。
明白了，我回头再看看这块儿的逻辑，应该是同步分组和同步用户的时候，这块儿逻辑有点重叠，晚些时候我看看兼容一下这块儿
明白了，我回头再看看这块儿的逻辑，应该是同步分组和同步用户的时候，这块儿逻辑有点重叠，晚些时候我看看兼容一下这块儿
还有2个问题：
- 恢复完成以后，切换用户登录提示密码不对；
- 支持原地升级吗；
就目前的情况来看，升级或者其他问题导致数据丢失，恢复起来还是相对麻烦的。
密码应该是没问题的，难道你备份的数据，和恢复的数据，使用的后端不是同一个版本吗？
升级的话，目前来说，不是很熟悉里边的变更，且版本跨度比较大的情况下，风险有点大。
坦白来讲，这个项目在版本升级方面做的工作的确不够。
密码应该是没问题的，难道你备份的数据，和恢复的数据，使用的后端不是同一个版本吗？
升级的话，目前来说，不是很熟悉里边的变更，且版本跨度比较大的情况下，风险有点大。
坦白来讲，这个项目在版本升级方面做的工作的确不够。
我知道啥原因了，我是 docker-compose 拉起的服务，而你构建的镜像秘钥对和上一次不一样了，导致认证失败了。
折腾了2天，做个总结吧。本身打算做备份进行逐步升级，由于通过备份数据库进行恢复时失败。那就转换思路，由于我是通过docker-compose拉起的服务，改为备份docker-compose挂载数据目录以及其他配置文件等，经过验证是可以恢复的（为了保险期间，依然不要忘记对mysql的备份哟）。
既然解决了恢复的问题，接下来就是升级。我采用的就是原地升级，替换容器镜像。升级的过程中，唯一的坑就是与上一次的容器内的密钥对文件不匹配，导致升级完成之后用户无法登陆（查看go-ldap-admin-server会有日志提示）。这个没有好的办法，我的办法是将原来容器内的密钥对拷贝下来，自己重新构建容器镜像（包括前端和后端的两个容器，关于密钥对认真看官文，有说明）。接下来就是替换配置文件为当前最新版本的config.yaml内容，然后替换最新的镜像。目前验证是没有问题，下周准备升级生产......直接干。
折腾了2天，做个总结吧。本身打算做备份进行逐步升级，由于通过备份数据库进行恢复时失败。那就转换思路，由于我是通过
docker-compose拉起的服务，改为备份docker-compose挂载数据目录以及其他配置文件等，经过验证是可以恢复的（为了保险期间，依然不要忘记对mysql的备份哟）。既然解决了恢复的问题，接下来就是升级。我采用的就是原地升级，替换容器镜像。升级的过程中，唯一的坑就是与上一次的容器内的密钥对文件不匹配，导致升级完成之后用户无法登陆（查看go-ldap-admin-server会有日志提示）。这个没有好的办法，我的办法是将原来容器内的密钥对拷贝下来，自己重新构建容器镜像（包括前端和后端的两个容器，关于密钥对认真看官文，有说明）。接下来就是替换配置文件为当前最新版本的
config.yaml内容，然后替换最新的镜像。目前验证是没有问题，下周准备升级生产......直接干。
这里不太对劲儿，秘钥对在我这边，尽管是不同的版本，也是一样的，这块儿没有做改变。
是不是你之前部署的时候，这块儿用的自定义生成的，而没有使用项目里边默认的呢，如果是默认的，那么不同版本之间的认证文件，是一样的。
折腾了2天，做个总结吧。本身打算做备份进行逐步升级，由于通过备份数据库进行恢复时失败。那就转换思路，由于我是通过
docker-compose拉起的服务，改为备份docker-compose挂载数据目录以及其他配置文件等，经过验证是可以恢复的（为了保险期间，依然不要忘记对mysql的备份哟）。
既然解决了恢复的问题，接下来就是升级。我采用的就是原地升级，替换容器镜像。升级的过程中，唯一的坑就是与上一次的容器内的密钥对文件不匹配，导致升级完成之后用户无法登陆（查看go-ldap-admin-server会有日志提示）。这个没有好的办法，我的办法是将原来容器内的密钥对拷贝下来，自己重新构建容器镜像（包括前端和后端的两个容器，关于密钥对认真看官文，有说明）。接下来就是替换配置文件为当前最新版本的config.yaml内容，然后替换最新的镜像。目前验证是没有问题，下周准备升级生产......直接干。这里不太对劲儿，秘钥对在我这边，尽管是不同的版本，也是一样的，这块儿没有做改变。
是不是你之前部署的时候，这块儿用的自定义生成的，而没有使用项目里边默认的呢，如果是默认的，那么不同版本之间的认证文件，是一样的。
有可能，自定义过证书吧，时间长了，我也忘记了。当做经验分享给其他人，遇到类似问题有个思路，感谢作者长期共享（可以关闭这个ISSUE）。