You are here

Home

Enhancing the Solaris LCFG Platform

Fri, 01/25/2013 - 15:45 - boss
Project ID: 
9
Current stage: 
5_Completed
Manager: 
cc
Unit: 
mp-unit
What: 

Description: The core LCFG platform is incomplete on Solaris and would benefit from being enhanced in a number of ways. Reliability and manageability would improve were various aspects of machine configuration and management further automated. These areas need tackling:

  • Solaris machines need to move to using Subversion-based header and package list files. DICE Linux machines largely made this transition with the move to FC3.
  • The files and scripts on the Solaris install servers need to be versioned. (They are already backed up.)
  • The install server support needs to be built/configured automatically, as much as possible through LCFG, rather than installed and maintained manually.
  • Patching needs to be done more efficiently, particularly since patching has to be done in single-user mode: Sun's per-patch scripts are too slow and stupid for us to rely on them alone.
  • Sort out package installation: we have automated package management with updatepkgs and lcfg-updaterpms, but it needs to be more sophisticated. One addition that's certainly required is the ability to specify packages to be installed at boot time only. Other modifications may also be needed but have not yet been identified.
  • Package building and submission needs to be made straightforward. This needs further investigation.
  • Various configuration files (for Kerberos, PAM, etc.) are currently fixed at install time, where ongoing automatic LCFG-driven configuration would provide far greater flexibility.

Deliverables:

  • Completion of the automation of the OS installation procedure.
  • LCFG-configured install servers for Solaris installs.
  • LCFG-controlled user authorisation.
  • LCFG-driven disk partitioning and filesystem configuration.
  • Efficient LCFG-configured patch management.
  • Efficient LCFG-configured package management.
  • Automated LCFG-driven networking configuration.
  • Straightforward package-building and submission procedures.
  • Solaris use of the Subversion-based header and package list files, and the elimination of the old non-Subversion equivalents.
Why: 

Customer:

  • Computing staff, primarily in the Services Unit.
  • Informatics research teams.
  • The project's deliverables look likely to be used by EPCC and related units.

Craig Strachan of the Services Unit will review the project.

Case statement: The Solaris LCFG platform is incomplete: installs need to be hand-configured on one or more servers; the install servers themselves also need to be hand-configured; patching is slow and inefficient; package management facilities are not yet complete enough to be safely usable on our servers; and several other core aspects of Solaris systems are not yet configurable and maintainable with LCFG.

As with DICE, more automatic LCFG-based configuration should increase the reliability and security of the systems, make them more resistant to human or physical disaster, and reduce time spent setting them up and fixing problems. Completing the Solaris core LCFG platform will make Solaris LCFG more usable and more efficient to manage.

When: 

Status: The expected increased demand for LCFG-managed Solaris has not made itself evident. LCFG community interest has shifted decisively towards Linux and MacOS. Research interest in LCFG-managed Solaris machines is not evident either. Additionally, it seems likely that given the move from NFS to AFS we will ourselves abandon Solaris as our fileserver OS and switch to Linux.
Also, other OSes are now being viewed as important targets for LCFG.

Given all this, improved Solaris LCFG support no longer seems like a high priority, so we propose to abandon most of the former aims of this project. The remaining aim is the most urgent one, the speeding up of Solaris patching, which at the moment is prohibitively slow.

Timescales: The more urgent aspects should be finished by the end of summer 2007, with the other aspects finished by the next summer.

Priority: High priority, particularly the more urgent parts.

Time:

  • Moving to Subversion-based header and package lists: 4 weeks
  • Completing the automation of the OS installation procedure: 2 weeks
  • LCFG-configure the Solaris install servers: 2 weeks
  • More efficient and LCFG-based patch management: 2 weeks
  • Smooth the package-building process: 2 weeks
  • Add boot-only option to package management: 2 weeks



Total for the more urgent aspects: roughly 10 weeks.


The less urgent work is more open-ended as it consists in part of investigation of what more needs to be done, but no part of it should be more than about two week's work.

How: 

Proposal:

Resources: It would be helpful to have a machine or two to act as Solaris install servers as well as a machine or two to be test clients for them. The machines need to be Suns capable of running Solaris 9. This unfortunately rules out the purchase of new ones, so second-hand machines will be needed. We seem to have plenty of old Suns; they may well suffice.

Plan:

The More Urgent Aspects

  1. Moving the Suns to using Subversion-based header and package list files, rather than the pre-Subversion ones. This is holding up other work.
  2. Completion of the automation of the OS installation procedure:
    1. Make the jumpstart install files using an LCFG component (possibly the file component) and a spanning map, rather than hand-editing them.
  3. LCFG-configured install servers for Solaris installs:
    1. Analyse & list how to turn a Sun into an install server.
    2. Set the file component and the package installation facilities to work on automating this configuration work.
  4. Efficient LCFG-configured patch management:
    1. Investigate the internals of Sun patch scripts and devise ways to replace the scripts with a more efficient mechanism, probably done by an LCFG patch component. The solution needs not only to keep track of which patches should be installed, updaterpms style, but also to be capable of automatically unpacking Sun patch packages and installing their patches. Sun patch reporter may be of some help here.
    2. Implement.
  5. Straightforward package-building and submission:
    1. Analyse package-building hassles and obstacles.
    2. Eliminate each one.
  6. Efficient LCFG-configured package management:
    1. Add to updatepkgs the ability to specify packages to be installed at boot time only.



Still Worthwhile But Less Urgent

  1. LCFG-controlled user authorisation:
    1. At present giving someone permission to login to one of our Suns requires hand-editing of files. It should instead be an automatic process driven from LCFG. This involves at least the porting of lcfg-auth to Solaris. (Questions: Which bits of the DICE authentication system are DICE (and thus irrelevant to this project) and which are general LCFG? How much of the latter is there already? Do we just need lcfg-auth?)
  2. LCFG-driven disk partitioning and filesystem configuration:
    1. Study fstab/vfstab differences and Solaris configuration software. (What configures vfstab, the start.lcfg script? Look into this further.)
    2. Work out how to adapt fstab component for Solaris (as vfstab component?).
    3. Implement.
  3. Automated LCFG-driven networking configuration:
    1. Study how the existing Solaris configuration software configures networking.
    2. Work out how to interface this system with LCFG resources. (Do we drive this system using Solaris tools with complementary lightweight LCFG software or do we replace Solaris tools with more comprehensive LCFG components?)
    3. Adapt the network component or implement a Solaris equivalent. (What other components are involved in DICE network configuration?)
  4. Efficient LCFG-configured package management:
    1. Look for any other necessary enhancements (besides boot-time-only installation, covered above).
  1. Investigate the possible use of Patch Check Advanced
  2. If suitable, revisit plan with more details of proposed solution

The project will be reviewed by the Services Unit.

Other: 

Dependencies:

Risks:

Milestones

Proposed date Achieved date Name Description
2006-09-01 2006-09-07 1.1 Get a Sun working with Subversion-based headers supplemented by a monolithic Solaris override header.
2006-10-01 2006-10-07 1.2 Branch the Subversion headers to a Solaris branch
2006-11-04 2006-11-04 1.3 Move resources from the monolithic Solaris override header to the normal headers in the branch, making them suitable for use by both Linux and Solaris hosts.
2006-11-07 2006-11-07 1.4 Test the branch configuration using a Solaris host.
2007-01-31 2007-01-31 1.5 Re-port old Solaris resources to Subversion
2007-01-31 2007-01-31 1.6 Establish lcfg-level Solaris support in Subversion, distributing old Solaris resources to LCFG-level header files as necessary
2007-04-17 2007-03-09 1.10 Test the new Solaris configuration with Services and Inf unit test Suns.
2007-04-17 2007-03-31 1.11 Upgrade all other Suns one by one from the old headers to the new ones.
2007-01-12 2006-12-20 re-evaluate Re-evaluate approach after running into problems with integration of headers
2007-02-02 2007-02-28 1.7 Establish inf-level support for Solaris in Subversion
2007-02-02 2007-02-28 1.8 Establish dice-level Solaris support in Subversion
2007-02-14 2007-02-28 1.9 Test configuration with MPU test Sun
2007-04-27 2007-05-01 1.12 Reassess remaining aims of project in light of changing circumstances & needs
2007-06-01 2007-06-01 1.13 Look for ways to speed up the patching process
2007-09-04 2007-07-31 2.0 Develop and demonstrate a minimum-effort pca-based patch solution which delivers accurate patch selection and far quicker patch selection than current tools.
2007-11-02 2007-11-07 2.1 Services Unit adopts new patching solution.