Accessing Novell Groupwise from Ubuntu, Mint, etc

We use Groupwise at work, and up until recently Groupwise support was available in Evolution. I don’t know why it was dropped, but it’s fairly easy to reinstate it again if you’re prepared to build from source.

These are the steps I used to build it on two Linux Mint installations, although it should work on Ubuntu and Debian too.

Edit /etc/apt/sources.list and ensure you have deb-src equivalents for all your main, universe and multiverse repositories

sudo apt-get update
sudo apt-get install libedata-book1.2-dev libedata-cal1.2-dev evolution-dev libdb5.1-dev libcamel1.2-dev
sudo apt-build dep evolution

All being well, a big bunch of build dependencies will be installed

cd ~/src/
git clone
git checkout -b 3.2.0-patch EVOLUTION_GROUPWISE_3_2_0
# This is the patch for the SOAP port bug
git cherry-pick 3aae80f55d5fd565274f19210564e74d5350a66c

All being well, ./ will finish and tell you to run make to compile it.

make ; sudo make install

Now, the makefile doesn’t seem to copy over some UI elements, which means the Proxy login feature destroys Evolution if you try to use it. A quick workaround is to copy them from your source tree to your system.

sudo cp src/plugins/*.ui /usr/share/evolution/3.2/ui/

Kill any existing Evolution components…

ps waux | grep -i evolutio[n] | awk {'print $2'} | xargs kill -9

Run evolution from the command line


Changing OES DHCP Range

Recently we were in the unfortunate position of running out of IP address in our DHCP pool. The Novell DNS/DHCP Management Console will give you a handy utilization % for your subnet, but will not tell you how much of your allocatable pool is in use. As a result, machines were timing out whilst waiting for an IP.

To diagnose this, we loaded dhcpsrvr.nlm with the -d3 option, and checked sys:/etc/dhcp/dhcpsrvr.log. The tell-tale sign is copied below.

67  : Get type:2, IPAddr:, LeaseTime:0, MacIndx:774, pIP:B23F2540
AMAGet() exit err:0, subnet:, addr:
2010/05/21 10:15:56  <DHCPINFORM> packet received from client <0:13:72:9D:1C:E6>, IP Address <>.
2010/05/21 10:15:56  Sending BOOTP/DHCP reply <DHCPACK> to <0:13:72:9D:1C:E6> as <>.
Get type:4, IPAddr:, LeaseTime:0, MacIndx:1042, pIP:0
Fill pool returned error 1
Error 5 adding new ip
AMAGet() exit err:5, subnet:, addr:

Ultimately, we needed more addresses in the pool. It would appear that in order to change your pool range in OES, you export the pool, edit it, and reimport the pool.

This seemed like far too much of a faff for me, so it was time for some rummaging. Normally the eDirectory enabled DHCP server stores lease data in eDirectory. First port of call was the WM_Subnet container that we use for those objects. In there, there’s an object called WM_Range. This contains details of the IP range available for DHCP use.

First off, unload the dhcpsrvr.nlm module, and then open the object up in ConsoleOne, and click on the “Other” tab. The attributes “DNIP:Start Address Number” and “DNIP:End Address Number” are decimal representations of the start and end IPs respectively, and can be expanded out to edit each attribute individually. Simply overwrite the current entry with the new decimal address that you want to use, click ok, and load dhcpsrvr.nlm back up.

Figuring out a decimal address is fairly easy, and is described in this Technet article. You can also convert a quad octet (IP address) to decimal notation with an online calculator.

Lost your APC UPS?

I was in a sticky situation this weekend. I had casually set up one of our APC UPS RT 5000 units to use DHCP to get a statically assigned address. However, I hadn’t implemented Option 43 on the DHCP server and the APC management card had fallen off the network.

Unable to find a serial cable of the right type, and unable to get the card onto the subnet, I was faced with resetting the firmware. That was until I read the manual!

With the APC9619 card, at least, if you know the MAC address (I did, it was in our DHCP server config), you can prod the card with an ICMP packet to assign the desired address.

Simply do this…

Assign an IP address to the MAC address in your local ARP table
sudo arp -s 00:C0:B7:CA:D8:9B

Ping the address with a 113 byte ICMP packet.
ping -s 113

This causes the management card to accept the address as its own, and at that point you can now telnet to the card and enter the administration console (unless you like clicky pointy things, in which case you can use your web browser)

It seems to time out rather quickly, so don’t mess about in the admin console. Jump in, remove the DHCP Vendor cookie requirement (2, 1, 1, 1, 2, 8, 1, 9) and reboot the management card.

All done! No cables, no firmware, no massive reconfiguration.