[讨论] 基础结构升级、Wiki 迁移

[Justin Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

不知道还有多少人知道，我们还有个 wiki [1]
我调到中央以后，由于历史的行程，TUNA 从一个相对封闭的网管会，转型成开放的爱好者同好会。
而之前的 wiki，基于 LDAP [2] 的帐号系统、仅注册用户可编辑，等等这些设定使得很少有人能够贡献。
事实上，现有成员里拥有 LDAP 帐号的已经寥寥无几。

LDAP 又是另一个问题，当年 xiaq 为了满足一些定制化需求，用了特别的 LDAP 使用技巧，添加了特殊的
schema …… 使得维护 tuna ldap 比维护一般的 ldap 还要更复杂一些……

所以我建议:
1. wiki 迁移到 GitHub，和 issues 一样，使用更开放的管理模式，方便大家贡献
2. 全面升级基础业务
- 用户系统改用贵系科协开发的 accounts9 (开发者大多也同时是 TUNA 成员)
- 更新 DNS 服务

各位有什么想法？


[1] https://wiki.tuna.tsinghua.edu.cn/
[2] https://ldap.tuna.tsinghua.edu.cn/
[3] https://github.com/net9/accounts9


- --
Justin Wong

Blog: https://bigeagle.me/
Fingerprint: 15CC 6A61 738B 1599 0095 E256 CB67 DA7A 865B AC3A
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXcAreAAoJEJFxpFccJ5IKraEIAJ2ohHaBpjsarixYq+APpgSc
f5rnlEbWLDyVuIrSbND3rdPqH5sRkKDohvvbmaDo6vL/q5YIStB8cJjapk5cKbIg
c1b9SDbk7n/DNdFzPrZczfyoiE1MKvkEHMUiPNC0RV96tE5gtZkhzHZhdyegU4Pi
CEQX36cuYPHZUPhPpK9zhZsAS7BtUg1HDiSFVAPO2R6+C8+H/z1K5BzEg6heFxHg
E8lxOpDcAgOHboeKvzjyPA6lreNU3zKSbceOXrMNSzTPv8+6wKsZObm7LsUIw7Oc
2DB2i7d9EHTDELWH+jR26i94+6yN/AQYc/bS+TAAf7KBqwItE/uc6mCpKTIusQM=
=TPoV
-----END PGP SIGNATURE-----

[Shanker Wang]

> 在 2016年6月27日，01:03，Justin Wong <i...@bigeagle.me> 写道：
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 不知道还有多少人知道，我们还有个 wiki [1]
> 我调到中央以后，由于历史的行程，TUNA 从一个相对封闭的网管会，转型成开放的爱好者同好会。
> 而之前的 wiki，基于 LDAP [2] 的帐号系统、仅注册用户可编辑，等等这些设定使得很少有人能够贡献。
> 事实上，现有成员里拥有 LDAP 帐号的已经寥寥无几。
>
> LDAP 又是另一个问题，当年 xiaq 为了满足一些定制化需求，用了特别的 LDAP 使用技巧，添加了特殊的
> schema …… 使得维护 tuna ldap 比维护一般的 ldap 还要更复杂一些……
>
> 所以我建议:
> 1. wiki 迁移到 GitHub，和 issues 一样，使用更开放的管理模式，方便大家贡献
> 2. 全面升级基础业务
> - 用户系统改用贵系科协开发的 accounts9 (开发者大多也同时是 TUNA 成员)

a9 适合于组织比较严密的（带有层次性的）组织，往tuna里塞有点 heavy。

另外 a9 也确实有一些特别的针对贵系的功能可以删减。

或者你们可以重新搞个轮子。

> - 更新 DNS 服务
没了ldap，你们打算拿啥作dns？

>
> 各位有什么想法？
>
>
> [1] https://wiki.tuna.tsinghua.edu.cn/
> [2] https://ldap.tuna.tsinghua.edu.cn/
> [3] https://github.com/net9/accounts9
>
>
> - --
> Justin Wong
>
> Blog: https://bigeagle.me/
> Fingerprint: 15CC 6A61 738B 1599 0095 E256 CB67 DA7A 865B AC3A
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJXcAreAAoJEJFxpFccJ5IKraEIAJ2ohHaBpjsarixYq+APpgSc
> f5rnlEbWLDyVuIrSbND3rdPqH5sRkKDohvvbmaDo6vL/q5YIStB8cJjapk5cKbIg
> c1b9SDbk7n/DNdFzPrZczfyoiE1MKvkEHMUiPNC0RV96tE5gtZkhzHZhdyegU4Pi
> CEQX36cuYPHZUPhPpK9zhZsAS7BtUg1HDiSFVAPO2R6+C8+H/z1K5BzEg6heFxHg
> E8lxOpDcAgOHboeKvzjyPA6lreNU3zKSbceOXrMNSzTPv8+6wKsZObm7LsUIw7Oc
> 2DB2i7d9EHTDELWH+jR26i94+6yN/AQYc/bS+TAAf7KBqwItE/uc6mCpKTIusQM=
> =TPoV
> -----END PGP SIGNATURE-----
>

> --
>
> ---
> 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...@googlegroups.com.
> To post to this group, send email to tuna-g...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Justin Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 16-06-27 01:07, Shanker Wang wrote:
>
> > 在 2016年6月27日，01:03，Justin Wong <i...@bigeagle.me> 写道：
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > 不知道还有多少人知道，我们还有个 wiki [1]
> > 我调到中央以后，由于历史的行程，TUNA 从一个相对封闭的网管会，转型成开放的爱好者同好会。
> > 而之前的 wiki，基于 LDAP [2] 的帐号系统、仅注册用户可编辑，等等这些设定使得很少有人能够贡献。
> > 事实上，现有成员里拥有 LDAP 帐号的已经寥寥无几。
> >
> > LDAP 又是另一个问题，当年 xiaq 为了满足一些定制化需求，用了特别的 LDAP 使用技巧，添加了特殊的
> > schema …… 使得维护 tuna ldap 比维护一般的 ldap 还要更复杂一些……
> >
> > 所以我建议:
> > 1. wiki 迁移到 GitHub，和 issues 一样，使用更开放的管理模式，方便大家贡献
> > 2. 全面升级基础业务
> > - 用户系统改用贵系科协开发的 accounts9 (开发者大多也同时是 TUNA 成员)
>
> a9 适合于组织比较严密的（带有层次性的）组织，往tuna里塞有点 heavy。
>
> 另外 a9 也确实有一些特别的针对贵系的功能可以删减。
>
> 或者你们可以重新搞个轮子。

我看了下，的确很多轮子没有必要。
然后我看到了一个 golang 的 ldapserver 框架，突然有了轮子欲…
https://github.com/vjeantet/ldapserver

>
> > - 更新 DNS 服务
> 没了ldap，你们打算拿啥作dns？

数据都放在数据库里，DNS server 换成从数据库读数据的，ldap server 也从数据库读数据。
数据库我姿词 mongo 或者 postgreSQL

iQEcBAEBCAAGBQJXcA3KAAoJEJFxpFccJ5IKjtsH/0AquVgOEcUdP+T7oTIwu3h0
ZbonswgGA+KUUJMiZY7A629B+Lpa3wwh9aJ0WnA6zp/mvY4c9gPXlFpDrX33YRdp
PqWRrgTEAyd6qLASAWguY1oTUmF5qJQUlPw8aaHiBwTPzy1K++QuOYiK8W0x2nZV
anvIbe8fiYrldZtfGIPsC1pxWDlpwpHDwS35lhFoC4FAak/DlrrCcCac9eXgoyu3
5fa/QqTI3w7BWpn6Afs9pX6xRyFPe1qq6IxsyV/GhCpA5KRZDjXZr9CBBp9xhIhb
sVc7K4g5NRQJtwkVOF5A734TvkpwuimQkRCEFsfDkNJUkC+BoCnsMV+F1emKOGM=
=RZvn
-----END PGP SIGNATURE-----

[Ray Song]

On 2016-06-27, Justin Wong wrote:
>On 16-06-27 01:07, Shanker Wang wrote:
>>
>> > 在 2016年6月27日，01:03，Justin Wong <i...@bigeagle.me> 写道：
>> >
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA256
>> >
>> > 不知道还有多少人知道，我们还有个 wiki [1]
>> > 我调到中央以后，由于历史的行程，TUNA 从一个相对封闭的网管会，转型成开放的爱好者同好会。
>> > 而之前的 wiki，基于 LDAP [2] 的帐号系统、仅注册用户可编辑，等等这些设定使得很少有人能够贡献。
>> > 事实上，现有成员里拥有 LDAP 帐号的已经寥寥无几。
>> >
>> > LDAP 又是另一个问题，当年 xiaq 为了满足一些定制化需求，用了特别的 LDAP 使用技巧，添加了特殊的
>> > schema …… 使得维护 tuna ldap 比维护一般的 ldap 还要更复杂一些……
>> >
>> > 所以我建议:
>> > 1. wiki 迁移到 GitHub，和 issues 一样，使用更开放的管理模式，方便大家贡献
>> > 2. 全面升级基础业务
>> > - 用户系统改用贵系科协开发的 accounts9 (开发者大多也同时是 TUNA 成员)

支持accounts9

>> a9 适合于组织比较严密的（带有层次性的）组织，往tuna里塞有点 heavy。
>>
>> 另外 a9 也确实有一些特别的针对贵系的功能可以删减。
>>
>> 或者你们可以重新搞个轮子。
>
>我看了下，的确很多轮子没有必要。
>然后我看到了一个 golang 的 ldapserver 框架，突然有了轮子欲…
>https://github.com/vjeantet/ldapserver
>
>>
>> > - 更新 DNS 服务
>> 没了ldap，你们打算拿啥作dns？
>
>数据都放在数据库里，DNS server 换成从数据库读数据的，ldap server 也从数据库读数据。
>数据库我姿词 mongo 或者 postgreSQL

支持PostgreSQL
讨厌MongoDB

Ray
http://maskray.me

[Wang Kang]

> 1. wiki 迁移到 GitHub，和 issues 一样，使用更开放的管理模式，方便大家贡献

支持！

> 2. 全面升级基础业务
> - 用户系统改用贵系科协开发的 accounts9 (开发者大多也同时是 TUNA 成员)

引入accounts9的话，能和github对接吗？（我貌似看到过是可以的?)

