Application Delivery Management
Application Modernization & Connectivity
CyberRes by OpenText
IT Operations Management
Like an old soldier, NetWare refuses to die and just keeps slowly fading away. This means that customers will still likely need to migrate their files from NetWare for some time to come. Unfortunately, this is becoming more difficult as time goes on.
Migration can be a complex process when you take into account product versions and various system configurations. The product documentation should first be consulted to determine what options are available to you. It is beyond the scope of this Cool Solution to explore all those possibilities but I will try to identify some important issues and provide some alternatives which may help in specific situations.
Source data
GroupWise
If you are doing a GroupWise migration, one component of that migration is transferring the domain and post office files to the new server. While there is nothing unusual about the files themselves, a post office can contain several hundred thousand small files and the time needed to transfer the files is often quite lengthy.
NSS Files
For many customers, it is essential to maintain trustee rights. This implies the destination be an OES server supporting NSS volumes.
Destination Server
If you are running current versions of SLES or OES you are likely using one of the following:
Migration to SLES
Issues
Of the various migration scenarios, migrating GroupWise files from NetWare to Linux is the most problematic.
The GroupWise documentation instructs the reader to use the GroupWise Server Migration Utility to migrate the GroupWise system. The migration includes the domain and post office files. The other option is to use the dbcopy command if you just want to copy the domain and post office files.
Both these utilities require that the remote NetWare volume be mounted on the Linux server to facilitate the copy between the source and destination servers. The GroupWise Server Migration Utility specifically states that having the ncpfs package installed is a prerequisite. If you intend to use dbcopy to copy files across the wire, you are instructed to mount the remote NetWare NCP or NSS filesystem on the SLES server using the ncpmount command which is included with the open source package ncpfs.
If you are following the GroupWise documentation and using one of those “supported” migration methods here’s what you can expect to find, especially if you’ve just installed a new destination server.
Here’s what the GroupWise documentation doesn’t tell you:
Despite the above restrictions and limitations, the SLES 11 mount command does appear to support filesystem type ncpfs. Use at your own discretion. See the man pages for more information.
Conclusion: For most customers, using ncpfs is no longer a viable option.
Options
If you need to use the GroupWise Server Migration Utility, your options are limited. The ncpfs package is a requirement because the Utility automatically mounts the source server in the background using the ncpmount command.
If you are using dbcopy, you have some options when deciding how to mount the source NetWare volume.
The Novell Client for Linux
You can find the Novell Client for Linux on the SLED DVD. It is supported on a SLED workstation but some customers have had success using it with SLES. Make sure your SLES server and the SLED DVD are at the same SP level.
Like the Windows version, it allows you to access NCP and NSS files natively. When I tried it on a SLES 11 SP4 system to copy files from my live GroupWise server, performance was much better than when using ncpfs but only about ten percent of my files were initially copied. Presumably, if I ran dbcopy a sufficient number of times it would eventually copy everything but I abandoned this approach as I could never be sure everything got copied. YMMV!
For more information see:
TID 700712 - How to install the Novell Client for Linux on SLE 11 SP1.
The Novell Client for SUSE Linux Enterprise Desktop 11 entered extended support 31 Mar 2016.
Novell Native File Access Protocols
NetWare supports a number of protocols to simplify communications with other operating systems. You may wish to read the
NW 6.5 SP8: AFP, CIFS, and NFS (NFAP) Administration Guide.
SLES supports a wide variety of different protocols and is able to mount both smbfs (CIFS) and NFS filesystems which NetWare supports natively.
Protocol Restrictions
If you refer to the various TIDs you will see there is a lot of contradictory information regarding which protocols are appropriate. One thing is clear, however: Never use NFS!
GroupWise 2014 R2 Installation Guide:
6.8 File System Support
GroupWise is supported on any file system supported by the server OS. Using an NFS mount to the file system where the GroupWise system is located is not supported.
GroupWise 8 Design Services Wiki
Access Protocols
Whenever possible utilize NetWare Core Protocol (NCP) to access GroupWise information stores. This simplifies administration greatly especially when administrators and support staff utilize Windows based instances of ConsoleOne. Samba is often touted as a viable option but its use should be avoided. Whereas it will technically work the file system semantics, file locking behaviour, and performance leave much to be desired. The end result minimally will be annoyances due to performance or database corruption at the worst. The Network File System (NFS) protocol for accessing GroupWise information stores should not be used for system administration.... ever.
Windows workstation
Running dbcopy from a Windows workstation and using the Micro Focus Client for Open Enterprise Server (formerly the Novell Client) to access the NetWare server is a supported solution. The destination could be a Samba share on your SLES server.
This solution circumvents all the protocol restrictions and allows dbcopy to be run multiple times while your GroupWise system is live. Because it requires network access to both your NetWare and your SLES servers, it may take a while to complete.
Thinking Outside the Box (literally)
Copying a couple of hundred thousand files across the wire can take a significant amount of time, often several days! What if you could circumvent that? What if you could accomplish your migration in a matter of hours? Yes, it is possible if you have an OES server. Even if you want to run GroupWise on SLES, you may want to consider using an evaluation copy of OES as a migration tool. If you’re curious, then read on.
Migration to OES
Unlike SLES, OES is able to mount an NSS volume and access the files directly just as NetWare would. This opens up a whole range of additional possibilities for us to explore and depending on your specific setup, one of them may work for you. Before we get into that, let’s first get something else out of the way.
Migration Tool
The migration tool, also known as MIGGUI, is the main utility used to migrate services to an OES server. It is the tool you would want to use to migrate your NSS files and trustees. While it could also be used to migrate GroupWise files, there are better options considering that trustees are seldom an issue with GroupWise. For additional information, please refer to the OES 2015 SP1: Migration Tool Administration Guide.
Accessing your NetWare Server
OES has a map command. It will mount your NCP or NSS volume and has been around since OES1. See the OES 2015 SP1: Linux Tips for NetWare Administrators and the man pages for more information. The man page title reads “Novell Client for Linux Man Pages” suggesting the map command is part of the Novell Client for Linux. Other than that, there is very little information about it and no information I could locate regarding its use in data migration.
GroupWise File Migration
The migration of GroupWise domains and especially post offices is a lengthy process due to a number of factors.
Perhaps we can greatly reduce the total migration time and possibly even the GroupWise server outage by taking a different approach? What if we were to transfer between two servers a disk image rather than individual files? Since OES can natively access files on a NSS volume, this approach is not only feasible but could greatly simplify the whole migration.
Migration from a NetWare VM
To do the migration, first we want to attach our NetWare disk to our OES VM.
Just as you can pull a hard drive out of one system and insert it into another, in a virtual environment you can accomplish the same thing if you take the storage (a file, LUN, LV, disk, etc.) associated with a disk in one VM and reassign it to a disk in another VM.
I was working on a VMware vSphere system so, after shutting down the source server, I made a copy of the .vmdk file and worked with the copy. We all know that the safety of our data is paramount and are always encouraged to have more than a single backup so it’s just prudent to make a copy of the storage device first then attach the copy. I was quite surprised how little time it took to make the copy.
Now that the NetWare disk is attached to our OES VM:
Migration from a Stand-alone NetWare server
Another time I needed to copy a domain and post office from a stand-alone NetWare 6.5 SP8 server so I decided to clone the disk. Here’s how:
Make sure ssh is enabled on your OES server and that you can login as root.
fdisk -l
dd if=/dev/sda bs=5M | ssh root@<OES IP addr> “dd of=/dev/sdx bs=5M”
(Adjust "/dev/sda", "<OES IP addr>", and "/dev/sdx" for your configuration.)
A copy of your NetWare disk is now attached to the OES server.
Finishing up
After you have copied the files, you’ll want to remove the NetWare disk from your OES server. If you used a copy of your NetWare disk, you may want to delete the copy too.
Before you begin a GroupWise install, you’ll need to make sure file names have been converted to lower case. When I copied my domain and post office, I did not use dbcopy. Instead, after I finished copying the files, I used dbcopy to do an “in-place” conversion of files and directories to lowercase:
dbcopy -l -d /<path to destination domain directory>
dbcopy -l -p /<path to destination post office directory>
This is what the -l (lower case “L”) switch does:
Performs the GroupWise Check function of storelowercase on the migrated GroupWise databases. Its purpose is to do an “in-place” conversion of files and directories to lowercase, rather than as part of a copy operation. For a post office, it also updates the guardian database with the new, lowercase names.
Final notes
Cloning the NetWare disk was much faster than copying individual files. Data was transferred at full wire speed: 120 MB/sec across a gigabit link. The dbcopy in-place conversion was also very quick.
I hope I’ve given you a few ideas on how you might accomplish your migration and how to avoid some of the pitfalls. If you would like more information or would like to discuss any of the ideas presented here, feel free to stop by the Open Enterprise Server - OES NetWare Install-Upgrade forum. We’d love to chat with you.