<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 9pt;
font-family:±¼¸²
}
--></style>
</head>
<body class='hmmessage'>
 <BR>
Thank you<BR>
<BR> <BR>> From: freeradius-devel-request@lists.freeradius.org<BR>> Subject: Freeradius-Devel Digest, Vol 63, Issue 1<BR>> To: freeradius-devel@lists.freeradius.org<BR>> Date: Fri, 9 Jul 2010 12:00:15 +0200<BR>> <BR>> Send Freeradius-Devel mailing list submissions to<BR>> freeradius-devel@lists.freeradius.org<BR>> <BR>> To subscribe or unsubscribe via the World Wide Web, visit<BR>> http://lists.freeradius.org/mailman/listinfo/freeradius-devel<BR>> or, via email, send a message with subject or body 'help' to<BR>> freeradius-devel-request@lists.freeradius.org<BR>> <BR>> You can reach the person managing the list at<BR>> freeradius-devel-owner@lists.freeradius.org<BR>> <BR>> When replying, please edit your Subject line so it is more specific<BR>> than "Re: Contents of Freeradius-Devel digest..."<BR>> <BR>> <BR>> Today's Topics:<BR>> <BR>> 1. sql module and radgroup... (predrag balorda)<BR>> 2. Re: RES:!
  Patch: avpair.c - empty reply VALUE_PAIR (0x0) for<BR>> replies withunknown vendor attributes (Adam Lewis)<BR>> 3. Re: sql module and radgroup... (Alan DeKok)<BR>> <BR>> <BR>> ----------------------------------------------------------------------<BR>> <BR>> Message: 1<BR>> Date: Thu, 8 Jul 2010 15:12:16 +0200<BR>> From: predrag balorda <predrag.balorda@gmail.com><BR>> Subject: sql module and radgroup...<BR>> To: freeradius-devel@lists.freeradius.org<BR>> Message-ID:<BR>> <AANLkTilbHng3bcXjYqFjZyoQQWAEfArp-pOvngSGHtx2@mail.gmail.com><BR>> Content-Type: text/plain; charset=ISO-8859-1<BR>> <BR>> Would it be so difficult to add a "groupinfo" table? Just like you<BR>> have /etc/passwords you have /etc/groups so should you have userinfo<BR>> and radgroup or groupinfo or somesuch.<BR>> Namely, there is an awful kludge in radgroupreply in that if a a reply<BR>> with a group name exists then the group exists, o!
 therwise it doesn't.<BR>> Now that's funny, it's the same thing as 
saying if there is an entry<BR>> in radcheck then the user exists, otherwise they don't. Which is<BR>> silly. Not only in my opinion but in the the opinion of all database<BR>> people out there. Referential integrity is non-existent. So is<BR>> entity-integrity.<BR>> <BR>> A simple statement like this in your sql scripts would suffice (mysql<BR>> exaple here)<BR>> <BR>> DROP TABLE IF EXISTS `groupinfo`;<BR>> CREATE TABLE `groupinfo` (<BR>> `id` bigint(20) NOT NULL auto_increment,<BR>> `groupname` varchar(200) default NULL,<BR>> PRIMARY KEY (`id`),<BR>> KEY name (`groupname`)<BR>> );<BR>> <BR>> Then you can draw all sorts of relations back to this table from<BR>> radgroupcheck, radgroupreply, usergroup etc.<BR>> <BR>> Try and create a radgroupreply for group "Normal", say a bandwidth<BR>> limitation of some sort. Then add another limitation but this time<BR>> make an intentional typo and put in "nOrmal" in grou!
 pname instead.<BR>> What happens? If you had referential integrity the database wouldn't<BR>> let you make such mistaks. Just like this silly gmail webmail won't<BR>> let me make mistakes and underlines them with a red squiggly line.<BR>> <BR>> I'm saying all this because I'm writing a freeradius frontend (there,<BR>> that stupid red squiggly line again) - I'll probably call it<BR>> dialUpAdmin# as I'm using NHibernate, mono, asp.net2 and it's going<BR>> nice; I'll try and submit the initial version to the cvs (or is it<BR>> svn) repository sometime next week - and silliness like this pops up<BR>> everywhere. Some simple referential and entity integrity never hurt no<BR>> one.<BR>> <BR>> I'm probably talking crap here as I'll be switching to LDAP soon<BR>> enough for all this to go away, but still. It'd be nice.<BR>> <BR>> Best regards,<BR>> <BR>> Pele<BR>> <BR>> <BR>> ------------------------------<BR>> <BR>!
 > Message: 2<BR>> Date: Thu, 8 Jul 2010 07:03:23 -0700 (PDT)<BR>
