Showing posts with label LABS. Show all posts
Showing posts with label LABS. Show all posts

Monday, April 18, 2011

Creating a YUM Repository

Welcome Again. In this post I will describe the steps required in order to create your own YUM repository that can be used to install new versions of software. For this post I am using the “gnupg-1.4.11-1.fc14.x86_64.rpm” I created in my previous posts. Only this time I had added an option in the Spec File which increased the Epoch version.

Before we begin you need to generate a GPG Key using the gpg --gen-key command -- this allows you to sign your RPM file.

After you generate your key you will need to add the email address associated to your GPG key to the %_gpg_name macro in the ~/.rpmmacros file -- %_gpg_name “email-address”.

Our first step after creating our GPG key would be to sign this RPM package, the command that we need to use in order to accomplish this is below – enter your pass phrase when prompted;
rpm --addsign gnupg-1.4.11-1.fc14.x86_64.rpm
Enter pass phrase:
Pass phrase is good.

If the previous command returned successful then we can move onto the next step – creating your repository. (Assuming Apache is installed we will create the directory /var/www/html/fedora/14/x86_64/rpms/ which will hold our RPM files). To accomplish this follow the steps provided below;

Log in as the super user
cp ~/rpmbuild/RPMS/gnupg-1.4.11-1.fc14.x86_64.rpm  /var/www/html/fedora/14/x86_64/rpms/
createrepo /var/www/html/fedora/14/x86_64/rpms/ (output provided below)
1/1 - gnupg-1.4.11-1.fc14.x86_64.rpm                                           
Saving Primary metadata
Saving file lists metadata
Saving other metadata

If the YUM repository was created successfully above you should see a directory named repodata in the /var/www/html/fedora/14/x86_64/rpms/ directory.

After we have verified that the repository has been created you will need to create a new repository file inside of the /etc/yum.repos.d directory -- an example of a repository file (called fedora-gcasella.repo) I have created is below;
[fedora-gcasella]
name=Fedora $releasever - $basearch
failovermethod=priority
baseurl=http://gcasella.dynamic-dns.net/fedora/14/$basearch/rpms/
enabled=1
metadata_expire=7d
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-gcasella

IMPORTANT: If the gpgkey option is commented out and you try to run the yum install command you will receive an error indicating that the public key for the package is not installed.

Before testing out new repository we will create a new file within the /etc/pki/rpm-gpg/ directory – you may give it any name that you want.

After creating this file we will run the command; gpg --export --armor <email-address> (ensure that this is done as the regular user and NOT the super user.) Save the output of this command to the new file you had created inside of the /etc/pki/rpm-gpg/ directory.
If everything has gone well you will be able to test your newly created repository (ensure that the httpd service is started on the machine holding your RPM files.) and run the yum install gnupg command. You should receive similar output as below;

Loaded plugins: langpacks, presto, refresh-packagekit
Adding en_US to language list
fedora-gcasella                                                                                                                       | 1.3 kB     00:00    
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package gnupg.x86_64 3:1.4.11-1.fc14 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

=============================================================================================================================================================
 Package                         Arch                             Version                                    Repository                                 Size
============================================================================================================================================================
Updating:
 gnupg                           x86_64                           3:1.4.11-1.fc14                            fedora-gcasella                           1.2 M

Transaction Summary
============================================================================================================================================================
Upgrade       1 Package(s)

Total size: 1.2 M
Is this ok [y/N]: y
Downloading Packages:
warning: rpmts_HdrFromFdno: Header V4 RSA/SHA1 Signature, key ID e1af8018: NOKEY
fedora-gcasella/gpgkey                                                                                                                | 3.4 kB     00:00 ...
Importing GPG key 0xE1AF8018:
Userid: "Gian-Luca Casella <gcasella@learn.senecac.on.ca>"
From  : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-gcasella
Is this ok [y/N]: y

Selecting “y” will install the GPG key into your system, indicating that it is now a valid signature and to accept any other packages from you that you may have available for download.


Repository-Release RPM:

To make it easier for other users to access my repository I have created an RPM which contains both my repository file along with my GPG key. This RPM can be found by clicking on this link.

The steps below show how I was able to create this repository release RPM file …
cp /etc/yum.repos.d/fedora-gcasella.repo   ~/rpmbuild/SOURCES/
cp /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-gcasella ~/rpmbuild/SOURCES/
tar cvf gcasellarepo-0.0.1.tar *gcasella* && gzip gcasellarepo-0.0.1.tar

