Fedora Build and Release Infrastructure

This page contains some general notes on the Fedora Build & Release Infrastructure, intended to provide some background information for those working on the DPI908 Research Paper.

Systems involved in the Build and Release Process

• The Upstream Software Source
  • Provide source tarballs
• Packager's System(s)
  • Initial builds and tests
• GIT and Look-aside Cache
  • Used to store packages with full history
  • Each package may be edited only by (a) the package maintainer (b) provenpackagers, a group of seasoned packagers who have special privilege to fix emergency problems, blocker bugs, and bugs for which the maintainer has been slow to respond (c) selected secondary-architecture group members, who may alter packages to enable them to build on secondary architectures
• FAS2
  • Used to maintain user accounts
  • Holds uploaded ssh public keys for some Fedora systems (e.g., people.fedoraproject.org)
  • Generates certificates for access to some Fedora systems (e.g., Koji)
• Koji
  • Used for preliminary (scratch) and final builds
  • Scratch builds accept input from (a) the GIT repo or the Packager's system plus (b) the Fedora package repos
  • Final builds accept input only from (a) the GIT repo and (b) the Fedora package repos
  • Authenticated against FAS2 using PKI. Revocation lists are downloaded hourly
  • Uses mock for builds (which in turn uses yum and rpmbuild within a chroot environment)
• Bugzilla
  • Tracks review requests
  • Is updated automatically by some tools (e.g., Bodhi)
  • Does not use FAS2 for authentication
• Bodhi
  • Used for managing packages through the QA process
  • Interfaces with AutoQA and manual processes
  • Authenticated against FAS2 using passwords
  • As packages pass various QA stages, Bodhi tags and untags the packages though Koji to track their state
• Sigul
  • Used to sign packages
  • Three-tier design which interfaces with Koji. Signatures are generated on a signing server, which interfaces (outbound-only) with a bridge server. The bridge server interfaces with the sigul client (run by the person doing the signing) and Koji (which holds the packages being signed, and which stores the signatures). The user never has the private key, the server does not accept inbound connections, and the signers' passwords may be individually revoked as needed
  • Koji holds the unsigned packages and combines them with the appropriate signatures on-demand. For example, a particular binary package may be included in both Fedora 17 and Fedora 18 - the package is held once, and merged with the appropriate signature when needed
• Fedora Mirror System
  • Over 300 mirrors, managed by the individual organizations that have volunteered mirror space, are rsynced from a master mirror daily
• Mirrormanager
  • Directs incoming requests to the appropriate mirrors (using IP address heuristics) by sending a presorted mirror list to the YUM client
• YUM and RPM
  • Packages are authenticated using a public key

General Infrastructure

• Most of the Fedora infrastructure is physically located in a datacentre in Phoenix, Arizona (PHX2)
• Infrastructure is managed by the Fedora Infrastructure Team. Membership is open to the community through a sponsorship and mentorship process
• Two-factor authentication is used for most but not all infrastructure access; the current Security FAD is attempting to add two-factor authentication to the remaining portions of the infrastructure

Software

All of the software used in the Fedora Infrastructure is (supposed to be) from the Fedora repositories. In addition, there is a git repository of configuration files and helper scripts.

Documentation

The Fedora infrastructure, standard operating procedures, and policies are documented on the Fedora wiki.