Difference between revisions of "Checkdeps"

From PDP/Grid Wiki
Jump to navigationJump to search
 
Line 28: Line 28:
 
* a cron job /etc/cron.d/make-yum-repos runs the above script once per hour in quiet mode
 
* a cron job /etc/cron.d/make-yum-repos runs the above script once per hour in quiet mode
  
Note: the CentOS distributions already provide repository metadata, but in a different directory than checkdeps would expect. The latter expects to find directory repodata in the directory containing the rpms, whereas the distribution provides it one level higher in the file system hierarchy. Recreating the metadata is time consuming because of the large number of packages, so symlinks have been created in the rpms directory.
+
'''Note: the CentOS distributions already provide repository metadata, but in a different directory than checkdeps would expect. The latter expects to find directory repodata in the directory containing the rpms, whereas the distribution provides it one level higher in the file system hierarchy. Recreating the metadata is time consuming because of the large number of packages, so symlinks have been created in the rpms directory.'''
  
  

Latest revision as of 23:04, 19 March 2012

Checkdeps is a tool from the Quattor suite that allows to verify that all package dependencies are satisfied before deploying a new profile on the node. Details about this tool are on the Quattor web site: http://sourceforge.net/apps/mediawiki/quattor/index.php?title=Checkdeps

Checkdeps is particularly useful when preparing the initial installation of a new OS distribution or type of middleware, which typically requires numerous attmepts before all dependencies are satisfied. Every attempt consists of the following steps:

 change templates -> compile -> deploy to node -> SPMA verifies dependencies -> failure, please try again

This is a boring and slow process to go through and it is certainly not fun!

Using checkdeps, the steps are:

 change templates -> compile -> checkdeps verifies dependencies

This worklow not only contains fewer steps, checkdeps can even suggest which lines of Pan code to add to resolve failing depencies (but please, do not discard brain when checkdeps makes suggestions!).

Checkdeps does all magic via calls to the Yum API. That requires Yum repositories on the repository server. The next section describes how to set these up.


Server

The server is the host holding the software repositories. Currently, this is also the Quattor server stal.

All software repositories that can be used by the templates in the configuration database have to prepared so that yum can use them. To create a yum repository in directory /my/repo, execute

 createrepo /my/repo

This will create a new directory /my/repo/repodata which contains the repository contents.

When new packages are added to the repositories, the repository metadata should be updated. That can be done via createrepo --update (only processing the changes) or createrepo -C (rebuilding if anything changed).

We use ~30 repositories, so the update task has been automated:

  • the configuration file /project/quattor/etc/ndpf-yum-repos contains a list of directories that should be updated; 1 directory per line
  • the script /project/quattor/bin/make-yum-repos reads the above configuration file and creates the repositories if needed (using option -C for createrepo).
  • a cron job /etc/cron.d/make-yum-repos runs the above script once per hour in quiet mode

Note: the CentOS distributions already provide repository metadata, but in a different directory than checkdeps would expect. The latter expects to find directory repodata in the directory containing the rpms, whereas the distribution provides it one level higher in the file system hierarchy. Recreating the metadata is time consuming because of the large number of packages, so symlinks have been created in the rpms directory.


Client

If the server has been prepared, the client can be configured with the file $HOME/.quattor/checkdeps.conf:

[config]
generate_repos=False
output_pan=False
debug_level=0
profile_dir=/home/ronalds/src/ndpf-scdb/conf/build/xml
match=*.nikhef.nl.xml
match=*.xml

[yum]
root=/tmp/ronalds/yumroot

Notes:

  • The client needs access to the software repositories. At Nikhef, access to the the management network is required. In practise, that means a VPN tunnel or using the client from stal (either as ordinary user or ndpfmgr).
  • The client code has only been tested at linux clients.
  • The field root point to a local working directory. Ensure that this directory exists before running checkdeps and create it on the local machine, not on an NFS mount (unless you've got plenty of time).

Then run the tool to verify the dependencies. Below is an example of a successful verification of the object tbn17.nikhef.nl:

$ checkdeps -l $L/build/xml -x tbn17.nikhef.nl.xml
checkdeps: 1 profile(s) to check in /user/ronalds/src/ndpf-scdb/conf/build/xml
checkdeps: tbn17.nikhef.nl.xml - starting check
checkdeps: tbn17.nikhef.nl.xml - profile seems OK

The following example shows a missing package and the suggestion that checkdeps gives:

$ checkdeps -l $L/build/xml -x tbn02.nikhef.nl.xml
checkdeps: 1 profile(s) to check in /user/ronalds/src/ndpf-scdb/conf/build/xml
checkdeps: tbn02.nikhef.nl.xml - starting check
checkdeps: tbn02.nikhef.nl.xml - YUM wants to add the following 1 package(s): 

Package                        Version              Arch     Needed by
=================================================================================
apr                            1.2.7-11.el5_3.1     x86_64   apr-util-1.2.7-7.el5_3.2.x86_64


checkdeps: Pan snippet to add missing packages: 

"/software/packages"=pkg_repl("apr","1.2.7-11.el5_3.1","x86_64");

checkdeps: tbn02.nikhef.nl.xml - problem found with profile