Use this documentation with care! It describes
the outdated version 7, which was actively
developed around 2014 and is considered dead by the
This documentation reflects the latest update of the v7-stable branch. It describes the 7.6.8 version, which was never released. As such, it contains some content that does not apply to any released version.
To obtain the doc that properly matches your installed v7 version, obtain the doc set from your distro. Each version of rsyslog contained the version that exactly matches it.
As general advise, it is strongly suggested to upgrade to the current version supported by the rsyslog project. The current version can always be found on the right-hand side info box on the rsyslog web site.
Note that there is only limited rsyslog community support available for the outdated v7 version (officially we do not support it at all, but we usually are able to answer simple questions). If you need to stick with v7, it probably is best to ask your distribution for support.
GuardTime Log Signature Provider (gt)¶
Signature Provider Name: gt
Author: Rainer Gerhards <email@example.com>
Supported Since: since 7.3.9
Provides the ability to sign syslog messages via the GuardTime signature services.
Signature providers are loaded by omfile, when the provider is selected in its “sig.providerName” parameter. Parameters for the provider are given in the omfile action instance line.
This provider creates a signature file with the same base name but the extension “.gtsig” for each log file (both for fixed-name files as well as dynafiles). Both files together form a set. So you need to archive both in order to prove integrity.
sig.hashFunction <Hash Algorithm> The following hash algorithms are currently supported:
sig.timestampService <timestamper URL> This provides the URL of the timestamper service. If not selected, a default server is selected. This may not necessarily be a good one for your region.
Note: If you need to supply user credentials, you can add them to the timestamper URL. If, for example, you have a user “user” with password “pass”, you can do so as follows:
sig.block.sizeLimit <nbr-records> The maximum number of records inside a single signature block. By default, there is no size limit, so the signature is only written on file closure. Note that a signature request typically takes between one and two seconds. So signing to frequently is probably not a good idea.
sig.keepRecordHashes <on/off> Controls if record hashes are written to the .gtsig file. This enhances the ability to spot the location of a signature breach, but costs considerable disk space (65 bytes for each log record for SHA2-512 hashes, for example).
sig.keepTreeHashes <on/off> Controls if tree (intermediate) hashes are written to the .gtsig file. This enhances the ability to spot the location of a signature breach, but costs considerable disk space (a bit mire than the amount sig.keepRecordHashes requries). Note that both Tree and Record hashes can be kept inside the signature file.
- currently none known
This writes a log file with it’s associated signature file. Default parameters are used.
action(type="omfile" file="/var/log/somelog" sig.provider="gt")
In the next sample, we use the more secure SHA2-512 hash function, sign every 10,000 records and Tree and Record hashes are kept.
action(type="omfile" file="/var/log/somelog" sig.provider="gt" sig.hashfunction="SHA2-512" sig.block.sizelimit="10000" sig.keepTreeHashes="on" sig.keepRecordHashes="on")