We’re currently testing Sun ONE Calendar on a Sun Fire V210/Solaris 9 system.

So far, things look good. We’re using v 5.1.1, and it integrates well with the directory server (v 5.1). The installation is straightforward.

Additions:

• I’ve enabled another color palette and set it to default to mimic the red and white scheme of Earlham’s colors.

• I found basic PHP source code from Rutgers to access public calendars in a way that can be used in an Apple iCal subscription. I have translated this to perl and put it in the CGI directory of our main web server.

• A number of sites run Calendar Express behind an SSL connection, the one I found that worked was to put in Pound to handle the SSL proxy, to use an HTTPS URL for the ui.base.url value, and to modify the default.html to include JavaScript that puts out a refresh target for non-https connections:

if ((document.URL=='http://calendar.earlham.edu/') && (!location.search)) {
    document.write("<meta http-equiv=\"refresh\" content=\"0; URL=https:/calendar.earlham.edu/\">");
}

• I have a basic perl script that converts Russell Calendar Manager ASCII export data into iCal format for import into Sun ONE. The only thing it does not handle “properly” is multiple attendees to an event: while it lists all attendees as confirmed, it does not enter the event into their calendars (it can’t given the access permissions standard on most people’s calendars).

I'm doing some exploration of mail routing using LDAP.

The Email and LDAP chapter of O'Reilly's LDAP System Administration book is available free in PDF format. It covers how to set up e-mail clients to access LDAP servers for address book information and also how to configure three popular MTAs to use LDAP for map and routing information.

The chapter assumes that one is working with OpenLDAP. As we will be using the Sun ONE Directory Server, some things need to change. Particularly for the Sendmail routing information, the object class we should use is already built in to the DS: mailRecipient. This object class does not define the attribute mailLocalAddress, but I believe we can simply use the mail attribute and put the same value in it (it should be the canonical e-mail address of the user, in either case).

The routing support may come in handy when (if?) we move seminary users to receiving mail on the seminary servers.

I've done some more testing of OpenLDAP, and have found that FreeBSD's lack of a flexible name switching service might be a significant limitation in LDAP's usefulness.

FreeBSD 4's limited PAM support presents additional problems. While a pam_ldap module does exist and can be used to authenticate most services, programs such as passwd(1) do not have PAM support, and cannot authenticate against or change password information in an LDAP directory.

FreeBSD 5 has somewhat better support for LDAP. passwd(1) has LDAP support, but there still is no name support for LDAP, so UIDs and GIDs cannot be mapped to usernames after authentication. What this means is that while LDAP can be used to login (authentication), it cannot be used to determine ownership of files (authorization).

These limitations could be worked around by creating a set of scripts to synchronize an NIS map with an LDAP directory, and have authorization functions go over NIS rather than LDAP. Since passwords are only required during authentication, no password information need be stored in the NIS map, which would significantly improve its security.

Red Hat Linux has complete support for LDAP. With the nss_ldap package from PADL, LDAP can be listed in the nsswitch.conf(5) file, in the same manner that NIS and other name lookup facilities are presently. Presumably other Linuxes, System V-based Unixes such as HP-UX, and commercial BSDs such as AIX have similar methods of adding LDAP support.

Solaris 9, release 12/02 solves the MD5 crypt problem noted earlier.

I did an upgrade install of Solaris 9 12/02 over the Solaris 8 install on the SunFire. This kept the same iPlanet installation. Testing against this with MD5 crypted passwords was successful. I am currently investigating newer LDAP directories for the Solaris 9 platform, as it seems clear that this is what we'll want to pursue.

The results are in: I tested iPlanet 4.12 on Solaris 8 with good success. Presumably Sun ONE DS 5.1 will be at least as good performance-wise.

The test box was a SunFire V120 with a 650Mhz processor and 1 Gb RAM. iPlanet Directory Server (aka Netscape) 4.12, which came with our Solaris 8 media was installed. I added the Samba schema to the core files. Loading the authentication information is relatively painless (the same ldapadd function works). Changes to the data include changing the ou=Group to ou=Groups for all groups (the Groups ou is already present in iPlanet), removing the duplicate ou=People and the base dn from the LDIF file. Everything else added without a problem.

Difficulties are to be found in the authentication and binding: specifically, we have a number of users whose passwords are stored in MD5 crypt format (Linux, FreeBSD, etc. style). Unfortunately, this does not work on Solaris 8: the crypt(3c) library only supports DES crypted passwords. This post on the focus-sun mailing list gives the basic rundown: MD5 crypt is not supported in Solaris 8; it is supported in the 12/02 release of Solaris 9. So to use iPlanet or Sun ONE without a painful migration strategy we'll have to get Solaris 9.

Aside from the crypt issue, the directory server performed extremely well. The basic test is to point Mozilla's LDAP address book at the server and run a search for something common (like "Tom", "Smith", or "John"). With OpenLDAP, these searches finished within 30 seconds. With iPlanet 4.12, the searches returned within 2 seconds. The same indexes were established as on OpenLDAP. Most telling is that vmstat shows no more than about 5% CPU utilization while performing a search from Mozilla (it's slightly higher when using the administrator console, but that's a Java application).

I think the search performance issue points clearly to using Sun ONE as the directory server over OpenLDAP. While OpenLDAP performs quite adequately for authentication, I would like to use the directory server for general searches in e-mail clients, and I don't know what sort of load something like a portal or calendar server would put on it. With these considerations, something that performs this well with general searches tunrs into a necessity.

I have, or am very close to having, a working Jumpstart system for Solaris 8 servers.

ROJ is the Jumpstart server, and the relevant directory trees are /export/home/jumpstart and /export/home/jump_5.8. The former is the global Jumpstart area (useful for all versions of Solaris), while the latter is specific for Solaris 8.

