Re: [cobalt-developers] [ISP Related] RadiusX for Cobalt RaQ2/3 Testing

[Greg Boehnlein <damin@xxxxxxxx>]

On Wed, 16 Feb 2000, Jeff Lasman wrote:

> > > The advantage of what the consultant did was he gave us a complete 
> > install,
> > > PHP, Radius, MySQL, running on the box.  He did all the work.  I think I'd
> > > like seeing such an RPM, myself.
> >
> >PHP Rpms        - http://www.modssl.org/contrib/
> >MySQL Rpms      - http://www.mysql.org/download_3.22.html
> >Radius          - http://www.freeradius.org/
> >Radius w/ MySQL + Web Front End - ftp://ftp.cheapnet.net/pub/icradius/
> 
> But of course after doing this (and I'm only presuming you mean I should do 
> all this in this particular order), I still don't have an ssl-protected 
> website with a point and click interface for adding and modifying 
> customers.  That's what the consultant gave us.

That is why, I assume, you bought a Cobalt product, correct? I'm confused.
Why would you need to hire a consultant to give you the pre-existing
features of the Cobalt RAQ? It doesn't make sense to hire a consultant to
provide the same features of the Raq if you already OWN a Raq!

The Cobalt RAQ-3 runs a modified RedHat 6.0 distribution. Putting RADIUS
on that is a simple, easy task. The Cistron RPMS will install without a
problem on it. If you configure the Cistron RADIUS server correctly, all
you need to do on the Raq3 is add a user and -BINGO- you get E-mail setup,
Home directory, PublicHTML, quotas etc.. RADIUS will authenticate through
PAM, and therefore use any authentication method that you choose, wether
it is the local passwd/shadow files, LDAP, NIS or whatever. There is
nothing to hire a consultant to DO!

I.E. You don't NEED MySQL in this situation, as your authenticating out of
the local password database that is being managed by the Raq interface.
 
> >And if you want to do E-commerce, just scrap the RedHat Apache RPMS and
> >grab the apache_modssl drop in replacements off of modssl.org's site.
> >There are what we use in production on boxes that need more specialized
> >applications than the Raq can provide.
> 
> From your paragraph, repeated above, I got the impression there were RPMs, 
> RaQ-ready, on this site.

Absolutely not. They are designed for -RedHat- Linux, which is what the
Raq distro is based on. Therefore, 99% of the RPMS that are available for
RedHat will plug unto the Raq without much problem. I run a variety of
RedHat 6.1 code on my Raq 3 units, and have personally built a HUGE number
of RedHat 5.2 and 6.0 packages for the MIPS based Raqs. Check out
ftp://intel.cleveland.lug.net/pub/Mipsel if your looking for stuff for the
MIPS.

> There aren't.  I've got no problem installing from tarballs on my
> server, but a lot of RaQ owners do; see the cobalt-users list for the
> clue-level of many RaQ owners (not meant to be any kind of put-down;
> merely an observation of the fact that Cobalt's advertising of the RaQs
> as appliances is paying off for them <smile>).

I have no qualms about stating the complete idiocy of a majority of the
cobalt-users list. The Cobalt guys have to be given a LOT of credit for
dealing with some of the crap that is spewed out onto that list by people
that just don't get it! They do an excellent job of answering
un/reasonable questions by the user base. And hey, the Raq is a GREAT
product!

> But personally, I run Red Hat's 6.0 secure web server on a generic 
> (home-built, in fact) multi-processor intel-based box, and I'm going to get 
> a Red Hat 6.1 Professional box done this week.  I don't "love" Red Hat, but 
> I do like the plug-and-play concept; after all, it's what attracted me to 
> the RaQs in the first place.

That's my point. I assume that you hired in a consultant to provide you
the features that attract you to a RAQ, but on the RedHat box. I guess
MORE to the point is that was that the RedHat Secure Webserver is a
crappy design for a Secure Server. I understand why they did things the
way they did, but it still has some very very very serious drawbacks.

