Die STARFACE Services – heute: STARFACE Einrichtung (remote)

Im NETWAYS Online Store bieten wir zusätzlich zu den STARFACE Telefonanlagen, STARFACE Lizenzen, STARFACE Modulen und STARFACE Updateverträgen auch die STARFACE Services an! Die Firma sysob aus Schorndorf unterstützt uns dabei.

 

Zu unseren Dienstleistungen zählen die STARFACE Einrichtung (remote), der STARFACE Service vor Ort, die STARFACE Wartungsverträge und der STARFACE Emergency Support. Heute möchte gezielt auf den Service STARFACE Einrichtung (remote) eingehen.

STARFACE Einrichtung (remote) – Ein STARFACE Profi für die Basiskonfiguration

Sie möchten in Ihrem Unternehmen auf Lösungen aus dem Bereich VoiP umstellen und haben damit bisher wenig Erfahrung? Sie möchten die Einrichtung von einem Profi unterstützt selbst in die Hand nehmen? Dann ist der Artikel STARFACE Einrichtung (remote) wie für Sie gemacht! Bevor Sie die Dienstleistung auch wirklich bestellen können, sind einige Voraussetzungen auf Ihrer Seite zu erfüllen. Keine Sorge, hier geht es vor allem auch darum, dass Ihre Unterstützung Remotezugang zur STARFACE Appliance erhält und viele andere Formalitäten geklärt sind. Aber sehen Sie selbst:

  • eine Verkabelung zwischen Ihrem Gateway und der STARFACE Appliance ist vorhanden           
  • eine Verkabelung zwischen dem internen S0-Anschluss und den analogen Geräten ist vorhanden
  • es existiert mindestens ein angeschlossenes Telefon inklusive IP-Adresse
  • die IP-Adresse der STARFACE Appliance ist bekannt
  • eine Fernwartungslösung via Teamviewer (oder vergleichbar) ist realisierbar, bzw. ist vorhanden
  • die Zugangsdaten des Telefonanschlusses liegen vor (IP/ISDN/PMX)
  • Sie verfügen über Rufnummernblöcke für die Zuweisung
  • Sie verfügen über entsprechende STARFACE Lizenzen (bei VM Download der ovf Vorlage)
  • Informationen zur bestehenden Mailserveranbindung (Stichwort Fax) liegen vor
  • das Firewallregelwerk z.B. für die Anbindung von Home Office Arbeitsplätzen inkl. fester IP liegt vor
  • es existiert eine Datenablage zur Sicherung

Sie können hinter jedem Punkt Ihren Haken machen? Bingo, dann steht Ihrem Kauf nichts mehr im Wege! Im Artikel in unserem Shop finden Sie auch Anregungen dazu, was bei Ihrem Remotetermin, der einen halben Arbeitstag dauert, zum Beispiel angegangen werden kann. Dies können Sie aber individuell gemeinsam mit Ihrem Profi abstimmen. Übrigens: Die Leistung kann so genutzt werden, wie Sie es benötigen. Bei jedem Kunden kann es woanders “klemmen”. Maßgeschneiderte Lösung heißt hier das Zauberwort!

 

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.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 3: Plugins

Heute gehen wir der Frage nach wann und wie Plugins installiert werden sollten, was besonders wichtig bei Systemen mit icinga Benutzern zum Gegensatz nagios zu beachten ist. Auf z.B. RedHat-Systemen besteht das Problem, dass der Prozess Icinga 2 unter dem Benutzer icinga läuft, aber unteranderem das Plugin check_icmp oder auch check_dhcp nur vom Benutzer root oder einem Mitglied der Gruppe nagios mittels suid-Bit ausgeführt werden können.

# ls -l /usr/lib64/nagios/plugins/check_icmp
-rwsr-x---. 1 root nagios ... /usr/lib64/nagios/plugins/check_icmp

