Up to Something

We win again. I wanted to run Scalix for a client, inside of a VE/CT/whatever, and I tried using Fedora Core 7 to do so. I was unable to make the installer work and didn’t see much in the way of help from Scalix. Here is a link to the Bugzilla page. (Login Required) Here are the important bits. Aside from discouragement I didn’t get anything from Florian… Nothing except responses that was. No one else seems to give a damn if I even exist.

Whatever. The point is that with some minor extra-effort, Scalix does indeed work inside of an OpenVZ container on Linux. My host OS is gentoo, running 2.6.18-028stab053.

The Scalix package is pretty great, just up the Java memory once you have it running. The instances (two) on a system shared by two different companies work great. We migrated to Scalix from Kolab. Outlook users (all two) are happy. Thunderbird users didn’t see too much of a change.

Yay for us.

We were messing w/ Postfix and Cyrus IMAPD today. Our prime goal was making a sensical approach to authenticating against a PostgreSQL-based directory. LDAP (OpenLDAP and FDS) based tools sucks for most people. Using native-box-auth is actually quite messy. The mail data cannot be easily associated with the users. You end up with data spread everywhere.

Our basic tenants are:

• Simple Database Schema - there is no need for a highly relational approach for something so simple.
• Embedded procedures where possible.
• Simple front-end.

My esteemed colleague John implemented our thoughts. He ended up with a few PGSQL functions, a couple views and a very straight-forward process.

The actual setup for IMAPD and Postfix is nearly as simple. He will be documenting it at his site later. For now, we wanted to verify the actual behaviour of postfix and imapd during SASL auth in realtime. We turned to inotify. I install pyinotify, and used thier Quick Start script. This ended up leaving me a simple script which monitored the directories which I wanted.

This will not show you files which failed to open. But it does good enough.

import os
from pyinotify import WatchManager, Notifier, ThreadedNotifier, EventsCodes, ProcessEvent

wm = WatchManager()

mask = EventsCodes.IN_DELETE | EventsCodes.IN_ACCESS | EventsCodes.IN_OPEN | EventsCodes.IN_CREATE  # watched events

class PTmp(ProcessEvent):
    def process_IN_CREATE(self, event):
        print "Create: %s" %  os.path.join(event.path, event.name)

    def process_IN_DELETE(self, event):
        print "Remove: %s" %  os.path.join(event.path, event.name)

    def process_IN_ACCESS(self, event):
        print "Access: %s" % os.path.join(event.path, event.name)

    def process_IN_OPEN(self,event):
        print "Open: %s" % os.path.join(event.path, event.name)


notifier = Notifier(wm, PTmp())
wdd = wm.add_watch('/etc', mask, rec=True)
wdd = wm.add_watch('/usr/lib/sasl2', mask, rec=True)

while True:  # loop forever
    try:
        # process the queue of events as explained above
        notifier.process_events()
        if notifier.check_events():
            # read notified events and enqeue them
            notifier.read_events()
        # you can do some tasks here...
    except KeyboardInterrupt:
        # destroy the inotify's instance on this interrupt (stop monitoring)
        notifier.stop()
        break

I setup VMWare Server on Gentoo the other day. It was pretty much easy. After install, cleanup all the .vmware folders in various home directories. Assign users with priv's to the 'vmware' group.

User Setup

gpasswd -a vmadmin vmware

Run the vmware-config.pl - Note the network numbers.

Network Setup

e.g.

• Host-only: 172.16.42.0/24
• NAT: 10.51.1.0/24

Vmware will NAT on the 10.51.1.0 network. Linux will have something like:

• vmnet0 172.16.42.1
• vmnet8 10.51.1.1

Next, fixup /etc/xinetd.d/vmware-authd

--- vmware-authd~       2007-10-13 13:26:18.830128814 -0700
+++ vmware-authd        2007-10-13 13:36:42.833942428 -0700
@@ -10,5 +10,5 @@
     user            = root
     server          = /opt/vmware/server/sbin/vmware-authd
     type            = unlisted
-    only_from      =
+    only_from      = 0.0.0.0/0
 }

Firewall Setup

Once you get a guest running, you discover that DHCP on the NAT network provides a gateway of 10.51.1.2. That is great for VMWare-based NAT setup. See /etc/vmware/vmnetX/nat/nat.conf to tweak the NAT settings. I wanted to use shorewall, complete with NAT and port forwarding. I installed/configured shorewall. After that, I setup the NAT and port-forwarding rules. Finally, I connected to the Guest OSs which I wanted to expose, assigned static IPs and set thier default gateway to .1 instead of .2. This effectively removed them from the control of VMware nat. And that was is awesome.

Cisco VPN concentrators are a regular occurrence in the field. They can be the bane of your life. However, there is one simple change to enable these to consistently work with multiple policy routed subnets.

In your /etc/ipsec.conf use set the policy level to 'unique' instead of 'require'.

