Red_Hat_to_SUSE

Migrating from Red Hat*
to SUSE® LINUX Enterprise Server 9
SEPTEMBER 2004
A Novell® Migration Study w w w . n o v e l l . c o m

Disclaimer Novell, Inc. makes no representations or warranties with respect to the contents or
use of this document, and specifically disclaims any express or implied warranties of
merchantability or fitness for any particular purpose.
Trademarks Novell and ZENworks are registered trademarks; BrainShare is a registered. service
mark; and eDirectory is a trademark of Novell, Inc. in the United States and other
countries. SUSE is a registered trademark of SUSE LINUX AG, a Novell business.
* Red Hat is a registered trademark of Red Hat, Inc. Linux is a registered trademark of
Linus Torvalds. Windows is a registered trademark of Microsoft Corporation. UNIX is a
registered trademark of X/Open Company Ltd. IBM, S/390 and zSeries are registered
trademarks and POWER is a trademark of IBM Corporation. JBOSS is a registered
trademark of Marc Fleury. MySQL is a trademark of MySQL AB. Intel and Itanium are
registered trademarks of Intel Corporation. Solaris is a registered trademark of Sun
Microsystems, Inc. All third-party trademarks are property of their respective owners.
Copyright Copyright 2004 Novell, Inc. All rights reserved. No part of this publication may be
reproduced, photocopied, stored on a retrieval system, or transmitted without the
express written consent of Novell, Inc.
Addresses Novell, Inc.
404 Wyman Street, Suite 500
Waltham, MA 02451
USA
Novell UK Limited
Novell House
1 Arlington Square
Downshire Way
Bracknell
Berkshire
RG12 1 WA
Prepared by Novell Solution Creation and Marketing—Linux Team
Contributors John Beuchert, Global Solutions Director
Kurt Brust, Global Solutions Manager
Nathan Wilkey, Solution Support Lead
Doug Clower, Global Solutions Manager
Joyce Whiting, Solution Development Specialist
Date September 2004

Table of Contents
Introduction...................................................................................................5
Planning the Migration.......................................................................................5
Planning..................................................................................................6
Training..................................................................................................6
SUSE LINUX Enterprise Server 9............................................................................6
Preparing to migrate.........................................................................................7
Select Linux hardware ................................................................................7
Back up the source system............................................................................8
Locate the documentation............................................................................8
Make sure applications are SUSE LINUX-compatible..............................................8
Installing SUSE LINUX Enterprise Server 9................................................................8
Complete post-installation tasks....................................................................10
Begin the migration ..................................................................................10
Migrating User Accounts and Passwords.................................................................11
Move user accounts...................................................................................11
Move user passwords..................................................................................11
Migrating and Configuring Network Services............................................................12
DNS ...........................................................................................................12
Install DNS on SUSE LINUX Enterprise Server 9...................................................12
Migrate DNS ...........................................................................................12
Option one: Create a secondary DNS...........................................................13
Option two: Replace the DNS Server...........................................................13
Use Novell eDirectory to host DNS..................................................................13
DHCP..........................................................................................................14
FTP............................................................................................................16
Add users...............................................................................................16
VSFTPD modes.........................................................................................17
Standalone..........................................................................................17
inetd/xinetd........................................................................................17

Enable controlled access.............................................................................18
PAM ...........................................................................................................19
SSH/VPN......................................................................................................19
Set up the VPN client.................................................................................19
Set up the VPN script.................................................................................22
Migrating the File System..................................................................................23
With FTP................................................................................................23
With NFS................................................................................................24
With a file dump......................................................................................24
Moving from Red Hat Apache to SUSE Apache..........................................................24
With SCP................................................................................................24
With FTP................................................................................................25
Migrating E-mail Systems...................................................................................26
Configure Sendmail...................................................................................27
Generate the configuration file ................................................................27
Install the configuration file.....................................................................28
Copy users' mail from Red Hat .....................................................................28
Porting Applications........................................................................................28
Additional application porting resources .........................................................29

5
I N T R O D U C T I O N
This study addresses migrating from Red Hat* to SUSE® LINUX Enterprise Server 9—the first enterprise-class Linux*
server built on the new 2.6 Linux kernel. Released by Novell® in August 2004, it offers improved performance and
scalability for large-scale Linux deployments, rich software-development capabilities and industry-leading security
certification. As an added bonus, it's backed by the complete Novell software ecosystem of services and programs:
technical support, training, consulting and indemnification.
As you know, making a decision to change Linux distributions has many ramifications for your business and isn't
always as straightforward as it might appear. Of course, migration is easiest when the applications and services
you've been running on Red Hat are available on SUSE LINUX; you'll be happy to know that applications that run on
Red Hat will usually run on SUSE LINUX. In addition, many applications are not only SUSE-LINUX-ready, but are also
SUSE LINUX certified, which means that both Novell and the application vendor have certified and will support the
application on SUSE LINUX.
This migration study assumes that you've already decided that SUSE LINUX is the right direction for your
organization and that you are beginning to draft your migration plans. This study focuses on how to make the move
rather than on providing reassurance about why you should. It provides insight into what you will be looking at in
migrating edge-of-the-network infrastructure and basic file, print and e-mail services and is intended as a starting
point in your discovery. It does not represent all of the options available to you. Other Linux migration scenarios—
application migration, desktop migration and migration from other platforms (Windows* or UNIX* to SUSE LINUX)—
are addressed in companion Novell migration studies.
P L A N N I N G T H E M I G R A T I O N
As an IBM* Global Services white paper suggests, “Migration is not simply the rollout of new hardware, software
and applications. To make it as safe and cost-effective as possible, considerable preparation is required to
properly plan for, design, test, optimize and measure the new system. ... Failure to properly conduct a migration
to Linux can, at best, lead to greater costs. At worst, it could put mission-critical computing tasks at risk due to
mismanagement and reduce the credibility of an organization’s overall Linux initiative.” See “Successfully
Migrating to Linux: Business and IT Considerations,” IBM Global Services, June 2004, available at
http://www-1.ibm.com/services/us/its/pdf/g510-3885-00-linux-migration-wp.pdf
As you begin your migration, we suggest you plan carefully so that such a transition addresses not only your
immediate goals but your long-term strategy as well. You'll want to make sure your technical staff has the
necessary skills to implement and maintain a SUSE LINUX environment. While Red Hat and SUSE LINUX are similar
in many respects, you'll need to be aware of the differences. If your initial investigation suggests that you need
experienced help in planning and completing the migration, Novell Professional Services can provide consulting,
training and world-class support. Other organizations, including some hardware vendors, also offer professional
migration services.

