Zakynthos Configuration

From ImageWeb

Jump to: navigation, search

Contents

Overview

ADMIRAL system build procedure

  • If this is the first time an ADMIRAL system has been built on this host:
    • change to the directory that will contain the mercurial repository for ADMIRAL build software; e.g. /var/kvm/hg/.
    • use hg clone https://admiral-jiscmrd.googlecode.com/hg/ admiral-jiscmrd to create a local copy of the ADMIRAL build software repository.
otherwise:
    • change to the directory that contains a local workspace copy of the ADMIRAL build software repository; e.g. /var/kvm/hg/admiral-jiscmrd/.
    • use hg pull then hg update to obtain the most recent version of the ADMIRAL build software
  • Use makeresearchgroupfiles.sh to create a new instance of the ADMIRAL build scripts tailored to the target environment (hostname, password, etc.) in /var/kvm. (Ensure this script is run from the local mercurial workspace for the ADMIRAL software; e.g. /var/kvm/hg/admiral-jiscmrd/admiral-base/)
  • Change to the directory where the files were just created, e.g. /var/kvm/hostname
  • Use make-admiral-server.sh to create a virtual machine image.
  • If installing to a local virtual machine environment:
    • If this is the first time an ADMIRAL system has been created for this particular target hostname:
      • use virt-install to create an XML domain description for the new VM: 
  virt-install \
    --connect qemu:///system \
    --name (hostname) \
    --ram 256 \
    --disk path=/var/kvm/(hostname)/ubuntu-vmserver/disk0.vmdk,bus=scsi \
    --import \
    --network bridge:br0 \
    --accelerate \
    --os-type=linux \
    --os-variant=ubuntukarmic \
    --vnc
    • If running under KVM for testing, use virsh or virt-manager to start the new VM: 
