In this book we assume that you have already installed and prepared your new Linux or Windows server for the move of your GroupWise domain.
While we do not intend to go through all of the steps of installing and configuring your new server, we will point out a few requirements and recommendations.
If you are moving GroupWise to an OES server, eDirectory will be one the of the standard additions during installation. However, one of the big questions when installing a new SLES or Windows server is whether or not to install eDirectory on the server itself. This really depends on your GroupWise infrastructure. The simple fact is GroupWise needs eDirectory. Somewhere. This does not necessarily mean that each GroupWise server needs eDirectory. As a NetWare Administrator, you know that every NetWare server runs eDirectory, and each server is installed “into” the tree. Not every NetWare server needs to have an eDirectory partition on it though. This is the same for GroupWise servers. While you CAN install eDirectory onto every Windows or Linux server that houses GroupWise components, it is not a requirement. As long as there is one eDirectory server in the network to manage eDirectory authentication, then GroupWise will work.
If you will be retiring all of your NetWare servers with this migration, and you currently have eDirectory ONLY on NetWare servers, then you will need to install eDirectory on at least one GroupWise server. Plan on putting a Windows or Linux eDirectory server everywhere that you would normally place an eDirectory replica for the most part. If eDirectory already exists on some Linux or Windows servers in your organization, you can choose to put eDirectory on your new GroupWise servers according to your own requirements.
Rather than reinventing the wheel, we point you to a very good App Note on installing eDirectory on Windows. If you are in a situation where you need eDirectory on your Windows server (i.e., you will have no NetWare or OES2 Linux servers in your network), then use this guide to get eDirectory installed on your Windows server:
NOTE: While these instructions are for 8.7.3, the 8.8 installation is very similar, and preferred for Windows and Linux servers.
If you are moving your GroupWise system to Windows, you can jump down to the section entitied “The GroupWise Server Migration Utility”. For a few paragraphs we will be discussing special Linux considerations.
Why Move to Linux?
There are really two components to the “why” of running GroupWise on Linux. One is the technical (i.e., how does running GroupWise on Linux benefit us from an IT perspective), and the other is more political or even emotional.
The Case for Linux
There are many reasons why Linux enthusiasts, consultants, Novell, and even IT departments tout Linux over Windows. Here are a few that are most often cited:
- Improved stability: Linux typically has fewer operating system faults of its own, and individual applications generally do not bring an entire Linux server down. Whereas on NetWare, an administrator could choose to run a particular application in its own address space to minimize the overall impact that an errant application might have on the server, Linux applications run this way by default. So if a particular application on Linux crashes, it is unlikely to bring the entire system down with it.
- Better application fault handling and recovery: GroupWise agents restart in seconds on Linux. So, if you do have a post office agent or such crash, the high availability agent (or other script) can bring it back up quickly.
- Core files are generated very quickly as well. Each application on a Linux server can be set to generate a core file if you are having problems, and you can be back up and running within minutes (Novell says seconds, but we all know that humans also only work so fast!), and deal with getting the core file to Novell after everyone is back working in GroupWise.
- Database stability: According to Novell IS&T, they see far fewer database corruption issues in GroupWise databases due to hardware crashes or power problems. For whatever reason, Linux seems to manage “closing” GroupWise files more effectively during routine operation, and thus fewer files are left open to cause issues.
- Automation: While certainly some scripting can be used on Windows to provide ease of administration, this cannot come close to the flexibility of Linux to design management scripts, health check scripts, code deployment scripts, coredump management scripts, backup scripts and the like.
So, as you can see, there are many good reasons to move to Linux from a purely technical standpoint. However, the political and organizational reasons why a company moves to Linux are often more intangible.
The question of “why” an organization moves to Linux is very important, but often not given nearly enough thought in our experience. It’s a given that we have to move somewhere. NetWare is no longer a supported platform for GroupWise agent components.
GroupWise is and has always been a somewhat rare exception to the Novell application offerings. GroupWise has always been available as a multi-platform product, and has been less tied to NetWare than any other Novell product (there are some other exceptions as well, but we aren’t going to get into those!!). eDirectory is also available on multiple platforms, but it seems to always be less for its own sake than to allow things like GroupWise and other Novell applications to exist on other platforms. For example, while eDirectory runs on Windows, we know of very few sites who use eDirectory as the primary directory for their Windows only networks. When eDirectory appears on a Windows server, it’s almost always to support something like GroupWise without needing a NetWare server in the mix.
There is no doubt that Linux is the true present and future of Novell products. That said, small companies where there is little or no Linux administrative experience should think good and hard about making this move before they are really ready. When customers ask us if they should move GroupWise to Linux, we have two important questions:
- Who in your organization knows Linux well enough to administer GroupWise on that platform?
- Why do you see moving to Linux as an important business decision?
Here are some of the most common responses:
- We can’t run GroupWise 2012 on Netware, so we must move. It doesn’t matter that we have no Linux experience at all, our salesperson says it just needs to be done, and we’ll be able to deal with it. Our secretary who knows how to reboot the NetWare server when we’re having trouble will be able to do the same with the Linux server, won’t she?
- With the changes in GroupWise 2012, it’s time to move on, and Linux seems the obvious choice. We’re looking at moving things over slowly, perhaps putting a GWIA or WebAccess on Linux first, and getting our feet wet before we move our post offices to Linux. Our administrators are working with Linux in a testing environment, and we should be in a good position with our Linux knowledge by the time we complete our migration.
- We have a comprehensive plan to move all of our mission critical operations to Linux. We have a lot of experience in the area. We have other applications and processes running on Linux now, so adding GroupWise to Linux will be easy for the Linux administrators. Hopefully the GroupWise administrators will not have too many problems, but we have a good set of people to support them if there are issues.
- We have to do something. We don’t want to move to Windows, we have to move GroupWise to something. We don’t have much choice here, and I think we’ll send the GroupWise administrators to a couple of Linux classes and then plan to get everything moved over during the upcoming long weekend about two months from now.
While you might think that the first scenario above is the most scary for us, it’s really not as frightening a situation as you might think. Certainly, we have small GroupWise customers who have no network administrators or GroupWise administrators on site, and rely on consultants to handle all of their networking needs just like the customer in the first scenario. For those, generally NetWare is just as foreign a concept as Linux. They don’t know Fat32 from NSS from NTFS; eDirectory from Active Directory. In many ways, for those customers, moving to Linux is all about the expertise of their consultants. If the consultant understands Linux, and can get to the office quickly when there is a problem, then the situation is not much different than with the current NetWare servers.
The second scenario is one that we like to see. For sites that currently have no Linux, bringing up a Linux server and installing WebAccess or a GWIA is very good practice, and gives the administrator something to cut his/her teeth on without having to worry about that all important post office with those databases full of information that we all need! Since WebAccess and the GWIA are essentially “pass through” processes, there is very little catastrophic that can happen by moving them to a Linux server. Certainly, a site could experience some downtime of WebAccess or Internet e-mail if that new Linux server isn’t well understood, but actual data loss is unlikely. Of course, if you wish to put WebAccess or a POP3/IMAP4 GWIA on Linux before you upgrade all of your post offices, you will need to leave your current POP3/IMAP4 GWIA and WebAccess in place to service those GroupWise 8 post offices until after the upgrade is complete.
Perhaps the most appealing and frustrating things about a move to Linux for folks in the second scenario is that like NetWare, once you get the Linux server installed and working to your satisfaction, it just seems to run. This is very appealing, because you don’t worry that much about whether or not the system is working. It’s also very frustrating though, because this also means that there is very little opportunity to learn by doing over and over again! Years ago, when we first began our work with GroupWise on Linux, it took us months to remember things as simple as how to install an RPM! Danita had to write everything down, and look at her notes constantly in the beginning, because it was often weeks, if not months between times that she needed to truly “fix” something on the Linux servers. She ended up formatting her laptop hard drive and installing Linux on it, with VMWare for Windows, so that she would have to be confronted with Linux every day in order to learn it. Not everyone will be as ambitious as that in order to learn Linux, but we have to say, it really worked!
The third scenario is more common for large networks. We occasionally find a small to mid-sized company that has a good deal of Linux experience, but the typical organization that will have a lot of Linux experience on-site is a bit larger. The general downside with these installations is that the Linux administrator has a lot of Linux experience, but does not understand GroupWise, and the GroupWise administrator has a lot of GroupWise experience, but does not understand Linux. This can result in a lot of confusion in and of itself. So while this is generally a “happier” situation than some, it does not ensure clear sailing for the GroupWise migration. It will be necessary for the GroupWise administrator to learn some Linux in order to deal with management of the server, but it’s a nice warm feeling to know that someone in the organization will be able to help with critical issues (and maybe even just some hand holding).
The last scenario seems to be the most disconcerting though. There are many sites that are feeling a “push” to do something. They have enough Novell enthusiasts on the team to avoid a move to Exchange, and feel like moving GroupWise to Windows would be a “step down” or maybe even opening a door to a future move to Exchange. They are accustomed to the ease of managing GroupWise, and somehow feel like it should just be a “breeze” to get to Linux. It’s likely that no one in their office has ever touched Linux. While the perfect solution would be to hire a Linux administrator and bring him/her up to speed on GroupWise, that is threatening to the current administrators, and they are often willing to just say “I know I can do that” and then try to cram in as much Linux experience as they can in the next two months in order to avoid risking their authority in the department, or even their very jobs, by bringing in a new “Linux expert”.
In these scenarios, we always recommend a step back, and an assessment of just what can be done in order to bring the situation under control. If there is truly good management support to bring in Linux, then we try to slow down the push for the ultimate move and recommend a graduated solution such as the second scenario above. In some cases, we will flat out recommend that the customer move GroupWise to Windows if the Linux skills of the organization seem minimal, with little likelihood of changing in the near future.
Now, let’s be clear: We at Caledonia think that Linux is really the way to go for GroupWise. That said, however, there are some situations where a move to Linux just does not seem to make sense or even be prudent. In those cases, we caution customers against making rash decisions for the “big move” based on what “everyone else is doing”. After all, we didn’t all move to Exchange just because “everyone else is doing it”. And indeed, if moving GroupWise to Windows seems more reasonable for a customer, we have a section in this book for that as well!
Developing Linux Skills
The primary purpose of this Section of our book is to assist you in moving your GroupWise system to Linux. It is beyond the scope of this book to teach you everything there is to know about Linux! That said, there were be times when we give you hints about how to facilitate Linux commands, expound upon the differences between Linux mount points and mapped drives and drive letters, case sensitivity and other sundries. We will try our best to cover all of the “gotchas” of moving to Linux. You will need to bring a certain level of Linux expertise to this party though.
In our discussion above of the move to Linux, one of the major considerations was the Linux expertise of those in your organization who will be managing the GroupWise system. Unless you fall into scenario #1 above, having someone on your staff who really understands Linux is crucial. If you fall into either scenario #2 or #4 above, it’s important to find ways to improve the Linux skills in your office. There are various ways to do this.
Using Linux to Learn It
As mentioned before, hands on use of Linux is by far the best way to learn Linux. Here are a few ideas about how to learn Linux better:
- Put Linux on your workstation: We know this seems to be the most drastic of any of the possibilities, but it certainly gets the job done. We have found that with Linux in a virtual machine on an administrator’s Windows workstation, the administrator is rarely forced to use Linux. On the other hand, with Linux as the primary desktop OS, there isn’t much choice but to learn to install RPMs frequently, learn Linux command line utilities, etc. Linux at the desktop is really the “fast track” to learning about Linux on a daily basis.
- Put Linux in a virtual machine on your workstation: You can either put a desktop version of Linux in a VM and try out things like the GroupWise client for Linux, OpenOffice for writing reports, etc, or you could install a Linux server product into the VM and learn to install web server components, play with user permissions and the like.
- Set up a full blown Linux test lab: Some mid-sized to larger companies will not even consider their move to Linux for GroupWise without a full test lab. This is a very good way to get to know GroupWise on Linux before you actually make the move. If you have External Document Storage Locations for GroupWise Document Management, we highly recommend that you build a test lab and model your current system. As you will see when we get to the moving of Document Storage Locations, this is probably the most time consuming and difficult part of moving to Linux.
There are many excellent resources for Linux available. We can’t even begin to list them all. Novell has some wonderful self-study kits; there are many good Internet resources; books galore. Find something that makes sense to you and have good reference materials at hand so that you can look up issues when they pop up. And don’t forget the folks at http://forums.novell.com to help with both GroupWise and Linux issues.
Special Considerations for Linux
Before we start, we will outline some of the special concerns about moving to Linux, and then we will start moving.
Here are a few things to consider before and during your move to Linux:
- You have two general options for GroupWise on Linux. You can choose SuSE Linux Enterprise Server (SLES) or Open Enterprise Server (OES). There are benefits to each, which will be discussed below. While some sites have done workarounds to make GroupWise run on Redhat, for example, we do not feel that it is in your best business interests to try to force this issue, especially since you essentially have SLES for free (see our discussion on server OS below).
- Linux has many more options for file systems, and depending on the version of Linux you use (SuSE Linux Enterprise Server or Open Enterprise Server) you will have different possibilities for file systems. We will discuss file systems in detail below.
- Linux is case-sensitive. GroupWise on Linux will expect all file names and directories to be all lower case. We will discuss options for getting there later in this chapter.
- Linux isn’t always easily accessible, at least not in the way you’ve become accustomed to with NetWare. What that means is that perhaps not all of your administrators will have access to ConsoleOne running in the GUI on your Linux server. As you move your primary domain to Linux, make sure you grant rights to all administrators necessary to administer the primary domain.
- Post Offices with DMS have three important issues to deal with:
- Document Storage Locations need to be redefined when you move them. You must make sure to indicate not only the UNC value for the document storage location, but also the “Linux” location for the documents. (Some sites prefer to move their documents under the post office before making a move to Linux, and quite honestly, if this is at all possible, it is our preference at this time. We will discuss the pros and cons of this as well when we discuss moving GW DMS to Linux).
- There is no Document Properties Maintenance applet available for ConsoleOne on Linux. Thus, you will need to enable Samba and access the post office via ConsoleOne on Windows to make changes to your document properties. If you are on OES, you can use NCP for access to the GroupWise databases.
- There is no GroupWise “Import/Export” applet for ConsoleOne on Linux. Many DMS sites use this tool for importing documents, fixing document number issues and the like. As above, you would need to run ConsoleOne on Windows in order to use this applet.
Once you have chosen your Linux distribution, you will need to make sure that a few items are installed when you install the server. While we do not intend to go through all of the steps of installing and configuring your Linux server, we will point out a few requirements and recommendations for the Linux server.
For OES, make sure that the following options are installed:
- NCP™ server
- Linux user management (if you wish to LUM enable your adminstrators for easy access to the GroupWise directories)
- GUI libraries (GroupWise dependencies)
- ncpfs to move your GroupWise domain from NetWare
For SLES, make sure the following options are installed:
- GUI libraries (GroupWise dependencies)
- Samba Server if you intend to manage your system later via ConsoleOne on Windows
- ncpfs to move your GroupWise domain from NetWare
The Great Linux File System Debate
When moving to Linux from NetWare or Windows, perhaps the most confusing issue is which file system to use. While both Windows and NetWare have multiple file systems (NSS vs. Traditional, NTFS vs. FAT), it has become fairly common for sites to simply use NSS on NetWare and NTFS on Windows without much thought about it. Linux has many file systems. Here are some of the file systems you will hear about:
Let’s talk about each of these in more detail.
- EXT2: This is essentially the second generation of the “Extended File System” for Linux, and was the default file system for many distributions until EXT3 came along. It is still often used for boot partitions and places where journalling isn’t terribly important.
- EXT3: This is the third generation of the “Extended File System” and includes journalling (i.e., changes are logged to a journal so that they can be replayed in case of a power outage or other failure, thus helping to prevent corruption in such cases). EXT3 is very popular and stable. It is, however, somewhat slow, especially when dealing with a lot of very small files (which is a common situation for GroupWise). That said, EXT3 is Novell’s stated recommendation for GroupWise 2012 systems.
- EXT3 with HTree: EXT3 has an optional function that creates additional indexes for the system, which can speed up the access of files tremendously. This would seem to be a very useful function for GroupWise. However, the nature of how these indexes are written worries the GroupWise developers greatly. While some smaller sites have enabled HTree without incident, there is a real possibility of data truncation when HTree is used on EXT3. For this reason, Novell obviously discourages the use of HTree on GroupWise systems. We defer to the engineers on this one. Caledonia does not wish to be the “source of authority” that promotes HTree only to later find out that indeed it causes even one customer to lose vital GroupWise data! Use something else. It is important to note that EXT3 has HTree turned off by default, so you would have to consciously enable it in order to sustain this risk. EXT4 enables HTree by default. EXT4 is, however, not yet widely used.
- XFS: XFS is a robust file system that provides for very fast access for large file systems and large files. While it seems like a very good choice for GroupWise on initial consideration, it also uses 64 bit calls that worry some of the GroupWise engineers. We do not know of any large test scenarios for GroupWise that have used XFS, so indeed we are also leery of this particular file system for GroupWise. In the future, if Novell releases some testbed benchmarks for XFS that remove some of these worries, XFS might be a good alternative file system. For now, we stay away from it.
- ReiserFS: Reiser is a very popular file system, and was the recommended file system on Linux for GroupWise for quite awhile. Reiser is still quite popular among Linux administrators. But as loved as Reiser is, it also has its detractors. Reiser seems more “fragile” than EXT3 when there is a problem. And of course, with the original developer of Reiser no longer available, no one really knows what the future holds for this file system.
- NSS: Technically, NSS is only available on OES Linux (we say technically, because there are of course possible ways of compiling SLES to allow for NSS, but when we speak of NSS we typically expect that you are running OES). While NSS on OES1 posed some problems, not only for GroupWise, OES2 NSS seems quite stable for GroupWise systems. Some sites will be very tempted to use NSS if for no other reason than their current NSS partitions can easily be converted over to their new Linux system without having to actually “move” the data (i.e., the Linux server will simply read the NSS drive that was on NetWare before). That said, “converted” NSS volumes will suffer many performance problems that a new NSS volume, configured with GroupWise in mind would not have.
Technically, while Novell Clustering Services is available for all supported file systems on OES 2, NSS will be the fastest for GroupWise in a cluster.
Perhaps the one reason why we would love NSS is the option of salvage. However, Novell recommends that if you use NSS for GroupWise, you turn off salvage!
Our recommendation for the file system depends in good part on where the GroupWise data will reside, and which Linux OS you choose. Here are, then, our recommendation:
- NSS for OES
- EXT3 on SLES
- What about ReiserFS?
NSS for OES
Our testing has shown that the following NSS setup is the best configuration for GroupWise:
- create a new NSS volume
- disable salvage at create time so no salvageable files will ever have existed on the volume
- change the default name space (again so none ever existed any other way) to UNIX
- enable the noatime option for your volume in /etc/fstab
- volname vol_mountpoint nssvol noauto,rw,name=volname,noatime 0 0
Our friends at NDS8 (http://www.nds8.co.uk) have seen as much as a 50% performance increase with this configuration over a “reused” NetWare NSS volume. So, while it is very convenient for sites moving from NetWare to Linux to not “move” the data, the very rich NSS features are largely unneeded for GroupWise, and there will be tradeoffs that might outweigh the initial time savings on the migration of data.
If you do choose to keep your current NSS volume, make sure that you do the following:
- Files and directories should be converted to all lowercase
- Turn off salvage completely
- enable the /noatime command in NSSCON
The conversion to lowercase can be done fairly quickly with free or shareware Windows utilities, or Linux scripts that change the case. We prefer a simple Windows utility called Change Case. It can be found at many download sites with a quick “google”.
Even knowing that we recommend against it, some sites will choose to “reuse” their current GroupWise NSS volume to avoid the downtime of a copy of the data. It is beyond the scope of this book to cover all aspects of moving an NSS pool/volume from a NetWare server to a Linux server. There is ample documentation for this process found on the Novell documentation site at http://www.novell.com/documentation/oes2/stor_nss_lx_nw/data/bt8gbxo.html.
There is of course one other reason to put GroupWise on NSS on your Linux server, and that is simply “comfort level”. Most NetWare administrators who are unfamiliar with Linux have a certain sense of security leaving their GroupWise systems on NSS. We are not going to argue with that!
All in all, NSS seems to be the best choice for GroupWise if you have it available, especially for clustering. It will be fast and stable. It will not, however, behave exactly as you are accustomed to on NetWare, especially if you take the recommendations to heart to pare down the NSS options for your GroupWise volume.
EXT3 for SLES
EXT3 is becoming the preferred file system for GroupWise on Linux when NSS is not available. It certainly has some speed issues, but we are not convinced that the benchmarks comparing EXT3 and Reiser are that noticeable in daily usage on GroupWise. Indeed, EXT3 is the default file system on OES 2/SLES 10 for native Linux partitions, and it is likely that this will remain the case for some time. There is one huge caveat that you must remember though: as tempting as the idea of HTree on EXT3 might seem, do not risk your GroupWise system to this indexing method. In the future, this could change, but as of the time of this writing, we cannot stress enough that this is a dangerous combination.
NOTE: Remember that HTree is not enabled by default, so a standard installation of SLES 10 or OES 2 will not turn this on without your knowledge.
What About ReiserFS?
ReiserFS is a popular file system for many Linux administrators. Certainly there is no immediate problem with using ReiserFS. That said, any administrator who has lost an entire ReiserFS partition and been forced to restore from the most recent backup will probably have been burned badly enough to not use ReiserFS again. But perhaps the biggest issue with ReiserFS is that there is no guarantee of the future of the file system. This one is still a “wait and see” situation. If you like ReiserFS and want to use it, we won’t object. Just know that future versions of OES or Linux may eventually deprecate or even stop supporting this file system. For now though, if it works for you, Reiser is still a very fast and useful file system for GroupWise.
Understanding Linux Mount Points
As we discussed above, we are not going to “teach you Linux” in this book. There are, however, various Linux concepts and ideas that we will expound upon and Linux Mount Points is one of those concepts.
If you wish to copy data directly from a NetWare server to the Linux server (which we will want to do!), you need to be able to see the data on the NetWare server from the Linux server.
In the NetWare world, for a NetWare server to access a volume on another server, everything is done via UNC paths (\\server\volume\path), or NetWare pathing (such as SERVER/VOLUME:\Path). Windows can also use UNC paths for the connection, or map a drive letter to the remote location.
Linux doesn’t really use UNC paths for anything. In order for Linux to access a file system on another server, Linux simply “mounts” that file system into its own file system hierarchy. In some ways, this is similar to how a Windows server (or workstation) might assign a drive letter to a volume on another server. If you mount \\gwserver\gwvol\gwdata to g: you now know that you can bypass entering all of the path to the server, and simply go to “g:” to access the GroupWise data volume.
Likewise, in Linux, a “mount point” is created for the \\gwserver\gwvol\gwdata location, and then you simply navigate to that directory on your Linux server and you see all of the files on the NetWare volume that you have mounted.
Traditionally, Linux puts all of the “external mount points” into the directory structure under /mnt. There is no technical requirement for putting your mount points in /mnt, but it is a nice, standardized location for them, so we will use that for our examples.
So, let’s say that we wanted to be able to see all volumes on our NetWare server where the current GroupWise system resides. We could create a /mnt/netware directory for the structure, or we might prefer to create directories by server name. If we were to choose the latter, we might create a directory called /mnt/gw1 for a NetWare server called “gw1”. Indeed, ConsoleOne expects you to use the /mnt/servername format to mount your GroupWise servers when administering a multi-domain GroupWise system from Linux.
The following are instructions on how to mount volumes from a NetWare server into the Linux file system.
To mount the NetWare volumes into our Linux file system, we would perform the following steps:
- On the Linux server, open up a terminal window.
- ”su root” to become root for this session.
- Create a directory structure for your mount point. For our purposes, we have created /mnt/gw1 as the mount point for our NetWare server.
- We have chosen to connect to our NetWare server via ncpfs. To mount the NetWare server via ncpfs, issue the following command
ncpmount -S server -A 184.108.40.206 -U userid -P password /mnt/gw1
replacing your server name for “server” and your server’s IP address for 220.127.116.11. For example
ncpmount -S gw1 -A 192.168.100.200 -U danita.cnc -P password /mnt/gw1
NOTE: You might wonder about the “user.context” vs. “.user.context” in this example. While “.user.context” works on some versions of Linux, it fails on others. In our testing, “user.context” has always worked on all versions. You might keep this in mind if you experience any problems authenticating with ncpmount.
This will actually mount all volumes from the NetWare server to this location. So, if we cd to /mnt/gw1 we will see a directory called SYS, one called GWDATA, and any other volumes that are on that server.
If you look at your current GroupWise domain and post office directories, you will notice that many files and directories are in all uppercase, and many are all lowercase. It is important to know that while both NetWare and Windows “respect case” during the “save” process, neither of them “discriminate case” upon reading. Now, this might be a long way around saying they are not “case-sensitive,” but it’s an important concept to understand. Let’s take an example. If a user is creating a WordPerfect document and chooses “File|Save As,” typing in MyLetter.WPD will show the “case” distinctions in this document name when viewed in Explorer or from a command prompt. However, another document named myletter.wpd cannot be saved in the same folder.
Linux, however, is absolutely case-sensitive. MyLetter.WPD, myletter.WPD, MYLETTER.WPD and myletter.wpd are four distinct file names. All four documents can legally exist in the same Linux directory as separate and distinct files. This is not a huge problem when moving domains and post offices to Linux, except that you must be aware of the issue and deal with it. All files and directories for the Linux domain and post office must be all lowercase, otherwise the agents will simply not see the “proper” file and will fail to load. Prior to loading the POA on Linux, we will need to change the case of all files and directories for the post office. Indeed, during the migration of the data using Novell’s DBCopy utility, we can use the “migrate” switch to force all file names to lowercase. Thus, any migration that we do, other than the possibility of reusing an existing NSS volume that we discussed above, will automatically change the case for us. If you wish to reuse your existing NSS volume on your Linux server, you can use a Windows utility called “Change Case” or you can use a Linux script to do the change for you.
NOTE: If you are using NSS volumes for your GroupWise data on Linux, you can enable the “Long Namespace” option. This essentially removes the case sensitivity from the volume. If you do that, you might think that you would not need to change the case of the GroupWise files. However, we have found multiple instances where things fail because of case in this situation. You must ensure that the case be changed for all GroupWise data on Linux. And indeed, if you will have a mixed OS system for any length of time, all of your domain directories should be changed to lowercase right away. In order for ConsoleOne on Linux to properly access domains on Windows or NetWare, the domain directories on Windows and NetWare must be all lowercase for all files and directory structures. For very simple systems where all of the components of GroupWise will be moved to Linux right away, this is not an issue. But if you ever intend to access a domain database on NetWare or Windows directly from your Linux server, you should go ahead and deal with the case issues for the domain directories now. Indeed, in the chapter entitled “Moving and Upgrading Your Primary Domain” we do access the primary domain directory that resides on NetWare from the Linux server, and for that reason need the domain directory case changed before we ever move a domain to Linux.
The easiest thing to do is simply download a free Windows utility called “Change Case”. There are Linux scripts that can do this as well, but we recognize that most people reading this book are new to Linux, and we want to make this as painless as possible. There are many locations for this Change Case utility, and we do not wish to favor one download site over another. So just google for “change case utility”. If you have difficulty finding this utility, e-mail us at firstname.lastname@example.org and we will point you in the right direction. The important thing is that no matter what you use to change the case of your domain directory, all files and subdirectory names must be all lowercase. And of course make sure that you unload your MTA and any associated gateways and kick everyone out of ConsoleOne before you attempt to change the case so that there will be no access conflicts.
Making Linux Accessible to your Administrators
GroupWise is one of those applications where we rarely worry about giving users access to the actual file structure. Administrators, however, need physical access to the domain database and often to the post office databases and files themselves. There are three ways to manage this:
- Use ssh utilities to access the GroupWise server, and manage GroupWise through ConsoleOne directly on the server.
- Use Samba on SLES to access the GroupWise databases from ConsoleOne on Windows.
- Use NCP on OES2 to access the GroupWise databases from ConsoleOne on Windows.
Running your GroupWise Agents as Linux Daemons/Windows Services
Perhaps one of the most difficult transitions for GroupWise Administrators (especially those running GroupWise on NetWare), is getting used to the idea that you will no longer have a GUI console for your agents. While many Windows administrators are accustomed to running their agents as services with no console screens, this is a very foreign concept to GroupWise Administrators who run GroupWise on NetWare. This is something that you simply must accept. No amount of arguing or begging will change the fact that while there are GUI Consoles on Linux and Windows that can be used for testing, you should rarely (we’d rather say never) use the GUI Console for the agents in production on a Linux or Windows server. In order to use the GUI Consoles, the user running the GroupWise agents must always be logged into the Linux or Windows server. This is not something that is recommended by Novell or Caledonia, and it is definitely seen as a taboo by both Windows and Linux administrators. You will need to learn to love the HTTP Monitors for the GroupWise agents. If you have never used the HTTP monitors before, we’ll walk through enabling them, and looking at their features.
Novell has a utility called the GroupWise Server Migration Utility. The purpose of the utility is to facilitate the move of GroupWise systems from NetWare to Linux or Windows. In this book partly because we wish to avoid installing an “older” version of GroupWise on your new Linux server, and partly because we think understanding the move is important, we will teach you how to move your GroupWise system to Linux entirely by hand. We think this is the best way to approach the move. That said, however, there are people who just like to have a GUI and a Utility to assist them through such moves. While we will not use the GroupWise Server Migration Utility in this book, we will not be hurt if you decide to use the utility for your move. The knowledge about what happens “behind the scenes” in a move to Linux that you will gain from this book will help you should anything go wrong during the use of the migration utility. So, if when the time comes to do the move you decide to use the migration utility, hopefully you will be able to approach the migration tasks with increased confidence in your abilities and better understanding of the processes behind the migration. Understand though, that the Migration Utility will not perform a move and an upgrade simultaneously. The only way to use the Migration Utility is to migrate at your current version of GroupWise to Linux, and then after the system is running on Linux, perform an upgrade.
You will need to install the Novell Client for Windows on any Windows server that will install and run GroupWise agents. If you do not have the Novell Client installed on your server, you can download it from http://download.novell.com.
Extracting Your Software
Once you receive your GroupWise 2012 media (typically as a download from your Customer Portal), you will of course be very anxious to get started! For the Windows version, if you download the software it will most likely be in a self-extracting EXE file or a ZIP file. You can unzip it with your program of choice into your new Master SDD location. If you are downloading the Linux files, they will be in a tar.gz file. Use tar -xzf to extract it. For example, in the directory where you wish to make your Master SDD (perhaps /grpwise/gw12soft):
tar -xzf gw12.0.0-97810_full_linux_en.tar.gz
Most sites will want to place the GroupWise software in an accessible location out on the network. Where you put it is up to you, but it must be accessible from the Linux or Windows server where you will install GroupWise.
The most important part of our installation for the migration needs to be installed before we proceed.That component is the GroupWise DBcopy application. DBcopy is a utility that was originally developed by Novell as a backup tool. DBcopy can copy GroupWise databases while they are open, thus ensuring a good backup without worrying about files being skipped because they are open. Over the years, DBcopy has been optimized to also include functionality needed for a move or migration of GroupWise from one location to another.
If you will be moving a post office to a Windows server, you will want to have access to Novell’s DBCopy utility. This is found in the \admin\utility directory of your software distribution. You can copy the DBCopy files to another directory on your Windows server, or simply run the program from the directory in the software distribution.
In order to install DBCopy, we will need to drop to a terminal window.
- In the terminal window, change to the directory where your extracted GroupWise distribution files are located. There is an admin directory in this directory structure.
- Change to the admin directory, and you will notice a number of files, including one for novell-groupwise-dbcopy. The remainder of this file name will vary, depending on the version of GroupWise that you are installing.
- We will now install DBCopy by executing the following command:
rpm -Uvh novell-groupwise-dbcopy-8.0.1-88138.i586.rpm
Of course the above file name is the one for our distribution. Your file name may vary.
- Once the rpm has been installed you will be returned to the terminal prompt.
- You can verify that DBCopy has been installed by typing:
With the initial server preparation done, we can now start our GroupWise components move. We will begin with a domain move in the next chapter.