Back to what I was saying before.. The RPMS that I pointed out above are
drop in replacements for the RedHat stuff (Secure Server, PHP3) that
provide -MORE- functionality, with a better design, and a much smoother
intergration than RedHat's own products. And they are free software. Of
course, if you want to run more than 56 bit encryption, you will need to
purchase the Raven module and an RSA license to do so, but your supporting
free software in the process.

I run the RPMS listed above on several production, high traffic E-commerce
websites. Indeed, I built and posted the PHP-3 3.0.12 RPMS for the Mod_SSL
contrib site. I've got internal versions that use the OpenLink drivers to
directly connect to Microsoft SQL, which makes it a breeze to intergrate
the Linux server with data in the MS-SQL server. I.E. adding users,
checking records etc.. It fits in and intergrates VERY nicely with the
RadiusX server from IEA-Software, which ALSO use the OpenLink drivers to
facilitate the same communication.

In any case... the point. Short and sweet. Using the packages above, you
don't need to spend the $99 on RedHat's secure server. You don't need to
spend $1,500 on a consultant. It's a simple as..

rpm -e apache-devel
rpm -e apache
rpm -Uvh apache_modssl_...
rpm -Uvh apache_modssl_devel
rpm -Uvh php
rpm -Uvh Mysql

and PRESTO. You have a system that is Redhat 6.1 based w/ MySQL, PHP3 (w/
MySQL drivers) and Apache w/ SSL.

THEN, you can hire your consultant to build whatever interface you like to
it, or check out the Commanche Web interface to managing Apache.

> I don't own any RaQs outright, I rent one, and might eventually rent or buy 
> more.  I've always felt the design philosophy is great, and I love the 
> form-factor and the low power consumption.  But I've always felt the MIPS 
> architecture was too nonstandard to invest in.  And I find the web-based 
> interface quite limiting as it doesn't fit with my business model at all 
> (we don't allow our customers to choose to run or not run mailing lists, to 
> add users at will, and to control logon names).

Yes. When Cobalt sent the Cleveland Linux User's Group our RAQ-1 for
development, we had a goal of porting RedHat 5.2 to the MIPS architecture.
We managed to get about 65% there, but got mired on the "cutting edge" of
Mips technology. I even had a guy that does ECGS development log into one
of our development Qubes and hack EGCS to support and generate MIPS code.
His comment was "I develop MIPS code for Serial Cards that use higher
speed MIPS processors than this unit. It will take 2 weeks to do a full
build of EGCS on this box.".. But he DID it.. And he checked in the mods
to the CVS tree, so current versions of EGCS should build MIPS code
without a headache.
 
> Now that Cobalt is switching to Intel architecture, I will seriously look 
> at RaQ3s as I need to expand further.  I can always reinstall Linux 
> software from scratch and create a system that more nearly matches what I do.

That's been my biggest plea to Cobalt since we got our first Qube to
develop on. When I got the inside tract that Cobalt was releasing the Raq3
on an x86 platform (They use AMD, -NOT- Intel!!!) I ran around the office
screaming "We're going to run Oracle on the RAQ!!!". Everyone looked at me
like I was insane, but just 3 weeks ago, I talked with someone who is
interested in trashing Oracle on NT in favor of 16 RAQ-3 units!!!!!

> I've got the following installed on my RaQ2; all installed as part of 
> consultant-driven solution by my colocation source:
> 
>    Cobalt OS Release 4.0
>    Miva Empresa Release 3.62
>    Miva Merchant Bundle Package (RaQ2) Release 2.00
>    RaQ2-Update-OS Release 2.0
>    Red Hat Secure Web Server Release 3
> 
> And though I know how to be very hands-on, I don't always have the 
> time.  So, yes, I'm very happy to have someone else do most of this for me.

Great. I've run the same configuration on the Raq2 units and it works. The
RedHat secure server is NOT an elegant solution to the problem, but that
is a non-issue on the Raq3, as you can manage the SSL stuff right from the
Virtual Site manager.

