DICE SL5 Server Upgrade


1. Overview

The DICE SL5 Services project is coordinating the transition to SL5/SL5_64 of all DICE servers and services currently running on FC5 and FC6.

Other than this webpage, currently-available documentation for this project is as follows:

  1. Project homepage on the devproj system
  2. Project plan
  3. Bugzilla tree and current status of servers and services to be ported
  4. Current status of OS versions running on Informatics servers
  5. Machines still running FC5
  6. Progress reports (all for the week ending the indicated date):

    2008 2009
    Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun
    8 7 4 2 6 4 [c] 1 5 3 7 5 9 6 [b] 6 3 1 5
    15 14 11 9 13 11 8 12 10 14 12 16 13 13 10 [a] 8 12 [b]
    22 21 [a] 18 16 20 [c] 18 15 19 [b] 17 21 [b] 19 23 20 20 17 [b] 15
    29 28 25 23 [b] 27 [c] 25 22 26 [b] 24 28 26 [b] 30 27 27 24 22



    [a] Easter holiday; no report
    [b] Holiday; no report
    [c] Move to Forum; no report
    Note: from June 12 2009, these weekly reports have been discontinued, at the request of CEG.

2. DICE-level SL5 - general 'how-to?' information

The following collection of notes is intended to contain information of general use, and to explain any 'standards' which we want to adhere to in the course of the SL5 port.

2.1 Package organisation / rpmsubmit buckets

The overall intention is that the organisation of our DICE-level SL5 packages should mirror that of our earlier FC(n) set-ups. So, we intend to use 'lcfg', 'ed', 'dice', 'extras' etc. buckets for RPM submission and organisation, all as before.

To which bucket should any particular package be submitted? The least disruptive approach is simply to decide this on functional and historical grounds. Anything previously in 'ed' should still live in 'ed'; and so on. If there is any uncertainty, ask!

The above has been overtaken by events: all packages should now be submitted to whichever of the new buckets 'world', 'uoe', or 'inf' is appropriate. The expectation is that the majority of our packages - being freely distributable - will be submitted to 'world'.

The 'extras' repositories are maintained by Stephen Quinney and are mirrors of the EPEL 'Extra Packages for Enterprise Linux' repositories for SL5 i386 and x86_64. As for all previous distributions, Source RPMs are not maintained locally for anything in 'extras'.

2.2 Sources of packages

Official package repository

The official download site for SL5 is https://www.scientificlinux.org/download: this points to the official repository for SL5 RPMs at http://ftp.scientificlinux.org/linux/scientific/.

The repository is mirrored at: http://www.mirrorservice.org/sites/ftp.scientificlinux.org/linux/scientific/

You can get the Redhat Enterprise Source RPMs from http://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/

Other packages

[Information from Stephen Quinney]

If a suitable source package is not directly available locally, there are a number of external repositories that can be used. For RHEL and SL5, the first port of call should be EPEL - http://fedoraproject.org/wiki/EPEL. (And also see http://download.fedora.redhat.com/pub/epel/ - RPM's in their 'testing' phase can be obtained from here.) If that fails then try any of:

(Be aware that these repositories often provide their own versions of the same packages but with different dependencies. Mixing them on the same box can lead to all sorts of conflicts even after rebuilding from SRPM.)

Typically, if there are no specific RHEL5 or SL5 packages available, then the SRPM from a comparable Fedora release (for SL5, the comparable Fedora release should be FC6) can be used, possibly with a bit of coercion.

For Perl modules, it is normally better to use the cpan2rpm tool rather than grabbing packages from elsewhere. That way you get the latest version and you know it is built to a consistent standard. It will pull the package from CPAN, for example:

  cpan2rpm --no-sign File::Tail

Turn off gpg package signing, as above. You might also need to specify the package author (--author=...) or version (--version=...) if the tool fails correctly to parse the CPAN module metadata.

Comment: Simon Wilkinson suggests that "if you're packaging Perl modules, could you consider using cpanspec, rather than cpan2rpm. cpanspec generates packages which more closely follow the Fedora Packaging guidelines."

2.3 Package building

SL5 (S)RPMs obtained from the EPEL repository will be tagged with an .el5. string. (For example: perl-Test-Pod-1.26-1.el5.noarch.rpm and perl-Test-Pod-1.26-1.el5.src.rpm.)

