Migrating from
UNIX/LINUX to SLES9

Kurt Brust

Global Solutions Group

Novell, Inc.

Paul Rice

Global Solutions Group

Novell, Inc.

Where to start

Edge-of-the-network servers: DNS/DHCP

Web-serving functions: Web servers and firewalls

General services: file, print, and e-mail servers

Application servers

Database servers

Start your migration to Linux in areas that have been successful for others

Why move?

Lower-cost hardware replacements for proprietary server systems

Lower-cost peripheral hardware: SCSIs, modems, and CD-ROM

Lower support and licensing costs

Compelling cost advantages

When to move

Expiring hardware or software support and licensing contracts

Hardware or software refresh cycles

Adding additional server capacity

Typical triggers

Before you start
hardware considerations

Device incompatibilities - SCSIs, graphics, sound, and network cards

Computer model differences – Same make and model shipped with slightly different driver configurations

Device recognition - Multiple SCSI adapters that need the same Linux driver; machine recognizes only one device when it boots

In short, check with the hardware vendor —before you purchase a machine.

Before you start
application considerations

Understand which applications are supported on Linux.

Find alternatives for applications that aren’t.

Make sure you have the proper installation and configuration tools; some packages require an RPM installation; others use the make command.

Lab test applications before rolling them to production.

More and more application vendors are supporting Linux; the list grows daily.

Before you start
environment considerations

Make a backup—disasters happen.

Gather the documentation
(if all else fails...read it).

Note: The SUSE LINUX Enterprise Server 9 Installation and Administration manual can be downloaded from

http://www.novell.com/documentation/sles 9 /index.html

Check port availability.

Install SUSE® LINUX Enterprise Server 9

The installation process is simple and GUI-driven—Next, Next, Finish.

Basic installation steps are similar to those for UNIX.

Hardware is usually auto-detected and drivers loaded.

Boot loader installation is prompted for.

All steps are clearly documented in the left pane.

Check the system

Verify network connectivity

Create a system snapshot

Create boot and rescue diskettes

Make sure applications run as expected

Create a non-root account

Migration overview

Determine which services to migrate.

Identify source and destination directories.

Transfer files using SCP or FTP.

Move all HTML files from /etc/var/docs on UNIX to
/srv/www/htdocs on SLES9.

Manually verify that all necessary files have been copied.

Test the Web site using “spiders.”
See http://www.download.com or http://www.tucows.com/

Test the migrated services for a day or two in a test lab.

Remove the UNIX box from service.

Migrating user accounts

User accounts

/etc/password on UNIX

/etc/passwd on SLES9

Passwords

/etc/shadow on both systems
(but encrypted differently so not convertible)

Conversion Script

Convert user accounts to LDIF format

See http://www.padl.com/OSS/MigrationTools.html

Migrating DNS

Note the UNIX file structure so you can either replicate it or change it to better meet your needs.

Typical UNIX file structure

/var/named/named.ca

/var/named/hosts

/var/named/hosts.rev

/var/named/named.local

/etc/resolv.conf

/etc/dhcp/inittab

Migrating DNS and other networking (edge) services is
straightforward since the two systems are similar.

DNS installation
with BIND

BIND (Berkeley Internet Name Domain) is included with SLES9 and is already configured; it can be started immediately after installation.

BIND settings are stored in /etc/named.conf.

BIND runs as a pure caching-only name server until you configure zones.

Zone data (host names and IP addresses) is stored in separate files in /var/lib/named.

To configure DNS, use YaST.

To start the name server, enter rcnamed start (you must be logged in as root).

If the name server does not start or behaves in an unexpected way, look for the cause in /var/log/messages.

Use rcnamed status to see whether the server is running.

DNS migration
from UNIX DNS to Linux BIND

Use the information in the secondary zone file on UNIX to create the primary zone on SLES9.

Complete a zone transfer by running the rndc command.

Use the secondary zone file on UNIX to create the primary zone file for SLES9.

Change from the secondary to the primary using BIND config or change this in the named.conf file.

1

Scenario one—Create a secondary DNS

2

3

DNS migration
from UNIX DNS to Linux BIND

Create slave entries on the Linux server for each zone in the UNIX named.conf file.

Change the domain name, file path, and master DNS server IP address to those for the Linux system.

This causes named to do a zone transfer of each domain into its respective file.

Change slave to master in named.conf.

Edit each domain configuration file, changing the NS and SOA records to match the new nameserver.

ndc reload and named will now act as the primary DNS server for these zones.

Scenario two—Replace the DNS server

1

2

3

4

DHCP migration

