Teamevent 2017: NETWAYS Managed Services

Auch dieses Jahr hat sich das NETWAYS Managed Services Team wieder zusammengesetzt, um nicht nur das vergangene Jahr Revue passieren zu lassen, sondern auch um den aktuellen Stand des Teams zu analysieren und dessen Zukunft proaktiv zu gestalten. Genauso wenig durften aber auch der Zusammenhalt und der Umgang miteinander zu kurz kommen.

Das Team hatte sich hierzu in der Wutzschleife in der Oberpfalz einquartiert und den Konferenzraum bezogen. Die Wutzschleife ist ein Hotel, das sehr schön in der ruhigen Landschaft liegt und alles bietet, was der Gast benötigt.

Los ging es um 10:00 Uhr mit einem Überblick über das Team und dessen Aktivitäten im letzten Jahr durch unseren Teamleiter Sebastian Saemann. Sehr interessant war hier unter anderem die Visualisierung unserer Arbeit in unserem Infrastruktur Git-Repository. Durch das animierte Video wurde sehr deutlich, wieviel daran gearbeitet und verändert wurde.

Nach diesem Rück- und Einblick konnten wir es uns erstmal am Mittagsbuffet gut gehen lassen und ausgiebig die Küche der Wutzschleife genießen.

Nach dem MIttagessen gingen wir über zu Rollenspielen, die es den einzelnen Teammitgliedern erlaubten, sich in verschiedenen Situationen nicht nur in die Lage der Kollegen sondern auch in die Lage von Kunden zu versetzen. Für uns war dies sehr lehrreich, da die Rollen spontan verteilt wurden und man ohne Vorbereitung mit nur ein paar wenigen Stichpunkten die Situation meistern musste.

Nach den Rollenspiele gab es einen sogenannten Open Space, den die Gruppe selbstständig ausfüllen sollte. Nach einer Abstimmung war klar, dass das Team sich mit dem Thema “Fort- und Weiterbildung” beschäftigen wollte. Auch dies war recht produktiv, da neben allgemeinen Fakten zu diesem Thema auch Meinungen ausgetauscht und Anregungen in die Runde geworfen werden konnten.

Es dauerte auch nicht lange und das Team rückte wieder im Speisesaal ein um über das Abendbuffet herzufallen. Dies war jedoch gerechtfertigt, da wir uns für das GoKart-Rennen am Samstag gut stärken mussten!

Wie bereits gesagt, ging es am Samstag nach dem Frühstück los nach Wackersdorf zu Prokart Raceland, wo wir dann zur Abwechslung knallharte Konkurrenten anstelle von Kollegen waren. Aber auch ein Kräftemessen kann ja manchmal ganz amüsant sein!

Das NETWAYS Managed Services Team möchte sich nochmals herzlich beim Team der Wutzschleife und bei Prokart Raceland für díe tolle Umsetzung unseres Teamevents bedanken!

 

 

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.

Shopware Update

Jeder nutzt für seine Dienste die verschiedensten Tools. Wir bei NETWAYS kümmern uns im Hosting Bereich für Sie um eben diese Dienste und Tools, sodass Sie als User sich damit nicht beschäftigen müssen.
In diesem Rahmen betreuen wir auch Shopware Installationen unserer Kunden.
Jedoch wollen derartige Dienste auch Updates um aktuell zu bleiben. Ein Shopware Update ist meist nichts großes. Dennoch gibt es hier auch nicht nur eine Variante, wie diese am besten durchzuführen sind. Die Variante die für mich die “beste” ist, möchte ich hier kurz vorstellen.


Schritt 1

Zunächst benötigt man das Paket des jeweiligen Updates. Diese können hier heruntergeladen werden. Im Anschluss kurz entpacken und schon kann es los gehen. Wichtig hierbei ist, dass die Dateien des Updates, die Dateien der Shopware Installation überschreiben.

Deswegen: Ein Backup rettet manchmal jeden Admin! Dies gilt auch für die DB, da diese ebenfalls bearbeitet wird.

