|
Members:
Vlado Bahyl, Benjamin Marco Chardi, Jan van Eldik,
Uli Fuchs, Thorsten Kleinwort, Martin Murth, Tim Smith
LXDEV Cluster usage
LXSERV Cluster software
setup page
The new CVS Repository:
Minutes of the FIO-LXDev Meetings: here.
Documentation:
Work in Progress:
Goals:
| Long term |
To operate the computer centre using integrated
installation, configuration and monitoring tools |
| Medium term |
To prototype the EDG WP4 integrated tools
set on production farms |
| Short term |
To prepare the production systems for this
change of toolset by:
- Identifying (and isolate) the additional functionality
required to transform a "CERN standard server installation"
into interactive or batch server
- Cleanly separate the functionality of base installation,
feature installation and system configuration
- Reduce the diversity of tools currently employed
by rewriting to use respectively kickstart, RPM
and SUE for these functions uniquely
- Collect all the configuration information from the
current remote flat files and DBs into a local config
cache file, ready for transformation to use a proper
configuration management and delivery system
- Using a standards based approach for coding
- Collect back together the customisation code which
is currently scattered across the filesystem into
standard locations
- Transforming all features into "run every night"
instead of just half of them
|
Short Term Action Plan:
The move of the LXPLUS/LXBATCH services to RedHat7.2 is taken as
a good opportunity to implement these changes. So basing on
the work of the ADC certification team, we have analysed the current
LXPLUS RedHat6.1 installation which uses a complex
kickstart file, 51 SUE features,
and 28 BIS features to extract
their essence and to rewrite them as clean SUE features. During
this the aims will be
- To separate all configuration information out of the features
into a local config cache file
- To code against some clean standards as far as possible as defined
in the Linux Standards Base
project
- Summary of required functionality of code to go on a production
server:
- Installation of software using RPM
- Configuration of software by SUE
- Services started using init.d scritps which
- support all the standard functions like start / stop
/ restart as defined in (2)
- Check whether requirements are met before starting the
service
- Daemons log messages using syslog and/or to /var/log
- Daemons to store pids in /var/run/pid file
- /etc/logrotate.d entries added for any log files created
as defined in (2)
- /etc/cron.d entries added for any crontabs required as defined
in (2)
- All configuration information stored externally from the
code
- in a single config cache file
- accessed using a standard API
- Install everywhere, select with chkconfig
- Independence from AFS
- No reliance on insecure protocols like rsh or .rhosts for
root
- Use a CVS repository for code to be released
- Documentation to be generated alongside the code!
|