Use the DHCP module in YaST to set up the DHCP server included in SLES9. DHCP configurations can be stored locally or on an LDAP server.

Manually transfer the zones.

Shut down DHCP on Solaris.

Activate DHCP on SLES9 using rcdhcpd start.

1

2

3

4

The DHCP daemon leases addresses according to the settings defined in /etc/dhcpd.conf.

To move from DHCP on UNIX:

DHCP migration

Use rcdhcpd start to copy the configuration files to chroot so the daemon can find them.

Check configuration file syntax using rcdhcpd check-syntax.

Make sure the /etc/dhcpd.conf is located in
/var/lib/dhcp/etc/ so dhcpd can:

Run with the permissions assigned to nobody

Run in a chroot environment (/var/lib/dhcp/)

The corresponding init script copies the file to this directory.

By default, the DHCP daemon is started in a chroot environment.

Moving Apache to Linux

Log in as root and stop Apache on UNIX (apachectl stop).

At the SLES machine, copy documents to a destination directory.

cd /srv/www/

scp -rvp * www@Solaris.IP:/var/www/

Check and edit the permissions to replicate the UNIX configuration.

Test Apache syntax by entering apachectl configtest.

Start Apache on SLES9 (/etc/init.d/apache start).

Tail the /var/log/httpd/error_log to check the configuration.

Test with a compliant browser.

Use either FTP or SCP to move from Apache on UNIX to Apache on SLES9.

Using SCP

1

2

3

4

7

6

5

Moving e-mail systems

Install Sendmail. With SLES9, the YaST mail server module is installed by default.

Configure Sendmail via the Sendmail configuration file, sendmail.cf.

Numerous example configuration files are distributed with the Sendmail source; tweaking any one of them will work for most purposes.

To replicate e-mail services - port UNIX Sendmail to Linux Sendmail.

To create a collaboration environment (e-mail, calendaring, and scheduling) - consider Evolution, Open Exchange, or Novell GroupWise® 6.5 for Linux.

Porting Sendmail

1

2

Moving e-mail systems

Using m4, a macro preprocessor shipped with Sendmail, create a master configuration file (.mc).

Use the master file with m4 to generate a sendmail.cf.

Use one of the sample m4 master configuration files to tweak features appropriate for your system.

Install the new Sendmail.cf on SLES9 by copying the new version into place and restarting the Sendmail daemon.

Use FTP or SCP to copy users' e-mails from /var/mail on UNIX to /var/spool/mail on the SLES9 mail server.

Both e-mail servers use text-based messaging; you won’t need to convert documents.

4

5

3

Moving file systems

Position the two servers sharing the transfer close together (on the same subnet and on the same physical network switch).

Make sure the UNIX server holding the data has a configured FTP server.

Transfer files from UNIX to SLES9 using:

FTP or SCP

NFS

File copies through an intermediate device

With FTP

Two FTP clients (ncftp and wget) are included with SLES9.

1

2

Moving file systems

Make sure file and directory permissions for incoming data have been determined on SLES9.

Start FTP on the UNIX server. The FTP service can be configured to run from the super daemon inetd or xinetd.

Log in to the UNIX server using the FTP client on SLES9.

Navigate to the data to be transferred.

Make sure the FTP client is prepared to place the incoming data in the correct directory (at the command line, use lcd; with the GUI, navigate graphically to the correct location).

Begin the transfer.

For large amounts of data, the transfer may take a while.

6

7

8

5

4

3

Linux printing

CUPS – adequate for small to medium printing environments

iPrint – best choice for enterprise printing environments

Differences between CUPS and iPrint printing

iPrint

The client does the print filtering (converting data to printer format).

The server handles only spooling; thus a single server can accommodate more printers.

CUPS (default scenario)

The server handles both data filtering and spooling.

A client isn’t required.

Printing options

Setting up CUPS printing

Connect the printer to the network and install the printer software.

Select the Default or Full installation options during SLES9 installation to install CUPS.

Most CUPS print options are activated by default.

Install CUPS

1

2

Configuring CUPS

Identify the printer’s TCP/IP address and queue name, make and model.

Make sure necessary PostScript Printer Description (PPD) files are located in /usr/share/cups/mode.

Log in as root.

Select Start Applications > System > YaST > Hardware > Printer.

Create or modify the printer configuration by following the on-screen prompts.

1

2

4

5

Configure CUPS using YaST

3

CUPS configuration screen

Migrating database services

Proprietary databases. Consider Oracle, DB2, Sybase, and Informix. (Most vendors that support UNIX database servers also support Linux.)

Open source databases. Consider MySQL, PostgreSQL, Ingress r3.