> - 更新 DNS 服务
>> 没了ldap，你们打算拿啥作dns？
>
> 数据都放在数据库里，DNS server 换成从数据库读数据的，ldap server 也从数据库读数据。
> 数据库我姿词 mongo 或者 postgreSQL

我们现在有多少条DNS记录? 用LDAP+DNS的意义是什么?


总之，我的建议是弄的尽可能简单，尽可能多的用通用方案，这样之后维护的同学也能很快上手。
不会总想着推倒之前的方案再重来。
否则就年年造轮子，没有办法<del>发车</del>上高速了...

[Alick Zhao]

2016-06-26 12:03 GMT-05:00 Justin Wong <i...@bigeagle.me>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 不知道还有多少人知道，我们还有个 wiki [1]
> 我调到中央以后，由于历史的行程，TUNA 从一个相对封闭的网管会，转型成开放的爱好者同好会。
> 而之前的 wiki，基于 LDAP [2] 的帐号系统、仅注册用户可编辑，等等这些设定使得很少有人能够贡献。
> 事实上，现有成员里拥有 LDAP 帐号的已经寥寥无几。
>
> LDAP 又是另一个问题，当年 xiaq 为了满足一些定制化需求，用了特别的 LDAP 使用技巧，添加了特殊的
> schema …… 使得维护 tuna ldap 比维护一般的 ldap 还要更复杂一些……
>
> 所以我建议:
> 1. wiki 迁移到 GitHub，和 issues 一样，使用更开放的管理模式，方便大家贡献

