[BlueOnyx:10038] Re: Conf files replaced by update

[Michael Stauber]

Hi Frank,

> > Generally you shouldn't modify your sendmail.cf. Any modification should
> > go into sendmail.mc, which our updates will never overwrite. So whenever
> > sendmail.cf is rebuilt from the sendmail.mc during an update, your
> > changes will be retained.
> 
> Are you sure ? When I modify the .cf, I need to compile the .mc file as
> sendmail only know this one.

Yes, I am sure. The sendmail.cf is compiled from the sendmail.mc, so your 
changes ought to go into sendmail.mc

> > As for the AdmServ configuration: This is a "no-go territory".  You
> > should not modify AdmServ's configuration for any reason. If you do so,
> > then that will always be at your own risk and will always be entirely
> > unsupported and highly discouraged.
> 
> I understand that it's unsupported, of course. I just wondered if it was
> not an option in yum, maybe...

No, sorry.
 
> Yes, but the 5107 and 5108 are based on Scientific Linux and it's
> problematic for some clients, convincing them to use CentOS instead of
> RH was already complicated, so Scientific Linux.... 

Yes, I'm just at the end of a tree day ordeal to build an updated CentOS-5 
install CD. See:

http://www.blueonyx.it/index.php?mact=News,cntnt01,detail,0&cntnt01articleid=124&cntnt01origid=62&cntnt01pagelimit=100000&cntnt01returnid=62

For the last three days I've been cursing like a drunk sailor at Karanbir and 
the entire CentOS team for delivering such a piece of sh*t (excuse my French) 
distribution like CentOS-5. No, I'm really not the least bit amused and just 
had it with CentOS.

Compared to Scientific Linux (both SL-5 and SL-6) CentOS-5 and CentOS-6 are 
lightyears behind. This starts with availability of major and minor updates 
(where CentOS never seems to see the light of day). 

But it also involves outright snobbism of CentOS, which goes like this: "Oh, 
we know that this is broken. But we only tell you if you ask. And no, we won't 
fix it. At least not until upstream (RHEL) has fixed it. And even then you 
have to wait for a few extra weeks, because we're busy with woreshipping 
Karanbir and he will only release updates once we have sufficiently sweet-
talked him into pushing the button."

Like Chris said: SL is binary compatible to CentOS and whatever was compiled 
to run on either RHEL or CentOS will run on the same version of SL. So there 
is no good reason to choose CentOS over SL. Only a ton of bad ones, which 
includes simply not yet knowing SL to begin with. Yeah, I know. This is a 
problem.

> I know that you had already have this remarks and that you are working on
> the CentOS6 release, right ?

Yes, with much sadness and regret I must say that I will be working on a 
CentOS-6 version of BlueOnyx. I really do NOT want to and it is silly, because 
CentOS just plain sucks. But will have to do it to offer an alternative to 
those who don't know a better Linux distribution even if it falls right into 
their laps <sigh>.

One of the most hillarious good reasons (besides it's quality - of course) to 
choose Scientific Linux is this: It is made by Fermilabs and Cern. So no 
matter if you live in the USA or in Europe: This is basically the best and 
most productive tax return that you'll ever get. Because the development of 
Scientific Linux is basically funded with your tax money. ;-)
 
> If it's so, I suppose there is no possibility to just install the
> "base-*" files from 5607 or 5608 on this boxes, by modifying the yum
> repos, and keeping the PHP5.3 installed ?

Hell, no!

Look at this URL: http://devel.blueonyx.it/trac/browser/BlueOnyx

Except for ...

base-alpine
base-admserv
base-blueonyx
base-java
devel-tools
i18n

... all the base-* modules are identical between 5106R, 5107R and 5108R.

Some modules (that are identical) just check on installation which platform 
they are being installed on and may then make some post-install adjustments to 
get things right.

Mixing repositories is a receipe for desaster. That's like crossing the beams 
in Ghostbusters and will lead to a spectacular self destruction.

Even if you just try to force the 5107R RPMs into a 5106R box, then that won't 
work either, as both use different versions of RPM. So the 5106R box can't 
even open the RPMs. And if it would, the dependencies would fail due to 
different GLIBC versions.
 
> The servers where the webUI was broken was 5106, but was up-to-date
> (redhat-release say "5.8"). Do you mean that the files are updated but
> always for a version 5.1 of PHP ? Do you maintain 2 branches, for PHP
> 5.1 and PHP 5.3, of the UI ?

See above. Yes, we have three code branches:

One set of code with the above listed modules for 5106R only. 

One set of code with the above listed modules that works on 5107R and 5108R 
only. In SVN that's the 5107R code branch.

Then there is the third branch of modules (which contains the majority of the 
modules) that will compile and run anywhere. They're in the "ui" and "utils" 
directory.

> To be clear about the problem described, I haven't *moved* the admserv
> directories, but *copied* them in another location. So the updates of
> "base-*" have been applied in the original directories. When the files
> php.ini and php.conf were replaced, the pathes returned to these
> directories, and then admserv restarted with the installed PHP : 5.3.8,
> but in error.

Yes, but sadly that approach is flawed to begin with. Yes, it works. But for 
how long? Well ... until the next major update. And then it breaks hard again.

The third party PHP modules from Solarspeed and Compass Networks use a 
different approach: The third party PHP is installed into a separate path. The 
public Apache then uses the third party PHP, while AdmServ remains unchanged 
and continues to use the OS supplied original PHP.

This causes no conflict and will survive through any minor and major YUM 
updates without any problems.

> About that, can you tell me if the prices given on Solarspeed for
> example are a definitive prices, or a yearly (monthly ?) rental ?

At the present the Solarspeed PHP is a one time purchase per server. But 
sometime near the end of the month there will be an optional subscription 
model for updates. So whatever the latest PHP is, if you go for the 
subscription model you always get access to the updates and can install them 
through the GUI at a time of your choosing.

-- 
With best regards

Michael Stauber