The commands above will copy the repository file and the GPG Key file (created previously) into your ~/rpmbuild/SOURCES/ directory. Next you would need to create a tarball of these files using the tar cvf command – this tarball can be found here.

Once we have the Sources in the appropriate place we will create the SPEC file, the contents of my spec file are listed below, this will install the repository file and the GPG key to their appropriate locations;

Name:gcasellarepo
Version:0.0.1
Release:1%{?dist}
Summary:RPM Package containing my repository file along with my GPG Key

Group:System Environment/Base
License:GPLv3
URL:http://gcasella.dynamic-dns.net/fedora/
Source0:http://gcasella.dynamic-dns.net/fedora/14/x86_64/source/gcasellarepo-0.0.1.tar.gz
BuildRoot:%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

%description
Installs my custom made repository configuration file along with its GPG key

%prep
%setup -q

%build

%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT%{_sysconfdir}/yum.repos.d/
mkdir -p $RPM_BUILD_ROOT%{_sysconfdir}/pki/rpm-gpg/
cp -p fedora-gcasella.repo $RPM_BUILD_ROOT%{_sysconfdir}/yum.repos.d/
cp -p RPM-GPG-KEY-fedora-gcasella $RPM_BUILD_ROOT%{_sysconfdir}/pki/rpm-gpg/

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)
%doc
/etc/yum.repos.d/fedora-gcasella.repo
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-gcasella

%changelog
* Tue Feb 08 2011 Gian-Luca Casella <gcasella@learn.senecac.on.ca> 0.0.1
- Created my own personal RPM in order to install both my repository file along with the corresponding GPG Key needed to install with.

Additional Notes:

If you buy chance have SELinux running and is set to “Enforcing” issue the setsebool  -P httpd_read_user_content 1 command, this has fixed any issues for me.

Gian-Luca Casella -- Last Updated on Monday, April 18, 2011

Tuesday, February 1, 2011

Using Mock and Koji




Hello Readers,


The purpose of this post is to demonstrate a step-by-step procedure on how to use the mock and koji tools.

Mock is used to test that the BuildRequires for a package are accurate; creating a bare-bone chroot environment that only contains the basic build packages plus any packages that were indicated by the BuildRequires line in the spec file.

Koji is a client-server system that allows you to queue build with the Fedora build farm. This will allow you to test your packages by building them for different architectures.

Mock

Before we being we must install mock by using the yum install mock command.
Add yourself to the mock group giving you the ability to properly use the command: usermod –G mock <username>.

In order to use mock to test your package’s  BuildRequires you will need to use SRPMs that you have built in the past. The command syntax for using mock is, mock –r <architecture> <path-to-SRPM>.


NOTE: A list of architectures that mock is able to test can be found in the /etc/mock/ directory, and your systems default architecture for mock can be found in the /etc/mock/default.cfg file.


I will be using my SRPMs that I created in my previous post in order to demonstrate how the mock command is used. (gnupg-1.4.11-1.fc14.src.rpm and wdiff-0.6.5-1.fc14.src.rpm)

[gcasella@Fedora14  SRPMS]$ mock -r default wdiff-0.6.5-1.fc14.src.rpm
INFO: mock.py version 1.1.8 starting...
...
INFO: Start(wdiff-0.6.5-1.fc14.src.rpm)  Config(fedora-14-x86_64)
State Changed: lock buildroot
...
State Changed: running yum
State Changed: creating cache
State Changed: unlock buildroot
State Changed: setup
State Changed: build
INFO: Done(wdiff-0.6.5-1.fc14.src.rpm) Config(default) 3 minutes 43 seconds
INFO: Results and/or logs in: /var/lib/mock/fedora-14-x86_64/result

As you can see from the output above it took 3 minutes and 43 seconds for the mock command to complete its tests. Any errors that may arise can be found in the log files in your /var/lib/mock/<architecture>/results/ directory.

NOTE: It may seem that the mock command times out while it’s running yum. It is crucial to remember that each SRPM that is being tested for the first time will take a long time.

KOJ I

In order to use koji we must install the client software that will upload your package to the Fedora farm build. Koji requires you to have a Fedora Account System (FAS2) account, this is where you will be able to watch the status of your uploaded packages.

To install Koji use the command: yum install fedora-packager

Before using the Koji command line interface you need to perform an initial setup, luckily the Koji package includes a script which will automatically set up your Koji client. To perform the initial setup you must run the command as a non-super user: /usr/bin/fedora-packager-setup – Follow the on screen instructions and import the created certificate into your Firefox web browser. (Additional information can be found here)

