Automatic update scenario for Linux machines at DESY Zeuthen

1
Automatic update scenario for Linux machines at
DESY Zeuthen

• Peter Jung
• DESY Zeuthen

2
Contents

• Goals
• building the RPM repository on server
• accessing the repository from clients
• rpm update and postinstallation
• rpm update levels
• future plans

3
Goals

• Have a local up to date repository of a given
  Linux release
• presently done for SuSE distribution
• should work with minor mod's for other rpm based
  distributions
• Have a mechanism to enforce software updates
• mainly intended for security fixes
• should be adaptable to different needs (server,
  desktop machines)
• Should simplify the handling of rpm packages
• update, remove, install, query, browse
• enhanced functionality as compared to autorpm

4
building the RPM repository on an NFS server

• exporting the whole rpmcollection includingnew
  updates, non-SuSE packages, outdated updates etc.
  for differentdistributions
• Create an index for lookups, package queries like
  keyword/file/phrase- searching

ftp.SuSE.com
NFS Export
daily update mirror
i386
RPM-Repository
src
original distribution
noarch
non SuSE
lookup index
5
accessing the repository from clients (rpmupdate)
rules ? update package to most recent
version? update package to a specific version?
install / remove packages depending on the
version and the Linux release? ...
local databasepackages.rpm
action

• comparing the current installation to the
  repository and prepare actionsgiven by simple
  rule sets (typically done in a cron job)
• simplifies the interactive package management as
  well, allows package browsing like

do we have an update for this ? which package
provides the file lt...gt - is it installed already
- and is it up to date ? - Can I first
look into the file ? what we have on LDAP in
the repository ?
6
rpmupdate and postinstallation

• problem after an update the site specific
  configuration may have been overwritten
• the postinstallation process (SUE/cfengine) fixes
  that rpmupdate needs to run immediately BEFORE
• better solution found integration in the concept
  of SUE/cfengine (rpm-feature)

first installation
rpmupdate
24h
SUE/cfengine
7
rpm update levels

• categorizing the packages (software groups)
• normal applications - update on a running system
  (24h-cycle)
• critical applications that are installed only at
  a reboot
• more
• ? specifying tags for each package (make groups)

8
Future work

• (a) using package time stamps like install only
  packages older than 1 month
• (b) introducing time delays per package like
  ltknfsdgt should be at least 2 weeks out. if not
  continue with the release before.
• point (a) could be host-specific
  (test-/productions environments), (b) allows
  individual time offsets (critical packages)
• (c) additional predefined tags (classes) like
  netgroups / hosts / shell variables