SUSE LINUX Enterprise Server 11 to Oracle Linux 6 Migration Guide

An Oracle White Paper February 2013

Introduction ...... 1 Benefits of Migrating to Oracle Linux ...... 2 Planning Your Migration ...... 2 General Migration Steps ...... 3 Application Inventory ...... 4 Inventory of Applications in a Standard Build ...... 5 Third-Party Application Inventory ...... 7 Breaking Applications Down into Categories ...... 8 System and Infrastructure Inventory ...... 8 Hardware Inventory ...... 9 Network Inventory ...... 10 License Inventory ...... 12 User Account Inventory ...... 12 Platform Differences ...... 12 Differences in Applications/Features Used ...... 12 Differences in Directory Structure ...... 18 Subscription Management ...... 18 Transition Process ...... 19 Preparation ...... 20 Oracle Linux Installation ...... 20 Postinstallation ...... 22 Conclusion ...... 22

SUSE LINUX Enterprise Server 11 to Oracle Linux 6 Migration Guide

Introduction

Migrating to a new operating system environment requires structured planning and testing. This document provides information regarding the differences between SUSE Linux Enterprise Server 11 and Oracle Linux 6. It provides suggestions for assessing your existing SUSE Linux environment in preparation for the migration and on how to use this information to successfully plan for and transition to Oracle Linux.

1 SUSE LINUX Enterprise Server 11 to Oracle Linux 6 Migration Guide

Benefits of Migrating to Oracle Linux

Migrating from a SUSE Linux Enterprise system to Oracle Linux gives you benefits that include better performance, reliability, and scalability. Oracle Linux provides features and tools you won’t find in SUSE Linux. For example, Oracle Linux with Oracle’s Unbreakable Enterprise Kernel has been optimized for Oracle applications. It receives more than 100,000 hours of use daily and is deployed throughout Oracle on development and production systems. Oracle Linux customers have access to the latest innovations in the mainline kernel community as well as to world-class support and features meant to simplify their administrative tasks. With hundreds of validated configurations and tools for simplifying Oracle application installations, such as Oracle-validated and preinstalled Red Hat Package Manager (rpm) files and features such as DTrace and zero-downtime kernel patching with Ksplice (available with all Oracle Linux premier subscriptions), Oracle Linux is designed for mission-critical data centers. For additional information on the advantages of Oracle Linux, take a look at the following links:

• Oracle Linux Components

• More Oracle Linux Options

• Deploy Linux Faster: Oracle Validated Configurations

• Oracle Database 11g Installation on Oracle Linux 6

• Ksplice: Zero-Downtime Updates for Oracle Linux

Planning Your Migration

Before beginning a migration, you will need to do some preliminary work. First, you have to gather information on the software components currently installed on your SUSE Linux system and which ones will be migrated to Oracle Linux. In addition, you will need to spend time capturing information on your environment, such as the hardware configuration, network settings, security settings, and users and groups, to name a few. There are tools to help you accomplish these tasks, such as Yet Another Setup Tool (YaST), the SUSE Linux system setup and configuration tool. Alternatively, you can collect this information from the command line. The following sections outline some of these steps for you and provide examples. One key difference between SUSE Linux and Oracle Linux lies in the applications and features used to accomplish system and administrative tasks. For example, consider the features that support the access control security policies used in these two platforms. SUSE Linux uses AppArmor, and Oracle Linux relies on SELinux. This means that you need to think over a migration plan for converting data. The “Differences in Applications/Features Used” section presents a more detailed discussion on these two features, their differences, and some ideas for migration.

2 SUSE LINUX Enterprise Server 11 to Oracle Linux 6 Migration Guide

Although the application migration is going to take up a large portion of your effort, there are some other operations to accomplish to complete the overall migration process. For one thing, you have to take care of the system and infrastructure data to be migrated. For instance, with the application layer, your first step should be to inventory the system and infrastructure layer and then come up with a migration strategy. For more on this step, see the “System and Infrastructure Inventory” section. Once these inventories are completed, you can begin the process of setting up a test environment. You start by creating a scratch area to hold the configuration and application files and directories to be migrated. Once the archives are copied to the scratch area, you can install the Oracle Linux operating system and then restore the files from the backup copy, making conversions where required. The steps of the migration process are discussed in more detail in the “Transition Process” section. After you’ve successfully moved the applications as well as some system metadata from SUSE Linux to Oracle Linux, what else is left? Well, because SUSE Linux and Oracle Linux are different in some respects—including differences in directory structure and features/toolset—you may need to change some of your past procedures to accomplish certain tasks. You’ll also need to get accustomed to the new environment to take full advantage of it.

