Creating a meta-package

We will be creating a meta-package today, because this is one of simplest kind of packages to create, and can be extremely useful for installing a bunch of other packages. I want to create a package I can install, that will let me communicate in the modern world. I think I’ll call it “danny-talkfoo”.

I create my packages in ~/packages/sources, so I will create a new folder in there for my new meta-package. Package directories have a folder that contain information, and customization to the package, this folder is named DEBIAN. For our talkfoo-danny package, we only need a single file, ~/packages/sources/danny-talkfoo/DEBIAN/control. This is the contents of my control file:

Package: danny-talkfoo
Version: 0.1
Section: main
Priority: optional
Architecture: all
Depends: irssi, irssi-fish, mutt, mutt-patched, muttprint, gnupg
Maintainer: Daniel Bond
Description: A metapackage for Dannys usual communication tools (irc, mail)
 This package includes the mailclient mutt with some addons, gnupg for
email encryption, and irssi for Internet Relay Chat

And thats it. The important points here are:

• Depends – Describes what packages this package are required. This is what makes our meta-package do anything when installed.
• Long description – Note how the last line is prefixed with a single space, it means it’s the start of the long package description.
• Version – If you change the package, increase the version, so people using it will see the updates.

To create the package, simply type the following commands:

# cd ~/packages/sources
# dpkg -b danny-talkfoo
# dpkg-deb: building package `danny-talkfoo' in `danny-talkfoo.deb'.

Cool, that was easy! Let’s continue to creating our own repository.

Creating a repository

I presume that you are familiar with Gnu Privacy Guard (GnuPG/GPG). Apt-repositories are normally signed with GnuPG, to verify the package provider. Strictly speaking, it is not necessary to sign your repository with GPG, but it is very good practice – and apt will complain if you don’t.

The GnuPG commands you need to know are:

• gpg –gen-key
• gpg –export -a

Once you have created the key you want to sign packages as, you will need the following packages, to create the repository:

• lighttpd
• reprepro

In your ~/packages directory, create the following folders:

# mkdir repo
# cd repo
# mkdir conf incoming

Ok, you are doing well! Good job! We need to configure reprepro, to understand our setup. Create the following configuration file in ~/packages/repo/conf/distributions:

Origin: http://www.danielbond.org
Label: Bond's apt repository
Suite: stable
Codename: lenny
Architectures: amd64 i386
Components: main
Description: A selection of meta-packages, free to use, without charge!
SignWith: your-gpg-identity@yourdomain.org

If you want to host several Debian releases, copy-paste this entry in the distributions-file, and change “codename” for each entry, to the appropriate value.

Populating the repository

For now we will just be adding the simple package we created earlier. Reprepro maintains database files over what it’s indexed in the repository, make sure to use the reprepro interface to maintain your repository (removing or replacing files, ie), to keep your repository healthy. To add the package, type:

# cd ~/packages
# reprepro -b ./repo includedeb lenny ./sources/danny-talkfoo.deb
 exporting indicies...
#

Reprepro has no populated ~/packages/repo/dists and ~/packages/repo/pool with files for us to publish in our repository. We can now create a network apt-mirror, using FTP or HTTP, etc. I will just be using a simple webserver, lighttpd, but any old webserver would do.

Publishing the repository with Lighty

# cd /var/www && rm /var/www/index.lighttpd.html
# ln -s /home/db/packages/repo/dists/
# ln -s /home/db/packages/repo/pool/
# if ! grep dir-listing.show-header /etc/lighttpd/lighttpd.conf
    then echo "dir-listing.show-header = \"enable\"" >> /etc/lighttpd/lighttpd.conf
 fi
# /etc/inet.d/lighttpd reload
# cat << EOF > /var/www/HEADER.txt

> Danny debian packages
> =====================
>
> The GPG key can be imported from http://keys.yourdomain.com/mainrepo.gpg.
> EOF 
# gpg --export -a "your-gpg-identity@yourdomain.org" > /var/www/mainrepo.gpg

Now you can add your repository to apt!

Apparently, Irssi-FiSH version 1.x works better on amd64 platform. Therefor I went with the 1-RC5 (release candidate 5) version of it instead.

To make FiSH compile, you need to build MIRACL first, then copy miracl.a to the directory with FiSH source in it. You will have to tweak MIRACL and irssi’s Makefile’s, to make sure everything is being built with GCC-flag “-fPIC”, so the shared libraries will succeed.

When writing this article, I learned how to make a “secure apt repository”. I’ll try to keep it up to date, with the latest irssi-fish.

Binary package

If you are lazy like me, and just want something that works, do the following:

