TLP Whitelists and Blacklists

This section describes the whitelist and blacklist configuration files that are referenced in the TLP configuration file. The whitelist and blacklist files are where you designate those patches that are to be included or exclued during patch set creation. The files are located in the following directories:

• $BaseDirectory/conf/black_list.cfg

• $BaseDirectory/conf/white_list.cfg

For task-related information, see TLP Whitelists and Blacklists.

TLP Whitelist File Configuration

With the whitelist configuration, you can specify patches that should always be included in the patch set. In addition, this configuration can override recommendations from the Analyzer module. If you need to select a particular patch for a specific operating system, you can provide a selector in the second column within the whitelist. Lines starting with a hash mark (#) and empty lines are ignored. The known selectors are the keys of the system information, as returned by the Collector module. For more information on the Tlp::Roles::Collector module, see TLP Server Modules. The most crucial selectors are as follows:

name
name of the system

        os, version, arch
        The operation system's name, version and hardware architecture
            (e.g. 'SunOS', '5.8', 'sparc')

        Example:

          # Select this patch (any rev level allowed), but only for Solaris 8 systems.
          111234     os=>"SunOS",version=>"5.8"
  
          # Select this patch for all operating systems
          115634

          # Select this patch only for host 'eclipse'
          187653     name=>"eclipse"

          # Select a specific revision. This one will always be used. 
          197654-23 

          # Use a regexp for name
          168787-15  name=>'/cores|eclipse\d+/'

You can provide more than one whitelist. Multiple whitelists are merged. A whitelist given later in the configuration overrides any previous whitelist entries. Whitelist patches are moved to the beginning of the patch list. If multiple whitelist entries apply, those that are furthest down on the list are moved to the beginning of the patch list. If a whitelist cannot be found, it is ignored.

TLP Blacklist File Configuration

The blacklist contains those patches that should be excluded during the patch set creation process. It also contains those patches that should be replaced by another patch. This list contains one patch per line, where patches are given a specific revision level, or the patch ID is given by itself. You can also replace a given patch. To do so, provide a second column with the replacement patch ID.

Be mindful that no further dependency checks are performed on the replacement patch.

As with the whitelist configuration, lines beginning with a hash mark (#) and empty lines are ignored. You can use selectors at the end of a line to indicate for which system the specified patch should be replaced or ignored. See the whitelist configuration information for possible selectors to use. The selector must be the last entry on a line. Values of the selectors that are embedded in slashes are treated as regular expressions. You can also list a patch multiple times, with different selectors. In this instance, the first match is taken as black-listed patch.

Example 3–1 Sample Blacklist Configuration

This is an example of a blacklist configuration.

# We don't like this patch at all:
123456

# We don't like this very specific revision
# However, other revision could be included.
789098-24


# We want to replace a specific patch
109320-06   109320-08

# Only ignore this patch on machine "eclipse"
109456-13   name=>"eclipse"

# Patches can be mentioned multiple times with different 
# selectors
109456-13   name=>"sun42"

# The same as above in one single line using regular expressions
109456-13   name=>"/eclipse|sun42/"

# Replace this patch on all Solaris 5.8 machines
109320-06   109320-08     os=>"Solaris",version=>"5.8"

Any additional patches that are dependent on these black-listed patches are excluded from the resulting patch set, as well. For replacement patches, no further check or dependency resolution is performed. You can provide more than one blacklist option in the configuration file. Multiple blacklist entries are merged. If a blacklist cannot be found, it is ignored.