tooltip httrack

Bild der httrack WeibseiteIch stand letzte Woche vor einem kleinen Problem. Ein Freund von mir möchte seine WordPress-Seite aufgeben. Allerdings möchte er auch gerne ein Backup haben um, wie in einem Photoalbum, die schönsten Momente seines Blogs Revue passieren zu lassen.

Mit einem einem normalen “hier, DB-dump” war diesem Freund kein stück weitergeholfen und auch ein “Dann fahr dir das Setup doch in nem Docker hoch” stellte sich als nicht so zielführend heraus.

Also brauche ich ein Original-Weibseiten-Abbild, dass auch ohne DB, webserver und php schön aussieht und in weiten Teilen funktioniert.

Die einfache Lösung war für mich httrack. Ein tool das einfach genau das kann.

Kurzanleitung:

  1. installieren
  2. mkdir myExample; cd myExample
  3. httrack http://example.org

Für mich war noch der schalter –language de hilfreich. Um meine Wunschseite auch in der Wunschsprache herunterzuladen.

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

NETWAYS Cloud: Alles im Griff mit API

Die Nutzung von APIs ist in der modernen Softwareentwicklung nicht mehr wegzudenken und ein zentraler Bestandteil einer funktionierenden DevOps-Strategie. Mit einer API können Applikationen, die voneinander unabhängig sind, miteinander arbeiten und Daten austauschen.

Wozu brauche ich APIs?
APIs setzt man immer dann ein, wenn man einen hohen Grad an Automatisierung erreichen und eine dynamische und programmatische Infrastruktur aufbauen und betreiben will.

Was können wir?
Wir setzen bei unserem Cloud-Angebot auf nws.netways.de auf OpenStack und stellen somit unseren Hostingkunden auch die verfügbaren OpenStack-APIs zur Verfügung. APIs gibt es für alle OpenStack-IaaS-Komponenten in der NETWAYS Cloud: Compute (VMs), Storage (S3, Volumes, Images) und Network (VPNaaS, SDN, Firewall usw.).

Die OpenStack-APIs kannst Du verwenden, um Serverinstanzen zu starten, Images zu erstellen, Instanzen und Images Metadaten zuzuweisen, Speichercontainer und -objekte zu erstellen und andere Aktionen in deiner OpenStack-IaaS Instanz auszuführen.

Zielgruppe
Entwickler, Admins, DevOps und alle, die sich voll auf Ihre Anwendungen konzentrieren wollen.

Wie kann ich loslegen?
Einfach unter nws.netways.de einen Account anlegen und loslegen. Und bei Bedarf steht unser MyEngineer bei jedem Projektschritt mit zur Seite.

Martin Krodel
Martin Krodel
Head of Sales

Der studierte Volljurist leitet bei NETWAYS die Sales Abteilung und berät unsere Kunden bei ihren Monitoring- und Hosting-Projekten. Privat reist er gerne durch die Weltgeschichte und widmet sich seinem ständig wachsenden Fuhrpark an Apple Hardware.

Glossar für SMS Gateways

 

Bei SMS Gateways gibt es sehr viele Fachbegriffe, bei denen sich viele hart tun, sie zu verstehen. Gerade für Anfänger klingt das oft wie eine andere Sprache. Doch was bedeuten diese Begriffe?

 

Hier eine kleine Übersicht über ein paar Fachbegriffe:

Message templates Message templates sind Nachrichtenformate für häufig wiederverwendete Nachrichten, die ein Unternehmen möglicherweise senden möchte. Man kann eine Textnachricht generieren und diese kann immer wieder verwendet bzw. mit Auto-reply automatisch versendet werden.
Multiuser support Jeder Benutzer hat einen eigenen Account. Meist hat er damit Zugriff auf einen privaten Posteingang, Postausgang und gesendete Objekte.
SMS alerting Mit SMS alerting hat man die Möglichkeit, mehrere automatische Antwortregeln zu gernerieren.
Auto-reply to incoming SMS Das Auto-reply Plugin ermöglicht es, automatisch auf empfangene Nachrichten mit einer definierten Textantwort (Message templates) zu antworten. Der Benutzer kann viele Autoreply-Regeln definieren, und jede Regel wird unabhängig verarbeitet.
Email to SMS Wie der Name schon sagt kann man mit dem Email-to-SMS-Plugin eingehenden E-Mails als SMS weiterleiten
SMS to Email Andersherum als bei Email-to-SMS können mit dem SMS-to-Email-Plugin eingehenden SMS-Nachrichten an eine E-Mail-Adresse weitergeleitet werden.
Digital input and output Viele SMS Gateways sind mit digitalen Eingängen und Ausgängen ausgestattet. Die digitalen Eingänge können verwendet werden, um Signale von externen Sensoren oder Geräten zu empfangen und das Senden von SMS-Nachrichten basierend auf dem Eingangsstatus automatisch auszulösen. Andererseits können die digitalen Ausgänge verwendet werden, um externe, angeschlossene Geräte zu aktivieren, wenn bestimmte SMS-Nachrichten vom SMS Gateway empfangen werden.
HTTP/HTTPS API Zum Senden von SMS von externen Anwendungen und Systemen. Diese API eignet sich vor allem zum Automatisieren des Nachrichtenversands.

[Das Hypertext Transfer Protocol ist ein zustandsloses Protokoll zur Übertragung von Daten auf der Anwendungsschicht über ein Rechnernetz. Es wird hauptsächlich eingesetzt, um Webseiten aus dem World Wide Web in einen Webbrowser zu laden.]

NTP client Die Abkürzung NTP steht für Network Time Protocol. NTP kann zur Synchronisierung von Uhren in Computersystemen über paketbasierte Kommunikationsnetze verwendet werden. Es wurde entwickelt, um eine zuverlässige Zeitangabe über Netzwerke mit variabler Paketlaufzeit zu ermöglichen. Im allgemeinen Sprachgebrauch bezeichnet NTP sowohl das Protokoll als auch die Software-Referenzimplementierung desselben.
SNMP agent Das Simple Network Management Protocol kann zum Auslesen von Werten des Gateways genutzt werden. Die MIBs hierfür werden meist von den Herstellern öffentlich zur Verfügung gestellt, sodass bei einem SMS Gateway z. B. die Funksignal-Stärke, die Länge der SMS-Outbox, die Anzahl der versendeten Nachrichten, Sendefehler und weitere Werte abgerufen werden können.
Delivery reports Delivery reports sind zuständig für Zustellungsberichte die automatisch per E-Mail gesendet werden. Man kann ablesen, wie viele Nachrichten gesendet wurden, wie viele erfolgreich waren und wie viele fehlgeschlagen sind.
Watchdog mechanisms Ein Watchdog ist ein Mechanismus, der bei Gateways z. B. dafür sorgt, dass automatisch Alarme per SMS versendet werden, wenn ein Fehler auftritt. Ein solcher Fehler kann z. B. der Netzwerkverlust über LAN darstellen.

Ich hoffe, das Glossar war hilfreich und erleichtert die nächste Bestellung im NETWAYS Shop. 😉

Wir sind jederzeit für Euch erreichbar per Mail: shop@netways.de oder telefonisch unter der 0911 92885-44. Wer uns gerne bei der Arbeit ein bisschen über die Schulter schauen oder den Shop und die angebotenen Produkte verfolgen möchte, kann uns auch auf Twitter folgen – über @NetwaysShop twittert das NETWAYS Shop Team. Bleibt gesund – wir freuen uns auf Euch!

Natalie Regn
Natalie Regn
Junior Office Manager

Natalie macht seit September 2019 ihre Ausbildung zur Kauffrau für Büromanagement hier bei NETWAYS. Vor ihrer Zeit bei NETWAYS war sie ein Jahr als Au-pair in Schottland unterwegs. Passend dazu widmet sie sich seit vielen Jahren dem Spielen der Great Highland Bagpipe. Natalie ist in ihrer Freizeit nicht nur musikalisch unterwegs, sondern auch sportlich. Sie trainiert im Fitnessstudio, geht gerne in den Kletterpark und in die Trampolinhalle.

