OES2 Rolling Cluster Upgrade from NetWare - Part 2 - GroupWise 8 Cluster Migration to OES2 Linux

Contents


 

Overview
Pre-requisites
Disk Settings (Cluster)
GroupWise Software
Cluster script preparation:
Scenario 1 (No NSS Case Sensitivity)-load scripts:
Scenario 2 (NSS is Case sensitive)-load scripts:
Unload scripts (both for Scenario 1 and Scenario 2):
Migration Pre-requisites
Scenario 1 (without case sensitivity):
Scenario 2 (modifying case with NSS)
Migrate Cluster Resource
Set Case Sensitivity (Scenario 2 Only)
Change Case (scenario 2 only)
GWCHECK – Post Offices ONLY (Scenario 2 only)
Software Install – Primary Node
MTA and POA only
Software Install – Secondary Nodes – MTA and POA only
Agent Configuration - MTA/POA (Primary Nodes)
Startup Files
ConsoleOne Settings – Domain, Post Office, & Agent Settings
Finalize Cluster Scripts – MTA and POA
Final Items – MTA and POA
Software Distribution Directory Settings
eDirectory User Synchronization
WebAccess Application (Web Server)
Installation
WebAccess Application – Configuration
webacc.cfg settings
WebAccess – Web Agents
Scenario 1:
Scenario 2:
Software Install and Configuration
Cluster Load Scripts
Cluster Unload Scripts
GWIA – Install and Configure
GWIA ConsoleOne Settings
gwia.cfg file
Secondary Node(s) Configuration
Manual adjusting of gwha.conf
Appendixes:
Clusterimport.conf example
gwha.conf file example

Overview

The purpose of this document is to list the steps necessary to perform a Rolling Cluster Upgrade from NetWare 6.5.8 to OES2 SP2 Linux as it pertains to GroupWise. Due to a lack of documentation on Novell's site for the GroupWise Rolling Cluster Migration, I felt it necessary to list the procedure here. This is a continuation of my OES2 Rolling Cluster Upgrade from NetWare guides: OES2 Rolling Cluster Upgrade from NetWare - Part 1- Installing OES2

The OES2 SP2 docs for GroupWise as it pertains to Rolling Cluster Upgrade, tell you to go look at the GroupWise docs. But when you go to the GroupWise docs, you find that you are told to go look at the OES2 docs. Unfortunately it appears that the GroupWise Team does not officially support converting a NetWare Cluster with GroupWise to an OES2 SP2 Cluster. I'm guessing a lot of customers DO actually run GroupWise on NSS in a NetWare Cluster and would benefit from this material. However, keep in mind this is NOT (currently) officially supported by Novell as of the date of this document.

There are two methods to convert/upgrade GroupWise on NetWare with NSS over to OES2 SP2 Linux with NSS in a cluster environment. I am going to detail BOTH methods here. Note that I have never personally used Scenario 1 (just mounting the NSS volumes). I have been told UNOFFICIALLY that NSS with the LONG name mount space should "just work" on Linux. However, I preferred to use the Unix mount name space instead just to be safe. (That is Scenario 2). It adds a little extra time, but until Novell officially confirms that GroupWise with Linux on NSS with LONG name mount space will work and be supported with mixed case paths/files, I didn't want to run a production environment that way.

Also, there are TWO completely unsupported methods of getting WebAccess Application (web server) to be clustered. Novell does not support GroupWise WebAccess Application in an NCS cluster for some reason, so while either method will work, Novell won't support it. Perhaps if enough people submit RMS requests, Novell may change their mind. I am currently only documenting the method that I used (I will work on submitting the second method later).

Our Post Office cluster resources are named after our PO's and we load/unload the MTA/POA pair together on the same cluster resource. Each PO has a GroupWise domain. Our Gateways (WebAccess and GWIA) have MTA/Domains on each of their resources as well. Each cluster resources uses a unique IP and port numbers for GroupWise since our failover does allow for multiple POA/MTA to reside on the same physical cluster node. We have a cluster resource for our GWIA and its MTA. We have two webaccess AGENTS (GWINTER) cluster resources that also have MTAs. Lastly we have a WebAccess Web Server (Application) as a cluster resource. We run the agents as root. Your setup may vary.

Some things to keep in mind when you are converting GroupWise from NetWare to OES2 Linux in a rolling cluster conversion.

The cluster load scripts are NOT auto-translated as it pertains to the GroupWise NLM load lines. As such, this requires manually changing the cluster load/unload scripts so that OES2 Linux can load the agents.

Because you have to modify the load/unload scripts, you will not be able to auto-failover the resources BACK to NetWare nodes. As such, it's highly recommended that once you migrate the GroupWise resource to OES2 Linux, that it STAYS on a Linux node. Otherwise your resources will go comatose.

We assume that NSS is being used on NetWare and that you will continue to use NSS on OES2 Linux
This is NOT officially supported by the GroupWise team at Novell.

Pre-requisites

