1,885
edits
Changes
no edit summary
You will make a brief (3-5 minute) presentation of your project plans on '''Thursday, February 9'''.
= Week 5 (Feb 7) =
== Tuesday ==
=== Signing RPM packages ===
An RPM signature, like the digital signature used on many other software-signing systems, is a private key encryption of a checksum. RPM uses the GPG libraries for signing.
# Create a GPG key: <code>gpg --gen-key</code>
# Add the e-mail address associated with your gpg key to the <code>%_gpg_name</code> macro in <code>~/.rpmmacros</code> -- the line will look like this: <code>%_gpg_name "<i>e-mail-address</i>"</code>
# Find (or make) some packages to put in your repository. Make sure that the epoch-version-release is higher than that of any package with the same name in the Fedora repositories.
# Sign those packages with: <code>rpm --addsign <i>packagefile</i></code>
=== Creating a YUM repository ===
A yum repository is just a directory of packages and some metadata.
To create a yum repository:
# Create a directory that can be served. The protocol used to serve that directory could be http, ftp, nfs, or something else (the files can be served by putting them on a DVD too!). For http, create the directory within <code>/var/www/html</code>
# Put your signed packages in that directory.
# Create the repository metadata for that directory: <code>createrepo <i>/name/of/directory</i></code> (typically: <code>createrepo . </code>)
Notice that the repository metadata will be placed in a subdirectory named <code>repodata</code>
=== Testing ===
# Create a new repository file in <code>/etc/yum.repos.d</code> by copying and modifying an existing file in that directory. Keep <code>gpgcheck=1</code> but comment out the <code>gpgkey</code> file.
# Confirm that you cannot install from that repository using yum.
# Uncomment the <code>gpgkey</code> line, and point it to a new file within <code>/etc/pki/rpm-gpg/</code>
# Create that file by running (as your regular user): <code>gpg --export --armour <i>e-mail-address</i></code> and saving the output to the new filename (note: you'll need to be your regular user to perform the export, but the root user to install the file).
# Confirm that you can now install from your repository. You should be asked whether you wish to import the key for your repo the first time you use a package from that repo.
=== Creating a Repository-release RPM ===
To make it easier for users to access your repository, create a RPM containing:
# Your repo file
# Your GPG key
You can link to this repository-release RPM from a web page, and users can install access to your repository by simply clicking on that link. You can also include this package in a [[:fedora:Spin|Spin]] or [[:fedora:Remix|Remix]]. If you ever need to move your repository's location or make other adjustments, you can provide an updated repository-release package which will be installed when your users perform a <code>yum update</code>.
Take a look at the [http://rpmfusion.org/ RPMFusion] release RPM for an example.
=== ToDo ===
Lab
# Create a signed repository containing your RPM package.
# Create an RPM package that will install your repository configuration file and the key (repository-release package).
# Test it.
# Blog about this lab, and include a link to your repository-release package and the repository URL.
== Thursday ==
=== Project Plan Presentations (0.0) ===
* Project pages are due. Link from the ''Projects'' column of the [[Winter 2012 SBR600 Participants]] table to a page for your project; use the [[Sample Project]] template for your project page, and fill in as much detail as possible.
* Be prepared to give a professional, detailed, but very brief (2- to 4-minute) presentation on your project plan. Include:
** Your approach to the problem.
** Contacts and resources you've identified.
** Your plans for each release. Note that at each release you will be expected to actually '''release''' something -- an RPM, a script, test results -- as appropriate to your project. Identify what you are intending to release at each stage:
*** 0.1 Release - proof of concept
*** 0.2 Release - initial functionality
*** 0.3 Release - tested and usable
** Challenges and potential pitfalls that you have identified, and your approach to mitigating those challenges so that you can complete your project on time regardless of things beyond your control.
** Time for a brief Q&A/Feedback session at the end.
<!--