Authenticating groups via LDAP

[Josip Rodin]

On Sat, May 22, 2010 at 07:17:29PM +0100, Alan Buxey wrote:
> although some would say thats the package people talking - and that the issue
> is only present because of how package management tools etc work. surely
> the best way of RPM, APT etc leaving behind all their rubbish/old-files/new-files
> etc is for them to utilise some revision control system or drop the files into
> a .special directory, eg .rpmnew for example.

Even if there was no packaging system, you would still have users who aren't
excessively pedantic who would leave their own copies of files in the same
folder. For example leaving an explicit copy of an old configuration in e.g.
ldap-2010-05-23.bak.

It still seems best to avoid the greediest match...

> moving to a new system where eg module files have a .mod extension and virtual
> servers have a .vsf extension (virtual server file ;-) )  then any present
> systems need to have quite a few tweaks to be upgraded from their present
> situation... 

That's why the mods-{available,enabled} idea is IMHO best. All Apache users
are used to it, which covers most people anyway, the FR users got used to
sites-{available,enabled} already so it's not much of a leap, and the
upgrade procedure is simple:

	mv $confdir/modules $confdir/mods-available
	mkdir $confdir/mods-enabled
	cd $confdir/mods-enabled && ln -s ../mods-available/* .

That preserves existing functionality to the letter - but it allows people
to later disable what they don't want/need easily - just remove some extra
symlinks.

> you could also argue that the easiest way is to include each file line
> by line in the radiusd.conf instead of using funky directories and including
> files wholesale. 

This is bad for packaged radiusd.conf's because it requires explicit user
intervention into the file contents.

The unconditional inclusion of (also packaged) eap.conf is an example of why
this is bad - the admin who wants to tweak those settings has to either
modify radiusd.conf to comment out the inclusion, or modify eap.conf to
adjust the parameters. And either one of those causes the packaging system
to notice that the user changed a configuration file upon the next upgrade,
and in turn present a possibly confusing choice to the upgrading admin - and
that kind of a situation doesn't necessarily end well :)

Since this file simply defines the eap module, I don't really see any reason
why it should not exist simply as a modules/eap file (or analogous in the
future). Same goes for sql.conf, but luckily that one is commented out by
default.

-- 
     2. That which causes joy or happiness.