Novell Open Enterprise Server 2 Best Practices Migration Guide - Migrating Background Infrastructure Services

From MicroFocusInternationalWiki
Revision as of 17:19, 12 January 2008 by Coolguys (Talk | contribs)

Jump to: navigation, search

< Novell Open Enterprise Server 2 Best Practices Migration Guide

Migrating Background Infrastructure Services

Some of the information in this section has been compiled from early-adopter consulting engagements. We thank our customers and our experts, particularly Michael Saunders, Gilson Melo, Jim Short, and Tom Veite for their contributions to this section.

In addition to the information found here, we recommend referring to the OES 2 Migration Tools Administration Guide as well as migration information specific to each service (generally included in the Administration Guide for the service). Links to the migration sections of each service guide are provided in Section 1.3, "Other Migration Tools, in the [OES 2 Migration Tools Administration Guide].

In addition to the information found here, we recommend referring to the [OES 2 Migration Tools Administration Guide] as well as migration information specific to each service (generally included in the Administration Guide for the service). Links to the migration sections of each service guide are provided in Section 1.3 of the [OES 2 Migration Tools Administration Guide.

When you migrate services from NetWare to OES 2 Linux, some services have to be rebuilt on Linux and data (where it exists) migrated. Other services can be easily implemented and include a migration tool specific to the service; for example, you use migedir to move eDirectory from NetWare to Linux. For many services, both command line and GUI migration tools are available; however, OES 2 Linux must first be installed to access the GUI tools which are then available via YaST under the Migration and Open Enterprise Server categories. Each of the sections below includes cross-references to additional migration information specific to that service.

Services not included in this section. A synopsis of service-specific migration information, including services not discussed in this section, can be found in the "OES 2 Migration Utilities Best Practices Guide" which can be accessed from the [NetWare to Linux Migration Sources] on the Novell Open Enterprise Server Migration Web site. The following services are included:

  • Data Migration
  • eDirectory
  • iPrint
  • Novell Archive & Versioning Services
  • Distributed File Services (DFS)
  • NetStorage
  • Novell Cluster Services (NCS)
  • Novell Remote Manager (NRM)
  • Novell Storage Services (NSS)
  • Novell Backup/Storage Management Services (SMS)
  • NetWare Core Protocol (NCP)
  • Novell FTP
  • Novell iManager
  • Novell QuickFinder

Novell Cluster Services

Review the Current Cluster

Typically, the primary purpose of a cluster is providing file and print services. Make sure you check the volume resources since it is easy to overload these services. As a general guideline, Novell recommends that NSS volume resources be kept at a total capacity of 80% or less. If you need to reduce the number of standalone servers in production, the logical approach is to migrate data and services into the high availability resources of a cluster.

  • Review the health of NCS background operations to resolve any operational issues with the cluster.
  • Make sure all cluster nodes are up to the latest support pack levels.
  • Avoid spanning LUNs across NSS pools
  • Review and modify, where necessary, the cluster design to take full advantage of the High Availability capabilities of current release software.

Novell recommends the following steps to address both the reliability and the performance of your current cluster:

  • Make sure all NetWare nodes are at NetWare 6.5 SP6
  • Use relatively small LUNs and data volumes
  • Introduce OES 2 Linux nodes as required
  • Reconfigure the SAN to host DST shadow volumes

Migration to OES 2 Linux

There are a couple of possible migration paths for moving existing NetWare clusters to Linux: converting the existing clusters (also referred to as a rolling cluster conversion) or using a parallel build.

  • Cluster Conversion (Same Cluster). In order to convert existing clusters, new OES 2 Linux servers need to be built with the same LUN visibility as the existing NetWare nodes and the new servers added to the existing cluster. The new Linux nodes would then mount the existing volumes and services and then the NetWare servers could be removed from the cluster and removed from eDirectory. While it is feasible to use a mixed NetWare and Linux cluster temporarily as a migration strategy, Novell does not recommend it as a permanent production implementation.

Important. The NetWare 6.5 SP1 kernel includes several patches and updates. If you will be using a mixed NetWare and Linux cluster to facilitate a migration to OES 2 Linux based clusters, then upgrade the NetWare cluster servers to NetWare 6.5 SP1 before Linux is introduced. All standalone servers can remain NetWare 6.5 SP5 as OES 2 Linux is introduced into the environment.

  • Parallel Build (New Cluster). A parallel-build Linux migration strategy would entail building a new separate OES 2 Linux cluster on the same SAN as the existing NetWare-based clusters. Doing so allows resources to be moved to the new cluster by changing LUN visibility from the old cluster nodes to the new. This can also be done in a phased approach. After the last resource is moved, the NetWare cluster can be removed from the tree. Since it is a new cluster, the virtual server names would change and login scripts and other references would need to be updated during the migration process.

There are pros and cons to each approach so you'll need to do a more detailed analysis and/or secure assistance from Novell Consulting before deciding on or implementing a cluster migration.

Novell Cluster Services software must be running on the Linux server (SLES 10 and OES 2 must be installed on every server you want to add to a cluster). You can install Novell Cluster Services and create a new cluster, or add a server to an existing cluster either during the SLES 10/OES installation or afterwards, using YaST.

See Section 3.5.2, "Installing Novell Cluster Services during the OES Installation" and Section 3.5.3, "Installing Novell Cluster Services after the OES Installation" in the [OES 2: Novell Cluster Services 1.8.4 for Linux Administration Guide].

Additional Information

Refer to the following sections in the [OES 2: Novell Cluster Services 1.8.4 for Linux Administration Guide] for additional information about migrating Novell Cluster Services:

  • Section 3.6, "Converting a NetWare Cluster to Linux"
  • Section 3.7, "Upgrading an OES 1 Linux Cluster to OES 2"
  • Section 4.1, "Migrating Resources"

A synopsis of the process for migrating clusters can be found in the "OES 2 Migration Utilities Best Practices Guide" which can be accessed from the [NetWare to Linux Migration Sources] on the Novell Open Enterprise Server Migration Web site.

An additional resource is a document created in conjunction with Dell: ["Managing Live Migrations from Novell NetWare to SUSE Linux Enterprise Server."] This document references OES1, but should apply equally to OES 2. It is currently being updated for OES 2.

GroupWise Collaboration Services

Installing or Upgrading GroupWise on OES 2

Instructions for installing GroupWise 7 SP2 on OES 2 Linux are included in the [GroupWise 7 Support Pack 2 Readme]. Use the instructions in the Readme in conjunction with those in the [GroupWise 7 Installation Guide].

The following should be noted:

  • When you use the Linux GroupWise Installation program to install a Support Pack, use the Install option to install the updated RPM for each agent. If you encounter a problem starting the agent, use the Configure option to update the configuration information.
  • When you upgrade a server where GroupWise WebAccess is installed, new versions of Apache and Tomcat are installed. Therefore, you must reinstall and reconfigure the WebAccess Application. A script is available to help you with the reconfiguration process (see the Readme). You don't need to reinstall the WebAccess Agent.
  • When you upgrade from Open Enterprise Server (OES) 1 to OES 2 or from SUSE Linux Enterprise Server (SLES) 9 to SLES 10 with GroupWise installed on your SLES server, you may encounter package conflicts that must be resolved. Instructions for handling this situation are included in the Readme.
  • Section 5.3 in the Readme documents Linux installation issues. Other sections of the Readme are also pertinent and should be reviewed before installing SP2.

Minimum System Requirements

  • 32-bit/x86 processor or 64-bit/x86 processor running in 32-bit mode
  • Any of the following server operating systems, plus the latest support pack:
    • Novell Open Enterprise Server (NetWare or Linux version)
    • NetWare 5.1, NetWare 6.0, or NetWare 6.5
    • SUSE® Linux Enterprise Server 9
    • SUSE® Linux Enterprise Server 10
  • Windows 2000 Server or Windows 2003 Server
  • eDirectory® 8.7 or later
  • Novell GroupWise ships with the eDirectory version required to run it. You do not need to purchase eDirectory separately, unless you need it for other reasons.
  • ConsoleOne® 1.3.6 or later
  • ConsoleOne on Linux requires Java Virtual Machine (JVM) 1.4.2, plus The X Window System, version X11R6 or later.
  • Windows 2000/XP/2003 and the Novell Client on any administrator machine where you run ConsoleOne or the GroupWise Installation program

For SP2, the following additional environments are supported:

  • XEN virtualization on SUSE® Linux Enterprise Server (SLES) 10
  • Heartbeat 2.0 clustering on SLES 10
  • Novell Cluster Services on Open Enterprise Server 2
  • Microsoft* Windows* 2003 R2
  • Microsoft Vista for the GroupWise Windows client

Migrating NetWare GroupWise to OES 2

There are two methods for migrating NetWare GroupWise to OES 2 Linux: manual or automated:

  • Manual. Instructions for manually moving existing GroupWise 7 users, post offices, and domains from NetWare or Windows to Linux are included in the GroupWise 7 Installation Guide. See Sections 18 - 24.
  • Automated. The GroupWise Server Migration Utility can be used to transfer GroupWise agents, domains, post offices and data from a NetWare or Windows* server to a Linux server. These tasks can also be performed manually.

Available as a free download from the Novell Downloads Web site, the GroupWise Server Migration Utility (gwsvrmig100.exe) is currently supported on GroupWise 6.5 or later. It migrates the GroupWise system to servers running SUSE Linux Enterprise Server 9 or 10 or Novell Open Enterprise Server 1 with the latest support packs. Novell is in the process of certifying GroupWise 7 on Open Enterprise Server 2 Linux and recommending changes for the NetWare to OES 2 Linux migration.

The GroupWise Server Migration Utility allows you to identify the relevant components (Post Office agents, Message Transfer agents, Monitor agent and so forth) to be migrated from NetWare or Windows servers to a Linux server. The utility then installs necessary software, configures the agents and migrates the data—all in real time. The process is flexible, allowing you to choose which components to migrate and when.

During the initial transfer, the software, settings and agents on the original server are maintained, ensuring consistent uptime and enabling you to continue running GroupWise on the original server. After the initial transfer is complete, the GroupWise Server Migration Utility guides you through a process of testing the system running on the new Linux server. As a final step, the utility migrates any data that was altered since the initial transfer and activates the GroupWise services on the Linux server. This is the only point in the process when post office agents will need to be taken down.

For migration instructions, refer to the [GroupWise Server Migration Utility Installation and Migration Guide].

Note the following:

  • NetWare version update. Update the NetWare GroupWise system to GroupWise 7 before migrating it to OES 2 Linux.
  • Linux version update. If you are updating your version of Linux as well as updating GroupWise, perform the Linux operating system upgrade first.


The GroupWise issues listed in this section are concerns identified by customers in their implementations. Some were most probably one-offs and related to the environment and will likely not occur in your environment. Many have already been addressed by GroupWise engineering. When they do occur, we recommend the [GroupWise 7 Support Pack 2 Readme] as the primary resource for information and/or suggested work-arounds.

  • Migrating vs installing GWIA and WebAccess. Novell Support recommends deleting the NetWare-based GWIA and WebAccess objects and then installing new GWIA and WebAccess services on Linux, even though there are instructions for migrating the GWIA and WebAccess services from NetWare to Linux in the documentation.
  • GWCHECK not supported on OES 2 Linux. GWCHECK does not work on OES 2 and won't anytime soon (Java issue). The suggested workaround is to run gwcheck with the storelowercase option from another platform against the migrated database on OES 2. This recommended procedure is currently (October 2007) being added to the migration section of the GW7SP2 Installation Guide.
  • Locating expath.cfg. There is some indication that the GWIA admin can't locate expath.cfg when installing GWIA on an NCS-clustered 64-bit OES 2 Linux (XEN) with NSS storage. Testing is currently in progress to discover whether this is an issue or a factor of the customer environment.
  • Post-migration domain database corruption. Corruption in the post-migration domain databases was experienced at one site; this is being analyzed to see if there is an issue with the migration procedure or if there is corruption in the customer's current production domain databases. Do make sure there are no issues with the pre-migration database before beginning the migration.
  • ConsoleOne script. You need to edit the ConsoleOne script (as referenced in TID 3805759) to add "C1_JRE_HOME=/usr/lib/jvm/jre" after "export LD_LIBRARY_PATH."
  • File Locking issues with NSS. Because of long-standing file lock issues with NFS*, you cannot use an NFS mount to mount a server file system where your GroupWise system is located to a workstation where you are running ConsoleOne. Novell recommends using an SMB mount instead.
  • Accessing GroupWise from ConsoleOne. Some customers have had problems accessing a GroupWise / OES server from ConsoleOne after migration to OES. Refer to the following Cool Solution tip and the proposed solution if you experience this problem.

"Accessing a GroupWise / OES Server from ConsoleOne after OES Migration" []

Additional Information

The readme discusses some of the issues and recommendations for installation on OES 2 Linux and upgrading from OES 1 Linux to OES 2 Linux, but does not specifically address migrating from NetWare to OES 2 Linux.

  • Product Flyer

[Automate Migrations to Linux* with the GroupWise® Server Migration Utility]

  • Novell GroupWise Web site

Access []

  • Additional GroupWise articles

Access []

Service Location Protocol (SLP)


One of the key roles of a server on an IP-only network is to provide network services. To use a service, an application must be able to find the location of the service on the network. Without an advertisement or discovery mechanism, users have to know the IP address or DNS name of the server hosting the tree in order to log in and use network services. With SLP, however, services can register their availability with an SLP agent when they are brought up. The agent keeps track of which services are available and where they are located.

Four components are included with SLP:

  • Service Agent (SA) - works on behalf of the services running on its server. When the server starts up, the services on that server register themselves with the server's SA. The SA maintains a local database of its service URLs. An SA replies to UAs who request services and can register its services with DAs.
  • User Agent (UA) - works on behalf of an application to retrieve service URLs and attributes of network services, understands the service and resource needs of the application and retrieves that server information from an SA or a DA.
  • Directory Agent (DA) - acts as a centralized repository for service location information, receiving registration requests from SAs and then use the service information to answer requests from UAs.
  • Scope - a defined group of network services that groups users or services into manageable entities. A Scope is supported by UAs, SAs, and DAs.

SLP can be configured in a variety of ways. Key factors are the size of the network and how geographically dispersed the network is:

  • Implement UAs and SAs only. The network is automatically configured in this manner when you install the first eDirectory server; it's sufficient for networks with fewer than 25 servers and 1,000 clients but requires more network bandwidth than configurations that employ a DA. With small networks, the multicast traffic usually remains within acceptable limits. Another disadvantage is that administrators must configure network routers to forward multicast packets. If the network uses routers, users may only be able to locate services located on the same network segment as the one their workstation resides on.
  • Implement UAs, SAs, and DAs. The use of a DA eliminates all UA multicasts and SA responses to those multicasts. This option is recommended for larger networks and for networks with routers that don't support multicasting.

If your network has multiple sites separated by WAN links, Novell recommends using multiple DAs. If users need to access remote services, configure UAs with the addresses of both (local and remote) DAs. SLP does not define a protocol for synchronizing service information between DAs.

  • Implement Scopes. If all services in a large network are registered with a single DA and, therefore, a single service cache, the amount of service information can become unwieldy and difficult to manage and response times suffer. Novell recommends grouping services (based on geography, department, or shared services) into scopes and then assigning one or more DAs to service the scopes. This speeds up access to requested services while reducing network traffic.

Note: The Novell version of SLP takes certain liberties with the SLP standard in order to provide a more robust service advertising environment, but it does so at the expense of some scalability. For a discussion of SLP and OpenSLP and references to documents essential to understanding the protocol, refer to Appendix C, "Service Location Protocol" in the [Novell eDirectory 8.8 Installation Guide].

Configure SLP on Linux

NetWare and OES 2 Linux include separate but compatible SLP solutions: SLP and OpenSLP respectively. Which solution you use largely depends on which platform you use for the eDirectory Tree.

NetWare Tree. If you have a NetWare tree, you automatically have Novell SLP on your network and you can continue to use it as the SLP service for both NetWare and Linux OES 2 platforms. If you decide to use OpenSLP, NetWare servers can also be configured to use OpenSLP. On NetWare, SLP services are integrated with and configured to work with eDirectory and other services automatically; if eDirectory is configured correctly, the services will work without SLP.

Linux Tree. Two scenarios are possible:

  • SLP. Novell provides a basic level of SLP support when eDirectory is installed on a Linux server. Linux servers are configured with an SA that registers SLP-aware applications (such as eDirectory) with the server. UA and SA services are provided by the slpuasa daemon (the slpuasa init script is located in /etc/init.d). DAs are not supported on Linux.
  • Open SLP. Novell recommends using OpenSLP instead. OpenSLP is the default SLP service installed on SLES 10. The default discovery mechanism is actually DNS, but SLP must be present for any applications that require it, especially in those cases where the OES 2 Linux server is the fourth or later server added to a tree and doesn’t have an eDirectory replica automatically installed. OpenSLP needs to be installed on servers prior to installing eDirectory. (The eDirectory installation routine detects OpenSLP and does not install the slpuasa daemon.) OpenSLP is capable of operating within most existing configurations.

Important: Novell recommends setting up SLP (or OpenSLP) services on every OES 2 Linux server, particularly before you set up the fourth OES 2 Linux or any NetWare servers in your tree.

You'll need to set up OpenSLP on your OES 2 Linux server if both of the following apply:

  • You plan to install more than three servers into a new tree being created on an OES 2 Linux server.
  • You either don’t have an existing Novell SLP service, or you don’t want to continue using Novell SLP.

On OES 2 Linux, the OpenSLP service must be manually configured to work with eDirectory and other services. The server must either:

  • Have an eDirectory replica installed.

This is not automatic after the third server installed in a tree, nor is having more than three to five replicas on servers in the tree recommended.

  • Have eDirectory registered with the OpenSLP service running on the server.

This requires configuring SLP either during the OES 2 Linux installation or manually.

If you need OpenSLP and you don’t already have an OpenSLP Directory Agent (DA) set up on your network, we recommend setting up the first OES 2 Linux server in your tree as an OpenSLP DA. Although SLP services can be managed without having a Directory Agent, that approach is far less robust, requires multicasting, and for OES 2 Linux involves disabling the firewall.

After creating the DA, you can then configure all subsequently installed servers to either point to that DA or to other DAs you create later.

Although SLP provides a default scope if no scope is specified, it is always good practice to define one or more by configuring the net.slp.useScopes line in slp.conf.

To configure SLP on Linux, you will need to enable multicasting and configure OpenSLP.

Enable Multicasting

SLP relies on multicasting; however, most Linux systems are not configured, by default, to provide multicast support. Enter the following at the shell prompt to determine whether multicasting is supported:

     route -n

If multicasting is supported, you'll see an entry in the routing table for the destination.

If not,

  1. Open a terminal session.
  2. Change to the root user account.
  3. At the shell prompt, enter the following command:
    route add -net netmask dev interface
    (eth0 is usually the interface parameter)
  4. Verify that the route has been added by entering route -n at the shell prompt.

Install and Configure OpenSLP

Open SLP is available as an RPM and provides UA, SA. and DA functionality. You can download a copy from, It is also included with SLES 10 SP1.

OpenSLP installs like any other RPM using the rpm -i command. The slpd daemon is installed in the /usr/sbin directory on the server.

Once installed, you can configure the slpd daemon by editing the /etc/slp.conf file.

  • To configure the daemon to run every time the server is booted using the following command:
chkconfig slpd 345
  • To configure an OES 2 Linux server as a DA, edit the "Static Scope and DA Configuration" portion of the file.
  • To run the daemon, enter slpd at the shell prompt.

For additional OpenSLP set up instructions, see Section 5.2.3, '"Setting Up OpenSLP on OES 2 Networks" in the [OES 2: Planning and Implementation Guide].


  • DA synchronization is not part of OpenSLP.
  • OpenSLP-based user agents or service agents can access Novell SLP-based directory agents when configured to do so. However, directory agent types must be either one type or the other. The SLP daemon (slpd) cannot access both Novell SLP and OpenSLP DAs from the same configuration.

Additional Information

[Novell eDirectory 8.8 Administration Guide]

  • Section 15.8, "Setting Up SLP on Linux or Solaris"
  • Appendix C, "Configuring OpenSLP for eDirectory"

[Novell eDirectory 8.8 Installation Guide], Appendix C, "SLP"

[OES 2: Planning and Implementation Guide]

  • Section 5.2.3, '"Setting Up OpenSLP on OES 2 Networks"
  • Section 12.5, "SLP"


With OES 2, DNS and DHCP have been integrated with eDirectory. This means you can transition your existing DNS and DHCP infrastructure from NetWare to Linux, as well as centrally administer them the same way you do on NetWare. To accomplish eDirectory integration on the DNS side, Novell did a full port of NetWare DNS to Linux to make it functionally equivalent to DNS in NetWare 6.5. Novell plans in the future to fully integrate all of the required functionality into the Open Source “BIND” project.

A direct migration of DNS/DHCP from NetWare to Linux is not supported. However, you can install a DNS/DHCP server on Linux and then use iManager to move DNS servers within the same eDirectory Tree or across eDirectory trees.

The administration of DNS does not change between NetWare and OES 2; either iManager or the Java console can be used as the administrative tool. If you are using Novell's NetWare based DNS and DHCP services and hosting it via a cluster, this configuration can also be carried forward into an OES 2 environment.

Novell recommends that all servers, virtual cluster servers, and the tree object be registered in DNS regardless of platform. A full verification should be performed and any required additions made. All new servers, either virtual or physical, should be registered as they are deployed.

The DHCP services in OES 2 Linux have been enhanced to store configuration information in eDirectory just as NetWare implementations do. Once the DNS/DHCP information has been mirgated to OES2 Linux, administration can be performed through iManager and also an update to the DNS/DHCP Java Console.

Migrating DNS/DHCP

From iManager

The DNS/DHCP management utility in iManager 2.7 is available to convert existing NetWare DNS configurations to OES 2 Linux. This can be performed on a server by server basis, or all at once. The source server must be at least NetWare 6.5 SP5.

From YaST

The OES Migration Tools can also be used to migrate DHCP configurations from NetWare to OES 2 Linux. Again, the source server must be at least NetWare 6.5 SP5.

  1. Open YaST.
  2. Select Open Enterprise Server > Migrate Novell DHCP Server package and follow the screen prompts.

From the Command Line

     Run /opt/novell/migration/bin/

Note: Some DHCP features available with NetWare are not supported on Linux. See Section 12.2.2, "DHCP Differences Between NetWare and OES 2 Linux" in the [OES 2: Planning and Implementation Guide for additional information].

Additional Information

See also the [OES 2 DNS/DHCP Administration Guide for Linux]].