General Migration Steps

Viewed at a high level, the steps of migrating from SUSE Linux to Oracle Linux look fairly straightforward. The diagram in Figure 1 depicts these general steps:

Figure 1. The steps of migrating from SUSE Linux to Oracle Linux are generally straightforward.

3 SUSE LINUX Enterprise Server 11 to Oracle Linux 6 Migration Guide

Let’s take a closer look at this general migration plan, covering its steps in greater detail. 1. Preparing SUSE Linux for migration

• Collect information about the software installed, and then determine which applications to migrate (application inventory).

• Break applications down into categories in light of the forthcoming migration.

• Conduct system and infrastructure inventory.

• Create a scratch area for storing the files to be migrated.

• Shut down all running applications and services.

• Archive the files and directories to be migrated, sending them to the scratch area. 2. Installing Oracle Linux

• Customize the software installation so you don’t need to install more than the packages needed for operation.

• Back up the data and metadata to be replaced, to be on the safe side.

• Check port availability on Oracle Linux for all the services you had on SUSE Linux. 3. Moving data and metadata

• Restore the operating system configuration files from the backup archive.

• Restore the application-specific files from the backup archive. 4. Verifying migration

• Test the migrated applications and services to verify that they are all working properly.

Application Inventory

Application inventory is the starting point in the migration process. In this step, you capture as much information as possible on the software components you want to migrate. To accomplish this task, you can use a package management tool. In the case of SUSE Linux, you can use the package manager YaST to obtain all the information on the package management applications installed in your system. It’s interesting to note that even third-party applications (those not included in a standard build but installed as Red Hat Package Manager [RPM] packages) will be visible in the package manager. Be forewarned, though: the software installed manually (i.e. using [./configure], [make], [make install] sequence) or with custom installers will not be detected by the package manager. Further details are provided in the following sections.

4 SUSE LINUX Enterprise Server 11 to Oracle Linux 6 Migration Guide

Inventory of Applications in a Standard Build As mentioned, applications in a standard build as well as third-party applications installed as RPM packages are visible in the package manager. In this respect, there is no difference between these two types of applications. The following steps describe how you can capture information on the package management applications with YaST: 1. Select Computer -> YaST to invoke the YaST Control Center dialog box. 2. In the YaST Control Center dialog box, in the Software section, select Software Management to invoke YaST2. 3. In the YaST2 window, you can go to the RPM Groups tab and choose a package group of interest from the Package Groups pane. Alternatively, you can go to the Search tab and search for a package of interest. To see the entire list of installed RPM packages as well as those that are not installed but available for installation from the distribution, you can choose zzz All from the Package Groups pane.

Figure 2. In the YaST2 window, you can choose a package group of interest. 4. To save the list of installed packages in XML format, select File -> Export in the YaST2 window.

5 SUSE LINUX Enterprise Server 11 to Oracle Linux 6 Migration Guide

TIP: Having the package list saved in an XML file gives you a good opportunity to employ an Oracle Database instance for improving the application inventory procedure. In particular, you might use Oracle XQuery—an Oracle Database feature—to query the package list stored in that XML file. You will be able to consolidate the data derived from XML and data stored in the database to get the results for your inventory, generating a variety of reports. When broken down into bullets, this concept might look like this: • You may have one or more relational tables in your Oracle Database instance to keep some information about the applications to be migrated. • The other pieces of information on this same set of applications are derived from the XML file generated with YaST as described earlier. • From within an SQL environment, you can issue an Oracle XQuery query that will join the XML and relational data mentioned above. For example, the relational structure may keep just the names of applications (packages) you’d like to migrate, whereas the list stored in the XML file contains some additional information, such as version and release numbers. Issuing a join query upon these two sources could give you a list that includes only those applications you want to migrate, along with additional information for each application included. For details on how you might combine relational data from your Oracle Database and XML data from external sources into one query result, check out the Oracle Technology Network article “Retrieving, Transforming, and Consolidating Web Data with Oracle Database.”