6
Planning
Novell Professional Services offers consulting engagements that span the spectrum: from Strategy and Discovery to
Requirements Assessment, Planning and Design to Implementation. These offerings help you assess both current
and future strategies and discover your readiness for moving to SUSE LINUX, provide information about how to best
approach a migration and, finally, help you implement your migration plans. For additional information about
Novell Professional Services, refer to
http://www.novell.com/linux/migrate
Training
Because you are currently using Red Hat in your network, some of your technical staff are probably already Linux
certified [Linux Professional Institute (LPI) level 1 and/or LPI level 2]. If not, we recommend LPI certification.
Many third-party training and Linux certification courses are available to meet this need.
In addition to Linux certification, we recommend SUSE LINUX-specific training. Novell offers a variety of
instructor-led and self-study certification and training options, including the following:
• Novell Certified Linux Professional (Novell CLP) or SUSE Certified Linux Professional (SCLP); these courses
are the best place to start:
• Course 3036—Linux Fundamentals
• Course 3037—Linux Administration
• Course 3038—Advanced Linux Administration
• Course 3019—Migrating to SUSE LINUX (for experienced Linux administrators)
• Novell Practicum
• Novell Certified Linux Engineer (Novell CLE); these courses build on CLP and SCLP training:
• Course 3017—Fundamentals of Novell eDirectory
• Course 3015—Novell Nterprise Linux Services
• Novell Practicum
Note: Only the practicum exams are required for certification.
Novell certification and training options change periodically as new needs are identified and courses are
developed. To learn more about these and other training options, visit the Novell training Web site at
http://www.novell.com/training
S U S E L I N U X E N T E R P R I S E S E R V E R 9
Backed by Novell, SUSE LINUX Enterprise Server 9 offers improved performance and scalability for large-scale Linux
deployments. It also
• Features advanced I/O schedulers for quick application tuning
• Offers support for the latest hardware and advanced network, storage and connectivity features—including
clustering capabilities—for redundancy and automatic failover across peripherals and the network
• Provides Hotplug services so hardware can be changed without system disruption
SUSE LINUX Enterprise Server 9 also offers rich software-development capabilities through built-in network
services and protocols, including CUPS, DNS, DHCP, IMAP, NTP, SLP, Postfix, PXE, Proxy, Samba, SNMP, SMTP and

7
many others. Additionally, it includes application and database services—such as Apache, JBoss*, Tomcat, MySQL*
and PostgreSQL—and supports popular solutions from hundreds of independent software vendors. Numerous
architectures are also supported, including x86, AMD64, Intel* EM64T, the Intel Itanium* Processor family, IBM
POWER*, IBM zSeries* and IBM S/390*.
SUSE LINUX Enterprise Server 9 is being evaluated for compliance with the Common Criteria Controlled Access
Protection Profile Evaluation Assurance Level 4+ (CC-CAPP/EAL 4+). Certification is expected shortly after the
product release. SUSE LINUX Enterprise Server 8 achieved the highest level of security and operations certification
ever in the Linux market: CAPP/EAL 3+.
Other security features include
• Rich user management, authentication and access control
• Support for encrypted file systems
• Easy-to-use certificate authority and management
• Virtual private networking
• Integrated firewall and proxy services
• Automated monitoring and intruder detection
With an array of unique management features, SUSE LINUX Enterprise Server 9 is easy to deploy, configure and
maintain across the enterprise:
• Yet another Setup Tool (YaST) enables easy installation and configuration of the operating system, network
services, storage, clusters and even applications. (Novell has recently made YaST available to the Open Source
community.)
• AutoYaST enables “no touch” deployment of Linux across your infrastructure.
• Open application programming interfaces (APIs) and support for the Common Information Model (CIM)
standard allow integration with third-party management solutions.
• Class-based kernel resource management (CKRM) allows mainframe-like partitioning of large-scale servers.
• Directory-enabled configurations provide centralized management.
• Built-in support for Novell ZENworks® Linux Management offers an optimal solution for keeping Linux servers
and applications up-to-date and secure.
To access a document describing the numerous technical features of SUSE LINUX Enterprise Server 9, refer to
http://www.novell.com/products/linuxenterpriseserver/sles9_featurelist_technical.pdf
P R E P A R I N G T O M I G R A T E
Select Linux hardware
Not all hardware drivers—particularly SCSI adapters and drivers for graphics, sound, video and network cards—are
Linux-compatible. If you are using the same hardware for SUSE LINUX Enterprise Server 9 as you did for Red Hat,
however, you should have few problems. Just be aware that the same computer make and model is sometimes
shipped with slightly different driver configurations and that these differences can take their toll. Having multiple
SCSI adapters of the same make that need the same Linux driver can also cause problems: only one of the devices
is recognized by the machine on bootup.
Many of the larger companies produce drivers specifically for Linux, but many vendors leave this to the Linux
community. Because the hardware market changes rapidly, almost daily, you'll want to monitor the market

8
closely. Before purchasing a server, check with the vendor or the vendor's Web site to determine whether the
hardware drivers you need for a specific adapter are available. To be certain, consider purchasing a server with
SUSE LINUX Enterprise Server 9 pre-installed.
Check the following sources for additional hardware information:
• The Linux home page at Linux online: http://www.linux.org
• The Xfree86 Project, Inc.: http://www.Xfree86.org
• The Linux Documentation Project on “Hardware Compatibility”: http://www.tldp.org/HOWTO/Hardware-
HOWTO/)
Back up the source system
Make sure you have a backup to a tape or another hard drive. Disasters can happen, even with Linux.
Locate the documentation
Most of the basic Linux commands, system calls, libraries and system configuration files are documented in manual
pages (as they are with Red Hat), but don't ignore HOWTO and README files and GUI-based help programs.
Additionally, most packet managers (RPMs) install the source code documentation—a good source for additional
information—under /usr/share/doc.
You'll also want to refer to the SUSE LINUX Enterprise Server 9 Installation and Administration manual for detailed
information about the services referred to in this paper:
http://www.novell.com/documentation/sles9/index.html
Make sure applications are SUSE LINUX-compatible
While application compatibility is not the subject of this migration study, you will need to make sure SUSE LINUX
versions or alternatives are available for any home-grown or third-party applications you will be migrating from
Red Hat. Make sure you have the necessary Linux CDs, and make sure you test applications in a lab or pilot
environment before rolling them into production.
I N S T A L L I N G S U S E L I N U X E N T E R P R I S E S E R V E R 9
The SUSE LINUX Enterprise Server 9 installation is simple and GUI-driven; basic steps include the following:
• Select a location for installation files
• Choose the geographical locale
• Select the software packages to install
• Set the configuration for keyboard, video card and mouse for X Windows
In most cases SUSE LINUX Enterprise Server 9 probes the hardware to discover which drivers are needed and
prompts for boot loader installation: LInux LOader (LILO) or GRand Unified Bootloader (GRUB).
Explanations for all steps are documented in the left pane of the SUSE LINUX Enterprise Server 9 installation
screens; if you need additional information, the complete SUSE LINUX Enterprise Server 9 Installation and
Administration manual is downloadable from
To install SUSE LINUX Enterprise Server 9, complete the following:

