Re: Cistron-Radius Users
Hi, On Thu, 14 Mar 2002, Russell Coker wrote: The only thing that would move him is if I get some success stories from using cistron radiusthe bigger the number the better. So, you guys know of BIG names (or numbers) using cistron radius?? I've worked on two large RADIUS server installations. One was running FreeRADIUS (a PERL based RADIUS server that's slow as a dog but even so is able to serve requests for 1,000,000 users). The other was running a RADIUS server that has since been bought out by Cisco. That must have been Radiator, not FreeRADIUS. FreeRADIUS is written in C and in some cases it's said to be faster than Cistron. Of course, it's hardly the radius server itself that is the bottleneck here, but the backend database, especially if you're writing accounting information. *That* tends to be the hardest on a RADIUS server, not authentication. Measuring the amount of fully static authentications may give a nice big number, but it doesn't mean a thing - just like the IIS vs. Apache comparison. The Cistron RADIUS server is a solid product that's well tested. The source is available and it's easy to upgrade if you find a bug. I can second that, having implemented it on a number of occasions. Cheers, Emile. -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153| http://www.e-advies.info -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cistron-Radius Users
On Thu, 14 Mar 2002 13:35, you wrote: On Thursday 14 March 2002 11:09, Russell Coker wrote: I've worked on two large RADIUS server installations. One was running FreeRADIUS (a PERL based RADIUS server that's slow as a dog but even so is You mean radiator? freeradius is written in C and quite fast, usable and extensible (it has a good modular design). Of course I meant Radiator, I can't believe that I wrote that! Must have been too early in the morning for me or something. Yes, Radiator is slow as a dog but still workable. FreeRADIUS is really fast and well written. I'm using it in production (a few thousand users dialing into *spit* USR total control) and I'm quite happy with it. Sorry for not sending this to the mailing list, but I don't like to expose my e-mail address if it's not really necessary. No probs. I'll BCC you and reply to the list. Thanks for informing me of my mistake! -- If you send email to me or to a mailing list that I use which has 4 lines of legalistic junk at the end then you are specifically authorizing me to do whatever I wish with the message and all other messages from your domain, by posting the message you agree that your long legalistic sig is void. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cistron-Radius Users
On Thu, 14 Mar 2002 14:18, you wrote: On Thu, 14 Mar 2002, Russell Coker wrote: I've worked on two large RADIUS server installations. One was running FreeRADIUS (a PERL based RADIUS server that's slow as a dog but even so is able to serve requests for 1,000,000 users). The other was running a RADIUS Afaik freeradius isn't perl-based, it doesn't even allow perl scripting. But I'm interested in a working perl-based radius server if one exists, so please tell me its name if you can. We're using freeradius now but it's a bit far from stable. Correct, the Perl based RADIUS server is Radiator. My experience of FreeRADIUS has been that it's stable, but I expect it depends what features you use. -- If you send email to me or to a mailing list that I use which has 4 lines of legalistic junk at the end then you are specifically authorizing me to do whatever I wish with the message and all other messages from your domain, by posting the message you agree that your long legalistic sig is void. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cistron-Radius Users
On Thu, 14 Mar 2002 13:57, Emile van Bergen wrote: Of course, it's hardly the radius server itself that is the bottleneck here, but the backend database, especially if you're writing accounting information. *That* tends to be the hardest on a RADIUS server, not authentication. There is the issue of whether the RADIUS server is multi-threaded or forking, or if it does all database lookups synchronously. If the RADIUS server can only have one database lookup outstanding at any time (such as Radiator) then it'll be quite slow, and minor issues such as a small amount of network congestion between the RADIUS server and the database server can really kill performance. Multithreaded servers such as FreeRADIUS don't have this problem and can deliver much greater performance. -- If you send email to me or to a mailing list that I use which has 4 lines of legalistic junk at the end then you are specifically authorizing me to do whatever I wish with the message and all other messages from your domain, by posting the message you agree that your long legalistic sig is void. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cistron-Radius Users
On Thu, 14 Mar 2002, Russell Coker wrote: On Thu, 14 Mar 2002 13:57, Emile van Bergen wrote: Of course, it's hardly the radius server itself that is the bottleneck here, but the backend database, especially if you're writing accounting information. *That* tends to be the hardest on a RADIUS server, not authentication. There is the issue of whether the RADIUS server is multi-threaded or forking, or if it does all database lookups synchronously. Or neither, but a design based on pre-spawned childs for all operations (such as database operations) that take some time to complete. Such as OpenRADIUS, incidentally written by yours truly. I think that's generally a better idea than multi-threading. Having multiple threads in the same address space always adds complexity, and I tend to avoid it unless I really can't. FreeRADIUS modules also have to deal with module instantiation themselves if you want to run multiple copies of a module. OpenRADIUS uses Unix's standard facilities (copy-on-write) for that, which makes them a lot simpler. The server itself only has to keep track of all outstanding I/O happening to and from modules in the background. The only performance drawback is the pipe I/O instead of C calls, but that has the advantage that you can write modules in other languages than C. If the RADIUS server can only have one database lookup outstanding at any time (such as Radiator) then it'll be quite slow, and minor issues such as a small amount of network congestion between the RADIUS server and the database server can really kill performance. Of course. Does Radiator really handle all external operations synchronously? Boy. Multithreaded servers such as FreeRADIUS don't have this problem and can deliver much greater performance. If you're interested, see http://www.openradius.net for another approach. Cheers, Emile. -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153| http://www.e-advies.info -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cistron-Radius Users
On Thu, Mar 14, 2002 at 11:09:30AM +0100, Russell Coker wrote: The Cistron RADIUS server is a solid product that's well tested. The source is available and it's easy to upgrade if you find a bug. What happens when a bug is found in the Navis? What happens when you discover you have a critical need for a feature it lacks? Or when Lucent treats their RADIUS server like the Portmaster line they acquired from Livingston. What Portmasters? they say. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cistron-Radius Users
On Thu, 14 Mar 2002 16:19, Emile van Bergen wrote: Or neither, but a design based on pre-spawned childs for all operations (such as database operations) that take some time to complete. Such as OpenRADIUS, incidentally written by yours truly. I think that's generally a better idea than multi-threading. Having multiple threads in the same address space always adds complexity, and I tend to avoid it unless I really can't. That's a matter of opinion. I'd choose multiple threads over multiple processes any day. The problem with multithreading is that debugging can be a bitch. Core files don't support multi-threading, debuggers have problems with it too, so too often you end up doing printf() debugging. The positive thing about threaded programming is that there's no cost to transferring data between threads. You want to malloc() in one thread and free() in another, no probs. This adds some extra freedoms to the design. Would you like to have one thread for reading data from the net, a pool of threads doing database lookups, then another thread writing responses? It's no challenge to code. Mainly I think it's what you're most experienced with. You obviously have more skills in fork() based programming so I won't try and convince you to change your programming style. But threaded programming can work equally well if you've had some practice. Of course. Does Radiator really handle all external operations synchronously? Boy. Yes. Also even without that issue the performance isn't particularly stunning. Threaded programming in Perl is apparently extremely difficult. Multithreaded servers such as FreeRADIUS don't have this problem and can deliver much greater performance. If you're interested, see http://www.openradius.net for another approach. Are you going to package it for Debian? Also are you planning to attend the Debian meeting in den Haag on Saturday? -- If you send email to me or to a mailing list that I use which has 4 lines of legalistic junk at the end then you are specifically authorizing me to do whatever I wish with the message and all other messages from your domain, by posting the message you agree that your long legalistic sig is void. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Cistron-Radius Users
Hi, Ive a client that wants to choos his radius platform. Despite my say that its not that important and that a cistron/debian/Big Baad carrier class hardware radius would more than take care of him (c'mon...its like 2000 users tops!), he still wants the lucent navis thingie. cant blame him, it has some mean java apps for configuration and a very propietary language for (get this) Policy speciffication (which is long for fallback authent). The only thing that would move him is if I get some success stories from using cistron radiusthe bigger the number the better. So, you guys know of BIG names (or numbers) using cistron radius?? Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