Before you start your rolling cluster upgrade of GroupWise, you may wish to make a note of which resources can run on which servers. In our environment we do not allow all resources to run on every server. We also have a specific cluster failover path. In this regard, only certain servers can run GroupWise in our setup. This can affect your rolling cluster upgrade since you need to remove the physical node and install OES2 Linux on it. As such, either plan your migration path accordingly, or you may need to temporarily adjust your cluster node failover depending upon which node is being upgraded.

We will prepare our cluster servers for GroupWise by identifying which servers can run GroupWise. Remember, in Part 1 of my guide, we are using OES2 SP2 64-bit Linux. OES2 Rolling Cluster Upgrade from NetWare - Part 1- Installing OES2

Disk Settings (Cluster)

The "noatime" setting for NSS is set in the CLUSTER load script commands as per Novell's own docs. Therefore, it will be documented in that section. You really don't want NSS to be tracking the attribute on a busy GroupWise system, so that's why we turn it off.

GroupWise Software

You can copy the GroupWise software to the OES2 Linux node ahead of time and extract the file contents to whatever directory you prefer. In this example, I have extracted the .tar.gz file to the /root/gw802 directory on the OES2 Linux server. We also used the chcase.pl script (you can google for it). The chcase.pl script is only for Scenario 2.

Cluster script preparation:

Once you are ready to start your migration (our largest PO of about 110 GB took about 20-30 minutes to do, although the first few I did took longer until I got the hang of things), you'll need to modify the existing NetWare NCS Cluster load/unload scripts to temporarily comment out the lines that load/unload the actual GW agents on NetWare (otherwise if you try to migrate the resource to Linux it will go comatose because it doesn't understand or translate the NLM load lines). I suggest that you record your current load/unload scripts somewhere prior to migrating things if you have not already done so.