This prompted our decision to purchase -ONLY- Raq3 units for hosting from
this point onward in our business. As old RedHat servers in our
organization bite the dust, they will be replaced with Raq3 units. With
the appropriate security modifications and a couple of small
modifications, the Raq3 forms the PERFECT ISP appliance.

> >As for the other stuff, I've used it on RedHat boxes as well as just about
> >every other Linux distro out there. It all works with a bit of tweaking.
> >
> > > My statement about selling it for a good
> > > deal less than $1500 was meant to be tongue-in-cheek.  I just wanted to
> > > point out that having an "expert" install a complete open-source solution
> > > seemed both cheaper and "better" than buying a retail solution.
> >
> >You have to compare apples to apples and oranges to oranges. If you are
> >going to install Cistron, ICradius, or Livingston's Radius, you are
> >getting a bare bones radius server that you can extend if you want to.
> >None of these (except perhaps Cistron) come with the advanced features
> >that RadiusX (Or RadiusNT) from IEA-Software come with. Absolutely NONE of
> >them will interface with Microsoft SQL. While they may form one component
> >in a chain for your billing and authentication "system", they are
> >individual, seperate products that are not designed to work together. On
> >the other hand, RadiusX from IEA works with their complete ISP management
> >back-end, which works TRANSPARENTLY with Linux, SCO or just about anything
> >on the planet. I'm PARTICULARLY pleased to see that they are not
> >supporting the Cobalt RAQ products, as I have been beating on Dale Reed
> >(The Author of Emerald and RadiusNT) to port the backend to Linux for
> >nearly 3 years now.
> 
> And the solution I chose (I was with Jatek at the time) worked for Jatek's 
> business model, and still does.  Jatek doesn't aggressively sell dialup; 
> they make nationwide (Megapop) dialup available to their hosting 
> customers.  It had to be a quick and simple solution.  In fact we almost 
> went with Megapops generic web-based solution, as I recall.
> 
> > > Last year I discussed this on one of the Internet lists.  We were
> > > terminating people who were late.  Everyone came down against me.  It 
> > seems
> > > that a large number of ISPs feel that one major difference between the 
> > "big
> > > guy" ISPs and the little people like us is that we can be more flexible 
> > and
> > > work with people on payments.  At the time we loosened up our late-payment
> > > policies quite a bit.
> >
> >On the other hand, we have made the transition from a small to a large ISP
> >and we can't afford to have people not paying for services they are using.
> >It took some training to get the customers used to the idea that if they
> >don't pay, they don't get access, but after a while you weed out the bad
> >seed and stick with the good. As a result, my cash flow is very steady,
> >and my receivables are extremely low.
> 
> I'm not disagreeing here at all; I'm just reporting what other people told 
> me.  Obviously there are a lot of different feelings on this issue, and 
> Jatek chose to loosen up it's late-payment policies (I had no control over 
> that aspect of Jatek, and I've since left over management disagreements 
> that made it impossible for me to work there as a department head).
> 
> >The IEA Emerald billing manager has completely eliminated the need to keep
> >track of the intergration between Accounting, RADIUs Authentication and
> >UNIX account creation. If a customer is past-due, the RADIUS server knows
> >based on it's database backend that the customer should not be allowed
> >acccess to the network.
> >
> >Intergrated CC billing, batch E-mailing of invoices and all the "goodies"
> >have virtually eliminated the need to have highly trained "technical"
> >staff doing the simple tasks of adding accounts. This can be handled by
> >the low end help-desk people. They add the account in Emerald, and with a
> >couple of clicks, the account is active and ready to go. The information
> >is replicated from MS-SQL to our LDAP servers, which allow our Linux boxes
> >to use NSS-Ldap for authentication purposes.
> >
> >This is a HUGE win. If a server fails in production, all I need to do is
> >stick in a replacement w/ the same IP and point it's LDAP entry towards
> >the master server. BINGO. Instant replacement servr.
> 
> And I believe that when I'm ready for this kind of solution, I'll want one, 
> too.  It's been my experience that most of the RaQ owners I've come across 
> are not in your league; maybe I'm wrong.