好好好，终于不用再学一套 wiki 语法了。

不过，有很好的迁移方案吗？

另外，xiaq 当年用 Moin 的一点是它支持 ACL，所以有一些页面是仅成员可读的。这些页面迁移时注意不要漏掉也不要贸然公开😅

> 2. 全面升级基础业务
>   - 用户系统改用贵系科协开发的 accounts9 (开发者大多也同时是 TUNA 成员)

我有个设想是用户分三大类：prospective member, (current student) member, 以及 (graduated) associate member 希望能看到实现的一天😂

>   - 更新 DNS 服务
>
> 各位有什么想法？
>
>
> [1] https://wiki.tuna.tsinghua.edu.cn/
> [2] https://ldap.tuna.tsinghua.edu.cn/
> [3] https://github.com/net9/accounts9
>
>
> - --
> Justin Wong
>
> Blog: https://bigeagle.me/
> Fingerprint: 15CC 6A61 738B 1599 0095  E256 CB67 DA7A 865B AC3A
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJXcAreAAoJEJFxpFccJ5IKraEIAJ2ohHaBpjsarixYq+APpgSc
> f5rnlEbWLDyVuIrSbND3rdPqH5sRkKDohvvbmaDo6vL/q5YIStB8cJjapk5cKbIg
> c1b9SDbk7n/DNdFzPrZczfyoiE1MKvkEHMUiPNC0RV96tE5gtZkhzHZhdyegU4Pi
> CEQX36cuYPHZUPhPpK9zhZsAS7BtUg1HDiSFVAPO2R6+C8+H/z1K5BzEg6heFxHg
> E8lxOpDcAgOHboeKvzjyPA6lreNU3zKSbceOXrMNSzTPv8+6wKsZObm7LsUIw7Oc
> 2DB2i7d9EHTDELWH+jR26i94+6yN/AQYc/bS+TAAf7KBqwItE/uc6mCpKTIusQM=
> =TPoV
> -----END PGP SIGNATURE-----
>

