SSL leicht gemacht – forcierte Weiterleitung von HTTP auf HTTPS einrichten


In den vorherigen Teilen der Serie wurde bereits die Erstellung und Einbindung der Zertifikate beschrieben. Eines Tages wünscht sich der Admin jedoch die sichere Verbindung aller Seitenbesucher, ohne dass diese manuell ein https voranstellen müssen. Gerade bei einer Migration einer bestehenden Seite wird der
Parallelbetrieb erst nach eingehenden Tests eingestellt und das SSL jeweils forciert, um Seitenbesucher nicht mit ungültigen Zertifikaten oder Mixed Content zu verunsichern.
Die eigentliche Umsetzung ist dann relativ einfach und wird in unserem Beispiel direkt in der Vhost-Definition des Apache vorgenommen. Übrigens, die verfügbaren Vhosts sind zu finden unter: /etc/apache2/sites-available. Hier wird nun der HTTP-Vhost (Port 80) um den unten aufgezeigten Block mit den Rewrites erweitert.

<VirtualHost *:80>
  ServerAdmin webmaster@netways.de
  ServerName www.netways.de
  DocumentRoot /var/www/html/netways.de/
  <Directory /var/www/html/netways.de/>
   Options FollowSymLinks
   AllowOverride All
  </Directory>
  ErrorLog /var/log/apache2/error.log
  LogLevel warn
  CustomLog /var/log/apache2/access.log combined
  RewriteEngine on
  RewriteCond %{SERVER_NAME} =www.netways.de [OR]
  RewriteCond %{SERVER_NAME} =netways.de
  RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]
 </VirtualHost>

Damit das Ganze nun auch funktioniert, muss natürlich der SSL-Vhost unter Port 443 erreichbar sein. Wie dieser initial erstellt wird, ist im Artikel SSL-Zertifikat einbinden beschrieben.
Übrigens: wer Let’s Encrypt verwendet, wird im Wizard gleich gefragt, ob SSL forciert werden soll. Der Wizard übernimmt dann die oben gezeigten Schritte. Wie man Let’s Encrypt einsetzt, haben wir natürlich auch schon einmal beschrieben. Damit später keine Seitenbesucher verloren gehen, sollte der HTTP-Vhost, der auf Port 80 läuft, nicht abgeschaltet werden. Die Verbindung ist mit dieser Maßnahme sicher und alle Besucher werden auf https umgeleitet.
Wer damit gar nichts zu tun haben will, und trotzdem stets auf der sicheren Seite sein will, der kann natürlich seine Seite auch bei NETWAYS im Managed Hosting betreuen lassen. Hier kümmern wir uns darum.
In den anderen (teilweise noch kommenden) Blogposts zum Thema SSL leicht gemacht geht es um:

Georg Mimietz
Georg Mimietz
Lead Support Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

Icinga 2 Plugin Check Command Definitionen beisteuern

Auswahl_154Icinga 2 liefert eigene CheckCommand Objektkonfiguration mit, welche den Start in die neue Konfigurationswelt durchaus erleichtert – einfach z.B. ping4 als check_command Attribut für die Service-Apply-Regel verwenden, und fertig. Auf den ersten Blick sind dies hier lediglich die (gängigsten) Definitionen aus dem Monitoring-Plugins-Projekt – allerdings wurden über die letzten Monate viele neue Definitionen aus der Community Patches eingereicht. Dabei ist aufgefallen, dass der ultimative Guide hierfür noch nicht geschrieben ist.
Warum sollte man diese Definition Upstream einschicken?

  • Es ist Open Source – jeder kann diese verwenden und aktualisieren/verbessern
  • Eine zentrale Stelle für Konfiguration und Dokumentation
  • Entwickler können Updates einspielen und mit Best Practices unterstützend zur Seite stehen
  • In einem verteilten Setup müssen die Definitionen nicht (manuell) verteilt werden, sondern werden durch Upstream-Pakete ausgeliefert

Ich habe hierzu im Icinga Wiki einen detaillierten Guide verfasst – auf gehts, gemeinsam schaffen wir das! 🙂
PS: Unsere Kollegen setzen dies auch in Kundenprojekten vor Ort um, und schicken diese Patches dann an uns Entwickler 🙂

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

LConf 1.5.0 released