I'd hate to think that I'm the only real geek hacking on the Raq series.
In fact, I know I am not!!!! It's just that the others don't seem to be
actively participating in the list! ;)
 
> > > I'm still in the throes of a startup, and my cash flow, while almost
> > > adequate <smile> isn't always smooth.  So I enjoy a more flexible policy
> > > myself <smile, again>.
> >
> >In 1992, I started an ISP with 2 486 computers in my basement, running
> >SCO. No one knows more about cash flow and tight budgets than me. I've
> >hacked just about every piece of free software on the planet related to
> >the provision of ISP services. I assist in providing patches to the Linux
> >port of the Merit AAA Radius server. If it isn't out there, I find
> >something that fits closely and modify it. This is the beauty of Open
> >Source. This is the flexibility of OpenSource. This is what makes the fact
> >that Cobalt is basing their product on Linux such an enourmous gain for
> >people with the knowledge.
> 
> I began using SCO-Xenix back in it's early days, too; somewhere around the 
> late 80s.  I studied it as a platform for supplying multi-user business 
> management systems for the garment manufacturing industry, which is what I 
> was doing then (Microsoft didn't make a good multi-user solution then; they 
> still don't <wry grin>).
> 
> >But there is a whole section of people out there that don't want, need or
> >have the time to hack the source themselves. They are called "end users"
> >and not "hackers". There are also us "hackers" that don't have the time to
> >modify every piece of software that comes along. If a commercial piece of
> >software does the job with minimal effort, it is worth the long term
> >savings in development and code maintenance.
> 
> I agree with everything in this statement.  In fact the reason I chose a 
> consultant to install the system that started this whole discussion was 
> that I didn't have the time to do it all myself.
> 
> > > >I am greatly simplifying it, but for users of the Emerald billing package,
> > > >having RadiusX available to run on the Linux platform instead of IEA's
> > > >RadiusNT on NT removes one more dependence on a Microsoft product.
> > >
> > > Obviously it works for you.  But... while you're saying that using RadiusX
> > > with Emerald removes a dependency on a Microsoft product, it seems to me
> > > that depending on another package rather than Emerald could remove your
> > > dependencies even further <grin>.
> 
> Just curious?  Did you notice my <grin>?
> 
> I'm a tool-user myself, and my desktops are all Microsoft (combination of 
> WinNT and Win98); I'll change to Linux desktops when all the tools I want 
> to use every day are available on them, not before (and for those who will 
> argue I can find similar tools, I'll just say, "why bother? what I'm using 
> now works for me").
> 
> > > Of course you've decided to go with Emerald, and obviously, for you, 
> > that's
> > > fine.  And you've decided to go with RadiusX.  For you, again, that's fine.
> >
> >After 4 years of using Free Radius servers, running an accounting system
> >on QuickBooks for some 5,000 users, my decision is based on experience.
> 
> I think so.  Quickbooks isn't a solution for 500 users, no less 5,000.  At 
> the moment my solution is a modification of some software I wrote years ago 
> in a language called DataFlex, back when I was president of the DataFlex 
> Professionals' Guild.  And no, it doesn't do everything.  I'll put in a 
> more robust solution at some point, I'm sure.  If it ever becomes important 
> to me to link my Radius into my accounting, I'll do it.  As I said, I'm a 
> tool-user.

Speaking of this.. It just occurred to me that Appgen could make a killing
if they considered releasing a version of PowerWindows that specifically
intergrated with Radius, Web and other accounting information in real
time! I should ask them if this has ever come up in their discussion with
ISPs..... Whole new market for them, and it's a Linux native solution that
could replace Emerald in my organization! ;)

> >that RadiusX has into Cistron, or Livingston's radius, you would have at
> >LEAST a 6 month development and testing cycle before you got the first
> >working alpha out the door.
> 
> Again, if and when I become a high-volume ISP, I'll be interested.  I still 
> don't think most of the people on these RaQ lists are; maybe I'm wrong.