The Linux Foundation

 
Appchk-glue

From The Linux Foundation

Appchk-glue is a perl script that allows entire RPM or dpkg packages to be analysed with appchk. It also supports 'tarball installations'. It subsumes a number of standalone scripts previously develped by a number of parties for portions of this task. The RPM or dpkg's can either be installed on the system or the tool can be pointed at a .rpm or .deb package to analyse. In order to avoid false positives we added a option to appchk called '-i' which will prevent recursion within appchk into shared libraries included in the -L list to appchk. Appchk-glue will in turn analyse all binaries in a package, including shared libraries shipped with the package.

Contents

TODO

  • Feedback on script
  • Apply appchk patch for -i option to bzr
  • Apply appchk-glue to bzr
  • Include appchk-glue in LSB Application Testkit.

Usage

This is the script used for analysing installed applications or complete package archives for missing symbols in reference to the LSB GUI library baseline.

Contents

  • Installation - what needs to be where for this tool to function
  • Usage - how to use the tool
  • Installation Types - different procedures for different install methods
  • Collating Data - combining data from multiple sources
  • Rerunning Analysis
  • Troubleshooting
  • Notes - things that have happened to this analysis tool

Installation

There are two requirements for this tool to function:

1) The appchk-glue.pl script is in a writable directory, this will be termed the "installation directory".

2) An appchk binary supporting the undocumented "-i" switch in the path.

Something which works well if multiple version of appchk is available is to copy them all into a suitable location (eg /usr/local/bin) but with different names, then create a symlink to the right version.

Usage

This tool is used to analyse either binaries, or RPM files after installation. In either case, the application is analysed by:

1) creating a subdirectory under the installation directory named for the application to be analysed. This subdirectory will be termed the "analysis directory"

2) creating a text file in the analysis directory which lists the files to be used as source material for analysis. The precise contents of this file are discussed below in the section "Installation Types", but the root name of the text file must match then name of the analysis directory.

Once that has been done, the tool itself is started by changing to the installation directory and running the command line:

   ./appchk-glue.pl

This script will walk across the set of subdirectories looking for source listing files, running analyses where necessary, and combining analysis information from all the directories which it finds. Since the analysis process can be lengthy, the script will only run an analysis if it does not find a file with the extension ".l2out".

The script will generate multiple files, the main ones to note are:

  analysis_report.out 

symbols that are in use yet not within lsb core

  *.misslib 

libs that are in use yet not within lsb core

Installation Types

"Installation" may be as simple as unpacking a tarball in an arbitrary location, or there may be a custom installer. For the purposes of this analysis, however, we shall consider three kinds of installer: those that use RPM or dpkg, and those that do not.

RPM Installers

The process with an RPM installer is as follows:

1) create a text file in the analysis directory called

   <application name>-rpm.list

Note that the root name of the text file must match then name of the analysis directory

2) On each line of the file write either the name of the package in the RPM database or the full path to a packaged rpm file. If you use the rpm package atabase name you will need to have previously installed the package using the RPM tool of your choice. You can determine the rpm package name using this command:

   rpm -q <application name>

If the full path to a .rpm file is specififed. The .rpm's file contents will be extracted into a temp directory for analysis.

dpkg Installers

1) create a text file in the analysis directory called

   <application name>-deb.list

Note that the root name of the text file must match then name of the analysis directory

2) On each line of the file write either the name of the package in the dpkg database or the full path to a packaged .deb file. If you use the .deb package atabase name you will need to have previously installed the package using the dpkg tool of your choice. You can determine the dpkg package name using this command:

  dpkg --list <application name>

If the full path to a .deb file is specififed. The .deb's file contents will be extracted into a temp directory for analysis.

Non-RPM Installers

The process with any other installer is as follows:

1) install the application using the method described in the instructions which come with the binaries.

2) create a text file in the analysis directory called

   <application name>-bin.list

Note that the root name of the text file must match then name of the analysis directory

3) write in this file the paths of application binaries associated with the application. For some applications this may just be the binary itself. For othersthere may be hundreds of libraries attached.

One method which yields usable results to find the executables is to use find to search for files in the application installation location which are executable. The command

       find <app inst locn> -type f -perm +111

... will find all files in the given directory with executable permission. Note the use of the "-type" qualifier, since otherwise you will end up with directories too.

It is possible, even likely, that not all of the files present in this list will be ones which are of interest. Many scripts will legitimately be executable, and some installers will give everything executable permissions (particularly if the installation image has been prepared on Windows). The files we are interested in are:

a) ELF executables - these must be executable ELF binaries. Finding these can be achieved by looking at the first line: those of interest will not have a shebang line at the start (eg a script which starts "#!/user/bin/perl" is not of interest).

An easier method is to use the "file" command to identify the type of the file. The following command will extract only ELF binaries:

   find <app locn> -type f -perm +111 -exec file {} \; | grep 'ELF 32-bit' | cut -d':' -f1 > executables

b) ELF libraries - these have an extension containing '.so', sometimes with a version number attached.

Note that some applications will install libraries which do not have executable permissions set.

Collating Data

There are applications with specific system requirements, such as that the system uses a Xeon processor or that there is a dependency on a certain application. If this is the case, then install the gapanalysis directory on a system which satisfies the requirements, then copy the analysis directories which are output back to the machine where the collation is to be done. The script will combine all of the data as necessary.

Rerunning Analysis

There may be a need to rerun analysis on one or more applications. There are several ways to manage this:

1) delete the .l2out file. This is the simplest, but can produce variable results.

2) delete everything except the .list file. The surest way, but time consuming and error prone to do manually.

3) use the "-c" script option. This implements /2/ for any directories supplied on the command line, or for all directories if a force flag is supplied. The usage text for this script is as follows:

   ./appchk-glue.pl -c [-f] [<dir> ...]

... where <dir> is an optional list of directories to clean the results files from, and the -f flag is used to force cleaning of all data directories.

The cleaning process will follow these rules:

1) looks for directories in the nominated set containing exactly one .list file whose prefix matches the containing directory name.

   eg  fred/fred-bin.list would match
       fred/harold-bin.list would not match
       fred/frederica-bin.list should not match
       fred/fred-bin.list and fred/fred-rpm.list should not match
   A file called SAVE in a directory will always block a match.

2) deletes anything in those directories which match which is not a .list


[Article] [Discussion] [View source] [History]