Open Enterprise Server 2 SP1 Migration Guide – Vol. 1, NetWare

Open Enterprise Server 2 SP1 Migration Guide – Vol. 1, NetWare

Source URL: http://www.novell.com/communities/node/6813http://www.novell.com/communities/coolsolutions/upgradetooes

By mfaris01

Created 20 Feb 2009 - 8:22am

Open Enterprise Server 2 SP1 Migration Guide – Vol. 1, NetWare  [1] Open Enterprise Server 2 SP1 Migration Guide – Vol. 2, OES1  [2]

Since the release of Open Enterprise Server SP1 (Linux), I have received several requests to revise my articles concerning OES2 and migrating from NetWare to OES2 Linux. After much thought, I decided to rewrite the entire article in lieu of a simple revision to make it easier for the reader to follow the steps I took instead of needing the knowledge of the earlier software packages. I've also decided to write articles that cover migrating from OES 1 to OES 2 SP1 and introducing a new OES2 SP1 server [3] into and existing eDirectory [4]8.7.3.x tree. I've also added, as requested, iFolder [5] 3.7 into these articles.

If you have read my previous articles, you will see that there are some sections that are completely different from before and there are some sections, Decommissioning, that still hold true today. I have included these redundant sections to complete the guide as they remain the recommended process to successfully complete the migration process, although one would assume you'd decommission the, now obsolete, server. Some may not have that assumption, and thus, I include it. Please disregard the redundancy.

Note: The installations covered in these articles are based on SuSE Linux Enterprise Server 10 SP2 (32 and 64 bit) and have been tested on both physical and virtual (VMWare©) servers. There may be dissimilarities in some screen shots, such as disk partitioning, as best practices recommends separate physical disks for mixing EVMS.

Please make modifications to the data, where noted, to reflect your own organization's structure.

Other resources:

Novell Open Enterprise Server 2 Migration Best Practices Guide:http://www.novell.com/communities/node/2758/novell-open-enterprise-server-2-best-practices-migration-guide [6]

Overview

The services to be migrated include:

Data – User and other sharedDNS [7]DHCP [8]PrintersZENWorks – Applications and policiesBackup – RSYNCiFolder 2.xDecommissioning

The steps to perform the migration are listed here:

1. Preparing your current environment.2. Installation of OES2 SP1 Linux to a new server3. Securing the new OES2 SP1 Linux server.4. Data migration.5. DHCP migration.6. Printer migration.7. DNS migration.8. ZENWorks Desktop Management v7 SP1 - Optional.9. RSYNC modification - Optional.10.NetWare Server Decommission.11.Workstations.12. iFolder 2.x to 3.7 migration – Optional.

Preparing your Environment

OES2 SP1 installs eDirectory 8.8.4 and can affect other applications in your environment.

Some applications will continue to run in a mixed eDirectory environment, as long as eDirectory 8.8 is not installed on that particular server.

To see a list of which Novell applications are compatible with eDirectory 8.8 and which are not, look here. http://support.novell.com/cgi-bin/search/searchtid.cgi?10099872.htm [9]

OES2 SP1 migration will migrate versions of NetWare from 4 and later. For purposes of this article, we will be migrating NetWare 6.5 SP6.

EVMS or non-EVMS for NSS?

With the original release of OES Linux (OES1), EVMS was required for NSS volumes and pools. When OES2 was released, this requirement was removed and NSS volume creation was simply done using unpartitioned disk space. OES2 SP1 gives you the option of using EVMS for NSS volume management or create your NSS volumes and pools using non-EVMS utilities, namely mkfs. The use of either is your choice, although EVMS allows for more features of NSS to be utilized. In this example migration, we will use EVMS as the default.

OES2 Linux Installation and Configuration

This installation and configuration is based on SuSE Linux Enterprise Server 10 SP2 and OES2 SP1 The option still exists to install OES2 SP1 as an Add-on Product during the initial installation or to add it post SLES install. In this example, we are adding it after the SLES installation.

Previously, I have excluded SLES and OES Linux installations from my articles, and assumed the reader would be bored with the redundancy of the various installation screens. I include them here because of the changes Novell has made compared to the older versions and to show you what's new and included with OES 2 SP1, as well as SLES SP2, specifically EVMS partitioning for NSS volumes and pools.