Das Ändern der Gruppenzugehörigkeit mit Puppet ist wenig hilfreich, da leider bei einem Update des Paketes nagios-plugins die alten Berechtigungen wieder hergestellt werden. Man könnte nun natürlich den Benutzer icinga und das Paket nagios-plugins explizit vor der Klasse icinga2 managen, verliert dann jedoch die Paketkontrolle über die uid und muss das Home-Directory, Shell und weitere Eigenschaften per Hand in Puppet entscheiden. Klarer ist die Methode genau diese Sachen dem Paket zu überlassen und erst danach icinga in die Gruppe nagios aufzunehmen.

yumrepo { 'icinga-stable-release':
  ...
}
->
package { [ 'icinga2', 'nagios-plugins' ]:
  ensure => installed,
}
->
user { 'icinga':
  groups => [ 'nagios' ],
}
->
class { '::icinga2':
  manage_package => false,
}

Um dieses Vorhaben umzusetzen ist es erforderlich die benötigten Repositories zuerst einzubinden, hier mit yumrepo angedeutet, dann die Pakete zu installieren, den Benutzer anzupassen und erst dann die Klasse icinga2 zu deklarieren.

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.

Monthly Snap April > NETWAYS Web Services, Braintower, OSBConf, Teamweekend, AKCP, OSDC, GitLab CE, Galera, GitHub, Puppet

In April, Isabel startet with announcing a new Software Update for Braintower and Martin K. continued with a new NETWAYS Web Services tool: Rocket.Chat Hosting.

Then Julia announced the call for papers for the Open Source Backup Conference 2017 in Cologne while Marius wrote about the end of Ubuntu 12.04 LTS.

Later in April, Marius H. gave some practical tips for the Galera Cluster and Dirk wrote about contributing to projects on GitHub.

Then Martin K. presented the next NETWAYS Web Services App, GitLab CE Hosting, and Julia told about the latest OSDC-News.

Furthermore, Catharina reviewed the team event of the commercial departments while Noah told us how to block some Google searches in Google Chrome.

Lennart gave an insight in the monitoring project at htp GmbH and Daniel introduced himself.

Towards the end of April, Isabel told about the latest news concerning the AKCP sensorProbe 2+ and Martin S. explained external monitoring by the Icinga2 satellites at NETWAYS Web Services.

Last but not least, Jean reported on monitoring powershell scripts with Icinga 2, while Lennart went on with part 2 of automated monitoring with Puppet.

Julia Hackbarth

Autor: Julia Hackbarth

Julia ist seit 2015 bei NETWAYS. Sie hat im September ihre Ausbildung zur Kauffrau für Büromanagement gestartet. Etwas zu organisieren macht ihr großen Spaß und sie freut sich auf vielseitige Herausforderungen. In ihrer Freizeit spielt Handball eine große Rolle: Julia steht selbst aktiv auf dem Feld, übernimmt aber auch gerne den Part als Schiedsrichterin.

Faster, Higher, Stronger. – OSDC 2017, Baby!

The conference on application of open source software in data centers and large IT environments  will take place on May 16 to 18, in Berlin.

Main program subjects are: CONTAINERS AND MICROSERVICES | CONFIGURATION MANAGEMENT | TESTING, METRICS AND ANALYSIS | TOOLS & INFRASTRUCTURE.

Take a deep dive into the depth of GRAYLOG, MESOS MARATHON or TERRAFORM by participating in one of three hands-on workshops on May 16.

Meet international open source specialists and gain valuable know-how and practical know-how from experienced developers, administrators and architects.

Hurry up and register now for the last few tickets at www.osdc.de!

Pamela Drescher

Autor: Pamela Drescher