9
1. Insert CD 1 and boot up.
2. Provide information for the following settings:
System—Leave at the default
Mode—Perform new installation
Keyboard—Accept default (US ENGLISH) or change it as needed
Mouse—Leave as is (should be auto-detected)
Partitioning—Accept default partitioning or change it as needed
Software—Select this option, click Detailed Selection and choose File Server (NFS/Samba) from the
right-hand window. Select any other software you want installed.
Booting—Leave default as GRUB
Time Zone—Set to your location
Language—Accept default (US ENGLISH) or change it as needed
Default runlevel—Leave default as GUI login
3. When finished, click Accept, and then click Yes, Install.
Depending on the speed of the machine and the applications you've chosen to install, this can take
anywhere from 15 to 60 minutes. Once the packages have been installed, you will see a Finishing Basic
Installation screen.
4. Click OK to reboot (or, after 10 seconds, the machine will reboot on its own).
5. When prompted, enter a password for root and click Next.
6. At the Network Configuration screen, click Next to save your network settings.
7. At the Test Internet Connections screen, choose Next.
8. At the Service Configuration screen, choose Next to view the Lightweight Directory Access Protocol (LDAP)
server configuration settings.
9. When prompted for the type of User Authentication to implement, choose LDAP [Network Information
Service (NIS) and Local are the other choices; Local is least secure] and then select Next.
10. If using LDAP, specify a name for your Certificate Server, and then choose Next.
11. At the Release Notes screen, scan the notes for any items that might affect your configuration, and then
click Next.
12. At the Hardware Configuration screen, make sure the video, printer and other defaults are set the way you
want them for your environment, and then click Next.

10
13. When you are informed that the installation is complete, click Next. Your computer will reboot and return
you to the login screen.
Complete post-installation tasks
Once installation is complete, you'll want to make sure your server is operating as expected and that you have a
way to recover, if necessary. For example:
• Verify network connectivity. Make sure the computer is being recognized on the network by pinging the
router, gateway or other computers.
• Keep a system snapshot. It's always good to keep a snapshot of your new system so you have a way to recover
if, for example, a hard drive fails.
• Create and test boot diskettes. You'll want both boot and rescue diskettes.
• Check all major application packages to make sure they work.
• Create a non-root account. You won't want to log in as root unless you are completing tasks that can be done
only as root. Use the non-root account for day-to-day activities so that you won't inadvertently compromise
your system.
Begin the migration
General migration steps are noted here for moving typical edge (infrastructure and networking) services as well as
Web-server, database, file, print and e-mail services to SUSE LINUX Enterprise Server 9. For additional detail about
each service, refer to the corresponding sections below.
• Start by determining which services to migrate.
• Determine which source directories you are moving files from and which destination directories you are
moving them to.
• Move the designated files from Red Hat to SUSE LINUX Enterprise Server 9 via Secure Copy Protocol (SCP) or
FTP; use FTP if you are transferring files internally or SCP if you are transferring files over the Internet. Both
FTP and SCP are included with SUSE LINUX Enterprise Server 9.
• You will be moving all HTML files from the /etc./var/docs directory on the Red Hat box to /srv/www/htdocs
on the SUSE LINUX Enterprise Server 9 box.
• Manually verify that all necessary files have been copied to the new SUSE LINUX Enterprise Server 9 box. (If
there were 640 files in one directory on Red Hat, make sure 640 have been copied to SUSE LINUX Enterprise
Server 9.)
• Test your Web site. Note that there are programs (spiders) that test Web sites; these are run from a Windows
machine and test every page on your Web site to make sure there are no errors. For additional information,
refer to
http://www.download.com
or
http://www.tucows.com
• Test the migrated services for a day or two in a test or pilot lab before cutting them over to production. If you
will be running both the source Red Hat and destination SUSE LINUX Enterprise Server 9 services on the same
network, you will need to provide IP addresses, at least temporarily, for both systems. You may also need to
tweak the DNS configuration if both sets of services are running side by side.
• When you have verified that all services are working correctly, remove Red Hat from service.

11
M I G R A T I N G U S E R A C C O U N T S A N D P A S S W O R D S
Move user accounts
Moving user accounts from Red Hat to SUSE LINUX Enterprise Server 9 is not an easy or straightforward task. To
make moving accounts (identities) easier, but not foolproof, you can use products such as Novell Account
Management (NAM ) 3.0, Pluggable Authentication Modules (PAM), LDAP redirection, or PADL (we recommend PDL
only for experts).
Rather than managing individual accounts on each server, consider porting users to an enterprise directory (such as
Novell eDirectory™) to centralize authentication and administration and increase security.
User account locations are different on the two systems:
• On Red Hat, user accounts are stored in /etc/password
• On SUSE LINUX Enterprise Server 9, user accounts are stored in /etc/passwd.
Both include user name, password placeholder (for /etc/shadow), user ID (UID), group ID (GID), description,
home directory location and default shell.
• Passwords are stored in /etc/shadow on both systems but are encrypted differently.
Tools are available to convert the accounts in the Red Hat /etc/passwd directory into LDAP Data Interchange
Format (LDIF) so they can be imported into an LDAP directory on SUSE LINUX Enterprise Server 9. Passwords are
not converted and will need to be reassigned.
For a useful /etc/passwd–to-LDIF conversion script, see
Site: http://www.padl.com/OSS/MigrationTools.html
Tool: migrate_passwd.pl (migrates users in /etc/passwd)
Other helpful migration tools are also available from this site.
Move user passwords
To allow users to keep the same password when migrating from Red Hat to SUSE LINUX Enterprise Server 9, follow
these instructions provided by Lenz Grimmer:
http://lists.suse.com/archive/suse-linux-e/2000-Dec/0867.html
• If you were using shadow passwords on the old system, just add the respective users from /etc/passwd and /
etc/shadow to the new SUSE password files. Afterward, you can copy over the users' home directories.
• Note that some Red Hat dotfiles might not work on SUSE (for example,
.xinitrc, .bashrc and others). Have a look at /etc/skeleton and replace the files, if necessary. (Compare what
you have in Red Hat to those in the SUSE LINUX Enterprise Server 9 directory /etc/skeleton.)
• If you were using MD5 passwords on Red Hat, you will first need to enable MD5 password support by editing
/etc/pam.d/passwd on the SUSE LINUX Enterprise Server 9 server:
Replace the line
password required /lib/security/pam_unix.so nullok use_first_pass use_authtok
with
password required /lib/security/pam_unix.so nullok md5 use_first_pass
use_authtok

