aevans's blog

I forget this and have to relearn it every time I update VMWare on my machine (yes, it breaks with every update from VMWare).  For the nitty gritty details I am running VMWare Server on SLED10 SP1, though this also affects VMWare Workstation.  I am not sure if it broke with the update to SP1, or if it broke in one of the VMWare updates as I did them both at the same time back in one of the SLED 10 internal betas but at some point the browse button in VMWare started causing VMWare to hang.  After much searching on the web I discovered the fix - though I could have saved myself a bunch of time by searching our own Knowledgebase first, as someone had already created a TID.

The fix, for which I can claim no credit, is to su to root and:

1.  cd /usr/lib/vmware/lib/libpng12.so.0
2. mv libpng12.so.0 libpng12.so.0.old
3. ln -sf /usr/lib/libpng12.so.0
4. cd ../libgcc_s.so.1
5. mv libgcc_s.so.1 libgcc_s.so.1.old
6. ln -sf /lib/libgcc_s.so.1

And that should be it.

I have a note in Tomboy with a list of blog topics that I have been compiling, so I am on a bit of a blogfest at the moment to get some of them done - incidentally I am looking for more topics if you have any ideas?

Over the years I have dealt with huge numbers of GroupWise systems, both during onsite visits and on dialins and a very common theme is that customers have not bothered to secure their agents in any shape or form - some not even enabling a username/password. At the most basic level I would certainly recommend securing the HTTP interface on any agent where you have enabled it - yes, this is a bit of work, but if you don't do all traffic is basic, unencrypted HTTP - including the password. Here's how:

First, set up a username and password to secure the agents, otherwise the interface is completely open to the public. In ConsoleOne go to the properties of the agent in question and, on the Agent Settings tab (optional agent settings on GWIA and WA), set an HTTP Username and Password. This does not need to exist in eDir, it's just an arbitrary name. If you are doing multiple agents I would recommend trying to keep them all the same.

Quick Tip - instead of having to remember all the HTTP ports you can connect to the C/S port on the POA (normally 1677) or the MTP port on the MTA (normally 7100) and you will get redirected. Eg - http://10.10.10.10:1677
At this point all the traffic is still cleartext so we need to SSLize the connection (not sure that's a word but I like it). I don't think there is any need to get an expensive Verisign minted certificate for this - I would just use a self signed cert from your own certificate server. The easiest way to do this is using iManager but first you need to create a CSR (Certificate Signing Request). Go to your GW CD/admin/utility/gwcsrgen and run gwcsrgen.exe. Fill it in like in the diagram, but make sure the values reflect your own server and that any filenames you use are 8.3 format.

Once you have the .key and the CSR you can start iManager. Down the left there should be a Novell Certificate Server task - expand that and select Issue Certificate. If it's not there check to see if you have the .NPM installed (hit the configure option and see if you are told that there are new ones to install). When you do get to the wizard you will first have to browse for the CSR you created. Then you need to select the usage - I put SSL or TLS and Server Authentication and User Authentication.

On the next page I select End Entity and then accept the default 2 year validity and save as a Base64 format file. Now download the resulting certificate.

Now you have a .key file and a .b64 file - you need to copy these to a place where the agent can access them - for best practices I always place them at the root of the domain or po directory. Then, in ConsoleOne, go to the SSL Settings tab on the agent you want to secure and browse to the .b64 and the .key files you created. Set the .key password to whatever you entered in gwcsrgen.

Finally, on the Network Address tab on the same agent set the SSL drop down next to HTTP to 'Enabled'. You are done with that agent. You should now do the rest - you need to generate a new CSR, .key and .b64 for each server that runs the agents. What I have not tried, but it should work, is to create a wildcard certificate and key and secure all you agents using that. This would be much less time consuming - if anyone out there has already done it and it worked let us know.

Oh, and as a point worth noting I spent an hour, generating and regenerating certificates and swearing at iManager, because Firefox was giving me 8101 errors and refusing to connect.  It was only when I went into IE that I noticed the certificate was not yet valid - my VMWare session with my NetWare 6.5 box was running in the future so the certificate had the wrong dates.  So, sorry iManager.

I sat down tonight determined to figure out just how useful the Alternate Gwia option was in internet addressing. I will admit that I spent quite some time lying on the floor, staring at the ceiling, trying to get my head around it - but I think I have it figured out. I have to say, it's a lot more useful then I first thought......

The key to making the most of it is ensuring that the first attempt to send a mail out of a GWIA will fail - this gets the MTA into 'failover' mode. Getting this done is relatively simple, though it will increase the load on one of your MTA's quite significantly. In the domain that you want to handle this extra load, which can be a purpose created domain, create a dummy GWIA object.

1. Browse to that [domain]\wpgate dir and create a new, empty directory - example, gwia
2. In ConsoleOne right click the domain object in the GroupWise view and select New -> Gateway. On the resulting dialog fill it in like in the picture below (click to see a bigger version) making special note of the radio button at the top
3. On the GWIA properties -> Network Address enter the server's IP address and a unique port on the Message Transfer port.
4. On the Internet Addressing tab on the domain enter the Alternate GWIA that you actually do want to handle all the outbound mail.

You do not want to install any GWIA software or start this dummy GWIA. Now in GroupWise System Operations | Internet Addressing you want to specify this dummy GWIA as the default outbound GWIA for the entire system. What this just achieved is it gets all outbound internet mail in the system to be routed to this domain for this dummy GWIA. The MTA will not be able to communicate to the GWIA on the port you specified so it enters into (for want of a better term) 'failover' mode.

Obviously, we need to get the rest of the system ready to handle the alternate GWIA setup. Here's how - on any domain that contains a functioning GWIA:

1. Setup the MTA-->GWIA communications to use TCP/IP - this is simply achieved by entering the server's IP address and unique port on the GWIA Network Address tab, like we did above. Make sure that you hit F6 on both the MTA and GWIA to get them to restart afterwards and that the MTA shows the GWIA as open and F10 | Configuration on the MTA shows the GWIA on an IP address and not a UNC path.
2. On the Internet Addressing tab of the GWIA's domain override the default outbound GWIA and select it's own GWIA and also enter an alternate GWIA.

With planning you can chain the failover. Let me explain how it works with an example - imagine we have 4 domains; DOM1, DOM2, DOM3 and DOM4. In dom1 I create my dummy GWIA, DOM2 and DOM3 have real GWIAs and DOM4 has my post offices in it.

On DOM1 I specify DOM2.GWIA as my alternate.

On DOM2 I specify DOM2.GWIA as my default and DOM3.GWIA as my alternate.

On DOM3 I specify DOM3.GWIA as my default and DOM2.GWIA as my alternate.

I am going to coin the term 'chained group' here - to signify an initial dummy GWIA and a series of alternates.
Now, a user in DOM4 sends a mail to the internet - as the system default outbound GWIA is DOM1.GWIA the mail gets routed to DOM1. The MTA there will not be able to contact it's (dummy) GWIA so it checks what it's alternate is. It sees that it's DOM2.GWIA so it attempts to contact the Message Transfer Port of that GWIA directly (note that it's not going back across the domain links). If that works then DOM2.GWIA will deliver the mail. Here's the smart part - if DOM2.GWIA is down then the MTA at DOM1 will look up what DOM2's alternate GWIA is and attempt to contact that one instead - again, directly instead of across the domain links. You can chain as many as you want in this way.
Now, I do recognize that some of you have multiple outbound GWIA's - either based on load or geographic location. You can still do this, but you need to override a few more things. What you would need to change is the current default outbound GWIA to instead point to a local dummy GWIA - then specify a real alternate GWIA on that hub domain. You can essentially create a whole series of chained groups to handle geographies or whatever.

