This section covers the general coexistence and migration issues that you should consider as you plan your transition to OES. Where appropriate, it provides links to service-specific information found in the individual OES product administration guides.
The discussion of coexistence and migration issues is organized around the various system fabrics:
Together, these fabrics make up the underlying foundation and infrastructure of the network. While it is unlikely for any two networks to have the same configuration within each fabric area, the sections that follow cover common issues that can help ease your transition to OES.
Directory services is a central, underlying component in distributed systems. The directory stores information about all services and resources available on the network. It also contains information about the users who are authorized to access these services and resources. The integration of the directory with user authentication allows for identity-based access to resources. A user logs in once to the directory tree and is granted access to servers and resources across the entire network.
Each iteration of NetWare from 4.0 on has been accompanied by its own version of Novell Directory Services® (NDS) and later by versions of Novell eDirectory. More recently, eDirectory has been ported to other platforms and made available as a separate product that can run on Microsoft* Windows, Red Hat*, and SUSE versions of Linux, as well as on various flavors of UNIX (Solaris*, AIX*, and HP-UX*).
While each new version of NDS/eDirectory brought numerous technical improvements, some backward compatibility issues arose as changes were made to the underlying protocols, database, and security infrastructure. Customers moving from NetWare 4.x to 5.x faced significant challenges not only in upgrading NDS but in moving from IPX™-based NetWare 4 to TCP/IP-based NetWare 5. Those transitioning from NetWare 5.x to 6.x faced major hurdles in the switch from NDS to eDirectory, as changes were made to the core schema and security-related components.
To minimize coexistence issues with older versions of NDS and eDirectory, OES ships with Novell eDirectory 8.7.3. This version of eDirectory is compatible with the versions of NetWare and NDS/eDirectory listed in Table 2-2.
Table 2-2 NetWare versions and corresponding NDS/eDirectory versions
Since the release of NetWare 6.5, Novell has strongly encouraged customers to upgrade to eDirectory 8.7 wherever possible. The compatible NDS/eDirectory versions listed in the table above are to help servers coexist temporarily during a phased upgrade project and should not be viewed as a long-term coexistence solution.
The recommendation to move to eDirectory 8.7 has been generally accepted throughout the NetWare customer base. Novell has helped motivate customers by making minimal schema changes between eDirectory 8.7.0 and 8.7.3, and by resolving most of the security infrastructure issues of the past.
Most NetWare installations today have at least one NetWare 6.x server running on the network. Thus, for the majority of Novell customers looking to deploy OES servers on their networks, the necessary eDirectory implementation issues have already been dealt with.
If you have successfully installed at least one NetWare 6.5 server in your tree, you can skip the rest of this section and continue with Section 2.2.2, Identity Management.
If you have an NDS/eDirectory tree that was created with any version of NetWare prior to NetWare 6.5 and you plan to introduce a new OES server (running on either NetWare or Linux) into that tree, you should be aware of and take appropriate steps to address the following coexistence issues.
Trees running eDirectory 8.6 and NDS 8.85c, 7.62c, or 6.21 must have the core schema extended to support eDirectory 8.7 before you can install the first NetWare 6.5/OES NetWare or OES Linux server.
Use the Novell Deployment Manager and complete the tasks to
Search for eDirectory/NDS Versions and Prepare for New
eDirectory. For more information, see Prepare
the Network with Deployment Manager
in the OES
for NetWare Installation Guide.
In a NetWare 5.1 environment, the Certificate Authority (CA) and security domain key (W0 object) must be located on a server running eDirectory 8.7.
For more information, see Section 2.2.5, Security and Certificate Management.
There are several issues with NetWare 5.1 SP7 and NDS 8 regarding Service Location Protocol (SLP) and LDAP authentication. Novell recommends that you apply at least the sas.nlm and SLP modules from NetWare 5.1 SP8 before attempting to install an OES server.
Without the updated sas.nlm module, an OES Linux server installed into an NDS 8 tree hangs during the LDAP authentication portion of the install.
If the SLP modules are not applied, the NetWare 5.1 SP7 server might not be able to work correctly with the Linux version of OpenSLP.
For more information, see Section 2.2.4, Discovery.
In a NetWare 5 tree running NDS 7.62c or a NetWare 4 tree running NDS 6.21, either the OES servers must be installed into their own eDirectory 8.7 partition, or the master replica of the partition must be located on a server running eDirectory 8.7.
For more information, see the Novell eDirectory 8.7.3 Administration Guide.
In a NetWare 4 tree running NDS 6.21, you must enable IPX on all NetWare 5 or later servers that need to communicate with the NetWare 4 servers. Coexistence of an IPX-based network and a TCP/IP-based network is achieved through the technologies introduced with NetWare 5 (SCMD compatibility mode, dual transport stacks, etc.).
OES Linux servers do not support IPX and are unable to communicate with NetWare 4 servers.
For more information, see Section 2.2.7, Network Protocols.
Many of the current eDirectory management tools do not perform well with older versions of the directory. For example, NDS iMonitor can not get health check information from an NDS 6 server, and iManager cannot perform partition operations on an NDS 6 server. In large networks, scalability issues can arise as well.
The recommended strategy to avoid migration issues on an existing NetWare network is to upgrade to eDirectory 8.7.3 before you start installing OES servers.
For information on upgrading to eDirectory 8.7.3 on NetWare,
see Installing
or Upgrading Novell eDirectory on NetWare
in the Novell
eDirectory 8.7.3 Installation Guide.
For more information on preparing an existing NetWare eDirectory tree for OES, see Section 3.2, Installing OES Servers into an Existing Tree.
OES for Linux servers can be installed into an existing eDirectory 8.7.3 tree consisting of SLES 9 servers. However, you should install OES for Linux only on a clean computer. Do not attempt to install OES for Linux on a server that already has eDirectory 8.7.3 installed.
You can upgrade existing SLES 9 and SLES 9 SP1 servers to
OES. The upgrade process updates Novell eDirectory on the servers
at the same time. For more information, see Upgrading
to OES Linux
in the OES for Linux Installation
Guide.
The following eDirectory platforms do not support OES for Linux, even if you upgrade them to version 8.7.3:
For additional information, see eDirectory
Coexistence and Migration
in the Novell
OES Planning and Implementation Guide.
Novell eDirectory includes Lightweight Directory Access Protocol (LDAP) Services, a server application that provides LDAP authentication for objects stored in eDirectory. It also lets LDAP clients access information stored in eDirectory.
SLES 9 uses OpenLDAP, an open source software component, as its LDAP authentication mechanism.
LDAP Services for eDirectory 8.7.3 and OpenLDAP servers can coexist in the same tree. Most OES services leverage LDAP Services for eDirectory for authentication.
When you install OES for NetWare or OES for Linux, default port numbers are assigned to eDirectory LDAP. You can change the default ports if necessary to avoid port conflicts.
If you are adding an OES Linux server to a NetWare 5.1/NDS 8 tree, ensure that all OES services which use LDAP are configured to go to the OES Linux server and not to a NetWare 5.1 server.
LDAP is not available in a NetWare 4 environment. NetWare 4 supports only Novell Directory Access Protocol (NDAP), which is not compatible with LDAP.
If you have users in an OpenLDAP database and you want to
migrate them to eDirectory, you can use the Novell Import Conversion
Export (ICE) Utility for this purpose. For more information, see Novell
Import Conversion Export Utility
in the Novell
eDirectory 8.7.3 Administration Guide.
For additional information, see Coexistence
and Migration of eDirectory LDAP Services
in the Novell
OES Planning and Implementation Guide.
Maintaining user identities on a network might seem like a basic task, but it can become complex when users have multiple identities to access services on NetWare, Windows, and Linux servers.
To simplify identity management in mixed networks, OES includes the Nsure® Identity Manager Bundle Edition. Formerly known as DirXML, Nsure Identity Manager provides licensed synchronization of user-related information (including passwords) held in NT domains, Active Directory* domains, and eDirectory trees. When data from one system changes, Identity Manager detects and propagates these changes to other connected systems based on the business policies you define.
In networks where eDirectory must coexist with other directories, Identity Manager is a good solution for synchronizing user identities across disparate systems.
For additional information, see Identity
Management Services
in the Novell OES
Planning and Implementation Guide.
Linux User Management (LUM) is a service provided in OES to let eDirectory users function as local users on Linux servers.
Users in a Linux environment are defined and managed according to the POSIX (Portable Operating System Interface) standard. POSIX dictates that all users of a particular Linux server have standard attributes, such as user name, user ID (UID), primary group ID (GID), and password.
When eDirectory users are Linux enabled through LUM, the standard Linux (POSIX) attributes and values are added to their User objects, including membership in a special group that serves as the primary group.
When users are Linux enabled, access to OES Linux servers is enabled by leveraging the Linux Pluggable Authentication Module (PAM) architecture. PAM makes it possible for eDirectory users to authenticate with the OES Linux server through LDAP.
Some services on an OES Linux server require that eDirectory users be Linux enabled in order to access the services. These include core Linux utilities enabled for LUM (such as ftp, login, and rsh), OES Samba shares on the server, and Novell Remote Manager (NRM) on Linux.
There are other OES services that do not require Linux-enabled access, but have some LUM requirements. These include NCP™ Server, NSS, QuickFinder, Novell iFolder 2.x, and other Web services.
For more information about planning for LUM access to OES
services, see Linux
Access for eDirectory Users (LUM)
in the Novell
OES Planning and Implementation Guide.
Novell Linux User Management was first introduced for Novell Nterprise Linux Services (NNLS). LUM has been enhanced for use with the expanded suite of OES services.
There is no direct migration path from NNLS to OES, so there are no coexistence and migration issues to deal with for LUM.
For more information about LUM and how to Linux enable eDirectory users, see the Novell Linux User Management Technology Guide.
In TCP/IP-based networks, a naming service is required to resolve IP addresses into server names. This allows users and applications to identify network servers either by name (such as server1) or by IP address (such as 123.45.67.89).
Domain Name Services (DNS) is the standard naming service in TCP/IP-based networks. DNS is based on the Bind architecture developed for UNIX systems. It is often paired with Dynamic Host Configuration Protocol (DHCP) to provide host server configuration information to clients.
For NetWare, Novell has developed a directory-enabled DNS/DHCP service that complies with the Bind 9.2 standard. Novell DNS/DHCP Services leverage eDirectory to provide centralized configuration and management of the services. Administrators can manage Novell DNS/DHCP Services using the Web-based iManager utility or the standalone DNS/DHCP Management Console.
SLES 9 also comes with a Bind-compliant DNS Server.
Because the NetWare and Linux DNS/DHCP services both adhere to the Bind standard, they can coexist on the same network. Clients can receive naming and configuration information from any DNS/DHCP server that is available.
Some DNS security mechanisms, such as DNS Security Transaction Signatures and DNS Security Extensions, are not supported in the NetWare DNS server.
The SLES 9 DNS server does not support the dynamic reconfiguration and SNMP Traps that are available with the NetWare DNS server. It is not integrated with eDirectory and cannot be managed with iManager or the Novell DNS/DHCP Management Console.
You can migrate zone data of a master zone from a NetWare DNS server to a SLES 9 DNS server.
For more information, see OES
Coexistence and Migration Issues
in the Novell
OES DNS/DHCP Services Administration Guide.
Another essential function within a network is the ability for clients and applications to discover the existence and location of services. The discovery fabric of a system can range from a fully manual process such as DNS to a fully automatic process such as Service Location Protocol (SLP).
Various discovery mechanisms are available to network service components:
Any given system can adopt the exclusive use of a particular discovery technology, or it can use the different technologies in combination. When multiple discovery providers are available, clients and applications can be written to select from the alternative elements in a policy ladder.
NetWare 3 and 4 used the IPX-based Service Advertising Protocol (SAP) as the discovery mechanism. With SAP, NetWare servers began advertising their services automatically upon installation. If a server became unavailable, the SAP information on the network was dynamically refreshed.
When support for the TCP/IP protocol was added starting with NetWare 5, the Service Location Protocol was adopted as the default, though optional, discovery mechanism. SLP was chosen because it was the TCP/IP-based protocol most like SAP in its automatic nature and dynamic refresh capabilities.
The Novell version of SLP adapted portions of the SLP standard in order to provide a more robust service advertising environment.
Novell SLP remains the default discovery mechanism in OES for NetWare. However, all NetWare service components that engage in discovery, including Novell Client software, can use alternative mechanisms such as DNS, eDirectory, or local host configuration files.
In SLES 9, SLP is available through the inclusion of OpenSLP, an open source implementation of the IETF Service Location Protocol Version 2.0 standard.
In OES for Linux, OpenSLP is available for those applications that require it. However, the default discovery mechanism is DNS.
Novell SLP directory agents share information with other directory agents in the same context through eDirectory. With OpenSLP, each directory agent is completely separate. An OpenSLP directory agent knows only about the services it is told about, and directory agents are not synchronized.
You can run both OpenSLP and Novell SLP directory agents in the same network, but OpenSLP directory agents won't synchronize with Novell SLP directory agents, and Novell SLP directory agents won't synchronize with OpenSLP directory agents.
OpenSLP-based user agents or service agents can access Novell SLP-based directory agents.
For more information on SLP configuration issues in eDirectory,
see Configuring
OpenSLP for eDirectory
in the Novell
eDirectory 8.7.3 Administration Guide.
NetWare Loadable Module (NLM) programs that use the WinSock interface can have access to all of the discovery vehicles automatically. When an application sends an inquiry to WinSock, whether the inquiry is for a specific service name or specified with wildcard characters, WinSock searches all of the discovery vehicles for information to return to the application. If you removed SLP as a source of information and placed the information into DNS or a local host file, the application would not know the difference.
NOTE:There is no WinSock equivalent in the Linux environment. BSDSock provides only the transport interface, not the name resolution interface.
UDDI is an open-source, platform-independent registry that enables you to describe, discover, integrate, and publish Web services. The purpose of UDDI-compliant registries is to provide a discovery platform on the World Wide Web so you can easily locate, integrate, and manage businesses and services.
For NetWare 6.5, Novell developed a directory-enabled UDDI server for use with the exteNd™ J2EE Application Server. In OES for NetWare, the UDDI server component has been removed from the list of products that can be installed throught the NetWare installation program.
However, the Novell UDDI server has been released as open source software and is available for download on the Novell Forge Web site.
The current OpenWBEM implementation of the Common Information Model Object Manager (CIMOM) lists SLP as an optional discovery provider. If SLP is to be used with CIMOM, it must be in compliance with the SLP API specification (RFC 2614). The default discovery vehicle for CIMOM is the statically configured URI. For more information, see the CIMOM specification at the Desktop Management Task Force (DMTF) Web site.
Security is a top concern in network environments, especially when internal networks are connected to the outside world via the Internet. Among the many aspects of security are user identification and authentication (making sure a user is who he or she claims to be) and authorization (giving an authenticated user permission to access resources on the network).
The simplest form of user security is assigning a username and password. If a person supplies the correct password for a given username, that person is assumed to be an authentic network user and is granted access to all resources authorized for the user account.
A more stringent authentication process involves the use of digital certificates issued and verified by a Certificate Authority (CA) as part of a Public Key Infrastructure. In this system, public and private keys are used to encrypt user passwords to prevent their detection as they are transmitted across the network.
For a more detailed overview of network security concepts,
see Authentication
and Security
in the Novell
OES Planning and Implementation Guide.
Novell International Cryptography Infrastructure (NICI) is the basis for the security services offered in NetWare/eDirectory-based networks. NICI is a cross-platform, extensible cryptography module that provides keys, algorithms, various key storage and usage mechanisms, and a large-scale key management system. Downloadable modules enable eDirectory users throughout the world to implement 128-bit (and stronger) network encryption.
For more information about NICI, see the NICI 2.6x Administration Guide.
In addition to eDirectory, other security services built on NICI include Novell Certificate Server™ and Novell Modular Authentication Service (NMAS).
Novell Certificate Server provides public key cryptography services that are natively integrated into eDirectory and that allow you to mint, issue, and manage both user and server certificates. These services allow you to protect confidential data transmissions over public communications channels such as the Internet.
For more information about Novell Certificate Server, see the Novell Certificate Server 2.7.x Administration Guide.
NMAS provides unified support for additional ways of authenticating users to eDirectory on NetWare 5.1 or later, Windows NT/2000, and Linux/UNIX networks to help ensure that the people accessing your network resources are who they say they are. NMAS allows the use of authentication devices such as smart cards and tokens, as well as biometric methods such as fingerprint reading and retinal scanning.
For more information about NMAS, see the Novell Modular Authentication Services (NMAS) 2.3 Administration Guide.
In OES, you have the choice of retaining your current password maintenance methods (simple password, NDS passwords, etc.), or you can deploy Universal Password to simplify password management.
For more information, see Password
Support in OES
in the Novell OES Planning
and Implementation Guide.
Coexistence and migration issues can arise when OES servers are installed into networks that use older versions of NICI. NICI was first introduced with NetWare 5.0. It has undergone several updates in conjunction with subsequent releases of NetWare. The version included with OES is NICI 2.6.6.
The first server you install in an eDirectory tree becomes the Certificate Authority for that tree. If you have a tree that was created with a NetWare 5.x server as the first server, you should check the tree for SDI (Security Domain Infrastructure) key consistency before installing any OES servers.
NOTE:A Security Domain is a collection of one or more servers that share a common cryptographic key. In Novell network environments, a Security Domain is a single NDS/eDirectory tree.The Security Domain Infrastructure is a cryptographic system that comprises the components and services used to manage these common keys.
You might see SDI keys referred to as NICI keys because they are created within the NICI framework.
You might have invalid SDI keys if the following products or features do not work after installing an OES server into the tree:
You might also see errors such as the following:
To verify that SDI keys are properly synchronized in your tree, use the SDIDiag utility as described in Section 2.1.3, SDIDiag Utility.
To identify and resolve problems with the PKI service in your tree, use the PKIDiag utility as described in Section 2.1.2, PKIDiag Utility.
Keeping accurate time is a critical function for servers in an eDirectory tree. The reported time must be synchronized across the network in order to provide expiration dates and time stamps to establish the order of events taking place in eDirectory.
By default, NetWare servers use an NLM mechanism called Timesync to provide for synchronized time. Timesync supports the NetWare time server hierarchy of Single Reference Time Server, Reference Time Server, Primary Time Server, and Secondary Time Server.
Timesync is a derivative of the Network Time Protocol (NTP) version 3 and can both consume and provide NTP time packets in addition to Timesync packets.
During installation of OES for NetWare, you can choose between Timesync and NTPv3 as the time synchronization mechanism for new servers. Choosing NTPv3 allows OES NetWare servers to participate in an existing NTP-based network.
NTP addresses fault tolerance in the form of a time provider group, where all the servers in one geographical location network obtain time from other servers in the same network. Only one server communicates with an external time provider and obtains time from it.
On OES for Linux servers, NTP is the only supported time synchronization method. OES Linux uses the NTP daemon (xntpd) to communicate with other servers in the time provider group and get time information.
The time synchronization modules in OES have been designed to ensure that new OES servers, running on either NetWare or Linux, can be introduced into an existing network environment without disrupting any of the products and services that are in place.
For a thorough explanation of time synchronization planning
and implementation, as well as coexistence and migration issues,
see Time
Synchronization
in the Novell OES Planning
and Implementation Guide.
Network nodes must support a common protocol in order to exchange packets. For example, a transport protocol defines how to establish a point-to-point connection so that one node can send a message to another and have the packets arrive intact and in the correct order. It also determines how nodes are identified with unique addresses and how packets are routed, if necessary, to reach the intended receiver.
In the 1980s, Novell adopted Internetwork Packet Exchange™ (IPX) as the networking protocol for NetWare-based networks. IPX and its companion transport protocol Sequenced Packet Exchange™ (SPX™) form a very efficient mechanism for exchanging packets within local and wide area networks.
IPX remained the foundational protocol for NetWare until the release of NetWare 5.0, which introduced support for the Internet-standard TCP/IP protocol suite.
The Novell TCP/IP stack that runs on NetWare servers is compliant with the latest RFCs. It is multiprocessor enabled and provides advanced features such as multihoming, load balancing, and fault tolerance.
Like all UNIX and Linux operating systems, SLES 9 is designed to work with the TCP/IP protocols. Novell does not support IPX on Linux.
In OES, communication between existing NetWare servers and new OES Linux servers is provided through TCP/IP.
IP Address Management is a centralized framework that stores and displays the IP address:port configuration of applications present on a server. The framework helps you in managing the IP address-application association when changing the server's IP address. It also helps in resolving IP address and port conflicts. This framework is available in OES NetWare and is fully functional with most NetWare 6.5 services.
In OES SP2, Novell IP Address Management is available as an optional network service that you can install on your OES Linux server. However, in this release, no services are currently using this framework to manage IP address configurations.
Coexistence between old IPX-based networks and new OES TCP/IP-based networks can be achieved through the technologies introduced with NetWare 5.0, such as the SCMD compatibility mode and dual transport stacks. When you install OES for NetWare, you can add IPX support as required.
The release of OES provides NetWare 4 customers with IPX-based networks an excellent opportunity to migrate to TCP/IP. Although there is no direct upgrade path from NetWare 4 to OES for NetWare, tools such as the NetWare Migration Wizard and Server Consolidation Utility are available to help in migrating user and directory data to new OES servers.
The migration of the transport fabric from IPX to TCP/IP is a different, larger issue. During the data migration process, IPX compatibility must be maintained on both source and destination servers. Applications and services that run only on IPX must be either rewritten or replaced. After all IPX dependencies are resolved, you can safely remove IPX support from your NetWare servers.
For more information on deploying TCP/IP in a NetWare environment, see the Novell TCP/ IP Administration Guide for OES.
Hosting shared data storage is one of the primary functions of network servers. Whether data volumes are directly attached to the server in RAID configurations or externally accessible in Storage Area Network (SAN) or Network Attached Storage (NAS) configurations, users need to be able to access their data on a continual basis.
For a comparison of the various file systems available on
NetWare and Linux, see File
Systems Overview
in the File Systems
Management Guide for OES.
The NetWare traditional file system is used in NetWare 5.0 and earlier versions. It is a 32-bit file system that supports ASCII double-byte characters and a maximum file size of 4 GB.
Novell Storage Services (NSS) was introduced in NetWare 5.1 and became the primary storage system in NetWare 6. NSS is a 64-bit file system that supports faster volume mounting and a maximum file size of 8 TB. NSS offers many advanced features and capabilities, including multiple simultaneous namespace support, native Unicode*, user and directory quotas, multiple data stream support, and event file lists.
In OES, both NetWare and Linux servers can host NSS volumes. NSS offers Linux advanced file system features that aren't available in other Linux file systems, including directory structure visibility, a trustee access control model, rich file attributes, and a file salvage subsystem.
OES SP1 added support for many new features to bring NSS on
Linux more into parity with NSS on NetWare. For a list of new features
in NSS for OES SP2, see What's
New
in the Novell Storage Services File
System Administration Guide for OES.
OES for Linux supports Linux traditional file systems such as Reiser, ext2, and ext3. SLES 9 requires one of these file systems for its system (root) partition.
OES NetWare supports both the NetWare traditional file system and NSS.
After upgrading an older NetWare server to OES for NetWare, it is possible for a NetWare Traditional file system volume to still reside on that server. You can continue to use Traditional volumes with OES NetWare or you can upgrade them to NSS.
For information on converting Traditional volumes to NSS,
see Coexistence
and Migration Issues
in the Novell Storage
Services File System Administration Guide for OES.
If you want to migrate data from a Traditional volume to an NSS volume on OES for Linux, use the Novell Server Consolidation Utility 4.0 or later. You must first install NFS name space support on the Traditional volume.
For more information on migrating data from NetWare to Linux,
see Understand
NetWare-to-Linux Data Migration Issues
in the Novell
Server Consolidation and Migration Toolkit 1.1 Administration Guide.
NSS volumes are cross-compatible between NetWare and Linux servers. You can mount a nonencrypted NSS data volume on either kernel—Linux or NetWare—and move it between them. In a clustered SAN, volumes can fail over between kernels, allowing for full data and file system feature preservation when migrating data to Linux.
To use NSS on OES Linux, you must have a disk available to be managed by Enterprise Volume Management System (EVMS). The boot partition (such as /boot for Grub) and system partition (such as /root for the swap and system volumes) are managed by Logical Volume Manager (LVM). Any disk managed by LVM cannot be managed by EVMS, which makes the disks where the boot partition and system partition reside unavailable to NSS.
If you have a single-disk server that you want to install
OES for Linux on and create an NSS volume, see Installing
Linux with EVMS as the Volume Manager of the System Device
in
the OES Linux Installation Guide.
On OES Linux, you can use NSS volumes only as data volumes. Configure NSS pools and volumes in iManager or NSSMU after the server installation completes successfully.
For OES SP1, a new metadata structure (Beast Version 3) on
NetWare was implemented to provide improved support for hard links.
After you upgrade your NetWare operating system, you must upgrade
the media format to use the new metadata structure; some restrictions
apply. For more information, see Upgrading
the Media Format (NetWare)
in the Novell
Storage Services File System Administration Guide for OES.
For additional information about coexistence and migration
of NSS volumes, as well as access control issues for NSS on Linux,
see Coexistence
and Migration Issues
in the Novell Storage Services
File System Administration Guide for OES.
You can install NCP Server for Linux to provide NetWare Core Protocol™-based access to Linux traditional file systems. This allows users running the Novell Client software to map drives to the Linux file system data, with access controls being enforced by NCP.
For more information on using NCP Server for Linux in OES, see the NCP Server for Linux Administration Guide.
For information about clustering servers to provide high availability data storage, see Section 2.2.9, Clustering.
Users can access data storage on OES NetWare and OES Linux servers through a number of methods. For more information, see Section 2.2.11, Client Access to File Services.
In mission-critical networks where 24x7 availability is of paramount concern, clustering is a popular solution for business continuance. By installing multiple servers together in a cluster, resources can be dynamically switched or moved in the event of a server failure. Clustering also allows dynamic assignment and reassignment of server storage.
Novell Cluster Services is a multinode clustering product available for both NetWare and Linux. It is eDirectory enabled and supports failover, failback, and migration (load balancing) of individually managed cluster resources.
With Novell Cluster Services, you can configure up to 32 servers into a high-availability cluster that can be managed from a single point of control. The product supports shared SCSI, iSCSI, and fibre channel storage area networks.
OES provides the ability to convert an existing NetWare based cluster to Linux and to manage mixed Netware and Linux clusters.
Performing a rolling cluster conversion from NetWare to Linux lets you keep your cluster up and running and lets your users continue to access cluster resources while the conversion is being performed.
In a rolling cluster conversion, one server is converted to Linux while the other servers in the cluster continue running NetWare 6.5 or OES NetWare. Then, if desired, another server can be converted to Linux, and then another, until all servers in the cluster have been converted to Linux. You can also leave the cluster as a mixed NetWare and Linux cluster.
For additional information, see Converting
a NetWare Cluster to Linux
in the OES
Cluster Services 1.8 Administration Guide for Linux.
The ability to back up and restore network information is essential for protecting business-critical data.
Novell Storage Management Services™ (SMS) is not a backup application. Rather, it provides a standard framework and the necessary interfaces that can be used in developing a complete backup/restore solution. SMS helps back up file systems (such as NSS) on OES NetWare and OES Linux servers to removable tape media or other media for offsite storage.
SMS is implemented as two independent components that provide functional abstractions:
For example, various applications use the file system TSA to back up and restore NSS file system data and metadata (trustee assignments, file attributes, and name spaces).
In OES, the SMS API framework is available on SLES 9 so that there is a single consistent interface to back up file systems on NetWare, file systems on Linux, and Novell applications such as GroupWise® and Novell iFolder. The API set has been enhanced to include new functionality for OES.
Most of the SMS coexistence and migration issues are of concern only to backup application developers. However, administrators should be aware that SMS-based applications must be used to back up and restore NSS file system data on OES for Linux servers. Although NSS is exposed as a Virtual File System-compliant file system, the Linux interfaces are inadequate to be able to back up NSS file system attributes, rich ACLs, trustees, and multiple data streams.
For additional information, see Coexistence
and Migration Issues
in the Storage Management Services
Administration Guide.
Storing shared data on network servers is only half of the picture. The other half is making it possible for users of Windows, Macintosh, and UNIX/Linux workstations to access the data. In some networks, the installation of special software is permitted on the workstations to provide client access. Others require users to be able to access shared data without having to install extra software on the workstation.
Novell Client for Windows is the long-standing software solution for providing NCP-based access to NetWare data from Windows workstations. The Novell Client extends the capabilities of Windows desktops to access the full range of Novell services, such as authentication to eDirectory, network browsing and service resolution, and secure file system access. It supports traditional Novell protocols such as NCP, RSA, and NDAP, and it interoperates with open protocols such as LDAP. For more information on the Novell Client for Windows, see the Novell Client for Windows Installation and Administration Guide.
The Novell Client for Linux provides these same services for Linux workstations. For more information on the Novell Client for Linux, see the Novell Client 1.0 for Linux Installation and Administration Guide.
Because NCP is now available on Linux, Novell Client users can attach to OES Linux servers as easily as they have been able to attach to NetWare servers. The NCP Server for Linux enables support for login script, mapping drives to OES Linux servers, and other services commonly associated with Novell Client access.
For more information on NCP Server for Linux, see the NCP Server for Linux Administration Guide.
On NetWare servers, the Native File Access Protocols (NFAP) allow users of Windows, Macintosh, and UNIX/Linux workstations to access NetWare server data through their native interfaces. No Novell Client software is required.
With NFAP, Windows workstations can access data through the Common Internet File System (CIFS) protocol. Macintosh workstations can access data through AppleTalk* Filing Protocol (AFP). UNIX/Linux workstations can access data through the Network File System (NFS) protocol.
Novell iFolder 2.1.x provides a Web- and network-based repository (iFolder server) that stores master copies of locally accessible files. Novell offers iFolder client software for Windows and Linux workstations.
The cross-platform capabilities of iFolder make it an ideal file synchronization solution for OES networks. The iFolder server integrates with the Apache Web Server on NetWare and Linux, and it uses LDAP authentication through eDirectory.
For more information about iFolder 2.1.x, see the Novell iFolder 2.1 Installation and Administration Guide.
Novell iFolder3.x is the next generation of iFolder, supporting multiple iFolders per user, user-controlled sharing, and a centralized network server for file storage and secure distribution. Users can share files in multiple iFolder folders, and share each iFolder folder with a different group of users. Users control who can participate in an iFolder folder and their access rights to the files in it. Users can also participate in iFolder folders that others share with them.
Novell iFolder 3.x is available only on OES Linux. For more information, see the Novell iFolder 3.x Administration Guide.
NetStorage provides Web access from browsers and Web-enabled devices such as PDAs to files on NetWare and Linux servers. It is also the browser-based access solution for iFolder.
In OES, NetStorage is available for both NetWare and Linux.
For more information about NetStorage, see the OES NetStorage Administration Guide for NetWare or the OES NetStorage Administration Guide for Linux.
OES includes a Novell implementation of the open source Samba software. Samba implements key services found in Microsoft CIFS environments, such as file and print services, authentication and authorization, name resolution, and service announcement (browsing). Through Samba, Windows workstations can access files stored on OES Linux servers using CIFS or HTTP-WebDAV instead of NCP.
For more information about Samba in OES, see the Samba Administration Guide for OES Linux SP2.
This section summarizes the coexistence and migration issues for the various client access features.
Native File Access Protocols are available only on OES NetWare servers.
For more information, see the OES Native File Access Protocols Guide.
In OES for Linux, iFolder 2.1.x can be installed in one of two modes:
For more information, see Installing
iFolder 2.1.5 on OES for Linux
in the Novell
iFolder 2.1 Installation and Administration Guide.
For additional information on iFolder coexistence and migration,
see Coexistence
and Migration Issues
in the Novell iFolder
2.1 Installation and Administration Guide.
Novell recommends that you install iFolder 3.x servers and iFolder 2.1x servers separately, each on its own dedicated computer. However, because these are two different software packages that share no files in common, they can coexist on an OES Linux server under certain conditions.
There is no migration path between Novell iFolder 2.1x and iFolder 3.x.
The iFolder client software for these two servers are also separate applications that can coexist on the same workstation; however, you should not attempt to convert the iFolder folder from a previous version of iFolder to an iFolder folder to be managed by iFolder 3.x.
For additional information on iFolder 3.x coexistence
and migration, see Coexistence
and Migration Issues
in the Novell iFolder
3.x Administration Guide.
NetStorage on Linux offers connectivity to storage locations using the CIFS/SMB, NCP, and SSH protocols. NetWare uses only NCP.
Because NetStorage is a service that facilitates access to file services in various locations but doesn't actually store files, there are no coexistence or migration issues to consider.
For more information, see Access
and File
Services
in the Novell OES Planning and Implementation
Guide.
Samba is a Linux-only solution. NetWare has NFAP to provide similar functionality.
For more information, see Access
and File
Services
in the Novell OES Planning and Implementation
Guide.
Print services constitute another fundamental network component. Users need to be able to print to shared printers attached to the network. Administrators can facilitate printing for users by making it easy to locate nearby printers, install the proper print drivers, and connect to the printer.
OES includes Novell iPrint, a powerful and easy-to-implement printing solution that provides print-anywhere functionaity to network users. iPrint lets Windows, Linux, and Macintosh users quickly locate network printers using their Web browser, easily install and configure a located printer using their native printer installation method, and print to installed printers from any location using an IP connection.
For more information about iPrint in general, see the OES iPrint Administration Guide for NetWare or the OES iPrint Administration Guide for Linux.
For more information about planning for iPrint, see Print
Services
in the Novell OES Planning and
Implementation Guide.
For information on upgrading from NetWare queue-based printing,
Novell Distributed Print Services™ (NDPS®), or
previous versions of iPrint, see Installing
iPrint Software
in the OES
iPrint Administration Guide for NetWare.
If you select iPrint during the OES for Linux server installation, the iPrint software components are automatically installed on the server. While the Common UNIX Printing System (CUPS) software is also installed with SLES 9, CUPS is disabled to avoid port 631 conflicts.
For more information on configuring iPrint on OES for Linux,
see Setting
Up iPrint on Your Server
in the OES iPrint
Administration Guide for Linux.
In OES SP2, migrating iPrint services from a NetWare server
to an OES Linux server is supported in Server Consolidation Utility
4.11, which is included in the Novell Server Consolidation and Migration
Toolkit. For more information, see Migrating
iPrint Printers and Print Managers from NetWare to Linux
in
the Novell Server Consolidation and Migration Toolkit
1.1 Administration Guide.
The ability to effectively manage servers and network resources is another key service. All network operating systems come with a suite of utilities to help administrators maintain the system in peak working condition.
Network management can be divided into two categories: presentation and instrumentation. Presentation includes the utilities and interfaces that are provided to manage the system. Instrumentation defines the types of information and alerts that can be passed on to a standards-based management tool.
At the presentation level, OES includes Novell iManager 2.6 as a cross-platform utility for general system management and Novell Remote Manager (NRM) for low-level, node-specific management.
At the instrumentation level, Novell provides Simple Network Management Protocol (SNMP)-based instrumentation and proprietary instrumentation for NetWare. SNMP support is installed with eDirectory.
With OES, Novell is embracing a new strategy to reduce the level of complexity associated with consolidating network management tasks across disparate systems. The strategy is based on OES and adds Common Information Model (CIM)-based instrumentation for NetWare and Linux in an effort to move away from the proprietary instrumentation. iManager 2.6 supports CIM-based plug-ins to present the management information.
Novell iManager 2.6 is an extensible Web-based network management console that supports both OES NetWare and OES Linux servers. Through various plug-ins, iManager can configure and manage OES network services. It also manages eDirectory schema, partitions, and replicas, as well as users, groups, and other objects. Through Role-Based Services (RBS), you can delegate iManager administration tasks to other users.
Novell Remote Manager (NRM) is a Web-based tool for low-level, node-specific management. With NRM, you can manage OES servers from a remote location, monitor a server's health, change the server configuration, and perform diagnostic and debugging tasks.
RconsoleJ is a Java*-based tool that lets you access NetWare servers remotely and run server utilities from a workstation.
For additional information, see Coexistence
and Migration
in the Remote Server Management
for NetWare Administration Guide for OES.
Health Monitoring Services let you monitor the health of NetWare or Linux servers. Among the various aspects of server health you can monitor are memory, operating system, processes/threads, network, and CPU. Color-coded icons (in green, yellow, and red) indicate whether your servers meet performance standards.
Health Monitoring Services use a CIM Object Manager provided by the Open Web-Based Enterprise Management (OpenWBEM) initiative. For more information about OpenWBEM, visit the DMTF Web site.
The preceding list of OES management tools is by no means comprehensive. Novell includes many other tools to help you manage everything in your network.
Wherever possible, Novell provides cross-platform tools that can be used to manage both OES NetWare and Linux services. However, some of the tools are service specific or platform specific and are for managing only NetWare or only Linux servers.
For a complete listing and description of the management tools
and interfaces available in OES, see Overview
of Management Tools and Interfaces
in the Novell
OES Planning and Implementation Guide.
Although iManager is written to function on either NetWare or Linux, not all of the plug-in modules are present in the OES Linux environment. Some plug-in modules present information unique to the NetWare environment and have no equivalent in the Linux environment.
For information about migrating from iManager 1.5.x and upgrading
from iManager 2.0.x, see Upgrading
to iManager 2.5
in the Novell iManager
2.5 Administration Guide.
NRM is available on both OES NetWare and Linux platforms. However, due to the inherent differences between the two operating systems, NRM on Linux doesn't include all the functionality of NRM on NetWare.
For additional information on NRM for NetWare, see Coexistence
and Migration
in the Novell Remote Manager
for NetWare Administration Guide for OES.
For additional information on NRM for Linux, see Coexistence
and Migration
in the Novell Remote Manager
Administration Guide for Linux.
Health Monitoring Services is a new service in OES. For robust monitoring, OES NetWare and OES Linux servers must be running the OpenWBEM CIMOM (owcimomd) module. Otherwise, the servers can report only a Simple Server Status (up or down).
For additional information, see Coexistence
and Migration
in the Health Monitoring
Services Administration Guide for OES.
The implementation of OpenWBEM and CIMOM in OES represents the first release of these services by Novell. In this release, you can only collect data and do some analysis. When these services are fully implemented, you will be able to gather data, analyze it, configure thresholds, set up system alerts, and perform any corrective actions needed.
For additional information, see Coexistence
and Migration
in the OpenWBEM Services Administration
Guide for OES.
Web and application services support the creation and deployment of Web sites and Web applications. More and more applications are being developed to the Web services model to leverage the widespread availability of Internet-based protocols and tools.
With the proper Web components in place, a server can host dynamic Web sites where the content changes according to selections made by the user. You can also run any of the hundreds of free Web applications that can be downloaded from the Internet. Web and application services make it easy to build your own dynamic Web content and create customized Web database applications.
Apache is the most popular Web server in use on the World Wide Web today. OES includes the Apache Web Server 2.0 for both NetWare and Linux. This serves as the foundation Web server upon which you can build Web sites and host Web applications for use in your business.
OES also includes a Jakarta-Tomcat servlet container for both NetWare and Linux. Tomcat is used to run basic Java servlet and Java Server Pages (JSP) applications on either operating system platform. Tomcat 4 is the default version for the administrative instance on both platforms. For Web application development, OES also includes Tomcat 5 for both NetWare and Linux, which implements the Java Servlet 2.4 and JSP 2.0 specifications.
OES includes the open source MySQL* database server on both the NetWare and Linux platforms. When combined with a Web application and a Web server, MySQL is a very reliable and scalable database for use in hosting eCommerce and business-to-business Web applications.
NOTE:The more powerful PostgreSQL database server comes with SLES 9. It has been ported to the NetWare platform as well and is available separately as open source software.
The scripting technologies integrated with OES for both NetWare and Linux include industry standard Perl (Practical Extraction and Report Language) and PHP (PHP: Hypertext Preprocessor). These are powerful server-side scripting languages commonly used by Web programmers to create scripts for Web servers and to access Web databases.
OES NetWare includes additional scripting technologies that simplify the task of developing NetWare-based applications. They include Novell Script for NetWare (NSN), Universal Component System (UCS), and Novell ScriptPages (NSP).
The Java 2 Platform, Enterprise Edition (J2EE*) is a widely used environment for developing large-scale Web applications. OES offers a choice of J2EE-certified application servers: JBoss* and the Novell exteNd™ Application Server. JBoss is bundled with SLES 9, while the Novell exteNd Application Server is available with OES NetWare.
OES inclues the Novell QuickFinder Server on both the NetWare and Linux platforms. QuickFinder lets you add search and print functionality to any Web site or internal intranet. It can index and find matches within a wide variety of data types.
QuickFinder replaces the NetWare Web Search Server that is available in NetWare 6.5 SP3 and earlier versions of NetWare 6.
The Web and application services available in OES can be deployed in a variety of combinations. Their availability on both NetWare and Linux platforms makes it easy to mix and match according to your network's needs. In most cases, you can also migrate existing installations on NetWare to OES Linux.
For the most part, Apache is functionally the same on both NetWare and Linux. Novell made some enhancements in Apache for NetWare to allow for directory-enabled administration.
OES for NetWare installs an administration instance of Apache that is used by Web-based management tools such as Novell Remote Manager.
For additional coexistence and migration information on the
Apache Web server, see Apache
Coexistence and Migration Issues
in the Apache
Web Server for NetWare Administration Guide for OES.
OES for NetWare installs an administration instance of Tomcat that is used by Web-based management tools such as Novell Remote Manager.
For additional coexistence and migration information on the
Tomcat servlet container, see Tomcat
Coexistence and Migration Issues
in the Tomcat
for NetWare Administration Guide for OES.
QuickFinder and NetWare Web Search Server cannot coexist on the same NetWare server. However, you can have as many instances of QuickFinder and NetWare Web Search Server as you need on separate servers.
When indexing a file system, the QuickFinder engine indexes only what it has rights to see. On NetWare, it has full access to all mounted volumes. On Linux, it has rights to only the files that the novellwww users in the wwwgroup have rights to see.
When you upgrade a NetWare server running NetWare Web Search Server to OES SP2 for NetWare (NetWare 6.5 SP5), Web Search Server is automatically upgraded to QuickFinder. The upgrade identifies all the configuration settings and indexes from Web Search and enables them to be used by QuickFinder.
For additional coexistence and migration information on QuickFinder,
see Coexistence
and Migration Issues
in the QuickFinder
Server 4.2 Administration Guide.
OES provides support for running a variety of open source software programs.
Both OES for Linux and OES for NetWare provide a platform for running the thousands of AMP (Apache/Tomcat, MySQL, Perl/PHP) programs that are available in the open source community.
For more information, see the Web and Application Services Overview for OES.
OpenSSH is an open source technology that has been integrated with OES for NetWare. It provides a secure shell that lets users who are Admin equivalent gain remote access to servers on the network and copy files and directories between those servers using SSH utilities.
Novell’s implementation is based on OpenSSH version 3.6p1. It uses encryption provided by NICI technology rather than SSL to implement 128-bit (and stronger) encryption. Because OpenSSH encrypts all traffic (including passwords), it effectively eliminates eavesdropping, connection hijacking, and other network-level attacks that have plagued users of Telnet, Rlogin, FTP, and similar utilities.
For more information, see the OpenSSH Administration Guide.
One of a network administrator’s biggest challenges is keeping installed software up to date on all servers and workstations.
For OES, Novell has laid the foundation for a common software distribution and patch management facility for both NetWare and Linux servers.
BASH (Bourne Again Shell) is a versatile Linux utility that has been ported to NetWare. It lets you perform a subset of the BASH commands available on Linux.
For more information, see BASH
in
the Utilities Reference for OES.
SLES 9 uses RPM (RPM Package Manager) to manage software packages. Its main programs are rpm and rpmbuild. The powerful RPM database can be queried by users, system administrators, and package builders for detailed information about the installed software.
For OES, RPM has been ported to NetWare and runs as a NetWare Loadable Module on the server. RPM for NetWare works the same as RPM on Linux, with a few minor differences due to limitations in the BASH command on NetWare.
In OES SP2, not all of the products that can be installed on OES NetWare servers support RPM. Those that are not installable through RPM store information in the products.dat file. For interim compatibility, the information in products.dat is synchronized with the RPM database.
ZENworks® Linux Management 6.6.x supports software distribution via RPM on the NetWare platform. For more information, see the ZENworks Linux Management Administration Guide.
Red Carpet® Daemon (RCD) is a software distribution mechanism developed for Linux. RCD performs software management functions on behalf of the rc software management tool, which allows remote software management. RCD can update, install, and remove software from local files or from specified download servers, and can handle interactions with the system's package database (such as verification and searching).
For OES, RCD has been ported to NetWare and runs as a NetWare Loadable Module on the server. RCD works the same on both Linux and NetWare.
RCD for NetWare is not loaded by default in OES. You must either load rcd.nlm manually at the server console or add the command to the server's autoexec.ncf file.
You can set up users with the rcdpass command and control the software distribution process using the rug command line utility.
Rug is a patch management utility developed for Linux. It is the command line complement to RCD and works with the rcd daemon to install, update, and remove software according to the commands you give it.
For OES, rug has been ported to NetWare and runs as a NetWare Loadable Module on the server. Rug works the same on both Linux and NetWare.
You can run rug from the BASH shell or from the NetWare server console. Screen output for rug is displayed in a new proprietary screen.
For registered OES customers, Novell has set up an upgrade server at http://update.novell.com to deliver patches to subscriber channels. You can access this server to install OES patches that apply to NetWare, but not SLES 9 patches.
Licensing provides a way for software manufacturers to enforce compliance with end user license agreements (EULAs). Licensing services monitor license usage and prevent customers from exceeding the number of licenses they purchased.
When you install or upgrade NetWare servers, the installation software automatically installs Novell Licensing Services (NLS). Either during the installation or afterwards using iManager, you can install and manage license certificates in your eDirectory tree. You must have a valid license/key file pair (*.nlf and *.nfk).
For more information, see How
Novell Licensing Services Works
in the OES
Licensing Services Administration Guide for NetWare.
Installing OES for Linux doesn’t require license
files. Nevertheless, you are required to accept a EULA, which defines
your rights to use OES on the Linux platform. For more information,
see Licensing
in
the Novell OES Planning and Implementation Guide.