Winter 2010 Posters/Certs

From CDOT Wiki
Revision as of 20:15, 17 April 2010 by Sadiki (talk | contribs) (The Koji Certification Process)
Jump to: navigation, search

Project Name

Koji Certification Creation

Name

Sadiki Latty


Understanding the Koji Process

Before understanding the koji certification process, one must first understand the koji process. Koji utilizes various machines (virtual or physical) to build software packages for different architectures. We decided to create a koji builder scenario for our ARM based physical machines (openrd, sheeva plug) and our virtual machine (arm emulators). In order for these machines to perform these tasks we need a central monitoring system that can track progress accordingly, this is the kojihub. Before these builders can communicate with the hub they need to be authenticated and verified as authorized builders, and that is where koji certifications come in.

The Koji Certification Process

As you may or may not know, the Koji build process

So after reading and tweaking sample openssl code and config here:

http://fedoraproject.org/wiki/Koji/ServerHowTo

I managed to break the code down into 2 separate peices. One for making the CA and one for making the certs for the different users. Now the way my script differs from the original is that it uses the variables passed to it as the default commonName in the ssl.cnf file.

For example, when executing my script to create a cert for a new user...lets say "kojiuser1":

  1. ./certscript kojiuser1

The script as usual asks the various questions about where you are from and the OU name and the province etc, etc, but is then followed by the question of what the commonName should be. This name and/or the OU name should always be different from any other certs already created or you will get a TXT_ error. My script makes pressing enter easier by allowing you to press enter knowing that the commonName will be (by default).. "kojiuser1". Now this may not seem like anything huge for the creation of one user but what if we were creating multiple users (which was the case with me).



  1. for user in arm{1..25}

>do >./certscript $user >done

In addition, a folder called "confs" holds all the conf files used to make the certs, this makes backtracking easier. For now only one line gets modified but it leaves progression for future endeavours. The only time you need to press a key other than enter is when it asks if you want to sign the cert. Of course 95% of the script remains the same as before but this modification makes life one step easier and hence minimizes the length of the cert creation process.