Schritt 2
Das Update einspielen.

root@shopware:/tmp# cp -a -R /tmp/update_5/update_5/* /var/www/shopware_directory

Schritt 3
Im Endeffekt war es das auch schon. Unter http://shopware-test.meinedomain.com/recovery/update kann nun das Update gestartet werden. Hier passiert bis auf einige wenige Klicks alles automatisch. Nach dem erfolgreichen Update, muss noch ein Ordner gelöscht werden, sodass das System wieder freigegeben wird.

root@shopware:/var/www/shopware_directory# rm -rf /update-assets

Nun sind keine weiteren Schritte mehr nötig. Auf Fehlermeldungen muss natürlich individuell eingegangen werden. Sollten Sie hierbei auf Probleme stoßen oder möchten ebenfalls eine Umgebung aufbauen, können Sie gerne Kontakt zu uns aufnehmen.

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz

Braintower SMS Gateway: Die Support Optionen

Wahrscheinlich kennen Sie bereits unsere SMS Gateways von Braintower. Kaufen Sie die Ware bei uns, bekommen Sie von uns das Rundum-Sorglos-Paket was den zeitnahen Versand, die Bearbeitung von möglichen Reklamationen und die aktuellsten Informationen rund um das Produkt angeht. Sollten Sie darüber hinaus auch Interesse an einem 1:1 Austausch innerhalb von 24 Stunden im Falle eines Defektes Interesse haben, empfehlen wird die Braintower Support Option Desktop Edition oder die Braintower Support Option Rack Edition.

Wem das nicht reicht, der kann nun auch auf den  telefonischen 24/7-Support in Form der Braintower 24/7 Support Option: Desktop Edition oder Braintower 24/7 Support Option: Rack Edition zurückgreifen. Mit diesen neuen Optionen sind nun die Spezialisten von Braintower rund um die Uhr, 365 Tage im Jahr für Sie erreichbar. Fantastisch, oder?

Alle Supportoptionen können auch nachträglich, also nach dem Einkauf gebucht werden. Dabei ist es nur wichtig, dass sich das Gerät zum Buchungszeitpunkt noch in der Gewährleistungsfrist (12 Monate ab Kaufdatum) befindet. Eine Buchung ist bis zu 5 Jahre möglich. Der Vertrag verlängert sich NICHT automatisch.

Sie haben noch kein Braintower SMS Gateway? Dann wird es aber Zeit:

Braintower-SMS-Gateway-Desktop

 

Braintower SMS Gateway Desktop Edition

 

 

Braintower-SMS-Gateway-Rack

 

Braintower SMS Gateway Rack Edition 

 

 

Übrigens: Zu den Braintower SMS Gateways gibt es zahlreiche zubuchbare Software Optionen, die Ihnen gefallen könnten. Schauen Sie sich einfach einmal in bei den Braintower Erweiterungen um.

Isabel Salampasidis

Autor: Isabel Salampasidis

Isabel ist seit Februar zurück bei NETWAYS. Bis 2009 war sie unsere Office Managerin und verstärkt nun ab sofort das Sales Team. Hier ist sie für alle Belange des Online Stores verantwortlich. Der Ein- und Verkauf der Monitoring Hardware sowie die Weiterentwicklung des Shops und seines Portfolios wird sie mit ihrem bekannten Tatendrang gehörig vorantreiben. Privat verbringt die halbgriechische Ruhrpott-Fränkin sehr gerne so viel Zeit wie möglich mit ihren bald 4-jährigen Patensöhnen oder schreit sich für den Club - als stolze Dauerkartenbesitzerin! - die Seele aus dem Leib.

Revisited – Graphite-Web installation unter Debian 9

Erstmal wieso Revisited ?

Dies ist ein update meines älteren Blog Posts Blogpost 2016 welcher darauf einging das unter Debian 8.4 graphite-web wegen eines Fehlenden Eintrages in der Apache 2.4 Konfiguration nicht korrekt gestartet/aufgerufen werden konnte.
Es ist schon einige Zeit ins Land gegangen und ich habe weniger ein Auge darauf geworfen ob das weiterhin so Funktioniert.
Deshalb Revisited.

