Date: Sat, 7 Oct 2000 17:33:58 -0400 From: "Troy Settle" <troy@psknet.com> To: "Odhiambo Washington" <wash@iconnect.co.ke>, <freebsd-isp@freebsd.org> Subject: RE: Radius and Accounting Message-ID: <BFEGKDHLHDNOJEIHJDBAAEDJCAAA.troy@psknet.com> In-Reply-To: <20001007224813.A29067@siafu.iconnect.co.ke>
next in thread | previous in thread | raw e-mail | index | archive | help
> > * Troy Settle <troy@psknet.com> [20001007 22:26]: > => > =>1. It almost sounds like you've gone and deployed a radius > server at every > =>POP. While I'm sure there's plenty of arguments for doing > this, you should > =>be aware that a single radius server (even on a 486) can handle many > =>thousands of ports. I can't speak for others, but I know Cistron is > =>reliable enough to trust as a single radius server (though a backup is > =>always a good idea). At the very least, make sure that all > your users are > =>in a single user database (/etc/passwd, the users file, whatever), and > =>distribute it among each radius server (they should probably > all have the > =>exact same configuration by the time you're done). > > > I did this yes ;-) for two POPs but we're going to have 2 more POPs and I > am concerned about it. At current we use PortMaster 2E (old stuff!) and > Radius on FreeBSD. I also use proxy radius. When you have a single radius > server and you've got to authenticate from more that 3 POPs, I thought > there would be some concern on authent traffic on the link btn the POPs. Radius is extremely lightweight on the network. In fact, you could probably authenticate several hundred (if not thousands) of ports over a 56k dialup. If all of your POPs are connected back to your main office, then having multiple radius servers spread out will just create an administrative hassle. However, if each of your POPs have their /own/ upstream connection, then perhaps having your secondary authentication server in a remote POP would be a good thing (in case you lose connectivity at your main office). > > On a single user db, my only worry is that of how I can merge the info rqd > by radius (as in the /etc/raddb/users) into /etc/passwd?? That kinda makes > it difficult.. I'm not sure what you mean. I didn't keep passwords in the users file. What I had, was a DEFAULT profile worked for about 99.9% of all users. The few remaining users (MLPPP, static IP, subnet, etc..) had their own profiles. Out of ~4k users, only 30-40 had their own profile. So, Radius looks at the users file for authorization, but uses the system passwd file for authentication. > > => > =>In a previous position, we had a secondary radius server. Accounts were > =>created on the primary, then the passwd file was distributed to the > =>secondary by a script that checked for updates every 5 minutes > (if a user > =>signs up or changes their password over the phone, they > shouldn't have to > =>wait too awful long to use the 'net). I also had a simple > script that I ran > =>to copy any changes to the radius configuraiton itself (clients, users, > =>realms, etc...) > > Almost what I am looking for!! Any possiblility of sharing those scripts, > please. I must plead because I am not a programmer...I am those network > engineers promoted to sysadmin ;-) but I'm thinking of embracing perl, > though I must swear I need more time. I just used a simple shell script. I'd gladly share it, but no longer have access to that network or backup media. It was fairly trivial. Every 5 minutes, check against a backup copy of the password file. If it's different, make a new backup, scp it to a list of target hosts, and you're done. Same thing for the radius config files. > > => > =>2. Check /usr/ports/net/radreport. It's fairly primitive, but > will give > =>you the information you want. If you need something more > advanced, I would > =>suggest SQL. A lot of folks have started dumping their accounting data > =>directly into SQL (my radiusd doesn't even think about writing > a detail file > =>to disk any more). Having the data in SQL, I can generate > reports whenever > =>I like. I can even have a realtime web interface for customers > to see how > =>many hours they've spent online and how much data they've transferred. > > Now that is superb!! Any HOWTOs towards achieving this??? Howto get radius > to write directly to SQL db?? We have 2 SQL programmers who I believe will > assist with some coaxing... If you got some SQL people, then you're set. Most radius daemons should be easily modified to do this. I wrote a patch against Cistron radius 1.6.1 or so (should work on all current versions). It's available from the freeradius.org ftp site. I'm not, however, supporting that patch at this time (I believe there's several dozen others who are currently using it. It does work). I'm currently contemplating re-writing it to add support for SQL servers other than MySQL (each additional server would actually be fairly trivial to hack in). There's a few other modifications for adding SQL support to Cistron there as well. None of them suited my needs, but they may suit yours. ICRADIUS, for example, seems to be a very well written (if limited) version of the Cistron server and soon the freeradius server. It has extensive support for MySQL. -- Troy Settle Pulaski Networks 540.994.4254 It's always a long day, 86400 doesn't fit into a short To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BFEGKDHLHDNOJEIHJDBAAEDJCAAA.troy>