Time Synchronization

Time synchronization is not provided by eDirectory, but is important in maintaining the integrity of the tree. In previous versions of eDirectory, replica synchronization depended on time synchronization. Currently, replica synchronization works independently (doesn't depend on either NetWare timesync.nlm or NTP) but does rely on accurate time stamps; replica synchronization will still occur without proper time synchronization, but events may happen out of proper sequence and result in inconsistent information about what took place and in what order.

In short, the servers that host eDirectory replicas need to be synchronized. OES 2 Linux uses the Network Time Protocol (NTP) to maintain a common time for all servers on the network. NTP is an industry standard protocol that uses UDP (part of the TCP/IP protocol suite) on port 123 to communicate between time providers and time consumers.

A computer functioning as a time provider understands the NTP protocol and provides NTP time to other servers and workstations on the network. Time consumers also understand the NTP protocol and seek NTP time from an NTP time provider and can, in turn, act as a time provider for other network servers and workstations.

All computers on the network with Internet access can get time from NTP servers on the Internet. NTP synchronizes clocks to the Universal Time Coordinated (UTC) standard, which is the international time standard. The hierarchy that indicates where each server is getting its time is referred to as a stratum, with the first time provider designated as stratum 1.

A server that gets its time from a stratum 1 server is stratum 2, and so on. timesync.nlm is stratum 5 always. Both NTP providers and consumers work with operating systems that are NTP-compliant.

By default, NTP uses its own internal clock as the time provider but can be configured to use other time providers via the /etc/ntp.conf file. It's best to synchronize with multiple servers to help protect clients from an incorrect or downed server.

NTP time can be supplied from several sources:

  • Public Time Server. For small organizations (fewer than 100 servers), synchronizing servers to accurate public NTP servers provides sufficient time synchronization. To reduce traffic, it's best to have one or two servers synchronize with a public NTP source and have those servers provide time for the remaining servers. See
  • Reference Clock. Reference clocks are devices that synchronize via a variety of technologies including long wave radio signals, GPS transmissions, or CDMA technology. These can be expensive.
  • Server's Local Clock. The server's internal clock can be used as a time source, but because time can wander, this is generally not a preferred solution.
  • Network NTP Time Source. This is the recommended option for larger networks. In this case, you'll need to set up a server as an NTP time provider and then add the IP address of the time source to the /etc/ntp.conf file for servers that will use the designated server as the time provider.

General Guidelines

Consider setting up a master timeserver to make sure the entire directory tree has its time synchronized accurately.

  • Designate the most reliable server in the subnet as the time provider.
  • Configure at least two time providers to set fault tolerance.
  • Configure time consumers to contact a time provider within its own local network (so they don't contact time providers across costly WANs).
  • Generally, only one server in a network should communicate with an external time provider. This reduces network traffic across geographical locations and minimizes traffic across routers and WANs.

Note: The time synchronization modules in Novell Open Enterprise Server (OES) have been designed to ensure that new OES 2 servers can be introduced into an existing network environment without disrupting any of the products and services that are in place.

Both the Linux and NetWare installs automate the time synchronization process where possible. For complete information about planning and implementing a time synchronization strategy and setting up time providers and consumers, see Section 12, [Time Synchronization], particularly Section 12.3.4, ["Implementing Time Synchronization"] in the [OES 2: Planning and Implementation Guide].

Additional Information

For information about the files and programs included with NTP, refer to [].

For information on migrating NetWare NTP or TimeSync services to NTP on OES 2 Linux, see Section 4.0, "Migrating From NetWare to OES 2 Linux," in the [OES 2: Novell TimeSync for NetWare Administration Guide]. For information about setting up time synchronization on OES 2 servers, see Section 13, ["Time Synchronization," in the OES 2: Planning and Implementation Guide].

Anti-Virus and Backup Software

Several industry leaders in the anti-virus and backup markets have publicly committed to support Novell Open Enterprise Server 2, the following among them:

  • Symantec's Veritas NetBackup and Backup Exec and Symantec AntiVirus
  • BrightStor ARCserve Backup
  • McAfee anti-virus software

Anti-Virus Software

Symantec and McAfee based anti-virus solutions should work well in an OES 2 Linux environment. However, specific support for OES 2 is not provided by either vendor at this time. Symantec, and all other major vendors currently providing anti-virus and backup software for Novell operating systems, have committed to having OES 2 support in the release of their products that follows the OES 2 launch. Novell is working with vendors to get products certified. At the time of this writing, the McAfee LinuxShield product line supports both SLES 10 and the OES 1 Linux products. Since SLES 10 is the base product underlying OES 2 Linux, we anticipate that McAfee will have a supported solution available very shortly.

Important. If you run server-based anti-virus software, configure it so that it does not scan GroupWise directory structures such as domains and post offices where file locking conflicts can create problems for the GroupWise agents. If you need virus scanning on GroupWise data, check the [GroupWise Partner Products page] ([]) for compatible products.

A list of currently certified anti-virus software vendors can be accessed from []

Backup Software

Tivoli Storage Manager. If you are using Tivoli Storage Manager (TSM) v5.4 as a data backup solution, you will need to run the latest TSM 5.4 agents for OES 2 Linux to get full functionality including the proper back up of rights and trustees from NSS volumes.

Use the following command to back-up the trustee assignments in OES 2/ NSS with Tivioli Storage Manager (TSM) v5.4:

nss /ListXattrNWMetadata

Agent installs will need to be scratch installations on OES 2; no migration from NetWare is possible or required. New backup jobs should be configured and tested as the new Linux servers are put into production.

CommVault Galaxy. CommVault Galaxy version 6.1 doesn't support OES Linux. CommVault will be releasing version 7 SP1 in October, which will support SUSE Linux Enterprise Server 10, SP1. They currently plan to have full support for OES 2 by December 2007.

If you decide to use this software, you'll need to run the latest CommVault iData and Media agents for OES 2 Linux to get full functionality including properly backing up rights and trustees from NSS volumes. These agent installs will be scratch installations on OES 2; no migration from NetWare is required. New backup jobs should be configured and tested as the new Linux servers are put into production.

A list of currently certified anti-virus software vendors can be accessed from []


Many ZENworks features, such as polices and application distribution, are purely eDirectory and file system dependent. There is no dependency on the server OS. The remaining services, such as inventory and imaging, that do have modules that run on a server are dependent on a host OS.

The ZENworks 7 suite of products is fully tested and supported on the SLES 10 platform. Testing on the SLES 10 sp1 and OES 2 platforms is ongoing. If you are using ZENworks, Novell recommends keeping server-based ZENworks modules on the current NetWare platforms until such time as Novell has fully tested and certified the product suite (ZDM 7 and ZSM 7 ) on the OES 2 platform.


With OES 2 SP1, Novell will enable Linux servers to behave as if they are Active Directory servers. This will allow users to authenticate to a Linux server or service with their Windows clients using their eDirectory usernames and passwords, but using native Windows protocols.

This will provide seamless cross-authentication between Active Directory and eDirectory. In other words, users will work in a pure Windows desktop environment while still taking advantage of Novell back-end services and technology.

This Windows server access technology will use cross-protocol locking to allow support for both NetWare Core Protocol (NCP) and pure Microsoft protocol clients; however, it will be possible to disable NCP clients on a case-by-case basis if needed. Either way, access rights will be enforced by NSS.

You can enable Windows server access technology when the server is first installed or after the fact by creating Windows shares using Novell iManager or the Microsoft Management Console. You can also perform certain file system and directory tasks, as well as centrally administer SAMBA shares, using either Novell iManager or Microsoft Management Console.

As OES 2 is implemented, existing clients can be used (Windows XP, 2000, NT, Vista). However, an upgrade to the latest clients and workstation OS will be required to take full advantage of the new features of eDirectory and OES 2 such as NMAS and Password Self Service. The iPrint agent will also need to be installed on all workstations to use this functionality in the OES 2 environment.


The currently supported printing infrastructure from Novell, iPrint, is a greatly enhanced version of NDPS and is Novell's recommendation going forward. iPrint is completely IP-based and platform independent on both the client and server side. There is no requirement for an NCP client on the workstation. Printer provisioning and deployment is Web-based. iPrint is also fully cluster-aware.

While iPrint is supported on both the Linux and NetWare platforms, the back end infrastructure is different. iPrint on Linux does not support NDPS/NCP client-based printing. Both platforms support the same iPrint workstation agent. Automated migration tools are available to deploy the iPrint agent to any workstations still using NDPS. This can also be done using a ZENworks application deployment. A silent install option is available.

Tip: If any printers in your environment have IPX enabled but not configured, disable IPX. This is an unnecessary use of JetDirect and LAN bandwidth.

Set Up Workstation Printer Agents

Novell recommends deploying the iPrint agent to workstations before converting the backend infrastructure to OES 2 Linux. This will allow for the phased removal of the NDPS-based printers from the workstations before it becomes a requirement with the deployment of iPrint on OES 2. This will allow for a phased and transparent OES 2 printing migration for users.

An additional consideration is the use of literal IP addresses vs DNS entries with the printer configurations deployed to the workstations. If the printer/manager configurations are using IP address assignments rather than DNS, Novell recommends deploying the iPrint agent to all of the workstations and changing the existing iPrint managers to a DNS configuration. This will allow you to convert to iPrint on Linux without having to revisit the workstations.

If you use DNS, the new iPrint infrastructure can be migrated to Linux in phases while leaving the existing NetWare infrastructure in place. The users are converted over when the DNS entry for each individual print manager is changed.

Set Up iPrint on OES 2

iPrint can be installed and configured on OES 2 Linux in parallel with an existing print environment to allow for a gradual phased migration of users to the iPrint infrastructure. While iPrint can be used to support queue-based printing, it is not the preferred method (the only normal requirement to maintain a queue is to support legacy DOS-based applications that print directly to a queue rather than to a windows printer or LPT port).

Source and target servers can be in the same or different eDirectory trees. The source server for an iPrint migration to OES 2 Linux must be NetWare 6.5 SP5 or above.

To set up iPrint on OES 2 Linux, you'll need to

  • Install iPrint on the OES 2 target Linux server using the iPrint pattern install. See Section 3.0, "Setting Up iPrint on Your Server."
  • Create an OES 2 Driver Store on the network. See Section 3.2.1, "Creating a Driver Store."
  • Create a Print Manager on the target server. See Section 3.2.3, "Creating a Print Manager."

All references are to the [OES 2 iPrint for Linux Administration Guide].

Migrate iPrint to OES 2

Novell recommends the following steps to bring a current printing environment up to supported standards before migrating print infrastructure to OES 2 Linux or Linux clusters as required:

  • Install and configure iPrint on any NetWare 6.5 clusters.
  • Install and configure all network printers in iPrint.
  • Install and configure web-based client deployment tools.
  • Set up iPrint on OES 2 Linux.
  • Deploy iPrint agents to workstations.

Novell's Server Consolidation and Migration Tool or the YaST iPrint Migration Utility are available to copy a NetWare-based iPrint/NDPS environment to a Linux iPrint infrastructure. This will allow for a phased parallel installation approach to a Linux migration with a minimum of user or administrative impact. Using a mixed Linux and NetWare based printing environment within the same tree is fully supported.

Additional Information

See the [OES 2: iPrint for Linux Administration Guide], particularly the following sections:

  • Section 5.4.1, "Migrating Your iPrint System using the YaST iPrint Migration Utility"

S*ection 5.4.2, "Using the Command Line Utilities to Migrate to OES 2 Linux"

Securing the OES 2 Server

This section was originally published as part of a Cool Solutions AppNote, ["Complete NetWare to OES Linux Migration Guide,"] written by Mike Faris, Sr. Network Engineer at Aviall. It is reprinted here with permission.

These recommendations are optional and should be used only as a guide in securing your server. Make sure these recommendations are in line with your organization's security policies regarding hardening your servers.

GRUB Boot Loader

Password protect the boot loader to prevent editing of the boot environment or passing kernel level commands to the system at boot time. Use the md5crypt command within GRUB to encrypt a password. Then use this hash to edit the menu.lst file and insert the password line as shown below.

Be sure NOT to use the same password as root or any other user password on the system. If you “fat finger” the password without testing it first you will not be able to make changes to the boot process upon boot up.

# grub

  GRUB version 0.97 (640K lower / 3072K upper memory)

[ Minimal BASH-like line editing is supported. For the first word,
 TAB lists possible command completions. Anywhere else TAB lists 
 the possible completions of a device/filename. ]

grub> md5crypt

Password: *******
Encrypted: $1$vUYoM$OAxm9NVNUBsCeP1dl50


vi /boot/grub/menu.lst

color white/blue black/light-gray
default 0
timeout 8

password --md5 $1$vUYoM$OAxm9NVNUBsCeP1dl50
title linux
  kernel (hd0,0)/boot/vmlinuz root=/dev/sda1 vga=795


Password protect changes to the BIOS to prevent changing the boot order of the device. In production systems, booting from CD or floppy should be disabled.

Tuning Network Kernel Parameters

There are a few parameters that can be applied to the kernel through the proc file system to improve protection of the server.

Modify /etc/sysconfig/sysctl to add these options along with the default configuration options.

net.ipv4.ip_forward = 0 -- Disables IP forwarding.
net.ipv4.conf.all.accept_source_route = 0 -- Disables source routing.
net.ipv4.tcp_syncookies = 1 -- TCP syn flood protection parameter.
net.ipv4.tcp_max_syn_backlog = 4096 Additional TCP syn flood protection.
net.ipv4.conf.all.rp_filter = 1 Enables anti-spoofing protection.
net.ipv4.conf.all.send_redirects = 0 Disables the sending of ICMP redirects.
net.ipv4.conf.all.accept_redirects = 0 Disables receipt of ICMP redirects.
net.ipv4.conf.default.accept_redirects = 0 Disables ICMP redirects for newly activated.

Warning Banners

Include a warning message for all direct methods of connection to the server.

/etc/motd. Add a warning banner to this file.

/etc/issue. Add a warning banner to this file and copy the /etc/issue file to /etc/

SSH connections. For SSH connections, edit the /etc/ssh/sshd_config file. Below is the what needs to be changed to point the banner at the /etc/ file.

# vi /etc/ssh/sshd_config

# no default banner path
Banner /etc/
#VerifyReverseMapping no

# override default of no subsystems

SSH Configuration

In addition to setting a banner as above, SSH should be restricted to version 2. Version 1 has some inherent weaknesses and so should be avoided. Edit this file and make the changes listed in Bold in the example below. Most settings are fairly self explanatory. Hosts should not be automatically trusted through the rhosts types of authentication or even with a machine-based certificate as with the RSA variants. Root should not be allowed direct access. For administration, connect to the machine as a regular user and then SU to root for additional needed rights.

#Port 22
Protocol 2
#ListenAddress ::
SyslogFacility AUTH
#LoginGraceTime 600
PermitRootLogin no
#StrictModes yes
RhostsAuthentication no
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in 
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
PermitEmptyPasswords no

Further Securing Remote Login

In addition to the restrictions made on SSH, we should also further disable remote interactive login for root in case, mistakenly or maliciously, telnet or some other method of tty access was enabled again. Modify the /etc/securetty file. All lines except the TTY1 should be commented out. This is needed for console access. SSH is running its own daemon and is not affected by these settings.

# This file contains the device names of tty lines (one per line,
# without leading /dev/) on which root is allowed to login.
# for devfs:

Protect this file further by executing the following to ensure that only root can read the file and nobody can write to it, even root, until root again chmod's the file with more permissions.:

chown root:root /etc/securetty 
chmod 400 /etc/securetty 

Modify /etc/inittab

/etc/inittab has several settings that should be hardened.

  • Disable Ctrl-Alt-Delete from shutting down the server.
  • Edit the default run level.
  • Protect the server even in Single User mode.
  • Disable extra console login daemons (Ctrl-Alt-Fx) to further protect console access.

See the settings in Bold.

# The default runlevel is defined here

# First script to be executed, if not booting in emergency (-b) mode
# what to do in single-user mode
ls:S:wait:/etc/init.d/rc S

# what to do when CTRL-ALT-DEL is pressed. Comment to disable.
#ca::ctrlaltdel:/sbin/shutdown -r -t 4 now

The "3" in the id:3:initdefault line designates that the default run level is level 3 which does not load the GUI. The GUI can be loaded as necessary with the startx command but should not remain loaded nor should it load by default on the server.

The line beginning with "~~:S" is the command for what to do in single user mode. (i.e. typing "single" as a boot parameter in grub -- which now requires password access anyway). Change the "respawn" command to "wait." This will prompt for the root password before continuing.

The "ca::ctrlaltdel:/sbin/shutdown --r --t4 now" line is the command to execute when Ctrl-Alt-Delete is pressed. This should be commented out as shown to disable this functionality and prevent someone with physical access from shutting down the machine without a valid login.

Xwindows - GUI Protection

Although X-windows does not loading by default on the server, this can be changed easily by an administrator; it is also available to load manually by changing run levels or typing startx at the console prompt. Therefore, implement the following extra safeguards:

Disable XDMCP

Remote machines should not be able to get an X terminal login window. Edit the following lines in /etc/X11/xdm/Xaccess to prepend them with a "!" as shown.

!* #NO host can get a login window !* CHOOSER BROADCAST #NO indirect host can get a chooser

Disable listening on port 6000

This prevents the X system from listening for X events from remote machines. Local X access at the console is not affected. Edit the config file /etc/X11/xdm/Xservers as shown below to add the "-nolisten tcp" switch to this line.

:0 local /usr/X11R6/bin/X :0 vt07 -nolisten tcp

Restrict cron and at daemons

Cron and at daemons run processes on the system as root so prevent access to them, as well as the crontab command and files, so that malicious code can't be "scheduled." The binaries are also world executable and SUID to root so they can be dangerous. Restrict access to them with the following steps.

Create cron.allow and at.allow files

These files will restrict access to cron to only the users listed in the files. All others will be denied. The only user in the list should be root. These files don't exist by default so you need to create them with the echo command as follows. Delete any deny files (/var/spool/cron/deny).

# echo root > /etc/cron.allow
# echo root > /etc/at.allow

Modify permissions on cron/at related files

Since all cron and at files are read and written to by processes that are SUID root, normal system users won't ever need direct access to the files so they should be secured to prevent tampering.

# chown -R root:root /etc/cron* /var/spool/cron
# chmod -R go-rwx /etc/cron* /var/spool/cron

Additional Information

See Section 21.0, "Security," in the [OES 2: Planning and Implementation Guide]. The following sections are included:

  • Section 21.1, Overview of OES Security Services
  • Section 21.2, Planning for Security
  • Section 21.3, Configuring and Administering Security
  • Section 21.4, Links to Product Security Considerations Sections (this section provides links to security sections in the various OES 2 installation and administration guides for OES 2 services).

The Security table of contents for the OES 2 documentation is also an excellent resource for accessing security information. See []