Call-Home-Service Privacy Policy explained

Please note that this article / this category refers either on older software / hardware components or is no longer maintained for other reasons. This page is no longer updated and is purely for reference purposes still here in the archive available.

When using the Thomas Krenn Call-Home-Service in some cases your monitoring system Icinga, Nagios or TKmon transmits encrypted data to Thomas Krenn. The purpose of this data is to provide the best support to our Thomas Krenn customers by sending you necessary replacements quickly should any hardware problems arise. Here we will explain, using our Call-Home-Service Privacy Policy, which data is transmitted as well as explain when, how and why the data is transmitted.

Important hint

The monitoring software TKmon is no longer being developed further and the Thomas-Krenn call-home service has also now been switched off.

Function

In order to use the Call-Home-Service you must allow the transfer of data from your Icinga, Nagios or TKmon monitoring system to Thomas Krenn, in order for our support team to contact you in case of hardware problems.

The transmitted data is generated by the open source program TKalert. TKalert must be configured by the user for use with Icinga. (Information regarding this can be found in the article Call-Home-Service using Icinga or Nagios). When used with TKmon TKalert is configured under the settings menu Call Home.

The source code of TKalert is publicly available at git.netways.org/thomas-krenn/tkalert.

Transmission of Heartbeats

Purpose: To test if Thomas Krenn is receiving emails from our customer’s monitoring systems. If no heartbeat message is received for a period of two days, Thomas Krenn automatically sends an email to the email address where the most recent heartbeat message was received, so that the customer can be informed when Thomas Krenn is no longer receiving emails from your monitoring system. After three days the Thomas Krenn support team is also automatically notified by email. The Thomas Krenn support team will then contact the customer by phone.

Transmission Type: GPG-encrypted email to Thomas Krenn
Frequency: 1x per day (every 24 hours)
Type of Data Transmitted:
- --auth-key: Call-Home Auth-Key
- --contact-person: name of the contact person
- --contact-mail: Email address
Data Management: During your first transmission to the Call-Home-Service database a single heartbeat message entry, including time stamp, is generated. When the next heartbeat message is received the time stamp entry and any updated information, such as the name of the contact person or the email address is also updated. Therefore only the last heartbeat message sent to Thomas Krenn is stored for a particular Call-Home Auth-Key.

Example Heartbeat

The following call shows how a heartbeat message is generated and how it is stored to a file instead of sending an email:

$ sudo /usr/share/tkalert/tkalert.sh --type="heartbeat" --auth-key="0123456789a" \
  --contact-person="Testperson" \
  --contact-mail="test@example.com" \
  --verbose \
  --dump /tmp/dump-heartbeat.xml
2013-05-18 11:47:34,981 [DEBUG] Starting up
2013-05-18 11:47:34,982 [INFO] Creating heartbeat object
2013-05-18 11:47:34,982 [INFO] Set --date switch to NOW
2013-05-18 11:47:34,983 [DEBUG] Dump xml to file (/tmp/dump-heartbeat.xml)

The contents of this file is then: (in this example line breaks are added for readability):

<?xml version="1.0" encoding="UTF-8"?>
  <heartbeat version="1.0">
    <authkey category="Monitoring">0123456789a</authkey>
    <date>Sat May 18 11:47:34 2013</date>
    <contact-name>Testperson</contact-name>
    <contact-mail>test@example.com</contact-mail>
  </heartbeat>

