sql module and radgroup...

[predrag balorda]

Ok, I said to myself we're grownups, we have to think things through.
But then if you didn't I sure as hell ain't!

On 8 July 2010 16:16, Alan DeKok <aland at deployingradius.com> wrote:
> predrag balorda wrote:
>> Would it be so difficult to add a "groupinfo" table? Just like you
>> have /etc/passwords you have /etc/groups so should you have userinfo
>> and radgroup or groupinfo or somesuch.
>> Namely, there is an awful kludge in radgroupreply in that if a a reply
>> with a group name exists then the group exists, otherwise it doesn't.
>
>  ? The reply is allowed to be empty.  If it is empty, it has no effect
> on group membership.

Yes and if it's empty there _is no_ group membership as the group
doesn't even exist.

>> Now that's funny, it's the same thing as saying if there is an entry
>> in radcheck then the user exists, otherwise they don't. Which is
>> silly. Not only in my opinion but in the the opinion of all database
>> people out there. Referential integrity is non-existent. So is
>> entity-integrity.
>
>  I have no idea what that means.

Well, read it, over and over again, until you do.

>> A simple statement like this in your sql scripts would suffice (mysql
>> exaple here)
>>
>> DROP TABLE IF EXISTS `groupinfo`;
>> CREATE TABLE `groupinfo` (
>>   `id` bigint(20) NOT NULL auto_increment,
>>   `groupname` varchar(200) default NULL,
>>   PRIMARY KEY  (`id`),
>>   KEY name (`groupname`)
>> );
>>
>> Then you can draw all sorts of relations back to this table from
>> radgroupcheck, radgroupreply, usergroup etc.
>
>  Sure.  That's useful, but not required.

Useful but not required? Interesting postulate. Then all my rdbms
professors were and everything I know about rdbms is wrong, I
guess....

>  I've seen 7 figure commercial solutions with *less* referential
> integrity than the default FreeRADIUS schema.

I haven't _seen_ those, per se, but I have _worked_ on some that were
7, 8 and 9 figure commercial solutions with less and more referential
integrity than the default FreeRADIUS schema. What are you trying to
do? Impress me? Or say that if some XYZ company doesn't do it then
it's not worth doing?
So if Microsoft doesn't check for buffer underruns and overflows in
their code it isn't worth implementing in your FreeRADIUS code? Again,
interesting postulate. I'll have to go read up a bit on that.

>> Try and create a radgroupreply for group "Normal", say a bandwidth
>> limitation of some sort. Then add another limitation but this time
>> make an intentional typo and put in "nOrmal" in groupname instead.
>> What happens? If you had referential integrity the database wouldn't
>> let you make such mistaks. Just like this silly gmail webmail won't
>> let me make mistakes and underlines them with a red squiggly line.
>
>  You can supply a patch to the SQL schema && statements to add this
> capability.  The software *is* open source.

I just did!

>> I'm saying all this because I'm writing a freeradius frontend (there,
>> that stupid red squiggly line again) - I'll probably call it
>> dialUpAdmin# as I'm using NHibernate, mono, asp.net2 and it's going
>> nice; I'll try and submit the initial version to the cvs (or is it
>> svn) repository sometime next week
>
>  'git'.
'pufter'
>> - and silliness like this pops up
>> everywhere. Some simple referential and entity integrity never hurt no
>> one.
>
>  Sure.  But it's one more requirement before people get the server up
> and running.

Yes, and one more thing to stop the server from keeling over. And one
more thing to stop the server from replying with crap information. And
one more thing to stop people from making mistakes. And one more thing
to stop people from loosing account information. And one more thing to
make code easier to read and understand. And one more thing to make
bug-finding easier. And one more thing to increase performance. And
one more thing to reduce database size. And and and....

>> I'm probably talking crap here as I'll be switching to LDAP soon
>> enough for all this to go away, but still. It'd be nice.
>
>  As always, patches are welcome.

Again, I just did!

>  Alan DeKok.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
>

Ok, and now seriously. I'll look into your schema and see what can be
done. I've already begun modifying it as I go along. Would you prefer
a set of simple statements to create tables or would you rather alter
existing ones? I think altering existing ones would make all hell
break loose, but I can try?!

Best regards,

Pele