Date: Fri, 6 Sep 2002 19:40:31 -0400 From: Scott Lambert <lambert@lambertfam.org> To: freebsd-isp@FreeBSD.ORG Subject: Re: OT? MySQL based RADIUS servers Message-ID: <20020906234031.GA3180@laptop.lambertfam.org> In-Reply-To: <20020906174341.U8414-100000@lethargic.dyndns.org> References: <20020906202221.GA2208@laptop.lambertfam.org> <20020906174341.U8414-100000@lethargic.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 06, 2002 at 06:01:53PM -0400, Jason Hunt wrote: > On Fri, 6 Sep 2002, Scott Lambert wrote: > > > I ran ICRadius at another ISP before it was "stable". I didn't know it > > had been upgraded to a "stable" condition yet. It ran ok for us as long > > as I had a watcher daemon on it to restart it on the very many occasions > > when its accounting daemon went away. > > > > The only time I've experienced that happening was if MySQL died. > Then again, it could be co-incidental .. It was happening several times per hour on each box. MySQL was active, and available at all times. > Other than that, IC-RADIUS has been great for an SQL-based RADIUS server. > One of the nice things is that it stores the accounting information in a > table, allowing you to apply "Monthly-Time-Limit" and "Total-Time-Limit" > restrictions on a user. The downside to this is if you don't clean out > the table every few months it could get pretty bloated and lagged on > responses. I got around this by having a script run on the first of the > month that moves logs from the previous month to a second table. I then > have a interface users can log into to check their time usage, which reads > both tables. My accounting records table hit 2.1GB before I had a problem with speed of queries on a dual PII400 with 256MB RAM. That was 10 months of records, IIRC. We rolled any records older than 6 months into an archive table and were happy. Gnu-RADIUS also has SQL accounting. > However, I think that if you are expecting to have thousands of users, > with hundreds of access-requests per minute, you might be better off, > performance-wise, to use something that is file- or directory-based. At a > former ISP, we had the accounting scripts generate a new users file > whenever there were modifications to an account. I'm starting to > experiment now with an LDAP-based solution. I expect that getting a > result from LDAP would be quicker than MySQL when you're searching through > 20,000+ users. Of course, if you just need something small, MySQL > solutions are very effective. Uhm, does 15,000 users and ~1,800 ports count as "thousands of users"? I'm not sure how many auth requests we had per minute. We pushed the users table to MySQL on each radius box. There were three RADIUS boxes. They also did DNS and MX duty. They were PPro200s with 80MB of RAM. We logged acct recs to a central server (the BillMAX box). If, for some reason, the central server was unavailable, we logged the acct recs to the local MySQL server and we merged them into the central server two times per day with a python script. About half our access servers hit each of two radius servers. They all used the third as a secondary radius server. We never had any radius performance issues. I'm trying to replicate that setup (less the BillMAX parts, dang it) using gnu-radius now. It should work fine from what I've seen but I don't have access to the code we used anymore. So I have to re-write the database consistency checking code. I didn't write it the first time. -- Scott Lambert KC5MLE Unix SysAdmin lambert@lambertfam.org 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?20020906234031.GA3180>