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

[Frank Soyer]

Mmmh, I see that it's a pain for you...
Sorry for rubbing salt in the wound. Chris has explained well too.

OK. Just a last thing, with no relation to that, but I don't think that 
it's maybe not necessary to begin a new post for that :
do you know if someone works or has at least begun a french translation 
of the interface ?
And is this link : http://www.bluequartz.org/docs/translate/index.html 
valid for BlueOnyx ?

Thank you two.

Le 04/04/2012 16:17, Michael Stauber a écrit :
> 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.
>