Thanks Lonnie,
On May 23, 2006, at 4:23 PM, Lonnie Olson wrote:
>
> On May 23, 2006, at 12:49 PM, Isaac Levy wrote:
>> I'm wondering if anyone here has experience with
RADIUS servers? I'm
>> setting one up for a fun project (wireless captive
portal), and not
>> all that exited about using FreeRADIUS- lots of
unanswered questions
>> in my brain...
>> That stated, my concerns are with ease of
management, and redundant
>> replication for high-availability.
>
> I only have experience using Radiator, so I am a bit
biased.
> http://www.open.com.
au/radiator/
Sweet- something new to grok...
>
>> I'm basically concerned about scale issues-
>>
>> 1) For a network of 300-5000 users, do the standard
unix /etc/
>> password files scale sanely? I mean, the docs have
this as the
>> default config for user db, which is a type of data
backend I'd
>> usually have in some other kind of DB. It just
seems like a recipe
>> for poor scalability.
>
> I think it would work ok for that many users, but not
much more.
> I use an SQL backend for my main radius setup with
about 4000
> users, but that is kept in sync with the passwd files
for my legacy
> apps. It is pretty ugly, but it works.
Gotcha.
>
>> 2) LDAP backends? Is this common practice? (I'm
concerned about
>> over-
>> complexity)
>
> LDAP does introduce quite a bit of complexity, but
could be useful
> if you have many applications that do authentication.
> I actually would like to move in that direction
"some day". If
> this is just for radius, don't even bother.
This is just for RADIUS, and with only one application
connecting to
it- totally (purposefully) isolated from anything else.
>
>> 3) SQL backends? Is this common practice? (Again,
concerned about
>> over-complexity)
>
> SQL backends work well, and won't introduce much more
complexity if
> you are already maintaining a db server. However it is
not quite
> as ubiquitous as LDAP in your apps. (unless you look
at pam_mysql)
Gotcha. I think, with my application, SQL and LDAP backends
seem to
be about the same amount of complexity to add- both are
extra
software to manage/secure, both need some kind of library
for the
server to interact with them, more or less.
>
>> 4) Custom RADIUS implementations- RADIUS is more or
less just a
>> protocol, with defined parameters for how it
manages the big AAA.
>> Since it's the data backend I'm concerned about,
(and know a lot
>> about how to deal with), I'm thinking of just
implementing a simple
>> RADIUS server on top of databases I know and love?
I've found a
>> good-
>> looking RADIUS library in Python, my favorite
language, and I was
>> thinking of rolling my own server with a tiny,
easily replicatable,
>> Python embedded DB. It seems the simplest route to
me, but I'm
>> hesitant because I feel there may be
best-practicices for heavy
>> RADIUS users? (ISP's, Telcos, anyone managing
remote AAA)
>
> Radiator will connect to a whole lot of different
backends. It is
> extremely configurable, but has a moderate learning
curve.
I'm going to look at the map before I go down the path, so
to speak-
and feel it out- (I'm bound to at least learn something,
right?)
>
> If you are just looking for a radius server with a
separate
> authentication database, Radiator w/ an SQL db backend
will work
> fine. However it might be better in the long run to
take the time
> to centralize you authentication if you can.
>
> --lonnie
Thanks for the experience Lonnie- much appreciated.
Rocket,
.ike
_______________________________________________
% NYC*BUG talk mailing list
http://
lists.nycbug.org/mailman/listinfo/talk
%Be sure to check out our Jobs and NYCBUG-announce lists
%We meet the first Wednesday of the month
|