NETWAYS Web Services: Request Tracker

This entry is part 8 of 8 in the series NETWAYS Web Services

Unsere NWS-Produktfamilie ist um ein weiteres Mitglied gewachsen: Den BestPractical Request Tracker. Dies wird vor allem Kunden freuen, die zwar ein stabiles und zuverlässiges Ticketsystem nutzen möchten, sich aber nicht um die Bereitstellung von Ressourcen, die Installation sowie die Wartung kümmern möchten – denn all dies wird von unserer NETWAYS Web Services Plattform übernommen. Der Kunde selbst muss sich nur um eine Hand voll Voreinstellungen kümmern, die jedoch direkt über Webformulare an die App übergeben werden.

Diese Voreinstellungen umfassen folgende Aspekte, die der Kunde bereitstellen muss:

  • ein IMAP oder POP3 Postfach, von dem der Request Tracker Kundenmails abholt und daraus ein Ticket generiert. Dies stellt vor allem sicher, dass bestehende Mail-Adressen weiter genutzt werden können.
  • einen SMTP-Server, der den Versand der Mails aus dem Request Tracker steuert.

Des Weiteren bietet unsere App viele Möglichkeiten, den Request Tracker nach Belieben anzupassen. Kunden können nicht nur den Namen Ihres Request Trackers und Ihrer Organisation festlegen, sondern auch eine Zeitzone und eine eigene Absender-Mail-Adresse eintragen:

Auch innerhalb der App kann der Request Tracker hervorragend an Ihr Unternehmen angepasst werden. Es können nicht nur im administrativen Bereich User-Gruppen und Ticket-Queues erstellt werden, sondern auch das Erscheinungsbild des Tools individualisiert werden.

Wichtiger Hinweis: Alle Angebote bei den NETWAYS Web Services können Sie 30 Tage kostenfrei testen!

Nicole Lang

Autor: Nicole Lang

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest Bücher und zockt auch mal gerne.

Cloud Management – Teil 1: blkdeviotune/migrate-setmaxdowntime

This entry is part 1 of 2 in the series Cloud Management

Viele von euch haben bestimmt schon einmal von OpenNebula oder OpenStack gehört, beiden Plattformen verwenden standardmäßig libvirtd als Hypervisor, da jedoch die darunter liegende Hardware mit unter stark beansprucht werden wird, vor allem im Cloud Bereich, wo mehrerer KVM Instanzen auf einem Virt Host um CPU/Speicher/IO Resourcen konkurrieren, ist es gelegentlich notwendig die einen oder andere Instanz zu bändigen bzw. in die Schranken zu weisen.

Unsere Cloud läuft derzeit noch mit OpenNebula, wir selbst sind sehr zufrieden mit dem Stack, da sich dieser leicht Verwalten lässt und sich auch gut mit unserem Ceph als Backend verträgt, natürlich verwenden wir in unserem Cloud Stack noch andere Tools, diese sind aber nicht Gegenstand dieses Artikels, mehr dazu in späteren Teilen der Serie.

Libvirtd kann mit CLI Tools wie virsh gesteuert werden, auch besteht die Möglichkeit libvirtd über die entsprechende libvirt C API oder durch seine ScriptLanguage Bindings für ruby/python/perl/javascript/etc… anzusprechen bzw. anzusteuern zu können.

So beispielsweise unterstützt man OpenNebula wenn die Migration einer KVM Instanz von Virt Host A zu Virt Host B aufgrund von Last auf der Instanz selbst partout nicht klappen will…

root@virt1: ~ $ virsh migrate-setmaxdowntime --downtime 1800 one-8366
error: Requested operation is not valid: domain is not being migrated (dieser Fehler kommt nur wenn sich die Instanz nich im Status Migrate befindet, ist hier also nur exemplarisch mit abgebildet)

…oder wenn die Instanz AMOK läuft und somit andere Instanzen zu stark beeinträchtigt…

root@virt1: ~ $ virsh blkdeviotune one-8366 vda --live
total_bytes_sec: 62914560
read_bytes_sec : 0
write_bytes_sec: 0
total_iops_sec : 400
read_iops_sec  : 0
write_iops_sec : 0

…dann limitieren wir diese einfach ein bisschen…

root@virt1: ~ $ virsh blkdeviotune one-8366 vda --live 62914560 0 0 200 0 0

…und vergewissern uns nochmal ob unsere neuen IOPs Limits übernommen wurden…

root@virt1: ~ $ virsh blkdeviotune one-8366 vda --live
total_bytes_sec: 62914560
read_bytes_sec : 0
write_bytes_sec: 0
total_iops_sec : 200
read_iops_sec  : 0
write_iops_sec : 0

…ich denke, damit sollte klar sein worauf wir hier abzielen möchten.