Here we Go again !

Ich gehe in diesem Fall von einer Debian Version der Nummer 9 aus und werde wie bei dem alten Blogpost. In der Grundannahme mal davon ausgehen das alles Funktioniert wie es soll:

Also hier die folgenden installationschritte:

#> apt-get install apache2 libapache2-mod-wsgi python-django python-django-tagging fontconfig python-tz python-pip python-dev python-twisted python-cairo
#> pip install carbon whisper graphite-web
#> pip install --upgrade twisted
#> cp /opt/graphite/conf/carbon.conf.example /opt/graphite/conf/carbon.conf
#> cp /opt/graphite/conf/storage-schemas.conf.example /opt/graphite/conf/storage-schemas.conf
#> /opt/graphite/bin/carbon-cache.py start
#> /opt/graphite/bin/carbon-cache.py status
#> cp /opt/graphite/examples/example-graphite-vhost.conf /etc/apache2/sites-available/graphite.conf
#> cp /opt/graphite/conf/graphite.wsgi.example /opt/graphite/conf/graphite.wsgi
#> cp /opt/graphite/webapp/graphite/local_settings.py.example \ /opt/graphite/webapp/graphite/local_settings.py
#> python /opt/graphite/webapp/graphite/manage.py syncdb
#> chown www-data. -R /opt/graphite/storage
#> a2dissite 000-default
#> a2ensite graphite
#> a2enmod wsgi
#> service apache2 restart
#> chmod +x /etc/init.d/carbon-cache // Damit 'carbon-cache.py start' mit Systemstart erfolgt

Ergebnis davon ist -> Nichts funktioniert.

Back to the Roots

Ab hier kommt der Weg graphite-web auf einem Debian 9 (Stretch) in Betrieb zu nehmen.

Ausgangspunkt ist ein frisch installiertes Debian 9.

#> apt-get install vim -y
#> vim /etc/apt/sources.list

Wir müssen die Sources auf die Jessie Repositories setzen da zum Zeitpunkt dieses Blogposts die graphite-web Pakete nicht abrufbar sind.

Daher fügen wir folgendes hinzu in der sources.list
deb http://httpredir.debian.org/debian jessie main
Gefolgt von einem frischem #> apt-get update -y .

Nun installieren wir den großteil der Pakete welche wir benötigen.
#> apt-get install graphite-web graphite-carbon mysql-server python-mysqldb python-pymysql apache2 libapache2-mod-wsgi apt-transport-https ssl-cert python-pip -y

Es folgen ca. 300MB an Daten.
Daraufhin stürzen wir uns direkt auf die Konfig.

Wir fangen an folgende Datei zu editieren.
#> vim /etc/graphite/local_settings.py
Darin ändern wir folgende Settings Sinnvoll in etwas was wir für unsere Installation benötigen.

Also SECRET_KEY, TIME_ZONE & ALLOWED_HOSTS setzen.

Danach muss in der folgenden Datei ein “true” gesetzt werden damit graphite & carbon gemeinsam starten.

#> vim /etc/default/graphite-carbon

Nun kommt der trickreichste Part wir sind leider dazu genötigt eine alte django Version zu installieren.

#> pip install "django==1.4"

Damit haben wir die Grundlage womit wir das folgende Kommando erfolgreich absetzen können.

#> graphite-manage syncdb
#> chown _graphite. /var/lib/graphite/graphite.db
HINWEIS ! Dies setzt erst mal die voreingestellte sqlitedb in Gang.
Wenn eine andere DB verwendet werden soll dann sollte dies bitte in der “local_settings.py” vorgenommen werden.

Wir sind fast am Ziel ein funktionierendes graphite-web zu haben.
Es fehlt nur etwas Apache2 Magie.

#>a2dissite 000-default.conf
#>cp /usr/share/graphite-web/apache2-graphite.conf /etc/apache2/sites-available/
#> a2ensite apache2-graphite.conf
#> systemctl restart apache2