SuSE Linux Enterprise Server 10 SP2 Installation

Installing SLES 10 SP2 on a new server follows the standard SLES install as previous versions, except for disk partitioning. These screens and options have changed to the affect that I want to include each to show differences.

Select Create Custom Partition Setup and click Next

Select Custom Partitioning (for experts) and click Next

This is just an example of how you can set up your partitions. Be aware that you can only have 4 Primary partitions. Extended partitioning allows for more.

If you are going to use non-EVMS for NSS volumes, then you can stop here with the partitioning. Notice that the Extended is 47GB and we've only used a total of 25GB of this partition. We've left 22GB unpartitioned for non-EVMS NSS later.

Otherwise, If you wish to use EVMS, only include what you need for your Extended Partition and leave the rest for EVMS.

Click Create and specify Primary Partition. Choose Do Not Format and Type 82. Do not set a mount point [13] and click Ok.

Highlight this new Linux Native partition and click the EVMS button.

You will see your partition listed. First we have to create an EVMS container. Click the Create Container button in the upper right-hand side.

You will see your volume listed, but we need to add it to the container, click Add Volume and you will see the path to the container appear in the Container field. Click OK to create your EVMS container.

Now you see your available space for your EVMS volumes, of which there are none yet. Click Add.

Since we want to make this an NSS volume, click Do Not Format and do not specify a mount point. Enter a meaningful name for the volume and specify the size or click Max to use all the available space. Click OK.

Now we see the volume and that it's not mounted or formatted. If you have more to add, do it at this time, otherwise click Next.

We are now done with partitioning as far as the install is concerned, after OES2 SP1 is installed and configured, we'll complete the NSS volume and pool creation.

Note: Although SLES will allow EVMS and non-EVMS to reside on the same physical device, it is recommended that your EVMS/NSS partitions/volumes reside on separate devices from the rest of your SLES installation. Should corruption happen in the future, it's make restoring and even a complete re-install more reliable and easier if they are separate.

My own use is to have a “Linux” installed on a RAID [20] 1 and my NSS volumes on a separate RAID 5. Making it easier to add disks to the RAID, if needed.

Installation Progress screen.

Installation completed successfully.

After the OES installation is complete, you must perform the following tasks to ensure that the system device functions properly under EVMS:

Disable boot.lvm and boot.mdDisable boot.lvm and boot.md so they do not run at boot time. EVMS now handles the boot.

1. In YaST [23], click System > Runlevel Editor > Expert Mode.2. Select boot.lvm.3. Click Set/Reset > Disable the Service.4. Select boot.md.5. Click Set/Reset > Disable the Service.6. Click Finish, then click Yes.

Enable the boot.evms Service

The boot.evms service should be enabled automatically after the install, but you should verify that it is enabled.

1. In YaST, click System > Runlevel Editor > Expert Mode.2. Select boot.evms.

3. Click Set/Reset > Enable the Service.The B runlevel [24] option is automatically selected.

4. Click Finish, then click Yes.

Edit the /etc/init.d/boot.evms Script

1. Open the /etc/init.d/boot.evms script in a text editor.2. Add the following lines to the Stop section:

mount -n -o remount,rw /echo -en "\nDeleting devices nodes"rm -rf /dev/evmsmount -n -o remount,ro /The Stop section looks like this after the edit:

stop) echo -n "Stopping EVMS" mount -n -o remount,rw / echo -en "\nDeleting devices nodes"

rm -rf /dev/evms mount -n -o remount,ro / rc_status -v ;;

3. Save the file.

Finally! Reboot the Server

Now reboot the server to activate post-install configuration settings.

Verify the System Services

After the post-install configuration is complete and you have rebooted the server, make sure the server is operating as expected.

Adding OES2 SP1

Again, I'm adding OES2 SP1 to the SLES server post-installation.

When your server comes up, start YaST and choose Software | Add-on Product.

Select your media and click Next. If you have not placed your CD/DVD [27] in the drive, you will be prompted to do so.

The media is cataloged and then the OES2 SP1 Installation will ensue.