In folgenden Teilen dieser Serie werden wir euch noch mehr Tips & Tricks mit auf den Weg geben, die helfen sollen eure Cloud zu bändigen bzw. aufkommende Probleme anzugehen, also bleibt gespannt. 😉

Enrico Labedzki

Autor: Enrico Labedzki

Enrico ist beruflich ganz schön rumgekommen – IT hat ihn aber immer beschäftigt. Nach einem Ausflug in die Selbstständigkeit im Bereich Webentwicklung und Network Solutions, wurde es dann Zeit Nägel mit Köpfen zu machen und endlich den Weg als Softwareentwickler und Systemintegrator einzuschlagen. In seiner Freizeit widmet sich der passionierte Bastler der Elektrotechnik und Animatronik. Bei Netways bereichert er mit seinem vielseitigen Know-How das Managed Service-Team.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 7: Objekte aus Hiera erzeugen

This entry is part 7 of 7 in the series Icinga 2 Monitoring automatisiert mit Puppet

Vor einiger Zeit trat der Wunsch auf mit dem aktuellen Icinga-2-Modul für Puppet beliebe Objekte aus Hiera heraus zu erzeugen. Zum Beispiel aus folgender Hiera-Datei sollen ein Host-Objekt und zwei Service-Objekte gebaut werden.

---
monitoring::object:
  'icinga2::object::host':
    centos7.localdomain:
      address: 127.0.0.1
      vars:
        os: Linux
  'icinga2::object::service':
    ping4:
      check_command: ping4
      apply: true
      assign: 
        - host.address
    ssh:
      check_command: ssh
      apply: true
      assign:
        - host.address && host.vars.os == Linux

In Puppet 4 lässt sich dies nun sehr einfach mit zwei Schleifen realisieren:

class { 'icinga2':
  manage_repo => true,
}

$default = lookup('monitoring::default')

lookup('monitoring::object').each |String $object_type, Hash $content| {
  $content.each |String $object_name, Hash $object_config| {
    ensure_resource(
      $object_type,
      $object_name,
      deep_merge($default[$type], $object_config))
  }
}

Hierbei sind sogar für jeden Objekt-Type auch noch Defaults in Hiera gesetzt, z.B. in einer Datei common.yaml, die immer gelesen wird.

---
monitoring::default:
  'icinga2::object::host':
    import:
      - generic-host
    target: /etc/icinga2/conf.d/hosts.conf
  'icinga2::object::service':
    import:
      - generic-service
    target: /etc/icinga2/conf.d/services.conf

Dieses Verfahren ist mit dem selben Code auf Objekte mit allen möglichen Objekt-Typen erweiterbar. Passt man den Funktionsaufruf von lookup entsprechend an, kann auch über die Hiera-Struktur gemerged werden.

Lennart Betz

Autor: Lennart Betz

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

“Willkommen auf der dunklen Seite der Macht, Alexander …”

Nein, ich meine nicht die antagonistische Fraktion aus einer sehr populären Filmreihe (deren Name nicht genannt werden muss), sondern die Apple-Fraktion bei NETWAYS.

Letzten Monat habe ich nämlich meine Ausbildung zum Fachinformatiker für Anwendungsentwicklung abgeschlossen und wurde in die Development-Abteilung übernommen.

Neuer Status – neues Gehalt, neue Aufgaben … und neues Arbeitsgerät. Ich habe mich bewusst für ein MacBook Pro entschieden, weil auf dieser Plattform sehr vieles viel besser und einfacher funktioniert und ich nicht bei jeder Kleinigkeit erst den Linux-Kernel patchen und neu kompilieren, SELinux abschalten oder die IPTables-Regeln anpassen muss. 😉

Wer weiß wann ich mit dem nächsten Kunden von Angesicht zu Angesicht zu tun haben werde – diesbzgl. will ich keine Risiken eingehen.

Abstriche muss ich keine machen – schließlich bietet MacOS X alles, was das Entwickler-Herz begehrt. Außer vielleicht …

Container

Auf Linux haben sie sich breit gemacht wie ein Türsteher: Docker, LXC, LXD und wie sie alle heißen. Auch BSD macht mit seinen Jails keine Kompromisse in Sachen Virtualisierung und Sicherheit.

Umso mehr wundert es mich, dass das BSD-basierende MacOS X dieses Feature nicht übernommen hat. Aber es wäre kein *nix-System, wenn man das nicht mit ein wenig Geschick nachrüsten könnte …

Dann eben so …

Auf meinem alten Arbeitsgerät habe ich Ubuntu 16.04 verwendet. Diese GNU/Linux-Distribution enthält von Haus aus LXD in den Paketquellen, womit ich in einer leichtgewichtigen und sicher isolierten Umgebung mal schnell was ausprobieren konnte.

