If you are installing an OES 2 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 2 SP3
in the OES 2 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 2 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.
On OES 1, problems occur when additional OES NetStorage servers with NSS volumes are installed in the same eDirectory container. Because the UIDs and GID are assigned by the system, unless the installation process is exactly the same for each OES 1 server, the UIDs and GID don’t match server-to-server.
When the local X-Tier UIDs and GID on subsequently installed servers don’t match the X-Tier UIDs and GID in eDirectory, NetStorage can’t access the NSS volumes on the server.
To solve the problem of mismatched Ids, the OES 1 installation program looks for X-Tier ID conflicts, and if the IDs on a newly installed server don’t match the IDs in eDirectory, the program generates a script file named nssid.sh. The OES 1 documentation instructs installers to always check for an nssid.sh file on a newly installed server, and if the file is found, to run it. The nssid.sh script synchronizes all of the X-Tier IDs with those in eDirectory.
However, this solution is only viable through the first release of OES 2.
System-level changes in SUSE Linux Enterprise Server 10 SP2 and later invalidate the nssid.sh script solution for mismatched IDs. Synchronizing the X-Tier IDs with an OES 1 installation can now cause instability in other non-OES components. Therefore, starting with OES 2 SP1, you should standardize all X-Tier IDs on existing servers before installing a new server with X-Tier-dependent services.
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 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 six 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 2 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 2 SP3.
A single asterisk (*) indicates a service that is either required for OES 2 servers or for the default services that are installed on every OES 2 server. They are implemented when the first OES 2 SP1 or later server is installed in the tree.
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).
CIFS
Directory Services*
iFolder
iPrint
DHCP
DNS
Domain Services for Windows
Linux User Management*
NCP
NCS
Novell Cluster Services requires you to extend the schema manually. Follow the instructions in Extending the eDirectory Schema to Add Cluster Objects
in the OES 2 SP3: Novell Cluster Services 1.8.8 Administration Guide for Linux.
NetStorage
NMAS*
Novell Storage Services
Storage Management Services*
The simplest way to extend the schema for OES 2 servers is to have a tree admin install the first OES 2 server and the first instance of each OES 2 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 2 server or the first instance of an OES 2 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 2 SP3 server running in another tree
An OES 2 SP3 server that was installed without any OES 2 services added (the YaST plug-in is a default OES 2 component)
or
A SLES 10 SP4 server with the yast2-novell-schematool.rpm installed. The RPM is available on the OES 2 SP3 installation media and can be launched at a terminal prompt following installation by entering yast2 novell-schematool.
To run the Novell Schema Tool:
On the server’s desktop, click and open the .
Click > .
Depending on the installation method you used, you might be required to insert your OES 2 installation media.
On the Novell 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.
If you are preparing the tree so that a subcontainer admin can install the first OES 2 SP1 or later server, select the services marked with an asterisk (*) in Which OES 2 SP3 Services Require a Schema Extension?.
Although this step is not required if the tree already has an OES 2 SP1 or later server installed, selecting the marked services won’t cause any problems.
Select all of the other services you plan to run on any of the OES 2 servers in the tree.
Click .
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 Extending the eDirectory Schema to Add Cluster Objects
in the OES 2 SP3: Novell Cluster Services 1.8.8 Administration Guide for Linux.