The is the list of services offered for OES2 SP1. Notice Domain Services for Windows, Pre-Migration Server, AFP [30], CIFS [31] and Novell Samba. These are new to OES2. Select the packages your organization requires and click Accept.

Note: You cannot install iFolder and Domain Services on the same server. YaST will complain about conflicts in dependencies. You probably wouldn't want iFolder running on a “Domain Controller” anyway.

Installation progress screen.

After the packages are installed, the installation process starts the OES Configuration process. Select whether you are starting a neweDirectory tree [34] or place this server into an existing tree. Selecting the option to use eDirectory certificates for HTTPS [35] will place the server's eDirectory certificates in Tomcat's certificate store and also replace Apache's certificates. The second option regarding TLS [36] is the default for LDAP [37] Binds to eDirectory, this is recommended. Click Next.

Enter the IP address [39] (faster) of an existing eDirectory server holding a R/W replica of the Root Partition. I always use the server that holds the Master replica of the root partition. This server will always have all schema extensions and knows about all other servers in the tree.

Unless there is a conflict, it is recommended to leave the default ports.Enter the ID and password of the tree admin or an admin equivalent.Click Next

Enter the context you want the server placed during installation of eDirectory. Again, it is recommended that you leave the DIB path and listed ports to default.

Configure NTP and SLP, in accordance with your organization's settings.

This is the last screen before eDirectory and the other OES option you selected before are configured and written to disk. This screen allows you to review your options and make changes as needed. Read your selections carefully, I have found placement of objects listed with the incorrect context than I wanted them. Corrections are much easier here than later.

When you are satisfied, click Next.

This is the installation and configuration of all the options you check earlier. Depending on how many you selected, this may take a while.

Your installation of OES2 is completed. Click Finish.

Create NSS Volume

From the command prompt, type nssmu to start the NSS Management Utility.

Select Devices and highlight the device you wish to use for your NSS volumes.

In order for NSS to utilize the space, the device must be Initialized. Warning: Init will destroy any data or volumes on this device.

Ensure you certain this is the device you want be fore proceeding.

Press F3 to Initialize this device.

When complete. You will see the available space for your NSS pools and volumes.

Select Pools, press Insert and create a new Pool. Call it VOL or whatever your standard dictates. Designate all or some of the free space to it, depending on your requirements.

Select Apply and the Escape back to the main menu.

Select Volumes, press Insert and create a new volume. Name it VOL1 (for example) and place it in the pool you created earlier. Designate all or some of the space to this volume and select apply.

If you don't see the volume in eDirectory, select the volume and press F4 to update eDirectory. Press Esc to exit the utility.

Securing the New OES2 Linux Server

These recommendations are optional and should be used as, at least, a guide to securing your server. Refer to your organization's security policies regarding hardening your servers.

GRUB [48] Boot Loader

Password protect the boot loader [49] to prevent editing of the boot environment or passing kernel level commands to the system at boot time. Use the md5crypt command within GRUB to encrypt a password. Then use this hash to edit the menu.lst file and insert the password line as shown below.

Be sure NOT to use the same password as root or any other user password on the system. If you “fat finger” the password without testing it first you will not be able to make changes to the boot process upon boot up!

# grub

GRUB version 0.97 (640K lower / 3072K upper memory)

[ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename. ]

grub> md5crypt

Password: *******Encrypted: $1$vUYoM$OAxm9NVNUBsCeP1dl50

grub>quit

vi /boot/grub/menu.lst

color white/blue black/light-graydefault 0timeout 8

password --md5 $1$vUYoM$OAxm9NVNUBsCeP1dl50title linux kernel (hd0,0)/boot/vmlinuz root=/dev/sda1 vga=795

BIOS [50]

Password protect changes to the BIOS to prevent changing the boot order of the device. In production booting from CD or floppy should be disabled.

Tuning Network Kernel Parameters

There are a few parameters that can be applied to the kernel through the proc file system [51] to improve protection of the server.

Modify /etc/sysconfig/sysctl to add these options along with the default configuration options.

net.ipv4.ip_forward = 0 -- Disables IP forwarding.net.ipv4.conf.all.accept_source_route = 0 -- Disables source routing.net.ipv4.tcp_syncookies = 1 -- TCP syn flood protection parameter.net.ipv4.tcp_max_syn_backlog = 4096 Additional TCP syn flood protection.

