If you are installing an OES 11 SP3 server into an eDirectory tree that is earlier than eDirectory 8.6, do the following before installing your first OES server in an existing NetWare tree:
Extend the schema by using Deployment Manager. See Schema Update
in the NW65 SP8: Installation Guide.
Ensure that the schema is synchronized throughout the tree from root:
Enter the following commands at the System Console prompt of the NetWare server with the Master of root:
Toggle to the Directory Services screen and look for the message All Processed = YES.
On each server that holds a Master of a partition, enter the following commands at the System Console prompt:
Toggle to the Directory Services screen and look for the message All Processed = YES.
If you are installing into an eDirectory tree that is using a NetWare server to supply LDAP, you should upgrade the LDAP server that the OES installation will communicate with to NetWare 6.5 SP3 or later. A server running NetWare 6.5 SP2 or earlier will probably abend.
Having NSS volumes on OES servers requires certain system-level modifications, most of which are automatic. For more information, see System User and Group Management in OES 11 SP3
in the OES 11 SP3: Planning and Implementation Guide.
By default, certain OES services, such as NetStorage, rely on a background Novell service named X-Tier.
To run on an OES server, X-Tier requires two system-created users (named novlxsrvd and novlxregd) and one system-created group that the users belong to (named novlxtier).
The two X-Tier users mentioned above, and their group, are created on the local system when X-Tier is installed. For example, they are created when you install NetStorage, and their respective UIDs and GID are used to establish ownership of the service’s directories and files.
For NetStorage to run, these X-Tier users and group must be able to read data on all volume types that exist on the OES server.
As long as the server has only Linux traditional file systems, such as Ext3 and Reiser, NetStorage runs well.
However, if the server has NSS volumes, an additional requirement is introduced. NSS data can only be accessed by eDirectory users. Consequently, the local X-Tier users can’t access NSS data, and NetStorage can’t run properly.
When NSS volumes are created on the server, the two X-Tier system users and their group are moved to eDirectory and enabled for Linux User Management (LUM). See Linux User Management: Access to Linux for eDirectory Users
in the OES 11 SP3: Planning and Implementation Guide.
After the move to eDirectory, they can function as both eDirectory and POSIX users, and they no longer exist on the local system.
If your eDirectory tree has ever contained an OES 1 Linux server with NSS and LUM installed, do the following on each server (including OES 2) that has NSS and LUM installed:
Log in as root and open a terminal prompt. Then enter the following commands:
id novlxregd
id novlxsrvd
The standardized X-Tier IDs are UID 81 for novlxregd, UID 82 for novlxsrvd, and GID 81 for novlxtier.
If you see the following ID information, the X-Tier IDs are standardized and you can move to the next server:
uid=81(novlxregd) gid=81(novlxtier) groups=81(novlxtier) uid=82(novlxsrvd) gid=81(novlxtier) groups=81(novlxtier),8(www)
If you see different IDs than those listed above, such as 101, 102, 103, etc., record the numbers for both X-Tier users and the novlxtier group. You need these IDs to standardize the IDs on the server.
Download the following script file:
Customize the template file by replacing the variables in angle brackets (<>) as follows:
<server_name>: The name of the server object in eDirectory.
Replace this variable with the server name.
For example, if the server name is myserver, replace <server_name> with myserver so that the line in the settings section of the script reads
server=myserver
<context>: The context of the X-Tier user and group objects.
Replace this variable with the fully distinguished name of the context where the objects reside.
For example, if the objects are an Organizational Unit object named servers, replace ou=servers,o=company.
<admin fdn>: The full context of an eDirectory admin user, such as the Tree Admin, who has rights to modify the X-Tier user and group objects.
Replace this variable with the admin name and context, specified with comma-delimited syntax.
For example, if the tree admin is in an Organization container named company, the full context is cn=admin,o=company and the line in the settings section of the script reads
admin_fdn="cn=admin,o=company"
<novlxregd_uid>: The UID that the system assigned to the local novlxregd user. It might or might not be the same on each server, depending on whether the nssid.sh script ran successfully.
Replace this variable with the UID reported for the novlxregd user on this server as listed when you ran the commands in Step 1.
In the example script, the original UID is 101. It is changed to 81 in the third line of the script. The sixth line changes the UID on all of the files and directories on the server that are owned by the novlxregd user from 101 to 81.
<novlxsrvd_uid>: The UID that the system assigned to the local novlxsrvd user. It might not be the same on each server, depending on whether the nssid.sh script ran successfully.
Replace this variable with the UID reported for the novlxsrvd user on this server as listed when you ran the commands in Step 1.
In the example script, the original UID is 103. It is changed to 82 in the fourth line of the script. The seventh line changes the UID on all of the files and directories on the server that are owned by the novlxsrvd user from 103 to 82.
<novlxtier_gid>: The GID that the system assigned to the local novlxtier group. It might not be the same on each server, depending on whether the nssid.sh script ran successfully.
Replace this variable with the GID reported for the novlxtier group on this server as listed when you ran the commands in Step 1.
In the example script, the original GID is 101. It is changed to 81 in the second line of the script. The sixth and seventh lines change the GID from 101 to 81 for all of the files and directories on the server that are owned by the novlxtier group.
Make the script executable and run it on the server.
IMPORTANT:Changes to the X-Tier files are not reported on the terminal.
Error messages are reported, but you can safely ignore them. The script scans the entire file system, and some files are locked because the system is running.
Repeat from Step 1 for each of the other servers in the same context.
An eDirectory tree must have its schema extended to accommodate OES 11 servers and services as explained in the following sections:
Only an administrator with the Supervisor right at the root of an eDirectory tree can extend the tree’s schema.
The following service schema extensions are included with OES 11 SP3.
A single asterisk (*) indicates a service that is either required for OES 11 SP3 servers or for the default services that are installed on every OES 11 SP3 server.
Unmarked extensions are implemented the first time their respective services are installed, unless the schema was previously extended using another method, such as the YaST plug-in (see Using the YaST Plug-In to Extend the Schema).
NetIQ Directory Services*
Novell Linux User Management (LUM)*
Novell iPrint Services
Novell DHCP Services
Novell DNS Services
Novell NCP Server
Novell NetStorage
Novell Storage Services (NSS)
Novell SMS*
Novell iFolder
Novell Domain Services for Windows
NetIQ NMAS*
Novell CIFS
Novell Clustering
Novell Cluster Services requires you to extend the schema manually. Follow the instructions in Installing, Configuring, and Repairing Novell Cluster Services
in the OES 11 SP3: Novell Cluster Services for Linux Administration Guide.
Novell Remote Manager
Novell Samba
The simplest way to extend the schema for OES 11 SP3 servers is to have a tree admin install the first OES 11 SP3 server and the first instance of each OES 11 SP3 service that you plan to run on your network.
After this initial installation, you can assign subcontainer admins with the required rights to install additional servers and services. For more information on the required rights for the various OES services, see Rights Required for Subcontainer Administrators.
If you want a subcontainer admin to install the first OES 11 SP3 server or the first instance of an OES 11 SP3 service in an existing tree, and you don’t want to grant that admin the Supervisor right to the root of the tree, someone with the Supervisor right to root can extend the schema by using YaST from any of the following locations:
An OES 11 SP3 server running in another tree
Install a fully patched SLES 11 SP4 server, then install OES 11 SP3 without installing any of the services, followed by the yast2 novell-schema tool installation.
To run the Novell Schema Tool:
On the server’s desktop, click Computer and open the YaST Control Center.
Click Open Enterprise Server > Novell Schema Tool.
Depending on the installation method you used, you might be required to insert your OES 11 SP3 installation media.
On the NetIQ eDirectory Extension Utility page, specify the information for an eDirectory server with a Read/Write replica of the Root partition.
Be sure to provide the correct information to authenticate as an admin user with the Supervisor right at the root of the target tree. Otherwise, the schema extension fails.
Select all of the other services you plan to run on any of the OES 11 SP3 servers in the tree.
Click Next.
The schema is extended.
The YaST2 novell-schematool utility writes the schema event messages to the /var/opt/novell/eDirectory/log/oes_schema.log file on the server where the utility is running.
If you want a subcontainer administrator to install the first instance of Novell Cluster Services in a tree, you can extend the schema by following the instructions in Installing, Configuring, and Repairing Novell Cluster Services
in the OES 11 SP3: Novell Cluster Services for Linux Administration Guide.