> --
>
> ---
> 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...@googlegroups.com.
> To post to this group, send email to tuna-g...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--

Regards,
Alick

[Alick Zhao]

2016-06-26 12:07 GMT-05:00 Shanker Wang <shanker...@gmail.com>:

> 在 2016年6月27日，01:03，Justin Wong <i...@bigeagle.me> 写道：
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 不知道还有多少人知道，我们还有个 wiki [1]
> 我调到中央以后，由于历史的行程，TUNA 从一个相对封闭的网管会，转型成开放的爱好者同好会。
> 而之前的 wiki，基于 LDAP [2] 的帐号系统、仅注册用户可编辑，等等这些设定使得很少有人能够贡献。
> 事实上，现有成员里拥有 LDAP 帐号的已经寥寥无几。
>
> LDAP 又是另一个问题，当年 xiaq 为了满足一些定制化需求，用了特别的 LDAP 使用技巧，添加了特殊的
> schema …… 使得维护 tuna ldap 比维护一般的 ldap 还要更复杂一些……
>
> 所以我建议:
> 1. wiki 迁移到 GitHub，和 issues 一样，使用更开放的管理模式，方便大家贡献
> 2. 全面升级基础业务
>  - 用户系统改用贵系科协开发的 accounts9 (开发者大多也同时是 TUNA 成员)

a9 适合于组织比较严密的（带有层次性的）组织，往tuna里塞有点 heavy。

其实人多了之后层次是必需的，我觉得从向后兼容性来看，重一点比轻一点要好。
 

另外 a9 也确实有一些特别的针对贵系的功能可以删减。

+1
 

--

Regards,
Alick

[Justin Wong]

On Mon, Jun 27, 2016, at 10:57, Wang Kang wrote:
>
> > 1. wiki 迁移到 GitHub，和 issues 一样，使用更开放的管理模式，方便大家贡献
>
> 支持！
>
> > 2. 全面升级基础业务
> > - 用户系统改用贵系科协开发的 accounts9 (开发者大多也同时是 TUNA 成员)
>
> 引入accounts9的话，能和github对接吗？（我貌似看到过是可以的?)

什么叫「和github对接」？

>
> > - 更新 DNS 服务
> >> 没了ldap，你们打算拿啥作dns？
> >
> > 数据都放在数据库里，DNS server 换成从数据库读数据的，ldap server 也从数据库读数据。
> > 数据库我姿词 mongo 或者 postgreSQL
>
> 我们现在有多少条DNS记录? 用LDAP+DNS的意义是什么?

DNS 放 LDAP 的核心意义请 @xiaq 说明
我的感觉是当年所有数据都存在 LDAP 里，我们在把 LDAP 当数据库用。

> 总之，我的建议是弄的尽可能简单，尽可能多的用通用方案，这样之后维护的同学也能很快上手。
> 不会总想着推倒之前的方案再重来。
> 否则就年年造轮子，没有办法<del>发车</del>上高速了...

康哥你提出了运维人员的理想啊，要简单稳定靠谱又能满足需求……
在有多个服务器的情况下，LDAP是最通用的认证方案了，但问题是 openldap 本身并不好用，怎么办？
其实裸OpenLDAP用起来也还行，关键是 xiaq 还魔改过schema……

应该说我们免不了造轮子，但是要尽量少用太trick的方案去造轮子，有些feature能砍就砍。

