Difference between revisions of "Checkdeps"
(2 intermediate revisions by one other user not shown) | |||
Line 1: | Line 1: | ||
− | Checkdeps is a tool from the Quattor suite that allows to verify that all package dependencies are satisfied before deploying a new profile. | + | 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 | 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 | 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!). | 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!). | ||
Line 8: | Line 13: | ||
− | Server | + | == Server == |
The server is the host holding the software repositories. Currently, this is also the Quattor server stal. | The server is the host holding the software repositories. Currently, this is also the Quattor server stal. | ||
Line 23: | 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.''' |
− | Client | + | == Client == |
If the server has been prepared, the client can be configured with the file $HOME/.quattor/checkdeps.conf: | If the server has been prepared, the client can be configured with the file $HOME/.quattor/checkdeps.conf: | ||
Line 37: | Line 42: | ||
match=*.nikhef.nl.xml | match=*.nikhef.nl.xml | ||
match=*.xml | match=*.xml | ||
− | + | ||
[yum] | [yum] | ||
root=/tmp/ronalds/yumroot | root=/tmp/ronalds/yumroot |
Latest revision as of 22: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