The command koji build dist-f14 –scratch SRPM will allow you to queue a build request on the main koji server. The target (dist-f14) instructs koji to build the package using packages available in the Fedora 14 distribution and the –scratch option causes koji to build the package but not take it for the specific target (i.e. not include it in Fedora 14). Below is an example of the Koji command using my gnupg-1.4.11-1.fc14.src.rpm package;

[gcasella@Fedora14  SRPMS]$ koji build dist-f14 --scratch gnupg-1.4.11-1.fc14.src.rpm
Uploading srpm: gnupg-1.4.11-1.fc14.src.rpm
[====================================] 100% 00:00:44   4.50 MiB 102.81 KiB/sec
Created task: 2748409
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=2748409
Watching tasks (this may be safely interrupted)...
...
2748409 build (dist-f14, gnupg-1.4.11-1.fc14.src.rpm): free -> open (x86-02.phx2.fedoraproject.org)
...
2748411 buildArch (gnupg-1.4.11-1.fc14.src.rpm, i686): free -> open (x86-14.phx2.fedoraproject.org)

You will notice in the output above that a Task ID will be given, with this task ID you can use the following command: koji watch-task <task ID>, alternatively you can monitor your tasks through the https://koji.fedoraproject.org website. An example of the koji watch-task <task ID> command is displayed below;

 [gcasella@Fedora14  SRPMS]$ koji watch-task 2748409
Watching tasks (this may be safely interrupted)...
2748409 build (dist-f14, gnupg-1.4.11-1.fc14.src.rpm): open (x86-02.phx2.fedoraproject.org)
  2748411 buildArch (gnupg-1.4.11-1.fc14.src.rpm, i686): open (x86-14.phx2.fedoraproject.org)
   ...
   ...
  0 free  2 open  1 done  0 failed
  2748411 buildArch (gnupg-1.4.11-1.fc14.src.rpm, i686): open (x86-14.phx2.fedoraproject.org) -> closed
  0 free  1 open  2 done  0 failed
2748409 build (dist-f14, gnupg-1.4.11-1.fc14.src.rpm): open (x86-02.phx2.fedoraproject.org) -> closed
  0 free  0 open  3 done  0 failed

2748409 build (dist-f14, gnupg-1.4.11-1.fc14.src.rpm) completed successfully



Where To Find My Files! 

I have provided links to my SRPMs from my previous posts along with a screen shot of my successful tasks performed on the Fedora build farm;


    Koji Server Screen Shot 

gnupg-1.4.11 Files
wdiff-0.6.5 Files



Gian-Luca Casella -- Last Updated on Tuesday, February 01, 2011



Tuesday, January 18, 2011

Creating an RPM Package



Hello Again Readers,

WARNING: All tasks performed in this post must NOT be done as the root user.

This post will discuss my experiences on creating an RPM Package based on the tarballs (packages) from my previous post -- gnupg-1.4.11 & wdiff-0.6.5, also including a step by step procedure on how I was successful.

Before beginning an RPM build you need to ensure you have the following installed; Fedora Packager (yum groupinstall "Fedora Packager"), this will automatically install rpmlint.

Note: yum-utils came pre-installed for me on Fedora 14 after performing a system update using the "yum update" command.

After the necessary packages were installed we then need to build the required RPM tree structure where RPM packaging will take place this can be done by using the "rpmdev-setuptree" command. This command will create the following directory structure;

[root@gcasella-fc14 ~]$ tree rpmbuild/
rpmbuild/
├── BUILD
├── RPMS
├── SOURCES
├── SPECS
└── SRPMS

Next I will provide the necessary commands and expected output to successfully build an RPM Package.


Step 1: I placed the source (.tar.gz) files into the ~/rpmbuild/SOURCES/ directory.

Step 2: Changed my current working directory to the ~/rpmbuild/SPECS/ directory and create a new spec file using the rpmdev-newspec <filename>.

