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 NetWare or 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. Getting a core dump on a NetWare server can take a long time. 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 NetWare and Windows to provide ease of administration, neither can 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 Novell has made the following pretty clear: NetWare as an operating system is going away. We say “NetWare as an operating system,” because many people have difficulty separating NetWare the OS from the services they have come to equate as NetWare. For example, to many sites, NetWare means iPrint, eDirectory, iFolder, NSS, etc. All of these “services” that were essentially built on top of the NetWare operating system seem part and parcel of the experience that Novell shops have. However, NetWare really is the OS, and the services should be thought of more as applications that run on that operating system. Moving those applications to Linux seems to be the logical step for many sites, because if NetWare is “gone” and we want to keep our Novell applications, then Linux is where to be.
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’ve been told that NetWare is going the way of the Dodo, and we need to get out while we can. 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?
- Our NetWare server is getting old. 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, but our boss has been told that “NetWare is dead” and he wants us to get rid of all of our NetWare servers ASAP. 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 email if that new Linux server isn’t well understood, but actual data loss is unlikely.
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! 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 NetWare 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 a move is absolutely mandated, but 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 in the future. 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.
Before we start, we will outline some of the special concerns about moving to Linux, and then we will start moving. Because we like scenario #2 above so well, we’ll follow that proposed path in this book. I.e., we will start off by either moving a domain to (or creating a domain on) a Linux server for the GWIA and/or WebAccess. Once we have that done, we’ll go through the steps of moving a post office over.
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. If you intend to 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 OES2, 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.
Choosing your Linux
When dealing with GroupWise, you have two supported (and accepted) options for your Linux Server: SuSE Linux Enterprise Server (SLES) and Open Enterprise Server (OES).
Depending on your version of GroupWise, your choices within these products will also be limited. While GroupWise 7 runs on both SLES 9 and SLES 10, and OES1 and OES2, GroupWise 8 (especially with SP1) is only supported on SLES10 or OES2. While these are all very similar, there are distinctions between SLES and OES that are important to discuss.
- Novell still ships GroupWise with SLES licenses. You can deploy a GroupWise system on SLES without having to incur any additional licensing costs. You can install as many SLES servers as are necessary to accommodate your GroupWise system. For some installations, this can be a huge cost savings. For many small GroupWise systems, the added benefits of OES are not really important, and SLES is a good choice.
- OES – in addition to all of the features of SLES (on which OES is based), OES gives you the following benefits:
- Integrated with eDirectory
- Can allow NCP access to all file systems
- Linux User Management
- Novell Remote Manager
- Novell Clustering Services
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 if you are moving your GroupWise domain from NetWare
- smbfs if you are moving your GroupWise domain from Windows
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 if you are moving your GroupWise domain from NetWare
- smbfs if you are moving your GroupWise domain from Windows
The Great 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).
- 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 was 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. We no longer recommend using Reiser for GroupWise systems.
- 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 and OES11 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, 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
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 datae. 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. 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 OES2/SLES10 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 SLES10 or OES2 will not turn this on without your knowledge.
Understanding Linux Mount PointsAs 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. If we are moving from Windows to Linux, we technically would have two different options. One would be to run DBCopy from the Linux server, accessing the source files on the Windows server, and copying them down locally to the Linux server. The other would be to map a drive from the Windows server to the Linux server via SAMBA or CIFS, and copy the local files from the Windows server over to the Linux server. We prefer the former, simply because we think the Linux DBCopy is faster, but certainly you could do either. We’ll discuss this more when we get down to moving data.
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. We will have very similar instructions for Windows using smbfs, and will detail those in the chapters where we migrate from Windows to Linux.
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 126.96.36.199 -U userid -P password /mnt/gw1
replacing your server name for “server” and your server’s IP address for 188.8.131.52. 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 “Creating a New Domain on Linux to Relocate a Gateway” 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, email 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.
We will discuss the administration of your GroupWise system more in our chapter entitled “Tips and Tricks for GroupWise on Linux” later in this book. Just know that in order to administer GroupWise on Linux, you still use the same tool (ConsoleOne) and this can be done directly on the GroupWise server itself, or from a Windows workstation.
Running your GroupWise Agents as Daemons
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 is a GUI Console on Linux that can be used for testing, you should never use the GUI Console for the agents in production. In order to use the GUI Consoles, the user running the GroupWise agents must always be logged into the Linux server. This is not something that is recommended by Novell or Caledonia, and it is definitely seen as a taboo among 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.
The GroupWise Server Migration Utility
Novell has a utility called the GroupWise Server Migration Utility. The purpose of the utility is to facilitate the move of GroupWise systems from Windows or NetWare to Linux. In this book 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.
Time to Move
Now that we’ve looked at the decisions behind moving to Linux, lets start actually moving. In the next few chapters we will do the following:
- Move a domain to Linux
- Move a domain and GWIA to Linux (and in some cases create a new domain for this purpose)
- Move a domain and WebAccess to Linux (and in some cases create a new domain for this purpose)
- Move a post office to Linux
- Move an external Document Storage Location to Linux