• No results found

2.1 Before You Install

Before you install Novell Open Enterprise Server 2015 (OES 2015 SP1), review the following information:

“Planning Your OES 2015 SP1 Implementation” in the OES 2015 SP1: Planning and Implementation Guide

“Before You Install” in the OES 2015 SP1: Readme

2.2 Meeting All Server Software and Hardware Requirements

Before installing OES 2015 SP1, ensure that your system meets the following requirements:

 Section 2.2.1, “Server Software,” on page 15

 Section 2.2.2, “Server Hardware,” on page 16

2.2.1 Server Software

As part of the OES 2015 SP1 installation, you install SUSE Linux Enterprise Server 11 SP4.

IMPORTANT: OES 2015 SP1 services were developed and tested on a default and fully-patched SLES 11 SP4 server base.

As you install OES 2015 SP1, do not change any of the SLES 11 SP4 Base Technologies package selections, such as Java support. Doing so can cause various problems, such as the installation failing or one or more OES 2015 SP1 services not working properly.

If you are installing on an existing SLES 11 SP4 server, be sure to verify that all of the default SLES 11 SP4 components are installed before attempting to install OES 2015 SP1 services.

2.2.2 Server Hardware

Table 2-1 Server Hardware Requirements

NOTE: The RAM and disk space amounts shown here are for system components only. The OES service components that you install might require additional RAM and disk space.

System Component Minimum Requirements Recommended Requirements

Computer Any server-class computer that

runs with AMD64 or Intel*

EM64T processors.

IMPORTANT: OES 2015 SP1 is an add-on product to SLES 11 SP4; it only runs on x86_64.

Other processors that are supported by SLES 11 SP4, such as Itanium (IA64) and Intel x86(IA32), are not supported for running OES services.

NOTE: Services such as iManager, SMS, and NRM run in 32-bit mode on a 64-bit platform.

Memory 2 GB of RAM 4 GB of RAM for the base system. Additional RAM

might be required depending on which OES components are selected and how they are used.

Free Disk Space 10 GB of available, unpartitioned disk space

16 GB of available, unpartitioned disk space.

Additional disk space might be required, depending on which OES components are selected and how they are used.

DVD Drive DVD drive if installing from physical media

DVD drive if installing from physical media

Hard Drive 20 GB

Network Board Ethernet 100 Mbps

IP address One static IP address

Subnet mask Default gateway

Mouse N/A USB or PS/2

Server computer BIOS Using a DVD installation source, prepare the BIOS on your server computer so that it boots from the DVD drive first.

Video Card and Monitor 1024 X 768 resolution or higher with a minimum color depth of 8 bits (256 colors)

Although it is technically possible to run the ncurses installation at a lower resolution, some informational messages aren’t displayed because text strings don’t wrap to the constraints of the window.

Be sure to complete the planning instructions in the OES 2015 SP1: Planning and Implementation Guide for each component that you install.

2.3 NetIQ eDirectory Rights Needed for Installing OES

 Section 2.3.1, “Rights to Install the First OES Server in a Tree,” on page 17

 Section 2.3.2, “Rights to Install the First Three Servers in an eDirectory Tree,” on page 17

 Section 2.3.3, “Rights to Install the First Three Servers in any eDirectory Partition,” on page 17

2.3.1 Rights to Install the First OES Server in a Tree

To install an OES server in a tree, you must have rights to extend the schema, meaning that you need Supervisor rights to the root of the tree.

You can extend the schema by using the Novell Schema Tool in YaST or by having a user with Supervisor rights to the root of the eDirectory tree install the first OES server and the first instance of each OES service that will be used into the tree. For more information, see Section 2.5.4, “Extending the Schema,” on page 25.

2.3.2 Rights to Install the First Three Servers in an eDirectory Tree

If you are installing the server into a new tree, the Admin user that is created during the OES installation has full rights to the root of the tree. Using the account for user Admin allows the installer to extend the eDirectory schema for OES as necessary. To install the first OES server in an