12
and then replace the user entries in /etc/passwd.
Note: You cannot simply replace the /etc/passwd file because the SUSE LINUX Enterprise Server 9 file
contains several system daemon accounts that are different for each distribution.
You can also obtain the tool JOHN the Ripper to move /etc/shadow passwords. See
http://www.openwall.com/john
M I G R A T I N G A N D C O N F I G U R I N G N E T W O R K S E R V I C E S
In most cases, migrating networking services (sometimes called edge services) from Red Hat to SUSE LINUX
Enterprise Server 9 is fairly straightforward because of the similarities in the two systems. Basic information about
migrating primary services is included below.
D N S
To begin the Domain Name Service (DNS) migration, take inventory of the current file structure on Red Hat so that
you can either replicate it on SUSE LINUX Enterprise Server 9 or change it to better meet your needs. Red Hat
typically uses the following structure:
• /etc/named.boot—defines how the named daemon initializes the DOMAIN name file server
• /var/named/named.ca—contains information about the root name servers
• /var/named/hosts—contains local server name and IP which may or may not be part of DNS SERVER
• /var/named/hosts.rev—specifies one or more reverse domain files
• /var/named/named.local—specifies the PTR record for the local loopback interface at the IP address
127.0.0.1
• /etc/resolv.conf—does a reverse of the domain name and the IP address.
• /etc/dhcp/inittab—stores initial information before the implementation
Install DNS on SUSE LINUX Enterprise Server 9
DNS is installed along with other networking services as part of the SUSE LINUX Enterprise Server 9 LDAP server.
The name server Berkeley Internet Name Domain (BIND) is included and comes pre-configured so it can be started
immediately after installation. BIND name server settings are stored in /etc/named.conf. However, the zone data
(host names and IP addresses) is stored in separate files in the /var/lib/named directory.
DNS can be configured with YaST, which provides both Wizard and Expert options. The name server runs as a pure,
caching-only name server until you configure its zones.
To start the name server, enter the command rcnamed start. (You must be logged in as root.) If the name
server does not start or behaves in an unexpected way, you can usually find the cause in the /var/log/messages
log file. Use rcnamed status to see whether the server is actually running.
Migrate DNS
This section includes instructions for manually migrating DNS from Red Hat to SUSE LINUX Enterprise Server 9
(BIND) using one of two options.

13
Option one: Create a secondary DNS
If you are currently running a primary DNS on Solaris*, you can use the information in the secondary zone file on the
Solaris server to create the primary zone on SUSE LINUX Enterprise server 9.
1. Complete a zone transfer by running the rndc command.
2. Use the secondary zone file on the Solaris server to create the primary zone file for SUSE LINUX
Enterprise Server 9.
3. Change from the secondary to the primary using the BIND config or change this in the
named.conf file.
Option two: Replace the DNS Server
If you are replacing the Red Hat DNS server completely, follow these instructions:
1. Create slave entries on the SUSE LINUX Enterprise Server 9 server for each of the zones in your Red Hat
named.conf file.
zone "example.org" {
type slave;
file "s/db.example.org";
masters {
10.11.1.3;
};
allow-query { any; };
};
2. Change the domain name, file path and master DNS server IP address to those for the Red Hat system. This
will cause Named to do a zone transfer of each of the domains into its respective files.
3. Change "slave" to "master" in named.conf (most often found in /etc/named).
Note: you can also do a zone transfer using named-xfer for each of the x number of domains.
4. Edit each of the domain config files, changing the nameserver (NS) and start of authority (SOA) records to
match the new nameserver.
ndc reload and named will now act as the primary DNS server for these zones.
Use Novell eDirectory to host DNS
Novell eDirectory has traditionally used Service Advertising Protocol (SAP) and Service Location Protocol (SLP) to
search for and advertise network services. DNS was added as a discovery protocol in eDirectory 8.7.1. This
enhancement means that if you ask for a tree name that eDirectory doesn't understand (either because you are

14
communicating with a server that doesn't hold a copy of the tree or you are using a standalone application), the
machine trying to do the discovery uses eDirectory discovery protocols, in the following order:
• DNS
• SLP
• SAP
Novell recommends putting the eDirectory tree name in DNS using an A, AAAA or Service (SRV) resource record
under the DNS domain the clients are going to use to resolve names. If you use A or AAAA records, the eDirectory
servers must be running on the default 524 port. If the servers are using any other port, use an SRV record.
For complete information, see “How Novell eDirectory Works with DNS” in the eDirectory Administration Guide at
http://www.novell.com/documentation/lg/edir873/index.html?page=/documentation/lg/edir873/edir873/data/a
2iii88.html
D H C P
DHCP servers (or daemons) provide clients with the ability to "plug and play" when connecting to any network.
Using DHCP daemons provides a way to administer IP information without going from workstation to workstation to
add it. The core of any DHCP system is the DHCP daemon that leases addresses and watches how those address are
used, according to settings the administrator defines in /etc/dhcpd.conf.
Both a DHCP server and DHCP clients are available for SUSE LINUX Enterprise Server 9. The DHCP server available
is dhcpd [published by the Internet Software Consortium (ISC)].
To move from DHCP on Red Hat to DHCP on SUSE LINUX Enterprise Server 9, you will need to set up DHCP on SUSE
LINUX Enterprise Server 9 and then follow the zone transfer information below to manually transfer the zones from
the DHCP box on Red Hat to the DHCP box on SUSE LINUX Enterprise Server 9. Although this is a manual process, it
should take only a half hour or so to complete. Once the zone transfer is finished, you'll need to shut down DHCP
on Red Hat.
Use the DHCP module in YaST to set up the DHCP server for the local network. The module can work in two
different modes: initial and expert. Use the configuration assistant to walk through the configuration process.
DHCP can be set up to store the server configuration locally (on the host that runs the DHCP server), or an LDAP
server can manage the configuration data.
The DHCP daemon can be activated with rcdhcpd start and is ready for use immediately.
Use rcdhcpd check-syntax to check the syntax of the configuration file. If you encounter any unexpected
problems, Use the information in log /var/log/messages to help pinpoint the problem.
On a default SUSE LINUX Enterprise Server 9 system, the DHCP daemon is started in a chroot environment for
security reasons. The configuration files must be copied to the chroot environment so the daemon can find them.
The files are copied automatically by rcdhcpd start.
To improve security, the SUSE LINUX Enterprise Server 9 version of the DHCP server comes with the non-
root/chroot patch applied. This enables dhcpd to
• Run with the permissions of nobody

15
• Run in a chroot environment (/var/lib/dhcp/)
To make this possible, the configuration file /etc/dhcpd.conf needs to be located in /var/lib/dhcp/etc/. The
corresponding init script automatically copies the file to this directory upon starting. The server’s behavior with
regard to this feature can be controlled through the configuration file /etc/sysconfig/dhcpd. To continue running
dhcpd without the chroot environment, set the variable DHCPD_RUN_-CHROOTED in /etc/sysconfig/dhcpd to no.
To set up DHCP on the SUSE LINUX Enterprise Server 9 server, use the following procedure:
1. Install DHCP on the SUSE LINUX Enterprise Server 9 server, if it's not already installed, from the
RPM package included in the distribution.
# rpm -ihv dhcp-*.rpm
2. Edit the /etc/dhcpd.conf file on the SUSE LINUX Enterprise Server 9 server to modify the variables
for your specific environment:
At the Red Hat box
a. Check the /var/named/dhcptab file and note the IP zone range
b. Check the subnet
3. At the SUSE LINUX Enterprise Server 9 box
a. Add the correct IP subnet to the subnet x.x.x.x
b. Add this range to the range dynamic-bootp x.x.x.x x.x.x.x
You can also obtain the lease time and DNSDAMIN values from this file.
In the example below, the server is assigned an IP address of 10.0.0.1 and provides IP addresses
for up to 253 clients.
Sample /etc/dhcp.conf file
#/etc/dhcpd.conf
server-identifier dhcp.clonedomain.com;
default-lease-time 172800;
max-lease-time 604800;
option domain-name "clonedomain.com";
subnet 10.0.0.0 netmask 255.255.255.0 {
range dynamic-bootp 10.0.0.2 10.0.0.254;
4. Start the DHCP server on SUSE LINUX Enterprise Server 9 by entering the following command:
/etc/rc.d/init.d/dhcpd start
5. Stop the Red Hat DHCP server with
/etc/init.d/dhcpd stop

16
F T P
Note: The information in this section is abstracted from “Use VSFTP for a secure, reliable FTP server,” by Scott
Lowe, January 22, 2003. Read the entire article at
http://techrepublic.com.com/5100-6261_11-5034763.html
Many FTP servers are currently in use. Very Secure FTP Daemon (VSFTPD) is considered one of the best in terms of
stability, scalability and security. If you are using a different FTP server, we recommend that you consider using
VSFTPD as part of your overall migration effort.
If VSFTPD is not already installed on your system, you can install it using YaST from the SUSE LINUX Enterprise
Server 9 installation media or download it from
http://vsftpd.org
Add users
VSFTPD uses the Linux/UNIX nobody user as a part of the default configuration. On most Linux/UNIX operating
systems, this user exists by default; if not, it is easy to add.
If you want to support anonymous FTP so users can download information from your servers without
authenticating, you'll need to create an FTP user. Doing so reduces account administration overhead but also
reduces the security of the server because anyone can access the files. To preserve the security of VSFTPD, the
anonymous user’s home directory must not be owned by the FTP user, and the user should not have any
permissions for it.
Use the commands in the table below to set up VSFTP:
VSFTPD Commands
Command Description
mkdir/srv/ftp/ Creates a directory named /var/ftp
/usr/sbin/useradd -d /srv/ftp ftp Creates a user ftp with the home directory /var/ftp; on many
systems, this user will already exist
chownroot.root /srv/ftp Changes ownership of the /var/ftp directory to the root user
chmodog-w /srv/ftp Removes the write permission from others and groups
Next, make sure the /usr/share/empty directory exists. If not, create it with the mkdir command.
Finally, install the executable file, help pages and other components not installed by default with VSFTPD. To
install these, change to the directory in which you built vsftpd and type make install. This installs everything
you need to begin using VSFTPD except a configuration file. You can copy a sample configuration file (vsftpd.conf)
located /int /etc/vsftpd/ to the /etc directory by typing cp vsftpd.conf /etc.

17
VSFTPD modes
VSFTPD can be run in two modes: standalone and inetd/xinetd.
Running the product through the inetd (or xinetd) daemon gives you more control and is the recommended
method. Another thing to keep in mind is that, as configured, VSFTPD will accept only anonymous connections,
assuming that you created the FTP user previously. If you want to allow local users to authenticate, you will also
need to configure PAM. See the PAM section on page 19 for additional detail.
Standalone
To run VSFTPD in standalone mode, add a single line to the end of the /etc/vsftpd.conf file that reads
listen=YES and then execute /usr/local/sbin/vsftpd &.
The & tells the program to continue to run but brings you back to a command prompt. Assuming you get no error
messages, you can now connect to the FTP server as an anonymous user and get directory listings, transfer files
and so forth.
inetd/xinetd
If you are running an xinetd machine, refer to the installation instructions included with VSFTPD, downloadable
from
http://vsftpd.beasts.org
Basically, you will need to
• Go into /etc/xinet.d
• Edit the file vsftpd by changing the disable= line to no
• Restart the inetd daemon either via a reboot or kill -SIGHUP {pid of inetd}
xinet.d/vsftpd Parameters
Option Default Explanation
socket_type stream The type of TCP socket to use for this protocol; FTP is a
TCP stream
wait no The ability for the socket to accept or deny messages
user root The user who will launch this service; note that VSFTPD
reduces privileges as soon as possible after starting
server/usr/sbin
/vsftpd
The location of the server program associated with this
configuration file; if VSFTPD is in a different location,
change this value to match
nice 10 The option to modify the default scheduling priority for the
process; 10 is the default with the range being negative 20
(highest) to 19 (lowest)
disable no The option to disable the service; should be started when
xinetd starts up

18
Option Default Explanation
per_source no The number of concurrent connections allowed from the
same IP address; useful for limiting the number of
connections from a single site
instances no Limits the maximum number of concurrent FTP connections
to the server; useful for limiting server load
no_access no Lists the IP addresses that are not allowed to access this
service
Using the default configuration file, restart xinetd on SUSE LINUX Enterprise Server 9 by typing
/etc/init.d/xinetd restart at the command prompt.
The edited file should appear as follows:
service ftp
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/vsftpd
disable = no
}
Note: If you previously configured VSFTPD in standalone mode, remove the line listen=YES from
/etc/vsftpd.conf. If you don’t, xinetd will restart, but the VSFPTD service will not work.
You should now be able to connect to the VSFTPD server as an anonymous user and get directory listings and
download files.
Enable controlled access
Setting up an FTP server to distribute software to anyone who connects can be useful in many cases, but you may
want to control access to the FTP resources. For example, suppose you want to set up a site just for your
customers. You can do this with VSFTPD by making use of PAM. SUSE LINUX Enterprise Server 9 uses PAM for
authentication. To determine whether other distributions use PAM, look for a file named pam.conf or a directory
named pam.d.

19
VSFTPD comes with a sample PAM configuration file. Rename the file and copy it to the pam.d directory. Name the
file either “ftp” or use the value specified by the “pam_service_name” parameter in /etc/vsftpd.conf; for
example: cpvsftpd.pam /etc/pam.d/ftp.
Next, change the VSFTPD configuration to allow local user logins. To do this, edit the file /etc/vsftpd.conf and
uncomment the line local_enable=YES.
Now when you attempt to connect to the server as a Linux/UNIX user, you will be placed in that user’s home
directory.
P A M
PAM modules are shared libraries that allow the system administrator to choose how an application will
authenticate users.
Red Hat and SUSE LINUX Enterprise Server 9 both use the same file system structure for PAM configuration files.
The /etc/pam.d directory contains a file for each service that might request authentication; these files dictate
how the authentication will behave.
The default files provided by Red Hat and SUSE LINUX Enterprise Server 9 are different but provide similar
functionality. Any modifications or customizations that have been made to the default PAM behavior on the Red
Hat platform should be documented and then tested on the SUSE LINUX Enterprise Server 9 platform as part of the
migration.
If custom PAM modules have been developed for specific applications, these modules should also be thoroughly
tested for compatibility on SUSE LINUX Enterprise Server 9. Most modules should work and will provide the same
functionality without need for modification.
S S H / V P N
Set up the VPN client
Before you begin, you'll need to meet the following prerequisites:
• You have installed Open Secure Shell (OpenSSH) on the computer you will be connecting to; it is included with
the SUSE LINUX Enterprise Server 9 distribution.
• You have access to the computer that’s running OpenSSH.
• You understand networking and TCP/IP in a Linux environment.
• You understand basic Linux commands.
Note: Edit the /etc/hosts.allow file to add the IP addresses that are to have access.
Complete the following steps:
1. Make sure necessary security precautions have been taken:
• Turn off all unnecessary services on your Linux computer.
• Make sure security patches are up-to-date.
• Use TCP wrappers to restrict the range of IP addresses that can access your computer.

