Posted: 2 Mar 2005
The Deployment team at Novell has begun creating a series of
papers explaining exactly how they have deployed Open Enterprise Server in some
very specific scenarios. Here's how they did it in a NetWare 4.11/4.2 tree. If
you have anything to add to this piece, you can visit the Cool Wiki and edit
away on the wiki version of this piece. Eventually we'll incorporate the wiki
edits into the Vault version of this Beige Paper.
Introduction
Novell supports two different kernels with Open Enterprise
Server (OES). They offer a Linux version based on the SUSE LINUX Enterprise
Server9 SP1, and a NetWare version based on NetWare 6.5 SP3.
Because NetWare 4.x servers used the IPX protocol stack and
did not support the LDAP server, OES NetWare must first be deployed in an
all-NW4.x tree before deploying OES Linux, to get infrastructure sufficiently in
place to deploy OES Linux. If the tree contains NW51sp8 or later versions of
NetWare, OES Linux can be deployed into the tree as long as the Deployment
Manager steps are run.
Novell does not support IPX or SCMD running on Linux. Once the
environment is sufficiently upgraded to OES NetWare and IP, OES Linux can be
installed into the environment. This document describes one implementation
scenario.
Here are the steps that were taken to bring a 4.11.2 (sp9)
tree up to OES NetWare. There may be various ways to do this, and hopefully this
example will help others who may have similar environments.
Preparing the Network and Servers
Patch all NW4.11 and NW4.2 to Support Pack 9. NetWare 4.10 is
not supported in a mixed tree with NW6.5, so any servers using that version
should be upgraded or removed from the tree.
Deploying OES into the 4.2.11sp9 tree
Run Deployment Manager Steps
Step 1
Make sure your NetWare client has been installed with IPX
support. The default client install will not install IPX. Run Deployment Manager
on a Windows workstation from root of 65OS CD, and select "Search tree for
eDirectoryNDS versions". Update NDS versions on the entire tree.
As an alternative method to running this wizard, these files
can be copied manually from NIPRODUCTSNDSUPDATE411, then just unload and
reload ds.nlm.
Step 2
Next run the PPrepare for New eDirectory" wizard from the
Deployment Manager.
Once this is finished, verify your servers have 6.21 NDS
loaded and SGuid. Do a "modules ds.nlm" at the console to check.
Step 3
Now if this is to be the first NW6.5 server inserted into the
tree, it is a good idea to update your schema and let it synchronize throughout
the tree. You can use the Schema Update wizard found in the Deployment Manager.
Then run the DSTRACE steps found in TID
10066604.
Don't forget this!
Warning - these next two steps are
very important. Please do not forget to do this on an all 4.x tree!
- Run Dsrepair Adv Options Global Schema Operations | Post NetWare5
Schema Update on Master server.
- Then run the Rebuild Operational Schema on the Master replica server from
the local DSREPAIR option.
Make sure Replica ring is synchronized and NDS is healthy.
InstallingUpgrading OES Servers
As we conducted this scenario in the lab, we next installed a
new NW6.5sp3OES server into the existing tree, and it installed successfully.
NW6.5sp3 and OES NetWare are installed from the same CD. During the product
selection phase you will be given a choice of which one to install based on if
you want the newer versions of iManager, Quick Finder (formerly
Web Search) or Virtual Office.
Next a NW4.2 RW replica of root server was upgraded to
NW6.5sp3 via the down-server upgrade. This can be done in two ways:
- Method #1: using the IPX client and attaching to a server hosting the
NW65sp3 files. In which case a drive is mapped to the build location and
Install /Upgrade is launched.
- Method #2 : booting off the NW65sp3 CD and pressing a key to intervene
during the initial CD boot, then pressing P, and then entering [inst:
/upgrade] hit enter, then hitting I to launch the down-server upgrade.
Next the Master of root was upgraded using the same method.
Next a down-server upgrade was performed on the last replica
of root a 4.11sp9 server. These servers were all upgraded successfully.
Novell recommends using the Migration
Wizard to migrate the 4.x server to NW6.5/OES or the Server
Consolidation Utility to move data off to a new OES server.
Note – The NW4.2 down-server upgrade to OES is not
officially supported, but in certain critical situations, a customer can work
with Novell Technical Services staff to use this technology.
After these upgrades, three servers were migrated to NW6.5OES
with the Migration Wizard 6.5. Please download the latest Migration Wizard 6.5
to ensure you have a fix to an issue has caused some failures during the
eDirectory migration. Migration Wizard 7.x.0 cannot be used to migrate 4.x
servers. Before running the Migration Wizard, load Clibaux on the 4.x server.
These migrations completed successfully as well as post-installs of products.
Last a 4.2 server was consolidated with the first new NW65sp3
server with its data, rights, and home directories copied over using Server
Consolidation Utility 3.x. (We always recommend you get the latest versions of
these utilities from the Novell
download site.) Before running the Server Consolidation Utility, load
Clibaux on the 4.x server.
After the home directories were copied over to the new server,
we used hbware's Homes
utility to quickly fix up the home directories, so users would automatically
login to the new server. In our configuration the users used a container login
script with "MAP ROOT F:=%HOME_DIRECTORY." After this server had its data moved,
it was removed from the tree using Load Install | Directory Options | Remove
Directory Services from this Server.
At this point all of the servers in the tree are now at the
NetWare 65sp3OES level.
Converting to NTP
At this point, the Time server which was previously using
timesync was converted to NTP. We simply changed the sys:system imeserv.ncf
file to now load XNTPD rather than timesync.nlm. We then changed the root time
provider's etc
tp.conf file by uncommenting the following entries: 127.127.1.0 prefer fudge 127.127.1.0 stratum 3
(So in this case the 127... address is telling the time
provider to get time from its local clock.)
Next, all other servers had the Timeserv.ncf file changed to
load XNTPD now and comment out Timesync. Then these servers were pointed to the
Time Provider server by adding this entry to their ntp.conf files: server IPAddress_of_TimeProvider
Next unload timesync on all the servers and load xntpd. Within
a few minutes time should be synchronized on all the servers. The NTPDATE
IPADDress_of_TimeProvider can also be executed on each server to quickly slam
the time to that of the Time Provider. Next run dsrepair | Time Synchronization
and it now shows all servers insync and shows NTP as the time method.
Note – NetWare NTP is also backward compatible with
Timesync. In one test we changed the tree from Timesync to NTP while we still
had some servers running IPX Timesync because they had not yet been upgraded to
OES. These servers were still able to synchronize time to the NTP Time Provider
via IPX and Timesync. Of course the 6.5OES time server had to have the dual
IPIPX Protocol stack in order for this to work.
Removing IPX
At this point all the servers have a dual stack using both IP
and IPX. Since all the 4.x servers are now gone from the tree, IPX is no longer
needed. In this scenario, the IPX modules and bindings were remarked out of the
autoexec.ncf, and/or bindings disabled in Inetcfg.
Down-server Upgrade caveats
Here are some issues that were hit randomly on different
down-server upgrades, that were able to be resolved through workarounds, but not
necessarily duplicatable in our labs.
- When upgrading the Master an error was hit trying to install eDirectory
toolbox (embox?). After the upgrade a post-install of embox successfully
completed.
- A -608 error was encountered during the SSL certificate creation on the
Master server down-server upgrade. A DSREPAIR to repair replicas fixed the
problem, and we were able to retry and get the certificates created.
- Another issue was synchronizing time with the 4.2 time server via IPX.
This was not duplicated in other environments, but the information is listed
here in case you encounter this.
Here are the details. During the
65sp3 install we went to adv on the timesync screen and gave it the name of
the IPX time server and checked the secondary box. After doing this we found
that time was still out of sync. After some fiddling around we went into
Monitor and found the time source entry had some corrupted characters. Once
the corrupted characters were removed and timesync was reloaded, then time was
synchronized.
- Restarting the down-server upgrade. If the down-server upgrade fails for
any reason, and it is necessary to reboot and try the upgrade again, you must
add the /nocheck option, otherwise the upgrade will think your server is
already at NW65 and will not let you proceed to do the upgrade.
Example: Use the install parameter- [inst: /upgrade /nocheck]
|