It seems useful to retain this string as a standard annotation to any such package submitted to our repositories, but to do so requires an extra define at (re)build time, as follows:


  rpmbuild --rebuild --define 'dist.el5' <source RPM>


  rpm -i <source RPM>
  rpmbuild -ba --define 'dist.el5' <specfile>

Comment: The above has probably been overtaken by events. With the move to University packaging standards (see ???), we should probably now be adding a release string like 1.inf instead.

2.4 Development machines

Build hosts

The following DICE-level machines are available for building SL5 software:

  • buildsl5.inf.ed.ac.uk (a.k.a. tarragona) - for 32-bit SL5 (i386 etc.)
  • buildsl5_64.inf.ed.ac.uk (a.k.a. dubrovnik) - 64-bit SL5 (x86_64)

These machines should only be used for building software, and doing simple tests which won't impact on other users. More extensive and/or intrusive testing should be done on your own DICE SL5 'test' machine(s).

The build hosts follow the 'stable' release, and not the 'develop' release. Should you - in the course of building software - need to install prerequisite packages on the build hosts, the approved method is to use the live/buildhost.h header. Please install any such packages by using that header rather than, say, adding packages manually, or placing them in the machine's source profile.

Test hosts

CO's are generally expected to set up their test machines for the purpose of testing SL5 software and services. For the 32-bit SL5 platform, spare GX270's should be available from the Support Office(s).

The 64-bit platform presents more of a problem since we don't have a spare pool of suitable machines. Ad-hoc arrangements will be made as necessary: contact me if you need this facility and can't provide it yourself from machines which are owned by your Unit.

Installing DICE SL5

Installation of a DICE SL5 machine should work in the same way as it does for other OS'es. Generally, take an existing FC5 (or FC6) LCFG profile, replace <dice/os/fc5> with <dice/os/sl5.h>, and reinstall.

An example of a basic SL5 LCFG profile (from the machine buckhaven) is as follows:

  #include <dice/os/sl5.h> 
  #include <dice/hw/dell_optiplex_gx270.h>
  #include <dice/options/server.h>
  #include <live/wire_k.h>

  dhclient.mac            00:0D:56:BE:35:4A 
  !profile.release        mSET(develop)

  /* Inventory information */

Use either sl5.h or sl5_64.h for the OS header, as appropriate.

Upgrading from Inf-level SL5 to DICE-level SL5

The safest way to initialize a DICE-level SL5 machine is to do a completely fresh install. However, should you want to, it should be also possible to effect the inf-level -> DICE-level change by an upgrade. Experiences on this seem to have differed depending on the state of the underlying software when the change was tried - but the following 'worked for me':

  1. Open a root window on the target machine.
  2. rfe lcfg/<machine>; change inf/os/sl5.h to dice/os/sl5.h; allow the change to compile and propagate.
  3. In the root window:
    • om dns restart
    • om updaterpms run
    • om openldap start
    • reboot

2.5 Apache on SL5

Since Linux distributions in use here from (at least) FC3 onwards have not shipped with RPM's for Apache v1.3, we have, up until now, built and supported our own dice-apache-1.3 RPM for these platforms, as well as RPM's for related modules (php etc.) We are not planning to continue this for SL5 or FC6.

This means that any Apache 1.3 based web service will need to be migrated to Apache 2.2 in the course of the SL5 upgrade. See Apache on SL5 (FC6) for further information.

2.6 Upgrading a host which uses Fiber Channel

See: https://wiki.lcfg.org/bin/view/LCFG/FibreAttach

2.7 Known issues with DICE SL5

(Please record any such here)

3. Other SL5/LCFG documentation

4. Related projects

4.1 LCFG SL5 port (inf level)

The LCFG SL5 port (inf level) project ported LCFG to the lcfg and inf levels.

4.2 DICE SL5 Server Platform

The DICE SL5 Server Platform project coordinated the production of DICE level version of SL5, for both i386 and x86_64 cpu architectures, in order to provide a platform on which any DICE service could be installed and run. That project is now largely complete; the documentation for it is as follows:

  1. Project homepage on the devproj system
  2. Project plan
  3. Bugzilla tree and current status of software and services to be ported

-- ChrisCooke / IanDurkacz - 24 Oct 2007

Topic revision: r65 - 26 Jun 2009 - 08:45:01 - IanDurkacz
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies