2016-06-26 22:48 GMT-05:00 Justin Wong <[email protected]>: > > On Mon, Jun 27, 2016, at 11:39, Wang Kang wrote: > > > > > > On Mon, 27 Jun 2016, Justin Wong wrote: > > > > >> 引入accounts9的话，能和github对接吗？（我貌似看到过是可以的?) > > > > > > 什么叫「和github对接」？ > > > > 因为现在在github.com/tuna组织下，已经有一些账号了。 > > 如果再搞一套基于accounts9的话，两边账号要不要互通？ > > > > 我记得accounts9是可以Oauth的，或许可以开放使用github账号登录accounts9.tuna的功能？ > > Oauth 注册分分钟实现了吧…… > > > > > 或者就不要github.com/tuna的账号体系...? > > > > > DNS 放 LDAP 的核心意义请 @xiaq 说明 > > > 我的感觉是当年所有数据都存在 LDAP 里，我们在把 LDAP 当数据库用。 > > > > > > 康哥你提出了运维人员的理想啊，要简单稳定靠谱又能满足需求…… > > > 在有多个服务器的情况下，LDAP是最通用的认证方案了，但问题是 openldap 本身并不好用，怎么办？ > > > 其实裸OpenLDAP用起来也还行，关键是 xiaq 还魔改过schema…… > > > > 我们应该有不超过10台服务器吧？ > > 除了将来要给大家人手一个容器的omni之外， > > 其它的机器平时也就是核心管理员登上去维护吧。 > > > > 要不然核心的几台服务器就靠key来认证？ 这样避免 LDAP 服务不稳定带来的问题.... > > 于是问题转化为 key 分发。 > 而且，最基本的问题：一段时间之后，谁都忘了谁能登录哪台服务器了，难道我们要用 excel 管理？ > > LDAP 稳定性问题并不是问题，以前发生这个问题是因为当时的服务器登陆依赖了LDAP单点，当然容易挂了。 > > 当时 LDAP 是有一备份节点的，不过同时挂过。我的感觉是和当时的机房与网络都不很靠谱有关。
> 我想做的方案是，内容就放在数据库里，对外暴露一个 LDAP 协议接口。跟 OpenLDAP 已经没有任何关系了， > 运维=管理数据库。 > > > > > 反正我在 xiaq 大侠的指导下折腾了一小会儿 LDAP 之后，发现以我的智商基本上是搞不懂LDAP了... > > 因为你折腾的那个是 xiaqLDAP ，比一般的 LDAP 还要再复杂一些…… > -- Regards, Alick -- --- You received this message because you are subscribed to the Google Groups "TUNA 主邮件列表" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
