HELP unsubscribe me please

Mon Jul 12 02:18:59 CEST 2010

 

Thank you


> From: freeradius-devel-request at lists.freeradius.org
> Subject: Freeradius-Devel Digest, Vol 63, Issue 1
> To: freeradius-devel at lists.freeradius.org
> Date: Fri, 9 Jul 2010 12:00:15 +0200
> 
> Send Freeradius-Devel mailing list submissions to
> freeradius-devel at 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 at lists.freeradius.org
> 
> You can reach the person managing the list at
> freeradius-devel-owner at 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 at gmail.com>
> Subject: sql module and radgroup...
> To: freeradius-devel at lists.freeradius.org
> Message-ID:
> <AANLkTilbHng3bcXjYqFjZyoQQWAEfArp-pOvngSGHtx2 at 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, otherwise it doesn't.
> 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 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.
> 
> 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
> Date: Thu, 8 Jul 2010 07:03:23 -0700 (PDT)
> From: Adam Lewis <VNQM87 at motorola.com>
> Subject: Re: RES: Patch: avpair.c - empty reply VALUE_PAIR (0x0) for
> replies withunknown vendor attributes
> To: freeradius-devel at lists.freeradius.org
> Message-ID: <29107373.post at talk.nabble.com>
> Content-Type: text/plain; charset=us-ascii
> 
> 
> Just a warning to anyone using the client on an embedded platform. The local
> variable "buffer" in the function rc_avpair_gen() uses 507 bytes, so if the
> function has many attributes to process, 507 bytes will be added to the
> stack every time the function recurses. Perhaps another reason why this
> function should be re-written.
> 
> Regards,
> Adam.
> 
> 
> 
> Alan DeKok-2 wrote:
> > 
> > Toledo, Luis Carlos wrote:
> >> How to debug the unknown attributes? Put some prints in the code or have
> >> clear way to do this? 
> > 
> > The code should print out which attributes it receives. If it
> > doesn't, supply a patch to fix it.
> > 
> > Alan DeKok.
> > -
> > List info/subscribe/unsubscribe? See
> > http://www.freeradius.org/list/devel.html
> > 
> > 
> 
> -- 
> 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
> Sent from the FreeRadius - Dev mailing list archive at Nabble.com.
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Thu, 08 Jul 2010 16:16:54 +0200
> From: Alan DeKok <aland at deployingradius.com>
> Subject: Re: sql module and radgroup...
> To: FreeRadius developers mailing list
> <freeradius-devel at lists.freeradius.org>
> Message-ID: <4C35DDD6.2090009 at deployingradius.com>
> Content-Type: text/plain; charset=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 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.
> 
> 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.
> > 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'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
> > enough for all this to go away, but still. It'd be nice.
> 
> As always, patches are welcome.
> 
> Alan DeKok.
> 
> 
> ------------------------------
> 
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
> 
> 
> End of Freeradius-Devel Digest, Vol 63, Issue 1
> ***********************************************
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20100712/946c1dd3/attachment.html>