Difference between revisions of "BCCD:Packages"

From Earlham CS Department
Jump to navigation Jump to search
(On a running BCCD)
 
(23 intermediate revisions by the same user not shown)
Line 1: Line 1:
=Building a Package and Adding it to the Repository=
 
 
The BCCD has a set of downloadable packages, available via the <code>list-packages</code> command (as root) on a running copy of the BCCD.  The instructions that follow explain the process of adding a package to the repository that <code>list-packages</code> uses.  The BCCD package system simply unpacks the specified tarball in /usr/local, so a "package" can contain anything from a set of binaries to a collection of documentation files in text, html, or some other format (e.g., a curriculum module).
 
The BCCD has a set of downloadable packages, available via the <code>list-packages</code> command (as root) on a running copy of the BCCD.  The instructions that follow explain the process of adding a package to the repository that <code>list-packages</code> uses.  The BCCD package system simply unpacks the specified tarball in /usr/local, so a "package" can contain anything from a set of binaries to a collection of documentation files in text, html, or some other format (e.g., a curriculum module).
==On a running BCCD==
+
 
These instructions assume that you '''start as root''' in ~, on a running copy of the BCCD.
+
==Building a package in the BCCD CVS tree==
 +
* Obtain a copy of the BCCD source from <code>bccd.cs.uni.edu</code> (contact Paul Gray for access), then
 +
* See the instructions for creating a new package at http://lnxbbc.org/garchitecture.html
 +
* After setting up the new package, run <code>make tarball</code> and note the location of the resulting file
 +
 
 +
==Building a package on a running BCCD==
 +
One should use this method for building a package only if all else fails.  These instructions assume that you '''start as root''' in ~, on a running copy of the BCCD.
 
* Build the source:
 
* Build the source:
 
<pre>
 
<pre>
Line 24: Line 29:
 
cd
 
cd
 
</pre>
 