20
• Disable SSH root logins on both your computer and the source computer by editing the login file
located in /etc/pam.d;
• Rem out the first auth line and save the file.
• Disable password-only authentication for SSH connections.
Note: If you are using Network File System (NFS) with SSH, disable this option in the
/etc/ssh/ssh_config file instead.
• Use a private/public key pair for authentication rather than a password.
• Make sure the company firewall is configured to open only TCP port 22 to your source machine.
2. Log in to the machine you are working from with your normal UID.
3. Open a terminal session and create a key pair with the sshh-keygen command:
$ ssh-keygen -t rsa -f ~/.ssh/vpn-key Generating public/private rsa key pair
4. Create a passphrase or press Enter to create a key with no passphrase.
Note: Using a passphrase in this instance doesn’t add significantly more security but does make your
virtual private network (VPN) more cumbersome to use. If you or your employer insists on having one,
then see man ssh-agent for some tips.
5. Make an SSH connection to your office machine. This will hereafter be referred to as session #1.
It's important to keep this session open as there is a possibility of locking yourself out of your office
machine if you type the wrong information.
6. Once connected to the office machine, type su - to become root.
7. Make sure /etc/hosts.deny on both machines contains the line: ALL: ALL
8. Enter the following lines to /etc/hosts.allow on the office machine:
ALL: 127.0.0.1
sshd: a.b.c.d/255.255.255.x
Substitute your own machine's IP address and sub-netmask for a.b.c.d/255.255.255.x
9. Start a new shell session on your machine. Verify that you can still make an SSH connection to the office
machine. If not, return to session #1 and review the logs to identify the problem. Refer to man
hosts.allow for help in problem diagnosis.
10. When you have verified that session #1 is still running properly, close the second SSH session and return
to session #1.
11. Working as root on the source machine, make sure the following lines are uncommented in
/etc/sshd/sshd_config:
Protocol 2
PermitRootLogin no
PasswordAuthentication no
Note: You will probably want to disable SSH v. 1 for security reasons (numerous protocol vulnerabilities);
not all Windows clients use SSH v.2, however, so you will need to change the client version as well.

21
See “Understanding and Implementing Security on SUSE Linux,” a BrainShare® 2004 tutorial,
downloadable from the Novell innerweb at
https://innerweb.novell.com/resourcecenter/item.jsp?itemId=12723
Note: You may be able to find this tutorial (TUT 303) on the Novell Web site but BrainShare files are
available only temporarily; try
http://www.novell.com/brainshare/catalog/controller/catalog
12. Save any changes and type:
/etc/init.d/sshd restart
13. Return to the shell session on your PC and make sure you can start a new SSH session with the office
machine. Again, if you have problems, check the logs to see why.
14. Return to session #1 and create a non-root user (on the office machine) that you can use to run the PPP
daemon:
# useradd vpn
# passwd vpn
Changing password for user vpn.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
15. Configure the sudo command so that the vpn user is allowed to run the PPP daemon as root. Type
visudo and add the following to the bottom of the file:
Cmnd_Alias VPN=/usr/sbin/pppd
Cmnd_Alias IFCONFIG=/sbin/ifconfig
Cmnd_Alias IPTABLES=/sbin/iptables
Cmnd_Alias PS=/bin/ps
Cmnd_Alias KILLALL=/usr/bin/killall
vpn ALL=NOPASSWD: VPN
vpn ALL=NOPASSWD: IFCONFIG
vpn ALL=NOPASSWD: IPTABLES
vpn ALL=NOPASSWD: PS
vpn ALL=NOPASSWD: KILLALL
16. Set the SSH options for the vpn user to allow login access from your PC:
# su – vpn
$ mkdir .ssh
$ chmod 755 .ssh
$ cd .ssh
$ vi authorized_keys

22
17. In the vi session (or text editor of your choice), paste the contents of the ~/.ssh/vpn-key.pub file
from your machine.
Save the file and set its ownership and permissions appropriately:
$ chown vpn:vpn /home/vpn/.ssh/authorized_keys
$ chmod 600 /home/vpn/.ssh/authorized_keys
18. From your network administrator, obtain a second, fixed LAN IP address for the office machine. This
interface will be used to NAT the traffic that travels through the Point-to-Point (PPP) tunnel, allowing
the PPP tunnel to connect your machine to the office LAN.
Set up the VPN script
Open a root shell on your remote machine and add the following to /etc/sysconfig/vpnopts:
# config file for VPN access to the office
# IP address of the remote machine to be connected
SERVER_HOSTNAME=mypc.officedomain.com
# username on the server that we run the tunnel as
SERVER_USERNAME=vpn
# use these IP addresses for the client and server ends of
# the PPP session
CLIENT_IFIPADDR=192.168.3.1
SERVER_IFIPADDR=192.168.3.2
# change these to match your office network
SERVER_LAN2=10.0.0.0
SERVER_LAN2_IF=10.0.100.0
SERVER_LAN2_MASK=255.255.255.0
# various SSH options for the client side
LOCAL_SSH_OPTS="-P -p 22"
LOCAL_VPNKEY=/home/phile/.ssh/vpn-rsa
# pppd options for the client and server
LOCAL_PPP_OPTS="updetach noauth passive ipparam vpn"
REMOTE_PPP_OPTS="nodetach notty noauth"