Plugins, Provider, PowerShell

Im Icinga-Windows-Kosmos passiert in letzter Zeit sehr viel, vor allem durch das Zauberwort PowerShell. Framework, Plugins, Kickstart und Service, das alles hört man recht oft und auch neue Releases sind da oder stehen an. Doch wie schreibe ich meine eigenen Checks beziehungsweise Plugins? Gibt es Vorschriften an die ich mich halten sollte? Und kann ich mich auch an dem Projekt beteiligen?

Plugins und Provider

Als das Projekt gestartet worden ist, war es bereits angedacht, dass Plugins individuell anpassbar sein sollten. Um dies zu gewährleisten, war es wichtig die Daten, die zur Prüfung genutzt werden in einer normierten Form gesammelt zurückzugeben und hier kommen die Provider ins Spiel.

Was ist ein Provider?

Ein Provider sammelt Daten vom System und stellt sie zur Verfügung um in Plugins genutzt zu werden. Sehen wir uns das ganze im icinga-powershell-plugins repository an:
└── provider
├── bios
├── cpu
├── directory
├── disks
├── enums
├── eventlog
├── memory
├── process
├── services
├── updates
├── users
└── windows

Innerhalb dieser Verzeichnisse befinden sich in der Regel zwei Dateien. Im Falle von CPU wären das Icinga_ProviderCpu.psm1 und Show-IcingaCpuData.psm1. Respektive Dateien existieren auch in allen anderen Verzeichnissen.

Mit dem gleichnamigen Befehl Show-IcingaCpuData kann man nun alle generischen Daten zur Thematik CPU abfragen. Während die Datei Icinga_ProviderCpu.psm1 verschiedene Funktionen enthält um spezifische Daten anzufordern. Darunter zum Beispiel folgende Funktionen: Get-IcingaCPUArchitecture, Get-IcingaCPUArchitecture.