Step 3: For the purpose of this post I will show a sample spec file that I had used for my gnupg-1.4.11.tar.gz RPM build. (The spec file can be found here http://fpaste.org/w9kr/)

Step 4: When the spec file was configured properly I ran the rpmbuild -ba <spec-filename> and waited for the build to complete. (Note: Some builds may take longer than others)

Step 5: If the build returned with no errors you should be able navigate to the ~/rpmbuild/RPMS/ and ~/rpmbuild/SRPMS/ directories and find your two newly created RPM Packages.

Step 6: I then tested my newly created RPM Packages by using the rpmlint  command on each of the following;
rpmlint ~/rpmbuild/SPECS/<spec-filename>
rpmlint ~/rpmbuild/RPMS/<new-RPM-package.rpm>
rpmlint ~/rpmbuild/SRPMS/<new-SRPM-package.src.rpm>
Note: The rpmlint command will show any errors/warnings that may be needed to fix before releasing.


Problems While Building

The only real problem I ran into while Building an RPM Package was during the actual build I would be told that a specific directory would not exist. I then noticed the "Name" and "Version" values MUST be the same as the name and version of the package. For example, if you use the gnupg-1.4.11.tar.gz package your spec file must contain the two pieces of data within the meta-data.
Name: gnupg
Version: 1.4.11
This was the only error that I've encountered throughout my attempts to build an RPM Package.


Where To Find My Files! 
gnupg-1.4.11 Files
RPM
SRPM
wdiff-0.6.5 Files
SRPM

Gian-Luca Casella -- Last Updated on Wednesday January 26th, 2011

Saturday, January 15, 2011

Building from Source Code

For this post I have chosen to build the following two packages from the GNU Software Collection;

       GnuPG -- Version 1.4.11
       wdiff -- Version 0.6.5

These two packages can be obtained by using the following two commands;
       wget ftp://ftp.gnu.org/gnu/wdiff/wdiff-0.6.5.tar.gz
       wget ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.11.tar.gz

After I downloaded the two packages I extracted the contents using the tar -zxf command. I then issued the ./configure command in both directories that were created after extracting the two packages.

While using the ./configure command I ran into no problems, all the required dependencies were already installed on my Fedora 14 System. Once the ./configure command returned successful I used the time make command for both packages, the results of this command are listed below;

          gnupg-1.4.11
          real    0m38.872s
          user    0m32.281s
          sys    0m4.720s

The binary created during the make process is located in ./g10/gpg. Basic instructions on how to use this package you can type the ./g10/gpg --help command.

          wdiff-0.6.5
          real    0m1.545s
          user    0m0.932s
          sys    0m0.394s

The binary created during the make process is located in ./src/wdiff. Basic instructions on how to use this package you can type the ./src/wdiff --help command.

Glossary
./configure ---> Configures the package for the specific system.
time make ---> Determines how long it took for the make command to execute.

--------------------------------------------------------
Gian-Luca Casella

Root Introduction

Hello Everyone,

My name is Gian-Luca Casella and I'm in my final semester in the CTYC program at Seneca@York.

After working at my last co-op placement I had the opportunity to work with different flavours of Open-Source Operating Systems. This includes but is not limited to -- Debian Based Systems, SLES (SuSe Linux Enterprise Server), and a great number of Red-Hat systems.

Software Build and Release is something new to me so I am really looking forward to participate in projects within the Fedora Community.

IRC Nickname: gcasella (Learn ID as well)
Seneca Wiki Profile
Fedora Wiki Profile


IRC Chat Log:

<gcasella> Hello Everyone! :-)

<mustafaj> hi gcasella!

<gcasella> How's it going? I'm in ctrylers SBR class this semester.

<mustafaj> oh cool stuff! I think you'll like it a lot

<gcasella> I hope so, haha, it's something completely new to me, so i'm hoping a lot will come out of it. I'm more of a Networking/Sys Admin type of guy.

<mustafaj> It's a networking/sys admin kind of course

<mustafaj> what you make of it really.  so should be just right

<gcasella> Well i figured it would be a sys admin/networking type of course since it's part of the CTY professional programs :-P.

<mustafaj> cool beans gcasella

<gcasella> Interesting, while I was on my co-op work term I've done a lot of source code installations, but I definitely failed using the rpmbuild command.

<mustafaj> yea its tricky stuff

<gcasella> Just out of curiosity, what kind of things have you done in this course? (Assuming you've already taken it :-))

<mustafaj> mustafaredha.wordpress.com

<gcasella> Cool cool, hah, I've also done the whole Windows USB bootable while I was on my work term as well.

<gcasella> I made a USB key with a grub menu to choose between different Operating Systems, even including live versions of Windows 2k3, XP, etc.

<mustafaj> thats pretty neat

<gcasella> if you're interested http://www.nu2.nu/pebuilder/

<mustafaj> you should blog it ;)

<gcasella> Definitely will eventually :)

<mustafaj> i am, thanks i'll bookmark it

<mustafaj> what's your blogs url?

<gcasella> I have two at the moment, one of them specific to SBR gcasella.blogspot.com and one personal one at gcasella.wordpress.com 

<mustafaj> cool i'll check em out.  time for food ;) cheers

<gcasella> Take care!

<mustafaj> you too

--------------------------------------------------------
Gian-Luca Casella