Migrating Unix to Linux

Linux has been around for some time now. Initially created by Linus Torvalds in 1991, it has grown into a major player in the server operating system (OS) landscape, alongside Windows and the major Unix distributions. While there is nothing inherently wrong with Unix, it has gotten rather "long in the tooth," and there is a growing trend of migrating away from Unix to Linux.

So why migrate?

If you are an administrator of an existing data center (whether on-premise or in a co-location facility), particularly one that has been around for a long time, chances are you have some commercial flavor of Unix running. These usually require proprietary hardware, and while this may be running without issue, there are challenges to maintaining such legacy environments. The biggest of these challenges that upper management might be looking at is support costs for both the hardware and the OS itself. Additionally, expansions can be harder and harder to do, as the legacy hardware is outdated and parts can be difficult to find and, when found, can be expensive (oh, supply-and-demand, you are such a harsh mistress!).

Something that can come up during this transition is the possibility that you discover an application that can't be migrated. Maybe the vendor went out of business or hasn't ported the application to Linux. Perhaps they have, but it would require direct vendor involvement in a professional engagement that carries too high a cost. If this comes up, you might have to see if you can migrate the workload to a new application that is supported on Linux or look at having to keep that particular legacy server around.

Another issue with staying on legacy Unix systems is the inability to virtualize. While there is some virtualization in a few Unix environments, modern hypervisors provide a lot more functionality and flexibility, if you can move to an OS that is supported by your chosen hypervisor.

Ok, so I'm going to migrate, how do I start?

The success of a migration from Unix to Linux is going to start with a solid investigation. There are several things on which to focus. There are two ways to approach this, and I've found a hybrid of both can yield the best results. The two approaches, as I've seen them, are "bottom up" and "top down." These phrases are common and pretty easy to apply here.

For the bottom-up approach, you start at the OS level. Begin with checking the current OS and version. Identify installed packages, modules, or additional software from the OS vendor. Next, check for third party software, capturing the vendor and version you are running. The last thing is any home-grown software you might have, including not only programs written in a formal language like C (or any of its descendants) or Java, but also scripts written in any of the common shell languages (sh, ksh, csh) or interpreted languages like PERL, Python, and the like.

One other place to look is the cron scheduler. Anything scheduled there, whether it is vendor-supplied or home-grown, is something that you want to spend extra time testing.

The top-down approach can be more difficult, as it entails starting with the end-users and finding out from them what they run on the system. This approach can be a trying experience, as users don't always understand how something works, just how they use it. For example, a user might know that they use a website, but not be aware that "under the hood" is Apache or Tomcat, whether or not it has any CGI scripts and if so, what language they are in. However, extra tidbits can be gleaned, such as finding out that a server you thought was more or less standalone is closely tied with another, and that you will need to migrate both of them at the same time.

My preference is to do both... I'll try to find out who leads the business users of a particular system and meet with them to find out what they use it for. I'll also try to match up the functionalities they use with identifiable system components. One example would be a web server. Is it a static server, or dynamic? You might not see that from reviewing installed packages on the server. Still, a user interview might tell you the site is based on WordPress, which means you need to find the database that drives it, whether it is on the same server or perhaps another that might need to migrate at the same time.

Ok, so now I know what is running, what next?

You need to decide what Linux distribution you are going to move to. Many things factor into this decision, which frankly should be a blog post of its own. For now, what I will highlight is that you need to look at the features that are in play on the server, and find out what distributions support those same features. If, for example, the server is a simple web or FTP server, just about any Linux will suffice. If you have some third party software running, the vendor might only support certain distributions, so you might want to start with that software, then narrow down from there.

Once you've selected your distribution, build yourself a development environment, install the base OS and needed packages, third party software, and the like. Set up users for testing, and either copy over their programs and scripts, or make sure they can do so.

Everything will just run, right?

In a perfect world, that would be true. However, we all know the world isn't perfect. OS-supplied features generally work out-of-the-box the way you would expect. If you are jumping up in versions for something like Apache, there might be differences in how to configure it to get your website to run the same way. Documentation usually helps you get there. Third party software can sometimes have more issues. If you have to deal with those, make sure you have confirmed OS version levels. One vendor I have dealt with supports RHEL 6, but not RHEL 7. Sometimes they might have only tested to a certain point-release, and support up to that but not beyond, such as supporting RHEL 6.4 but not RHEL 6.10. There can also be issues if you installed a 64-bit version of the OS, but the third party vendor only tested on a 32-bit install.

Home-grown software and scripts are another matter. You are almost guaranteed to have issues there, depending a lot on who wrote the code and how complex it is. Formal languages may transfer more easily, as long as the Linux OS has the right libraries to support compiling.

There could be issues if you were running on an older flavor of Unix, as things may have changed in the language. Certain defaults may have changed, and options to function calls, especially system calls, could be different. The recommendation is to do the first compiles of code with the highest amount of debugging that you can turn on, and then once you've worked through the issues, recompile with that debugging turned off to save on server load going forward.

For scripts, the same holds true, but with a greater chance of odd changes. Personal experience has shown that standard shell (aka sh) scripts usually run under Bourne Again Shell (aka bash). Still, there can be hidden gotchas that won't actually throw an error, but don't produce the results expected. One key example is this code snippet that I used a lot in my HPUX days:

cat datafile.txt | while read line ; do
    set - $line
    var1 = $1
    if [ $var1 = “yes” ] ; then saved_value = “$2”
done
echo “$saved_value”

Under HPUX, this worked fine. Under bash in RHEL, the variable $saved_value would be blank, due to how that shell was doing scoping versus how HPUX did it. I had to change the above to something like this:

while read line ; do
    set - $line
    var1 = $1
    if [ $var1 = “yes” ] ; then saved_value = “$2”
done < datafile.txt
echo “$saved_value”

So, it is important to do side-by-side executions between the old system and the new to verify that the same input into a script creates the same output on both systems.

Ok, we tested all the things, now what?

The actual step of doing the cut-over from the old system to the new can vary greatly in complexity, depending on your environment. For the topic to really be handled right, it should have a blog of its own. After you've done your migration, a post-mortem is handy, especially if you have additional migrations to do. A solid review of what worked and what didn't go so well can generate useful "lessons learned" to apply to your next migration project.

Wrapping up

I hope this article has helped highlight the types of things to look for, conversations to have, plans to establish, and gives you a head-start on your journey into Unix to Linux migrations. Hopefully, with the things you take away from this article, and a little luck, you'll have a relatively smooth transition.

[ Want to try out Red Hat Enterprise Linux? Download it now for free. ]