virsh start zakynthos
  • If installing to a VWare ESXi environment, see the next section for some extra details that need to be addressed. In particular, note that VMWare tools should be installed in the new system, preferably before proceding with the ADMIRAL installation; this can be done via SSH after postboot-1.sh has been run
  • On first boot, the system will complete some configuration actions,
  • Log in to the new system with username admiral and password specified when running the makeresearchgroupfiles.sh script. Then sudo su - to a root shell.
  • Use postboot-1.sh to install and configure the SSH server. Once done, further steps can be performed more conveniently using an SSH login from some other host.
  • If installing to a VMWare hosting environment, now is a good time to isntall VMWare tools (see below for details)
  • Use postboot-2.sh to install and configure additional applications, but not including LDAP:
    • Postfix configuration: select "satellite system"
    • (Mail host): zakynthos.zoo.ox.ac.uk
    • Mail relay host: smtp.ox.ac.uk
    • Nagios web admin password: nagios-zak (choose different value for live systems!)
    • TSM Nodename: zakynthos.zoo
    • TSM password: GqFj+7772 (register a different value for live systems!)
    • Run the TSM client scheduler: yes (default)
    • (software is installed)
    • Command may disrupt existing ssh connections ...: yes (this is the firewall being enabled, but SSH access has been enabled in the configuration).
  • Use postboot-3.sh to install and configure LDAP, authentication and authorization frameworks:
    • LDAP Server URI: ldapi:/// (default)
    • Distinguished name of search base: dc=zakynthos,dc=zoo,dc=ox,dc=ac,dc=uk
    • LDAP version to use: 3 (default)
    • Make root local database admin: yes (default)
    • Does the LDAP database require login: no (default)
    • LDAP account for root: cn=admin,dc=zakynthos,dc=zoo,dc=ox,dc=ac,dc=uk
    • LDAP root account password: use same password specified when running copywithhostandpassword.sh to create the installation scripts. (This may be a red herring, and completely irrelevant - it seems the actual password used is encoded in base.ldif and config.ldif, as created by copywithhostandpassword.sh.)
    • Unpacks and installs LDAP software packages, and initialize LDAP contents
    • When adding access control, Enter LDAP password: (same value as entered above)
    • Enter PEM pass phrase: (same as LDAP password) @@TODO: better choice
    • Enter pass phrase for zakynthos.key.secure: (same as LDAP password) @@TODO: better choice
    • Enter pass phrase for zakynthos.key.secure: (same as LDAP password) @@TODO: better choice
    • Enter pass phrase for /etc/ssl//private/cakey.pem: (same as LDAP password) @@TODO: better choice
    • Sign the certificate? [y/n]: y
    • 1 out of 1 certificate requests certified, commit? [y/n]: y
    • Enter LDAP Password: (same as LDAP password entered above)
    • (2 more times)
    • Samba Configuration File Path [/etc/samba/smb.conf] > (accept default)
    • Smbldap-tools Configuration Directory Path [/etc/smbldap-tools/] > (accept default)
    • workgroup name [testwg] > (accept default)
    • netbios name [] > (accept default)
    • logon drive [] > (accept default)
    • logon home (press the "." character if you don't want homeDirectory) [\\\%U] > (accept default)
    • logon path (press the "." character if you don't want roaming profile) [\\\profiles\%U] > (accept default)
    • home directory prefix (use %U as username) [/home/%U] > (accept default)
    • default users' homeDirectory mode [700] > (accept default)
    • default user netlogon script (use %U as username) [] > (accept default)
    • default password validation time (time in days) [45] > (accept default)
    • ldap suffix [dc=zakynthos,dc=zoo,dc=ox,dc=ac,dc=uk] > (accept default)
    • ldap group suffix [ou=Group] > (accept default)
    • ldap user suffix [ou=People] > (accept default)
    • ldap machine suffix [ou=Hosts] > (accept default)
    • Idmap suffix [ou=Idmap] > (accept default)
    • sambaUnixIdPooldn object (relative to ${suffix}) [sambaDomainName=testwg] > (accept default)
    • ldap master server [localhost:389] > (accept default)
    • ldap master port [389] > (accept default)
    • ldap master bind dn [cn=admin,dc=zakynthos,dc=zoo,dc=ox,dc=ac,dc=uk] > (accept default)
    • ldap master bind password [] > (same as LDAP password entered above)
    • ldap slave server [localhost:389] > (accept default)
    • ldap slave port [389] > (accept default)
    • ldap slave bind dn [cn=admin,dc=zakynthos,dc=zoo,dc=ox,dc=ac,dc=uk] > (accept default)
    • ldap slave bind password [] > (same as LDAP password entered above)
    • ldap tls support (1/0) [0] > (accept default)
    • SID for domain testwg [S-1-5-21-288482045-573168118-3552468495] > (accept default)
    • unix password encryption (CRYPT, MD5, SMD5, SSHA, SHA) [SSHA] > (accept default)
    • default user gidNumber [513] > (accept default)
    • default computer gidNumber [515] > (accept default)
    • default login shell [/bin/bash] > (accept default)
    • default skeleton directory [/etc/skel] > (accept default)
    • default domain name to append to mail adress [] > (accept default)
    • Changing UNIX and samba passwords for root; New password: (same as LDAP password) @@TODO: better choice
    • Changing UNIX and samba passwords for test_admiral; New password: (any value: user is deleted)
    • PAM profiles to enable: select Unix authentication and LDAP authentication; deselect Kerberos authentication (for now)
A couple of error messages mentioning "$#" can, I think, be ignored.
  • If running in the target ESXi environment, allocate a data volume, and configure LVM. See ADMIRAL_LVM_allocation.
  • Use postboot-4.sh to complete the installation.
    • (If running under KVM for testing, use command postboot-4.sh test.)
  • The system is now ready for new users to be configured.
    • The script admiraluseradd.sh can be used to add new users to the system.
    • User test_admiral has been created and can be used for testing the system on a non-logical-volume system. If using logical volumes (e.g. ESXi environment) then the user test_admiral should be deleted (or just ignored).


Skip the next section for ADMIRAL system update procedure as the update procedure deals with only the subsequent updates on the already built VM.

ADMIRAL system update procedure

  • The following procedure needs to be followed if an already built ADMIRAL system needs to pull in the updates:
    • Change to the directory/mnt/data/tool/admiral logging into the system as admin.
    • Use hg pull then hg update to obtain the most recent version of the ADMIRAL build software.
    • Use makeresearchgroupfiles.sh to create a customized copy of the installation build files form the directory /mnt/data/tool/admiral/admiral-base/
    • Change to the directory where the files were just created, e.g. /mnt/data/tool/'hostname'
    • Note:-
      • Ensure that the /root/admiralconfig.d/admiralconfig.sh is similar to /mnt/data/tool/'hostname'/admiralconfig.sh. If not the same or /root/admiralconfig.d/admiralconfig.sh still has old changes, then the new changes need to be copied into the /root/admiralconfig.d/admiralconfig.sh. This ensures that the updateadmiralfiles.sh runs properly and that the submission tool works effectively.
      • Also note any spurious databank-proxy files if present in /var/apache2/sites-available or /var/apache2/sites-enabled needs to be removed.
      • Ensure that a single copy of the databank-proxy.conf file is present only in the /var/apache2/conf.d and that it is similar to the apache-databank-proxy present in the /mnt/data/tool/'hostname'
    • Use updateadmiralfiles.sh to update the ADMIRAL configuration files, /var/www/docs , /var/www/images, /var/www/css/images and /var/www/js on the system.
    • Now restart apache for the changes to take effect: /etc/init.d/apache2 restart

You may skip the rest of the sections if not doing a completely new build.

Installing to a VMWare ESXi hosting environment

After the initial system image has been created, it should be copied to the VMWare environment before performing further installation steps.

  • Copy the newly created system image to a Windows machine with the VSphere management console software. Rename the image to match the target system name.
  • From the windows machine, run the VSphere management console. Log in to the ESXi host, and start a browser on the VMWare datastore. Upload the image to a working directory (e.g. /images).
  • Create a new virtual machine. Skip creation of the system image, or delete it from the virtual machine directory once the VM has been created. Create a VMXNET and E1000 ethernet controllers. (Later, we hope to delete the E1000 controller.)
  • Move the pre-built image into the virtual machine directory in the VMWare datastore.
  • Add a new disk to the virtual machine, using the virtual machine image.
  • Start the new virtual machine. The system should boot. The E1000 network controller should connect to the network.
  • Start a new console from the VSphere console, and select the "Install VMWare tools" option.
  • Mount the VMWare tools virtual CD from device /dev/scd0 to a suitablke mount point (e.g. /mnt/cdrom).
  • Install and configure VMWare tools.
    • To configure VMWare tools needs a linux-headers package to be installed. The package used should match the running kernel. Use the following command to see details of the running kernel: 
uname -r
or just use the command: 
apt-get install linux-headers-`uname -r`

(More: how to get VMXNET network driver running? Kernel version problems?)

System testing

Prepare the new system for testing (target system)

When running under KVM for testing, ACLs will need to be enabled on the root volume:

  • In /etc/fstab on the target ADMIRAL system, add acl to the mount options for the root filesystem; e.g.
/dev/sda1 / ext3 defaults,acl 0 0
  • Remount the root file system to activate the new option:
mount / -o remount

Create test users (target system)

The test suite is configured to use a number of predefined user accounts. The configuration is in file testConfig.py. Before running the test suite, these accounts must be created on the target system using the script /root/admiraluseradd.sh.

A sample script for adding the test users on the ADMIRAL system is in the test directory in file CreateTestUsers.sh. (Commands like the examples shown should be run as root user from directory /root on the target system.)

After creating the test users, restart the Apache web server on the target ADMIRAL system so that the updated configuration can be used (/etc/init.d/apache2 restart).

We have found that, by default, users are created with passwords that expire too quickly. The extend the time to expiry, us a command like this: 

 smbldap-usermod --shadowMax 99999 <username>

Run test suite (test system)

The testing is performed using a separate system with network access to the target system.

A file access test suite is available at test/FileShare/tests in the source code area.

The test suite must be run on a suitable Linux system. It uses Python 2.6 or later. In Python 2.5, there is a bug in urllib2.py that causes HTTP 201 and 204 errors to be treated as errors, and consequent test failures.

If the test suite is to be run from a non-root account, the utilities mount.cifs and umount.cifsshould be marked with +s access mode (e.g. chmod +s `which mount.cifs`, etc.).

There is also a bug in earlier versions of umount.cifs that fails to update /etc/mtab when the Samba test volumes are dismounted.

Details

Virtual machine building

  • The tool vmbuilder is used to build a virtual machine. The initial hypervisor chosen for testing is kvm, but other options are possible; in particular VMWare will be used for deploying live ADMIRAL data-sharing systems. A script (make-admiral-server.sh) has been created, which contains the options required to build a system which will (as far as possible) work "out of the box".
    • The virtual machine is currently built to run Ubuntu 9.10, but this will change when the next LTS (long term support) release becomes available. It is configured to have 8GB of disk space and 2 GB of swap. (Currently, Ubuntu 10.04 is an LTS release, but the vmbuilder utility has been broken in this release, so we continue to use Ubuntu 9.10.)
    • Modifications to the networking configuration system on which the virtual machine is to be built are detailed in ADMIRAL_LSDS_setup#Virtualization_setup.
    • The --addpkg [pkg] option is used multiple times to pre-install the virtual system with packages that are "safe" (i.e. where there are no security implications in pre-installing them, and where no user interaction is required). Some packages which would appear to be "safe" by these standards also have to be excluded because they cause vmbuilder to crash.
    • Packages which are added in this way (and which do not require detailed discussion in a later section of this document) are acpid, unattended-upgrades, ufw, denyhosts and apache2.
    • The --copy config-files option is used to copy useful configuration files (detailed in the file config-files) which would otherwise need to be edited manually once the system had booted into the appropriate places.
    • The --firstboot boot.sh option is used to request that the script boot.sh should be executed on the first boot of the system. This is used:
      • to install packages (e.g. openssh-server) which require unique keys;
      • to install packages (e.g. libpam-krb5) which cannot be installed using --addpkg;
      • to create required files and directories for various parts of the Kerberisation process;
      • to change permissions on some files and directories;
      • to enable required Apache modules and sites;
      • to generate a self-signed SSL certificate for WebAuth services;
      • to copy into place files that might get overwritten if they were to be installed using the --copy config-files option, as packages will be installed later that may edit these files automatically;
      • to add a default Samba user with password; and finally
      • to restart any services (e.g. Apache) which need to be aware of modifications made during the running of the script.

Basic Kerberos setup

Before Kerberisation of the required services can proceed, it is first necessary to install some basic Kerberos client tools.

  • The times on the host machine and the Kerberos KDC need to be within 5 minutes of each other, which means that it is neceesary to run some form of regular system time synchronisation.
  • The packages krb5-user (for the basic client tools) and ntp (for the time synchronisation) are installed during the virtual machine build (make-admiral-server.sh): 
 [...]
  --addpkg krb5-user \
  --addpkg ntp \
 [...]
  • An /etc/krb5.conf file is created containing the details of the local realm: 
[libdefaults]
        default_realm = OX.AC.UK
[realms]
OX.AC.UK = {
    kdc = kdc0.ox.ac.uk
    kdc = kdc1.ox.ac.uk
    kdc = kdc2.ox.ac.uk
    admin_server = kdc-admin.ox.ac.uk
    default_domain = ox.ac.uk
}
[domain_realm]
    .ox.ac.uk = OX.AC.UK
  • An edited version of /etc/ntp.conf is copied into place. The NTP servers to be used are adjusted from the defaults to local OUCS ones: 
server ntp0.oucs.ox.ac.uk
server ntp1.oucs.ox.ac.uk
server ntp2.oucs.ox.ac.uk
server ntp3.oucs.ox.ac.uk
  • Kerberos principals for each of the services (cifs and host for Samba, webauth for WebAuth and HTTP for WebDAV) must be created, and then stored in appropriate keytab files (theoretically they can all be stored in /etc/krb5.keytab, but is is probably more secure for each service only have access to thos principals it actually needs to be able to authenticate against. To create the keytabs, run kadmin, e.g.: 
root@zakynthos:/home/admiral# kadmin -p zool0925/itss
Authenticating as principal zool0925/itss with password.
Password for zool0925/itss@OX.AC.UK: 
kadmin:  ktadd -k /etc/apache2/webauth/keytab webauth/zakynthos.zoo.ox.ac.uk
Entry for principal webauth/zakynthos.zoo.ox.ac.uk with kvno 11, encryption type AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/apache2/webauth/keytab.
Entry for principal webauth/zakynthos.zoo.ox.ac.uk with kvno 11, encryption type AES-128 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/apache2/webauth/keytab.
Entry for principal webauth/zakynthos.zoo.ox.ac.uk with kvno 11, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/apache2/webauth/keytab.
Entry for principal webauth/zakynthos.zoo.ox.ac.uk with kvno 11, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/apache2/webauth/keytab.
Entry for principal webauth/zakynthos.zoo.ox.ac.uk with kvno 11, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/apache2/webauth/keytab.
kadmin:  quit
  • To check that the requisite principals are present in a given keytab, use ktutil. 
root@zakynthos:/etc# ktutil 
ktutil:  rkt /etc/apache2/webauth/keytab
ktutil:  l
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1   10  webauth/zakynthos.zoo.ox.ac.uk@OX.AC.UK
   2   10  webauth/zakynthos.zoo.ox.ac.uk@OX.AC.UK
   3   10  webauth/zakynthos.zoo.ox.ac.uk@OX.AC.UK
   4   10  webauth/zakynthos.zoo.ox.ac.uk@OX.AC.UK
   5   10  webauth/zakynthos.zoo.ox.ac.uk@OX.AC.UK
ktutil:  quit

Kerberisation of services

ssh/sshd

  • The OpenSSH client supports GSSAPI which is an extensible authentication architecture capable of handling Kerberos negotiation. /etc/ssh/ssh_config needs editing as follows: 
 [...]
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes
 [...]

(the rest of the file can remain as per the Ubuntu default).

  • To enable the OpenSSH server, libpam-krb5 needs to be installed. This is done during the execution of the boot.sh script run the first time the virtual system is booted (it's done here rather than using --addpkg to ensure that each deployment generates a unique SSH public key). /etc/ssh/sshd_config needs editing as follows: 
 [...]
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
 [...]

(the rest of the file can remain as per the Ubuntu default).

  • Note: the files ssh_config and sshd_config are specified to be copied over into /root in config-files, as otherwise they would be overwritten during the installation of openssh-server on first boot. After openssh-server is installed, the files are copied over into /etc/ssh.
  • /etc/pam.d/common-password will have been modified during the installation of libpam-krb5. This will add unwanted options to the file, so the default needs to be restored. A saved copy of common-password is specified to be copied over into /root in config-files, which is then copied into /etc/pam.d/ after libpam-krb5 has been installed by the first boot script.

Samba 

####### Authentication #######

# "security = user" is always a good idea. This will require a Unix account
# in this server for every user accessing the server. See
# /usr/share/doc/samba-doc/htmldocs/Samba3-HOWTO/ServerType.html
# in the samba-doc package for details.
#   security = user
   security = ads
   realm = OX.AC.UK
   kerberos method = dedicated keytab
   dedicated keytab file = /etc/krb5.keytab
   ## use kerberos keytab = yes (seems to be obsolete in Ubuntu 9.10)

# You may wish to use password encryption.  See the section on
# 'encrypt passwords' in the smb.conf(5) manpage before enabling.
   encrypt passwords = true

# If you are using encrypted passwords, Samba will need to know what
# password database type you are using.  
   passdb backend = tdbsam

   obey pam restrictions = yes

and 

# Share /var/files as //admiral/files
[files]
   comment = File server area
   browseable = yes
   read only = no
   path = /var/files
   create mask = 0775
   directory mask = 0775
   valid users = admiral, zool0635, zool0925
  • The directory /var/files is created by the first boot script, and chmoded u+rw,g+rws.
  • The smbpasswd is run on first boot to create a default user (admiral) with a password. This will need to be dealt with more securely for the production version.

Linux

sudo mount.cifs //zakynthos.zoo.ox.ac.uk/files /mnt/admiral -o user=test_admiral,nounix,uid=1000,gid=www-data mounts the files area using the test_admiral user's credentials on the server, as /mnt/admiral on the local machine with the local user's uid (1000 in this case), and a gid of www-data. The nounix option is required to turn off the CIFS Unix extensions which transfer through the remote user's uid and gid -- which may not exist on the local system, thus meaning that files cannot be written to!

MacOS Client

(This test performed with MacOS Leopard 10.5.8)

Initially, attempt to connect using Kerberos credentials fail, indicating an NT login failure.

But, with the Kerberos realm configured on the MacOS client, the connection succeeds. Configuring the Kerberos details is a little bit of a fiddle - it doesn't seem to be doable using the normal GUI interfaces (or did I overlook one?). Instead, a new file /Library/Preferences/edu.mit.Kerberos needs to be created with the following content: 

[libdefaults]
        default_realm = OX.AC.UK
[realms]
OX.AC.UK = {
    kdc = kdc0.ox.ac.uk
    kdc = kdc1.ox.ac.uk
    kdc = kdc2.ox.ac.uk
    admin_server = kdc-admin.ox.ac.uk
    default_domain = ox.ac.uk
}
[domain_realm]
    .ox.ac.uk = OX.AC.UK

Then use: finder > go > connect to server > "smb://zakynthos/files".

Having previously logged in to a Kerberized SSO service, the login details have been saved in my MacOS keychain. A dialog box from "NetAuthAgent" asks if confidential information stored at "OX.AC.UK" in the keychain may be used: select "Allow". A new file system connection is created.

Well, that worked first time: on a second attempt, it asked for new username and password, then failed.

Investigations continue...

WebAuth

  • The first boot script runs a2enmod on the modules webauth and ssl in order to create symlinks from /etc/apache2/mods-available/ to /etc/apache2/mods-enabled/ (i.e. enabling the modules). It also runs a2ensite to create a symlink from /etc/apache2/sites-available/default-ssl to /etc/apache2/sites-enabled/sites-enabled (i.e. enabling the SSL-protected site), and creates a symlink from /var/lib/webauth to /etc/apache2/webauth, where required files are to be stored.
  • The keytab which was extracted from the key list for the webauth service is copied into place, chowned to root:www-data and chmoded 640.
  • A directory is created to store files to be accessible through the webauth/SSO mechanism, and chowned to the www-data user.
  • An SSL certificate is generated for the service using the make-apache2-cert.sh script. This also self-signs the certificate; for the deployed version of the environment the certificate will need to be signed by a proper certification authority.
  • A replacement version of the default SSL-enabled site configuration is copied into place as /etc/apache2/sites-available/default-ssl; the changed portion of this file reflects the location of the self-signed certificate: 
        SSLCertificateFile    /etc/ssl/certs/zakynthos.zoo.ox.ac.uk.pem
        SSLCertificateKeyFile /etc/ssl/private/zakynthos.zoo.ox.ac.uk.key

WebDAV

  • The packages libapache2-mod-auth-kerb and cadaver (for command-line access to WebDAV shares) are installed during the virtual machine build using --addpkg.
  • The first boot script runs a2enmod on the modules dav, dav_fs and auth_kerb in order to create symlinks from /etc/apache2/mods-available/ to /etc/apache2/mods-enabled/ (i.e. enabling the modules). A directory is created to store the WebDAV lock file in, this file is created, and the directory chowned to the www-data user.
  • A storage directory for files to be accessible using WebDAV is created and chowned www-data:root. The original default non-SSL-enabled web configuration is backed up, and a modified one suitable for use with a Kerberised WebDAV instantiation is copied into place as /etc/apache2/sites-available/default.
  • The relevant part of this file is as follows: 
        <Location /webdav>
                Dav On
                AuthName "Kerberised WebDAV"
                AuthType Kerberos
                KrbAuthRealms OX.AC.UK
                KrbServiceName HTTP
                KrbMethodNegotiate on
                KrbMethodK5Passwd on
                Krb5Keytab /etc/apache2/webdav.keytab
                Require valid-user
       </Location>
  • The keytab which was extracted from the key list for the HTTP service is copied into place, chowned to root:www-data and chmoded 640.

LDAP-based authorization

NOTE: This section is work in progress

TODO: tidy up these notes

Install LDAP

The packages slapd and ldap-utils are installed using the --addpkg option in the initial installation script.

LDAP support in Ubuntu 9.10 appears to be in a transient position; they are migrating from one way or doing things to another (possibly Kerberised) way, but the support for this is not all there yet. Consequently the LDAP server needs some initial configuration that was not necessary with previous versions of Ubuntu. In particular, various schemas need importing that would previously have happened as part of the installation process, and various configuration parameters need setting.

See:

These steps perform a basic LDAP server installation. Much of the detail here is specific to Ubuntu 9.10; see above links for more detail. 

apt-get install slapd ldap-utils
ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/cosine.ldif
ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/inetorgperson.ldif
ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/nis.ldif
# Create file db.ldif: see below for content
ldapadd -Y EXTERNAL -H ldapi:/// -f db.ldif
# Select LDAP root password
slappasswd -h {MD5}
# Create file base.ldif, with content shown below, but substituting output from above command for password hash
ldapadd -Y EXTERNAL -H ldapi:/// -f base.ldif
# Create file config.ldif, with content shown below
ldapadd -Y EXTERNAL -H ldapi:/// -f config.ldif
# Create file acl.ldif, with content shown below.
# This step requires re-entry of the password specified previously.
ldapmodify -x -D cn=admin,cn=config -W -f acl.ldif

According to http://www.howtoforge.com/install-and-configure-openldap-on-ubuntu-karmic-koala, "You should now have an openldap directory as it was shipped with Jaunty Jackalope", which also seems to be what is expected by the page at https://help.ubuntu.com/9.10/serverguide/C/samba-ldap.html.

To reset the LDAP database and start over, use: 

dpkg-reconfigure slapd

and, in response to the question "Omit OpenLDAP server configuration?", answer "No".

File: db.ldif 

# Copied from http://www.howtoforge.com/install-and-configure-openldap-on-ubuntu-karmic-koala

# Load dynamic backend modules
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module
olcModulepath: /usr/lib/ldap
olcModuleload: {0}back_hdb

# Create the database
dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=zakynthos,dc=zoo,dc=ox,dc=ac,dc=uk
olcRootDN: cn=admin,dc=zakynthos,dc=zoo,dc=ox,dc=ac,dc=uk
olcRootPW: example
olcDbConfig: {0}set_cachesize 0 2097152 0
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcLastMod: TRUE
olcDbCheckpoint: 512 30
olcDbIndex: uid pres,eq
olcDbIndex: cn,sn,mail pres,eq,approx,sub
olcDbIndex: objectClass eq

File: base.ldif

Edit this to contain the required password hash: 

dn: dc=zakynthos,dc=zoo,dc=ox,dc=ac,dc=uk
objectClass: dcObject
objectclass: organization
o: zakynthos.zoo.ox.ac.uk
dc: zakynthos
description: My LDAP Root

dn: cn=admin,dc=zakynthos,dc=zoo,dc=ox,dc=ac,dc=uk
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
userPassword: {MD5}Gnmk1g3mcY6OWzJuM4rlMw== <<< replace with required password hash
description: LDAP administrator

File: config.ldif

Edit this to match password hash entered previously: 

dn: cn=config
changetype: modify
delete: olcAuthzRegexp

dn: olcDatabase={-1}frontend,cn=config
changetype: modify
delete: olcAccess

dn: olcDatabase={0}config,cn=config
changetype: modify
delete: olcRootDN

dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcRootDN
olcRootDN: cn=admin,cn=config

dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcRootPW
olcRootPW: {MD5}vCxDg0JY2ieKRYCG0n417w== <<< Change this to password hash

dn: olcDatabase={0}config,cn=config
changetype: modify
delete: olcAccess

File: acl.ldif 

dn: olcDatabase={1}hdb,cn=config
add: olcAccess
olcAccess: to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=zakynthos,dc=zoo,dc=ox,dc=ac,dc=uk" write by anonymous auth by self write by * none
olcAccess: to dn.base="" by * read
olcAccess: to * by dn="cn=admin,dc=zakynthos,dc=zoo,dc=ox,dc=ac,dc=uk" write by * read

Check LDAP basic operation

To check if basic LDAP is responding to requests, enter the command: 

ldapsearch -xLLL -b cn=config -D cn=admin,cn=config -W olcDatabase={1}hdb

enter the password configured previously when prompted, and expect to see something like this 

Enter LDAP Password: 
dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=zakynthos,dc=zoo,dc=ox,dc=ac,dc=uk
olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=zakynthos,dc=zoo,dc=ox,dc=ac,dc=uk" write by anonymous auth by self write by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by dn="cn=admin,dc=zakynthos,dc=zoo,dc=ox,dc=ac,dc=uk" write by * read
olcLastMod: TRUE
olcRootDN: cn=admin,dc=zakynthos,dc=zoo,dc=ox,dc=ac,dc=uk
olcRootPW: example
olcDbCheckpoint: 512 30
olcDbConfig: {0}set_cachesize 0 2097152 0
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbIndex: uid pres,eq
olcDbIndex: cn,sn,mail pres,eq,approx,sub
olcDbIndex: objectClass eq

Configure for authentication

See:

LDAP seems to not like working with self-signed certificates, so the openssl operations used for (say) creating a self-signed certificate for use with Apache don't work for LDAP. Instead, we need to create a self-signed root/CA certificate, and use that to sign the generated host certificate.

To create the CA certificate, see https://help.ubuntu.com/9.10/serverguide/C/certificates-and-security.html#certificate-authority. This procedure is captured in the makeCA.sh script.

To create the host key and certificate for LDAP, use the script makeCertKey.sh, or use an equivalent sequence of commands.

Finally, the signed certificate and private key must be copied to the appropriate working locations (see copyCert.sh): 

sudo mv zakynthos.key /etc/ssl/private/
sudo chgrp ssl-cert   /etc/ssl/private/zakynthos.key
sudo chmod g=r,o=    /etc/ssl/private/zakynthos.key
sudo mv zakynthos.pem /etc/ssl/certs/

Configure LDAP to use server certificate

Create certs.ldif (matching the files created above): 

dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/zakynthos.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/zakynthos.key

Then add this to the LDAP configuration: 

ldapmodify -x -D cn=admin,cn=config -W -f certs.ldif

File /etc/default/slapd is expected to look like this (not sure which bits matter fill this in wwhen working with TLS): 

@@TODO ....

Add user openldap to group ssl-cert, and restart LDAP server: 

adduser openldap ssl-cert
/etc/init.d/slapd restart

Configure LDAP for Samba

  • The packages samba-doc and smbldap-tools are installed using the --addpkg in the initial virtual machine building script.
  • The Samba attributes are defined in the /usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz file which is part of the samba-doc package. This file is unzipped and copied to /etc/ldap/schema. The schema then needs to be added into the cn=config tree. A file schema_convert.conf is created containing the following: 
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/collective.schema
include /etc/ldap/schema/corba.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/duaconf.schema
include /etc/ldap/schema/dyngroup.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/java.schema
include /etc/ldap/schema/misc.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/openldap.schema
include /etc/ldap/schema/ppolicy.schema
include /etc/ldap/schema/samba.schema
  • A temporary directory e.g. /tmp/ldif_output is created to contain the output. The schema is then converted using the following command: 
slapcat -f schema_convert.conf -F /tmp/ldif_output -n0 -s "cn={12}samba,cn=schema,cn=config" > /tmp/cn=samba.ldif
  • NB: the schemas are numbered from 0 upwards. Change the "12" if this should be necessary in your setup.
  • Edit the /tmp/cn\=samba.ldif so that the dn and cn attributes read as follows: 
dn: cn=samba,cn=schema,cn=config
...
cn: samba

and remove the lines similar to the following from the end of the file: 

structuralObjectClass: olcSchemaConfig
entryUUID: b53b75ca-083f-102d-9fff-2f64fd123c95
creatorsName: cn=config
createTimestamp: 20080827045234Z
entryCSN: 20080827045234.341425Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20080827045234Z
  • Add this schema using the following command: 
ldapadd -x -D cn=admin,cn=config -W -f /tmp/cn\=samba.ldif
  • Now we create a file samba_indexes.ldif containing the following: 
dn: olcDatabase={1}hdb,cn=config
changetype: modify
delete: olcDbIndex
olcDbIndex: uid pres,eq
-
add: olcDbIndex
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: loginShell eq
olcDbIndex: uid eq,pres,sub
olcDbIndex: memberUid eq,pres,sub
olcDbIndex: uniqueMember eq,pres
olcDbIndex: sambaSID eq
olcDbIndex: sambaPrimaryGroupSID eq
olcDbIndex: sambaGroupType eq
olcDbIndex: sambaSIDList eq
olcDbIndex: sambaDomainName eq
olcDbIndex: default sub

NB It is necessary to run the delete: olcDbIndex command on the uid attribute as this was previously added with different options.

The indexes are now loaded: 

./ldapconfigmodify.sh samba_indexes.ldif
  • The next step is to configure the smbldap-tools package. Unzip and run the file /usr/share/doc/smbldap-tools/configure.pl.gz, answering the questions with suitable answers for the environment.

NB The version shipped with Ubuntu 9.10 seems to be slightly buggy, particularly with regard to the master and slave servers. Check /etc/smbldap-tools/smbldap_bind.conf to check that all is well after finishing running this configuration script.

  • Before adding the users, groups and LDAP objects, it is sensible to back up the current configuration: 
slapcat -l backup.ldif
  • Then add the users, groups and LDAP objects (you can save the output of this command to an LDIF file to ensure it looks sane before actually running it by using the -e samba.ldif option to smbldap-populate: 
smbldap-populate
  • To configure Samba to use LDAP, edit the main Samba configuration file /etc/samba/smb.conf as follows: 
#   passdb backend = tdbsam

# LDAP Settings
   passdb backend = ldapsam:ldap://hostname
   ldap suffix = dc=example,dc=com
   ldap user suffix = ou=People
   ldap group suffix = ou=Groups
   ldap machine suffix = ou=Computers
   ldap idmap suffix = ou=Idmap
   ldap admin dn = cn=admin,dc=example,dc=com
#   ldap ssl = start tls
   ldap passwd sync = yes
...
   add machine script = sudo /usr/sbin/smbldap-useradd -t 0 -w "%u"

NB The ldap ssl = start tls line is commented out for the time being as it leads to problems. This may be fixable with more time and effort than is currently available. For a similar reason /etc/smbldap-tools/smbldap.conf should be edited to contain the line ldapTLS="0" (the default is ldapTLS="1").

  • After restarting samba, the LDAP admin password is set using: 
sudo smbpasswd -w [password]
  • Current LDAP users wishing to use Samba will need some Samba attributes defined by samba.schema. These can be added using smbpasswd: 
smbpasswd -a [username]

Nagios installation

  • Run apt-get install nagios3 nagios-nrpe-plugin nagios-nrpe-server on new server to be monitored.
  • Postfix needs configuring appropriately.
  • Provide an admin password for the nagios user.
  • Edit /etc/nagios/nrpe.cfg to allow monitoring connexions from zoo-patmos (129.67.24.35).
  • /etc/init.d/nagios-nrpe-server restart (on the server to be monitored)
  • On zoo-patmos, copy /etc/nagios3/conf.d/host-zakynthos_nagios3.cfg to similar file for the new machine, and edit the values to reflect the name and IP address of the new server to be monitored.
  • Edit /etc/nagios3/conf.d/hostgroups_nagios2.cfg to include the new server where appropriate.
  • /etc/init.d/nagios3 restart on zoo-patmos

Relevant files

Shell scripts

make-admiral-server.sh

boot.sh

make-apache2-cert.sh

Other files referenced by make-admiral-server.sh 

[file on build system] [destination file on virtual system]

config-files

admiral.partitions

Configuration files

/etc/krb5.conf

/etc/ntp.conf

/etc/ssh/ssh_config

/etc/ssh/sshd_config

/etc/pam.d/common-password

/etc/samba/smb.conf

/etc/apache2/conf.d/webauth.conf

/etc/apache2/sites-available/default-ssl

/etc/apache2/sites-available/default


Things that currently do not work

  1. The SSL certificate is self-signed, which causes security-conscious web browsers to complain. This is tiresome rather than problematic, and will in any case be fixed in the production version by getting the certificate signed officially (OUCS can help with this).
  2. HTTP access to common areas (e.g. /data/shared is denied to all users. Attempts to enable access here cause other access controls to fail. We're not sure why, but it seems to be some subtlety of the HTTP access controls.
  3. The Samba share cannot be mounted using SSO credentials under Windows (tested on XP, but probably other versions as well), but can be mounted using the password in the Samba/LDAP password database. It also cannot be mounted using SSO credentials under MacOS X.
  4. The WebDAV file area cannot be accessed under Windows XP using SSO credentials. It has been partially mounted once using SSO credentials under MacOS X, but caused the Mac to require rebooting. There was also evidence of problems with the mod_auth_kerb module in the /var/log/apache2/error.log: Apache segfaulted.
Retrieved from "http://imageweb.zoo.ox.ac.uk/wiki/index.php/Zakynthos_Configuration"
Oxford DMP online
MIIDI
Claros