eDirectory tree, you must have the Supervisor right at the root of the eDirectory tree.

2.3.3 Rights to Install the First Three Servers in any eDirectory Partition

By default, the first three servers installed in an eDirectory partition automatically receive a replica of that partition. To install a server into a partition that does not already contain three replica servers, the user must have either the Supervisor right at the root of the tree or the Supervisor right to the container in which the server holding the partition resides.

2.4 Installing and Configuring OES as a Subcontainer Administrator

IMPORTANT: The information explained in Section 2.3, “NetIQ eDirectory Rights Needed for Installing OES,” on page 17 is prerequisite to the information contained in this section.

This section outlines the required eDirectory rights and explains how a subcontainer administrator approaches various installation tasks.

 Section 2.4.1, “Rights Required for Subcontainer Administrators,” on page 18

 Section 2.4.2, “Providing Required Rights to the Subcontainer Administrator for Installing and Managing Samba,” on page 20

 Section 2.4.3, “Starting a New Installation as a Subcontainer Administrator,” on page 22

 Section 2.4.4, “Adding/Configuring OES Services as a Different Administrator,” on page 22

2.4.1 Rights Required for Subcontainer Administrators

For security reasons, you might want to create one or more subcontainer administrators

(administrators that are in a container that is subordinate to the container that user Admin is in) with sufficient rights to install additional OES servers, without granting them full rights to the entire tree.

A subcontainer administrator needs the rights listed in Table 2-2 to install an OES server into the tree.

These rights are typically granted by placing all administrative users in a Group or Role in eDirectory, and then assigning the rights to the Group or Role. Sample steps for assigning the rights to a single subcontainer administrator are provided as a general guide.

Table 2-2 Subcontainer Administrator Rights Needed to Install

Rights Needed Sample Steps to Follow

Supervisor right to itself 1. In iManager, click View Objects > the Browse tab, then browse to and select the subcontainer administrator.

2. Click the administrator object, then select Modify Trustees.

3. Click the Assigned Rights link for the administrator object.

4. For the [All Attributes Rights] property, select Supervisor, then click Done

> OK.

Supervisor right to the container where the server will be installed

1. Browse to the container where the subcontainer administrator will install the server.

2. Click the container object and select Modify Trustees.

3. Click Add Trustee, browse to and select the subcontainer administrator, then click OK.

4. Click the Assigned Rights link for the administrator object.

5. For the [All Attributes Rights] and [Entry rights] properties, select Supervisor, then click Done > OK > OK.

Supervisor right to the W0 object located inside the KAP object in the Security container

1. Browse to Security > KAP.

2. In KAP, click W0 and select Modify Trustees.

3. Click Add Trustee, browse to and select the subcontainer administrator, then click OK.

4. Click the Assigned Rights link for the administrator object.

5. For the [All Attributes Rights] and [Entry rights] properties, select Supervisor, then click Done > OK > OK.

Supervisor right to the Security container when installing the NMAS login methods

If the subcontainer administrator will install the NMAS login methods:

1. Browse to and select Security.

2. Select Modify Trustees.

3. Click Add Trustee, browse to and select the subcontainer administrator, then click OK.

4. Click the Assigned Rights link for the administrator object.

5. For the [All Attributes Rights] and [Entry rights] properties, select Supervisor, then click Done > OK > OK.

Create right to its own container (context)

1. Browse to and select the container where you created the subcontainer administrator.

2. Select Modify Trustees.

3. Click Add Trustee, browse to and select the subcontainer administrator, then click OK.

4. Click the Assigned Rights link for the administrator object.

5. For the [Entry Rights] property, select Create, then click Done > OK > OK.

Create right to the container where the UNIX Config object is located

1. Browse to and select the container where the UNIX Config object is located. By default, this is the Organization object.

2. Select Modify Trustees.

3. Click Add Trustee, browse to and select the subcontainer administrator, then click OK.

4. Click the Assigned Rights link for the administrator object.

5. For the [Entry Rights] property, select Create, then click Done > OK > OK.

Read right to the Security container object for the eDirectory tree

This is not needed if the Supervisor right was assigned because of NMAS.

If the subcontainer administrator won’t install the NMAS login methods, do the following:

1. Browse to and select Security.

2. Select Modify Trustees.

3. Click Add Trustee, browse to and select the subcontainer administrator, then click OK.

4. Click the Assigned Rights link for the administrator object.

5. For the [All Attributes Rights] property, select Read, then click Done > OK

> OK.

Read right to the

NDSPKI:Private Key attribute on the Organizational CA object (located in the Security container)

1. Browse to Security and select the Organizational CA object.

2. Select Modify Trustees.

3. Click Add Trustee, browse to and select the subcontainer administrator, then click OK.

4. Click the Assigned Rights link for the administrator object.

5. Click the Add Property button.

6. Select NDSPKI:Private Key, then click OK.

The Read right should be automatically assigned.

7. Click Done > OK > OK.

Read and Write rights to the UNIX Config object

1. Browse to and select the UNIX Config object.

2. Select Modify Trustees.

3. Click Add Trustee, browse to and select the subcontainer administrator, then click OK.

4. Click the Assigned Rights link for the administrator object.

5. For the [All Attributes Rights] property, select Write (Read is already selected), then click Done > OK > OK.

Rights Needed Sample Steps to Follow

When you install DNS/DHCP into an existing tree with DNS/DHCP, see the following additional guidelines:

 For DNS, see “eDirectory Permissions ” in the OES 2015 SP1: DNS/DHCP Services for Linux Administration Guide.

 For DHCP, see “eDirectory Permissions ” in the OES 2015 SP1: DNS/DHCP Services for Linux Administration Guide.

2.4.2 Providing Required Rights to the Subcontainer Administrator for Installing and Managing Samba

Prior to installing any new OES Samba server in a tree, ensure that you provide supervisor rights to the subcontainer administrator for the location mentioned in Table 2-3.

Table 2-3 Subcontainer Administrator Rights Needed to Manage Samba Write right to the [All Attribute

Rights] property for the admingroup object

1. Browse to and select the admingroup object.

2. Select Modify Trustees.

3. Click Add Trustee, browse to and select the subcontainer administrator, then click OK.

4. Click the Assigned Rights link for the administrator object.

5. For the [All Attributes Rights] property, select Write (Compare and Read are already selected), then click Done > OK > OK.

Rights Needed Sample Steps to Follow

Rights Needed Sample Steps to Follow

Supervisor rights to the container where the Linux workstation object will be located

1. In iManager, click View Objects, then browse and select the container where the OES Samba server will be installed.

2. Click Actions > Modify Trustees.

3. On the Modify Trustees page, click Assigned Rights next to the trustee name for which you want to modify rights.

4. Click the desired container admin object to add it to the Selected Objects section.

5. Click OK.

6. Select Property Name rights (All Attribute Rights and Entry Rights) and assign Supervisor rights, then click Done.

Supervisor rights to the container where the Unix config object will be located

1. On the Novell iManager, click View Objects, then in the Tree, browse and select the container where Unix Config object is located.

2. Select the Unix Config object, then click Actions

> Modify trustees.

3. On the Modify Trustees page, click Assigned Rights next to the trustee name for which you want to modify rights.

4. Click the desired container admin object to add it to the Selected Objects section.

5. Click OK.

6. Select Property Name rights (All Attribute Rights and Entry Rights) and assign Supervisor rights, then click Done.

Supervisor rights to the container where the Samba/

LDAP base context will be located

1. On the Novell iManager, click View Objects, then in the Tree, browse and select the container where the Samba/LDAP base context will reside.

2. Select the Current Level tree object, then click Actions > Modify trustees.