Im Falle von Get-IcingaCPUs könnte der Output beziehungsweise die bezogenen Daten, wie folgt aussehen – gekürzt und in JSON konvertiert:
{
"specs":  {
"L3CacheSize":  0,
"CurrentClockSpeed":  2100,
"VoltageCaps":  0,
"L2CacheSpeed":  null,
"ThreadCount":  1,
"CurrentVoltage":  null,
"LoadPercentage":  7,
"L2CacheSize":  null
},
"errors":  {
"ErrorDescription":  null,
"ErrorCleared":  null,
"ConfigManagerErrorCode":  {
"value":  "This device is working properly.",
"raw":  0
},
"LastErrorCode":  null
},
"metadata":  {
"ProcessorType":  {
"value":  "Central Processor",
"raw":  3
},
...
"SocketDesignation":  "CPU 1",
"ProcessorID":  "078BFBFF000306A9",
"NumberOfCores":  1,
"SerialNumber":  "",
"Architecture":  {
"value":  "x64",
"raw":  9
},
"Availability":  {

},
"AddressWidth":  64,
"Status":  "OK",
"StatusInfo":  {
"value":  "Enabled",
"raw":  3
},

}

Auf diese Daten können wir nun Aufbauen. Ob die Daten direkt zuträglich sind oder ausreichend für unsere Anwendung ist individuell.

Bevor ich ein Plugin schreibe!

Bevor es dazu kommt, dass man ein Plugin schreibt und Unmengen an Cmdlets benutzt und die Daten normiert, sollte man sich darüber im Klaren sein, was es alles für Provider gibt und vorher überprüfen, ob die Daten nicht in der ein oder anderen Form bereits vorhanden sind.

Gefällt mir etwas am Invoke-IcingaCheckCPUs Check nicht, dann ist es sinnig, zumindest zunächst den Provider des Check-Plugins zu betrachten und zu prüfen ob man nicht die Informationen die der Check erhält anders nutzen kann.

Falls das nicht der Fall ist, sollte man seinen eigenen Provider schreiben oder einen vorhanden ergänzen und uns vielleicht mit einen Pull-Request überraschen.

Aber wohin das Ganze?

Damit nicht alles verloren ist beim nächsten Update oder Konflikte auftreten, gibt es im Icinga-PowerShell-Framework ein Custom-Verzeichnis. Dieses unterteilt sich wiederum in /lib und /plugins. In das plugins-Verzeichnis kommen folgerichtig natürlich die Plugins, die ihr für euch individuell anlegt und die nicht oder noch nicht Teil des Repositorys sind.

Das Gleiche gilt natürlich auf für das Library-Verzeichnis. Wenn ihr das Rad neu erfinden wollt und ein Custom-Module baut für Test-Numeric oder euch das Ausgabeformat von Convert-Bytes stört, dann sind eure Tools hier sicher. Und natürlich auch da freuen wir uns über einen Pull-Request.

Wir halten fest, wenn man also ein Plugin baut, dann sollte man ein eigenes PowerShell Modul bauen und sich dabei weitestgehend zunächst an den vorhandenen Plugins orientieren und aufpassen, wo was hingehört.

Fazit

Wer es richtig machen will, fängt langsam an und baut vor allem modular. Erst der Provider, dann das eigentliche Check-Plugin. Desto größer der Provider, desto einfacher das Bauen der Check-Plugins, weil mit bereits vorhanden Informationen ist die Logik, der Check-Prüfung das wenigste Problem.

Wem das alles noch nicht genug ist, der kann auch mal auf unserem Youtube-Channel vorbei schauen, wo wir im Umfang unserer Webinare mit unter Custom Plugin Development und Custom Daemon Development besprochen haben.

Seit in jeden Fall gespannt wie es mit dem Projekt weitergeht und für noch mehr zum Thema Plugin schreiben schaut euch den Developer-Guide an.

Alexander Stoll
Alexander Stoll
Junior Consultant

Alexander ist ein Organisationstalent und außerdem seit Kurzem Azubi im Professional Services. Wenn er nicht bei NETWAYS ist, sieht sein Tagesablauf so aus: Montag, Dienstag, Mittwoch Sport - Donnerstag Pen and Paper und ein Wochenende ohne Pläne. Den Sportteil lässt er gern auch mal ausfallen.

NETWAYS stellt sich vor- Ravi Srinivasa

This entry is part 3 of 26 in the series NETWAYS stellt sich vor

 

Name: Ravi Kumar Kempapura Srinivasa

Alter: 27

Position bei NETWAYS: Developer

Ausbildung: M.Sc. in Communications and Multimedia Engineering

Bei NETWAYS seit: November 2019

 

 

Wie bist du zu NETWAYS gekommen und was genau gehört zu Deinem Aufgabenbereich

Als ich mein Masterstudium abgeschlossen hatte war ich auf Jobsuche. Auf der Nürnberger Job-Messe traf ich Eric, und gab ihm meinen Lebenslauf. Daraufhin wurde ich zu einem Vorstellungsgespräch eingeladen und wurde eingestellt.

Meine Aufgaben sind vielfältig. Ich arbeite im Bereich Development und aktuell habe ich Aufgaben wie Erweiterung von Funktionen, Ausbesserungen in Icinga Web und auch Entwicklung des Icinga- Event Webs.

Was macht Dir an Deiner Arbeit am meisten Spaß? 

Die Arbeit im Bereich Development macht mir sehr viel Spaß, und ich lerne jeden Tag etwas Neues dazu. Jeder arbeitet in seinem eigenen Tempo, auf seine eigene Weise und ich kann jederzeit fragen, wenn ich etwas nicht verstehe.

Was machst Du, wenn Du mal nicht bei NETWAYS bist? 

Nach der Arbeit gehe ich oft ins Fitness Studio. Am Wochenende schaue ich gerne Netflix oder lerne online etwas, das mit Programmieren zu tun hat.

Wie geht es in Zukunft bei Dir weiter

Ich würde künftig gerne Machine-Learning ins Monitoring integrieren.

Ravi Srinivasa
Ravi Srinivasa
Developer