Dieses Werkzeug kann ich mit einer Virtuellen Maschine problemlos weiterhin verwenden – nicht nur in der VM selbst, sondern auch vom Mac-Host aus. Genau dafür braucht man das o. g. “wenig Geschick” …

LXD Server einrichten

Man logge sich in die VM ein und erlange Administratorrechte. Dann installiert man LXD und richtet diesen darauf hin ein:

$ sudo -i
(...)
# apt install lxd
(...)
# lxd init
Name of the storage backend to use (dir or zfs) [default=dir]: 
Would you like LXD to be available over the network (yes/no) [default=no]? yes
Address to bind LXD to (not including port) [default=all]: 
Port to bind LXD to [default=8443]: 
Trust password for new clients: 
Again: 
Do you want to configure the LXD bridge (yes/no) [default=yes]?

Fast alle Abfragen des Installations-Assistenten können bedenkenlos mit der Eingabetaste bestätigt werden. Die von mir hervorgehobene Frage allerdings muss mit “yes” beantwortet werden – ansonsten fällt die Nutzung vom Host aus ins Wasser. Außerdem muss ein einigermaßen sicheres Passwort gewählt werden.

Der Frage nach der “LXD bridge” folgt ein weiterer, “pseudo-grafischer” Installations-Assistent. Dessen Fragen kann man ausnahmslos mit der Eingabetaste bestätigen.

Des weiteren wird später die IP der VM benötigt:

# ifconfig
enp0s5    Link encap:Ethernet  HWaddr 00:1c:42:8b:e9:ba  
          inet addr:10.211.55.19  Bcast:10.211.55.255  Mask:255.255.255.0
          inet6 addr: fdb2:2c26:f4e4:0:880a:a527:1a6:1130/64 Scope:Global
          inet6 addr: fdb2:2c26:f4e4:0:fc54:870c:56af:cba0/64 Scope:Global
          inet6 addr: fe80::fbc7:ab4d:d29f:e227/64 Scope:Link
(...)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
(...)

lxdbr0    Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
          inet addr:10.83.127.1  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fdb3:61e3:ffb6:f62f::1/64 Scope:Global
          inet6 addr: fe80::4024:c9ff:fe4a:691b/64 Scope:Link
(...)

LXD Client einrichten

Da die Entwickler von LXD sich bemüht haben, nicht von Linux-spezifischen Funktionalitäten Gebrauch zu machen, funktioniert der LXD Client auch auf MacOS. Den muss man nur noch vom LXD Server in Kenntnis setzen.

Sobald das getan ist, kann auch schon der erste Container in Betrieb genommen werden.

$ brew install lxc
(...)
$ lxc remote add u1604vm 10.211.55.19
Certificate fingerprint: a761f551dffdf47d9145da2aa16b4f6be242d960ce1697994c969e495b0724fd
ok (y/n)? y
Admin password for u1604vm:
Client certificate stored at server:  u1604vm
$ lxc launch ubuntu:16.04 u1604vm:test1
Creating test1
Starting test1ge: rootfs: 100% (37.78MB/s)
$ lxc exec u1604vm:test1 -- bash
root@test1:~# man perlfunc

Fazit

Es muss nicht immer Docker sein.

Gerade wenn das Testsystem sich möglichst so verhalten soll wie eine VM oder eine Physische Maschine ist LXD auf jeden Fall einen Blick Wert – auch auf dem Mac.

Alexander Klimov

Autor: Alexander Klimov

Alexander hat 2017 seine Ausbildung zum Developer bei NETWAYS erfolgreich abgeschlossen. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der Arbeit an Icinga Web 2 bei uns friedliche Wege.

SSL leicht gemacht – Zertifikat einbinden (Apache2)

This entry is part 1 of 3 in the series SSL leicht gemacht

In meinem letzten Blogpost habe ich über die Erstellung eines Keyfiles und eines CSR geschrieben. Im zweiten Teil meiner Serie SSL leicht gemacht zeige ich den nächsten Schritt und beschreibe die Einrichtung des Zertifikates mittels der Webserversoftware Apache.

Bestandsaufnahme:
nun sollten folgende Dateien vorhanden sein

  • selbst erstellt
    • CSR (in unserem Beispiel netways.de.csr)
    • Privatekey (netways.de.key)
  • von Zertifizierungsstelle erstellt und übermittelt
    • cert.cabundle
    • certificate.crt

Diese Zertifikatsdateien können jetzt auf dem Webserver eingerichtet werden.

Als nächstes werden die Zertifikatsdateien im korrekten Verzeichnis abgelegt. Hierzu eignet sich zum Beispiel /etc/apache2/ssl/netways.de/. Hier sollte die Zusammengehörigkeit der einzelnen Dateien noch einmal überprüft werden. Der CSR wird übrigens nicht mehr benötigt und kann gelöscht werden.
Apache kann im Moment noch nichts mit den Zertifikatsdateien anfangen und noch lernen “SSL zu sprechen”. Dazu wird ein SSL-VHost eingerichtet. Als Basis hierfür kann der abzusichernde VHost vorerst kopiert werden.