Voilà !

Es sollte nun auf dem Host System das graphite-web aufrufbar sein.

Danke für die Aufmerksamkeit !

David Okon

Autor: David Okon

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu glücklichen Menschen zu machen.

Secure Elasticsearch and Kibana with an Nginx HTTP Proxy

Elasticsearch provides a great HTTP API where applications can write to and read from in high performance environments. One of our customers sponsored a feature for Icinga 2 which writes events and performance data metrics to Elasticsearch. This will hit v2.8 later this year.

We’re also concerned about security, and have been looking into security mechanisms such as basic auth or TLS. Unfortunately this isn’t included in the Open Source stack.

 

Why should you care about securing Elasticsearch and Kibana?

Modern infrastructure deployments commonly require Elasticsearch listening on an external interface and answering HTTP requests. Earlier this year we’ve learned about ransomware attacks on MongoDB and Elasticsearch too.

During development I’ve found this API call – just clear everything inside the database.

[root@icinga2-elastic ~]# curl -X DELETE http://localhost:9200/_all
{"acknowledged":true}

I don’t want any user to run this command from anywhere. You can disable this by setting “action.destructive_requires_name” to “true” inside the configuration, but it is not the default.

A similar thing is that you can read and write anything without any access rules in place, no matter if querying Elasticsearch or Kibana directly.

 

Firewall and Network Segments

A possible solution is to limit the network transport to only allowed hosts via firewall rules and so on. If your Elasticsearch cluster is running on a dedicated VLAN, you would need to allow the Icinga 2 monitoring host to write data into http://elasticsearch.yourdomain:9200 – anyone on that machine could still read/write without any security mechanism in place.

 

HTTP Proxy with Nginx

Start with the plain proxy pass configuration and forward http://localhosT:9200 to your external interface (192.168.33.7 in this example).

# MANAGED BY PUPPET
server {
  listen       192.168.33.7:9200;
  server_name  elasticsearch.vagrant-demo.icinga.com;

  index  index.html index.htm index.php;

  access_log            /var/log/nginx/ssl-elasticsearch.vagrant-demo.icinga.com.access.log combined;
  error_log             /var/log/nginx/ssl-elasticsearch.vagrant-demo.icinga.com.error.log;

  location / {
    proxy_pass            http://localhost:9200;
    proxy_read_timeout    90;
    proxy_connect_timeout 90;
    proxy_set_header      Host $host;
    proxy_set_header      X-Real-IP $remote_addr;
    proxy_set_header      X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header      Proxy "";
  }
}

Restart Nginx and test the connection from the external interface.

# systemctl restart nginx

# curl -v http://192.168.33.7:9200

Once this is working, proceed with adding basic auth and TLS.

 

HTTP Proxy with Basic Auth

This leverages the access level to authenticated users only. Best is to manage the basic auth users file with Puppet, Ansible, etc. – similar to how you manage your Nginx configuration. Our consultants use that method on a regular basis, and provided me with some examples for Nginx. You could do the same for Apache – I would guess that is a matter of taste and performance here.

Generate a username/password combination e.g. using the htpasswd CLI command.

htpasswd -c /etc/nginx/elasticsearch.passwd icinga

Specify the basic auth message and the file which contains the basic auth users.

    auth_basic                "Elasticsearch auth";
    auth_basic_user_file      "/etc/nginx/elasticsearch.passwd";

Restart Nginx and connect to the external interface.

# systemctl restart nginx

# curl -v -u icinga:icinga http://192.168.33.7:9200

 

HTTP Proxy with TLS

The Elasticsearch HTTP API does not support TLS out-of-the-box. You need to enforce HTTPS via HTTP Proxy, enable ssl and set up the required certificates.

Enforce the listen address to SSL only. That way http won’t work.

  listen       192.168.33.7:9200 ssl;

