March 31, 2003
[MIR] Sendmail patch on MIR

I downloaded and installed Sendmail RPMs from RedHat's support site. I installed the base, cf, and doc packages. Everything's fine.

Posted by littejo at 01:48 PM
March 29, 2003
[KE] Sendmail patch

Another security flaw found in Sendmail, as per this patch announcement.

I built a new Sendmail 8.12.6 package (sendmail-sasl-8.12.6_3ecs) and installed it on KE. I used the generic 8.12 patch file in the patch tarball referenced in the page above.

Posted by littejo at 07:53 PM
March 26, 2003
[R&D] LDAP, Solaris 9

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.

Posted by littejo at 04:44 PM
March 25, 2003
[R&D] LDAP: iPlanet

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.

Posted by littejo at 01:22 PM
March 24, 2003
[R&D] Jumpstart

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.

Posted by littejo at 10:20 PM
March 14, 2003
[R&D] LDAP, RADIUS, EZproxy

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

Posted by littejo at 09:04 AM
March 03, 2003
[KE] Sendmail upgrade

Sendmail upgraded on KE, same issue as MIR.

KE is special: we're using the sendmail-sasl port from the FreeBSD ports tree because we want to provide both SMTP AUTH and STARTTLS (which are not present in the default sendmail, particularly for FreeBSD 4.5). I have built a new package on my workstation, labeled sendmail-sasl-8.12.6_2ecs. This package include the 8.12 patch from sendmail.org. It still calls itself 8.12.6, however it is a fully patched version.

It seems to be working properly.

To apply the patch to the FreeBSD ports tree, I downloaded the patch (above) and saved it as /usr/ports/net/sendmail/files/patch-ab. The ports make system automatically applies patches with that filename scheme. Searching the source files after make for a post-patch modification (like "Dropped invalid comments from header address" in sendmail/headers.c) shows that the patch worked. This string is also in the sendmail binary (/usr/local/sbin/sendmail - use the strings command to look for it).

Posted by littejo at 09:40 PM, updated 10:40 PM March 03, 2003
[MIR] Sendmail upgrade

I upgraded Sendmail on MIR to take care of CERT Advisory 2003-07.

I used RH6.2 RPMS from RedHat support. The one oddity about this is that this removes support for SMTP AUTH on MIR. This should not be a big deal, since this is primarily a high order mail exchanger and not a system where we expect people to point their mail clients in sending mail.

Note: I have to edit /usr/lib/sendmail-cf/cf/Makefile to change CFDIR to an absolute pathname in order to get the rcs.mgr install script to work properly.

Posted by littejo at 05:37 PM, updated 10:41 PM March 03, 2003