On Sun, 2013-11-03 at 13:38 +0100, Jonas Smedegaard wrote: > Quoting Petter Reinholdtsen (2013-11-03 09:49:24) > > [Lorenzo] > >> For these reasons I think it's not necessary to put LDAP in the > >> freedombox. Maybe I'm overlooking something (maybe some critical > >> daemon is incompatible with SASL?). I hope what I wrote can be of > >> help in the design, I'm curious to hear what are the other opinions > >> on this topic. > > > > The reason I believe it is a good idea to have LDAP on the freedombox, > > is that it reduces the number of user databases on the system. Some web > > service systems, like owncloud and ejabberd, have their own user > > databases while also supporting LDAP as their user database backend. > > Several, or perhaps most, do not use /etc/passwd as their user database. > > So we can either maintain several user databases specific to a lot of > > the services we want to set up in the Freedombox, or we can maintain one > > in LDAP and hook the services up to LDAP to use one common user database > > instead. I prefer the latter. > > Ok. Makes good sense to mandate use of shared auth mechanism. Not > convinced LDAP is the ideal for that, though. > > Beware that simply "supports LDAP" may not tell the full story: Some > applications integrate with LDAP only by optional lookups of LDAP > records, while maintaining its user data in a custom database anyway > (i.e. not writing back to LDAP). > > If LDAP is used only for readonly user/group data, not for sharing other > user data and not updated from the applications, then it might be safer > to write a script exporting POSIX info to those applications needing a > custom format (e.g. as a cron job or added as hooks to e.g. change of > password. > > Ejabberd, specifically, _does_ support POSIX getent. That's the very > reason I suggested to use that daemon: I have experience using it in > production, because it fits my requirements of using that simple shared > auth mechanism.
It would help to avoid confusing identity store with authentication or authorization mechanisms. > Hint for someone wanting to help: Above has to potentially low hanging > fruits: > > * collect concrete data on which applications support which shared > mechanisms for user/group management, and whether the support is > readonly or read/write. Read Only is the most sensible, you do not want random apps to be able to write to an identity store, or you open up your flank for privileges escalations. > * document how to make prosody use getent. the nsswitch interface (which is what you refer to with getent) is pluggable, so LDAP would fit in quite easily, there are a number of tools that provide plugins for all sort of identity stores. > > In addition, we get a central and structured place to store > > configuration for at least some of the services, but that is of less > > importance to me. > > It is of *big* importance to me that we do *not* move storage from /etc > to a database: It may seem tempting to use that approach when needing a > setup different from what the corresponding package maintainer offers, > but since we have *no* administrator on our systems, our setup *must* be > supported by package maintainers. I am not sure what this means, package maintainers normally call adduser/addgroup or similar, how is that a problem ? Simo. _______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