Without --dump option TKalert encrypts the XML-contents and sends it to Thomas Krenn (however, the sender’s email does not appear, to protect against spam, when using this command:

$ sudo /usr/share/tkalert/tkalert.sh --type="heartbeat" --auth-key="0123456789a" \
  --contact-person="Testperson" \
  --contact-mail="test@example.com" \
  --verbose \
  --dump /tmp/dump-heartbeat.xml
2013-05-18 11:53:26,827 [DEBUG] Starting up
2013-05-18 11:53:26,828 [INFO] Creating heartbeat object
2013-05-18 11:53:26,829 [INFO] Set --date switch to NOW
2013-05-18 11:53:26,830 [DEBUG] Call GPG: /usr/bin/gpg --home /etc/tkalert --options /etc/tkalert/gnupg.conf --batch --encrypt -a -r 0x584F819C
2013-05-18 11:53:26,836 [DEBUG] Send mail to *******@thomas-krenn.com (server=localhost)
2013-05-18 11:53:26,871 [INFO] Runtime 0.0448 seconds

Transmission of Service Messages

Purpose: In the event of any hardware problems, (e.g. a fan failure), the Thomas Krenn support team will be notified automatically. The Thomas Krenn support team can then contact the customer and arrange for the rapid replacement of the required part.
Transmission Type: GPG-encrypted email to Thomas Krenn
Frequency: Transfer takes place in case of a change of status of a monitored hardware component. (transition from OK/WARNING/CRITICAL)
Type of Data Transmitted:
- --auth-key: Call-Home Auth-Key
- --contact-person: name of the contact person
- --contact-mail: Email address
- --host: name of host
- --host-status: status of Host
- --ip: IP Address of the Host
- --os: operating system of the Host
- --serial: Thomas Krenn serial number
- --service: service check requested (e.g. IPMI Sensors)
- --service-status: OK/WARNING/CRICITAL
- --output: edition of Nagios/Icinga Plug-ins
- --perf: Performance-Data of Nagios/Icinga Plug-ins
- --component-serial: serial number of the effected components (for each Plug-in)
- --component-name: name of the effected components (for each Plug-in)
- --duration: time lapse
- --date: date
Data Management: A message is sent by email directly to the Thomas Krenn support team and stored in the Call-Home-Service database. The entry is then used to filter our duplicate messages, that affects the same hardware problem (such as duplicate messages with a faulty manual configuration from Incinga or Nagios can occur). All such entries will be automatically deleted if that are older than 24 horus.

Example Service Message

The following call shows how a service message is generated and how it is stored to a file instead of sending an email:

$ sudo /usr/share/tkalert/tkalert.sh --type="service" \
  --auth-key="0123456789a" --contact-person="Testperson" --contact-mail="test@example.com" \
  --host="host1.example.com" \
  --host-status="UP" \
  --ip="127.0.0.200" \
  --os="Ubuntu 12.04.2 LTS" \
  --serial="90000xxxxx" \
  --service="IPMI Sensors" \
  --service-status="CRITICAL" \
  --output="Critical [PS 1 Status = 'Presence detected' 'Power Supply Failure detected']" \
  --perf="'System Temp'=28.00 'Peripheral Temp'=36.00 'FAN 1'=1725.00 'Vcore'=0.78 '3.3VCC'=3.38 '12V'=11.93 'VDIMM'=1.53 '5VCC'=5.09 '-12V'=-12.09 'VBAT'=3.14 'VSB'=3.34 'AVCC'=3.38" \
  --duration=3600 \
  --component-serial="012345" \
  --component-name="IPMI" \
  --verbose \
  --dump /tmp/dump-service.xml

The contents of this file is then: (in this example line breaks are added for readability):

<?xml version="1.0" encoding="UTF-8"?>
  <alert version="1.0">
    <authkey category="Monitoring">0123456789a</authkey>
    <date>Sat May 18 12:21:10 2013</date>
    <contact-name>Testperson</contact-name><contact-mail>test@example.com</contact-mail>
    <host>
      <name><![CDATA[host1.example.com]]></name>
      <ip><![CDATA[127.0.0.200]]></ip>
      <status><![CDATA[UP]]></status>
      <operating-system><![CDATA[Ubuntu]]></operating-system>
      <server-serial><![CDATA[90000xxxxx]]></server-serial>
    </host>
    <service>
      <name><![CDATA[IPMI]]></name>
      <status><![CDATA[CRITICAL]]></status>
      <plugin-output><![CDATA[Critical]]></plugin-output>
      <perfdata><![CDATA['System]]></perfdata>
      <duration><![CDATA[3600]]></duration>
      <component-serial><![CDATA[012345]]></component-serial>
      <component-name><![CDATA[IPMI]]></component-name>
    </service>
  </alert>

Without --dump option TKalert encrypts the XML-contents and sends it to Thomas Krenn (however, the sender’s email does not appear, to protect against spam, when using this command:

$ sudo /usr/share/tkalert/tkalert.sh --type="service" \
  --auth-key="0123456789a" --contact-person="Testperson" --contact-mail="test@example.com" 
  --host="host1.example.com" \
  --host-status="UP" \
  --ip="127.0.0.200" \
  --os="Ubuntu 12.04.2 LTS" \
  --serial="90000xxxxx" \
  --service="IPMI Sensors" \
  --service-status="CRITICAL" \
  --output="Critical [PS 1 Status = 'Presence detected' 'Power Supply Failure detected']" \
  --perf="'System Temp'=28.00 'Peripheral Temp'=36.00 'FAN 1'=1725.00 'Vcore'=0.78 '3.3VCC'=3.38 '12V'=11.93 'VDIMM'=1.53 '5VCC'=5.09 '-12V'=-12.09 'VBAT'=3.14 'VSB'=3.34 'AVCC'=3.38" \
  --duration=3600 \
  --component-serial="012345" \
  --component-name="IPMI" \
  --verbose \
2013-05-18 12:25:11,918 [DEBUG] Starting up
2013-05-18 12:25:11,919 [INFO] Creating alert object
2013-05-18 12:25:11,920 [INFO] Set --date switch to NOW
2013-05-18 12:25:11,921 [DEBUG] Call GPG: /usr/bin/gpg --home /etc/tkalert --options /etc/tkalert/gnupg.conf --batch --encrypt -a -r 0x584F819C
2013-05-18 12:25:11,927 [DEBUG] Send mail to *******@thomas-krenn.com (server=localhost)
2013-05-18 12:25:11,960 [INFO] Runtime 0.0430 seconds

Data Protection from Thomas Krenn

The data protection directory process for Thomas Krenn.AG with contact information to the privacy officer can be found here:

Privacy at Thomas Krenn

Author: Werner Fischer

Werner Fischer, working in the Knowledge Transfer team at Thomas-Krenn, completed his studies of Computer and Media Security at FH Hagenberg in Austria. He is a regular speaker at many conferences like LinuxTag, OSMC, OSDC, LinuxCon, and author for various IT magazines. In his spare time he enjoys playing the piano and training for a good result at the annual Linz marathon relay.