23
M I G R A T I N G T H E F I L E S Y S T E M
Once SUSE LINUX Enterprise Server 9 is installed, you can use one of several options for transferring files from the
Red Hat to SUSE LINUX Enterprise Server 9. You can set up the SUSE LINUX Enterprise Server 9 file system to mimic
the one on Red Hat, or consider this an opportunity to consolidate and reconfigure the file structure.
• You can manually create the directories on the SUSE LINUX Enterprise Server 9 server from a printout of what
you have on the Red Hat server (a time-consuming process).
• You can gzip or tar up files on the Red Hat server and then gunzip these files into their respective directories
on SUSE LINUX Enterprise Server 9.
There are three tested methods for transferring files (listed in order of preference):
• Use FTP or SCP
• Use NFS
• Use a file copy through an intermediate device (such as a drive attached to a workstation or the workstation
itself)
Note: Only the NFS method maintains ownership and permissions on the files. The other options lose this
information; the values must be regenerated once the files are relocated.
With FTP
Even on a fast network (100MB/sec and above), transferring files can be the most time-consuming event in a
migration. One of the easiest ways to transfer files from Red Hat to SUSE LINUX Enterprise Server 9 is using FTP.
FTP transfers typically provide the greatest transfer rates, but ownership and permission values are not
transferred. You will need to reassign them.
FTP is robust enough to handle transfers of large amounts of data. Furthermore, there are a number of smart FTP
clients that can resume a transfer where it left off: for example, ncftp (interactive) and wget (command line).
If there is a problem using the -c flag—continue, wget can perform this type of functionality and is included with
SUSE LINUX Enterprise Server 9. There is also a good chance FTP services are already running on the server where
the data resides; if not, FTP is easily set up.
SUSE LINUX Enterprise Server 9 includes a basic FTP client and server. Novell recommends using a client (such as
ncftp) that supports specifying directories as part of the transfer. Recursive directory retrieval is supported by
wget as well. This will facilitate retrieving large directory structures such as users' home directories.
The basic process for transferring files using FTP is as follows:
1. Where possible, position the two servers sharing the transfer as close together as possible.
Both servers should be on the same subnet, and if possible, on the same physical network switch. This
will reduce network latency and can increase security during file transfer.
2. Confirm that the Red Hat server holding the data has a configured FTP server. (You will need to know the
IP address and login ID).
3. Make sure file and directory permissions have been determined for incoming data on SUSE LINUX
Enterprise Server 9.

24
4. Start the FTP service on the Red Hat server containing the files to be migrated. The FTP service can be
configured to run from the super daemon inetd or xinetd.
Note: FTP is usually “off” by default for security reasons.
5. Log in to the system you are transferring files from using the FTP client on the SUSE LINUX Enterprise
Server 9 system.
6. Navigate to the data to be retrieved.
7. Make sure the FTP client is prepared to place the incoming data in the correct directory (at the command
line, use the lcd command; for GUI programs, navigate graphically to the correct location).
8. Begin the transfer. For large amounts of data this may take a while.
With NFS
NFS copies retain permissions but sometimes drop the ownership. User and group ownership may need to be reset.
To mount a remote NFS volume, issue the following command:
mount –t nfs –o rsize=8192,wsize=8192,hard <server:dir> <dir>
With a file dump
This method can be accomplished a number of ways and is particularly useful for older UNIX platforms that have
neither FTP nor NFS functionality. You can:
• Copy the data to an intermediate online or nearline storage device.
• Perform a direct copy facilitated by a workstation capable of connecting to both the source and the target file
systems.
M O V I N G F R O M R E D H A T A P A C H E T O S U S E A P A C H E
FTP or SCP can be used to move the Web server from Apache on Red Hat to Apache on SUSE LINUX Enterprise
Server 9. Make sure you have an FTP or SCP server set up correctly before you begin. If you are moving from an
internal location, use FTP. If you are transferring files across the Internet and need tighter security, use SCP.
Basic instructions for both options are included here.
With SCP
If you are using SCP to transfer files, complete the following:
1. Log in to the Red Hat server as root and stop Apache:
/etc/rc.d/init.d/httpd stop
2. From the SUSE LINUX Enterprise Server 9 machine, copy the documents to be moved to a destination
directory.
cd /srv/www/
scp -rvp * www@Red Hat.IP:/var/www/

25
3. Once the files have been copied, check the permissions and edit httpd.conf so that it replicates the
configuration of the Red Hat machine.
Note: Generally, httpd.conf will need to be rewritten to include appropriate modules [PHP, mod_ssl,
mod_perl], library paths, SUSE-specific directives, appropriate server root directories, virtual hosts and so
forth.
4. Test the Apache configuration on the SUSE LINUX Enterprise Server 9 machine for syntax by entering:
apachectl configtest
Syntax OK should be the response.
5. Start the Apache server on SUSE LINUX Enterprise Server 9 by entering:
/etc/init.d/apache start
6. Tail the /var/log/httpd/error_log to check whether the configuration is correctly implemented.
tail /var/log/httpd/error_log
7. Have someone familiar with the system test it with a compliant browser.
With FTP
Make sure you have an FTP server set up correctly so you can transfer the files from the Red Hat box to the SUSE
LINUX Enterprise Server 9 box. To make the transfer, complete the following:
1. Because you will need root privileges to transfer the files, edit the /etc/pam.d/vsftpd file (on the SUSE
LINUX Enterprise Server 9 machine) to allow root access:
Place a # in front of the line that reads:
auth required pam_listfile.so item=user sense=deny file=/etc/ftpusers
onerr=succeed
2. Stop and restart the service so this change will take affect.
/etc/init.d/xinetd stop
/etc/init.d/xinetd start
You may also need to edit the /etc/vsftpd.conf file to enable passive (PASV) mode:
#pasv_enable=NO to pasv_enable=YES
3. Return to the Red Hat server, log in as root, and go to the /var/www/html directory.
4. Prepare the directory using gzip:
gzip -rc * > apache.gz
Note: The -r gathers all the subdirectories and -c compresses the file to make it easier to transfer.

26
5. Using FTP, connect to the SUSE LINUX Enterprise Server 9 box:
ftp <ip address of SUSE LINUX Enterprise Server 9 box>
6. Log in to SUSE LINUX Enterprise Server 9 as root.
7. At the ftp> prompt, type binary and select Enter.
Note: You may need to switch to PASV mode.
8. Transfer the apache.gz file from the Red Hat box to the SUSE LINUX Enterprise Server 9 box:
put apache.gz /srv/www/htdocs
Note: This may take a while, depending on the size of the file. You will be notified that the file
transferred successfully.
9. Return to the SUSE LINUX Enterprise Server 9 server and CD to /srv/www/htdocs.
Note: If you have anything else in this directory, you may want to remove it to prevent problems.
10. Uncompress the apache.gz file. Once complete, you should be able to view all the files and sub-directories
transferred from the Red Hat box.
Note: You may need to stop and restart the http daemon.
/etc/init.d/apache restart
(restart stops and restarts the service.)
11. Now that the root no longer needs to access the FTP files, return to the SUSE LINUX Enterprise Server 9
box and remove the # from the following line in the /etc/pam.d/vsftpd file (see step 1):
auth required pam_listfile.so item=user sense=deny file=/etc/ftpusers
onerr=succeed
12. Open a Web browser and go to http://localhost on SUSE LINUX Enterprise Server 9 to view your Web sites.
Note: If you are running virtual servers, you will need to transfer the /etc/httpd/httpd.conf file over
from Red Hat to SUSE LINUX Enterprise Server 9 or manually edit the /etc/httpd/httpd.conf file on
the SUSE LINUX Enterprise Server 9 box to add the IP addresses for all the Virtual Machines.
If you are running anything more than a standard Web server (for example, JAVA, PHP and so forth),
additional configuration of the SUSE LINUX Enterprise Server 9 box may be necessary.
M I G R A T I N G E - M A I L S Y S T E M S
Whether you set up e-mail services on SUSE LINUX Enterprise Server 9 or port them from Red Hat depends on
whether you want just e-mail or a complete collaborative environment that includes e-mail, calendaring and
scheduling.
If you need to replicate only the e-mail services currently hosted on Red Hat, you can port Red Hat Sendmail to
SUSE LINUX Enterprise Server 9 Sendmail. Sendmail is included with SUSE LINUX Enterprise Server 9.

