From Sfvlug

Revision as of 09:04, 23 August 2010

# -*- python -*-

if xm_vars.env.get('install'):
    kernel	= "/var/lib/xen/images/osol-0906-unix.amd64"
    ramdisk	= "/var/lib/xen/images/osol-0906-x86.microroot.amd64"
    extra	= "/platform/i86xpv/kernel/amd64/unix " + \
		  "- nowin -B install_media=cdrom"
    disk	= [ "phy:/dev/VolGroup00/osolvm,xvda,w",
		    "file:/home/jeff/OpenSolaris/osol-0906-x86.iso,6:cdrom,r"
		    ]
    on_reboot	= "destroy"
    on_crash	= "destroy"
else:
    kernel	= "/var/lib/xen/images/osol.0906.xpv.unix"
    ramdisk	= "/var/lib/xen/images/osol.0906.xpv.boot_archive"
    extra	= "/platform/i86xpv/kernel/amd64/unix -B " + \
		  "zfs-bootfs=rpool/ROOT/opensolaris,"	   + \
		  "bootpath=/xpvd/xdf@51712:a"
    disk	= [ "phy:/dev/VolGroup00/osolvm,xvda,w" ]
    on_reboot	= "restart"
    on_crash	= "restart"

name		= "osolvm"
uuid		= "280b2556-94c8-49e0-b9c8-1127d57cee9c"
maxmem		= 1024
memory		= 1024
vcpus		= 1
on_poweroff	= "destroy"
vif		= [ "mac=00:16:3E:A8:01:04,bridge=xenbr0" ]

The above is how I got started, installed and running with OpenSolaris 0906 in Xen. As anybody should know, installation is just the beginning. Next I sat down and tried to turn my OpenSolaris installation into a functional member of my LAN.

And just what does being a functional member of my LAN mean? In short it means users are authenticated via LDAP, they NFS mount their HOME directories using the automounter, and the machine participates in IPv6. It also means my own user account needs to be treated as the administrator via some mechanism available, be that using su(1m), sudo(1m), or something else. In the case of OpenSolaris, that something else is called pfexec(1).

LDAP Authentication under OpenSolaris

Unfortunately, and leading to much hair pulling, the Solaris pam_ldap and nss_ldap modules don't use SSL the way we can easily manipulate it using the openssl command line. However, they do use the Netscape Security Services package, so I had to learn how to use the tools in that package. First was to install the package:

pkg install SUNWtlsu

Step two, initialize a new security database with the Netscape tool. This will generate three files, cert8.db, key3.db, and secmod.db. Change the permissions as they need to be world readable.

cd /var/ldap
certutil -N -d `pwd`
chmod 0644 *.db

Step three, assuming a copy of your root CA certificate is in /tmp, import it and optionally, list out the database's contents which should now be only your root CA.

certutil -A -n cacert -i /tmp/cacert.pem -a -t CT -d `pwd`
certutil -L -d `pwd`

Now, here's the part that tripped me up every time I tried this. In spite of the fact the commands say TLS, the Solaris client does not use starttls! It seems to only work using traditional SSL. This means the client does not connect to the plain text TCP port of 389, do a starttls command and upgrade to encryption; instead it must connect to port 636 which is LDAPS. I kept trying to do port 389 with TLS and failed.

ldapclient -v manual -a credentialLevel=proxy \
                     -a proxyDN=cn=Manager,dc=example,dc=com \
                     -a proxyPassword=soopersekrit \
                     -a defaultServerList=ldap:636 \
                     -a defaultSearchBase=dc=example,dc=com \
                     -a authenticationMethod=tls:simple \
                     -a serviceAuthenticationMethod=pam_ldap:tls:simple \
                     -a certificatePath=/var/ldap \
                     -a serviceSearchDescriptor=passwd:ou=People,dc=example,dc=com \
                     -a serviceSearchDescriptor=group:ou=Group,dc=example,dc=com

If you leave in the -v flag for verbose output, you'll see a lot of information fly by, followed by one or more services, possibly even networking, being stopped and started. It may take several seconds before the command returns. One final note, I don't know if the serviceAuthenticationMethod parameter is actually required, but it doesn't seem to hurt my case any.

Before you can authenticate a user using LDAP on OpenSolaris, you need to solve one more chicken and egg style problem. In the server list, I used a DNS name for my LDAP server. However, ldapclient just copied /etc/nsswitch.ldap over /etc/nsswitch.conf, and guess what? The original /etc/nsswitch.ldap does not tell the resolver to use DNS for host names -- it uses LDAP! Right, in order to resolve the name of our LDAP server, we need to connect to our LDAP server, for which we don't know the address. I'm sure that in some peoples' minds, this counts as a bug.

Open up /etc/nsswitch.conf in your editor, and change the hosts: and ipnodes: lines to "files dns mdns," getting rid of LDAP in the entries. Of course, if you actually have host information in your LDAP tree, leave it in. I do not. Also, make sure you are only using LDAP to look up data that you are serving with LDAP. In my case I removed the "ldap" entry from all the databases except passwd: and group:. Save /etc/nsswitch.conf and try to identify a user that's only in the LDAP tree using id username, and getent passwd username.