What to expect and prepare for when moving from LAMP to SAMP

Question

My company has a very real problem with patch management on our web servers. The public servers are out of date, and now management considers this a priority. However, rather than simply updating and patching the existing servers (and all the testing that goes along with that) they have embarked on the process of migration to Solaris servers as a way to "mitigate the problems". (I think it is because they happen to have some solaris servers sitting around)

I have no problems with Solaris and I see that technically all my php web code should run fine with the MySQL databases. I also understand it takes as much thought and testing to upgrade from php4 to php5.

What I want to know it what sort of gotchas should I have my head up for when the server team comes back and tells me my code doesn't work. I want to start looking for headaches now to ease the transition.

We have last generation of the stack currently, and I assume they will put in the current generation when they upgrade and migrate the servers for PHP, MySQL, and Apache

Question Summary: My company is moving from PHP4 sites on Linux servers to PHP4 sites on Solaris servers. What issues should I look for in preparing my code for the move?

Answer 1

Which version of Solaris, if you know?

There will be very little difference at the php4 level, presuming they install the same or newer version of PHP and MySQL. What's more likely to break when moving to Solaris is shell or C code, so if you're responsible for any of that as well, you'd have more work to do.

On the subject of shell, it's worth remembering that Solaris uses the Bourne shell, not Bash, as it's /bin/sh; lots of people have little bits of shell they use for various tasks, and it's easy to have bash-isms in there that don't work in vanilla bourne-shell.

Likewise, if you shell out to external binaries at all, Solaris ones may be quite different.

Answer 2

There are a couple details that are important.

First, I believe you need a service contract to access security patch-sets. Next you have to download monthly (or quarterly) patch sets from Sun's website. The patches are installed by executing a shell script that comes with the patch-set. There will be failures for some or even most of the patches depending on whether that patch applies to your configuration.

After the first round of patches, restart the box with: reboot -- (don't forget the two dashes) so the kernel will know to update configuration information. After that, you install the same patch set again in case there were dependencies from the first round of patching. And guess what, reboot -- again.

It's a much more formalized system of maintenance than Linux (or at least some variants of Linux). Obviously PHP, MySQL, Apache, etc. all work fine. But depending on the chip-set you choose (cool-threads) you'll want to install the proper tuned version of their SAMP stack (it's called something like glassfish stack or something).

I wouldn't worry too much about the shell since operating as root isn't usual behavior for most administrators - so you can pick bash or ksh. Also, do not change the root shell from /bin/sh it's statically linked in case you bugger up some shared libraries like libc.so.

You'll also want to download the SunStudio (current version is 12.1) and compile downloaded source files with Sun's compiler since it better optimizes for the SPARC chip-set. And don't forget to use the -fast compiler flag when you do compile. Other than that the only other thing I can think of is to download Sun's DTrace Guide (dynamic tracing guide).

Oh, and read up on pkgadd and pkgrm. One more thing, top may not exist on a default install so use Sun's version: prstat. And become familiar with svcadm to manage services. Alas, that's all I can think of.