Pamela hat im Dezember 2015 das Marketing bei NETWAYS übernommen. Sie ist daher speziell für die Corporate Identity unserer Veranstaltungen sowie von NETWAYS insgesamt verantwortlich. Die enge Zusammenarbeit mit Events ergibt sich aus dem Umstand heraus, dass sie vor ein paar Jahren mit Markus zusammen die Eventsabteilung geleitet hat und diese äußerst vorzügliche Zusammenarbeit nun auch die Bereiche Events und Marketing noch enger verknüpft. Privat ist sie Anführerin einer vier Mitglieder starken Katzenhorde, was ihr den absolut schmeichelhaften Vergleich mit einer gewissen "Crazy Cat Lady" eingebracht hat...

Ruby Applikationen testen mit RSpec und WebMock

Das Testen von Software begleitet mich von Projekt zu Projekt. Bei bisherigen Entwicklungen habe ich immer wieder auf RSpec zurück gegriffen, ein tool zum testen von Ruby Applikationen. Es zeichnet sich durch eine relativ einfache Handhabung aus und eine Ausdrucksweise die an die menschliche Sprache angelehnt ist. Auch wenn nicht jeder mögliche einzutretende Fall getestet werden kann, tests geben Entwicklern Sicherheit wenn Änderungen am Code vorgenommen werden.

WebMock

WebMock ist eine Library die es einem ermöglich HTTP requests auszudrücken und Erwartungen an diese zu setzen. In Verbindung mit RSpec lässt sich WebMock verwenden um eine Ruby Anwendung zu testen die HTTP Requests ausführt, beispielsweise an eine API. Oft sind diese Requests nicht starr sondern werden dynamisch anhand von Parametern zusammen gesetzt. WebMock/RSpec hilft dabei unterschiedliche Fälle zu simulieren, Erwartungen zu definieren und diese mit zu prüfen.

WebMock ist als Gem verfügbar, die Installation ist daher relativ einfach:

user@localhost ~ $ gem install webmock

Als Beispiel verwende ich eine sehr simple Ruby Klasse. Deren einzige Methode ‘request’ sendet einen GET request an die URL ‘https://wtfismyip.com’. Abhängig vom Parameter ‘option’ wird die IP entweder in Textform oder als JSON abgefragt:

require 'net/http'
require 'uri'

class ApiCaller
  def self.request(option)
    uri = URI.parse("https://wtfismyip.com/#{option}")
    http = Net::HTTP.new(uri.host, uri.port)
    http.use_ssl = true
    request = Net::HTTP::Get.new(uri.request_uri)
    http.request(request)
  end
end

Mein Test beinhaltet den Aufruf der ‘request’ Methode. Der HTTP request wird simuliert und die Erwartung das ein Request an eine bestimmte URL stattfinden soll wird auch definiert.

require 'api_caller'
require 'webmock/rspec'

describe ApiCaller do
  describe '.request' do
    context 'given json parameter' do
      it 'requests json url' do
        stub_request(:get, 'https://wtfismyip.com/json')
        expect(ApiCaller.request('json')).
          to have_requested(:get, 'https://wtfismyip.com/json').once
      end
    end

    context 'given text parameter' do
      it 'requests text url' do
        stub_request(:get, 'https://wtfismyip.com/text')
        expect(ApiCaller.request('text')).
          to have_requested(:get, 'https://wtfismyip.com/text').once
      end
    end
  end
end

Beim testen sieht das nun folgendermaßen aus:

user@localhost ~ $ rspec --format documentation

ApiCaller
  .request
    given json parameter
      requests json url
    given text parameter
      requests text url

Finished in 0.00557 seconds (files took 0.37426 seconds to load)
2 examples, 0 failures
Blerim Sheqa

Autor: Blerim Sheqa

Blerim ist seit 2013 bei NETWAYS und seitdem schon viel in der Firma rum gekommen. Neben dem Support und diversen internen Projekten hat er auch im Team Infrastruktur tatkräftig mitgewirkt. Hin und wieder lässt er sich auch den ein oder anderen Consulting Termin nicht entgehen. Mittlerweile kümmert sich Blerim hauptsächlich im Icinga Umfeld um die technischen Partner und deren Integrationen in Verbindung mit Icinga 2.