# wget http://www.danielbond.org/DB-GPG.asc
# apt-key add DB-GPG.asc
# gpg –import DB-GPG.asc
# rm DB-GPG.asc
# echo ‘deb http://www.danielbond.org/debian/ lenny main’ >> /etc/apt/sources.list
# aptitude update && aptitude install irssi-fish

BSD Installer

DragonFlyBSD ships with the BSDInstaller. You will find it familiar if you have previously used PFSense or FreeSBIE. The installer that comes with DragonFlyBSD, can be used to instantly make any computer an install-server. It is very fast and straight forward to use, and it lets you choice whether you want to set details like root-password, hostname and network settings – which can sometimes be nice to skip for a quick test.

The installer is also a LiveCD, that lets you log in to the system and test it, before installing it. To install it you simply log in as user “installer”, and you are presented with the installation menu. If you have flash video support, here is a clip of a DragonFlyBSD installation:

Videoclip of DragonFlyBSD installer

NRELEASE build system

The git-based release system, called nrelease. It trivializes the build-aspects of DragonFlyBSD. It lets the user generate custom installers and installations, with easy package-selection. It lets users build install ISO, LiveCD ISO and usb-stick images. Cool!

The nrelease system is in /usr/src/nrelease. You will first need to checkout a copy of the DragonFlyBSD operating system, this can be done efficiently with the git revision control management tools. To do the initial checkout do the following:

df# cd /usr
df# make git-clone 
df# make help 

The command above will give you latest HEAD, you might want to check out a release, unless you are a developer. To get finer control, you can use the git-tool directly. If you are in the scandinavian region, you could use my mirror, which is updated from crater.dragonflybsd.org:

df# git clone -o blazefire git://blazefire.danielbond.org/dragonfly.git /usr/src 

You will get an error, if “/usr/src” already exists. If you are going to mess about in /usr/src, it’s a good idea with some basic git knowledge.

Once you have obtained the source, you can mess about with the nrelease system in /usr/src/nrelease, here are some examples from “make help”:

df# make help
make [gui] release
make [gui] quick

These tools can be used to create LiveCDs or DVDs and USB-stick images.

Parallel kernel builds

DragonFlyBSD supports parallel kernel builds. Being mainly a FreeBSD user, this is one of the many small details I mentioned earlier, that makes DragonFlyBSD stand out. To use multiple jobs, you supply “-j <number>” argument to “make”, like you would in buildworld, and it’s completely safe!

rcNG improvements

Matt wrote a set of tools, which makes it more pleasurable to handle the rcNG system. Like FreeBSD, DragonFlyBSD also uses the rcNG system, to start and stop system daemons, like sendmail and OpenSSHD. It also controls daemons installed from pkgsrc (or ports in FreeBSD). Here are some examples of Matt’s tools:

Enabling OpenSSHD

df# rcrun enable sshd
df# rcrun start sshd
df# rcstop sshd && rcstart sshd && rcrestart sshd
df# rclist sshd
rcng_sshd=running
df# 

The way I use it, is by storing a groupOfNames-object in directory, which includes the DN’s I want to give access to. Here is an example object:

dn: cn=apacheadmins,ou=groups,dc=danielbond,dc=org
cn: apacheadmins
objectClass: groupOfNames
member: uid=danielb,ou=admins,ou=people,dc=danielbond,dc=org
member: uid=agent007,ou=outsourced,ou=people,dc=danielbond,dc=org

Then in my lighttpd configuration, I would include this group, in the list of allowed contexts:

auth.require = {
  ”/” => {
    ”method” => “basic”,
    ”realm” => “MI6 Agent login”,
    ”require” => “group=cn=apacheadmins,ou=groups,dc=danielbond,dc=org|user=coolguy|cn=awesome people,ou=groups,dc=danielbond,dc=org”
  } 
}

 The patch can be downloaded here: lighttpd-http_auth.c-ldap_group.diff.

The patch is based on benno’s patch for brgphy(4), but makes the hack specific for the BCM5708S chip. It seems like “mii_ticks” does not kick in at auto-negotiation phase.

David @ Broadcom (the maintainer of the FreeBSD drivers), mentioned an underlying problem, and wants to address this rather than applying hacks like this. Until the issue is fixed, applying this patch manually does the trick.

Link to patch: freebsd-brgphy.c-bce5708S-autonegotiation.diff.

As a side note, I suggest buying an bge(4) based card, rather than a bce(4) card, if you have a choice. Sepherosa Ziehau mentioned the firmware in bce(4) based cards are not as good, and is not near using the cards potential.

See kern/118238 for more info.