Enable SSL, specify the certificate paths on disk, use TLSv1 and above and optionally secure the used ciphers.

  ssl on;

  ssl_certificate           /etc/nginx/certs/icinga2-elastic.crt;
  ssl_certificate_key       /etc/nginx/certs/icinga2-elastic.key;
  ssl_session_cache         shared:SSL:10m;
  ssl_session_timeout       5m;
  ssl_protocols             TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers               ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS;
  ssl_prefer_server_ciphers on;
  ssl_trusted_certificate   /etc/nginx/certs/ca.crt;

Restart Nginx and connect to the external interface on https. Note: Host verification is disabled in this example.

# systemctl restart nginx

# curl -v -k -u icinga:icinga https://192.168.33.7:9200

 

Combine HTTP Proxy, TLS and Basic Auth

A complete configuration example could look like this:

vim /etc/nginx/sites-enabled/elasticsearch.vagrant-demo.icinga.com.conf

# MANAGED BY PUPPET
server {
  listen       192.168.33.7:9200 ssl;
  server_name  elasticsearch.vagrant-demo.icinga.com;

  ssl on;

  ssl_certificate           /etc/nginx/certs/icinga2-elastic.crt;
  ssl_certificate_key       /etc/nginx/certs/icinga2-elastic.key;
  ssl_session_cache         shared:SSL:10m;
  ssl_session_timeout       5m;
  ssl_protocols             TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers               ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS;
  ssl_prefer_server_ciphers on;
  ssl_trusted_certificate   /etc/nginx/certs/ca.crt;

  uth_basic                "Elasticsearch auth";
  auth_basic_user_file      "/etc/nginx/elasticsearch.passwd";
  index  index.html index.htm index.php;

  access_log            /var/log/nginx/ssl-elasticsearch.vagrant-demo.icinga.com.access.log combined;
  error_log             /var/log/nginx/ssl-elasticsearch.vagrant-demo.icinga.com.error.log;

  location / {
    proxy_pass            http://localhost:9200;
    proxy_read_timeout    90;
    proxy_connect_timeout 90;
    proxy_set_header      Host $host;
    proxy_set_header      X-Real-IP $remote_addr;
    proxy_set_header      X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header      Proxy "";
  }
}

The following example query does not verify the offered host certificate. In case you configure the ElasticWriter feature in Icinga 2 v2.8, you’ll find the options to specify certificates for TLS handshake verification.

