Index: [Article Count Order] [Thread]

Date:  Mon, 23 Apr 2007 13:17:57 +0200
From:  =?ISO-8859-1?Q?Tom_M=FCller-Kortkamp?= <tmueko (at mark) kommunity.net>
Subject:  [coba-e:09664] Re: Upgrade to CentOS5
To:  coba-e (at mark) bluequartz.org
Message-Id:  <AEDA79F0-D1E4-4979-AD78-31B7593E4D07 (at mark) kommunity.net>
In-Reply-To:  <200704231112.57002.bq (at mark) solarspeed.net>
References:  <F3C39080-9B4F-43E9-B66C-3B0082DA9A6B (at mark) kommunity.net> <200704231112.57002.bq (at mark) solarspeed.net>
X-Mail-Count: 09664

Am 23.04.2007 um 11:12 schrieb Michael Stauber:

> Hi Tom,
>
>> So, CentOS-5 is out.
>> How can one help the development/upgrade of BlueQuartz to Apache-2.2
>> and PHP5?
>
> I already looked at it over the weekend. I took a development BQ  
> box and
> forcefully upgraded it to CentOS-5 to see what it would break.
>
>    ****** To each and anyone: Don't do that on a production box!!!!  
> *********
>
> The newer Apache 2.2 no longer has the mod_cband module and a  
> couple of other
> modules. So during startup AdmServ complains six days to Sunday  
> about missing
> modules. Commenting them out one by one I eventually came to the  
> mod_cband
> module, which we use for bandwith management. That particular  
> module is
> apparently missing in Apache 2.2 and we'll have to manually supply  
> it again -
> if it still builds under Apache 2.2.
>
> Likewise, a couple of Apache related handlers and constructors may  
> need minor
> tweaks and adjustments to cope with some Apache 2.2 related changes  
> in config
> files.
>
> Now on to the heart and soul of BlueQuartz:
>
> CentOS-5 comes with PHP-5.1.6, so the i18n PHP module must be  
> ported to PHP5.
> Without that Sausalito won't run, which will be the biggest show- 
> stopper.
>
> The next and certainly saddest point are the many API changes  
> between PHP4 and
> PHP5. This forces us to go through a *lot* of old code in each and
> any "base-" package of the GUI to change old syntax to the new syntax.
> Messing with "Register Globals" may serve as a short lived work  
> around to
> cope with some of the fallout, but sooner or later this will get  
> deprecated.
> So we might as well do it right now and save us some headache later  
> on.
>
> All in all this ain't easy and can't be done on the fly.
>
> The starting point would of course be porting i18n to PHP5 to get  
> CCE back up
> and then we have to take it from there and fix all broken API calls  
> in the
> base packages.
>
> Help is certainly welcome.
>
> -- 
> With best regards,
>
> Michael Stauber
> http://www.solarspeed.net
>

Hi Michael,

IMHO Bandwidth limitation should be done by IP-Stack/Firewall.
I've never Used this function at a Cobalt so i would remove this  
funktion if it is too much work or to much customisation!

At FreeBSD there is a Port called raqdevil which uses PHP5, so maybe  
the work is allready done?


Tom MÍler-Kortkamp