In previous sections we have installed a build-server and several build-spaces so that we can build binary packages for use on various client systems. Whilst this will reduce installation time considerably when deploying these binary packages to clients and provide an opportunity to thoroughly test the newly built packages before deployment some of the management tasks we have been required to perform have been cumbersome to say the least.
In this section we shall install two packages which provide a collection of utility scripts designed to reduce the management burden when maintaining a build-server and the related build-spaces. As these packages are not currently available in the official portage repository we shall also install the layman overlay manager application and the Hacking Networked Solutions overlay for Gentoo Linux.
Before we can install the app-portage/layman package on the build-server we first need to install it in the relevant build-space. As you can see from the example below we do not require any of the optional checkout methods to be included when building the app-portage/layman package however if you wish to use other overlays then some of these may be required.
Once you are happy that the app-portage/layman package will be built with all the optional functionality you require it can be installed in the build-space as shown below. Once the build is complete you can exit the build-space and return to the build-server.
Before the binary package of the app-portage/layman package can be installed on the build-server we need to synchronise the testing package repository to the stable package repository. As we have not yet installed any tools to help with this we shall have to do it manually as shown below.
Now that the package repositories have been synchronised the app-portage/layman package can be installed on the build-server as shown below.
The final step in the installation of the app-portage/layman package is to edit the configuration file to point to the "live" repository as shown below. We have also modified the default location of the cache files to reduce clutter in the live/overlay directory and placed the layman managed make.conf file out of the way as it will not be used.
storage : /var/lib/layman
storage : /mnt/repositories/live/overlays
cache : %(storage)s/cache
cache : %(storage)s/cache/cache
make_conf : %(storage)s/make.conf
make_conf : /etc/layman/make.conf
With the layman application installed and correctly configured we can install the Hacking Networked Solutions overlay for Gentoo Linux which will provide access to the build-server and build-space utilities. As you can see from the example below before any overlays can be added a list of all available overlays has to be retrieved. Once this list has been downloaded the overlay can be added to the list of installed overlays. The layman application will automatically download the required files from our servers using the rsync application.
As usual, before the newly installed overlay can be used it must be copied to the testing repositories of the so it is accessible to the build-spaces. Once we have installed the build-server utilities this operation will be automated but for now we shall have to do it by hand as shown below.
Now that the required overlay has been made available in all the testing repositories we can return to the build-space and complete the installation of the layman application.
The only changes required to the configuration file are shown below. As you can see we have modified the storage location, as before, only this time it points to the copy of the overlays directory from the testing repository. We have also modified the cache location to match that set when configuring the "live" repository. There is no need to modify the make_conf entry as unfortunately the layman application cannot be used to manage the entries in this file, although they are easily maintained manually as shown later.
storage : /var/lib/layman
storage : /mnt/portage/overlays
cache : %(storage)s/cache
cache : %(storage)s/cache/cache
We can check that the layman application has been correctly configured, and that the overlay is available, before we add an entry to /etc/make.conf using the command below.
* hacking-gentoo [Rsync ] (rsync://rsync.mad-hacking.net/hacking-gentoo-overlay/ )
Once you are satisfied that the overlay is indeed installed and available to the build-space the /etc/make.conf file can be modified to include a reference to the overlay as shown in the example. If you wish to use additional overlays you will need to modify PORTDIR_OVERLAY entry accordingly by appending a space-separated list of the additional overlay paths.
PORTDIR=/mnt/portage/portage
DISTDIR=/mnt/portage/distfiles
PKGDIR=/mnt/portage/packages
OVLDIR=/mnt/portage/overlays
PORTDIR_OVERLAY="${OVLDIR}/hacking-gentoo"
As promised at the beginning of this guide we can finally install some utilities to assist in the management of the build-server and the build-spaces that we have created. The first package of interest provides a collection of utilities to assist in automating the upgrade process of a build-space. The example below shows a pretend merge of the app-admin/buildspace-scripts package in the 64bit server workspace.
Once you are happy that the app-admin/buildspace-scripts package will not install any dependencies you do not require, and that the dependencies which will be installed have the correct use-flags set, you can install the package as shown below.
As you can see from the output above one of the dependencies of the app-admin/buildspace-scripts package is a correctly configured Mail Transfer Agent (MTA), in the above example mail-mta/ssmtp. If you wish to receive email messages detailing the status of the update with the relevant log files as attachments it is critical that this package is correctly configured. It can be easily tested using the example command below which should send a totally blank message to the email address configured for the root user.
The second package of interest provides a collection of utilities to assist in synchronising and patching repositories as well as updating and maintaining a collection of build-spaces. The example below shows a pretend merge of the app-admin/buildserver-scripts package.
Once you are happy that the app-admin/buildserver-scripts package will not install any dependencies you do not require, and that the dependencies which will be installed have the correct use-flags set, you can install the package as shown below.
Before the binary package of the app-admin/buildserver-scripts package can be installed on the build-server we need to synchronise the testing package repository to the stable package repository. As we still have not yet installed any tools to help with this we shall have to do it manually one last time. Remember to exit from the build-space first as shown below.
The binary package of the app-admin/buildserver-scripts package can now be installed on the build-server as shown below.
In the next section we shall use the build-server and build-space utilities to automate many of the processes we have had to perform manually in this and previous sections.