3. On the Modify Trustees page, click Assigned Rights next to the trustee name for which you want to modify rights.

4. Click the desired container admin object to add it to the Selected Objects section.

5. Click OK.

6. Select Property Name rights (All Attribute Rights and Entry Rights) and assign Supervisor rights, then click Done.

Supervisor rights to the container where the Samba proxy user will be installed

1. On the Novell iManager, click View Objects, then in the Tree, browse and select the container where the Samba proxy user context will be installed.

2. Select the Samba proxy object, then click Actions

> Modify trustees.

3. On the Modify Trustees page, click Assigned Rights next to the trustee name for which you want to modify rights.

4. Click the desired container admin object to add it to the Selected Objects section.

5. Click OK.

6. Select Property Name rights (All Attribute Rights and Entry Rights) and assign Supervisor rights, then click Done.

Rights Needed Sample Steps to Follow

2.4.3 Starting a New Installation as a Subcontainer Administrator

You can install a new OES server into an existing tree as a subcontainer administrator if you have the following:

 The rights described in “Rights Required for Subcontainer Administrators” on page 18

 The rights described in “Providing Required Rights to the Subcontainer Administrator for Installing and Managing Samba” on page 20

 (If applicable) The rights described for the server installations in “NetIQ eDirectory Rights Needed for Installing OES” on page 17

When you reach the eDirectory Configuration - Existing Tree page, enter your fully distinguished name (FDN) and password. After verifying your credentials, the installation proceeds normally.

2.4.4 Adding/Configuring OES Services as a Different Administrator

To add or configure OES services on an OES server that another administrator installed, see “Adding/

Configuring OES Services on a Server That Another Administrator Installed” on page 114.

2.5 Preparing eDirectory for OES 2015 SP1

 Section 2.5.1, “If Your Directory Tree Is Earlier than eDirectory 8.6,” on page 22

 Section 2.5.2, “If Your LDAP Server Is Running NetWare 6.5 SP2 or Earlier,” on page 23

 Section 2.5.3, “If Your Tree Has Ever Contained an OES 1 Linux Server with LUM and NSS Installed,” on page 23

 Section 2.5.4, “Extending the Schema,” on page 25

2.5.1 If Your Directory Tree Is Earlier than eDirectory 8.6

If you are installing an OES 2015 SP1 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:

1 Extend the schema by using Deployment Manager. See “Schema Update” in the NW65 SP8:

Installation Guide.

2 Ensure that the schema is synchronized throughout the tree from root:

2a Enter the following commands at the System Console prompt of the NetWare server with the Master of root:

2b Toggle to the Directory Services screen and look for the message All Processed = YES.

2c On each server that holds a Master of a partition, enter the following commands at the System Console prompt:

set DSTRACE=off

set DSTRACE=nodebug set DSTRACE=+Schema set DSTRACE=*SS

2d Toggle to the Directory Services screen and look for the message All Processed = YES.

2.5.2 If Your LDAP Server Is Running NetWare 6.5 SP2 or Earlier

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.

2.5.3 If Your Tree Has Ever Contained an OES 1 Linux Server with LUM and NSS Installed

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 2015 SP1” in the OES 2015 SP1: Planning and Implementation Guide.

 “NetStorage, X-Tier, and Their System Users” on page 23

 “An NSS Complication” on page 23

 “eDirectory Solves the Basic Problem” on page 24

 “The OES 2 Solution: Standardizing the UIDs on all OES servers” on page 24

NetStorage, X-Tier, and Their System Users

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).

An NSS Complication

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.

eDirectory Solves the Basic Problem

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 2015 SP1: 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.

The OES 2 Solution: Standardizing the UIDs on all OES servers

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:

1 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.

2 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.

3 Download the following script file:

 fix_xtier_ids.sh (http://www.novell.com/documentation/oes2/scripts/fix_xtier_ids.sh) 4 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.

 <context>: The context of the X-Tier user and group objects.