Tools. Most vendors supply tools for migrating between platforms.

Consolidation. Consider:

Upgrading to the next version of the database

Consolidating on a single database vendor environment

Implementing advanced redundancy features

Migrating databases

Assess migration scope by accounting for current database instances, platforms and versions, size, connectivity and peak workload.

Inventory servers to identify opportunities to reduce the number of database instances and decommission end-of-life equipment.

An excellent source for real-life scenarios representing all major databases is http://www.dbforums.com/.

See also

http://www5.experts-exchange.com/Databases/

http://shearer.org/en/writing/replacemicrosoft/replace-windows2000-howto.html

2

1

Need training?

Linux certification

LPI level 1 or LPI level 2

SUSE LINUX training and certification

Novell Certified Linux Professional (Novell CLP)

Course 3036: Linux Fundamentals

Course 3037: Linux Administration

Course 3038: Advanced Linux Administration

Course 301: Migrating to SUSE LINUX (for experienced Linux administrators)

Novell Practicum

Novell Certified Linux Engineer (Novell CLE)

Course 3017: Fundamentals of Novell eDirectory

Course 3015: Novell Nterprise Linux Services

Novell Practicum

Novell Training Services

Need help with your move?

Strategy and Discovery - Define both current and future Linux strategies

Requirements Assessment - Discover your readiness (or not) for moving to Linux

Planning and Design – Define in detail how to orchestrate your migration

Migration – Implement your migration plans in pilot, test, and production environments

See http://www.novell.com/linux/migrate for details.

Novell Professional Services

If your organization is investigating whether to deploy Linux and open source solutions—either now or in the future—you already know how much there is to consider. Decisions range from tactical deployments in edge-of the- network or Web-serving functions to general infrastructure (like file and print) to enterprise use for application serving. Initially, you may be looking for advice or contemplating a limited proof-of-concept installation, or perhaps you've already made your business decision and are ready for an across-the-board deployment with Linux as the preferred platform.

At whatever point you are along the Linux migration path, you've probably read the hype—the claims and counterclaims— about whether Linux is or isn't ready for the enterprise in the data center or on the desktop. And frankly, the claims probably depend on which Linux migration paper you read most recently and who funded the research.

Not all hardware drivers—particularly SCSI adapters and drivers for graphics, sound, video and network cards— are Linux-compatible.

Sometimes the same computer make and model is shipped with a slightly different driver configuration, and these differences can take their toll.

Having multiple SCSI adapters of the same make that need the same Linux driver can also cause problems because the machine recognizes only one device when it boots.

Although several large companies produce drivers specifically for Linux, many vendors leave this to the Linux community. Because the hardware market changes rapidly—almost daily—you'll want to monitor the market closely. Before you purchase 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.

In addition, make sure you follow at least the minimum hardware guidelines (including processors, RAM and disk space) for the distribution you are using. Generally speaking, you will need a less robust processor on Linux than on UNIX; 1Ghz on a Solaris box is equal to approximately 750 Mhz on an Intel box because of the additional overhead imposed by the way UNIX code is handled.

One of the inhibitors to an across-the-board move to Linux has been the lack of Linux-friendly applications. This situation improves almost daily, but check with the application vendor before you proceed.

Make sure you have a backup

Make sure you have a backup to a tape or another hard drive. Disasters can happen—even with Linux.

Gather the documentation (if all else fails...read it)

Man pages - System calls, libraries, and system configuration files are documented in manual pages as they are with UNIX.

HOWTO and README files and GUI-based help programs are available.

Source code documentation - Many rpm packages install the source code documentation under /usr/share/doc.

Admin guides - the SUSE LINUX Enterprise Server 9 Installation and Administration manual can be downloaded from

http://www.novell.com/documentation/sles 9 /index.htm l

Check port availability

UNIX services require different ports than comparable services on Linux.

You may want to customize the port environment for security or other reasons.

To find out which ports are in use, access /etc/services on the Linux machine.

The installation process for SUSE LINUX Enterprise Server 9 is simple and GUI-driven; the basic steps are similar to those for a UNIX Operating Environment installation:

• Select the directory location for installation files

• Choose the geographical locale

• Select the software packages to install

• Set the configuration for the 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 the boot loader installation: LInux LOader (LILO) or GRand Unified Bootloader (GRUB).

Explanations for all steps are clearly documented in the left pane of the SUSE LINUX Enterprise Server 9

installation screens; the complete SUSE LINUX Enterprise Server 9 Installation and Administration manual isdownloadable from

http://www.novell.com/documentation/sles9/index.dex.htm

