<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>

> From: freeradius-devel-request@lists.freeradius.org > Subject: Freeradius-Devel Digest, Vol 63, Issue 1 > To: freeradius-devel@lists.freeradius.org > Date: Fri, 9 Jul 2010 12:00:15 +0200 >  > Send Freeradius-Devel mailing list submissions to > freeradius-devel@lists.freeradius.org >  > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freeradius.org/mailman/listinfo/freeradius-devel > or, via email, send a message with subject or body 'help' to > freeradius-devel-request@lists.freeradius.org >  > You can reach the person managing the list at > freeradius-devel-owner@lists.freeradius.org >  > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Freeradius-Devel digest..." >  >  > Today's Topics: >  > 1. sql module and radgroup... (predrag balorda) > 2. Re: RES:!

Patch: avpair.c - empty reply VALUE_PAIR (0x0) for > replies withunknown vendor attributes (Adam Lewis) > 3. Re: sql module and radgroup... (Alan DeKok) >  >  > ---------------------------------------------------------------------- >  > Message: 1 > Date: Thu, 8 Jul 2010 15:12:16 +0200 > From: predrag balorda <predrag.balorda@gmail.com> > Subject: sql module and radgroup... > To: freeradius-devel@lists.freeradius.org > Message-ID: > <AANLkTilbHng3bcXjYqFjZyoQQWAEfArp-pOvngSGHtx2@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 >  > 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, o!

 therwise it doesn't.<BR>> 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. >  > 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. >  > 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 grou!

pname 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. >  > 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 - and silliness like this pops up > everywhere. Some simple referential and entity integrity never hurt no > one. >  > 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. >  > Best regards, >  > Pele >  >  > ------------------------------ >  !

 > 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 >  > 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. >  > > 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. >  > > A simp!

le 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. >  > I've seen 7 figure commercial solutions with *less* referential > integrity than the default FreeRADIUS schema. >  > > 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. > > 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 > > 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'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'. >  > > - 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. >  > > 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>