我个人觉得，用 ldapjs 或者 go-ldapserver 把 postgres 或者 mongo 暴露出 LDAP 接口，
再提供一套 HTTP RESTful API 就足够了。

DNS 是完全另外一个问题，我再也不要把 DNS 和 LDAP 混到一起了。

[Wang Kang]

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

[Justin Wong]

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 协议接口。跟 OpenLDAP 已经没有任何关系了，
运维=管理数据库。

>
> 反正我在 xiaq 大侠的指导下折腾了一小会儿 LDAP 之后，发现以我的智商基本上是搞不懂LDAP了...

因为你折腾的那个是 xiaqLDAP ，比一般的 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
>

[Qijiang Fan]

2016-06-27 12:39 GMT+09:00 Wang Kang <i...@scateu.me>:
> 除了将来要给大家人手一个容器的omni之外，


omni 这 flag 多久了。。

[Justin Wong]

因为一直没有机器放omni呀……

--
Justin Wong

[Alick Zhao]

2016-06-26 22:48 GMT-05:00 Justin Wong <i...@bigeagle.me>:

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

[Justin Wong]

On Mon, Jun 27, 2016, at 12:09, Alick Zhao wrote:

 

 

2016-06-26 22:48 GMT-05:00 Justin Wong <i...@bigeagle.me>:

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

[Wang Kang]

> 于是问题转化为 key 分发。
> 而且，最基本的问题：一段时间之后，谁都忘了谁能登录哪台服务器了，难道我们要用 excel 管理？

用 LDAP 也一样会有这问题吧？
从权限分配上来说，每个学期初 revoke 一次应该就好了...

另外一方面，使用者如果连自己能登哪台服务器都不记得了的话....
说明那台服务器也不需要登了... 学期初被 revoke 掉就好了

此外，读写数据库和读写 excel 也没啥本质不同啊。
写纸上想想看也不是不行>_<

毕竟这事不是每时每刻都需要自动化做的..
总得有个权限的分配流程，得需要人的参与

> LDAP 稳定性问题并不是问题，以前发生这个问题是因为当时的服务器登陆依赖了LDAP单点，当然容易挂了。

新的方案怎样可以不依赖单点的 LDAP 呢？

> 我想做的方案是，内容就放在数据库里，对外暴露一个 LDAP 协议接口。跟 OpenLDAP 已经没有任何关系了，
> 运维=管理数据库。

我理解。但是问题是，得想一个办法让这个新项目能被够持续维护。
不然等你一毕业，新任管理员一想算了还是推倒再来一个 LDAP 吧

> 因为你折腾的那个是 xiaqLDAP ，比一般的 LDAP 还要再复杂一些……

不是这个，是 Alpine 里的 OpenLDAP 啦。

[Wang Kang]

>> 当时 LDAP 是有一备份节点的，不过同时挂过。我的感觉是和当时的机房与网络都不很靠谱有关。
>
> 我现在LDAP都是配成，所有需要登录的节点都做 slave，nslcd 直接从本地拿。
> 只要 LDAP 进程不挂就一定能登录。
> 同时本地保留一个非 admin 账户，LDAP 进程挂了也能维护。

想起来了，当时的确也是这个问题.....

另外跟 LDAP 的界面实在是太丑也有关.. (你丑你别服务)

[Justin Wong]

On Mon, Jun 27, 2016, at 12:22, Wang Kang wrote:
> > 于是问题转化为 key 分发。
> > 而且，最基本的问题：一段时间之后，谁都忘了谁能登录哪台服务器了，难道我们要用 excel 管理？
>
> 用 LDAP 也一样会有这问题吧？
> 从权限分配上来说，每个学期初 revoke 一次应该就好了...
>
> 另外一方面，使用者如果连自己能登哪台服务器都不记得了的话....
> 说明那台服务器也不需要登了... 学期初被 revoke 掉就好了
>
> 此外，读写数据库和读写 excel 也没啥本质不同啊。
> 写纸上想想看也不是不行>_<
>
> 毕竟这事不是每时每刻都需要自动化做的..
> 总得有个权限的分配流程，得需要人的参与
>

当然是 Web 上操作一下，把用户名加/减到一个节点里就好了呀…
即使是现行的 LDAP 方案做这个也非常方便，而且xiaq魔改过的 LDAP 还能分发 key

> > LDAP 稳定性问题并不是问题，以前发生这个问题是因为当时的服务器登陆依赖了LDAP单点，当然容易挂了。
>
> 新的方案怎样可以不依赖单点的 LDAP 呢？

