von Markus Frosch | Apr 13, 2020 | Icinga, Monitoring
Just about a week ago I posted a short blog post introducing a new check to verify firmware of SSD disks by HPE. Since our customer informed us about another bulletin he has to take care of, we extended the check to support RAID controllers, and verify if a problematic firmware needs to be patched.
HPE says about the issue in bulletin a00097210:
HPE Smart Array SR Gen10 Controller Firmware Version 2.65 (or later) provided in the Resolution section of this document is required to prevent a potential data inconsistency on select RAID configurations with Smart Array Gen10 Firmware Version 1.98 through 2.62, based on the following scenarios. HPE strongly recommends performing this upgrade at the customer’s earliest opportunity per the “Action Required” in the table located in the Resolution section. Neglecting to perform the recommended resolution could result in potential subsequent errors and potential data inconsistency.
Important: Please read the full document and verify with your used hardware.
For controllers, the check will alert you with a CRITICAL when the firmware is in the affected range with:
- if you have RAID 1/10/ADM – update immediately!
- if you have RAID 5/6/50/60 – update immediately!
And it will add a short note when firmware older than affected or firmware has been updated. At the moment the plugin does not verify configured logical drives, but we believe you should update in any case.
Please see the repository and README on GitHub for all details, you can download the binaries from releases.
All information about affected disks can be found on GitHub or the previous blogpost.
OK - All 2 controllers and 33 drives seem fine
[OK] controller (0) model=p816i-a serial=XXX firmware=1.65 - firmware older than affected
[OK] controller (4) model=p408e-p serial=XXX firmware=1.65 - firmware older than affected
[OK] (0.9 ) model=MO003200JWFWR serial=XXX firmware=HPD2 hours=8086
[OK] (0.11) model=EK000400GWEPE serial=XXX firmware=HPG0 hours=8086
[OK] (0.12) model=EK000400GWEPE serial=XXX firmware=HPG0 hours=8086
[OK] (0.14) model=MO003200JWFWR serial=XXX firmware=HPD2 hours=8086
[OK] (4.0 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.1 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.2 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.3 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.4 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.5 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.6 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.24) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.25) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.26) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.27) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.28) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.29) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.30) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.31) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.50) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.51) model=MO003200JWFWR serial=XXX firmware=HPD2 hours=7568
...
Markus Frosch
Principal Consultant
Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.
von Markus Frosch | Apr 3, 2020 | Development, Monitoring
With two bulletins published by Hewlett Packard Enterprise (HPE), several solid state disks (SSD) were declared vulnerable to a software bug, which causes the counter for uptime hours to overflow after 32768 or 4000 hours and renders the disk completely inaccessible. A quote from the vendor:
This … firmware is considered a critical fix and is required to address the issue detailed below. HPE strongly recommends immediate application of this critical fix. Neglecting to update to SSD Firmware Version … will result in drive failure and data loss at 40,000 (or 32,768) hours of operation and require restoration of data from backup if there is no fault tolerance, such as RAID 0 or even in a fault tolerance RAID mode if more SSDs fail than can be supported by the fault tolerance of the RAID mode on the logical drive. Example: RAID 5 logical drive with two failed SSDs.
One of our customers asked us for help with identifying the affected drives, since they noticed some of their servers being affected. We have written a custom Icinga plugin to check for affected drives and to identify where firmware updates are required. The only requirement is SNMP access to the servers or devices that need to be checked. The plugin lists all found drives, compares them against a list of affected models and compares the firmware version against the recommended fix by HPE.
When everything is fine, you should see something like this:
OK - All 2 controllers and 33 drives seem fine
[OK] controller (0) model=p816i-a serial=XXX firmware=1.65 - firmware older than affected
[OK] controller (4) model=p408e-p serial=XXX firmware=1.65 - firmware older than affected
[OK] (0.9 ) model=MO003200JWFWR serial=XXX firmware=HPD2 hours=8086
[OK] (0.11) model=EK000400GWEPE serial=XXX firmware=HPG0 hours=8086
[OK] (0.12) model=EK000400GWEPE serial=XXX firmware=HPG0 hours=8086
[OK] (0.14) model=MO003200JWFWR serial=XXX firmware=HPD2 hours=8086
[OK] (4.0 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.1 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.2 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.3 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.4 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
[OK] (4.5 ) model=MO3200JFFCL serial=XXX firmware=HPD8 hours=7568 - firmware update applied
You can find the plugin on GitHub under check_hp_firmware where the release page provides the built binaries for Linux.
Feedback or questions are welcome as GitHub issues, directly in the project.
Please make sure you have also read the official documents from HPE:
Update 2020-04-09: The plugin was enhanced to check for controller firmware vulnerabilities as well, and is now named check_hp_firmware. See the new blog post.
Markus Frosch
Principal Consultant
Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.
von Markus Frosch | Dez 20, 2019 | Icinga
Viele Kunden fragen mich, wie man zentral Zugangsdaten oder allgemeine Variablen in Icinga 2 verwalten kann. Icinga 1.x und Nagios hatte für solche Zwecke die resources.cfg, dort wurden zentrale Macros wie $USER1$ usw. konfiguriert.
Nun hat Icinga 2 einen relativen ähnlichen Mechanismus, mit dem man an einer zentralen Stelle globale Konstanten bzw. Variablen speichern kann. Dann können diese überall in der Konfiguration benutzt werden. Aber leider nicht als Macro, was die Verwendung mit dem Director etwas schwieriger macht.
Aber dafür gibt es Abhilfe, auch dafür pflegen wir die Werte in der /etc/icinga2/constants.conf
const GlobalVars = {
OracleDbUser = "svcicinga"
OracleDbPassword = "hunter2"
}
Nun fehlt noch eine kleine Konfiguration, damit diese Variablen auch überall verfügbar sind, dazu bearbeiten wir die Datei /etc/icinga2/conf.d/app.conf und die IcingaApplication.
object IcingaApplication "app" {
vars = GlobalVars
}
Jetzt sind die Variablen überall auch als Macro verfügbar.
vars.oracle_health_username = "$OracleDbUser$"
vars.oracle_health_password = "$OracleDbPassword$"
Ich wünsche viel Spaß beim Ausprobieren, und hoffentlich ruhige Feiertage und einen guten Rutsch ins Jahr 2020!
Bildrechte: Wikimedia Commons – von Psyomjesus
Markus Frosch
Principal Consultant
Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.
von Markus Frosch | Mrz 29, 2019 | Management
Das Thema Agile sickert nun so langsam in jeden großen Konzern und sogar die ersten Behörden.
Dabei klingt das Thema sehr Verlockend, egal in welcher Tiefe man es ausleben möchte:
- Kleinere Teams oder Squads
- Mehr Verantwortung der einzelnen Teams
- Kurze Dienstwege
- Klare Schnittstellen
- Flexible Prozesse
Nur ist die Realität oft nicht so einfach, denn es ist nicht damit getan einen neuen Organisationsplan zu erstellen, und Zuständigkeiten zu definieren.
Es gibt viele weitere Punkte die eigentlich wichtiger sind, gerade Verantwortungen verteilen und vor allem auch Rechte weitergeben fällt den meisten Konzernen sehr schwer. Meine Erfahrungen als Consultant zeigen leider, dass der technische Aspekt von Agile oft vernachlässigt wird.
Viele Konzerne arbeiten noch mit klassischen Managed-Systemen, bei denen das Fachteam, dass eine Anwendung betreibt so gut wie keine Rechte hat. Auch wenn dieses Konzept gute Gründe hat, so ist es fast das Gegenteil von Agile. Denn wenn ein Fachteam nicht in der Lage ist, außerhalb des Laufstalls des ihm zugestanden wird, etwas zu ändern, oder gar ein Paket zu installieren oder updaten, dann ist das eigentlich nicht der Server des Teams. Und dann eigentlich auch in dessen Verantwortung.
Deswegen mein Appell: Wenn man Agile macht, dann bitte auch technische Verantwortung und Rechte übertragen, eben Vertrauen zugestehen.
Das heißt übrigens nicht, dass ein Betriebssystem-Team damit obsolet wäre, dieses wird dann eher zum Dienstleister. Sie stellen die VM oder die Hardware bereit, liefern Grundkonfiguration, helfen bei der Einrichtung, Best-Practices und Problemen.
Der Blick auf die Security der Plattform bleibt eigentlich unverändert, denn es musste auch vorher schon auditiert werden, z.B. ob Sicherheits-Updates installiert wurden, oder Software unsicher konfiguriert ist.
Der Unterschied liegt darin mehr Eigenverantwortung zu etablieren, und damit Flexibilität und Einfachheit zu Gewinnen, eben die Agilität.
Photo by bonneval sebastien on Unsplash
Markus Frosch
Principal Consultant
Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.
von Markus Frosch | Jul 20, 2018 | German, Team
Als Consultant bei NETWAYS ist man durchaus auch auf Reisen, sei es zweigleisig, mit dem Auto oder Flugzeug. Auch das eine oder andere Hotel kennt uns schon als Stammgäste.
Nach nun knapp über 6 Jahren bei NETWAYS habe ich mir einen gewissen Rhythmus angewöhnt und möchte ein paar Eindrücke und Tipps weitergeben.
Die Warnung
Bei uns kann jeder Mitarbeiter seine Reisen selbstständig, und ohne Reisebüro, buchen. Das ist leider nicht bei jedem Unternehmen / Konzern so.
Reisebüros bringen zwar den Vorteil von Verfügbarkeit und ggf. Unterstützung beim Buchen, der Preis oder die Buchungsgeschwindigkeit zeigt eher aber das Gegenteil.
Als Mitarbeiter vor Ort wissen Sie spätestens nach dem 1. Besuch mehr als der Mitarbeiter im Reisebüro. Wenn ich fast jede Woche reise, habe ich lieber die Zügel selbst in der Hand.
(mehr …)
Markus Frosch
Principal Consultant
Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.
von Markus Frosch | Mrz 30, 2018 | Icinga
Disclaimer: This guide is only for RedHat and CentOS 7, using the PHP SCL packages with the official icingaweb2 package.
Often when we help customers implement Icinga 2, Icinga Web 2 and Director, they use custom imports to pull in data to their monitoring config. Whenever data is in need to be pulled from a MSSQL database, this can be challenging. Their are multiple guides around the Internet, even from Microsoft.
This post should clear things how to achieve this with the official Icinga packages and their requirements.
Requirements
Basic Installation Icinga Web 2
First of all icingaweb2 and PHP needs to be installed – usually you should have this already…
# on RedHat
subscription-manager repos --enable rhel-7-server-optional-rpms
subscription-manager repos --enable rhel-server-rhscl-7-rpms
yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
# on CentOS
yum install centos-release-scl epel-release
yum install httpd icingaweb2
systemctl start httpd.service
systemctl enable httpd.service
echo "date.timezone = Europe/Berlin" > /etc/opt/rh/rh-php71/php.d/timezone.ini
systemctl start rh-php71-php-fpm.service
systemctl enable rh-php71-php-fpm.service
Please also see the official documentation.
MSSQL PDO driver for PHP
Their are multiple ways to install a MSSQL compatible driver, but with icingaweb2 and the ZendFramework below in mind, we need to use pdo_dblib with FreeTDS as driver implementation. I prepared a RPM spec file for you to build and install, it is based on the php-extras packages shipped with Fedora’s EPEL, only updated for PHP 7.1 SCL.
You can setup a small RPM build environment on a RedHat or CentOS machine with the required repositories.
sudo yum install rpm-build rpmdevtools yum-utils gcc gcc-c++ scl-utils scl-utils-build
rpmdev-setuptree
cd ~/rpmbuild/SPEC
wget https://github.com/lazyfrosch/rpm-php-extras/raw/epel7/php-extras.spec
cd ../SOURCES
spectool -gf ../SPECS/php-extras.spec
cd ~/rpmbuild
rpmbuild -bs SPECS/php-extras.spec
sudo yum-builddep SRPMS/rh-php71-php-extras*.src.rpm
rpmbuild --rebuild SRPMS/rh-php71-php-extras*.src.rpm
With the built RPM files under RPMS/ you are good to go to your Icinga machine. Basically you only need to copy rh-php71-php-mssql*.rpm over and install it there.
yum install rh-php71-php-mssql*.rpm
scl enable rh-php71 -- php -m
After restarting php-fpm the driver has been loaded.
systemctl restart rh-php71-php-fpm.service
Patching Icinga Web 2
In Icinga Web 2.5.1 and before there is an error in detecting MSSQL correctly, detection only works in PHP 5.x. A fix has been suggested in PR#3400.
To manually patch this, you only need to fix a single line in /usr/share/php/Icinga/Application/Platform.php
--- /usr/share/php/Icinga/Application/Platform.php.orig 2018-03-27 06:02:59.454240788 -0400
+++ /usr/share/php/Icinga/Application/Platform.php 2018-03-27 00:38:15.967639651 -0400
@@ -351,7 +351,7 @@
*/
public static function hasMssqlSupport()
{
- return static::extensionLoaded('mssql') && static::classExists('Zend_Db_Adapter_Pdo_Mssql');
+ return static::extensionLoaded('pdo_dblib') && static::classExists('Zend_Db_Adapter_Pdo_Mssql');
}
/**
I hope this helps you getting started, feel free to ask questions in the comments.
NETWAYS offers professional support for Icinga and other Open Source tools, check our Website about Support.
The image used in this article is from johnmartel.blogspot.de, we assume fair use by mentioning the author.
Markus Frosch
Principal Consultant
Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.
von Markus Frosch | Feb 17, 2017 | English, PostgreSQL, Puppet
On a test system for a customer I wanted to bring up a newer PostgreSQL version on CentOS 7 (same for RHEL 7). Software Collections (also for RedHat) gives you a neat distribution method that is not very invasive into your existing distribution. So you can install a PostgreSQL 9.4 under RHEL 7 without replacing any of the existing packages. This is a bit tricky in terms of paths, but just works.
I found a relatively simple way to install, configure and run such a SCL with Puppet, with just using the existing PostgreSQL module.
https://gist.github.com/lazyfrosch/1926b17d1d605bfb819e899ef6bd4b63
Have fun trying it out and let me know what you think.
Markus Frosch
Principal Consultant
Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.
von Markus Frosch | Dez 9, 2016 | Development, English, Ruby
When you are into developing Ruby code, or even Ruby near stuff like Puppet modules, or Chef cookbooks, there is a nice tool you should have a look at.
The RuboCop can help you writing better Ruby code, it certainly did it for me.
In short words, RubyCop is a code analyzer that checks Ruby code against common style guidelines and tries to detect a lot of mistakes and errors that you might write into your code.
There are a lot of configuration options, and even an auto-correct functionality, that updates your code.
Simple usage
Either install the gem, or add it to your Gemfile:
gem 'rubocop', require: false
You can just run it without configuration, and it will look for all Ruby files in your work directory.
$ rubocop
Inspecting 19 files
....C............CC
Offenses:
lib/test/cli.rb:3:3: C: Missing top-level class documentation comment.
class CLI
^^^^^
lib/test/cli.rb:36:1: C: Extra empty line detected at method body beginning.
lib/test/cli.rb:41:1: C: Extra empty line detected at block body beginning.
lib/test/cli.rb:45:4: C: Final newline missing.
end
bin/test:12:1: C: Missing space after #.
#api.login('username', 'Passw0rd') unless api.logged_in?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
bin/test:15:3: C: Missing space after #.
#puts response.code
^^^^^^^^^^^^^^^^^^^
bin/test:19:1: C: Missing space after #.
#session.save(file)
^^^^^^^^^^^^^^^^^^^
18 files inspected, 7 offenses detected
You can add it as a rake job to your Rakefile:
require 'rubocop/rake_task'
RuboCop::RakeTask.new
task default: [:spec, :rubocop]
And run the test via your rake tests:
$ rake
$ rake rubocop
Configuration galore
There are a lot of options to modify the behavior and expectations of RuboCop.
Here is a short example I used with recent Puppet module.
require: rubocop-rspec
AllCops:
TargetRubyVersion: 1.9
Include:
- ./**/*.rb
Exclude:
- vendor/**/*
- .vendor/**/*
- pkg/**/*
- spec/fixtures/**/*
# We don't use rspec in this way
RSpec/DescribeClass:
Enabled: False
RSpec/ImplicitExpect:
Enabled: False
# Example length is not necessarily an indicator of code quality
RSpec/ExampleLength:
Enabled: False
RSpec/NamedSubject:
Enabled: False
Where to go next
Markus Frosch
Principal Consultant
Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.
von Markus Frosch | Okt 7, 2016 | Icinga, Monitoring
Ich nutze nun Telegram privat schon seit einiger Zeit, mir gefällt der Messenger und man kann dort auch sehr schön Bots einbinden.
Für meine privaten Systeme hat mich E-Mail für Notifications immer ein bisschen gestresst. Man möchte doch eigentlich nur kurz die Info sehen, was zählt ist doch eh der aktuelle Status im Dashboard. Mails muss man immer wegräumen/löschen.
Warum also nicht die Notifications via Bot an mich in Telegram schicken? Nichts einfacher als das.
In einem GitHub Repository habe ich alles nötige (auf Englisch) zusammengefasst. Doch hier gerne noch ein wenig auf Deutsch erklärt.
(mehr …)
Markus Frosch
Principal Consultant
Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.
von Markus Frosch | Jul 29, 2016 | DevOps, English, Linux
SNMP is, and will be for a long time, one of the key protocols in monitoring. Widely used in hardware and appliance monitoring, and for sending events and alerts via TRAP or INFORM.
Now the problem of SNMPv1 or v2 is, that it has no real security. SNMPv3 offers that, but might cause you headaches, trying to understand, how it works.
With this post I want to explain, how snmptrapd can be used in a high availability setup, with the security of SNMPv3. I hope this gives you an inside and a quick start guide to try it out.
Security model
If you never worked with SNMPv3, just a quick introduction to authentication and security. There are no communities anymore, but a few other parameters are required:
- securityName (username)
- authProtocol (MD5 or SHA hashing algorithm)
- authKey (secret to authenticate the peer)
- privProtocol (AES or DES to encrypt the data)
- privKey (secret to encrypt data)
Note: All keys are symmetric, which means both ends of the communication need to use the same keys (and protocol settings).
You can also disable authKey and/or privKey, but than why use SNMPv3? Check the manpage of snmptrapd for how to configure it in detail.
TRAP or INFORM?
With SNMPv3 a new notification type got introduced, called “INFORM”. The main differences between both types are:
- INFORM is using a protocol to ensure delivery (Receiver sends an ack)
- TRAP is working similar to v1/2, but its tricky with SNMPv3 security
- INFORM has protection against message replay
(mehr …)
Markus Frosch
Principal Consultant
Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.
