Hi folks. I am running opensuse 12.3 as a LAMP box. It’s been working great for a few years, but I need to go to a newer version now, especially to update PHP. I’m no guru and not much a command line guy. I do most everything in Webmin. The machine ins mine as in, it is in this house.
What would be entailed in duplicating the entire server and all it’s resources on a newer version of free Suse? (I have no money for this.) It’s hosting 3 Wordpress blogs, an SMF forum (vhosts) and numerous other files and stuff. I have 2 identical (older machines) 64 bit HP desktops with a couple gigs of ram and terabyte drives. Like I say, this has been working fine http://tiribulus.net/pix/pix1/server.jpg
Will simply loading up a newer version as a LAMP machine and copying the docroot, databases and all the conf files to the same place work? I’ve never done anything like this. Any help would be greatly appreciated.
As always, when first looking at a big and possibly very complex and technically challenging situation, if you see a possible shortcut, go ahead and try it. It shouldn’t take long to evaluate the results and at the least would provide you with your first look at what kind of issues have to be resolved if it doesn’t work.
There should be documentation available for your situation, but it might be in pieces you need to aggregate.
You probably have 3 main approaches…
Upgrade your existing deployment.
Advantages
If successful, may involve least amount of re-configuration and re-building so may be recommended as a first try.
Some old and currently unsupported pieces may continue to work in your new system.
Disadvantages
Depending on the pieces of your solution, success is only problematic.
As with any upgrade, all the “junk” accumulated in your system will be carried forward.
Some parts may not have an upgrade path, so have to be re-built anyway.
Re-build from scratch
Advantages
Everything is brand new, which means no junk carried forward.
Disadvantages
Greater chance that old parts may not work so will have to be replaced or just omitted
Much, much more work than an in-place upgrade.
Much, much more technically difficult than an in-place upgrade.
**For very small deployments
**Consider and compare the effort to simply build a brand new deployment and then manually (or possibly migrating your data) re-creating on your new deployment.
Regardless of the above overall approaches,
You need to identify each essential application subsystem… In the case of Wordpress, besides Wordpress itself and Wordpress plugins, there is PHP and your database, most likely MySQL/MariaDB. You need to identify the old and new version numbers and then research the issues involved for upgrading the application itself or migrating the data and configurations.
You should make a full system backup and make sure you can restore it. Virtualization can be a boon for upgrading because it enables you to make copies easily, implement and test upgrading pieces step by step and snapshot so you can easily “undo” and return to known points in time without having to re-build from scratch.
Since you’re upgrading from 12.3, you should upgrade to 13.1, then to 13.2 and then to LEAP 42.1. That’s a lot of upgrading and testing, and it’s all necessary for maximum chances of success.
If you’re upgrading major versions of MySQL, there is a high likelihood you’ll need to export your databases and then re-import.
Whether you upgrade or re-build, the general rule of thumb is to upgrade the HostOS, then the components, then the application at each step. This requires extensive planning and self-documentaion unless someone posted a blog or documentation for exactly what you should do.
It looks like Wordpress itself may have built in some upgrade assistance, the following is the official Wordpress documentation for upgrading https://codex.wordpress.org/Updating_WordPress
Wordpress and SMF (Simple Machines Forum) are actually all up to date. Its’ the backend stuff that’s behind. http://tiribulus.com/phpinfo.php
Especially PHP needs updating, but I’m told that this version is the highest that will run on 12.3. If I could just get the LAMP pieces up to date, that would be enough. Somebody told me that none of this can done on this version and that opensuse itself can’t be upgraded further without reinstalling from scratch. I keep full drive clones every couple weeks so that saves me from disaster from something like this. I have well above average PC skills, but with Linux not so much. I can get it to do what I want (webmin) as far a web server like this, but I’m not sure if I’m up to a full manual migration like this to be honest.
Yes,
Is why in my post I mentioned that you should upgrade from the foundation up, which generally means first updating the HostOS through the different versions I described, then the applications in their order at each HostOS version which generally means upgrading PHP and your database engine before upgrading Wordpress itself. Note that PHP may not be your biggest bugaboo, it’s usually the data and the database engine that will be forcibly upgraded as you upgrade your entire system.
So, for instance
Upgrade openSUSE 12.3 > 13.1
Upgrade PHP and MySQL (a “zypper up” can do this for you with one click)
Upgrade Wordpress
Then,
Upgrade openSUSE 13.1 > 13.2
Upgrade PHP and MySQL (a “zypper up” can do this for you with one click)
Upgrade Wordpress
Then repeat the above pattern for upgrading 13.2 > 42.1, and then again if you wish 42.1 > 42.2.
Or… And this is particularly noteworthy…
Because the Wordpress upgrade documentation says that it will tell you what components need to be upgraded, then it’s worth considering reversing the order of Applications… ie Wordpress before PHP and your database server.
This is why you need to either have a very good backup system or do this in a virtual machine as I suggested… There are a multitude of ways for things to go wrong which would mean backtracking and trying another option many times.
Count on having problems during the upgrade.
Do not in any way assume there is any way to upgrade without issues.
And, as I noted, an “In Place Upgrade” is still in most cases preferable to trying to do a migration to a brand new system although there are definitely exceptions.
I get 211 zypper errors when trying to run yast. Can these incremental updates be done with the DVD’s? This for instance is WAY over my head. https://en.opensuse.org/SDB:System_upgrade
I think I’m going to have to just face the fact that I don’t know how to do this. I upgraded from 12.3 to 13.1 and nothing worked except webmin. It told me at the start that the architecture didn’t match and as soon as I tired to start Apache it said it couldn’t find the location of the file to start it.
My friend said he’d help, but he started a new job and it’s been over 6 months so I thought I’d try it. Oh well.
How did you do your upgrade, using a DVD or changing online repositories?
If you used the DVD, you need to verify which repositories are enabled or disabled, then when those are to your satisfaction do the following in an elevated console to update to last versions released for 13.1.
Depending on errors you see, you may also need to manually start your LAMP services, so for instance the following returns the status and if there are any possible errors
systemctl status apache2.service
systemctl status mysql.service
If stopped, you can manually start with the following and if not successful should return info including a system log snippet of any detectable error
systemctl status apache2.service
systemctl status mysql.service
As I emphasized earlier, upgrading will involve encountering and overcoming errors.
There is hardly an upgrade that works without error.
Do you still have a working 12.3 setup? If so I’d just leave it as it is for now and try a new installation of 42.2 on another machine (or in a VM).
I’m assuming this is public facing, so is your current server on a static IP address or are you using some sort of dynamic DNS solution?
For the PHP files and all that in the docroot, that should be able to just be copied over, but make sure that if you have any passwords in some sort of config file elsewhere that you copy those to the appropriate place as well.
Attempt to migrate your MySQL database using some of the guides online and see if you can get the websites working on localhost (do not host publicly yet).
If and when everything seems to work fine, then it’s just a matter of switching a few things then that would be live.
