[LON-CAPA-admin] Re: LON-CAPA and RedHat Support

[Guy Albertelli II]

Hi Peter,

>     The discussion of what distribution to support is great and all but 
> why is LON-CAPA limiting itself to one distribution over another?

In general it isn't. You can go right ahead and get it working on
any system you want.

There are or have been test systems that are running RH 8.0, 9,
Severn, Debian, and Gentoo (and I believe Colorado got 99% the way
there with Debian this summer.)


The problem is something you alluded to, we depend on alot of
other software to be properly built and running

- MySQL
- Apache 1
- Mod_perl 1
- perl
    - and a very large number of Perl Modules, a large portion of
      which there aren't Redhat complaint rpms for
- gnuplot (with GIF support)
- libgd
- Kerberos (both 4 and 5, and yes you need a real krb4 if you want to
            talk to kerberos 4 servers, and I have yet to get krb4 to
            build on RH8/9 something in gcc changed that it isn't
            happy about.)
- LaTeX
- pstops psutils
- mod_auth_external
- pwauth 

Additionally, there are apache modulas which interfere with Lon-CAPA
(php, mod_throttle), software settings that can seriously hinder
Lon-CAPA (missing www user, missing mysql database/user, improper
firewalls settings, improper ntp settings)

Thus we try to automate the install, along with prepackaged rpms for
what RedHat doesn't provide.


We have also provided general instructions for other distributions.


But It takes not an inconsiderable amount of effort to do this and
test it (each full install cycle can take an hour), and it gains us
very little in the overall picture (no comparison studies of CMS ever
compare the ease of install :-) ).


Thus supporting more systems has never been too important.


>     Certainly LON-CAPA requires an installation of MySQL, Apache, Perl,  
> gnuplot, the system itself, and...?  The only *real* difference between 
> any given distribution is (1) support from the company (2) installation 
> tool, (3) proprietary configuration tools like YaST, (4) file system 
> layout -- which using LSB should be standardized, and (5) choice of 
> apt/emerge vs. rpm vs. ...

4 and 5 end up being more work than you might at first realize.


>     Given that I haven't looked through the inner workings of the code, 
> the following should be taken with a grain of salt.  But, if L-C only 
> requires the above tools plus others available as rpm's,

Some of the tools aren't available as rpms.


> it seems like 
> for any given RPM-based distribution (Fedora/RedHat, Mandrake, SuSE, 
> ...) a .src.rpm should be fairly easy to produce that checks appropriate 
> RPM dependencies and does the install.  I must admit I've always been 
> baffled by the strict adherence to not only RedHat but RedHat 7.x --

This was due to Redhat dropping support for Apache 1 and mod_perl 1

We can't run inside Apache/mod_perl 2 and when trying to get the
install to work on RH 8/9 with a rebuilt apache/mod_perl 1 this summer
things kept dieing somewhat randomly, we have figured out what was
causing this (an error on my part) and thus will be getting the
RH9/Fedora install done soon.

> Also, a standard gnumake 
> would be fantastic.  If the problem is related to where tools are 
> placed, simple use of environment variables, command-line options, or 
> ./configure should take care of it...

Sigh, all of this always seems simple but takes up significantly more
time and effort then you might first think.

-- 
guy at albertelli.com  LON-CAPA Developer  0-7-5-3-