We'll need to manually change the scripts as they are in "NetWare" format. I've included screenshots of the "before" and after so you can see what needs to be changed to illustrate this. You may find it easier to change these ahead of time and put them into text files so you can copy/paste into iManager (since the changes don't take effect until you offline/online the resource, you can do this a few hours ahead of time).

You are essentially going to adjust the NSS load/unload lines so that OES2 can mount the volume (technically the OES2 cluster translation engine CAN process this just fine, but we need to adjust for the "noatime" switch, and since we have to edit the GroupWise agent load /unload lines as well, we may as well change everything at once). Then we will online the resource to an OES2 Linux node so that NSS is available, then we will change the case of files/directories, verify that the agents will load and then adjust the cluster load/unload scripts accordingly.

I have not included the lines for killing agents that don't unload at this point. The main reason for this is that in a MIXED Cluster node, the cluster load scripts are limited to 1013 bytes. So you can't add all the extra lines just yet until you finalize the cluster conversion to Linux. (You can alternatively use a script to run all the lines, but I've had issues with this in the past when trying to troubleshoot things, so I prefer to leave everything in the cluster load scripts vs. calling a separate .sh script file).

Login to iManager -> Clusters -> Cluster Options

Click to view.

Click on the desired resource.

Click to view.

Click the Scripts tab

Click to view.

Scenario 1 (No NSS Case Sensitivity)-load scripts:

Edit the LOAD script so that it initially contains a format similar to:

#!/bin/bash
. /opt/novell/ncs/lib/ncsfuncs

exit_on_error nss /poolact=PO9POOL
exit_on_error ncpcon mount /opt="noatime" PO9=214
exit_on_error add_secondary_ipaddress 10.10.1.9

exit_on_error ncpcon bind --ncpservername=CS1-PO9 --ipaddress=10.10.1.9

exit 0

Items to change are highlighted in yellow:

/poolact=POOLNAME
PO9=214 (This is the volumeID). You can look in the cluster scripts directory to find the volumeID. Obviously the volume name is different for each server, as is its volumeID
ipaddress=IP of clustered resource
ncpservername=name of clustered resource

Scenario 2 (NSS is Case sensitive)-load scripts:

Edit the LOAD script so that it initially contains a format similar to:

#!/bin/bash
. /opt/novell/ncs/lib/ncsfuncs

exit_on_error nss /poolact=PO9POOL
exit_on_error ncpcon mount /opt=ns=unix,"noatime" PO9=214
exit_on_error add_secondary_ipaddress 10.10.1.9

exit_on_error ncpcon bind --ncpservername=CS1-PO9 --ipaddress=10.10.1.9

exit 0

Items to change are highlighted in yellow:

/poolact=POOLNAME
PO9=214 (This is the volumeID). You can look in the cluster scripts directory to find the volumeID. Obviously the volume name is different for each server, as is its volumeID
ipaddress=IP of clustered resource
ncpservername=name of clustered resource

Now we need to adjust the Unload scripts as well. We need to Comment out the old NetWare commands as shown on the next page.

Click to view.

Unload scripts (both for Scenario 1 and Scenario 2):

So the unload script will look like:

## Unload script (with modifications) ##
#!/bin/bash
. /opt/novell/ncs/lib/ncsfuncs

ignore_error ncpcon unbind --ncpservername=CS1-PO9 --ipaddress=10.10.1.9
ignore_error del_secondary_ipaddress 10.10.1.9

ignore_error nss /pooldeact=PO9POOL /override=question
exit 0

Items to change are highlighted.

Same items as before.

Click Apply and you'll get the pop up to remind you that you need to offline/online the resource for the changes to take effect.

DO NOT offline them just yet (do that when you migrate the resource to the OES2 node)

Modify the Preferred Nodes so that it can only load on an OES2 server.

Click to view.

Highlight the NetWare servers in the Assigned: column, and use the right and left arrow buttons to REMOVE the NetWare Nodes from the list. You can use the right/left arrow buttons to ADD the OES2 servers if necessary. Click Apply when finished. (the build numbers below may vary for your setup. At the time of our upgrade/conversion we only used GroupWise 8.0.2 and not 8.0.2 HP1 or HP2 codebase). Why do we do this? Because you don't want the GroupWise resource to try to load on a NetWare server once you've converted the cluster scripts to a Linux format.

Migration Pre-requisites

Scenario 1 (without case sensitivity):

Because we are simply mounting NSS and using it without enforcing case sensitivity, we can skip to the next section.

Scenario 2 (modifying case with NSS):

• • Open a terminal and cd into the /root/gw802 directory you just extracted things to

• • Type: cd /admin

• • Type: rpm –Uvh novell-GroupWise-gwcheck-8.0.2-91415.i586.rpm

• • WinSCP the chcase.pl script to the /root directory

• • Type: chmod x chcase.pl

Migrate Cluster Resource

Offline the resource (so that it reads your script changes and will not try to load the GroupWise NLM's onto the OES2 server).

Then, ONLINE the resource to the OES2 Linux node.

Make sure that the volume is mounted (GroupWise will NOT load/run at this point because we removed that section) and accessible.

If you are using Scenario one, you can skip to the Software Install section.

Set Case Sensitivity (Scenario 2 Only)

Change Case (scenario 2 only)

Now we need to change the case of the files/directories on the NSS volume. In our case, the cluster resource volume is:

/media/nss/PO2

Click to view.

The switches are:

-rdo

For PO9 it took 1:30 minutes for approx. 25 GB.
For PO2 it took about 10 minutes for approx 95 GB of data

GWCHECK – Post Offices ONLY (Scenario 2 only)

You only need to do this section if you are migrating a Post Office. You do not run these on MTA/Domains or the GWIA or WebAccess Components.

Since we are running OES2 SP2 64-bit (again, since Novell said the next version of GroupWise would be 64-bit only), you will need to change/adjust something in order to run gwcheck properly.

Next you need to export your jvm in order to run GWCHECK. Open a terminal and type:

export JAVA_HOME="/usr/lib/jvm/jre-1.5.0"

cd /opt/novell/groupwise/gwcheck/bin
./gwcheck

Click to view.

Enter the correct path to the post office (remember that it's all lowercase EXCEPT for the volume name). I try to use the Browse button/icon to avoid typos.

ONLY check the boxes as shown above.

Click to view.

Click Run

It'll take less than a minute

Software Install - Primary Node

MTA and POA only

This assumes you're just installing the MTA/POA at this point.

1. 1. Copy the gw802_full_linux_en.tar.gz file to the GW volume on the OES2 server. You can map a drive if you wish.

1. 1. At the OES2 server, using the GUI, open the gw802_full_linux_en.tar.gz file with File Roller and extract to the /root directory

1. 1. Rename the directory it creates to: gw802

1. 1. Make sure that the GW volume is mounted with the LOOKUP NameSpace of Unix (you did this with the cluster load scripts)

1. 1. Open a terminal and type: cd gw802

1. 1. Then type: ./install

Click OK.

(Check the box for "configure for clustering")

Click to view.

Click Install Products

Click to view.

Click GroupWise Agents

Click to view.

Click Install Agents

Click to view.

Click OK

Software Install - Secondary Nodes - MTA and POA only

Repeat pages 14-17 to install the software onto the secondary cluster nodes.

Agent Configuration - MTA/POA (Primary Nodes)

Click to view.

Click Configure Agents

Click to view.

Click Next

Click to view.

Accept the terms and click Next

Click to view.

Click Add

I try to keep the case the same as what's actually on the file system. The volume name will always be upper case. Use the browse button to avoid typos.

Click OK

Do this for each agent that's on the server. (If your cluster resource runs 2 MTA/POA then you will have a total of 4 agents to configure).

Click to view.

IF you use the "browse"/folder icon, it will NOT put the trailing "/" for the cluster mount point.

If you fail to include this trailing "/", then the GroupWise software installation routine will NOT create the correct directory structure on your NSS clustered volume and your agents will fail to load. It SHOULD create a: /media/nss/VOLUME/GroupWise/software/agents/share directory.

Click OK

Click to view.

Again, make sure that the TRAILING "/" is there for the cluster resource mount point!

Click OK

Click to view.

Now click Next

Click to view.

Then click Exit.

Startup Files

We need to edit the startup files for the MTA for OUR setup. Your environment may vary. Adjust the load files accordingly. The Clustering option should have installed the startup files onto the /media/nss/VOLUME/GroupWise/agents/share directory. Each resource has a unique volume name (PO1, PO2, WA1, etc.)

cd /media/nss/PO7/GroupWise/agents/share

You'll see the .mta and .poa startup files

Edit the .mta file (you can use vi or gedit)

Make sure you have the line:

--tcpinbound 80

in the file.

Click to view.

Then change the log directory line:

Click to view.

And comment it out with a semicolon (we have this set in the eDirectory object for the MTA).
Save the file.

Now edit the POA startup file (again, it will vary for your environment) and find the "log directory" and comment it out as well.

Also, add the nodca switch at the very END of the file (the document conversion agent has a tendency to cause instability with the agents, so we just disable it all together). We set the quickfinder level so that it can index fully:

--nodca
--qflevel 999

ConsoleOne Settings - Domain, Post Office, & Agent Settings

Now we have to use ConsoleOne to adjust everything (the paths and other items).

Fire up ConsoleOne (I'm assuming Windows workstation here, vs. on the Linux server itself). If you get an error about ncp cross protocol locks, ignore it. It's a bug. The value IS set on the server already, if you followed my OES2 installation guides. You may have to manually copy the ncpchecked file into the directory that contains your domain (this is what ConsoleOne looks for) to fix the error message. Refer to TID #7004594 for more information.

Right-click the domain object of the server you migrated and select Properties

Click to view.

Use the browse button to select the path so that it shows lower case. Technically this part here is just used by ConsoleOne.

Do the same for the Post Office (NOT the POA):

Click to view.

Again, browse the path.

More importantly is on the MTA and POA objects.

Click the View in ConsoleOne to look at MTA and find the MTA for the domain you migrated and click properties for it.

Click to view.

For the platform select Linux

Click GroupWise -> Log Settings

Click to view.

Change the path to be relative and with the slashes being the other direction. For example, the above setting would be:

/media/nss/GW/training/traindom/logs

Do the same for the Message Logging section underneath GroupWise tab.

For the POA, make sure you select the PO first in ConsoleOne (the one that you migrated) and THEN access the POA (if you don't, you won't be able to change the platform):

Technically if you have overridden the eDirectory settings with the startup files you don't need to adjust the log files locations, but we choose to use the eDirectory settings instead.

Click to view.

Again, change to Linux.

Then under GroupWise tab, change the Log Settings:

Click to view.

I then rebuild the databases at this point to ensure they get the settings that I changed in consoleone.

I assume that you have basic understanding of rebuilding the domain and post office databases at this point.

THEN, do a test run of the agents startup (failure to do this will cause the gwha.conf file to not be updated and your cluster load scripts won't work). The reason for this is that the /etc/opt/novell/groupwise/gwha.conf file will list the "new" agents with a @ until you actually start them once. Then it'll re-adjust itself to use the [domain] or [po.domain]. (again, there is a workaround for this, albeit unsupported).

cd to the:
/media/nss/VOLUME/GroupWise/agents/share directory
And then type:

/opt/novell/groupwise/agents/bin/gwmta –show @startup.mta &
(where the startup.mta is the name of the domain you wish to start)

And do the same for the POA:

cd /media/nss/VOLUME/GroupWise/agents/share
/opt/novellGroupWise/agents/bin/gwpoa –show @startup.poa &

(and that's a "dash dash" not a single dash).

Click to view.

Sample of functional MTA:

Click to view.

Sample of Functional POA:

Click to view.

Exit both MTA and POA via the File -> Exit menu items.

Once they're unloaded type this from a terminal to verify they load once more:

rcgrpwise start DOMAIN (it's case sensitive, so most of the cluster files are: Domain9, Domain8, etc.)
EX: rcgrpwise start Domain9

And

rcgrpwise start PO.Domain (again, pay attention to the case)
EX: rcgrpwise start PO9.Domain9

You will NOT see an agent window. To verify they are running, open a terminal and type:

rcgrpwise status

Click to view.

You want to see green items saying running (if not using Putty you want to see the word: running)

Then type:

rcgrpwise stop

This will stop all the agents.

Finalize Cluster Scripts - MTA and POA

Now we need to finalize the cluster load and unload scripts.

Again, use iManager -> Clusters -> Cluster Options and click the name of the resource to show the properties:

Click to view.

Click Scripts

Click to view.

ADD the section as shown above.

I've put it here for easier copy/pasting:

#Start Services
exit_on_error /etc/init.d/grpwise start Domain9
exit_on_error /etc/init.d/grpwise start PO9.Domain9

Obviously the names of the items change depending upon the resource.

Now click on the Unload Script

Click to view.

ADD the section as shown above for the unload section.

We will need to later re-modify this when the cluster is 100% linux. The main reason is that we need to ADD a section in case the agents don't unload nicely. However, in a mixed cluster there's a limitation of 1013 bytes for the scripts files.

What we NEED to add (eventually) is this section:

#Stop Services Otherwise
ignore_error /etc/init.d/grpwise stop domain
ignore_error /etc/init.d/grpwise stop post_office.domain

sleep 8

ignore_error pkill -fx "/opt/novell/groupwise/agents/bin/gwmta @/path_to_startup_file/domain.mta"
ignore_error pkill -fx "/opt/novell/groupwise/agents/bin/gwpoa @/path_to_startup_file/post_office.poa"

(Each of the last two "ignore" lines are ALL on ONE line. There's no carriage return after the /gwmta and /gwpoa).

Biggest change will be that you CANNOT have the agents auto-start AND get a GUI screen for the agents like what is shown above. You will have to use the GroupWise HTTP interface if you wish to look at the agent status.

Final Items - MTA and POA

Software Distribution Directory Settings

• • Edit the setup.cfg file in the new SDD that you created and turn off the auto-client updating (per your environment)

• • Adjust the SDD directory if necessary in ConsoleOne so that the POA on Linux points to the appropriate SDD directory to use.

eDirectory User Synchronization

Because the agents are now Linux, we have to re-configure the eDirectory User Synchronization
(otherwise you will find that your eDirectory stuff no longer syncs to GroupWise).

To adjust the NDS Synchronization, do this:

Launch ConsoleOne -> GroupWise System Operations -> eDir User Synchronization

Click to view.

Click to view.

Find the Domain that you just migrated and click Configure Agents

Click to view.

Now, scroll through the list to find the MTA of the domain you just migrated and click Set Up eDirectory Access.

Click to view.

Click the Set Preferred button so that the appropriate LDAP server is the "preferred" server.

Click the browse icon button for the LDAP user name. The userid you are looking for is:

.GroupWise.ldap-users.svcs.dec

It will change this into an LDAP format with commas automatically.

Then click the Set Password button (this does not actually CHANGE the password, it's just so you can enter what the password CURRENTLY is). The password is in our list of passwords.

Click to view.

Click Set Password

For the LDAP Group browse button, you will choose the appropriate eDirectory LDAP GroupWise object that belongs to the LDAP server(s) you have already defined in GroupWise.

Click OK

Now click OK again.

Click OK again (it will keep taking you "up" one level).

Click OK again.

WebAccess Application (Web Server)

Installation

This method is NOT supported by the GroupWise team at Novell. Use at your own risk. This also assumes you ALREADY are clustering WebAccess on NetWare via the same method. (although if you are experienced enough you can use this to setup a new cluster IP Resource).

In this method, the GroupWise WebAccess Application code must be installed onto each physical node separately. (Similar to how one would cluster NetStorage in OES2 Linux). Again, there is another method but I will have to detail that later in a separate document.

However, you can cluster-enable the virtual IP address that corresponds to the DNS for the web server (ie: gwweb.abc.com) so that it will fail over if necessary.

I strongly suggest you backup/copy your webacc.cfg file from your existing NetWare setup first. And document all your GroupWise Provider object settings as well (you can technically use the .cfg file for all the configuration information but not everyone has their settings in one spot). Because of this method, we will NEED to have the settings in the .cfg file because the multiple node installation will re-write the eDirectory configuration objects.

On the physical node, either VNC or ILO into the server.

Copy and extract the GroupWise 8.0.2 code to the Linux server as per page 12.

(it may already be on the server, so check before hand)

Open a terminal and type:

cd gw802/
./install

Click to view.

Do NOT check the box for Clustering!!

Click to view.

Click Install Products

Click to view.

Click GroupWise WebAccess

Click to view.

Click Install WebAccess Application

(make sure that you do not install the AGENT)

Click OK

WebAccess Application – Configuration

Click to view.

Click Configure WebAccess Application

Click to view.

Click Next

Click to view.

Accept the license agreement and click Next.

Remember, this is in a MIXED cluster, so your WebAccess Agents/Domains may still be on NetWare.

If mounting to a NETWARE server:

Open a Terminal and ncpmount a location to the WebAccess Agent:

ncpmount -S server -A IP -U userid -P password /mnt/gw1

Where server = name of source netware server
Where IP = IP of the source NetWare server
Where userid = your userid in FQDN format like: .jsmith.nyc.abc
Where password = your password

Example:

ncpmount -S cs1-wa1 -A 10.10.1.131 -U .jsmith.nyc.abc -P password /mnt/gw

If mounting to an OES2 Linux Cluster server:

ncpmount -S cs1-wa1 -A 10.10.1.131 –o tcp –V WA1 -U .jsmith.nyc.abc -P password /mnt/gw

Now use the browse button on the GroupWise Install GUI to select the appropriate path:

Click to view.

Click Next

Click to view.

Click Next

Click to view.

Make sure that you change the "o" for the location of the admin user. It will default to be:

cn=admin,o=novell which is wrong for our environment.

Click Next

Click to view.

The browse button doesn't work in our environment for some reason. So you'll have to manually enter the information as shown above.

Click Next

Click to view.

Click OK

If you get the AD25 error, you'll need to use ConsoleOne to delete the 4 "application" objects in eDir

(or point it to a new location)

After deleting, wait a minute or so and then click Next and OK to retry

Click to view.

Click Exit

Use the same terminal to type:

ncpumount /mnt/gw

Now test the webaccess:

https://co-nc1-svr14.abc.com/gw/webacc

(use the server name that matches the server you just installed the code onto)

Verify that you can login and view email correctly.

Test both Firefox and IE.

webacc.cfg settings

Then you need to edit the /var/opt/novell/groupwise/webaccess/webacc.cfg file so that it fits your environment. In our case, we don't change much. Remember, my setup has two GWINTER/Agents and I desire fault tolerance for them, so that's why I have two entries for my GWAP settings.

The key items are the following lines:

User.Access.document=false

Security.UseClientIP.enable=false

#Provider.default=GWAP
Provider.GWAP.Default.address.1=10.10.1.131:7206
Provider.GWAP.Default.address.2=10.10.1.138:7205

Then restart the Apache and Tomcat processes to read the new file

WebAccess - Web Agents

In our case, we have the WebAccess Web Agent run on the same server as its associated Domain/MTA.

Therefore, you have to actually migrate/install BOTH an MTA and the WebAccess Web Agent itself.

Follow the docs up to page 8 (basically offline the resource, adjust the load/unload scripts and the preferred nodes). Copy the software over to the cluster node (if it's not already there).

Scenario 1:

If using this Scenario (you are not concerned with case sensitivity), then skip the Scenario 2 section as we don't change the case of the directories, and head straight for the Software Install and Configuration section below.

Scenario 2:

If you are setting your NSS to use the "unix" name space, then you need to change the case of the directories.

Now we need to change the case of the files that contain our clustered webaccess NSS volume.

Click to view.

The switches are:

-rdo

As an example: ./chcase.pl –rdo /media/nss/WA1

Software Install and Configuration

Now open a terminal and type:

cd gw802
./install

Click to view.

Check the box and click OK

Click to view.

Make sure you ADD the trailing "/" for the cluster mount point.

If you browse for it, it will not add it.

Failure to add this will result in the files not being created properly.

Click OK

Adjust the agent config files as necessary for your environment.

Click the back button to be presented the main GroupWise Install screen (do not exit out of the install entirely. If you do, you'll need to re-run the ./install and check the box for enable agents for clustering):

Click to view.

Select GroupWise WebAccess

Click to view.

Select Install WebAccess Agent (again, the AGENT, not the Application!!!)

Click OK

Click to view.

Now select Configure WebAccess Agent

Click to view.

Click Next

Click to view.

Accept the terms and click Next.

Click to view.

Make sure to enter the correct Port number.

For the cluster mount point make sure to enter the trailing "/".

Click Next.

Click to view.

Enter (browse) for the appropriate directory and click Next

Click to view.

Be sure to adjust the O=novell to the correct setting for your environment. Enter the password and click Next.

Click to view.

You'll have to type the location of the domain name in ldap format (the browse button doesn't work in our environment).

Click Next

Click to view.

Click exit.

Adjust the webaccess configuration file as necessary for your environment. In this example, the file is located:

/media/nss/WA1/GroupWise/agents/share/webac80a.waa

You MAY have to manually create the webaccess gateway at this point, but Novell's docs leave that out.

Verify that the agents load with the –show switches (that's a dash, dash)

Cluster Load Scripts

Adjust the cluster load scripts by ADDING the following:

#Start Services
exit_on_error /etc/init.d/grpwise start WA1
exit_on_error /etc/init.d/grpwise start webac80a.wa1

(you can find out what the "start" commands are by looking at the /etc/opt/novell/groupwise/gwha.conf file on the server)

Cluster Unload Scripts

Modify the UNLOAD scripts by ADDING the following:

#Stop Services
ignore_error /etc/init.d/grpwise stop WA1
ignore_error /etc/init.d/grpwise stop webac80a.wa1

GWIA - Install and Configure

Remember in our setup, our GWIA resource also runs an MTA. I STRONGLY advise that you backup your CURRENT gwia.cfg file because when you install the Linux version it will create a brand new gwia.cfg file with default settings that will NOT be desirable (in fact it will prevent the gwia from even loading on Linux). This is not mentioned in Novell's docs.

Install the Agents

Configure the MTA

Click to view.

Click to view.

Click OK

Now Configure the agent:

Click to view.

Click to view.

Click to view.

Click to view.

Enter the information accordingly as per your setup.

Click Next.

Enter the appropriate mail forwarding settings for your environment and click Next.

Enter your email domain name accordingly and click Next.

Click to view.

Enter the GWIA location in a Linux format as shown above (just an example).

Click to view.

Again, enter the information that is right for your environment. Don't forget to change the "o=" section to match your actual location of your admin user.

Click to view.

Browse or enter the LDAP context of your domain object that houses your GWIA object.

The GWIA is located in the SMTP domain in the CO container.

Click to view.

GWIA ConsoleOne Settings

This is very detailed. DO NOT load the GWIA until you fix these items (otherwise it won't load at all or load with the wrong settings and you won't get email processing properly).

First, we need to edit the following in ConsoleOne:

Click to view.

Click to view.

Make sure that the "bind exclusively" box is checked.

Click to view.

This is the section that is easy to forget. If you forget this, the usual symptom is that the GWIA will load and run but not process any mail.

gwia.cfg file

And lastly, edit the gwia.cfg file located in:

/media/nss/GWIA/GroupWise/agents/share

At the bottom, you'll need to REM out all the stuff it puts in (it SHOULD read the settings from the ConsoleOne object). EXCEPT for the –home switch. Leave that in. I've attached an example here. If you do not remove the –dhome switch, I have found the GWIA process will immediately crash without any indication of why (it will not even write to the log file to tell you this).

;======================================================================
;         DEFAULT AND CONSOLEONE ENABLED STARTUP OPTIONS
;
;  After running ConsoleOne for the first time against a 8.0 Internet
;  Agent object, All settings below except the --home switch will be 
;  written to the wpdomain.db and will be removed from below.  Any further
;  changes made from ConsoleOne will not be written to this file, so any
;  option enabled in this file will override setting made in ConsoleOne.
;  Also, ConsoleOne will not read any settings from this file after the
;  first time ConsoleOne is run for a 8.0 Intenet Agent object.
;
;======================================================================
--home /media/nss/GWIA/smtp/wpgate/gwia
;--dhome /smtp/wpgate/gwia
;--ip address 10.10.1.34
;--smtp
;--nosmtpversion
;--mime
;--mudas 2
;--sd 8
;--rd 16
;--p 10
;--te 2
;--tg 5
;--tc 5
;--tr 5
;--td 3
;--tt 10
;--pt 10
;--it 10
;--ldapthrd 10
;--st 4
;--rt 4
;--dsn
;--dsnage 4
;--xspam
;======================================================================

Then test by starting it:

cd /media/nss/GWIA/GroupWise/agents/share
/opt/novell/groupwise/agents/bin/gwia –show @gwia.cfg &

Secondary Node(s) Configuration

Since the GroupWise software (ie: the /opt/novell/groupwise directory) is installed locally to the physical node (ie: co-nc1-svr01) we only need to update the config files on the secondary nodes.

For example:

co-nc1-svr03 is the primary node for CS1-PO3. However, it can also host the PO1, PO7 and PO8 resources as well.

What this means is that we need to configure the GroupWise software on the node so that it is aware of PO1, PO7 and PO8 agents. Or any other agent that may reside on that server.

This can be accomplished with the /root/gw802/gwinst/clusterimport.conf file (or wherever you extracted your GroupWise software to). Although this file does not get created until you actually "configure" the GroupWise software on a physical cluster node (so in a rolling cluster upgrade you may only have one "configuration" to start with until you can upgrade other cluster nodes).

You can copy this file elsewhere and view the syntax if you wish to adjust it fully ahead of time. An example file is located at the end of this document. (Once you observe the syntax, you can manually create/adjust this file ahead of time).

I've created a master clusterimport.conf file and you can import and select the items that SHOULD be on that physical node.

 

However, I have developed an UNSUPPORTED method to get around this situation.

A typical cluster load/unload script will have something in this format:

#Start Services
exit_on_error /etc/init.d/grpwise start Domain9
exit_on_error /etc/init.d/grpwise start PO9.Domain9

AND, the gwha.conf file will have something like this in it:

[Domain9]
server=/opt/novell/groupwise/agents/bin/gwmta
command=/etc/init.d/grpwise
startup=/media/nss/PO9/domain9/GroupWise/agents/share/domain9.mta
delay=2
wait=10

[PO9.Domain9]
server=/opt/novell/groupwise/agents/bin/gwpoa
command=/etc/init.d/grpwise
startup=/media/nss/PO9/po9/GroupWise/agents/share/po9.poa
delay=2
wait=10

Notice that the agents are in the format of [agentname]

If you just do an import of the clusterimport.conf file, the gwha.conf file is written like this:

[domain9]
name=[@domain9.mta]
shared=/media/nss/PO9/domain9
server=/opt/novell/groupwise/agents/bin/gwmta
startup=/media/nss/PO9/domain9/GroupWise/agents/share/domain9.mta

[po9]
name=[@po9.poa]
shared=/media/nss/PO9/po9
server=/opt/novell/groupwise/agents/bin/gwpoa
startup=/media/nss/PO9/po9/GroupWise/agents/share/po9.poa

Notice the differences. One has the "@" symbol (among other things) and one does not (this is just the obvious set of differences).

What will happen:

IF you try to migrate your cluster resource to a secondary node, the cluster load script will try to run the agent with the first format. Since this is different than what the gwha.conf file shows, the GroupWise scripts will generate an error and your resource will go comatose.

IF you manually run the agents ONCE, after importing the clusterimport.conf file, the gwha.conf file will automatically update itself to the "correct" format. The problem with THIS method is that it assumes that you have migrated ALL your secondary NetWare nodes so that you can migrate the cluster resource (without the GroupWise load lines) and manually load/unload the agents on all your servers. If you need to do this AFTER adjusting the cluster load scripts with the load/unload lines, you will need to temporarily comment out those lines, and offline your resources (thus causing more downtime) and migrate the cluster resource to the secondary nodes so you can manually load/unload the agents.

My method basically circumvents this by manually adjusting the gwha.conf file so that you can simply migrate the resource. However, this is not supported.

Manual adjusting of gwha.conf

In order to prevent further downtime of our GroupWise resources, this is perhaps the easiest method (again, unsupported).

Make a list of what GroupWise resources can reside on which cluster nodes. Since we know what the gwha.conf file SHOULD look like for any given resource, we can simply edit it appropriately for our secondary nodes (this assumes of course, that you have properly installed the actual GroupWise code onto the secondary nodes).

You will need to create the /etc/opt/novell/groupwise/gwha.conf file manually. I prefer to use the vi editor, although you can use the GUI and gedit or pretty much any text editor you prefer on the OES2 Linux server.

 

Here's what a normal gwha.conf file has on the OES2 server:

Let's say we have a secondary node that we have already installed the GroupWise agents and software onto. But we have NOT run the Configuration option. And let's say this server will run an MTA and a POA. And let's say that the MTA/POA in question are called Domain3 and PO3 respectively. We would CREATE an: /etc/opt/novell/groupwise/gwha.conf file with the following information:

[gwha]
ssl       = no
key       = 
cert      = 
password  = 

[PO3.Domain3]
server    = /opt/novell/groupwise/agents/bin/gwpoa
command   = /etc/init.d/grpwise
startup   = /media/nss/PO3/GroupWise/agents/share/po3.poa
delay     = 2
wait      = 10

[Domain3]
server    = /opt/novell/groupwise/agents/bin/gwmta
command   = /etc/init.d/grpwise
startup   = /media/nss/PO3/GroupWise/agents/share/domain3.mta
delay     = 2
wait      = 10

Obviously use the information that is correct for your environment (remember that the Domain and PO names match the case of the eDirectory objects).

Perhaps the easiest method to do use, is to LOOK at the existing gwha.conf file on the PRIMARY node and enter the relevant information onto the secondary node(s).

Once this is done, and you have saved the file and set the rights/owner accordingly, all you should have to do is simply migrate the GroupWise resource to the secondary node and it should work. This assumes that you have already adjusted the cluster node failover and offlined the resource as necessary to read any changes.

Appendixes:

Clusterimport.conf example

If you wish to build a "master" clusterimport.conf file, here's an example of a file with a Domain (MTA), a Post Office (POA), a GWIA, and a GWINTER. Just keep adding sections for your domains, Post Offices, etc.

[domain1]
name=[@domain1.mta]
shared=/media/nss/PO1
server=/opt/novell/groupwise/agents/bin/gwmta
startup=/media/nss/PO1/GroupWise/agents/share/domain1.mta

[po1]
name=[@po1.poa]
shared=/media/nss/PO1
server=/opt/novell/groupwise/agents/bin/gwpoa
startup=/media/nss/PO1/GroupWise/agents/share/po1.poa

[GWIA]
name=[@gwia.cfg]
shared=/media/nss/GWIA
server=/opt/novell/groupwise/agents/bin/gwia
startup=/media/nss/GWIA/GroupWise/agents/share/gwia.cfg

[WEBAC80A]
name=[@webac80a]
shared=/media/nss/WA1
server=/opt/novell/groupwise/agents/bin/gwinter
startup=/media/nss/WA1/GroupWise/agents/share/webac80a.waa

gwha.conf file example

Here's what an unmodified gwha.conf file would look like (if you performed the "import cluster configuration). I have included lines for an MTA and POA:

[gwha]
ssl       = no
key       = 
cert      = 
password  = 

[@po4.domain4]
server = /opt/novell/groupwise/agents/bin/gwpoa
command = /etc/init.d/grpwise
startup = /media/nss/PO4/GroupWise/agents/share/po4.poa
delay = 2
wait = 10

[@domain4]
server = /opt/novell/groupwise/agents/bin/gwmta
command = /etc/init.d/grpwise
startup = /media/nss/PO4/GroupWise/agents/share/domain4.mta
delay = 2
wait = 10

And here's what it SHOULD look like after you manually run the agents (or you can simply adjust it to look like this and skip that step). I have included samples of an MTA, POA, GWIA, and WebAccess Agent.

[gwha]
ssl       = no
key       = 
cert      = 
password  = 

[PO3.Domain3]
server    = /opt/novell/groupwise/agents/bin/gwpoa
command   = /etc/init.d/grpwise
startup   = /media/nss/PO3/GroupWise/agents/share/po3.poa
delay     = 2
wait      = 10

[Domain3]
server    = /opt/novell/groupwise/agents/bin/gwmta
command   = /etc/init.d/grpwise
startup   = /media/nss/PO3/GroupWise/agents/share/domain3.mta
delay     = 2
wait      = 10

[gwia.smtp]
server    = /opt/novell/groupwise/agents/bin/gwia
command   = /etc/init.d/grpwise
startup   = /media/nss/GWIA/GroupWise/agents/share/gwia.cfg
delay     = 2
wait      = 10

[webac80a.wa2]
server    = /opt/novell/groupwise/agents/bin/gwinter
command   = /etc/init.d/grpwise
startup   = /media/nss/WA2/GroupWise/agents/share/webac80a.waa
delay     = 2
wait      = 10

[/no-glossary]