attr filter "attrsfile" -> "file"
...might be worth adding a note to the 2.x porting stuff in README.rst about this - confused me for a few minutes.
Hi,
it should be there - that was a recent change.
I'm not seeing it... am I being dense?
no. as i said, it SHOULD be there. the README.rst isnt 100% locked to new features as they arrive, sometimes there are delays ( the 'git what-changed' command is the real oracle of changes to the HEAD ;-) ) alan
On 8 Jan 2013, at 08:07, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 01/07/2013 06:12 PM, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
...might be worth adding a note to the 2.x porting stuff in README.rst about this - confused me for a few minutes.
it should be there - that was a recent change.
I'm not seeing it... am I being dense?
It's not documented because it's not finalised. Alan D wanted to standardise on using sub section based configuration for the different sections of the server, so there's still some more work to do. the final config for attrfilter will look something like: attrfilter { authorize { file = } preacct { file = } } -Arran
On 08/01/13 12:07, Arran Cudbard-Bell wrote:
On 8 Jan 2013, at 08:07, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 01/07/2013 06:12 PM, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
...might be worth adding a note to the 2.x porting stuff in README.rst about this - confused me for a few minutes.
it should be there - that was a recent change.
I'm not seeing it... am I being dense?
It's not documented because it's not finalised. Alan D wanted to standardise on using sub section based configuration for the different sections of the server, so there's still some more work to do.
the final config for attrfilter will look something like:
The background here is I'm trying to maintain our "testing" server on a current version of "master", compiled once every few days. Do you guys have any thoughts on a release date and major changes before then? If it's a few months out or the other side of a major upheaval, I'll probably give up on it - too few hours in the day to track a moving target, I'm afraid.
Arran Cudbard-Bell wrote:
It's not documented because it's not finalised. Alan D wanted to standardise on using sub section based configuration for the different sections of the server, so there's still some more work to do.
the final config for attrfilter will look something like:
Yeah... I'm of two minds about this. Regularizing the config is good. Making it more verbose is annoying.
attrfilter { authorize { file = } preacct { file = } }
or even: attrfilter { authorize.file = ... preacct.file = ... } Which is nice, but doesn't fit the subsection paradigm. Alan DeKok.
On 8 Jan 2013, at 14:53, Alan DeKok <aland@deployingradius.com> wrote:
Arran Cudbard-Bell wrote:
It's not documented because it's not finalised. Alan D wanted to standardise on using sub section based configuration for the different sections of the server, so there's still some more work to do.
the final config for attrfilter will look something like:
Yeah... I'm of two minds about this. Regularizing the config is good. Making it more verbose is annoying.
attrfilter { authorize { file = } preacct { file = } }
or even:
attrfilter { authorize.file = ... preacct.file = ...
}
Sure but that should be done within the conffile API when the configuration files are being parsed. It'd also allow really compact module definitions like: attrfilter.authorize.file = <blah> Which'd be nice. I don't really want to touch that code though, it's pretty weird. -Arran
On Tue, Jan 08, 2013 at 09:53:00AM -0500, Alan DeKok wrote:
attrfilter { authorize { file = } preacct { file = } }
or even:
attrfilter { authorize.file = ... preacct.file = ...
}
Which is nice, but doesn't fit the subsection paradigm.
Are you planning to change other modules this way? For example, rlm_files has usersfile acctusersfile preproxy_usersfile auth_usersfile postproxy_usersfile postauth_usersfile I don't see what's wrong with this myself, apart from the missing underscore in acctusersfile not being consistent with the rest. Regards, Brian.
On 9 Jan 2013, at 10:20, Brian Candler <B.Candler@pobox.com> wrote:
On Tue, Jan 08, 2013 at 09:53:00AM -0500, Alan DeKok wrote:
attrfilter { authorize { file = } preacct { file = } }
or even:
attrfilter { authorize.file = ... preacct.file = ...
}
Which is nice, but doesn't fit the subsection paradigm.
Are you planning to change other modules this way? For example, rlm_files has
Yes, rlm_detail and fastusers shold be changed too.
usersfile acctusersfile preproxy_usersfile auth_usersfile postproxy_usersfile postauth_usersfile
I don't see what's wrong with this myself, apart from the missing underscore in acctusersfile not being consistent with the rest.
Nothing, except the fact that there's no way to infer the correct config item name. If we switch to use section.file, you know that if any module that reads or writes to a file you can always do: authorize { file = <foo> } Also if you see that the example has: authorize { file = <foo> } and authenticate { file = <foo> } you can assume there's going to be postauth { file = <foo> } That's the point of making things consistent, so you don't have to waste time referring to the man pages and documentation. Also adding a module specific prefix to 'file' is wrong. You know what type of file it is by the module section it's declared in. The only place this would be of use would be in a completely flat namespace. Maybe Cistron had a flat namespace (I don't know), but FreeRADIUS certainly doesn't now. It's pointless keeping the prefixes everywhere, it just makes it harder to infer the correct config item name. -Arran
On 09/01/13 11:23, Arran Cudbard-Bell wrote:
That's the point of making things consistent, so you don't have to waste time referring to the man pages and documentation.
Just to point out: this change is not without cost. Thousands of sysadmins will have significantly more work upgrading their configs as a result. I'm all for rationalisation, but TBH you're not selling me on the cost/benefit tradeoff. Your choice, of course. But you shouldn't be surprised if this kind of thing significantly retards deployment of 3.0.
Also adding a module specific prefix to 'file' is wrong. You know what type of file it is by the module section it's declared in. The only place this would be of use would be in a completely flat namespace.
It may be "wrong" but it's what we CURRENTLY DO. Telling people "Hey we've changed our minds that thing we made you all do is now wrong" just irritates them. Can we at least maintain backwards compatibility for one major version to read the old filenames? Surely it can't be that hard to have a short lookup table from the old names?
On 9 Jan 2013, at 13:12, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 09/01/13 11:23, Arran Cudbard-Bell wrote:
That's the point of making things consistent, so you don't have to waste time referring to the man pages and documentation.
Just to point out: this change is not without cost. Thousands of sysadmins will have significantly more work upgrading their configs as a result. I'm all for rationalisation, but TBH you're not selling me on the cost/benefit tradeoff.
The decision was made to break configuration compatibility for 3.0. The configuration of the EAP module, LDAP and SQL have already changed significantly. I won't claim this to be true for everyone, but from my own experience and reading posts on quite a few programming and administration blogs, one of the biggest timesinks in IT related jobs are context switches. That is, stashing your working knowledge of one very complex system, and constructing a mental model of another very complex system. Once you've made the decision to start the upgrade work to transition to 3.0, you've already paid the price in terms of the context switch. You're going to have to refresh your knowledge of how the server works anyway, to upgrade your EAP/LDAP/SQL module configurations. Adding a trivial copy and paste exercise to the upgrade process is not going to significantly increase the amount of effort you have to expend.
Your choice, of course. But you shouldn't be surprised if this kind of thing significantly retards deployment of 3.0.
Ok, but we've already done lots of 'this kind of thing', that was one of the big things in 3.0.
Also adding a module specific prefix to 'file' is wrong. You know what type of file it is by the module section it's declared in. The only place this would be of use would be in a completely flat namespace.
It may be "wrong" but it's what we CURRENTLY DO. Telling people "Hey we've changed our minds that thing we made you all do is now wrong" just irritates them.
It is *exactly* that kind of attitude which leads to Perl. Big surprise, people contributing their time for free aren't *that* concerned where the project will be in 10 years, so yes, sometimes things do need to be re-done. It's not a case of 'changing minds'. You need to refactor the configuration periodically just as you refactor the code, else it becomes an unworkable mess. Trying to insulate administrators from those changes means you end up with a system that is rediculously complex and unmaintainable. Of course there's a compromise, if you were constatly refactoring the configuration, then you'd also make the system unmaintainable. That is why these changes only occur between major releases.
Can we at least maintain backwards compatibility for one major version to read the old filenames? Surely it can't be that hard to have a short lookup table from the old names?
So then you take over maintence of a v3.x system and all the configurations are in this weird format and you can't really see how it works and, and... For some modules, like sql, yes, you can write drop in blocks of config that remap the new structure to the old config item names, for something like this, no, it's pointless and adds complexity. -Arran
On 09/01/13 14:31, Arran Cudbard-Bell wrote:
Can we at least maintain backwards compatibility for one major version to read the old filenames? Surely it can't be that hard to have a short lookup table from the old names?
So then you take over maintence of a v3.x system and all the configurations are in this weird format and you can't really see how it works and, and...
Ok. One suggestion, it's probably worth making sure rlm_files doesn't start unless at least one sub-section contains a "file". Otherwise people are going to not spot it. Obviously our opinions differ on the general topic, although I support your efforts to avoid Perl-izing the config language!
Arran Cudbard-Bell wrote:
Can we at least maintain backwards compatibility for one major version to read the old filenames? Surely it can't be that hard to have a short lookup table from the old names?
So then you take over maintence of a v3.x system and all the configurations are in this weird format and you can't really see how it works and, and...
The config system has provisions for backwards compatibility. We can leverage that, but deprecate the old system. That being said, there is config in 3.x that is backwards compatible with config from 0.x. That's wrong, and will be fixed. For other things, like "User-Password", it *causes* problems. People read decade-old "howto's", and create broken configurations. It's a good idea to get that fixed. Alan DeKok.
On 9 Jan 2013, at 15:46, Alan DeKok <aland@DEPLOYINGRADIUS.COM> wrote:
Arran Cudbard-Bell wrote:
Can we at least maintain backwards compatibility for one major version to read the old filenames? Surely it can't be that hard to have a short lookup table from the old names?
So then you take over maintence of a v3.x system and all the configurations are in this weird format and you can't really see how it works and, and...
The config system has provisions for backwards compatibility. We can leverage that, but deprecate the old system.
That being said, there is config in 3.x that is backwards compatible with config from 0.x. That's wrong, and will be fixed.
For other things, like "User-Password", it *causes* problems. People read decade-old "howto's", and create broken configurations. It's a good idea to get that fixed.
*grumble* We'll see if it makes sense in this context. -Arran
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Brian Candler -
Phil Mayers