Although using a GUI tool such as YaST2 is convenient, some people still prefer commands. When it comes to package management applications, you can use the rpm command to obtain all the necessary information. The following command will output the entire list of packages installed:

# rpm –qa filesystem-11.1.3.5.3 sles-release-DVD-11.2.1.234 ... However, you most likely will want to save this output in a file:

# rpm –qa > rpmlist.txt You can move that file to any location and, anytime later, search through the package list saved there to look for a package of interest. If you want to see the installed packages sorted by install time, the packages installed recently will appear at the top of the list, followed by the standard packages installed during the system installation, if you issue this command:

# rpm –qa --last VirtualBox-4.2-4.2.6_82870_sles11-0-1 ... If you want to make sure a certain component is installed and want to learn its version, you can use the rpm –qa component’s name command. For example, this is how you might know whether Python is installed in your system and, if so, what version:

# rpm –qa python python-2.6.0-8.12.2

6 SUSE LINUX Enterprise Server 11 to Oracle Linux 6 Migration Guide

If you need to find out what dependencies this package has, you might issue the following command:

# rpm –qR python-2.6.0-8.12.2 python-base = 2.6.0 rpmlib(VersionedDependencies) <= 3.0.3-1 ... It’s important to emphasize that software inventory records often include a bit more information than just the application names, their versions, and dependencies. Thus, you will need to know where an application stores its files and which ones have to be migrated. Also, you have to mark what manual corrections may be required in the application configuration files.

WARNING: Be aware that, because the distributions are developed independently of each other, there can be instances in which the packages from Oracle Linux are different from those found on SUSE Linux (different version, configuration, dependencies, and so on).

Third-Party Application Inventory Apart from the package management applications discussed in the preceding section, you may have manually compiled software, including third-party applications installed by use of tar/zip files and custom installers. Such applications are not caught by the package manager and will therefore not appear in YaST2 or in rpm command output. What that means in practice is that you’ll have to collect information about applications of this type on your own. Perhaps the first thing to do is work out a list of such manually installed applications you want to migrate, then find where they were installed, and finally capture as much information as possible about them. For example, suppose you’re using the latest version of Apache HTTP Server (2.4.3 at the time of this writing), downloaded from the Apache Website and installed in your SUSE Linux system with the [./configure], [make], [make install] sequence. Now you want to migrate it to Oracle Linux. What information do you need to collect about your Apache server when preparing for the migration? Consider the following list:

• Prerequisites. Because you’ll need to reinstall the application being migrated in the destination system, you have to make sure that all the prerequisites are met. For example, before you can install the Apache HTTP Server, you must either have the APR and APR-Util libraries installed in your system or download and unpack their latest versions and then use ./configure’s --with-included-apr option.

• Location. Before you can move configuration and user data, you have to know where the files are. Normally, the root directory of applications such as the Apache HTTP Server, when they’re installed manually, can be found at /usr/ local, provided they are to be accessible by all users.

• Directory structure. In fact, a customized application directory structure can differ a little from one generated by default. In the Apache HTTP Server, for example, you might have the root document directory organized further with subdirectories, specifying them in the httpd.conf configuration file.

• Permissions. If you’ve installed an application as a given user (in that user’s home directory), the application files will be available only to users with permission to access this directory. If you move

7 SUSE LINUX Enterprise Server 11 to Oracle Linux 6 Migration Guide

those files as a root, their owner will be changed to “root.” You may need to change the owner once the files have been moved to the destination.

• Configuration. You must check the configuration before migrating it, in order to avoid any potential hassle. For example, your Apache server may be configured to accept connections on port 8080 in the system you’re migrating from but this same port may already be in use by another application in the system you’re migrating to, so you’ll need to either change the value of the Listen directive in the httpd.conf configuration file or assign another port to that other application in the target system.

• Embedded applications. The application to be migrated can be configured to use other applications. For example, the Apache HTTP Server provides a great number of modules that extend its core functionality, enabling use of other applications within the server. Thus, the Apache HTTP Server mod_python module embeds the Python interpreter within the Apache server. So you have to verify that all those applications have been installed in the system to which you’re migrating, to make sure that all documents will be processed correctly. Although this example is specific to the Apache HTTP Server, this same plan of inventory collection should be used for any other application installed with the [./configure], [make], [make install] sequence.

Breaking Applications Down into Categories Once you have the list of applications currently installed in your system, you can categorize them in light of the oncoming migration. For example, you might break the applications down into the following categories: 1. Runs on both SUSE Linux and Oracle Linux; no configuration changes required 2. Runs on both SUSE Linux and Oracle Linux; minor configuration changes required 3. Runs on both SUSE Linux and Oracle Linux; additional software required 4. Runs only in a virtualized environment Sorting applications into categories can help identify the areas that may require additional testing or planning.

System and Infrastructure Inventory

System and infrastructure inventory is important, because it can help you make sure that after migration

• All hardware devices work correctly in your system

• All Internet Protocol (IP)–enabled devices function properly on your network

• All software licenses are up to date

• All user accounts are available

8 SUSE LINUX Enterprise Server 11 to Oracle Linux 6 Migration Guide

For that, you’ll need to accomplish the following:

• Hardware inventory

• Network inventory

• License inventory

• User account inventory

Hardware Inventory To perform hardware inventory, you need to detect the hardware devices installed in your system as well as the drivers used to run those devices. This information can be obtained via the YaST hardware information module: 1. Select Computer -> YaST to invoke the YaST Control Center dialog box. 2. In the Hardware section of the YaST Control Center dialog box, select Hardware Information, where you can view detailed information on the hardware devices installed in your system:

Figure 3. Here you can view the hardware devices installed in your system. 3. You can save this information in a file by clicking Save to File.

9 SUSE LINUX Enterprise Server 11 to Oracle Linux 6 Migration Guide

Alternatively, you can accomplish hardware detection with the help of the hwinfo command, which should generate the same results you would get from a file created from within YaST2’s Hardware Information dialog box:

# hwinfo ... 0: udi = '/org/freedesktop/Hal/devices/ppdev_parport0_0' info.callouts.remove = { 'hal-acl-tool --remove-device' } access_control.type = 'ppdev' linux.hotplug_type = 2 (0x2) linux.subsystem = 'ppdev' info.subsystem = 'ppdev’ info.product = 'Parallel Port Device' info.udi = '/org/freedesktop/Hal/devices/ppdev_parport0_0' linux.sysfs_path = '/sys/devices/pnp0/00:08/ppdev/parport0' info.parent = '/org/freedesktop/Hal/devices/pnp_PNP0400' access_control.file = '/dev/parport0' info.category = 'ppdev' info.capabilities = { 'ppdev', 'access_control' } info.callouts.add = { 'hal-acl-tool --add-device' } linux.device_file = '/dev/parport0'

... You can instruct hwinfo to output only the entries that belong to a certain category of hardware devices. For example, to see in the result list only the SCSI devices, you might issue the following:

# hwinfo – scsi

TIP: Examining entries in the device list generated, you may notice that they contain a lot of information you actually may not need. So you might write a script that would extract only the necessary information from the original device list. The results of such a selective extraction might be put into a relational database, which would enable you to generate flexible reports on different categories of the hardware devices installed in your system.

Network Inventory The same tools described in the preceding section can be used to get information about your network devices. Thus, in YaST2’s Hardware Information dialog box, you can check the following device categories:

• Network card

• Network interface

You can issue the hwinfo command with the “network” parameter to see only the network device entries in the result set:

# hwinfo --network

29: None 00.0: 10700 Loopback [Created at net.124]

10 SUSE LINUX Enterprise Server 11 to Oracle Linux 6 Migration Guide

Unique ID: ZsBS.GQNx7L4uPNA SysFS ID: /class/net/lo Hardware Class: network interface Model: "Loopback network interface" Device File: lo Link detected: yes Config Status: cfg=no, avail=yes, need=no, active=unknown