27
If you need a collaboration environment, consider Open Exchange or Novell GroupWise 6.5 for Linux.
With SUSE LINUX Enterprise Server 9, the YaST mail server module is installed as part of the LDAP server. If you
decide against the use of an LDAP server, the YaST mail server module will not work because it depends on LDAP
functionality. You will need to set up a mail server via the Mail Transfer Agent (MTA) module. Refer to “LDAP—A
Directory Service” in the SUSE LINUX Enterprise Server 9 Installation and Administration manual for additional
information. See
Configure Sendmail
Sendmail is controlled by a configuration file called sendmail.cf. Because Sendmail has to read this file to find
its configuration every time it is called, the design of the file takes advantage of computer parsing.
Numerous example configuration files are distributed with the Sendmail source; tweaking any one of them will
work for most purposes. File notation, while somewhat overwhelming initially, is actually relatively simple given a
little experience.
Generate the configuration file
The best way to configure Sendmail is to use m4, a macro preprocessor shipped with Sendmail that cuts the
configuration process down to several lines in master configuration files (these files end in .mc). This master file is
then used with m4 to generate a sendmail.cf.
The configuration is generic, except for turning on some features appropriate for your system and tweaking a few
options. In most cases, modifying one of the sample m4 master configuration files will meet your needs. You won't
have to modify sendmail.cf; just create a short .mc file, run it through m4 to create a sendmail.cf and install the
resulting configuration file. Occasionally, complex configurations require additional work.
The following example .mc file can be used in generating the sendmail.cf for a standalone machine:
include(`../m4/cf.m4')
VERSIONID(`$Id: configuration.html,v 1.9 2004/07/24 19:45:27 brier Exp $')
OSTYPE(unknown)
FEATURE(always_add_domain)
define(`UUCP_RELAY', `smtp:uunet.uu.net')
define(`LUSER_RELAY', `smtp:anywhere.com')
MAILER(local)
MAILER(smtp)

28
The m4 macros in the .mc file look like this:
name(arg1, arg2, ..., argn)
If any of the arguments to the macro are strings, they must be surrounded by quotes. However, the
quoting conventions are different than for most other situations. For example:
define(`LUSER_RELAY', `smtp:anywhere.com')
Carefully identify which characters are being used to generate the quotation marks. It's very important to get this
correct.
To generate a sendmail.cf with the above .mc file, simply issue a command similar to the following from the cf/cf
subdirectory of the sendmail distribution:
# m4 iu-standalone.mc >/tmp/sendmail.cf
Install the configuration file
To install the new sendmail.cf, copy the new version into place (always back up the original first) and restart the
Sendmail daemon. Many administrators keep a copy of the cf directory, so they can easily modify .mc files and
regenerate sendmail.cf files as necessary.
Copy users' mail from Red Hat
Once Sendmail is set up, you are ready to copy users' mail.
1. Go to /var/mail on the Red Hat box; each account name will be listed in this directory.
2. Copy users' e-mails to the /var/spool/mail directory on the SUSE LINUX Enterprise Server mail server,
using either SCP or FTP. Since both e-mail servers use text-based messaging, you won't need to convert
documents.
Note: You can create a tool to automate this as a cron job because you are just moving mail from one
server to another.
P O R T I N G A P P L I C A T I O N S
The information in this section is an abstract of the article “Migrating Red Hat Applications to SUSE,” written for
Cool Solutions for Developers by Paul MacKay and Arun Singh, Novell Senior Software Engineers, in June 2004. The
entire article can be accessed at
http://www.novell.com/coolsolutions/cooldev/features/a_red_hat_migration_cdev.html
Although the core components of Linux are the same across distributions, for technical, philosophical and business
reasons, developers need to understand differences in order to migrate an existing application from one Linux
distribution to another (in this case, from Red Hat to SUSE).
An application written and supported on Red Hat will probably run on SUSE if the application follows industry
standards, but there are other areas to understand to fully support SUSE LINUX.

29
The article provides suggestions for the following:
• Writing portable code: Make sure applications you are migrating follow the Linux Standard Base (LSB) and
Filesystem Hierarchy Standard (FHS) specifications. Getting as close to LSB/FHS compliance as possible is a
major step when migrating Red Hat applications to SUSE LINUX. SUSE LINUX is LSB compliant by default.
Note: IBM and others have created an excellent guide that outlines the steps necessary for developing LSB-
compliant applications.
• Packaging applications: RPM is recommended; created by Red Hat, it is considered the standard by most
Linux distributions, including SUSE LINUX. There are many How-To's and tutorials on creating RPMs (see
Resources below). Be sure to also consult the LSB specification, which describes how to create RPMs that will
run and install properly on LSB-compliant systems. Having LSB-compliant RPMs should be a mandatory
requirement for your application.
Note: Red Hat does not pre-install (by default) the required LSB components necessary for LSB-compliant
RPMs. In some instances, you will need to support both Red Hat-specific conventions and LSB specifications.
To create RPMs that will work in this situation, consult the Novell article "Linux Standard Base and Filesystem
Hierarchy Standard Compliance for Novell Products."
• Creating SUSE-friendly source RPMs: Binary RPMs should be created from source RPMs. SUSE provides a utility
called “Build” that streamlines the RPM creation process and ensures configuration and system uniformity.
The Build command installs all of the required packages necessary to compile the given RPM package and
copies all of the source files and patch files as well as the RPM spec file into a build area. Using Build ensures
a reproducible build environment that doesn't get corrupted by the host's environment and vice versa.
• YaST-enabling the application: On SUSE LINUX, YaST is used to install and manage RPMs and administer,
monitor, manage and configure the overall SUSE environment. To create a YaST module, you need the yast2-
devel package and other YaST tools available with the SUSE LINUX Software Development Kit (SDK).
Additional application porting resources
• LSB specification:
http://www.linuxbase.org
• FHS specification:
http://www.pathname.com/fhs
• Tutorial for creating LSB-compliant applications:
http://www-106.ibm.com/developerworks/linux/library/l-lsb.html
• RPM description and use:
http://www.rpm.org
• A three-part series from IBM entitled "Packaging software with RPM":
http://www-106.ibm.com/developerworks/linux/library/l-rpm3.html
462-001409-001

Red_Hat_to_SUSE

Recommended

Recommended

More Related Content

Similar to Red_Hat_to_SUSE

Similar to Red_Hat_to_SUSE (20)

Red_Hat_to_SUSE