</pre>
* Sign the package with GPG (assuming you have access to a [[BCCD#Generating_a_GPG_Key_to_Sign_Packages|valid private key]]):
 
<pre>
 
gpg --detach somepkg.tar.gz
 
gpg --verify somepkg.tar.gz.sig # does this do what I think it does?
 
</pre>
 
* Create the package directory on <code>bccd.cs.uni.edu</code> for x86 or <code>cluster.earlham.edu</code> for PPC, upload the package and signature, and add the package to <code>packages.txt</code>:
 
<pre>
 
#for x86
 
ssh bccd.cs.uni.edu mkdir /var/www/packages/ppc/2.2/somepkg
 
scp somesource.tar.gz* bccd.cs.uni.edu:/var/www/packages/ppc/2.2/somepkg
 
ssh bccd.cs.uni.edu echo "somepkg some package description" >> /var/www/packages/ppc/2.2/packages.txt
 
#for ppc
 
ssh cluster.earlham.edu mkdir /cluster/bccd-packages/ppc/2.2/somepkg
 
scp somesource.tar.gz* cluster.earlham.edu:/cluster/bccd-packages/ppc/2.2/somepkg
 
ssh cluster.earlham.edu echo "somepkg some package description" >> /cluster/bccd-packages/ppc/2.2/packages.txt
 
</pre>
 
(notice the tab between the package name and description on the last line)
 
  
 
===Example: Building GROMACS===
 
===Example: Building GROMACS===
Line 76: Line 64:
 
</pre>
 
</pre>
 
Now you should have a working copy of GROMACS in <code>/usr/local</code>.  Enjoy!
 
Now you should have a working copy of GROMACS in <code>/usr/local</code>.  Enjoy!
 +
 +
==Adding a package to the PPC repository on hopper==
 +
These instructions assume that you are operating as root on hopper.
 +
 +
* Create a directory for your package:
 +
<pre>
 +
cd /cluster/bccd-packages/ppc/2.2/
 +
mkdir somepkg
 +
</pre>
 +
 +
* Copy the tarball (generated by one of the above two methods) into this directory
 +
 +
* Sign the package with GPG.  The private key trusted by the BCCD resides in <code>/root/.gnupg</code> on hopper, so you must sign packages from the root account.  The password for the key is the secure cluster password.
 +
<pre>
 +
cd somepkg
 +
gpg --detach somepkg.tar.gz
 +
gpg --verify somepkg.tar.gz.sig # does this do what I think it does?
 +
</pre>
 +
 +
* Add the package to <code>packages.txt</code>
 +
<pre>
 +
cd ..
 +
echo "somepkg some package description" >> packages.txt
 +
# notice the tab between the package name and description
 +
</pre>
 +
 +
==Adding a package to the x86 repository on <code>bccd.cs.uni.edu</code>==
 +
* Copy the tarball (generated by one of the above two methods) to <code>hopper</code>
 +
 +
* Sign the package with GPG.  The private key trusted by the BCCD resides in <code>/root/.gnupg</code> on hopper, so you must sign packages from the root account.  The password for the key is the secure cluster password.
 +
<pre>
 +
gpg --detach somepkg.tar.gz
 +
gpg --verify somepkg.tar.gz.sig # does this do what I think it does?
 +
</pre>
 +
 +
* <code>scp</code> the tarball and its corresponding <code>.sig</code> file to <code>bccd.cs.uni.edu:/var/www/packages/2.2/packagename</code> (this may change to <code>bccd.cs.uni.edu:/var/www/packages/i386/2.2/packagename</code> at some point).  If you need an account on this machine and/or access to this directory, contact Paul Gray.
 +
 +
* Add the package to <code>packages.txt</code> (in the top level packages directory):
 +
<pre>
 +
echo "somepkg some package description" >> packages.txt
 +
# notice the tab between the package name and description
 +
</pre>
  
 
==Generating a GPG Key to Sign Packages==
 
==Generating a GPG Key to Sign Packages==
 +
'''This has already been done in the root account on hopper.  As of May 17, 2006 we will all use this key to sign packages.'''
 +
 
===Generating the Key===
 
===Generating the Key===
 
'''Quick Guide.'''  For the far more detailed instructions from which these commands have been extracted, see [http://www.nmlug.org/faqs/gen-gpg-key.html How to Generate a GPG key].
 
'''Quick Guide.'''  For the far more detailed instructions from which these commands have been extracted, see [http://www.nmlug.org/faqs/gen-gpg-key.html How to Generate a GPG key].
Line 89: Line 121:
 
</pre>
 
</pre>
 
When finished, <code>key.gpg.asc</code> is your public key (if you're going to sign packages with this key in the distribution BCCD, add it to the image as a trusted key), and <code>revoke.gpg.asc</code> is your revocation certificate, should you need to revoke this key pair.
 
When finished, <code>key.gpg.asc</code> is your public key (if you're going to sign packages with this key in the distribution BCCD, add it to the image as a trusted key), and <code>revoke.gpg.asc</code> is your revocation certificate, should you need to revoke this key pair.
 +
 
===Making the Key Authoritative===
 
===Making the Key Authoritative===
 
To make your new key authoritative in the BCCD image, you need to append it to <code>bccd/archive/garpkg/files/gar-keys.asc</code>.
 
To make your new key authoritative in the BCCD image, you need to append it to <code>bccd/archive/garpkg/files/gar-keys.asc</code>.
Line 116: Line 149:
 
tmcnulty@c15:~/bccd/archive/garpkg/files$ vim ../checksums #remove the old checksum line
 
tmcnulty@c15:~/bccd/archive/garpkg/files$ vim ../checksums #remove the old checksum line
 
</pre>
 
</pre>
Now, [[BCCD:PowerPC#Building_the_BBC-PPC_ISO|rebuild the ISO]], [[BCCD#Building_a_Package_and_Adding_it_to_the_Repository|upload some signed packages to the repository]], and give <code>list-packages</code> a try!
 

Latest revision as of 12:36, 18 May 2006

The BCCD has a set of downloadable packages, available via the list-packages command (as root) on a running copy of the BCCD. The instructions that follow explain the process of adding a package to the repository that list-packages uses. The BCCD package system simply unpacks the specified tarball in /usr/local, so a "package" can contain anything from a set of binaries to a collection of documentation files in text, html, or some other format (e.g., a curriculum module).

Building a package in the BCCD CVS tree

  • Obtain a copy of the BCCD source from bccd.cs.uni.edu (contact Paul Gray for access), then
  • See the instructions for creating a new package at http://lnxbbc.org/garchitecture.html
  • After setting up the new package, run make tarball and note the location of the resulting file

Building a package on a running BCCD

One should use this method for building a package only if all else fails. These instructions assume that you start as root in ~, on a running copy of the BCCD.

  • Build the source:
tar xzf somesource-*.tar.gz
cd somesource-*
./configure --prefix=/usr/local
make
  • Install the binaries in /usr/local, but archive its current contents first so they don't get packaged up too:
mkdir ~/local
mv /usr/local/* ~/local
make install
  • Package up /usr/local, clean up, and move the old contents of /usr/local back where they belong:
cd /usr/local
tar czf ~/somepkg.tar.gz .
rm -rf /usr/local/*
mv ~/local/* /usr/local
cd

Example: Building GROMACS

  • Setup your environment:
export LDFLAGS="-L/lib/gcc-lib/powerpc-lnxbbc-linux -L/usr/local/lib -L/mpich/lib"
export CPPFLAGS=-I/usr/local/include
export LD_LIBRARY_PATH=/lib/gcc-lib/powerpc-lnxbbc-linux/:/mpich/lib
export PATH=$PATH:/mpich/bin
  • Fix BCCD lib bug (necessary as of 6/20/2005):
mkdir -p /tmp/snapshot.build/staging/singularity/image
ln -s /lib /tmp/snapshot.build/staging/singularity/image/lib
  • Install necessary headers:
list-packages #select fixpackages and hit OK
  • Build FFTW and GROMACS:
cd fftw-* # 2.1.5 works
./configure --enable-float --enable-type-prefix --enable-mpi --prefix=/usr/local
make -j2
make install
make distclean
./configure --enable-type-prefix --enable-mpi --prefix=/usr/local
make -j2
make install
cd ../gromacs-* # 3.2.1 works
make distclean
./configure --enable-mpi --enable-shared --prefix=/usr/local --exec-prefix=/usr/local
make -j2
make install

Now you should have a working copy of GROMACS in /usr/local. Enjoy!

Adding a package to the PPC repository on hopper

These instructions assume that you are operating as root on hopper.

  • Create a directory for your package:
cd /cluster/bccd-packages/ppc/2.2/
mkdir somepkg
  • Copy the tarball (generated by one of the above two methods) into this directory
  • Sign the package with GPG. The private key trusted by the BCCD resides in /root/.gnupg on hopper, so you must sign packages from the root account. The password for the key is the secure cluster password.
cd somepkg
gpg --detach somepkg.tar.gz
gpg --verify somepkg.tar.gz.sig # does this do what I think it does?
  • Add the package to packages.txt
cd ..
echo "somepkg	some package description" >> packages.txt
# notice the tab between the package name and description

Adding a package to the x86 repository on bccd.cs.uni.edu

  • Copy the tarball (generated by one of the above two methods) to hopper
  • Sign the package with GPG. The private key trusted by the BCCD resides in /root/.gnupg on hopper, so you must sign packages from the root account. The password for the key is the secure cluster password.
gpg --detach somepkg.tar.gz
gpg --verify somepkg.tar.gz.sig # does this do what I think it does?
  • scp the tarball and its corresponding .sig file to bccd.cs.uni.edu:/var/www/packages/2.2/packagename (this may change to bccd.cs.uni.edu:/var/www/packages/i386/2.2/packagename at some point). If you need an account on this machine and/or access to this directory, contact Paul Gray.
  • Add the package to packages.txt (in the top level packages directory):
echo "somepkg	some package description" >> packages.txt
# notice the tab between the package name and description

Generating a GPG Key to Sign Packages

This has already been done in the root account on hopper. As of May 17, 2006 we will all use this key to sign packages.

Generating the Key

Quick Guide. For the far more detailed instructions from which these commands have been extracted, see How to Generate a GPG key.

gpg --gen-key
gpg --fingerprint
gpg --export --armor user@host.org > key.gpg.asc
gpg --keyserver wwwkeys.us.pgp.net --send-keys user@host.org
gpg --gen-revoke user@host.org > revoke.gpg.asc
chmod 400 revoke.gpg.asc

When finished, key.gpg.asc is your public key (if you're going to sign packages with this key in the distribution BCCD, add it to the image as a trusted key), and revoke.gpg.asc is your revocation certificate, should you need to revoke this key pair.

Making the Key Authoritative

To make your new key authoritative in the BCCD image, you need to append it to bccd/archive/garpkg/files/gar-keys.asc.

  • First, grab a copy of your key fingerprint:
tmcnulty@bccd:~$ gpg --fingerprint
/home/tmcnulty/.gnupg/pubring.gpg
---------------------------------
pub  1024R/825ADB6E 2005-06-14 Tobias McNulty (BCCD) <tmcnulty@ppckernel.org>
     Key fingerprint = 47BB 9126 6FE0 866D 11C0  AB3E 499D 4547 825A DB6E
  • Next, append the line starting with "pub" to gar-keys.asc:
tmcnulty@c15:~/bccd/archive/garpkg/files$ cat >> gar-keys.asc

pub  1024R/825ADB6E 2005-06-14 Tobias McNulty (BCCD) <tmcnulty@ppckernel.org>

<control-d>
  • Now, append gar-keys.asc with the contents of key.gpg.asc:
tmcnulty@c15:~/bccd/archive/garpkg/files$ cat ~/key.gpg.asc >> gar-keys.asc
  • You'll need to update the checksum for gar-keys.asc:
tmcnulty@c15:~/bccd/archive/garpkg/files$ md5sum gar-keys.asc >> ../checksums
tmcnulty@c15:~/bccd/archive/garpkg/files$ vim ../checksums #remove the old checksum line