尧图网站建设 
Memos 启动日志提示旧版 IdP 数据库存储副本仍在如何完成清理【免费下载链接】memosOpen-source, self-hosted note-taking tool built for quick capture. Markdown-native, lightweight, and fully yours.项目地址: https://gitcode.com/GitHub_Trending/me/memos如果你在 Memos 的启动日志中看到如下警告deployment identity provider shadows a stored provider; the stored configuration remains in the database日志里会附带uid字段指向被遮蔽shadowed的那个数据库存储的 IdP。这条警告说明/etc/secrets下的部署配置 IdP 文件与数据库idp表中一条旧记录使用了相同的uid运行时以文件为准但数据库里仍保留着旧配置副本——包括 client secret。它的来源是版本历史使用原始memos-idp-*.jsonbootstrap 的旧版本会在数据库迁移时把文件中的 IdP 配置含 client secret复制进idp表。新版部署配置加载器/etc/secrets下的memos-idp-label.json文件无法可靠区分这类自动复制的行和通过 UI 创建的 IdP因此不会自动删除或清洗它们只会打日志提醒。这条警告对应 store/deployment_config.go 中的warnShadowedStoredIdentityProviders。为什么必须手动清理在清理完成之前旧的存储 IdP 及其 secret 一直留在数据库里如果某个时刻 IdP 文件被移走被遮蔽的旧存储配置会重新变成生效配置例如回滚或误操作时新加载器的不落盘保证只对新版本生效不会清除早期版本写入的 secret。所以这条警告不应被忽略需要按下面流程一次性处理。清理前的准备确认出现警告的uid对应的就是/etc/secrets中某个memos-idp-label.json文件里声明的uid资源身份以消息内的uid为准文件名 label 只是描述性的改名不影响身份。用户身份关联使用的是 provideruid作为稳定值因此清理存储副本不会动user_identity的关联只要保留同一个uid的文件即可。清理步骤文档给出的清理流程是四步见 docs/configuration-provisioning.md 的 Transition from the database-writing bootstrap 一节备份数据库并确保管理员密码登录可用。第 2 步之后存储副本将重新出现在界面上删除前万一误操作密码登录是兜底路径。临时移除该 IdP 文件并重启 Memos使存储的 provider 不再被遮蔽。部署配置只在进程启动时读取一次文件变更后必须重启才生效。重启后启动日志中会打印loaded deployment configuration及匹配到的 identityProviders 数量可借此确认文件确实未被加载。通过管理员 UI 或 API 删除或更新那条存储的 provider或执行等效的离线数据库维护。此时该 provider 已不再由部署文件管理UI/API 中的删除操作会正常执行。恢复该文件并再次重启 Memos让文件配置的 IdP 重新成为生效配置。注意顺序在文件存在期间通过 API 更新或删除该uid的 IdP 会被拒绝返回codes.FailedPreconditionidp_service.go 中的守卫逻辑这是部署配置所有权的正常保护不是故障。验证清理结果按文档可核对以下几点重启后启动日志中不再出现deployment identity provider shadows a stored provider; the stored configuration remains in the database警告loaded deployment configuration日志中 identityProviders 计数与/etc/secrets中memos-idp-*.json文件数一致确认文件本身仍被正常加载管理员 UI 或 API 列出的 IdP 中该uid只对应文件来源的配置数据库里不再有同uid的存储副本第 3 步删除后即是。限制与相关提示如果 IdP 文件名不是小写 kebab 格式早期 bootstrap 接受的memos-idp-*.json命名仍兼容启动时会额外打印一条 deprecation 警告提示改名为小写 kebab 格式。这与存储副本警告是两回事但常在同一台从旧版升级的实例上同时出现可以一并处理。SSO-only 部署挂载了 IdP 文件和disallowPasswordAuth为 true 的memos-instance-setting-general.json在执行第 2 步临时移除 IdP 文件时存储副本仍在数据库中生效配置里仍有该 IdP不会触发禁用密码登录但无 IdP的启动校验失败恢复文件后行为回到原状。新加载器从不写入idp表文件 IdP 没有数据库 ID也永远不应被传给驱动层的更新或删除操作这正是文件存在时删除返回 FailedPrecondition的底层原因。完成上述四步并确认日志干净后这条启动警告就不会再出现此后对 IdP 配置的唯一事实来源就是/etc/secrets下的文件修改配置需要重新部署文件并重启进程。【免费下载链接】memosOpen-source, self-hosted note-taking tool built for quick capture. Markdown-native, lightweight, and fully yours.项目地址: https://gitcode.com/GitHub_Trending/me/memos创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Memos 启动日志提示旧版 IdP 数据库存储副本仍在，如何完成清理？
Memos 启动日志提示旧版 IdP 数据库存储副本仍在如何完成清理【免费下载链接】memosOpen-source, self-hosted note-taking tool built for quick capture. Markdown-native, lightweight, and fully yours.项目地址: https://gitcode.com/GitHub_Trending/me/memos如果你在 Memos 的启动日志中看到如下警告deployment identity provider shadows a stored provider; the stored configuration remains in the database日志里会附带uid字段指向被遮蔽shadowed的那个数据库存储的 IdP。这条警告说明/etc/secrets下的部署配置 IdP 文件与数据库idp表中一条旧记录使用了相同的uid运行时以文件为准但数据库里仍保留着旧配置副本——包括 client secret。它的来源是版本历史使用原始memos-idp-*.jsonbootstrap 的旧版本会在数据库迁移时把文件中的 IdP 配置含 client secret复制进idp表。新版部署配置加载器/etc/secrets下的memos-idp-label.json文件无法可靠区分这类自动复制的行和通过 UI 创建的 IdP因此不会自动删除或清洗它们只会打日志提醒。这条警告对应 store/deployment_config.go 中的warnShadowedStoredIdentityProviders。为什么必须手动清理在清理完成之前旧的存储 IdP 及其 secret 一直留在数据库里如果某个时刻 IdP 文件被移走被遮蔽的旧存储配置会重新变成生效配置例如回滚或误操作时新加载器的不落盘保证只对新版本生效不会清除早期版本写入的 secret。所以这条警告不应被忽略需要按下面流程一次性处理。清理前的准备确认出现警告的uid对应的就是/etc/secrets中某个memos-idp-label.json文件里声明的uid资源身份以消息内的uid为准文件名 label 只是描述性的改名不影响身份。用户身份关联使用的是 provideruid作为稳定值因此清理存储副本不会动user_identity的关联只要保留同一个uid的文件即可。清理步骤文档给出的清理流程是四步见 docs/configuration-provisioning.md 的 Transition from the database-writing bootstrap 一节备份数据库并确保管理员密码登录可用。第 2 步之后存储副本将重新出现在界面上删除前万一误操作密码登录是兜底路径。临时移除该 IdP 文件并重启 Memos使存储的 provider 不再被遮蔽。部署配置只在进程启动时读取一次文件变更后必须重启才生效。重启后启动日志中会打印loaded deployment configuration及匹配到的 identityProviders 数量可借此确认文件确实未被加载。通过管理员 UI 或 API 删除或更新那条存储的 provider或执行等效的离线数据库维护。此时该 provider 已不再由部署文件管理UI/API 中的删除操作会正常执行。恢复该文件并再次重启 Memos让文件配置的 IdP 重新成为生效配置。注意顺序在文件存在期间通过 API 更新或删除该uid的 IdP 会被拒绝返回codes.FailedPreconditionidp_service.go 中的守卫逻辑这是部署配置所有权的正常保护不是故障。验证清理结果按文档可核对以下几点重启后启动日志中不再出现deployment identity provider shadows a stored provider; the stored configuration remains in the database警告loaded deployment configuration日志中 identityProviders 计数与/etc/secrets中memos-idp-*.json文件数一致确认文件本身仍被正常加载管理员 UI 或 API 列出的 IdP 中该uid只对应文件来源的配置数据库里不再有同uid的存储副本第 3 步删除后即是。限制与相关提示如果 IdP 文件名不是小写 kebab 格式早期 bootstrap 接受的memos-idp-*.json命名仍兼容启动时会额外打印一条 deprecation 警告提示改名为小写 kebab 格式。这与存储副本警告是两回事但常在同一台从旧版升级的实例上同时出现可以一并处理。SSO-only 部署挂载了 IdP 文件和disallowPasswordAuth为 true 的memos-instance-setting-general.json在执行第 2 步临时移除 IdP 文件时存储副本仍在数据库中生效配置里仍有该 IdP不会触发禁用密码登录但无 IdP的启动校验失败恢复文件后行为回到原状。新加载器从不写入idp表文件 IdP 没有数据库 ID也永远不应被传给驱动层的更新或删除操作这正是文件存在时删除返回 FailedPrecondition的底层原因。完成上述四步并确认日志干净后这条启动警告就不会再出现此后对 IdP 配置的唯一事实来源就是/etc/secrets下的文件修改配置需要重新部署文件并重启进程。【免费下载链接】memosOpen-source, self-hosted note-taking tool built for quick capture. Markdown-native, lightweight, and fully yours.项目地址: https://gitcode.com/GitHub_Trending/me/memos创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考