And now the why's.

Why create the dummy GWIA in the first place?

Here's why. In most cases your GWIAs are installed on the same server as the domain, thus also the MTA - so if a GWIA goes down usually the MTA is down too. If this is your default outbound GWIA then the mails never get to the MTA so the whole MTA 'failover' mode never kicks in and we don't hit the chained group. By having the dummy GWIA we are getting the mails to an MTA that is pretty much always going to be up (MTA's rarely abend) and the rest of the mail flow from that point doesn't really care if any of the other MTAs are up.

If you read between the lines above you will have spotted that I am recommending that you don't put the domain with the dummy GWIA on the same server as a real GWIA - otherwise you have achieved nothing.

Why doesn't this do loadbalancing?

Loadbalancing is not the point of this - it's high availability. To loadbalance you would specify different default outbound GWIAs on the different domains or POs to invoke different chained groups - loadbalanced AND highly available. Granted this is not true load balancing but hey, it's close.

I just noted that Google have finally released a Google Desktop for Linux. They even have a ready made SuSE RPM. I just installed it on my SLED10 SP1 workstation so I will see how it does - to be fair I don't actually search my workstation all that often and Beagle was doing what I needed it to.

*Update * - OK, it's been something like 3 weeks and I have used Google Desktop a grand total of once.  I moved to Linux before the whole google desktop craze and I guess I imagined it to be more useful than I am finding it - it is not the 'can't live without it' app that the hype had me believing.   I find Beagle more useful and the results much more nicely displayed and if/when we get a GW plugin for it then I'll be completely stoked.

Yes, by now I guess most of you saw that the GroupWise 7.0.2 Hot Patch didn't really live up to it's name.  We had a couple of build issues that caused some multilingual client files and some WebAccess files to get left out.  Far from ideal and we have put additional processes in place so it doesn't happen again but we have fixed those plus a couple of other issues and released Hot Patch 1a.  If you did roll out HP1 then you will only need to update WebAccess, GWIA and any multilingual clients - no need for MTA or POA.  GroupWise 6.5 customers do not need another update.

Yesterday we announced that we had fixed a GroupWise security vulnerability. I am not posting to discuss the details of the vulnerability but I want to, again, give you pointers on how to update your system. First, the TID - here.

Next, the files - they are all linked from the TID but for completeness 6.5 and 7.

Lastly, how to update - well I already blogged on this so I am just going to link you there and then add a couple of fine points specific to this update.

A couple of differences on this one are that the POA's all need to be updated before you can install the new client or new GWIA and WebAccess. So, from this point forwards, the 7.02 Hot Patch client can no longer connect to an older POA. This is kind of a stake in the sand as, after this, the rule will reapply, you're just not going to be able to connect to a POA older than May 24 2007 with a client dated May 24 2007 or later.