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 using Deployment Manager. See Schema Update
in the NW65 SP8: Installation Guide.
Ensure that the schema is synchronized throughout the tree from [ROOT] by doing the following:
Verify that schema is synchronizing out from [ROOT] by entering 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, upgrade the LDAP server that the OES installation will communicate with to the NetWare 6.5 SP3 or later software. 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 SP2
in the OES 2 SP2: 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).
These users 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 only has Linux traditional file systems, such as Ext3 and Reiser, NetStorage runs fine.
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.
Therefore, when NSS volumes are created on the server, the X-Tier users 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 SP2: 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.
Problems with OES 1 occurred when additional OES NetStorage servers with NSS volumes were installed in the same eDirectory container. Because the UIDs and GID were assigned by the system, unless the installation process was exactly the same for each OES 1 server, the UIDs and GID didn’t match server-to-server.
When the local X-Tier UIDs and GID on subsequently installed servers didn’t match the X-Tier UIDs and GID in eDirectory, NetStorage couldn’t access the NSS volumes on the server.
To solve this problem, the OES 1 installation program looked for X-Tier ID conflicts, and if the IDs on a newly installed server didn’t match the IDs in eDirectory, the program generated a script file named nssid.sh. The documentation instructed installers to always check for an nssid.sh file on a newly installed server, and if the file was found, to run it. The nssid.sh script synchronized all of the X-Tier IDs with those in eDirectory.
This solution remained viable through the first release of OES 2.
Unfortunately, system-level changes in SUSE Linux Enterprise Server 10 SP2 and later invalidate the nssid.sh script solution. 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 type 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 to standardize the IDs on the server.
Continue with Step 3.
Download the following script file:
Customize the template file by replacing the angle bracketed variables (<>) 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>: This is 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 using 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>: This is 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 gets 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>: This is the UID that the system assigned to the local novlxsrvd 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 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 gets 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>: This is the GID that the system assigned to the local novlxtier group. 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 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 gets changed to 81 in the second line of the script. The six and sevenths 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 then 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 SP2.
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 extending the schema manually. Follow the instructions in Extending the eDirectory Schema to Add Cluster Objects
in the OES 2 SP2: Novell Cluster Services 1.8.7 for Linux Administration Guide.
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, you can extend the schema using YaST from either
An OES 2 SP2 server running in another tree
An OES 2 SP2 server that was installed without any OES 2 services added (the YaST plug-in is a default OES 2 component)
or
A SLES 10 SP3 server with the yast2-novell-schematool.rpm installed. The RPM is available on the OES 2 SP2 installation media and can be launched at a terminal prompt following installation by entering yast2 novell-schematool.
To run the Novell Schema Tool, do the following:
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, enter the information for an eDirectory server with a Read/Write replica of the Root partition.
Be sure to enter the correct information to authenticate as an admin user with the Supervisor right at the [Root] of the target tree. Otherwise, the schema extension will fail.
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 SP2 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.
If you want a subcontainer administrator to install the first instance of NCS 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 SP2: Novell Cluster Services 1.8.7 for Linux Administration Guide.