On Mon, 27 Jun 2016, Justin Wong wrote:
引入accounts9的话，能和github对接吗？（我貌似看到过是可以的?)
什么叫「和github对接」？
因为现在在github.com/tuna组织下，已经有一些账号了。
如果再搞一套基于accounts9的话，两边账号要不要互通？
我记得accounts9是可以Oauth的，或许可以开放使用github账号登录accounts9.tuna的功能？
或者就不要github.com/tuna的账号体系...?
DNS 放 LDAP 的核心意义请 @xiaq 说明
我的感觉是当年所有数据都存在 LDAP 里，我们在把 LDAP 当数据库用。
康哥你提出了运维人员的理想啊，要简单稳定靠谱又能满足需求……
在有多个服务器的情况下，LDAP是最通用的认证方案了，但问题是 openldap 本身并不好用，怎么办？
其实裸OpenLDAP用起来也还行，关键是 xiaq 还魔改过schema……
我们应该有不超过10台服务器吧？
除了将来要给大家人手一个容器的omni之外，
其它的机器平时也就是核心管理员登上去维护吧。
要不然核心的几台服务器就靠key来认证？ 这样避免 LDAP 服务不稳定带来的问题....
反正我在 xiaq 大侠的指导下折腾了一小会儿 LDAP 之后，发现以我的智商基本上是搞不懂LDAP了...
考究了一下，LDAP 是1993年，在 RFC 1487 里由 University of Michigan 的一群人 (难道是Michigan大学的开源技术协会MUNA)
提出来的。
反正这些人挖了这个坑之后毕了业，就没人管了。后来演变成了 OpenLDAP 。而且 OpenLDAP 居然是使用了 OpenLDAP
License。简直轮子狂人。
另外 LDAP 的前身还有 1988 年提出来的 DAP。
这里有一个比较仔细的考究:
https://ldapwiki.willeke.com/wiki/History%20of%20LDAP
我的点在于，这玩意岁数比我们都大啊..... 真正得管 LDAP 叫哥啊！
应该说我们免不了造轮子，但是要尽量少用太trick的方案去造轮子，有些feature能砍就砍。
我个人觉得，用 ldapjs 或者 go-ldapserver 把 postgres 或者 mongo 暴露出 LDAP 接口，
再提供一套 HTTP RESTful API 就足够了。
DNS 是完全另外一个问题，我再也不要把 DNS 和 LDAP 混到一起了。
+1
--
---
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 tuna-general+unsubscr...@googlegroups.com.
To post to this group, send email to tuna-general@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