> From: Adam Lewis <VNQM87@motorola.com><BR>> Subject: Re: RES: Patch: avpair.c - empty reply VALUE_PAIR (0x0) for<BR>> replies withunknown vendor attributes<BR>> To: freeradius-devel@lists.freeradius.org<BR>> Message-ID: <29107373.post@talk.nabble.com><BR>> Content-Type: text/plain; charset=us-ascii<BR>> <BR>> <BR>> Just a warning to anyone using the client on an embedded platform. The local<BR>> variable "buffer" in the function rc_avpair_gen() uses 507 bytes, so if the<BR>> function has many attributes to process, 507 bytes will be added to the<BR>> stack every time the function recurses. Perhaps another reason why this<BR>> function should be re-written.<BR>> <BR>> Regards,<BR>> Adam.<BR>> <BR>> <BR>> <BR>> Alan DeKok-2 wrote:<BR>> > <BR>> > Toledo, Luis Carlos wrote:<BR>> >> How to debug the unknown attributes? Put some prints in the code or have<BR>> >> clear way to do!
  this? <BR>> > <BR>> > The code should print out which attributes it receives. If it<BR>> > doesn't, supply a patch to fix it.<BR>> > <BR>> > Alan DeKok.<BR>> > -<BR>> > List info/subscribe/unsubscribe? See<BR>> > http://www.freeradius.org/list/devel.html<BR>> > <BR>> > <BR>> <BR>> -- <BR>> View this message in context: http://old.nabble.com/Patch%3A-avpair.c---empty-reply-VALUE_PAIR-%280x0%29-for-replies-with--unknown-vendor-attributes-tp28313256p29107373.html<BR>> Sent from the FreeRadius - Dev mailing list archive at Nabble.com.<BR>> <BR>> <BR>> <BR>> ------------------------------<BR>> <BR>> Message: 3<BR>> Date: Thu, 08 Jul 2010 16:16:54 +0200<BR>> From: Alan DeKok <aland@deployingradius.com><BR>> Subject: Re: sql module and radgroup...<BR>> To: FreeRadius developers mailing list<BR>> <freeradius-devel@lists.freeradius.org><BR>> Message-ID: <4C35DD!
 D6.2090009@deployingradius.com><BR>> Content-Type: text/plain; c
harset=ISO-8859-1<BR>> <BR>> predrag balorda wrote:<BR>> > Would it be so difficult to add a "groupinfo" table? Just like you<BR>> > have /etc/passwords you have /etc/groups so should you have userinfo<BR>> > and radgroup or groupinfo or somesuch.<BR>> > Namely, there is an awful kludge in radgroupreply in that if a a reply<BR>> > with a group name exists then the group exists, otherwise it doesn't.<BR>> <BR>> ? The reply is allowed to be empty. If it is empty, it has no effect<BR>> on group membership.<BR>> <BR>> > Now that's funny, it's the same thing as saying if there is an entry<BR>> > in radcheck then the user exists, otherwise they don't. Which is<BR>> > silly. Not only in my opinion but in the the opinion of all database<BR>> > people out there. Referential integrity is non-existent. So is<BR>> > entity-integrity.<BR>> <BR>> I have no idea what that means.<BR>> <BR>> > A simp!
 le statement like this in your sql scripts would suffice (mysql<BR>> > exaple here)<BR>> > <BR>> > DROP TABLE IF EXISTS `groupinfo`;<BR>> > CREATE TABLE `groupinfo` (<BR>> > `id` bigint(20) NOT NULL auto_increment,<BR>> > `groupname` varchar(200) default NULL,<BR>> > PRIMARY KEY (`id`),<BR>> > KEY name (`groupname`)<BR>> > );<BR>> > <BR>> > Then you can draw all sorts of relations back to this table from<BR>> > radgroupcheck, radgroupreply, usergroup etc.<BR>> <BR>> Sure. That's useful, but not required.<BR>> <BR>> I've seen 7 figure commercial solutions with *less* referential<BR>> integrity than the default FreeRADIUS schema.<BR>> <BR>> > Try and create a radgroupreply for group "Normal", say a bandwidth<BR>> > limitation of some sort. Then add another limitation but this time<BR>> > make an intentional typo and put in "nOrmal" in groupname instead.<BR>> > Wha!
 t happens? If you had referential integrity the database wouldn't<BR>&
gt; > let you make such mistaks. Just like this silly gmail webmail won't<BR>> > let me make mistakes and underlines them with a red squiggly line.<BR>> <BR>> You can supply a patch to the SQL schema && statements to add this<BR>> capability. The software *is* open source.<BR>> <BR>> > I'm saying all this because I'm writing a freeradius frontend (there,<BR>> > that stupid red squiggly line again) - I'll probably call it<BR>> > dialUpAdmin# as I'm using NHibernate, mono, asp.net2 and it's going<BR>> > nice; I'll try and submit the initial version to the cvs (or is it<BR>> > svn) repository sometime next week<BR>> <BR>> 'git'.<BR>> <BR>> > - and silliness like this pops up<BR>> > everywhere. Some simple referential and entity integrity never hurt no<BR>> > one.<BR>> <BR>> Sure. But it's one more requirement before people get the server up<BR>> and running.<BR>> <BR>> > I'm !
 probably talking crap here as I'll be switching to LDAP soon<BR>> > enough for all this to go away, but still. It'd be nice.<BR>> <BR>> As always, patches are welcome.<BR>> <BR>> Alan DeKok.<BR>> <BR>> <BR>> ------------------------------<BR>> <BR>> -<BR>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html<BR>> <BR>> <BR>> End of Freeradius-Devel Digest, Vol 63, Issue 1<BR>> ***********************************************<BR>                                        </body>
</html>