$ curl -v -k -u icinga:icinga https://192.168.33.7:9200
* Rebuilt URL to: https://192.168.33.7:9200/
*   Trying 192.168.33.7...
* TCP_NODELAY set
* Connected to 192.168.33.7 (192.168.33.7) port 9200 (#0)
* WARNING: disabling hostname validation also disables SNI.
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: icinga2-elastic
* Server auth using Basic with user 'icinga'
> GET / HTTP/1.1
> Host: 192.168.33.7:9200
> Authorization: Basic aWNpbmdhOmljaW5nYQ==
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.12.1
< Date: Tue, 12 Sep 2017 13:52:31 GMT
< Content-Type: application/json; charset=UTF-8
< Content-Length: 340
< Connection: keep-alive
<
{
  "name" : "icinga2-elastic-elastic-es",
  "cluster_name" : "elastic",
  "cluster_uuid" : "axUBwxpFSpeFBmVRD6tTiw",
  "version" : {
    "number" : "5.5.2",
    "build_hash" : "b2f0c09",
    "build_date" : "2017-08-14T12:33:14.154Z",
    "build_snapshot" : false,
    "lucene_version" : "6.6.0"
  },
  "tagline" : "You Know, for Search"
}
* Connection #0 to host 192.168.33.7 left intact

 

Conclusion

Secure data transfer from your monitoring instances to Elasticsearch is mandatory. Basic access control via basic auth should also be implemented. All of this is possible with the help of a dedicated HTTP Proxy host. Fine granular access control for specific HTTP requests is available in the commercial Shield package or variants. While securing Elasticsearch, also look into Kibana which runs on port 5601.

Since we’ve used the Icinga Vagrant boxes as a development playground, I’ve added Nginx as HTTP Proxy inside the icinga2x-elastic box. This provisions the required basic auth and TLS settings and offers to write data on https://192.168.33.7:9200 (icinga/icinga). The same applies for Kibana. The examples above can be replayed too.

If you want to learn more on this topic, make sure to join our Elastic Stack training sessions or kindly invite one of our consultants for a hands-on workshop. Hint: There is an Elastic Stack workshop at OSMC too 🙂

Michael Friedrich

Autor: Michael Friedrich

Michael ist seit vielen Jahren Icinga Developer 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. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht im Monitoring-Portal helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst das schöne Nürnberg. Oder - at an Icinga Camp near you 😉

Alternative zum CEP CT63: Das MultiTech MTD-H5-2.0 USB-powered

In letzter Zeit gab es immer mal wieder Nachfragen zu unserem ehemaligen Produkt, dem USB-Modem CEP CT63. Dieses gibt es bei uns nicht mehr und wir haben bereits vor Monaten sofort eine Alternative für Sie und uns gefunden, auf die ich gerne nochmals hinweisen möchte. Der bekannte, amerikanische Hersteller MultiTech liefert uns im MultiTech MTD-H5-2.0 USB-powered die passende Alternative.

 

Nahezu identisch in der Handhabung wie das CEP CT63 ist auch gedanklich keine große Umstellung nötig. Das MultiTech MTD-H5-2.0 eignet sich perfekt um SMS aus Icinga mittels der SMS Server Tools 3 zu versenden. Keine externe Stromversorgung, da USB-powered- das kann sich sehen lassen! Eine voll integrierte Antenne und das verbaute USB-Kabel tragen dazu bei, dass der Start mit dem oder die Umstellung auf das MultiTech MTD-H5-2.0 spielend gelingt. Unsere Empfehlung: Die PIN-Abfrage der eingesetzten SIM-Karte vorher am besten deaktivieren!

Hier noch kurz die Eckdaten im Überblick:

  • Frequenzen: 3G: Hepta-band 800/850/900/AWS 1700/1900/2100 2G: Quad-band 850/900/1800/1900
  • unter Linux und Solaris mit den SMS Server Tools 3 als SMS-Alarmierungsgerät mit Nagios und Icinga nutzbar
  • USB-Anschluss und USB-powered
  • integrierte Antenne
  • integriertes USB-Kabel
  • Maße (LxBxH): 7 cm x 4.01 cm x 1.88 cm)

Sie sind sich nicht ganz sicher? Wie wäre es dann mit einer 10-tägigen kostenlosen Teststellung des MultiTech MTD-H5-2.0 ? Prüfen Sie das Gerät auf Herz und Nieren. Ganz in Ruhe in Ihrem Hause. Sollten Sie wie wir begeistert sein, dann behalten Sie das Gerät einfach und begleichen Sie die im Paket enthaltene Rechnung. Einfacher geht es doch nicht, oder?

Sollte Ihre Anforderung zu einem SMS-Gateway mit LAN-Anschluss (z.B. Nutzung von mehreren Servern aus, Anforderung an eine HTTP-API oder Mail2SMS-API) gehen, sehen Sie sich doch unsere LAN gestützten Lösungen an:

Also jetzt gleich bestellen und sofort loslegen!

Isabel Salampasidis

Autor: Isabel Salampasidis

Isabel ist seit Februar zurück bei NETWAYS. Bis 2009 war sie unsere Office Managerin und verstärkt nun ab sofort das Sales Team. Hier ist sie für alle Belange des Online Stores verantwortlich. Der Ein- und Verkauf der Monitoring Hardware sowie die Weiterentwicklung des Shops und seines Portfolios wird sie mit ihrem bekannten Tatendrang gehörig vorantreiben. Privat verbringt die halbgriechische Ruhrpott-Fränkin sehr gerne so viel Zeit wie möglich mit ihren bald 4-jährigen Patensöhnen oder schreit sich für den Club - als stolze Dauerkartenbesitzerin! - die Seele aus dem Leib.