The entries in /etc/ipsec.conf are fully covered in the ipsec.conf man pages, and online at various locations. Google and find. My focus is the 'policy-level', the last value in the spdadd string. I have only ever seen it set to 'require', but recently I discovered the 'unique' as well as the 'unique:<1-32768>'. This allows for negotiating Phase2 crypto per-policy, or per-group. (unique:). Here is my example of a config which works with a large Cisco VPN concentrator.

Consider this policy file:

/etc/ipsec.conf

#### Tunnel: CheeseSteak Club
  spdadd 88.88.30.231       192.168.1.240/28 any -P in  ipsec esp/tunnel/88.88.30.231-66.66.177.102/require;
  spdadd 192.168.1.240/28   88.88.30.231     any -P out ipsec esp/tunnel/66.66.177.102-88.88.30.231/require;

  spdadd 99.99.0.0/16       192.168.1.240/28 any -P in  ipsec esp/tunnel/88.88.30.231-66.66.177.102/require;
  spdadd 192.168.1.240/28   99.99.0.0/16     any -P out ipsec esp/tunnel/66.66.177.102-88.88.30.231/require;

  spdadd 99.99.0.0/16       66.66.177.102    any -P in  ipsec esp/tunnel/88.88.30.231-66.66.177.102/require;
  spdadd 66.66.177.102      99.99.0.0/16     any -P out ipsec esp/tunnel/66.66.177.102-88.88.30.231/require;

#### Tunnel: Guinness Brewery Concentrator
  spdadd 44.44.82.31         192.168.1.0/24  any -P in  ipsec esp/tunnel/44.44.82.31-66.66.177.102/unique;
  spdadd 192.168.1.0/24          44.44.82.31 any -P out ipsec esp/tunnel/66.66.177.102-44.44.82.31/unique;

 ## Main Net (ireland)
  spdadd 10.1.30.205          192.168.1.0/24 any -P in  ipsec esp/tunnel/44.44.82.31-66.66.177.102/unique;
  spdadd 192.168.1.0/24          10.1.30.205 any -P out ipsec esp/tunnel/66.66.177.102-44.44.82.31/unique;

  spdadd 10.1.30.205          66.66.177.102  any -P in  ipsec esp/tunnel/44.44.82.31-66.66.177.102/unique;
  spdadd 66.66.177.102   10.1.30.205         any -P out ipsec esp/tunnel/66.66.177.102-44.44.82.31/unique;


 ## Mainland Dist. Net (America: New York)
  spdadd 10.1.30.210          192.168.1.0/24 any -P in  ipsec esp/tunnel/44.44.82.31-66.66.177.102/unique;
  spdadd 192.168.1.0/24          10.1.30.210 any -P out ipsec esp/tunnel/66.66.177.102-44.44.82.31/unique;

  spdadd 10.1.30.210          66.66.177.102  any -P in  ipsec esp/tunnel/44.44.82.31-66.66.177.102/unique;
  spdadd 66.66.177.102   10.1.30.210         any -P out ipsec esp/tunnel/66.66.177.102-44.44.82.31/unique;


 ## Western Region Sales (America: Seattle, Wa)
  spdadd 10.2.30.200          192.168.1.0/24 any -P in  ipsec esp/tunnel/44.44.82.31-66.66.177.102/unique;
  spdadd 192.168.1.0/24          10.2.30.200 any -P out ipsec esp/tunnel/66.66.177.102-44.44.82.31/unique;

  spdadd 10.2.30.200          66.66.177.102  any -P in  ipsec esp/tunnel/44.44.82.31-66.66.177.102/unique;
  spdadd 66.66.177.102   10.2.30.200         any -P out ipsec esp/tunnel/66.66.177.102-44.44.82.31/unique;


 ## Backup Network (America: Cheyenne, WY)
  spdadd 172.16.106.10        192.168.1.0/24 any -P in  ipsec esp/tunnel/44.44.82.31-66.66.177.102/unique;
  spdadd 192.168.1.0/24       172.16.106.10  any -P out ipsec esp/tunnel/66.66.177.102-44.44.82.31/unique;

Linux is pretty awesome, but sometimes manufacturers and hardware can be a pill. On such instance are LSI Logic MegaRAID controllers. From Dell PERC to HP NetRAID to off the shelf stuff, these can be the bane of your existance. Today I have the mispleasure of dealing with one that is partially/not-really supported.

• http://lwn.net/Articles/143397/
  
  

  livecd ~ # lspci
  .....
  01:02.0 0104 RAID bus controller: American Megatrends Inc. MegaRAID (rev 21)
  .....
  
  livecd ~ # lspci -n 
  .....
  01:02.0 101e:1960
  .....
  
  livecd ~ # echo "101e:1960" > /sys/bus/pci/drivers/megaraid_legacy
  

  That pretty much covers it, the long hand it this:
  • Locate the device PCI address, using lspci
  • Use 'lspci -n' to locate the PCI Device ID. (Hint: The PCI Address remains the same.)
  • echo 'XXXX:XXXX' into the 'new_id' node inside the proper sysfs pci/drivers driver directory.