lconf_logoWhile the backend exporter has been overhauled in many places, we’ve also tackled long lasting issues such as missing schema attributes or nasty import bugs. On the other hand, the LConf web interface reflects the schema additions as well fixes annoying bugs with custom variable removal, and also integrates community contributed patches such as a parent host drop down.
Download LConf Backend 1.5.0, LConf Icinga Web 1.5.0 & LConf Standalone Web 1.5.0.
Find the Changelog below.
Cheers, Alex & Michael

LConf Backend 1.5.0

CHANGES

  • Schema: Additional object attributes (see below) requiring update
  • Import: Skip already existing objects, set address to host name if not defined

FEATURES

  • Feature #1432: add inherits_parent attribute for host/service dependency
  • Feature #1480: add first_notification_delay as schema attribute to host/service
  • Feature #1886: contact attributes address1-6 missing
  • Feature #2082: Add ldap_person and allow auxiliary objectClass in ldap schema
  • Feature #2429: Add the attribute “address6” for ipv6 dual stack to the host-settings
  • Feature #2495: Add attribute contactgroup_members and servicegroup_members
  • Feature #2690: Complete LDAP schema
  • Feature #2889: LConfImport: Skip already existing objects and continue import
  • Feature #2891: LConfImport: Set host address to name if not existing

FIXES

  • Bug #2192: LConfImport.pl doesn’t ignore comments in objects.cache
  • Bug #2240: hostgroup alias/display_name is overridden with cn
  • Bug #2761: Escalations are no longer exported
  • Bug #2857: LConf 1.5.0-rc1: additional hostgroups are exported with a “+”
  • Bug #2859: Default User filter for Icinga2 is too restrictive
  • Bug #2887: str2arr_by_delim_without_excludes() must not return empty array values
  • Bug #2899: customvars with value 0 are not exported

LConf Icinga Web Module 1.5.0

CHANGES

  • Requires LConf Backend 1.5.x!
  • New object attributes (see below)
  • Export checks for unsaved settings
  • Exclude not supported attributes in properties tab

FEATURES

  • Feature #1568: Notify to save last changes before export
  • Feature #1727: Parent settings for Hosts via GUI
  • Feature #2096: connection manager: add the default 389 port and localhost as default
  • Feature #2425: Add “Max check attempts” to check settings
  • Feature #2517: ServiceEscalationServiceGroups and ServiceEscalationHostGroups dropdown missing
  • Feature #2645: Add an option to define override or add for specific attribute values (groups, contacts, etc)
  • Feature #2875: Add attributes: host address6, {contact,service}group_members, contact address1-6
  • Feature #2877: Add inherits_parents (dependencies 1.x) and first_notification_delay (host/service) attributes

FIXES

  • Bug #2177: Quicklinks from grid to access the hostObject directly in LConf don’t work
  • Bug #2410: delete customvar not possible
  • Bug #2553: Testcheck fails at expanding macros
  • Bug #2643: Contacts can not have an interval
  • Bug #2811: Find a way to hide StructObj attributes in Properties tab
  • Bug #2839: Add property not possible

LConf Standalone Web 1.5.0

Same as Icinga Web Module, and additionally:
FEATURES

  • Feature #2841: Increase Ajax timeout
  • Feature #2871: Add support for Apache 2.4
Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

Release packages for RPM repository configuration

While writing and updating training material for our Icinga 2 courseware, we are also re-evaluating the installation and configuration process by practical example and learning curve. Certain parts of the Icinga2 documentation are updated similar to the training material from training participants feedback and also by the trainers themselves.
In this special example, we found it tremendously hard to install the icinga rpm repository from packages.icinga.org inside the CentOS 7 training VM. By default you would just type a long string to fetch the yum repository information.

# wget http://packages.icinga.org/epel/ICINGA-release.repo -O /etc/yum.repos.d/ICINGA-release.repo
# yum makecache

training_install_icinga_repositoryWhile this works pretty well for release repositories, how about the snapshot repository for testing bleeding edge stuff? Similar to EPEL release package we’d just want that for Icinga as well.
The RPM package called ‘icinga-rpm-release’ contains the repository’s GPG key as well as the yum configuration for the release repository which is enabled by default. The snapshot repository is installed, but disabled. You may use it with the “–enablerepo” yum parameter.
Example for el7:

Name:           icinga-rpm-release
Version:        7
Release:        1%{?dist}
Summary:        Icinga Package Repository
Group:          System Environment/Base
License:        GPLv2
URL:            http://packages.icinga.org/epel/
Source0:        %{name}-%{version}.tar.gz
Source1:        http://packages.icinga.org/icinga.key
Source2:        http://packages.icinga.org/epel/ICINGA-release.repo
Source3:        http://packages.icinga.org/epel/ICINGA-snapshot.repo
BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch:      noarch
Requires:       redhat-release >=  %{version}
%description
This package contains the Icinga package repository GPG key
as well as configuration for yum.
%prep
%setup -q -c -T
install -pm 644 %{SOURCE0} .
%build
%install
rm -rf $RPM_BUILD_ROOT
#GPG key
install -Dpm 644 %{SOURCE1} $RPM_BUILD_ROOT%{_sysconfdir}/pki/rpm-gpg/RPM-GPG-KEY-ICINGA
#yum
install -dm 755 $RPM_BUILD_ROOT%{_sysconfdir}/yum.repos.d
install -pm 644 %{SOURCE2} %{SOURCE3} $RPM_BUILD_ROOT%{_sysconfdir}/yum.repos.d
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%config(noreplace) /etc/yum.repos.d/*
/etc/pki/rpm-gpg/*
%changelog

All distribution releases are organized in git branches, which keeps it fairly simply for Jenkins package builds.
Tip: Downloading the url-referenced sources (“SourceX: Url”) works using spectool.

$ cd sources
$ spectool -g ../icinga-rpm-release.spec
modify, add, commit

In the end, you’ll get a nice rpm which installs just fine. No need to worry about the GPG key or where to store the configuration files.

# rpm -i http://packages.icinga.org/epel/7/release/noarch/icinga-rpm-release-7-1.el7.centos.noarch.rpm
# yum search icinga2

See you in the icinga2 training sessions!

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

Neue Features in Icinga 2.3

Die nächste Major-Version von Icinga 2 wird einige interessante Features unterstützen, die es noch einfacher machen, Ausnahmen für Services zu definieren. Bis die 2.3 als Release-Version verfügbar ist, wird es zwar noch eine Weile dauern, aber hier gibt es schonmal einen kleinen Vorgeschmack:

Konditionale Statements

Auch bekannter als if/else: In 2.3 ist es möglich, Attribute nur dann zu setzen, wenn bestimmte andere Bedingungen erfüllt sind. Hier ein Beispiel:

object Host "localhost" {
  check_command = "hostalive"
  address = "127.0.0.1"
  vars.http_vhosts["icinga.org"] = {
    http_address = "icinga.org"
    interval = 1m
  }
  vars.http_vhosts["netways.de"] = {
    http_address = "netways.de"
  }
}
apply Service "vhost " for (vhost => config in host.vars.http_vhosts) {
  host_name = "localhost"
  check_command = "http"
  if (config.interval) {
    check_interval = config.interval
  } else {
    check_interval = 5m
  }
  assign where host.vars.http_vhosts
}

Entwicklungs-Konsole

Um Filterregeln für “apply” und auch andere Ausdrücke einfacher testen zu können, gibt es eine CLI-basierte Konsole, die beliebige Befehle auswerten kann und deren Ergebnis anzeigt:

$ icinga2 console
Icinga (version: v2.2.0-262-g7075607)
<1> => config = { http_address = "icinga.org", interval = 1m }
{"http_address":"icinga.org","interval":60.0}
<2> => if (config.interval) { check_interval = config.interval } else { check_interval = 5m }
60.0
<3> => check_interval
60.0

Prototypen

Alle eingebauten Datentypen (d.h. Strings, Zahlen, Arrays und Dictionaries) verfügen nun über Methoden. Mit Hilfe dieser Methoden können z.B. Dictionaries manipuliert werden:

<1> => vhosts = { "icinga.org" = { http_address = "icinga.org" }, "netways.de" = { http_address = "netways.de" } }
{"icinga.org":{"http_address":"icinga.org"},"netways.de":{"http_address":"netways.de"}}
<2> => vhosts.remove("icinga.org")
null
<3> => vhosts
{"netways.de":{"http_address":"netways.de"}}
<4> => vhosts.len()
1.0

Mit Dictionary#remove würden sich so z.B. bestimmte Dictionary-Items entfernen lassen, falls diese bei einem bestimmten Host bzw. Service nicht vorhanden sein sollen.

Reminder für das Puppet Webinar – Windows Configuration Management

puppet Heute will ich noch mal auf das Webinar zum Thema Puppet: Windows Configuration Management am Freitag, den 12.12.2014 um 10:30 Uhr hinweisen. Gemeinsam mit Dirk werde ich demonstrieren, wie man Windows-Systeme mit Puppet deployen und konfigurieren kann.
Wer hieran teilnemhen möchte, kann sich natürlich gerne registrieren.
Um die Zeit zu überbrücken, kann man sich auch gerne die Webinar-Videos in unserem Webinar-Archiv anschauen.
Bis Freitag!

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Weekly Snap: Neon 110 & Coshsh, Confs & Camps in San Francisco

weekly snap18 – 22 August offered an eclectic mix of subjects – from sys admin and handyman tools to configuration generators and analyzers.
On events, Eva counted 99 days to the OSMC with Gerhard Laußer’s talk: ‘Coshsh – Configuration Generation’ while Bernd made plans to join Puppet Conf and Icinga Camp in San Francisco.
Continuing the travel theme, Thomas shared his thoughts on the troubles of flying with and without Swiss army knives as Ronny reflected on the excitement of discovering new sys admin tools.
Lastly, Georg helped bring about a firmware update for the Neon 110 network thermometer and Gunnar offered a peek into a new configuration analyzer for Icinga 2.

Neue Webinar-Termine und Änderung zum Webinar am 26. Juni

Es ist wieder soweit – die nächste Runde von Webinaren ist jetzt online! Vorab gibt es meinerseits noch eine kleine Planänderung bzgl. des Webinars am 26. Juni 2014. Anstatt des Themas “inGraph: Neues Webfrontend für Graphite“, werden wir das Thema “Foreman: OpenNebula orchestrieren” behandeln.
Das Graphing-Webinar werden wir voraussichtlich gegen Ende des Jahres mit Icinga-Web 2 durchführen.
In den anderen geplanten Webinaren werden wir uns schwerpunktmäßig mit Icinga 2 beschäftigen.
Übrigens: Der Release ist heute!
Hier nochmal eine kurze Auflistung der nächsten Themen:

Titel Zeitraum
Foreman: OpenNebula orchestrieren 26. Juni 2014 – 10:30 Uhr
Icinga 2: Enterprise Monitoring der nächsten Generation 22. Juli 2014 – 10:30 Uhr
Icinga 2: Migration von Nagios oder Icinga 1.x leicht gemacht 02. September 2014 – 10:30 Uhr
Icinga 2: Integrierte Hochverfügbarkeit 07. Oktober 2014 – 10:30 Uhr

Einige weitere Themen für mögliche Webinare sind aktuell noch in Planung und wir werden natürlich zeitnah informieren, sobald diese konkret feststehen. Wer in der Sommerpause lust auf Webinare hat, kann natürlich gerne in unserem Webinar-Archiv vorbeischauen und sich bereits gehaltene Vorträge anschauen.
Bis dann!

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Project of the month: Nagios templates for configuration clarity

September 2009: When Schüco approached NETWAYS, they had a basic, sluggish Nagios installation they wanted to expand and optimise. With over 46 locations around the globe and 650 devices to monitor, Schüco was looking for support in the coming configuration chaos. Inadvertently, config details were replicated many times over, sitting in large unstructured files so that Schüco admins simply had too much information and no overview.
The first task for consultant William was to restructure their config files into a tree and added template functionality. This suited their multiuser admin needs and simplifying their file structure in turn simplified configuration work. Instead of changing a config variable over 40 times, with templates they now only needed to do it twice.
On this new tidy configuration base, he could then expand the monitoring system’s capabilities to include the usual suspects: EventDB, PNP4Nagios, Nagvis, NETWAYSPortal, SMS alerts, business processes and even Jasper reports. As William customised the NETWAYSPortal for Schüco, he enhanced the SLA view to make target SLAs easier to compare with ‘actual availability’. After a good 20 days work on and offsite, their new state of the art monitoring system was up and running at optimum efficiency. Kudos to that.

sla_screenshot

Enhanced SLA View for easy target vs. actual availability comparison