extras-buildsys ChangeLog,1.3,1.4 README,1.1.1.1,1.2
Daniel Williams (dcbw)
fedora-extras-commits at redhat.com
Thu Jun 9 01:57:36 UTC 2005
Author: dcbw
Update of /cvs/fedora/extras-buildsys
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv15057
Modified Files:
ChangeLog README
Log Message:
2005-06-08 Dan Williams <dcbw at redhat.com>
* Convert all client/server communication to SSL. You will now need certificates
(see the README file for how to set them all up) to get them to talk to each
other. Now requires m2crypto module as well.
Index: ChangeLog
===================================================================
RCS file: /cvs/fedora/extras-buildsys/ChangeLog,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ChangeLog 8 Jun 2005 15:55:51 -0000 1.3
+++ ChangeLog 9 Jun 2005 01:57:34 -0000 1.4
@@ -1,5 +1,11 @@
2005-06-08 Dan Williams <dcbw at redhat.com>
+ * Convert all client/server communication to SSL. You will now need certificates
+ (see the README file for how to set them all up) to get them to talk to each
+ other. Now requires m2crypto module as well.
+
+2005-06-08 Dan Williams <dcbw at redhat.com>
+
* Refactor FileDownload.py and FileServer.py, moving them into a shared
directory common/. Fix client & server to point to these modules and
implement callbacks in each that are required by FileDownload.py. Since
Index: README
===================================================================
RCS file: /cvs/fedora/extras-buildsys/README,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- README 1 Jun 2005 04:15:00 -0000 1.1.1.1
+++ README 9 Jun 2005 01:57:34 -0000 1.2
@@ -2,42 +2,44 @@
The build system is composed of a single build server, and multiple build clients. Both clients and server must be on the same LAN, or at least have access to the same shared storage. Clients run an XMLRPC server to which the build-server delivers build jobs. The build server runs an XMLRPC server to allow submission of jobs, and to retrieve basic status information about both clients and the build system as a whole.
-The Build Client (ArchWelder):
+The Build Client:
------------------------------------------
-usage: archwelder.py <address> <architectures>
-ie : archwelder.py localhost sparc sparcv9 sparcv8
+usage: build-client <address> <architectures>
+ie : build-client localhost sparc sparcv9 sparcv8
-Currently, archwelders are limited to building one job at a time. This limitation may be removed in the future. They do not queue pending jobs, but will reject build requests when something is already building. The build server is expected to queue and manage jobs at this time, and serialize requests to build clients. This may not be the case in the future.
+Currently, build clients are limited to building one job at a time. This limitation may be removed in the future. They do not queue pending jobs, but will reject build requests when something is already building. The build server is expected to queue and manage jobs at this time, and serialize requests to build clients. This may not be the case in the future.
main()
- `- Creates: XMLRPCArchWelderServer
- `- Creates: i386Arch, x86_64Arch, PPCArch, etc
+ `- Creates: XMLRPCBuildClientServer
+ `- Creates: i386Arch, x86_64Arch, PPCArch, etc (subclasses of BuildClientMach)
-The client creates an XMLRPC server object (XMLRPCArchWelderServer), and then processes requests in an infinite loop. Every so often (currently 5 seconds) the server allows each build job that is still in process to update its status and perform work. The XMLRPCArchWelderServer keeps a list of local build jobs, which are architecture specific, and forwards requests and commands for each job to that specific job, keyed off a unique id.
+The client creates an XMLRPC server object (XMLRPCBuildClientServer), and then processes requests in an infinite loop. Every so often (currently 5 seconds) the server allows each build job that is still in process to update its status and perform work. The XMLRPCBuildClientServer keeps a list of local build jobs, which are architecture specific, and forwards requests and commands for each job to that specific job, keyed off a unique id.
-Each build job (ArchWelderMach and its architecture-specific subclasses like i386Arch) has a number of states, that directly correspond to the actions that 'mach' must take to build the package. Each time the job is given time to process (which is done by calling the ArchWelderMach.process(), which in turn is called from XMLRPCArchWelderServer._process()) it checks its state, and advances to the next state when the previous state is complete. Communication with mach and retrieval of status from mach are done with popen2.Popen4() so that mach does not block the XMLRPC server from talking to the build server.
+Each build job (BuildClientMach and its architecture-specific subclasses like i386Arch) proceeds through a number of states. Build jobs are periodically given time to do work (BuildClientMach.process()) by their BuildClientInstance (from XMLRPCBuildClientServer._process()), which is in turn periodically given time by the client's main loop. During their processing time, build jobs check their state, see if any actions have completed, and advance to the next state if needed. Communication with mock and retrieval of status from mock are done with popen2.Popen4() so that mock does not block the XMLRPC server from talking to the build server.
+
+All communication with the build server is done through SSL to ensure the identity of each party. Both the XMLRPC server and the result file server are SSL-enabled, and require SSL certificates and keys to operate. See later section in this document on how to configure SSL certificates for your build system.
The Build Server:
------------------------------------------
-usage: bm_server.py
+usage: build-server
-The build server runs two threads. The first, the XMLRPC server (XMLRPCBuildMaster class), accepts requests to enqueue jobs for build and stuffs them into an sqlite database which contains all job details. The second thread, the Build Master (BuildMaster class), pulls 'waiting' jobs from the database and builds them. A third top-level object that runs in the same thread as the Build Master is the ArchWelderManager, which keeps track of build clients (ArchWelders) and their status.
+The build server runs two threads. The first, the XMLRPC server (XMLRPCBuildMaster class), accepts requests to enqueue jobs for build and stuffs them into an sqlite database which contains all job details. The second thread, the Build Master (BuildMaster class), pulls 'waiting' jobs from the database and builds them. A third top-level object that runs in the same thread as the Build Master is the BuildClientManager, which keeps track of build clients (ArchWelders) and their status.
main()
|- Creates: XMLRPCBuildMaster
- |- Creates: ArchWelderManager
- |- `- Creates: ArchWelderInstance (one for each arch on each ArchWelder)
- |- `- Creates: ArchWelderJob (one for each build job on each arch)
+ |- Creates: BuildClientManager
+ |- `- Creates: BuildClientInstance (one for each arch on each ArchWelder)
+ |- `- Creates: BuildClientJob (one for each build job on each arch)
`- Creates: BuildMaster
`- Creates: BuildJob (one for each build job)
-The ArchWelderManager object serves as a central location for all tracking and status information about each build job on each arch. It creates an ArchWelderInstance for each supported architecture of each build client (ie, each ArchWelder). The ArchWelderInstance keeps track of specific jobs building on that single architecture on that single build client. It also serves as the XMLRPC client of the ArchWelder on the remote build client, proxying status information from it.
+The BuildClientManager object serves as a central location for all tracking and status information about each build job on each arch. It creates an BuildClientInstance for each supported architecture of each build client. The BuildClientInstance keeps track of specific jobs building on that single architecture on that single build client. It also serves as the XMLRPC client of the remote build client, proxying status information from it.
-BuildJobs must request that the ArchWelderManager create a new ArchWelderJob for each build on each architecture the BuildJob needs. If there is an available ArchWelder (since ArchWelders only build one job at a time across all arches they support), the ArchWelderManager will pass the request to the arch-specific ArchWelderInstance, which creates the new arch-specific ArchWelderJob, and pass it back through the ArchWelderManager to the parent BuildJob. If there is no available ArchWelder for the request, the BuildJob must periodically re-issue the build request to the ArchWelderManager.
+BuildJobs must request that the BuildClientManager create a new BuildClientJob for each build on each architecture the BuildJob needs. If there is an available build client (since build clients only build one job at a time across all arches they support), the BuildClientManager will pass the request to the arch-specific BuildClientInstance, which creates the new arch-specific BuildClientJob, and pass it back through the BuildClientManager to the parent BuildJob. If there is no available build client for the request, the BuildJob must periodically re-issue the build request to the BuildClientManager.
-ArchWelderManager has a periodic processing routine that is called from the BuildMaster thread. This processing routine calls the ArchWelderInstance.process() routine on each ArchWelderInstance, which in turn updates its view of the remote build client/ArchWelder's status. Thus, the ArchWelderManager, through each ArchWelderInstance, knows the status and currently building job on each remote build client.
+BuildClientManager has a periodic processing routine that is called from the BuildMaster thread. This processing routine calls the BuildClientInstance.process() routine on each BuildClientInstance, which in turn updates its view of the remote build client's status. Thus, the BuildClientManager, through each BuildClientInstance, knows the status and currently building job on each remote build client.
BuildJobs track a single SRPM build through the entire build system. They are created from the BuildMaster thread whenever the BuildMaster finds a job entry in the sqlite database with the status of 'waiting'. BuildJobs proceed through a number of states: "initialize", "checkout", "make_srpm", "prep", "building", "finished", "cleanup", "failed", and "needsign".
@@ -55,6 +57,75 @@
- failed jobs? => failed
- otherwise => needsign
-The BuildJob updates its status when it is periodically told to do so by the BuildManager. At this point, it will advance to the next state, or spawn build jobs that have not yet started if ArchWelders for those architectures are now available. It stays in the "building" state until all jobs are first spawned, and then either completed or failed.
+The BuildJob updates its status when it is periodically told to do so by the BuildManager. At this point, it will advance to the next state, or spawn build jobs that have not yet started if build clients for those architectures are now available. It stays in the "building" state until all jobs are first spawned, and then either completed or failed.
+
+All communication with build clients is done through SSL to ensure the identity of each party. When the client requests the SRPM to build, SSL is used. When the build server retrieves logs and RPMs from the build client, SSL is also used. This ensures that build clients can be more or less trusted, or at least that some random build client is not serving you packages that might contaminate your repository. See later section in this document on how to configure SSL certificates for your build system.
+
+
+Configuring SSL for your Build System
+--------------------------------------
+
+When you set up the build system, you essentially become a Certificate Authority.
+Because the build server and the build clients communicate using SSL, they need
+to exchange certificates to verify the others' identity. You must first create
+a key/cert pair for the Build System Certificate Authority, which signs both
+the build server's certificate, and each build client's certificate.
+
+
+Setting up the Build System Certificate Authority
+
+1. Set up the CA directory
+cd <somedir>
+mkdir CA
+cd CA
+mkdir newcerts private
+touch index.txt
+echo '01' > serial
+
+
+2. Generate a BSCA private key:
+
+openssl genrsa -out private/cakey.pem 2048
+
+
+3. Generate the BSCA certificate
+
+openssl req -new -x509 -key private/cakey.pem -out cacert.pem -extensions v3_ca -days 3650
+
+
+4. Generate a build server key
+
+cd <somedir>
+mkdir -p buildsystem/server
+cd buildsystem/server
+openssl genrsa -out server_key.pem 2048
+
+
+5. Generate a build server certificate request
+
+openssl req -new -nodes -out server_req.pem -key server_key.pem
+
+
+6. Sign the build server certificate request with the BSCA certificate
+
+openssl ca -out server_cert.pem -infiles server_req.pem
+
+
+7. For each build client you have, you will need to do the following: generate a
+build client key, certificate request, and sign it:
+
+cd <somedir>/buildsystem
+mkdir client1
+cd client1
+openssl genrsa -out client1_key.pem 2048
+openssl req -new -nodes -out client1_req.pem -key client1_key.pem
+openssl ca -out client1_cert.pem -infiles client1_req.pem
+
+8. Use the certificates. You now have certificates for the build server and one
+or more clients. You may add clients using step 7 to create and sign their
+certificate requests.
+
+9. Copy server_cert.pem, server_key.pem, and cacert.pem to a directory on the build server. IMPORTANT: make sure only the build server's user can read server_key.pem, since it is the server's private key. Then, modify the server's CONFIG.py file and point the respective config options to the _full_ path to each file.
+10. Copy client1_cert.pem, client1_key.pem, and cacert.pem to a direcrory on the build client. IMPORTANT: make sure only the build client's user can read client1_key.pem, since it is the client's private key. Then, modify the client's CONFIG.py file and point the respective config options to the _full_ path to each file.
More information about the fedora-extras-commits
mailing list