Alan DeKok wrote:
That makes sense. It gets more difficult once multiple attributes of the same name are in a list. I'll have to think about that some more.
Codewise (well at least the patch I tried) its easier to deal with mutliple attributes if no attribute is also a successfull no match
Perhaps a small poll to find out if anyone present relies on the current behavior of != ?
Well I recall being bitten by != unexepcted behavior in the past and switching to !* (which also didnt work, which you took my 2 liner, which was also buggy, which the last patch includes a fix for) Yep, its in my users file to deny certain users who dont have a Connect-Info == "value" attribute. So its unpatched behavior is actually NOT what I wanted/expected until I read man 5 users. Perhaps the direction to be taken here is to add another way to negate the == test that behaves like the patches != ?
Sure. Since it's not really documented, I'm not sure what the existing systems *expect*.
man 5 users states that Attribute != Value As a check item, matches if the given attribute is in the request, AND does not have the given value. Not allowed as a reply item.
The use there is probably better done by something like:
... reply -= { foo == bar, ... }
i.e. "remove from reply attributes that match these conditions". The behavior of '==' and '=~' is always the same, which helps.
That syntax never occurred to me. It would be nice if it worked, so I tested it. /etc/freeradius/policy.txt[8]: Unexpected token -= But policy is not complete, hence this portion of discussion.
I would prefer to fix the policy module so it's complete and stable. With a little bit of effort, it can solve many of the same problems that the existing modules do, in a more general manner.
The policy module is a very powerfull concept, allowing one to use pseduo code to manipulate the attribute lists. I assume you mean it can make redundant modules like attr_filter attr_rewrite and others as well.
Yeah, that's bad. But the main reason is that paircompare() has it's problems. It's meant to support the "users" file, and extending it for any other purpose is a bad idea.
paircompare() supports xlat, supports registered comparison functions, and seems to be the code equivalent to man 5 users which is the freeradius authoritative source as to how operators are to be used. I havent checked but I would hope that rlm_sql and friends also used it as well, since their goal is to reproduce the users file environment in a db friendly environment. If you mean paircompare() should be used whenever one want users file like handling of comparisons, I would tend to agree.
Not like my opinion actually matters much.
<shrug> See the number of bufs fixes that have gonr in recently based on your comments.
Drop in the bucket compared to what the you and the existing contributors have done.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html