Much of the Jumpstart system is standard, with slight modifications as described by Hal Pomeranz. The local modifications are in the post-install script and the Solaris 8 extra packages directory.

Post-install script

The post-install script is in /export/home/jumpstart/Drivers/5.8/sparc-v120/post. It's somewhat complex and governs the fine-tuning of the Jumpstart installation. Its first task is to ask the admin for a local profile (currently Generic and DirectoryServer are supported). It uses this profile to set various options, including which package sets to install and what rcs.mgr profile to load (see below). Some profiles may also request RADIUS client information.

The best documentation is in the post-install script, however the overview is that it installs various packages, creates some further startup scripts to run security stuff (fixmodes, the rcs.mgr, disabling rc?.d scripts) and then exits. The system reboots, and then runs the startup scripts created by the post-install script. One of these will likely be the installation of the latest recommended patch cluster, which will take a long time and force another reboot. The rcs.mgr initialization will also force a reboot (for things like /etc/system).

After the various reboots, you should have a base system tuned for the purpose indicated by the local profile. Note that you may still need to install software, as some things are best installed by hand (e.g. iPlanet Directory Server, Oracle 9i, WebDB code...).

Packages

The Solaris 8 extra packages directory is /export/home/jump_5.8/Packages. I have copied the latest versions of various Sunfreeware.com packages here, along with a few packages maintained by me (ECS*) and the DiskSuite packages. These are in filesystem format. The post install script selects various packages from here for installation.

The other part of this directory is the rcsmgr-snap directory. This contains rcs.mgr initialization files for each of the post-install profiles. There is one directory within here for each profile (or a symbolic link pointing to the Generic directory). This directory has tuned install files for rcs.mgr for that profile. The post-install script copies these, along with the initialization script and configuration file to the Jumpstart client so that they may be installed after reboot.

We've been playing with LDAP authentication and making the RADIUS server work with it. Skylar has led the way in optimizing OpenLDAP performance. FreeRADIUS has a number of authentication modules, among them a working LDAP one. A request from upstairs has initiated a look into the latest version of EZproxy, the software that controls access to the library's online journal and database subscriptions.

This diagram shows how the future authentication system will work. The primary question at this point is whether we will use OpenLDAP or Sun ONE (iPlanet) for the directory server. So far, performance of OpenLDAP looks good, although it can be seen to degrade when running a substring address search (like the kind found in the Mozilla LDAP address book). Skylar found that indexing the LDBM database makes a huge difference in search times (not surprisingly). It also appears that the cache sizes may play a significant role. Currently, a test instance of the LDAP server on SHANTI has the following specified:

cachesize               8192
dbcachesize             20971520
index   objectClass     eq
index   uid             pres,eq,sub
index   uidNumber       eq
index   gidNumber       eq
index   rid             eq
index   memberUid       eq
index   cn              pres,eq,sub
index   mail,displayName,givenName,gecos,sn     eq,sub

In general authentication and authorization, the most common lookups will be uid, uidNumber, gidNumber, and rid (Samba unique identifier). Indeed, turning on these indices greatly speeds things. The last index line makes Mozilla address book searches much faster, although it doesn't solve the problem completely. The cachesize entry indicates the number of directory entries to keep in cache, while the dbcachesize entry indicates the amount of memory to allocate (in bytes) for the index cache. It's possible that both of these could be significantly increased; there's still at least 300 Mb of free memory on SHANTI with the current settings, and RAM is easy to get.

The next step is to obtain a copy of the Sun ONE directory server and test its performance on one of our Solaris machines.

The authentication diagram shows that RADIUS will still be used for a number of authenticated services. I have built a FreeBSD package of FreeRADIUS 0.7 that includes LDAP authentication. This will replace the current hand-installed FreeRADIUS installation on SHANTI. The salient parts of the radiusd.conf file are within the modules section:

ldap {
     server = "ldap.earlham.edu"
     basedn = "dc=earlham,dc=edu"
     filter = "(uid=%u)"
     start_tls = yes
     ldap_cache_timeout = 120
     ldap_cache_size = 64
     ldap_connections_number = 10
     password_attribute = userPassword
     timeout = 10
     timelimit = 10
     net_timeout = 5
}

Of course, ldap must be mentioned in the authorize and authenticate sections as well. This all works quite well.

EZproxy ties into this as well. Some of our subscriptions will require a finer grain of access control than we currently have with the proxy software (version 1.4g). Apparently, the current version (2.0i) adds a bevy of authentication systems and the ability to use group authorizations. Within the ezproxy.usr configuration file, it will be possible to specify something like:

::group=Default+Restricted
::acctype=student,ldap=ldap.earlham.edu,uid=$U,ou=Students,dc=earlham,dc=edu
::acctype=employee,ldap=ldap.earlham.edu,uid=$U,ou=Employees,dc=earlham,dc=edu
::group=Default
::acctype=others,ldap=ldap.earlham.edu,uid=$U,ou=Others,dc=earlham,dc=edu

This will allow users authenticated in the Students and Employees organizational units of LDAP to have access to the databases marked as Default and Restricted while those in the Others ou only have access to the Default databases. The "acctype=group" is a CGI variable passed by the login form, although I find that it's probably not necessary. This will require us to be a little more diligent in defining groups and organizational units (such as students, employees, alumni, prospectives, seminary affiliates, etc.).

The corresponding part of the ezproxy.cfg file that marks the databases is

Group Restricted

T Restricted database

U http://www.example.com/privatedb

D www.example.com

Group Default

T FirstSearch

U http://newfirstsearch.oclc.org

D newfirstsearch.oclc.org