Make sure your server is operating as expected and that you have a way to recover if necessary.

• 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 source system so you have a way to recover if necessary.

• Create diskettes. You'll want both boot and rescue diskettes. Test both to make sure you can use them to boot from Linux.

• Check applications. 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 you won't inadvertently compromise your system.

B E G I N N I N G T H E M IGRAT ION

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.

10

• Decide which source directories you are moving files from and which destination directories you are moving them to.

• Move the the designated files from Solaris to SUSE LINUX Enterprise Server 9 via secure copy protocol (SCP) or file transfer protocol (FTP); both FTP and SCP are included with SUSE LINUX Enterprise Server 9. Use FTP if you are transferring files internally or SCP if you are transferring files over the Internet.

• You will be moving all HTML files from the /etc./var/docs directory on Solaris to /srv/www/htdocs on SUSE LINUX Enterprise Server 9.

• Manually verify that all necessary files have been copied. If there were 640 files in one directory on Solaris, make sure 640 have been copied to SUSE LINUX Enterprise Server 9.

• Test the Web site if you are moving your Web site from Solaris. 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 pilot lab before cutting them over to production. If you will be running both the original Solaris 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 services are running side-by-side.

• When you have verified that all services are working correctly, remove Solaris from service.

Moving user accounts is not always straightforward. You can use products such as Novell Account Management (NAM ) 3.0, Pluggable Authentication Modules (PAM), LDAP redirection or PADL (PADL is recommended only for experts) to make moving accounts (identities) easier, but not foolproof.

Rather than managing individual accounts on each server, consider porting users to an enterprise directory (such as eDirectory) during the migration to centralize authentication and administration and to increase security.

User account locations

• UNIX /etc/password; SLES9 /etc/passwd. Both include user name, password placeholder (for /etc/shadow), UID, GID, description, home directory location and default shell.

• Passwords are stored in /etc/shadow on both systems but are encrypted differently (UNIX uses a different algorithm) so they are not convertible.

Conversion tools

Tools are available to convert the accounts in /etc/passwd directory to LDIF format so they can be imported to an LDAP directory SLES0. 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 at this site.

Migrating networking (edge) services is fairly straightforward because of the similarities in the two systems.

DNS

Take inventory of the current file structure on UNIX so you can either replicate it on SLES9 or change it to better meet your needs.

Typical UNIX file structure:

/var/named/named.ca—contains information about the root name servers

/var/named/hosts—contains the local server name and the IP address which may or may not be part of the 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—reverses the domain name to the IP address

/etc/dhcp/inittab—stores initial information before you perform the implementation

Migrate DNS

You can manually migrate from UNIX DNS to Linux (BIND) using one of two options:

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 BIND config or change this in the named.conf file.

Option two—Replace the DNS server: If you are replacing the UNIX DNS server completely, use these instructions:

1. Create slave entries on the Linux server for each of the zones in your Solaris named.conf file as in the following example:

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 Linux 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 configuration files, changing the NS and SOA records to match the new

nameserver.

ndc reload and named will now act as the primary DNS server for these zones.

The DHCP server can also be set up at the command line:

1. Install DHCP on the SLES9 machine (if not already installed) from the rpm package: # rpm -ihv dhcp-*.rpm

2. Edit the /etc/dhcpd.conf file on SLES9 to modify the variables for your specific environment: At the Solaris box

a. Check the /var/named/dhcptab file and note the IP zone range

b. Check the subnet

At the SUSE LINUX Enterprise Server 9 box,

c. Add the correct IP subnet to the subnet x.x.x.x

d. Add this range to the – range dynamuc-bootp x.x.x.x x.x.x.x

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;

3. Start the DHCP server on SLES9 by entering:/etc/init.d/dhcpd start

4. Stop the Solaris DHCP server:

a. Choose the Services menu > Start, Stop or Restart.

b. Click Stop to stop the DHCP or BOOTP daemon.

Note: If you plan to leave the UNIX DHCP server on the network, unconfigure DHCP so it won't be activated inadvertently or repurposed without removing DHCP:

Type /usr/sbin/dhcpconfig and choose Yes

Use rcdhcpd check-syntax to check the syntax of the configuration file. If you encounter problems, check the information in the main system log, /var/log/messages, to identify the reason.

On a default SLES9 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 DHCP server comes with the nonroot/chroot patch applied. This enables dhcpd to:

