Project plan for more secure RPM submission tool


Convert the rpmsubmit tool to use AFS instead of NFS.


Computing Staff and users of DIYDICE machines.


The current rpmsubmit tool is a crude setuid program which copies the submitted RPMs over NFS to the RPM repository and then runs the genhdfile program over those RPMs.

There are a number of problems with this approach :-

  • it has weak security as it uses NFS as transport
  • RPMs can only be submitted from local machines
  • only COs can contribute RPMs

This project will move the RPM repository to AFS and modify the rpmsubmit tool appropriately.

A further project will be proposed to enhance the functionality of the RPM submission technology :-

  • automatically detecting which bucket to use (based on history)
  • allow submitter to add a tag to explain reason for RPM
  • perform simple validation of RPM being submitted (particularly for user-submitted RPMs)


  • provision of AFS volume for repository (see Resources)
  • expertise from Services Unit (see Resources)


The project will be managed by Alastair Scobie


  • estimate 10 working days
  • RAIDed and replicated AFS volume for repository - current use is 100Gb, but this is currently 93% full, so 150Gb is probably more appropriate.
  • Some expertise from the Services Unit will be required to setup an AFS volume and advise on AFS ACLs


(8th Aug) Conclusions from discussion with Craig on 2nd August were :-
  • RPMs and SRPMs will live on a set of replicated AFS volumes
  • there is a preference for avoiding huge volumes, so we will need several volumes
  • the AFS root is likely to be /afs/
  • we will need to consider the structure under the above root
  • We need flexible host based access control to the RPMs; AFS host-based access is flakey/primitive so we will continue to deliver RPMs via HTTP.
  • RPMs/SRPMs will not be openly readable via AFS (?)
  • the two existing RPM accelerators will now run apache with identical configs
  • to allow apache to serve RPMs, will need to create a new principal with appropriate rights and use kstart as with backup server(s)
  • might need to hack apache component to do the relevant kinit as "packages" principal.
  • pezenas will become redundant


  1. design structure within /afs/ (2 days Alastair)
    • considerations include :-
      • different replication requirements for different branches
      • different access control requirements for different branches
      • yum compatibility
      • solaris and mac requirements
  2. arrange for /afs/ repository to be created (? days services-unit)
  3. populate repository and create appropriate access controls (1 day Alastair)
  4. identify required changes to rpmsubmit , implement and test (2 days Alastair)
  5. create new "packages" principal with appropriate rights for RPM accelerators (? days services-unit)
  6. identify required changes to RPM accelerators, implement and test (3 days Alastair)
    • may need to hack apache component to do relevant k5start as "packages" principal.
  7. deploy new repository, rpmsubmit and RPM accelerators (2 days Alastair)


Not much work on this happened due to holidays and post-holidays catch up. Alastair is about to start work proper.

Craig and Alastair met to discuss what was possible with AFS

No work has been carried out on this project, primarily due to illness.

Slipped again due to higher priority work. Now aiming for steps 1-4 to be complete by 1/11/06 (rather than 1-6).


  • Complete steps 1-4 (5 days) by 1/11/06
  • Complete steps 7 (5 days) by 6/12/06



-- AlastairScobie - 12 Sep 2006

Topic revision: r9 - 04 Oct 2007 - 16:43:45 - AlastairScobie
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