net.ipv4.conf.all.rp_filter = 1 Enables anti-spoofing protection.net.ipv4.conf.all.send_redirects = 0 Disables the sending of ICMP redirects.net.ipv4.conf.all.accept_redirects = 0 Disables receipt of ICMP redirects.net.ipv4.conf.default.accept_redirects = 0 Disables ICMP redirects for newly activated.

Warning Banners

Include this warning message for all direct methods of connection to the server.

/etc/motd Add this banner to this file

/etc/issue Add this banner to this file also. Below is an example that you can use. Change My Company to your Organization - It's lengthy, but you know the legal guys..

My Company owns this computer system and restricts access and use to authorized persons only. Use of and/or access to this system and/or any information obtained via this system is subject to My Company policies and procedures governing such use and access. Unauthorized or improper use of or access to this system, or any portion of it, either directly or indirectly, or any attempt to deny service to authorized users or to alter, damage, or destroy information, or otherwise to interfere with the system or its operation, is strictly prohibited. Any party using or accessing, or attempting to use or access, this system without express authority from My Company may be subject to severe disciplinary action and/or civil and criminal penalties in accordance with applicable state and federal law (including, but not limited to, the Computer Fraud and Abuse Act of 1986 and the Electronic Communications Privacy Act). My Company representatives may monitor and record use and access for quality assurance, security, privacy compliance, regulatory compliance i.e. HIPAA, Sarbanes Oxley, and performance, except as prohibited by law. Any person who uses or accesses this system expressly consents to such monitoring and recording. My Company or its representatives may furnish information obtained by its monitoring and recording activity to law enforcement officials if such monitoring and recording reveals possible evidence of unlawful activity.

Copy the /etc/issue file to /etc/issue.net

For SSH [52] connections edit the /etc/ssh/sshd_config file. Below is the what needs to be changed to point the banner at the /etc/issue.net file.

# vi /etc/ssh/sshd_config

??.# no default banner pathBanner /etc/issue.net#VerifyReverseMapping no

# override default of no subsystems

SSH configuration

In addition to setting a banner as above, it should be restricted to version 2 of the protocol [53] only. SSH version 1 has some inherent weaknesses and so should be avoided. Edit this file and make the changes listed in Bold. Most settings are fairly self explanatory. No hosts should be automatically trusted through the rhosts types of authentication or even with a machine based certificate as with the RSA variants. Root should not be allowed direct access. For administration, you should connect to the machine as a regular user and then SU to root for additional needed rights.

#Port 22Protocol 2#ListenAddress 0.0.0.0#ListenAddress ::SyslogFacility AUTH##LoginGraceTime 600PermitRootLogin no#StrictModes yesRhostsAuthentication no# Don't read the user's ~/.rhosts and ~/.shosts filesIgnoreRhosts yes# For this to work you will also need host keys in /etc/ssh/ssh_known_hostsRhostsRSAAuthentication no# similar for protocol version 2HostbasedAuthentication noPermitEmptyPasswords no

Further Securing Remote Login

In addition to the restrictions made on SSH, we should also further disable remote interactive login for root in case, mistakenly or maliciously, telnet [54] or some other method of tty access was enabled again. Modify the /etc/securetty file. All lines except the TTY1 should be commented out. This is needed for console access. SSH is running its own daemon [55] and is not affected by these settings.

# This file contains the device names of tty lines (one per line,# without leading /dev/) on which root is allowed to login.#tty1#tty2#tty3#tty4#tty5

#tty6# for devfs:#vc/1#vc/2#vc/3#vc/4#vc/5#vc/6

Now this file should be protected by executing the following:

chown root:root /etc/securetty

chmod 400 /etc/securetty

this makes it so that only root can read the file and nobody can write to it, even root, until root chmod's the file with more permissions again.

Modification to /etc/inittab

/etc/inittab has several settings in it that should be hardened. Disable Ctrl-Alt-Delete from shutting down the server, edit the default run level, protect the server even in Single User mode, and disable extra console login daemons (Ctrl-Alt-Fx) to further protect console

access.

See the settings made in Bold.