• Run with the permissions assigned to nobody (VSFTPD uses the Linux/UNIX nobody user as a part of the default configuration.

• 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 /etc/sysconfig/dhcpd configuration file. To continue running dhcpd without the chroot environment, set the variable DHCPD_RUN_-CHROOTED in /etc/sysconfig/dhcpd to no.

Using FTP

1.Edit the /etc/pam.d/vsftpd file on SLES 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

You may also need to edit the /etc/vsftpd.conf file to enable PASV mode: #pasv_enable=NO to pasv_enable=YES

2. Stop and restart the service so any changes will take effect.

/etc/init.d/xinetd stop

/etc/init.d/xinetd start

3.At the Solaris server, log in as root, and go to the /var/apache/htdocs directory.

4. Prepare the directory using GZIP: gzip -rc * > apache.gz

5. Use FTP to access the SLES9 box: ftp <ip address of linux box> and log in as root.

7. At the ftp> prompt, type binary and select Enter.

Note: You may need to switch to PASV mode by typing quote PASV.

8. Transfer the apache.gz file from Solaris to SLES9: put apache.gz /srv/www/htdocs

9. From SLES9, CD to /srv/www/htdocs.

10. Uncompress the apache.gz file and, If necessary, stop and restart the http daemon: /etc/init.d/apache restart

11. At SLES9, access the /etc/pam.d/vsftpd file and remove the # entered in step 1.

12. Open a Web browser and access this location on the server: http://localhost

Note: For virtual servers, you need to either transfer /etc/httpd/httpd.conf from UNIX (as long as the releases are the same) or manually edit /etc/httpd/httpd.conf on SLES9 to add the IP addresses for the virtual machines. If you are running anything more than a standard Web server (such as JAVA or PHP), additional configuration of SLES9 may be necessary.

Sample .mc file to generate a 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)

29

define(`UUCP_RELAY', `smtp:uunet.uu.net')

define(`LUSER_RELAY', `smtp:anywhere.com')

MAILER(local)

MAILER(smtp)

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 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

With NFS

NFS transfers retain permissions but sometimes drop file 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 is particularly useful for older UNIX platforms that have neither FTP nor NFS functionality and can be accomplished a number of ways.

Decide whether to make an intermediate copy of the data on an online or nearline storage device or to perform a direct copy facilitated by a workstation capable of connecting to both the source and the target file systems.

With CUPS, the conversion into the printer-specific format (the filtering) of all data to be printed takes place by default directly on the server . The advantage is that a print client is not necessary; the disadvantage is that the filtering process devours too many resources when a single server must support hundreds of printers.

With iPrint, the filtering takes place on the client system (reduces the load on the server), but this requires the installation of printer drivers on the client.

iPrint is only available with the OES version of SLES9.

iPrint and CUPS can’t both run on the same print server as both use the same port (if iPrint is selected during installation, CUPS is disabled).

iPrint requires eDirectory. CUPS doesn’t.

Install CUPS

Once the printer is connected to the network and the printer software installed, the printer needs to be installed on the SLES9 operating system. Novell recommends using either the command line or the YaST tools delivered with SLES9 since third-party tools often have difficulties with SLES9 security restrictions and often results in more problems than benefits.

CUPS is installed with SLES9 as long as you select the Default or Full installation options—it's not installed with the “minimal” options.

Install CUPS

Once the printer is connected to the network and the printer software installed, the printer needs to be installed on the SLES9 operating system. Novell recommends using either the command line or the YaST tools delivered with SLES9 since third-party tools often have difficulties with SLES9 security restrictions; using them often results in more problems than benefits.

CUPS is installed with SLES9 as long as you select the Default or Full installation options—it's not installed with the “minimal” options. If a version of CUPS has been installed on your system previous to the SLES9 installation, chose the Upgrade rather than the Update option.

Oracle - For large global enterprises that have enormous amounts of tables and data on multiple international sites or that emphasize grid computing, Oracle is a proven solution and the current database market leader.

DB2 - For organizations who use other IBM solutions (such as Websphere Studio for Web Services), DB2 is a logical solution as it integrates well.

Ingres r3 - For organizations that have a distributed system spread out among dozens of servers, Computer Associates* Ingres r3 is a good choice as its replication abilities are optimal and proven.

PostgreSQL - For organizations that need a flexible, standards-compliant database with a complex set of stored procedures and triggers, PostgreSQL is a good choice. Touted as the most advanced open source database server.

MySQL - For organizations that need a small Web application database or large data warehousing, the current version of the open source MySQL database (4.1) is heralded for its speed and simplicity and is a great choice. Reports indicate that MySQL 5.0 (to be released in Q2 2005) will be “enterprise-ready” and able to meet or exceed all the advantages of the aforementioned databases. MySQL is the current leader among open source databases.

UNIX to SLES

2003-12-08T12:43:39