In this chapter, we are moving a domain that owns no gateways to a new Linux server. It is acceptable for this domain to own post offices, and to leave those post offices behind on the source server. It may even be that you are moving this domain first, in preparation for moving your post office immediately after. For this particular task, the only important point is that the domain does not own any gateways. If you need to move a domain that owns gateways, please see the Chapters on “Moving a GWIA – Linux” or “Moving WebAccess – Linux”.
In the previous chapter, we installed the DBCopy utility that we use to migrate the data from the source server to the new Linux server. Additionally, during the setup of your server, you installed ncpfs, which allows us to attach to a NetWare server via NCP and/or smbfs which allows us to attach to a Windows server to copy the data. The steps we will take are as follows:
- Create a mount point for the source server. Technically, we do not need to create a mount point if your are moving your GWIA from one Linux server to another. We will do the copy of the files with scp (Secure Copy) when we get to the section on copying the files.
- Unload the existing Message Transfer Agent (MTA) for this domain. We will need exclusive access to the domain database, so no gateways should be loaded. This should not be an issue, because in this section we are specifically moving a domain that has no gateways. If you need to move a domain that owns gateways, please see the chapters on “Moving a GWIA – Linux” or “Moving WebAccess – Linux”.
- Rename the domain directory to avoid any accidental access while we are relocating the domain.
- Ensure that all file and directory names for the domain are lowercase.
- Copy the domain directory structure from it’s current location to the new Linux server using DBCopy from NetWare or Windows, or simply scp from Linux.
- Load ConsoleOne and edit the domain location, agent address and link information if necessary.
- Configure the MTA on the new Linux server.
- Load the MTA for the relocated domain.
- Verify that the MTA is communicating with any post offices it owns, and any other domains for which it has direct links.
So, let’s see how this all works.
Create a Mount Point for the NetWare Server
If you are moving your domain from NetWare, you need to attach to the NetWare server from your new Linux server. To mount the NetWare volumes 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 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 the 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 mounting by 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/gw1 -o username=danita,password=pass,domain=caledonia
Unload the MTA
First of all, go to the server where your MTA is loaded for the domain that you are moving:
- NetWare: press F7 at the agent console to unload the agent
- Windows: if the agent is running as an Application, you can also press F7, or use the File Menu and Exit. If the agent is running as a Service, you must stop the agent from the services applet.
- Linux: use rcgrpwise command. For example:
rcgrpwise stop DomainName
If you are not certain of the name that is defined for your domain in the rcgrpwise script, first run:
This will show you all agents that the rcgrpwise script controls. Find the name for your MTA and then issue the stop command for your MTA.
Also make sure that no administrators are accessing the domain database through ConsoleOne.
Copy the Files to New Linux Server
After the MTA is unloaded, we will prepare to copy the domain structure to the new Linux server. Let’s look at the current directory structure of our domain. Figure 4-1 shows the domain directory for our domain. Notice that on NetWare and Windows, most files and directories are in all uppercase (this is also dependent on your GroupWise version and more recent versions create everything lowercase to avoid problems down the road).
All files and directories for the domain and post office on Linux must be all lowercase, otherwise the agents will simply not see the “proper” file and will fail to load. Prior to loading the MTA on our new Linux server, we will need to change the case of all files and directories for the domain. We will use DBCopy for this purpose. If you are moving your domain from one Linux server to another, your file names are already all lowercase, and you will not need to concern yourself with this step.
Once we are ready to move the domain directory structure to our new Linux server, we will rename the domain directory to avoid any accidental access by administrators using ConsoleOne, NWADMIN, etc. DBCopy makes no changes to the original files in the domain directory. If needed, you could simply rename your domain directory back to its original name and load your MTA back up on the source server.
If you are moving your domain from one Linux server to another, there is very little reason to use DBCopy. Instead, you can simply use scp to copy the files over ssh. In order to use scp, you would issue a command like this:
scp -r /currentdomain user@newserver:/location
The -r switch tells scp to copy all subdirectories recursively from our current domain location to the requested location on the new server, and which user to log in as for the copy.
For example, if our current domain is at /grpwise/domains/cnc2.old (which we have now renamed to avoid accidental access), and it will go to server gw2 at /grpwise/domains/cnc2, our scp command would look like this:
scp -r /grpwise/domains/cnc2.old danita@gw2:/grpwise/domains/cnc2
If you ever have issues connecting to a source server from your Linux server by name, you can always replace the server name with the server’s IP address in the command. So, for example, danita@gw2 or email@example.com are both valid ways to use this command.
After you have copied your files over to the new server, skip down to “Edit Important information in ConsoleOne” and continue from there.
From NetWare or Windows
For those of you moving from NetWare or Windows, you will find that DBCopy on the Linux server does not run well from any directory other than /opt/novell/groupwise/agents/bin so we will cd to that location to run the utility. Run DBCopy to copy your files from the source server to the Linux location like this:
./dbcopy -m -d <source> <destination>
so for our situation it would be
./dbcopy -m -d /mnt/gw1/GWDATA/domains/cnc2.old /grpwise/domains/cnc2
This will copy all needed data from the old domain directory into the directory structure that we’ve indicated for the destination. In our case, we have chosen to locate our domain in /grpwise/domains/cnc2.
The -m switch copies the files over in all lower case. The -d switch tells DBCopy that it is migrating a domain. Generally this will not take long at all to perform the copy. Unless you have many files in your existing MTA queues, there is not really much to copy!
NOTE: It’s a good idea to look through your domain directory structure for old log files, files in the problem directories, etc. to clean up prior to copying the directory structure. This wlil ensure that you don’t needlessly copy unneeded information to the new server.
Now that your domain directory has been migrated to the new Linux server, we need to edit the location of the domain directory and fix some information in the agent’s network address configuration.
Since it’s a good exercise to learn to access ConsoleOne directly on your Linux server, we’ll do that for this task.
- When we installed ConsoleOne earlier, the installation routine should have created a shortcut to the application on your desktop. If you cannot find this shortcut, we can load the application by hand simply by running /usr/ConsoleOne/bin/Consoleone.
- The first time you launch ConsoleOne for Linux with GroupWise snapins, you will be presented with a screen like Figure 4-2.
- Assuming you wish to have your GroupWise server mount points in /mnt, leave the setting as it is and click okay. This mount point location for GroupWise is very important, and we discuss this in detail in the chapter entitled “Tips and Tricks for GroupWise on Linux”.
- You should now be presented with a login prompt. If for some reason the login prompt does not appear, click on NDS under My World, and then click on the tree icon in the toolbar. Log into your tree as you normally would if this were a Windows workstation. Note, however, that if you cannot find the tree, putting the IP address of one of the eDirectory servers in the tree field should help you with that. On our systems, sometimes the login box seems to not allow us to click in the password field to enter a password. If that happens, simply attempt to login with no password. You will receive an error that the password is incorrect, but then the login box will refresh and correct itself.
- Once you have logged into your tree, click on the “GroupWise System” next to the Globe.
- Now, from the menu choose Tools|GroupWise System Operations|Select Domain.
- Enter the Linux location for your domain. In our case, we put our domain in /grpwise/domains/cnc2. You can also browse for your domain directory if necessary.
- Once GroupWise opens the domain database, you should see your GroupWise system under the globe. This is a really good time to point out that you will be required to open your domain every time you load ConsoleOne on Linux. Unlike on Windows, where ConsoleOne remembers where your domain last was and automatically connects you back to the last domain you accessed, ConsoleOne on Linux requires you to go through the Tools|GroupWise System Operations|Select Domain process each time. You will find this particularly frustrating once you see that this location is remembered for you and filled into the Select Domain field, but will not automatically connect until you perform these steps.
- Right-click on the GroupWise domain you have moved to your new Linux server, and choose Properties.
- For now, you will see that your domain says it is location somewhere like /mnt/gw1/GWDATA/domains/CNC2 (which is the source server location in your mount point). Change this to reference the actual Linux path in the UNC Path field – you can browse for this if necessary. In our case our path is /grpwise/domains/cnc2. Note that this really isn’t a UNC path, but we will change this later when we discuss mount points and UNC paths in the “Tips and Tricks for GroupWise on Linux” chapter. When you have your Linux path in this field, click OK.
- Now, in the dropdown list that shows “Users”, change the setting to “Message Transfer Agents.”
- Find the MTA for your domain, right-click and choose Properties.
- On the first screen, change the Platform to Linux.
- Now click on the triangle in the GroupWise tab and change to Network Address. Here you must change the IP address to that of the new Linux server.
- Before you leave the Network Address tab, make special note of the HTTP port that is defined for this agent. By default, the HTTP port for the MTA is 7180. As we noted earlier in this book, since we will not have a GUI console for the MTA, you will want to ensure that you have the HTTP monitor configured properly so that you can access it for monitoring your MTA. If there is nothing in the HTTP port field, put 7180 (or another port of your choosing).
- Now, on the GroupWise tab, change to the Agent Settings screen. Notice the HTTP Monitor settings. If you have never enabled the HTTP monitors for your agents, you will need to decide on a good userid and password for the HTTP monitors. Please note that this is neither an eDirectory user nor a GroupWise user. This is an entirely made up user and password solely for the use of the HTTP monitors. If all administrators in your organization will have rights to use the HTTP monitors, then it is a good idea to have the same userid and password for all agents. If you need to limit rights to some agents to various groups, set up a userid and password for each group of agents that will be monitored. Enter the userid and password that you have decided on here in this screen.
- On the GroupWise tab, change to the log settings. If you have a custom path for the log settings, remove it. While it is technically okay to make a new custom path for your Linux agent logs, unless you have an overriding reason to have the logs somewhere other than the default, it’s best to just leave this field blank.
- On the GroupWise tab, change to the Message Log Settings tab. As above, delete any custom location you may have defined there.
- If you use SSL to communicate between agents, you will need to regenerate your GroupWise SSL Certificate for this server and make the changes on the SSL settings tab.
You can find information on generating your SSL certificates for GroupWise at http://www.novell.com/documentation/gw8/gw8_admin/data/adqul6f.html. This information is for GroupWise 8.Similar information can be found for all versions of GroupWise, but the instructions for GroupWise 8 are the same as prior versions.
- After you have made all of the above changes, click OK to save the settings.
Configuring the MTA on Your New Linux Server
Now we will go back and configure the agent for your new Linux server. The configuration process will create a new startup file for the MTA, and configure the agent to launch upon startup.
In a terminal window, go back to the location where you extracted your GroupWise distribution above in “Preparing your New Linux Server”. Run the install script as root. For example:
gwlinux:/grpwise # ./install
- Choose Install Products.
- Choose GroupWise Agents.
- Choose Configure Agents.
- At the License Agreement screen, accept the license.
- The next screen will look very familiar to GroupWise administrators (see Figure 4-3). This is where we list the agents that will run on this server to create startup files and the startup script for Linux.
While we are looking at this screen, we should explain its usage so that it’s more easily understood the next time you encounter it. There are a few misconceptions about what is done here, and what you need to put in this location, so we will try to clear those up.
First, this screen is a template for creating new agent startup files (for example the cnc2.mta file), and for configuring your gwha.conf file. Let’s take the example of our groupwise system. Our domain is called CNC. If we want to create a new startup file for the CNC file, and place it in our gwha.conf (provided that we checked the option above to “Launch the GroupWise agents on system startup”), we would click the Add button as shown in Figure 2-3 and enter the information for our domain.
- Enter the information for your domain, using the local Linux path (see Figure 4-4)
By entering this information, we are instructing the installation routine to create us a startup file called cnc2.mta with a –home switch of “/grpwisedomains/cnc2, place it in the /opt/novell/groupwise/agents/share directory and include the information in the gwha.conf file.
- After your domain information is entered, click next to move on to the startup screen.
- You will be asked if you wish for your agent to load on startup. This box is already checked, but really just looks like a red box. You will notice that if you click on the box, it becomes white (unchecked) and clicking again will recheck the box. It is advisable to have your agents load on startup.
- Click Exit to leave this setup, and then click the Exit icon (at the bottom right of the screen) to leave the GroupWise installation program.
When you perform these tasks, a startup file is created for the domain’s MTA, and if you chose to launch on startup, symbolic links were created in the proper run level directories to start the agent automatically. Looking at the /opt/novell/groupwise/agents directory you will see directories named bin, lib and share. Under bin you will see the agent executables, as well as default startup templates. Under the share directory are a couple of directories, and the cnc2.mta startup file that was created by our installation. Let’s run this agent now and see what it looks like.
Starting the GroupWise MTA with the GUI for Testing
The first time we start a new agent on a Linux server, we like to start it with a GUI console to test that everything is working properly. It’s important to know that you will not run your agents with the GUI console as standard practice. We will load our MTA up for the first time with the GUI console solely to verify that there are no problems with our installation.
The easiest way to start the GUI agent is as follows:
From a terminal window, change to the /opt/novell/groupwise/agents/bin directory. From here, type the following:
./gwmta –show @cnc2.mta &
This should bring up the agent screen as shown in Figure 4-5.
If this domain owns any post offices, and you had them configured as “mapped” or “UNC” locations, the post offices will be closed, as you can see in this figure. If we choose Configuration|Status, we see that these post offices had their link configuration as “mapped” before. Now that we are on a different server, we need to fix this. Of course, if your MTA and POA were talking IP prior to the domain move, your post offices should come up and be just fine. This example is merely to show what might happen if you have direct links.
- Configuration Status showing Post Office Closed
- Back in ConsoleOne (/usr/ConsoleOne/bin/ConsoleOne if you’ve closed it down), right-click on the domain and choose GroupWise Utilities|Link Configuration.
- From the menu choose View|Post Office Links.
- Double-click on the Post Office that cannot be accessed, and fix the link. It should, of course, be a TCP/IP connection, pointing to the IP address and port on the server where the POA resides. See Figure 4-7
If all goes according to plan, your MTA will now show your POA open. Verify all of the links for this MTA (other post offices and domains). Once you have verified that your MTA is working properly we will exit the MTA and start it back up as a daemon. Press F7 to exit the MTA.
Once the MTA has shut down, it’s time to restart it.
Starting Your MTA as a Daemon
When you configured your MTA above, a couple of scripts were created for GroupWise. One is in the /etc/init.d directory named grpwise, and can only be called explicitly from that directory. The other is rcgrpwise, which is essentially in your “search path” and can be called from any location. If you go to a terminal window and type
your MTA will be launched. The options for this script are:
- rcgrpwise start (starts the agents)
- rcgrpwise stop (stops the agents)
- rcgrpwise status (shows the status of the agents).
We will learn more about the rcgrpwise script later when we move our domain with a gateway.
Your domain is moved and your MTA is up and running. We can verify that by loading the HTTP monitor for the MTA.
Loading the HTTP Monitor
Now, since we have enabled out HTTP Monitor, let’s see what the new “console” for our Linux MTA looks like. The default port for the MTA’s HTTP Monitor is 7180. Unless you changed that port during the installation above, you can simply go to http://server:7180. Here’s what a typical MTA HTTP Monitor looks like:
It might take a bit of time for those of you unaccustomed to this tool to learn to love it, but you can do everything (and more) here in this HTTP monitor that you could do in your old Console GUI.
Truthfully, this domain move probably would take no longer than it took for you to read this chapter! Moving a domain to a Linux server is a fairly painless process.
From here, you can move on to moving a gateway to a new Linux server, or even your post office.