30: None 01.0: 10701 Ethernet [Created at net.124]

...

Then you’ll need to collect the following information on each Ethernet interface presented:

• IP address

• Subnet

• Gateway

• MAC address

• Speed/duplex

• Network bonding configuration Apart from the information on the Ethernet interfaces, you also have to collect the information on the network configuration. This information can be collected from the network configuration files. In SUSE Linux, the primary network configuration files are

• /etc/hosts

• /etc/resolv.conf

• /etc/sysconfig/network/config

• /etc/sysconfig/network/ifcfg- It’s interesting to note that the above list is slightly different in Oracle Linux:

• /etc/hosts

• /etc/resolv.conf

• /etc/sysconfig/network

• /etc/sysconfig/network-scripts/ifcfg-

11 SUSE LINUX Enterprise Server 11 to Oracle Linux 6 Migration Guide

License Inventory Every software application comes with an end user license agreement (EULA). It is always a good idea to check over an application’s agreement before installing, reinstalling, or migrating the application. If you want to automate this process, you can use a tool for finding and identifying licenses of existing software. Many such tools are on the market now. For example, you might choose ServiceDesk Plus to track software license compliance.

User Account Inventory In SUSE Linux, you can use YaST to view the user accounts. Alternatively, you can evaluate information found in /etc/passwd directly. There are ways to migrate user accounts from one Linux server to another. These methods are based on using standard commands, such as awk, applied to /etc/passwd, /etc/group, and /etc/shadow files. It’s important to note, however, that SUSE Linux 11 can use the DES, MD5, or Blowfish algorithm to encrypt passwords. And the default encryption algorithm is still Blowfish, whereas Oracle Linux 6 uses MD5 by default. What that means in practice is that the above files cannot be copied from SUSE Linux 11 to Oracle Linux 6 directly, but you can also choose to migrate this information manually. Another important task you have to accomplish at this stage is to examine the home directories for the users whose accounts you want to migrate. These directories keep users’ personal files and include their configuration files for any software they have used. The simplest solution would be to back up all directories in /home so that you could restore them in the new system.

NOTE: If you use nonlocal users and groups residing in services such as LDAP, you may have no home directories on the local host but have them located somewhere on a network file server. If your current system runs an LDAP server for authenticating users, you will need to think over a migration plan to move your LDAP database to the new system.

Platform Differences

Before you proceed to the migration, learning the key differences between the two platforms is very beneficial.

Differences in Applications/Features Used The next sections outline the key feature and tool differences you might need to be aware of.

Security Being a SUSE Linux user, you most likely use Novell AppArmor to restrict an application’s capabilities, associating a security profile with that application and thus giving administrators more control over the application’s privileges. Most Oracle Linux users use SELinux, and although both AppArmor and SELinux perform very similar functions, there are some differences in detail between the two.

12 SUSE LINUX Enterprise Server 11 to Oracle Linux 6 Migration Guide

One of the key differences is that SELinux uses inode numbers to identify file system objects whereas AppArmor relies on paths. Using inode numbers seems more reliable, because each file system object is associated with a certain inode. Even if you create a hard link to an object, it’s not going to compromise security, because the object’s inode remains the same. In contrast, with AppArmor’s path- based approach, the accessibility of a file system object may change if you create a hard link to that object, because each link can be associated with a different security profile. Turning to migration, it’s important to emphasize that translating AppArmor profiles to SELinux policies is not easy. AppArmor keeps profiles in the /etc/apparmor.d directory as simple text files. You need to understand the structure of an AppArmor profile to be able to get useful information from it.

TIP: Knowing the structure of an AppArmor profile can help you automate the process of analyzing and migrating profile rules. For example, you might write a script for extracting the necessary information from the profiles, reorganizing it into helpful structures for exploring and possibly customizing SELinux policies in the system you’re migrating to. First, though, you might want to pack the files in the /etc/apparmor.d directory into an archive to simplify the process of moving the profiles to another system or medium:

# tar zclpf apparmor_profiles.tgz /etc/apparmor.d Be aware that the script mentioned above is not supposed to automatically convert AppArmor profiles to SELinux policies (it would hardly be possible to imagine such a script). What it might do, however, is generate a customized report that could help you compare the security rules you had in SUSE Linux with those in Oracle Linux. For your convenience, the output of such a script might be in HTML or XML or even be sent to a relational database. The latter would enable you to view the profiles to be organized into groups based on the security rules applied.

SUSE Linux offers a GUI for working with AppArmor configuration and profiles. Thus, to look through the list of available profiles as well as to add a new profile or edit an existing one, you can use YaST: 1. Launch YaST by selecting Computer -> YaST. 2. In the YaST Control Center dialog box, in the Security and Users section, select AppArmor Configuration. 3. In the AppArmor Configuration dialog box, you can choose from several options, such as Generate Profile, Update Profile Wizard, Edit Profile, and Delete Profile. 4. If you want to look through the list of available profiles, you can choose Edit Profile. 5. Having looked through the entire list, you can select a profile for editing by double-clicking it. 6. Once a profile is opened for editing, you can double-click an entry of interest to view and/or edit its settings.

13 SUSE LINUX Enterprise Server 11 to Oracle Linux 6 Migration Guide

Figure 4. You can edit an AppArmor profile with YaST. In SELinux, you might take advantage of the SELinux Management GUI tool, part of the policycoreutils-gui package. By default, this tool is not installed, so it will need to be installed. Once it’s installed, follow these steps to view the policies: 1. Select System -> Administration -> SELinux Management. 2. In the SELinux Administration dialog box, click File Labeling in the Select pane to view the policies set on the files and processes. 3. Having looked through the entire list, you can select a policy for editing by double-clicking it.

14 SUSE LINUX Enterprise Server 11 to Oracle Linux 6 Migration Guide

Figure 5. You can modify a file labeling rule with the SELinux Administration tool. 4. Let’s now move on to the SELinux policy, viewing the set of rules it is composed of. For that, click Boolean in the Select pane.

Figure 6. You can view and modify the SELinux policy rules, changing the value of a Boolean if needed.

15 SUSE LINUX Enterprise Server 11 to Oracle Linux 6 Migration Guide

The process of security rules migration can be labor-intensive, especially if the list of those rules is long, but a competently organized inventory of AppArmor profiles can reduce the cost of migration. The ability to view the AppArmor profile information in the form of easy-to-read, informative reports can simplify the process of revising the default SELinux policy rules.

NOTE: SELinux is a comprehensive security solution, and it would be difficult to describe all the options available in this tool within the scope of this document. For more information on the features available in SELinux, see the documentation at https://linux.oracle.com/documentation/

System Installation and Configuration Both SUSE Linux and Oracle Linux offer tools for automatically performing operating system installation and configuration. SUSE Linux uses AutoYast, whereas Oracle Linux relies on Kickstart. These tools come in very handy for automating installations with standard configurations across multiple systems, obviating the need to work manually through the installation screens, doing the same work repetitively. Using AutoYaST, you can install SUSE Linux on one or more computers in parallel, with no user interaction. In Oracle Linux, using the Kickstart installation method is a common way to automatically install the operating system across the network. Like AutoYaST, Kickstart uses a configuration file (known as a Kickstart file) containing all the information needed to automate an Oracle Linux installation. As with AutoYaST, you can use a graphical interface to create or modify the configuration file required for Kickstart installations. Before you can use the Kickstart Configurator application, though, you must have the following packages installed in your system:

• pykickstart

• system-config-kickstart Once this requirement is met, you can follow the four steps outlined below to create or modify a Kickstart configuration file:

16 SUSE LINUX Enterprise Server 11 to Oracle Linux 6 Migration Guide

1. In Oracle Linux, launch Kickstart Configurator by selecting Applications -> System Tools -> Kickstart:

Figure 7. Launch Kickstart Configurator to create or modify a Kickstart file. 2. If you want to modify an existing Kickstart file, select File -> Open and choose the file. 3. In the left pane, you can browse through the groups, selecting one to view or to modify its configuration options. You can always review your current selections by selecting File -> Preview. 4. After you’re done with your selections, you can select File -> Save to save the chosen configuration as a Kickstart file. Once the Kickstart file is ready, you can make it available for the client systems by placing it in one of the following locations: a removable medium, a hard drive, or a network (the latter is most commonly used). For further detail on Kickstart, you can consult the Oracle Linux Installation Guide. In addition to the Kickstart utility, many customers make use of init scripts to load custom services during bootup. For customers on SUSE Linux, these scripts are located at /etc/init.d/boot.local. For customers migrating to Oracle Linux, these are located at /etc/init.d/rc.local. As part of the software and system inventory, customers should evaluate any custom services they could potentially be using with init scripts and note that they will have to be manually migrated.

17 SUSE LINUX Enterprise Server 11 to Oracle Linux 6 Migration Guide

Differences in Directory Structure When it comes to directory structures, SUSE Linux follows the Linux Standard Base (LSB) and, like Oracle Linux, also uses the Filesystem Hierarchy Standard (FHS) rules. However, there are some slight differences in the directory structure between SUSE Linux and Oracle Linux. FHS basically declares that /etc is the directory for static configuration files, but subdirectories, such as /etc/sysconfig, can be completely different between platforms. For example, Oracle Linux holds the ifcfg- files in the /etc/sysconfig/network-scripts/ directory whereas SUSE Linux doesn’t have this directory at all, holding those same files in the /etc/sysconfig/network directory. In turn, Oracle Linux has the /etc/sysconfig/network file instead of a directory. Table 1 lists some of the most important configuration files related to networking/routing, the operating system, and so on.

TABLE 1. DIRECTORY STRUCTURE MAPPING: SUSE LINUX AND ORACLE LINUX

CONFIGURATION SUSE LINUX ORACLE LINUX

Configurations for network interfaces /etc/sysconfig/network/ifcfg-* /etc/sysconfig/network -scripts/ifcfg-*

Static routing for each interface /etc/sysconfig/network/ifroute-* /etc/sysconfig/network -scripts/route-*

The IP addresses of DNS servers and /etc/resolv.conf /etc/resolv.conf the search domain

Resolving host names /etc/hosts /etc/hosts

OS *-release file /etc/SuSE-release /etc/oracle-release