# The default runlevel is defined hereid:3:initdefault:

# First script to be executed, if not booting in emergency (-b) modesi::bootwait:/etc/init.d/boot# what to do in single-user models:S:wait:/etc/init.d/rc S~~:S:wait:/sbin/sulogin

# what to do when CTRL-ALT-DEL is pressed. Comment to disable.#ca::ctrlaltdel:/sbin/shutdown -r -t 4 now

The "3" in the id:3:initdefault line designates that the default run level is level 3 which does not load the GUI. The GUI can be loaded as necessary with the "startx" command but should not remain loaded or load by default on the server.

The line beginning with "~~:S" is the command for what to do in single user mode. (i.e. typing "single" as a boot parameter in grub -- which now requires password access anyway). Change the "respawn" command to "wait." This will prompt for the root password before continuing.

The "ca::ctrlaltdel:/sbin/shutdown --r --t4 now" line is the command to execute when Ctrl-Alt-Delete is pressed. This should be commented out as shown to disable this functionality and prevent someone with physical access from shutting down the machine without a valid login.

Xwindows - GUI protections

Although X-windows is not loading by default on the server, this could be changed easily by an administrator [56] and it is available to load manually by changing run levels or typing "startx" at the console prompt. Therefore, implement the following extra safeguards:

Disable XDMCP

Remote machines should not be able to get an X terminal login window. Edit the following lines in /etc/X11 [57]/xdm/Xaccess to prepend them with a "!" as shown.

!* #NO host can get a login window!* CHOOSER BROADCAST #NO indirect host can get a chooser

Disable listening on port 6000

This prevents the X system from listening for X events from remote machines. Local X access at the console is not affected. Edit the config file /etc/X11/xdm/Xservers as shown below adding the "-nolisten tcp" switch to this line.

:0 local /usr/X11R6/bin/X :0 vt07 -nolisten tcp

Restrict cron [58] and at

Cron and at daemons run processes on the system as root so access to them as well as the crontab command and files so that malicious code can't be "scheduled." The binaries are also world executable and SUID to root so they can be dangerous. Restrict access to them with the following steps.

1. Create cron.allow and at.allow files

These files will restrict access to cron to only the users listed in the files. All others will be denied. The only user in the list should be root. These files don't exist by default so you can create them with the echo command as follows. Delete any deny files. (/var/spool/cron/deny)

# echo root > /etc/cron.allow# echo root > /etc/at.allow

2. Modify permissions on cron/at related files

Since all cron and at files are read and written to by processes that are SUID root, normal users on the system will not ever need to have direct access to the files so they should be secured to prevent tampering.

# chown -R root:root /etc/cron* /var/spool/cron# chmod -R go-rwx /etc/cron* /var/spool/cron

OES2 SP1 Migration

With the release of OES2 SP1, the migration utilities' robustness has greatly improved, especially the gui interface. Novell has combined a majority of the individual utilities into one, allowing for a single migration, instead of each service having it's own, needing to be launched individually.

Here is a list of possible services for gui migration. Note: only services that are installed will be listed.

DHCPAFPCIFSFile SystemsFTP [59]iFolderiPrint [60]NTP

DNS migration is performed through iManager [61].

For purposes of this article, we will only be migrating the following services.

File Systems (data)iPrintDHCPiFolder – Will be discussed later, as there are various scenarios associated, depending on version.

Data Migration

We will be migrating user data to a server that is in the same eDirectory tree and in the same container. We will use the GUI utility for presentation purposes.

The migration gui saves a lot of time and headaches versus the command line [62] utilities. Personally, I'm a CDL guy, but looking at the DHCP migration utility (migdhcp.sh) alone made me thankful for the gui this time.

With the gui, you can opt for migrating single or multiple services at the same time, we'll show each service covered individually.

You can type miggui from the cdl or launch the migration utility from YaST.

This screen shows both the Source and Target servers, as well as the services configured to be migrated. You can see that there aren't any listed. We'll do that in a moment. First let's configure our source and target servers.

Click the Source server. Enter the source server [66] information and authentication credentials. If the source server is a NetWare server [67], then the root password is not needed.

Click OK.

Click the Target server. Enter the target server information and authentication credentials. You will need to enter the root password since the target server is a Linux server.

