Installing the necessary packages.

	Note
	Since you don't have root rights, these packages have already been installed for you. The command is included here for those who wish to follow these instructions later with a computer of their own.

Environment Variables to aid dpkg-buildpackage

The program dpkg-buildpackage is used a lot in the exercises. In order to follow the instructions and greatly reduce the amount of editing you have to do, you need to set the following environment variables, e.g. in ~/.debpack:

DEBFULLNAME="Jurjen Bokma"
DEBEMAIL=j.bokma@rug.nl

export DEBFULLNAME DEBEMAIL
	    

which you then need to source from ~/.bashrc or the like:

	      [ -f ~/.debpack ] && . ~/.debpack
	    

GPG-setup

Signed packages are a Good Thing (tm). You may copy your actual keys from elsewhere to the practicum machine if you trust it, or you may generate a pair for the sake of the exercises like this:

	Warning
	The keypair you are creating here is for dummy purposes, but it consists of real keys. Do not upload the public key to a keyserver, or you will needlessly clutter the keyspace.

Typing fewer passwords

If you set up GPG, you will need to type your password a lot during packaging, unless you also set up gpg-agent in the environment (.e.g ~/.debpack):

if test -f $HOME/.gpg-agent-info && kill -0 $(cut -d: -f 2 $HOME/.gpg-agent-info) 2>/dev/null; then
    eval $(cat $HOME/.gpg-agent-info)
else
    eval $(gpg-agent --daemon --write-env-file $HOME/.gpg-agent-info)
fi
GPG_TTY=$(tty)

# GPG_AGENT_INFO is set from within $HOME/.gpg-agent-info, but still needs to be exported
export GPG_TTY GPG_AGENT_INFO
	    

Gpg needs to be notified that gpg-agent is available in ~/.gnupg/gpg.conf:

	      use-agent
	    

Now that ~/.debpack is finished, you want it to not only work in a new shell, but also in the current one, so you need to source it: . ~/.debpack. You can test whether the gpg-agent works by encrypting a file to yourself, removing the original and decrypting the encrypted file twice:

At the second decryption, gpg shouldn't ask for a password any more, and you should get your original file back.

You may also want to log off and back on again to verify that sourcing ~/.debpack from ~/.bashrc has the desired effect.

A virtual machine for root experiments

For experiments that require root rights, a virtual machine has been prepared for you in /opt/dpvh/dpvh.tgz. You cannot write in /opt, but you can copy it to /data:

	Note
	If you are doing these exercises at home or anywhere outside of our practicum environment, you may not have access to VMWare, nor to the Virtual Machine image that I prepared. In that case, you can make do with any Debian machine that you have root rights on.

1. 
     
       cd /data/scratch/
       mkdir test 
       cd test
       tar zxvf /opt/dpvh/dpvh.tgz
     
     
./dpvh/
./dpvh/vmware.log
./dpvh/dpvh-s001.vmdk
./dpvh/dpvh.vmx
./dpvh/vmware-0.log
./dpvh/dpvh.vmdk
./dpvh/dpvh.vmsd
./dpvh/nvram
  
     
       vmware -l&
     
   

   It is good custom on the practicum machines to create a directory called after your username in /scratch/data.

2. Click the button Open a Virtual Machine and browse to /data/username/scratch/dpvh/dpvh.vmx.

3. VMWare will complain that the location of the VM has changed, and that a new UUID must be created.

   Figure 2.1. VMWare asking to create a new UUID

   
   
   Create it.

4. Your VM will now boot. You can log in as root with password r00tm3, or as user john with password d03 and use sudo. The VM has OpenSSH running and can be reached from its host. So if you prefer ssh over the VMWare screen, you log in via VMWare once, call /sbin/ifconfig on the virtual machine so you can see its IP number, (192.168.216.128 in my case), and from then on use ssh john@192.128.216.128 from the vmware host to log in on the virtual machine.

A private local repository

The packages created in the exercises can be installed with dpkg. But in order to reap the full benefits of packages, the dependency resolver that comes with apt can be used. And to use that, the packages have to be in a repository. So on a system where you have root access, either the VM mentioned above or somewhere else, you can set up a trivial repository:

1. Log on to a machine where you have root access

   ssh john@192.128.216.128

2. Creating the directory structure

   mkdir -p /root/packages/binary /root/packages/source

3. Mentioning the repository to Apt

   Put a couple of lines like these in /etc/apt/sources.list:

   		  deb file:///root/packages binary/
   		  deb-src file:///root/packages source/
   		

4. Install dpkg-dev

   We need dpkg-scanbpackages and dpkg-scansources:

   
     
       apt-get install dpkg-dev
     
   

5. Adding packages

   Now every time you have a new package to test, you copy it to /root/packages/{binary,source}, and run a couple of commands, which you may want to script away in e.g. /root/newpackages:

   #!/bin/bash
   
   pushd /root/packages
   dpkg-scanpackages binary /dev/null | gzip -9c > binary/Packages.gz
   dpkg-scansources source /dev/null | gzip -9c > source/Sources.gz
   apt-get update
   popd
   		

   (Don't forget to chmod u+x /root/newpackages.)

A directory to work in

	Note
	Now get off the VM and back onto the real one.

I typically create a ~/packaging directory, and in it create directories for each new package I work on. So if I have programs foo, bar and baz on my workbench, the layout may look somewhat like this:

Note that versioned directories of a package are under a directory with the name of the package proper. For the exercises, this sort of layout is assumed, so on the packaging machine (not the VM), do: