Installing and Using Koji with EGEE SA1

Below describes a procedure to install, setup and interact with both the sa1 koji service at http://skoji.cern.ch/koji and more genrally the release process.

Install Koji.

Easiest on fedora just yum install koji. For SL4 or SL5 the take it from EPEL 5. If you to submit from jobs from another platform we can probably help, it's a very small client. For EPEL4 there is now a koji client in the SA1 repositories.

Koji Account

Send a mail to koji service manager with your DN, (GridAUTH support team, support@gridNOSPAMPLEASE.auth.gr)

CERN CA Identity.

The Koji system operated for SA1 currently uses CERN certificates only in the first instance. If this becomes impossible this can be changed. Also koji realistically can only be used by decrypting your globus key. This must also be changed with priority, I'll do this very soon.

mkdir ~/.koji
openssl rsa -in ~/.globus/userkey.pem > ~/.koji/usercertkey.pem
cat ~/.globus/usercert.pem >> ~/.koji/usercertkey.pem
chmod 600 ~/.koji/usercertkey.pem
# When you have finished working with koji
rm -f  ~/.koji/usercertkey.pem

Koji Configuration

Create a file ~/.koji/config containing:

[koji]
server = https://koji.afroditi.hellasgrid.gr/kojihub
cert = ~/.koji/usercertkey.pem
;certificate of the CA that issued the client certificate
ca = ~/.koji/cern-ca.pem
;certificate of the CA that issued the HTTP server certificate
serverca = /etc/grid-security/certificates/28a58577.0

in fact ca should be your own CA of course. In the CERN case because there are two certificates needed =cat /etc/grid-security/certificates/d254cc30.0 /etc/grid-security/certificates/1d879c6c.0 > ~/.koji/cern-ca.pem

Submit a SRPM to Koji

At this point if this package release is fixing any bugs in Savannah then they should have been moved to status Fixed. A src rpm can be submitted to one or preferably all of the build targets, in this CentOS 4 (=sl4) , CentOS 5 (=sl5) and fc10.

koji build --scratch centos4-egee foobar-1.23-5.el4.src.rpm
koji build --scratch centos5-egee foobar-1.23-5.el5.src.rpm

Note that your %{dist} tag should be correct before you submit your package. i.e the rpm release in the spec file should be of the form.

Release: 5{%?dist}

You can then define the relevant release when making your src package using:

rpmbuild -bs --define 'dist .el4' foobar.spec
rpmbuild -bs --define 'dist .el5' foobar.spec

and then submit of each of these in turn to koji.

Submit a SCM URL to Koji.

At this point if this package release is fixing any bugs in Savannah then they should have been moved to status Fixed. If your code or release is in SCM e.g CVS or SVN then you can just submit a tag or revision respectively. e.g.

koji build --scratch --nowait centos5-egee 'svn+http://www.sysadmin.hep.ac.uk/svn/grid-monitoring/trunk/msg/msg-utils/#1751'
koji build --scratch --nowait centos5-egee 'cvs://cvs.example.org/cvsroot?foobar/foo#v1_2_3'

The layout of your SCM must support a particular sequence once checked out.

SPEC=*.spec
make sources
rpmbuild --define "_sourcedir `pwd`" -bs $SPEC

That is to say once the sources has been checked out the spec file will be created by looking for *.spec. The make sources will then be called and this can do anything really, e.g nothing, download sources from somewhere else, construct a tar ball of the checked out sources. Finally rpmbuild will be called on the .spec file and the sources needed by the .spec file are expected to be located either already or by the make sources in the same directory.

Known Problems

• Currently the greek koji because of the improvements using a full DN rather than the CN=username it tries to notify DN@none which is of course an invalid email address. This will be fixed at some point.

-- SteveTraylen - 20 May 2009