Click OK.

Select the Type of Migration. Here we'll use Consolidate.

In the Services to Migrate frame, click Add to add services that are to be migrated.

You should see something similar, depending on what you have installed the source and target serversHighlight the services you desire to migrate and click OK.

Almost ready. We have our source and target servers defined and the services we want to migrate. Now each service needs to be configured to your specifications.

File System

Highlight the File System service and click the Configure button.

Select the directories on the source volume you wish to migrate and drag them to the target volume on the target server. Click the File Options tab

Select the options you wish. Click the Trustee Options tab.

Again, select the options as it pertains to your organization. The Match User Options tab is enabled when you select the Custom User Mapping option.

Click Ok.

Novell DHCP Service

Highlight the Novell DHCP Service and click the Configure button.

Select type of migration,

Tree level will consolidate all DHCP servers, in the tree to the target server

Server level will simply migrate the DHCP server listed and it's managed subnets to the target server.

Subnet Level migrates a specified subnet to the target server.

For our purposes, we're using Server Level

Browse to the DHCP server object of the source server.

On the Other Options tab, browse or enter, the base DN, i.e., O=Org

Locator DN: cn=dhcpLocator,o=org

Group DN: cn=DHCP Group,o=Org

Click OK.

Novell iPrint [75]

iPrint service requires that an iPrint Manager and Driver Store be already created on the target server prior to migration.Highlight the Novell iPrint service and click the Configure button.

Select the Source and Target Print Managers to be migrated. Don't get them mixed up!

Select which printer objects are to be migrated. Or Select All

Specify whether the migrated printer objects are to be placed in the same container after migration or, specify a different target context the printers are to be placed. Select whether existing target printer objects are to be migrated at all.

Click the Other Options tab

Specify the target Driver Store and whether to migrate drivers and profiles.

Click Ok.

Migration Process

when you are satisfied with your configuration, click the Start button in between the Source and Target servers.

Each service will migrate in order. When complete, you will see a similar screen.

If you have failures, the utility will let you know.

In the errors above, I learned that the DHCP migration utility migdhcp.sh, did not allow for spaces in the DN. i.e., ou=Salt Lake City,o=Org. This has since been fixed by it's author.

One other gotcha I found was if, ZENworks Inventory process is running on the source NetWare server and you select the ZENworks directory for migration, unload ZENworks, ZFDSTOP.NCF prior to running the migration as it will fail when trying to migrate the DB files because they will be open on the source server.

Let's check trustees to see if the migrated also. Open iManager and browse to a user's Home directory on the target server and view it's trustee assignments.

We see that Rjames has full rights to his Home directory on the OES 2 SP1 Linux server.

DNS

Ensure that DNS is not running on the NetWare server.

Login to iManager.

Click DNS and then DNS Server Management [82].

From the drop-down menu, select Move DNS Server and click OK.

Select the DNS Server name from the drop-down list. This will be the OES2 Linux Server.

Use the Object Selector to select the NCP (NetWare) server that will be migrated.

Click Move.

All primary zones associated with old DNS server will be migrated.

ZENWorks Desktop Management v7 SP1 - Optional

Insert the ZDM 7 SP1 CD in the new server and browse to the mount point from the command line.

(/media/cdrom)Copy the file, silent.properties to /root/.

Edit the file and modify the following lines:

INSTALL_REMOTE_MANAGEMENT=trueINSTALL_APPLICATION_MANAGEMENT=trueINSTALL_APPLICATION_MANAGEMENT_DATABASE=trueINSTALL_WORKSTATION_IMPORT_SERVER=trueINSTALL_ZDM_AGENT=true

Remove Comment from:

TREE_NAME=MY_COMPANY_TREE

SHOULD_EXTEND_SCHEMA=trueUSER_SUPPLIED_SERIAL_NUMBER=[Enter your Activation Code Here]ConfigureAction.ZDM_FORCE_CONFIGURE=true

Save the file and change directories to /media/cdrom

Type the following to install ZDM7 on your server:

./setup -f /root/silent.properties

When complete, dismount the CD.

In ConsoleOne [83], edit each NAL object to reflect the new path to the files on OES Linux Volume.

RSYNC - Optional

