On Mon, Jun 27, 2016, at 12:09, Alick Zhao wrote: > > > 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都是配成，所有需要登录的节点都做 slave，nslcd 直接从本地拿。 只要 LDAP 进程不挂就一定能登录。 同时本地保留一个非 admin 账户，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.
-- --- 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.
