Gnocchi: Metriken und Metadaten

Gnocchi LogoGnocchi kann im Vergleich zu anderen Timeseries Datenbanken auch Metadaten zu einzelnen Ressourcen hinzufügen. Somit kann man Metriken einfach mit Informationen versehen die wiederum für so spannende Dinge wie Accounting und Reporting verwendet werden können. Eine konkrete Metrik, z.B. der aktuelle Speicherverbrauch eines Servers, wird in Gnocchi immer zu einer Ressource (z.B. mein-db-server1) gespeichert. Eine Ressource hat einen Typ, z.B. Server. Der Typ Server gibt die Attribute/Metadaten vor, welche zu meiner Ressource mein-db-server1 gespeichert werden können.

Also nochmal in kurz: Eine Metrik gehört zu einer Ressource. Eine Ressource hat einen Typ. Ein Typ hat Metadaten.

Ein neuer Ressourcetyp, z.B. Server,  mit den Attributen Name und Kundenummer ist mit folgenden HTTP Post an den Endpunkt /v1/resource_type schnell erstellt:

{ 
  "Name": "Server",
  "attributes": {
    "name": {
    "required": true,
    "type": "string"
  },
  "Kundennummer": {
    "max": 8,
    "min": 8,
    "type": "number",
    "required": true
  } 
}

Um nun eine konkrete Ressource mein-db-server1 anzulegen, sendet man unten stehendes Json an den Endpunkt /v1/resource/server:

{
"Kundennummer": "12345678",
"Name": "mein-db-server1"
}

Zu der neuen Ressource kann man beliebige Metriken (z.B. CPU, Memory, Traffic etc.) hinzufügen und natürlich lassen sich auch die Filter der Suche auf die Kundennummer anpassen. Folgender HTTP Post an /v1/search/resource/server findet alle meine Server wieder:

{
  "=": {
    "Kundennummer": "12345678"
  }
}

Gnocchi gibt einem alles an die Hand um die eigenen Metriken mit Metadaten zu versorgen. Damit ist es ein Leichtes seine Reporting und Accounting Tools mit Daten zu befüllen, wie z.B. unser Cost Explorer.

Achim Ledermueller

Autor: Achim Ledermueller

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.

NWS OpenStack | The ultimate IaaS Platform!

 

With NWS OpenStack you get the cloud infrastructure that helps your business to stay flexible and grow.

NWS OpenStack lets you deploy virtual machines and other resources for managing a cloud environment on the fly.

Community-powered innovation with Enterprise-grade
features and support:

  • Compute | Your virtual machines with different operating systems can be up and running in seconds
  • Network | In your own virtual data center networks can be isolated and customized environments created
  • Storage | The replicated Ceph storage, hosted across two independent data centers, is ready for your workload
  • Support | We support you with Managed Services – 24 hours a day, 365 days a year
  • Availability | All instances of different available zones are located in an ISO-certified data center in Germany

Get your own cloud infrastructure managed by a team of experts!

Try now: nws.netways.de

OpenStack Webinar: Learn more!
Stack up your knowledge on Wednesday, October 17, 2018. At 10.30 am. Register here.

 

NWS OpenStack | Tailored Infrastructure as a Service

Julia Hornung

Autor: Julia Hornung

Julia ist seit Juni 2018 Mitglied der NETWAYS-Crew. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und Produktionsassistentin in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

NETWAYS Webinare – Jetzt mit OpenStack !

Wieder einmal mehr haben wir an unserem Webinar Kalender geschraubt – diesmal möchten wir euch etwas über OpenStack erzählen.

OpenStack: Infrastructure Hosting by NETWAYS
Dort wollen wir unsere neue OpenStack IaaS Plattform vorstellen und die Vorteile, welche sich hieraus ergeben. Dadurch gewähren wir unseren Kunden maximale Transparenz, Flexibilität und eigenes Management der IT-Umgebungen.

Als Termin ist der 17. Oktober 2018 um 10:30 Uhr angesetzt.
 

Die Anmeldung zum Webinar ist hier möglich.
Darüber hinaus möchte ich eine weitere Änderung in unserem Webinar Kalender ankündigen: Das Webinar Icinga 2: Monitoring für Windows musste leider verschoben werden und zwar auf den 05. Dezember 2018 um 10:30 Uhr. Eine Mitteilung an alle Teilnehmer ging heute morgen bereits raus.

Anbei gibt es hier einmal die aktuelle Webinar Liste im Überblick:

Selbstverständlich werden wieder alle Webinare aufgezeichnet und auf unserem YouTube Channel veröffentlicht.

Ich freue mich wie immer auf eine rege Teilnahme und die Webinare!

Christian Stein

Autor: Christian Stein

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".

NETWAYS goes to the Dortmund “Initiale”

We are happy to be the part of  “Die Initiale” on October 5, 2018 at Messe Dortmund. if you are visiting Dortmund at the time, Manfred and Nicole will be happy to greet, talk and help you with NETWAYS Hosting and Web Services information.

What you can expect from us at “Die Initiale”?

1. NETWAYS Hosting Services enriches the needs of a Start-up enterprise: 

“We love Open Source” is not just a marketing slogan for us, but it is a live reality. Whether video streaming, image delivery, load balancing or highly available database backends. Based on Open Source, we ensure your business with the following services:
– Infrastructure as a Service (IaaS) with OpenStack
– Managed Hosting with VMs and Rental Servers
– Software as a Service (SaaS) with many open source tools

 

2. Agency Hosting Services: 

Do you rely on Open Source for your (web) applications? With NETWAYS you get the competent partner for all hosting projects. We will build exactly the environment you need for your project and your development and advise you in all architectural questions – also gladly together with your customers.

 

 

3. OpenStack: 

Infrastructure as a Service  “Managed as you want”. OpenStack is the self-service tool for flexible infrastructure. You do not want to create your environment yourself? Just book our management package along with your resources and you are ready to start it off. Get what you need at the moment you need it.

 

Don’t forget to listen our Nicole’s talk on “Cloudcomputing – Vor- und Nachteile” at 11:00 am, FORUM B.

For more information visit nws.netways.de 

 

 

Keya Kher

Autor: Keya Kher

Keya hat im Oktober 2017 ihr Praktikum im Marketing bei NETWAYS gestartet. Seitdem lernt sie fleißig deutsch und fühlt sich bei NETWAYS schon jetzt pudelwohl. Sie hat viele Erfahrungen im Social Media Marketing und ist auf dem Weg, ein Grafikdesign-Profi zu werden. Wenn sie sich gerade nicht kreativ auslebt, entdeckt sie die Stadt oder schmökert im ein oder anderen Buch. Ihr Favorit ist “The Shiva Trilogy”.

Icinga2 GitLab Health Check

GitLab

Neulich hatten wir bei einigen GitLab Updates auf die neueste Version das Problem, dass die Dienste nach dem Update zwar korrekt alle wieder gestartet wurden und daher unser alter Monitoring Check “Service: gitlab” den Status “Gitlab OK: All services are running!” zurückgeliefert hat, auch der Check “Service: http git.netways.de” “HTTP OK: HTTP/1.1 200 OK” geliefert hat, und daher hat ohne manuelle Prüfung niemand vermutet, dass im Hintergrund doch etwas schief gelaufen war (z.B. die Datenbank Migration während einem Update, oder ein vergessenes skip-XXX File im /etc/gitlab Verzeichnis).

Auch wenn man das Update direkt auf der command line ausgeführt hat, konnte man in der abschliessenden Meldung nicht sehen, ob noch alles o.k. ist.

Festgestellt hat man das dann erst, wenn man sich in der GitLab Admin Area unter “Health Check” den Status angesehen hat.

Unten ein Beispiel wie es aussieht, wenn alles i.O. ist (Zur Info: Die Beispiel URL und Token gibt es nicht):

GitLab Status

D.h. ein neuer Check musste her, und den gibt es auch direkt bei GitLab zum Downloaden unter:

https://gitlab.com/6uellerBpanda/check_gitlab/blob/master/check_gitlab.rb

Der alte Check lief dabei direkt auf den einzelnen GitLab Hosts. Das war mit dem neuen Check allerdings ein Problem, weil er als Voraussetzung Ruby >2.3 hat, und wir z.B. noch einige Hosts unter Ubuntu Trusty betreiben.

Deshalb wird der neue Check direkt auf dem Monitoring Server (auch Ubuntu Trusty) ausgeführt, der zu diesem Zweck zusätzlich per rvm mit einem z.Zt. neuen Ruby 2.5.1 ausgestattet wurde, wobei im Ruby Skript das Shebang leider hardcoded eingetragen werden musste, weil es (zumindest unter Trusty) nicht anders funktioniert hatte (ohne grösseren Aufwand und vielen Änderungen an anderen Systemdateien):

#!/usr/local/rvm/rubies/ruby-2.5.1/bin/ruby

Nachdem die Token zum Zugriff im Bild oben seit einigen GitLab Versionen deprecated sind zugunsten einer IP Whitelist, hat das den Deploy des Checks zusätzlich erleichtert.

Der Aufruf des Checks sieht dann z.B. so aus:

root@icinga2-server:~# check_gitlab.rb -m health -s https://gitlab.netways.de -k
OK - Gitlab probes are in healthy state

Damit das dann auch funktioniert, muss auf der entfernten GitLab Instanz noch die IP Whitelist unter /etc/gitlab/gitlab.rb eingetragen werden:

gitlab_rails['monitoring_whitelist'] = ['127.0.0.1/8','10.XX.XX.XX/24']

Am besten checkt man natürlich nur über ein internes Netz, wie oben im Beispiel angegeben.

Das ganze kann man auch über ein GitLab Puppet Modul realisieren, indem man die Whitelist über Hiera oder Foreman verteilt:

Beispiel Hierarchie im Foreman:

gitlab:
    gitlab_rails:
      monitoring_whitelist:
      - 127.0.0.1/8
      - 10.XX.XX.XX/24  
Stefan Gundel

Autor: Stefan Gundel

Stefan ist ein Urgestein bei NETWAYS und arbeitet im Managed Services Team. Der internationale Durchbruch gelang Stefan als Fotomodel für den K+K Warenkorb. Nachdem er einige Jahre exklusiv für unseren Kunden StayFriends gearbeitet hat, darf er nun endlich auch wieder in anderen Projekten mitarbeiten.

Realisierung einer clientbasierten Zertifikats-Authentifizierung (Mutual SSL) mit selbstsignierten Zertifikaten auf Linux + Apache

This entry is part 4 of 4 in the series SSL leicht gemacht

Die IT-Landschaften der Unternehmen wachsen prächtig – und auch die Anforderungen an die Sicherheit der dort gespeicherten Daten, denn besonders sensible Daten sind für so manch einen besonders interessant.

Passwörter werden noch heute viel genutzt, aber die vergangenen Jahre haben bewiesen, dass hier vor allem der Nutzer eine Schwachstelle darstellt. Passwörter werden hier sehr bequem; also zu kurz, mehrfach auf verschiedenen Diensten oder leicht zu erraten, gewählt.

Da nützt die beste Verschlüsselung im Zweifel nicht viel, wenn das Passwort auf einer der unzähligen Passwort-Listen im Internet rumschwirrt. Auch Phishing stellt ein Problem dar und nutzt die Unaufmerksamkeit der Nutzer aus. Kürzlich erhielten wir von einem unserer Managed-Services Kunden die Anfrage, ob wir nicht dafür eine Lösung haben. Das Stichwort “clientbasierte Zertifikats-Authentifizierung” kam dabei vom Kunden. Wenn man danach sucht, findet man schnell den Fachbegriff Mutual SSL Authentication (also gegenseitige SSL Authentifikation).

Gesagt, getan. Wir haben eine Lösung auf seinem Managed-Server-System bereitgestellt und zu Abnahmetests aufgefordert – das Ergebnis überzeugt. Für den Zugang zum Webdienst des Kunden braucht man nun kein Passwort mehr und es ist sicherer als zuvor. Aber wie genau funktioniert das?

  1. Der Nutzer beantragt Zugang auf eine geschützte Ressource
  2. Der Server antwortet nun neben seinen TLS-Zertifikat mit seinem Serverzertifikat
  3. Der Client verifiziert das erhaltene Zertifikat
  4. Der Client vertraut dem Zertifikat und übersendet sein Publickey
  5. Der Server überprüft die vom Client erhaltenen Daten
  6. Der Server gewährt dem Client Zugang zum gewünschten Medium

Im nachfolgenden Beispiel werde ich die Vorgehensweise zur Erstellung der selbstsignierten Zertifikate, Konfiguration des Webservers (hier Apache) und Einbindung in den Webbrowser beschreiben. Ausgangssituation ist ein aktuelles Linux mit Apache (dieser nutzt für TLS bereits Zertifikate). Tools wie openssl und vim sehe ich jetzt mal als gegeben.

Wir wechseln zunächst auf die grüne Wiese und erstellen uns einen neuen Ordner, z. B. /usr/local/src/SSL

1. Erstellung eines firmenweiten rootca-Zertifikates-Privatekeys mit 4096 BIT Schlüssellänge

openssl genrsa -out ssl.netways.de_rootca.key 4096

2. Nun erstellen wir ein Serverzertifikat mit 10 Jahren Gültigkeit, dies kann natürlich individuell angepasst werden

openssl req -x509 -new -nodes -key ssl.netways.de_rootca.key -sha256 -days 3650 -out ssl.netways.de_rootca.pem


3. Wir erstellen einen Key unseres ersten Clients, dieser kann natürlich individuell benannt werden, damit die Unterscheidung leichter fällt

openssl genrsa -out ssl.netways.de_client1.key 4096

4. Für den soeben erstellten Client-Key erstellen wir nun eine Zertifikatsanforderung, CSR
Eine Besonderheit, ist hier dass wir als OU (also Organizational Unit, bzw. Abteilung) ein Mitarbeiter-Kürzel (im Beispiel gmimietz) angeben, dazu später mehr

openssl req -new -key ssl.netways.de_client1.key -out ssl.netways.de_client1.csr

5. Wir legen schnell die erforderlichen Daten an, damit wir nicht die ganze OpenSSL-Config umbauen müssen

mkdir -p demoCA/newcerts && mkdir demoCA/certs && mkdir demoCA/crl && echo 00 > demoCA/serial && touch demoCA/index.txt

6. Jetzt signieren wir das CSR des Clients gegen unsere Serverzertifikate und erstellen ein Clientzertifikat mit 10 Jahren Gültigkeit, dies auf Korrektheit überprüfen und bestätigen.

openssl ca -in ssl.netways.de_client1.csr -cert ssl.netways.de_rootca.pem -keyfile ssl.netways.de_rootca.key -out ssl.netways.de_client1.crt -days 3650

7. Abschließend exportieren wir das Clientzertifikat und den Key übertragungstauglich in PKCS12-Format, hierzu wird ein Passwort abgefragt, welches wir später beim Import wieder brauchen.

openssl pkcs12 -export -in ssl.netways.de_client1.crt -inkey ssl.netways.de_client1.key -out NETWAYS_Client_gmimietz.p12

8. wir kopieren unseren rootca in unser ca-Verzeichnis (wichtig, dies muss dort mit crt benannt sein, um im nächsten Schritt eingelesen zu werden)

cp /usr/local/src/SSL-TEST/ssl.netways.de_rootca.pem /usr/local/share/ca-certificates/ssl.netways.de_rootca.crt

9. Zunächst aktualisieren wir unseren Zertifikats-Store mit

update-ca-certificates

10. In der Apache-Config brauchen wir noch ein paar kleine Anpassungen innerhalb der jeweiligen vhost-Definition

SSLCACertificatePath "/etc/ssl/certs"
SSLVerifyClient require
SSLVerifyDepth 5

11. Falls wir einem Zertifikat das Vertrauen entziehen möchten, so müssten wir eine Unterscheidung sicherstellen, deshalb haben wir in Punkt 4 eine OU angegeben, diese dient nur der Unterscheidung

<location />
  SSLRequire (%{SSL_CLIENT_S_DN_OU} ne "gmimietz")
</location>

12. Final starten wir den Apache neu

service apache2 restart

13. Zertifikat auf Client importieren
Wir importieren das Zertifikat (p12-File aus Schritt 7) unseren Browser. Dazu brauchen wir unser Entschlüsselungspasswort wieder, womit wir den Export verschlüsselt haben.

Im Firefox gehen wir hierzu auf Einstellungen -> Datenschutz & Sicherheit -> Zertifikate anzeigen.
Dort importieren wir im Register “Ihre Zertifikate” nun das p12-File und geben einmalig das Passwort ein.

Für die Anlage weiterer Client-Zertifikate führen wir die Schritte 3., 4., 6., 7. erneut aus und unterscheiden mittels Nutzernamen anhand der OU.

Fertig, wird laufen. Bitte noch beachten, dass andere Vhost-Configs natürlich auch abgedichtet werden müssen, falls die in das gleiche Doc-Root mit sensiblen Daten zeigen!

Ja, so tolle Sachen machen wir – was der Kunde sich wünscht, setzen wir um!

Georg Mimietz

Autor: Georg Mimietz

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.