Migrating RSYNC is fairly uneventful accept for granting the proper POSIX acls to the NSS file mounts instead of default eDirectory acls.

Here is what needs to be changed and/or added and where.

On your main RSYNC Server, in the SYS:SYSTEM directory, there are several NCF files beginning with RS_. These files have numbers following the prefix that corresponds to a time that the file is executed. Find which file has the branch server reference in it and change that file to reflect the following:

Current:

rsync -vprtuz –stats –delete –volume=VOL1: NETWARE_SERVER_NAME::NETWARE_SERVER_NAMEUsers /BACKUP/Branch_name/Users –timeout=360 –bwlimit=256

New:

rsync -vprtuz –stats –delete –volume=VOL1: OES2_SERVER_NAME::OES2_SERVER_NAMEUsers /BACKUP/Branch_name/Users –timeout=360 –bwlimit=256

Change the NETWARE_SERVER_NAME to OES2_SERVER_NAME in the file for that branch you are migrating.

On the new OES Linux server, edit the file /etc/rsyncd.conf

Make the following changes:

uid = admingid = roottransfer logging = truelog format = %h %o %f %l %blog file = /var/log/rsyncd.logslp refresh = 300

[OES-ServernameUsers]path = /media/nss/VOL1/userscomment = (Branch name) Usersread only = nochroot = notimeout = 60

[OES-ServernameShare]path = /media/nss/VOL1/sharecomment = (Branch name) Shareread only = nochroot = notimeout = 60

Save this file and exit.

Decommission NetWare server

In ConsoleOne, remove the R/W replica from the NetWare Server.

Right-Click the Container Object for the branch and select Properties.

Click the Login Script Tab and change any reference to the NetWare server to reflect the OES Server – i.e., MAP ROOT U:=NNETWARE_SERVER/VOL1:USERS/%1 to MAP ROOT U:=OES_SERVER_NAME/VOL1:USERS/%1

From the console of the NetWare server, type NWCONFIG and press Enter.

Select Directory Options|Remove Directory Services from this server

Press Enter on the warning and Yes to remove Directory Services. Choose .Root. as the reference point. Authenticate and complete the removal. Exit NWCONFIG and type EDIT C:\AUTOEXEC.BAT. REMark out the statement to load server.exe. Save the file and exit EDIT.Down the Netware Server and power it off.

In ConsoleOne, remove any objects not removed by nwconfig relating to that server.

Workstations

The only changes that need to be made on the workstations is, if you specify a Preferred Server, it will need to be changed to reflect the new OES2 Linux Server.

iFolder Migration

There are several combinations for migrating iFolder to and OES 2 SP1 Linux server.

In this scenario, I will be focusing on migration iFolder 2.x on NetWare to 3.7 on OES 2 SP1 Linux.

To explore the other possibilities, refer to Novell's documentation concerning migration iFolderhttp://www.novell.com/documentation/oes2/mig_tools... [84]

Note: You must migrate iFolder 2.x server file system, using the Migration Utility's File System Migration first. See above File System.

Select your options depending on your current configuration. Note the default path for iFolder on Linux is /var/opt/novell/iFolder. If you migrated the file system data to a separate path, specify it here.

Once you have made your selections, click Ok.

Note: Encrypted file stores are not migrated because they need the user's passphrase and must be performed on the client side.

Now you must migrate your clients.

On the client PC, install the iFolder 3.7 client and ensure that it does not overwrite any iFolder 2.x files. Do this by specifying an alternate path. For the migration to be successful, both versions of iFolder (2.x AND 3.7) must be running on the client PC.It is not recommended to choose the move iFolder 2.x to 3.7 because there is no back out should the migration fail. The entire iFolder store is moved instead of copied.

Once the migration on the client is complete, you must remove the iFolder 2.x client from the PC for iFolder 3.7 to function normally. It also ensures that user will not accidentally use it out of habit before the NetWare server is decommissioned.

Conclusion

Open Enterprise Server 2 SP1 has many improvements for migration from NetWare AND Windows to OES2 Linux, including tree to tree migration. And with OES2 SP1, Domain Services for Windows will add to the migration possibilities.

Source URL: http://www.novell.com/communities/node/6813