cp /etc/apache2/sites-available/001-netways.de.conf /etc/apache2/sites-available/001-netways.de-ssl.conf

Diese neue SSL-Config wird nun angepasst, damit der Apache nun weiß, was er zu tun hat.

Innerhalb der nun betreffenden VHost-Definition werden nun noch ein paar Paramater für SSL angegeben

SSLEngine on
 SSLCertificateKeyFile /etc/apache2/ssl/netways.de/netways.de.key
 SSLCertificateFile /etc/apache2/ssl/netways.de/certificate.crt
 SSLCertificateChainFile /etc/apache2/ssl/netways.de/cert.cabundle

Übrigens in der Einleitung der VHost-Definition (i. d. R. ganz oben in der neuen Datei) sollte der angegebene Port 80 auf 443 geändert werden.

<VirtualHost 123.456.789.012:80> auf <VirtualHost 123.456.789.012:443>

Abschließend wird der Apache noch um ein paar Funktionalitäten erweitert (SSL und der neue VHost wird aktiviert):

a2enmod ssl
a2ensite 001-netways.de-ssl.conf
service apache2 restart

Der VHost ist nun zusätzlich mit SSL abgesichert und in unserem Beispiel via https://netways.de und http://netways.de erreichbar. Ob alles geklappt hat, sieht man nun am erfolgreichen Verbindungsaufbau via HTTPS oder kann es zum Beispiel bei SSL Labs ausführlich prüfen lassen.

Die Namensgebung der Zertifikate unterscheidet sich von Zertifizierungsstelle zu Zertifizierungsstelle und kann auch mal mit .pem bezeichnet sein usw. Dies kann “ignoriert” werden und beliebig selbst in der Config auf die neuen Endungen angepasst werden. Auch eine Umbenennung der Dateien auf das eigene Schema ist ein möglicher Lösungsansatz.

In den anderen (teilweise noch kommenden) Blogposts zum Thema SSL leicht gemacht geht es um:

Übrigens: Zertifikate müssen nichts kosten. Eine Alternative mittels Letsencrypt ist hier beschrieben.

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.

Github Topics – Ein kleiner Blick in die Zukunft

Wir sind seit einiger Zeit damit beschäftigt, Icinga Exchange in neuem Licht erstrahlen zu lassen. Neben einem neuen Design wird es allerdings auch einige andere Änderungen und Neuerungen geben.

Eine dieser Neuerungen wird eine stärkere Github Integration sein. Wir werden unter anderem die bisher notwendige yaml Datei ablösen, indem wir Details über von Github synchronisierte Projekte über die API von Github abrufen. Dabei ist uns eine neue Funktion von Github ins Auge gefallen: Topics.

Diese ist seit Anfang des Jahres verfügbar und erlaubt es einem Repository bestimmte Begriffe zuzuordnen, ganz ähnlich den auf Icinga Exchange bekannten Tags. Mit der üblichen URL um Details zu einem Repository abzurufen wird man jedoch nicht fündig:

https://api.github.com/repos/<owner>/<repository>

Aktuell fand diese Funktion noch keinen Einzug in die offizielle API. Stattdessen muss man explizit angeben, eine bestimmte preview Version der API benutzen zu wollen, damit zugeordnete Topics in den Details ebenfalls erscheinen.

Dies erreicht man bei Github mit bestimmten media types im Accept header:

Accept:application/vnd.github[.version].param[+json]

(Alle preview Versionen gibt es hier)

Um also über die API auf die Topics zuzugreifen, wird folgender media type benötigt:

Accept:application/vnd.github.mercy-preview

In der Antwort der API erscheint daraufhin ein neuer Eintrag:

{
  ...
  "topics": [
    "exchange",
    "icinga",
    "snmp"
  ],
  ...
}

Weil diese Funktion aber noch nicht Bestandteil der offiziellen API ist, werden wir vermutlich vorerst davon absehen diese in Icinga Exchange zu benutzen. Wir hoffen jedoch, dass sie bald Bestandteil der offiziellen wird oder absehbar ist, dass sie es sicher werden wird.

Ach, bevor Ihr fragt: Nein, wir haben noch keinen Release Zeitpunkt für die neue Version von Icinga Exchange. Aber vermutlich noch dieses Jahr. 😛

Johannes Meyer

Autor: Johannes Meyer

Johannes ist seit 2011 bei uns und hilft bei der Entwicklung zukünftiger Knüller (Icinga2, Icinga Web 2, ...) aus dem Hause NETWAYS.