We have a business critical PHP website, our Intranet, running on OpenSuse 11.4 with Apache 2.2.17. I cannot explain why updates and upgrades were never done to it, or why it is the only OpenSuse server in our server farm. It is also a virtual guest. We are just now beginning to have issues and no one whoever implemented or supported this server is still here. The initial issue was one of our data syncs with a third party is failing or hanging due to our lack of SSL/TLS certificates. I have tried both Certbot (total failure) and Acme. Acme installed, but is having issues issuing a certificate. Other issues are related to Apache and our inability to update any code.
I would like to upgrade this machine to a supported version of OpenSuse, but am really, really, really concerned that I could break the Intranet and stop our business. I’ve also contemplated standing a new server and moving files. However, this is first OpenSuse server/OS, I’ve ever worked with. Can anyone provide me with Pros/Cons for either or both? The plan is to make a copy of the server, when I can have it down for several hours, and make changes to that one. Any input is appreciated. Thank you.
On Fri, 05 Apr 2019 17:26:03 +0000, mdabney918 wrote:
> We have a business critical PHP website, our Intranet, running on
> OpenSuse 11.4 with Apache 2.2.17. I cannot explain why updates and
> upgrades were never done to it, or why it is the only OpenSuse server in
> our server farm. It is also a virtual guest. We are just now beginning
> to have issues and no one whoever implemented or supported this server
> is still here. The initial issue was one of our data syncs with a third
> party is failing or hanging due to our lack of SSL/TLS certificates. I
> have tried both Certbot (total failure) and Acme. Acme installed, but
> is having issues issuing a certificate. Other issues are related to
> Apache and our inability to update any code.
>
> I would like to upgrade this machine to a supported version of OpenSuse,
> but am really, really, really concerned that I could break the Intranet
> and stop our business. I’ve also contemplated standing a new server and
> moving files. However, this is first OpenSuse server/OS, I’ve ever
> worked with. Can anyone provide me with Pros/Cons for either or both?
> The plan is to make a copy of the server, when I can have it down for
> several hours, and make changes to that one. Any input is appreciated.
> Thank you.
Given the age of the server, I’d be inclined to start with a fresh
installation and then migrate to the new server.
An in-place upgrade could work, but if there is a problem, you’ll be down
while troubleshooting what’s not working.
Since it’s a VM, another option would be to try an inplace upgrade after
taking a snapshot of the current instance - I’d shut it down, take a
snapshot, and then run the upgrade (rather than taking the snapshot of
the running instance - but that’s largely a personal preference).
Depending on what VM technology you’re using, you could also look at
creating a linked clone - that would let you try the in-place upgrade
while leaving the existing VM running.
I also think that your aplication might need to be updated and thouroughly tested.
I migrated a small Apache-PHP-MySQL application from 13. to 15.0 and had to do this (as I expected and as at least some of the migrations to be done were known by me in advance). So I guess for you it might be even a bigger step.
A few I remember:
In Apache the AllowOverride and statements related to it changed, something like other defaults.
The interface from MySQL changed from a package usng mysql_… calls to msqli_… calls and the link parameter was moved from the end to the begin of the parameter list. Searching on the internet with something like “PHP conversion from msql to mysqli” will give you hints and examples.
My database being rather small, on conversion I normaly export/import the whole MySQL/MariaDB database. In my script I first DROPed the database to CREATE it fresh. The DROP statement could only be used when the database did exist and the CREATE only when it did not exist. Now there is DROP DATABSE IF EXISTS …; which makes life easier.
They changed the default storage engine. It was MyISAM, now it is different. I had problems with certain parameters not being supported with the new engine. Inserting ENGINE = MyISAM in the CREATE TABLE helped.
Thank you for both responses. In the back of mind I knew a fresh start was probably going to be the best. We are currently redeveloping the Intranet, but have gotten off schedule. I have major concerns about moving the current application to a new platform. I fear it would break and I would not be able to recover. It has have 9 different developers contribute and all but the last 4 where afraid of commenting. We’re not sure what some of the code does. Thank you again for replying.
Hi, sorry for the late response, but I happened to run into some notes from a kind-of-like same experience last december. Couldn’t find them when I first saw your post.
This was a small server, openSUSE 11.3, apache, mysql, php, with an in-house developed webapp. Here’s wat I did:
Created a Leap 15.0 VM, with stock LAMP server install, I used the pattern
Setup mysql_secureinstallation
Setup the apache webserver using the YaST http-server module
Checked whether apache ran properly
Compared the php modules loaded on the 11.3 server, and enabled those on the 15.0 VM, tricky cause some php modules had been replaced/merged etc.
Used phpMyAdmin to dump the mysql db from 11.3, used the same to import it in a new db on the 15.0 one
Copied the webroot of the application bluntly to the 15.0 VM
Tried running the webapp, which itself reported two or three missing php modules, installed those, and some others that seemed to be missing when reading the logs. Restarted the webserver
Much to my surprise I could login on the localhost/webapp_name, but it complained about not being able to verify the (sub)domain. So,
I rented a small VPS, I created a subdomain and pointed that to the VPS, used the Leap 15.0 install on the VPS, setup a vhost and replicated the stuff I did in the VM, but this time on the subdomain.
From there on, the whole thing worked like a charm.
Then installed certbot, and it created a the certs/keys, I added a couple of lines to the apache config, redirected http to https and off it went.
End of story: customer decided to scale up the VPS and keep that instead of investing in a new server.
On Mon, 08 Apr 2019 13:06:03 +0000, mdabney918 wrote:
> Thank you for both responses. In the back of mind I knew a fresh start
> was probably going to be the best. We are currently redeveloping the
> Intranet, but have gotten off schedule. I have major concerns about
> moving the current application to a new platform. I fear it would break
> and I would not be able to recover. It has have 9 different developers
> contribute and all but the last 4 where afraid of commenting. We’re not
> sure what some of the code does. Thank you again for replying.
You bet. There is a definite advantage to moving in that you can
continue to test until the developers are happy that the move has been
successful and leave the old platform in place until the migration has
been successful.