Bootloader configuration /boot/grub/*, /etc/grub.conf, /etc/sysconfig/bootloader /boot/grub/*, /etc/sysconfig/grub

Runlevel configuration /etc/inittab, /etc/init.d/boot.local /etc/inittab

NFS configuration /etc/exports, /etc/fstab /etc/exports, /etc/fstab

Subscription Management The difference in managing patches and provisioning processes with SUSE Linux and Oracle Linux is another area you have to look into before migrating. Most SUSE Linux users use Subscription Management Tool (SMT) integrated with Novell Customer Center—a Web-based portal that enables you to obtain updates and support in one location—to simplify the management of software updates and subscription entitlements. As an Oracle Linux user, you’ll be able to access Linux software patches, updates, and fixes through the Unbreakable Linux Network:

18 SUSE LINUX Enterprise Server 11 to Oracle Linux 6 Migration Guide

Figure 8. The Unbreakable Linux Network provides access to software patches, updates, and fixes. To register an Unbreakable Linux Network account, you’ll need

• An Oracle.com single sign-on (SSO) account

• A valid Oracle Linux support or Oracle VM support customer support identifier (CSI). The latter can be purchased online via the Oracle Linux Store or your sales representative. Oracle Linux provides several features for managing patching and provisioning on Linux. Oracle Enterprise Manager is provided as part of your Basic or Premier subscription, and you can add standard Linux tools such as Yellowdog Updater, Modified (yum) to install and manage updates on your system. In addition, you can set up a local yum repository to mirror errata from the Unbreakable Linux Network and apply to your internal system. For more information, see How to Create a Local Yum Repository for Oracle Linux.

Transition Process

Once inventories are completed, you can begin the process of setting up a test environment, defining criteria for production release; developing a roadmap for conversions; and implementing systems, from test environments to production. The transition process outlined below assumes that your primary purpose is to move from SUSE Linux 11 to Oracle Linux 6, retaining the same physical server and the application layer as far as

19 SUSE LINUX Enterprise Server 11 to Oracle Linux 6 Migration Guide

possible, of course. When broken into main steps, the transition process might be thought of as comprising the following stages:

• Preparation

• Installing Oracle Linux

• Postinstallation

Preparation The preparation stage comprises the following steps: 1. Prepare a scratch area for saving the key configuration files of your SUSE Linux system as well as the datafiles you need to migrate. When preparing such storage, make sure you have created a file system compatible with Oracle Linux 6. 2. Before moving any files, make certain to shut down all running applications and services. To list all the services, you can use the following command:

# chkconfig --list Then, to disable the running services, you can use

# chkconfig -- off If you have Oracle products running in your system, check the Oracle documentation to find out the recommended order of their shutdown. After stopping all running applications and services, you can archive the files and directories, such as the ORACLE_HOME directory (if you have it), to back them up, and then you can send the archives to the scratch area prepared in the first step. Your particular list of files and directories to be backed up will depend on your specific configuration. The files generated during the inventory stage—those that contain information on hardware, software, network, and so on—must also be sent to the scratch area in this step. Once these preparatory tasks are completed, you can proceed to install Oracle Linux.

Oracle Linux Installation The process of Oracle Linux 6 installation is fairly straightforward. The following sections just outline some installation nuances for the migration. You can install the Oracle Linux 6 operating system manually, working through the installation screens. Alternatively, you can use the Kickstart installation method to have the installation performed automatically.

Customizing the Installation The default installation of the Oracle Linux 6 server is a basic server install, but you can choose to install a different set of software programs to meet your needs. Also, you’ll be able to select any additional repositories you want to install. Moreover, the software selection can be further customized during the installation. For that, you select Customize now on the software selection installation

20 SUSE LINUX Enterprise Server 11 to Oracle Linux 6 Migration Guide

screen. In the case of a Kickstart installation, the packages to be installed are specified in the Kickstart configuration file.

Figure 9. You can customize the software during the Oracle Linux installation process. It’s a good practice to install only the software packages needed for operation. The installation wizard enables you to customize the list of software packages to be installed in your system. Here are a couple of articles that describe best practices for hardening and securing your Oracle Linux environment.

• Tips for Hardening an Oracle Linux Server

• Tips for Securing an Oracle Linux Environment

Backing Up Your Data Before proceeding to migration, it’s always a good idea to have a scratch area into which you can back up the data and metadata to be replaced. It’s important to emphasize that backing up is, in many ways, not just copying. The users and permissions of the files must be preserved. If not, you may end up with read-only files your new system cannot write to.

Checking Port Availability Make sure you have the appropriate ports available on Oracle Linux for all the services you had running on SUSE Linux. To discover which ports are in use, you can view the /etc/services file. To see what ports are actually active, you might use netstat or a port scanner.

21 SUSE LINUX Enterprise Server 11 to Oracle Linux 6 Migration Guide

Postinstallation In a nutshell, the postinstallation process might comprise the following steps: 1. From the backup copy, restore the operating system configuration files, adjusting them for the new environment if necessary. 2. From the backup copy, restore the application-specific files. 3. Test the migrated services and applications for a while in a pilot mode to verify that they are all working correctly before turning them over to production.

Conclusion

A migration to a new operating system platform will encompass several areas, depending on the workloads and features used in your data center. The most important step is to plan and take a systematic approach in gathering data, evaluating your environment, testing, and finally migrating. Consider which applications are hosted on the systems and, for a large migration, plan your conversion in stages. Besides the information found in this white paper, there are several other resources with information that will assist you in learning the features of Oracle Linux. For additional information, you can visit

• Oracle Linux Installation Guide

• Oracle Linux Deployment Guide

SUSE LINUX Enterprise Server 11 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. to Oracle Linux 6 Migration Guide February 2013 This document is provided for information purposes only, and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in Oracle Corporation law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any World Headquarters liability with respect to this document, and no contractual obligations are formed either directly or indirectly by this document. This 500 Oracle Parkway document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our Redwood Shores, CA 94065 prior written permission. U.S.A.

Worldwide Inquiries: Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Phone: +1.650.506.7000 Fax: +1.650.506.7200 Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are oracle.com trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. 0213