- The Case for Linux
- Preparing your New Linux Server
- Moving a Domain with No Gateways – Linux
- Moving a GWIA – Linux
- Moving WebAccess – Linux
- Creating a New Domain on Linux to Relocate a Gateway
- Moving a GroupWise Post Office to Linux
Now that your GroupWise components have been successfully migrated to Linux, we have a few tips to share that can make your life a little better. We will discuss the following:
- Administering your GroupWise system with ConsoleOne from both the Linux server and Windows workstations
- gwha.conf and what it means to you
- starting and stopping agents on your Linux server
Administering your GroupWise system from Linux and Windows
When moving your GroupWise system to Linux, one of the most misunderstood (or perhaps poorly understood) aspects of administration is ConsoleOne. Do you run ConsoleOne on the actual Linux server where GroupWise exists? Do you run it from a Windows workstation? Or do you have a need to do a little of both?
It has long been a point of discussion as to whether it is indeed safe to administer the GroupWise system on Linux from a Windows workstation, and the discussion continues to rage. However, Novell has stated that as long as your system is on at least GroupWise 7.02 (and it SHOULD be), then administering GroupWise on Linux from a Windows workstation, via either SAMBA or NCP, is safe. Thus, we will discuss how to best manage GroupWise with ConsoleOne in a mixed environment that finds you using ConsoleOne both on the local Linux server, and on Windows workstations.
Here’s the basic problem. Linux doesn’t really understand UNC paths. Linux sees ALL drives that it has access to in the context of its own file system. For example, if on your Linux server you want to do the equivalent of “mapping a drive” to a NetWare server, you create a directory on your Linux server, and “mount” that NetWare volume to that location. On Linux, this might very well look like:
/mnt/server/vol2/domain for NetWare
/mnt/server/d$/domain for Windows
This actually seems to be a relatively easy concept for most GroupWise administrators to grasp once they are exposed to the idea. It’s the “local” GroupWise domain that causes great consternation. Let’s look at a couple of issues with the local GroupWise domain. Our domain exists at /grpwise/domains, as shown in Figure 9-1.
If we leave the domain location as the Linux Path, ConsoleOne on the local Linux server will work perfectly, and all snapins for the GWIA, WebAccess Agent and the like will be available without problem. However, if we leave this Linux path there, a Windows PC can map to the domain, open ConsoleOne, etc., but all of the snapins for the GWIA and WebAccess will be missing, because /grpwise/domain/wpgate/gwia means nothing to the Windows box! In other words, ConsoleOne reads the information in the domain properties to build paths to all other GroupWise components.
So, what if we change the path in ConsoleOne to the UNC path of \\server\grpwise\domain as shown in Figure 9-2?
If you now map your Windows drive to \\server\grpwise\domain you will be able to connect to the domain and edit your gateways with no problems. However, on the Linux server itself, the gateways will not have their proper snapin tabs, because the Linux server has no idea where \\server\grpwise\domain is.
Enter the “Linux mount directory” setting in the Linux ConsoleOne. In ConsoleOne on Linux, go to Tools|GroupWise System Operations|System Preferences|Linux Settings and enter a “mount point” for your domains. This can really be anywhere you like, but it’s fairly common for /mnt to be the “mount point location” for placing links to external systems.
If you have entered \\server\grpwise\domain as the UNC path for your domain, after you have a mount point of /mnt defined in ConsoleOne, looking at the properties of the domain will now show /mnt/server/grpwise/domain as shown in Figure 9-3.
Now, it’s important to note that what we see here in this figure ONLY happens on the Linux machine. The Windows PCs still see the location of the domain in UNC format.
If you look in your /mnt directory though, it’s unlikely that you see a /mnt/server/grpwise/domain directory! This is accomplished either by “mounting” a drive in Linux (i.e., to an external NetWare, Windows or Linux server), or simply creating a symbolic link (symlink) to the local path for your domain. Since our domain is at /grpwise/domain on our local server, we can do the following in the /mnt directory location:
ln -s / server
This assumes that my server name is “server”. This command creates a symlink to show the files from “/” under the “server” directory. Now ConsoleOne can find my domain at /mnt/server/grpwise/domain, and the Windows boxes can map a drive to \\server\grpwise and also see the domain there with no problems.
NSS volumes on OES servers cause a bit of a twist here too. The UNC path of \\server\MAIL\grpwise\domain might actually be a path on your OES server of /media/nss/MAIL/grpwise/domain (with “MAIL” being the volume name for your server). In this case, your mount point in the /mnt directory would need to be /mnt/server/MAIL/grpwise/domain, so you would issue this command in the /mnt directory:
ln -s /media/nss/ server
Again, we are assuming that my server name is actually “server”. This would mount the /media/nss/ directory into /mnt/server/ and show you all of the volumes for that server, including the MAIL volume. Don’t forget that NSS volumes are all shown in all caps in the Linux file system, so be sure to keep your case proper in both the UNC path and in the mount point.
We mentioned in previous chapters that grpwise and rcgrpwise scripts are created during the configuration of GroupWise agents on Linux. Any time you run one of these commands, the script looks at a file called gwha.conf in the /etc/opt/novell/groupwise directory on your Linux server. This file tells the script which agents to launch, and where the startup files are for these agents. You can think of it as similar to the grpwise.ncf on NetWare. Of course, on Windows, this is either handled by the startup folder or the services manager.
Here’s what the gwha.conf file looks like for a typical GroupWise server:
ssl = no
server = /opt/novell/groupwise/agents/bin/gwmta
command = /etc/init.d/grpwise
startup = caledoni.mta
delay = 2
wait = 10
server = /opt/novell/groupwise/agents/bin/gwpoa
command = /etc/init.d/grpwise
startup = highland.poa
delay = 2
wait = 10
server = /opt/novell/groupwise/agents/bin/gwia
command = /etc/init.d/grpwise
startup = gwia.cfg
delay = 2
wait = 10
This particular file is also used for the GroupWise High Availability Agent, which can be used in conjunction with GroupWise Monitor to check the status of your agents and reload them if they are found to not be loaded.
The first section under [gwha] is used for the GroupWise High Availability Agent, and defines whether the agent will talk SSL to the GroupWise Monitor. The next sections reference which agents should be running on this server. These sections are what the grpwise script looks at when it is called in order to start the agents on your server.
Each section has a name, which corresponds to the output you see when you invoke the grpwise status command. For example, here is what the grpwise status command shows on our server:
Checking status [Caledonia] running
Checking status [Highlands.Caledonia] running
Checking status [GWIA.Caledonia] running
Checking status [WEBAC80A] running
If you ever run into difficulties where a particular agent will not load, or shows “unused” in the status, one place to check is this gwha.conf file to confirm that the startup file names are correct.
This now brings us to the next section on starting agents individually.
Starting and Stopping Your GroupWise Agents
In this section, we will discuss starting and stopping your GroupWise Agents as follows:
- Using the grpwise script
- Manually from a terminal prompt
- Forcing agents to terminate
Starting and Stopping Your Agents with the grpwise Script
As we discussed in the chapters on moving your GroupWise components, the installation routine for GroupWise creates both an /etc/init.d/grpwise script and an rcgrpwise script which can be run from anywhere. These scripts read the gwha.conf file in order to know how to load your agents. Commands that we discuss for the rcgrpwise script are also valid to use for the /etc/init.d/grpwise script.
When you run rcgrpwise will no other options, the script attempts to load all agents that are in the script. Thus, if you have an MTA, POA, GWIA and WebAccess Agent all running on the same server, the rcgrpwise script will attempt to launch them all. This is very handy of course, but often leaves new administrators wondering how to manage the agents individually.
The rcgrpwise script has a number of options as follows:
- rcgrpwise start (starts all of the agents)
- rcgrpwise stop (stops all of the agents)
- rcgrpwise status (shows the status of the agents).
If you wish to stop only one agent in your list, you must know the name of the agent first. As we saw above, running rcgrpwise status shows a list of all agents and their names. Thus, if we wanted to stop the MTA for the domain Caledonia, we would type:
rcgrpwise stop Caledonia
Likewise, to stop the WebAccess Agent on this server we would type:
rcgrpwise stop WEBAC80A
Then to restart an agent we would type
rcgrpwise start WEBAC80A
Starting Agents Manually from a Terminal Prompt
When we first loaded our agents during our migration, we used some command line statements in order to control startup options and the like. Any time you are having difficulty loading an agent through the rcgrpwise script, it is good practice to attempt to load the agent manually to see if any additional errors are listed.
Agents are always installed in the /opt/novell/groupwise/agents/bin directory on Linux. Startup files are always created in /opt/novell/groupwise/agents/share. It is possible to put your startup files elsewhere, but it is good practice to leave them in this directory.
Starting Temporarily from the Command Line
In order to startup a GWIA from the command line, you would simply type:
This would load the GWIA, but you would not be returned to a command prompt. Closing the terminal window, or pressing Control-C would then shut down the GWIA. This method is really only useful as a quick check to make sure the GWIA is loading properly.
Backgrounding from the Command Line
If you issue the same command as above, and end the command with an ampersand, you will “background” the command.
This loads the GWIA, and gives you back control of the command line. The GWIA will now run in the background as though it were started from the rcgrpwise script.
Using Startup Options for Agents
So, that is all well and good, but there isn’t much reason for you to do the command immediately above. You could have, of course, just used the rcgrpwise script for that. However, you might want to start the agent with temporary switches, or even the –show command (as we did in our earlier testing).
By loading the GWIA (or any agent) manually, and using command line switches, you can override the current settings and use new settings for that session. For example, you might need to bring up a POA with verbose logging temporarily, or try your GWIA with a different host name switch to test a PTR record. That type of a command would look like this:
/opt/novell/groupwise/agents/bin/gwia –hn newmail.caledonia.net @gwia.cfg
Forcing Agents to Terminate
Sometimes bad things happen to good agents! You may find that a GroupWise agent is running, and the rcgrpwise script will not terminate it. When this happens, you must rely on some other commands to help you out. Here are a few ways to do this:
Killing Processes at the Command Line
If you cannot unload your agent with the rcgrpwise command for whatever reason, try these options:
First, issue this command in the terminal window (substitute the command for whatever agent is stuck):
ps -A | grep gwpoa
This should just return you to a terminal prompt indicating that no instances of gwpoa are running. If you see something like this:
9980 pts/3 00:45:23 gwpoa
you will need to kill the process. First try a command like this
notice that 9980 was our process number in the above list. Substitute the number for your gwpoa process here. Try the ps -A | grep gwpoa again. If this still persists, try this:
Killing Processes with the GUI
You can also use either KSysGuard or the Gnome System Monitor to kill a process. While these are hidden away somewhere in your menus on Linux, simply going to a terminal and typing ksysguard if you use KDE or gnome-system-monitor if you use GNOME will bring up the application. This will look similar to the Windows Task Manager. Find the process that will not go away, right-click and choose Kill or Stop, depending on the version of the application you are using.
With GroupWise on Linux, it is likely that you will need to access other servers from time to time. This might be NetWare, Windows or Linux servers. There are many ways to access the files on other servers from Linux. This section is not intended to be exhaustive, but should give you some direction for when you need to access files on other servers.
Create a Mount Point for a NetWare Server
To attach to a NetWare server from a Linux server, 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 that is named gw1. It is suggested that you replace gw1 with the actual name of your NetWare server for ease of recognition later.
- 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 my 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 will will see a directory called SYS, one called GWDATA, and any other volumes that are on that server.
Create a Mount Point for a Windows Server
If you are moving your domain from Windows, you need to attach to the Windows server from your new Linux server. To mount the Windows drives into your Linux file system, perform the following steps:
- On the new 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 Windows server that is named gw1. It is suggested that you replace gw1 with the actual name of your Windows server for ease of recognition later.
- We have chosen to connect to our Windows server via cifs. To mount the Windows server via cifs, issue the following command:
mount -t cifs //server/d$ /mnt/name -o username=user,password=password, domain=domain or workgroup
This command is all one line, and there is no space between the comma following password and the word domain. You can use the entire drive (d$) or a specific share name. We like to use the drive (d$) when possible, but the share works as well. If for some reason you have difficulty mountinby by server name, you can substitute the IP address of the Windows server in the //server/d$ portion (i.e. //192.168.100.201/d$).
So, for example, our command would be
mount -t cifs //192.168.100.228/d$ /mnt/aberdeen -o username=danita,password=pass,domain=caledonia
Create a Mount Point for a Linux Server
There are, of course, a myriad of ways to connect from one Linux Server to another. We are not going to attempt to cover them all! Since this is a GroupWise server, we can assume that you are either using SLES or OES2. With that in mind, you can connect to your Linux servers the same as we outlined above for NetWare and Windows. You will choose which method depending on your server and access methods available. If the Linux server you are connecting to is OES2 and is using NCP for access, follow the instructions for NetWare. If the Linux server you are connecting to is granting access to the server via Samba, use the instructions as outlined above for connecting to a Windows server.
Of course, there are more native Linux methods for connecting, such as NFS. But since NFS and GroupWise do not go well together, we discourage the use of NFS on a Linux server.