这个刚才解释过了

>
> > 我想做的方案是，内容就放在数据库里，对外暴露一个 LDAP 协议接口。跟 OpenLDAP 已经没有任何关系了，
> > 运维=管理数据库。
>
> 我理解。但是问题是，得想一个办法让这个新项目能被够持续维护。
> 不然等你一毕业，新任管理员一想算了还是推倒再来一个 LDAP 吧

不一样，OpenLDAP 的管理极其麻烦，说白了就是因为它的数据存储太不自然了。
xiaqLDAP 难以维护的主要原因也就是 xiaq 魔改了 openLDAP 默认的存储结构，使得本身就难以维护的东西变得更加难以维护。

换成数据库就简单多了，想存什么存什么，比如 key 分发，就直接加个 key 字段就好，因为数据库格式我们完全可控。
openLDAP 就不一样了，数据的 schema 是有标准的，不能随便动…… 要动的话，就有一套极其麻烦的 schema 定义格式……

我举个例子，
数据库里可能存储的一行就是 username, uid, gid, home
当 LDAP 访问的时候，返回结果按照 LDAP 格式 uid: bigeagle 这样的返回就可以了。
我们只需要暴露 LDAP 只读接口，我昨晚看了下，用 go 写 100 行代码就能搞定，js 能更少。

>
>
> > 因为你折腾的那个是 xiaqLDAP ，比一般的 LDAP 还要再复杂一些……
>
> 不是这个，是 Alpine 里的 OpenLDAP 啦。
>

[ShanYafeng]

其实本质问题不是ldap难用，不是xiaq魔改schema，而是因为ldap没有一个好用的图形化/网页化界面。

使用数据库对外暴露LDAP协议，这个本质上就是简单粗暴，其他人接手时直接操作数据库，偷懒的话

没有学习成本，不过这是个很不好的习惯。

层级关系还是很必须的，尤其涉及到一堆服务器权限。

本质上，后台数据不管是ldap还是数据库，对外提供ldap访问，需要开发的是一个专用的网页帐户维护系统。

[Justin Wong]

但是 LDAP filter 转换为 SQL filter 有点困难啊
转换为 MongoDB 的 query 就非常简单……

> Email had 1 attachment:
> + signature.asc
> 1k (application/pgp-signature)

[Ray Song]

看到了死去多年的omni...

On 2016-06-27, Justin Wong wrote:

--
Ray
http://maskray.me

[XIAO Qi]

我当初用 LDAP 存储 DNS 信息的动机是把服务器的信息放在同一个地方维护。

LDAP 的数据模型并没有什么明显的优势，而且额外学习的成本很高。我很赞成自己设计数据库结构，然后造 LDAP 兼容层的轮子。当年要有合适的
LDAP server 框架我肯定也自己写了。

> --
>
> ---
> 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...@googlegroups.com.
> To post to this group, send email to tuna-g...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--

Best regards,
肖骐 XIAO Qi

[Justin Wong]

我用 goldapserver 写了个最简单的 demo，100行左右的代码（关键的就十几行），已经能顺利通过 nslcd 认证。

现在有一个还有争议的问题，数据库选型。

两个主要选择：mongodb 还是 postgreSQL
其他选择：etcd，bolt/sqlite 等嵌入式数据库

我列举一些优劣：

1. mongodb
* pros:
- 简单易上手，开发快，shemaless 很灵活
- replica set 好用，早年因网络抽风引起的认证故障后果很严重
* cons:
- shemaless 留隐患

2. postgres
* pros:
- 坚若磐石，非常稳固
- 完整的 SQL 支持
- 对于 用户、组 这种数据，用关系型模型很科学
* cons:
- replication 不如 mongodb 好用

3. etcd
* pros:
- 强一致性分布式存储
* cons:
- 只有 key-value，对于应用来说有点弱
- 资料相对较少，运维难度未知

4. 嵌入式数据库
* pros:
- 即开即用免配置
* cons:
- replication 完全得手动来

我个人倾向于 mongodb 和 postgres 二选一，并且把功能限制在仅仅保留用户和组，对外提供 ldap、oauth2 、REST
API 等接口，再加一个可选的 web。我相信有不少团队都有类似需求，把功能限制在一个小集合中，可以造福更多人。

大家有什么意见？

--
Justin Wong