Atomicorp

So, Scott, you're not sure if your packages are affected by this bug?

Clearly 4.4.1 has issues with some apps, from what I've been seeing in the way its coded is that they're trying to push more security features into php. So we're seeing the fallout from that, and I definitely expect to see a lot more as time goes by. This warrants a different approach from my side, what I dont want to do is get into maintaining an independant php code base. I'm one guy and thats a job for 10 guys, plus 50 testers.

Ive been thinking about creating some suite rpms, in the same style as project-gamera, ossim-suite, or atomic-psa, but focused on getting major revs of mysql or php on or off your system quickly. But I'm not sure how to do that yet, given the way rpms work. Rollbacks are this mythical feature I hear about with rpms all the time, but for the life of me I've never seen anyone actually do it in what Id consider a realistic way.

scott wrote:Clearly 4.4.1 has issues with some apps, from what I've been seeing in the way its coded is that they're trying to push more security features into php. So we're seeing the fallout from that, and I definitely expect to see a lot more as time goes by. This warrants a different approach from my side, what I dont want to do is get into maintaining an independant php code base. I'm one guy and thats a job for 10 guys, plus 50 testers.

Ive been thinking about creating some suite rpms, in the same style as project-gamera, ossim-suite, or atomic-psa, but focused on getting major revs of mysql or php on or off your system quickly. But I'm not sure how to do that yet, given the way rpms work. Rollbacks are this mythical feature I hear about with rpms all the time, but for the life of me I've never seen anyone actually do it in what Id consider a realistic way.

Yup I think that's a great idea. The perfect ART archive for me would be something like:

[atomic-psa] - just the core plesk - installable via yum
[atomic-php-mysql-compat] - a conservative releate mysql eg 4.0.25 / php 4.4.0
[atomic-php-mysql-stable] - like the current one - eg mysql 4.1 php 4.4.1
[atomic-php-mysql-bleeding] - mysql 5 , php 5.1
[atomic-spam-clam] - spamassassin / clamav stuff

That way you could install the atomic-psa stuff first and then add the specific channels you wanted for your server. In terms of the 'compat' archive; if it was available I would certainly suggest to my company that they pay for access to such an archive on the basis that they could keep their servers up to date and secure without introducing problems (like the different timestamp behaviour issues in mysql 4.1 and these issues identified in php 4.4.1)

I know this is a lot harder than it sounds; just my ideas

Youch, you have no idea how much trouble that would be to maintain. I'm thinking more along the lines of going back to using the -unstable channel again.

[atomic] <- mainstream packages
[atomic-unstable] <- known integration issues
[atomic-testing] <- untested packages


Anything that is in a known state of incompatibility would stay in the -unstable channel until those problems are resolved.

Sounds like a good idea to me.

I installed 4.4.1 on all my servers and it's working fine (I'm not using that ad software or anything).

It broke several of our domains running WordPress 1.5.2. They can no longer connect to the databases.

How can I revert to your previous version of php without breaking Plesk in the process?

Plesk has it's own php engine, so you shouldn't need to worry about that. You can download the rpms of the previous version and rpm -Uvh --oldpackage them.

Nope, already broke Plesk doing that. The doh-doh bird didn't stop psa before doing so. (me = doh-doh bird)

Already asked if there was a way to get the migration working so I can transfer the sites over to another server. 2nd server can't connect due to the php problem on the 1st server.

Don't want to bring down other client accounts if possible.

I have backups, but would rather fix this without a re-image.

We'll see. It'll work out either way.

Thanks

phatPhrog wrote:Nope, already broke Plesk doing that. The doh-doh bird didn't stop psa before doing so. (me = doh-doh bird)

You broke Plesk while installing php packages? I've up- and downgraded php on several servers without stopping psa and I never had a problem with that.

I guess some can....and some can't.

Plesk is clearly busted on the server we updated to 4.4.1. Only after, of course, that I tried to roll it back without stopping PSA.

PSA uses its own independent version of PHP and apache. Upgrading or even removing php from the system completely wouldn't have any effect on it.

Don't know what to say other than Thank you Scott and Breun.

This is the result of Plesk since our yum remove and yum install to restore php.

[LINK removed. See following post]

Fortunately, we have backups, we're hoping to restore it without having to take down client sites.

Thanks again.

Found a forum post at http://forum.ev1servers.net/showthread.php?p=349663

Ended up finding my /usr/loca/psa/version file to be empty. After inserting the version info I have limited control of Plesk again.

Still don't have full control, but we're getting there.

Thanks again everyone!

What control don't you have?

Maybe /usr/local/psa/bin/autoinstaller can help you install missing psa packages if that's the problem and you can't get in through the web interface.