Archive

Archive for October, 2011

Repositories and Distribution

October 13, 2011 Leave a comment

Purpose:

The Purpose of this lab is to sign and create a repository in order to distribute my newly created and tested RPM file.

Signing:

To sign my RPM package first I have to generate a key. This is done using GPG.

gpg –gen-key

This application asks you a few questions including

  • Type of key
  • Key expiry
  • Email address
  • Name

After generating my key, I edit my ~/.rpmmacros file and add in the line:

%_gpg_name “nlambert@learn.senecac.on.ca”

Now I can sign my RPM with the newly generated key and then export the public key in to be used later :

rpm –addsign rpmbuild/RPMS/i686/spell-1.1-1.fc15.i686.rpm

gpg –export –armour nlambert@learn.senecac.on.ca > mygpg

Using root privileges I moved my exported key in to the /etc/pki/rpm-gpg directory:

mv /home/nick/mygpg /etc/pki/rpm-gpg/RPM-GPG-KEY-nlambertrepo

I then created a temporary directory to make my repository in and copied my RPM to it. From there I ran the “createrepo” command to generate the repo data folder.

mkdir temp
cp rpmbuild/RPMS/i686/spell-1.1-1.fc15.i686.rpm temp
cd temp/
createrepo .

I then copied the contents of the repodata folder and my source file to a web host (Matrix)

scp -r spell-1.1-1.fc15.i686.rpm repodata nlambert@matrix:~/public_html/myrepo

SSHing into my matrix account I moved the files into their proper places:

mkdir /public_html/www/myrepo/repodata
mv *.gz public_html/myrepo/repodata/
mv *.bz2 public_html/myrepo/repodata/
mv repomd.xml public_html/myrepo/repodata/
mv spell-1.1-1.fc15.i686.rpm public_html/myrepo/

Testing:

In order to test my newly signed and created repository, I copied one of the files in /etc/yum.repos.d in order to create my own.

cp /etc/yum.repos.d/fedora /fedora.repo etc/yum.repos.d/nlambert.repo

The contents of my custom repository file

  1. [NLambert]
  2. name= NLambert Repo
  3. failovermethod=priority
  4. baseurl=http://matrix.senecac.on.ca/~nlambert/myrepo
  5. enabled=1
  6. metadata_expire=7d
  7. gpgcheck=1
  8. gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-nlambertrepo

Line 1 is the listed name of the custom repository.

Line 4 is the location of my repository where the RPM may be downloaded from.

Line 5 enables the repo file for use when installing files.

Line 6 specifies when the client must update their version of this repo in order to check for new updates.

Line 7 specifies that the RPMs served from this repo are signed with a key.

Line 8 specifies that the public key to be used to verify the signing of the RPMs should be located in /etc/pki/rpm-gpg and named RPM-GPG-KEY-nlambertrepo

Using this file I am now able to install from my very own repository!

A method I used to check my custom repo was “rpm repolist” which displays all repositories which you may install/update from.

From here I’m able to install from my repository with the command “yum install spell”. Because my version of spell has a higher version number it is able to install it from my repository.

Repository Release:

In order to make my repo available to others I can package my repo file and my GPG key into an rpm of its own.

I have yet to do this but will be detailing my attempt at it in my next blog post.

 

My Repository

 

 

 

Categories: Uncategorized

Mock and Koji

October 5, 2011 Leave a comment

Purpose:

The purpose of this lab is to use and become familiar with the mock and koji tools.

Installation of Mock and Koji:

Mock: Mock is used to test the accuracy of the build dependances for RPMS. Alerting you if your package is missing any.

To get mock, I simply used YUM to grab and install it # yum install mock -y

I then have to add my user account to the mock users group # usermod -G

Koji: Is a build farm system which lets you test your build on different architectures that you might not have an access to.

Koji can be installed with a single step # yum install fedora-packager.

And then run /usr/bin/fedora-packager-setup  which creates the certificates to use Koji.

Using Mock:

In order to use mock, you need to have an SRPM built.

The syntax for using mock is # mock -r <configfile> <SRPMfile>

Here’s an example of one of the mock commands I used:

mock -r fedora-14-i386 rpmbuild/SRPMS/spell-1.1-1.fc15.src.rpm

The results of the mock command are sent to the /var/lib/distribution/result directory.

The distribution is determined by the distribution that was selected when the mock command was entered.

Here is an updated version of my RPM of spell : SPELL


Using Koji:

To build a package using Koji the command syntax is # koji ¬†build dist-f14 –scratch rpmbuild/SRPMS/spell-1.1-1.fc15.src.rpm

The distribution to test the RPM on is F14(Fedora 14(32 and 64bit))

The RPM to be tested is spell-1.1-1.fc15.src.rpm

The –scratch specifies that the build is not committed to the fedora distribution.

Once the distribution has been uploaded to Koji, there will be a link which you can take to view the status of your build on Koji.

Here is one of mine : http://koji.fedoraproject.org/koji/taskinfo?taskID=3407241

The build is listed as closed because it has completed.

There is another method of tracking the status of your Koji build. By simply entering # koji watch-task taskID

Conclusion:

So, my first experience using Mock and Koji were interesting. It was fun to upload and queue my package to the Koji build farm and be able to watch as a host picks up the task and builds it for me.

Categories: Uncategorized