Clever die Temperatur via Netzwerk messen – HWg-STE und Neon 110

Da noch diese Woche die Temperaturen an der 30°C-Marke kratzen, stellen wir noch einmal unsere beliebtesten Geräte zur einfachen Temperaturüberwachung vor. Spätestens wenn Sie bereits einen Hitzeschaden an Ihrer Hardware hatten, wissen Sie die Vorzüge einer günstigen Temperaturüberwachung zu schätzen.
HWg-STE_IP_SNMP_Thermometer_800
HWg-STE: Unser günstiger Allrounder – ab 149,00 € erhalten Sie ein digitales Netzwerkthermometer inkl. allem was Sie zum Messen benötigen (3m IP67-Temperatursensor, Netzteil, MIB-Table, Plugin) – Natürlich gibts die Messwerte via Webinterface, Mail oder als Ausgabe fürs Monitoring (Plugin). Natürlich bieten wir noch andere Ausführungen an, wie beispielsweise PoE, Push (Messwerte via SensDesk-Portal), Plus (2 dry-contact inputs)… Darüber hinaus haben Sie die Möglichkeit, einen weiteren 1-Wire Sensor an das HWg-STE anzuschließen.
neon
Neon 110: Unser Neon 110 gibt’s zum Tiefpreis für 99,00 € – auch inkl. Sensor  (Temperatur und Luftfeuchtigkeit) und Netzteil. Eine PoE-Version gibt es nicht, das Neon ist halt wie es ist 🙂 Dafür aber mit Weboberfläche, Mailalarmierung und Messwerten via XML und Monitoring-Plugin.
99 € sind ja auch fast geschenkt und einem geschenkten Gaul… Sie wissen schon.
Natürlich kommt es immer auf die individuellen Gegebenheiten an, aber falls Sie sich nicht sicher sind, helfen wir Ihnen natürlich gerne und jederzeit weiter. Falls Sie Interesse an Lösungen für große Umgebungen haben, stöbern Sie doch einmal im Store – Sie werden sicher fündig!
Übrigens: bis 15:30 Uhr bestellt und die Ware ist schon am nächsten Werktag bei Ihnen.
SMS-Alarmierung? Die haben wir auch, schauen Sie doch mal unsere Ethernet-SMS Gateways an!

Georg Mimietz
Georg Mimietz
Lead Support Engineer

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.

NETWAYS-Online-Store: Angebot des Monats – Neon 110 ab 99,00 €

neon
Neon 110 Messgerät für Temperatur + Luftfeuchtigkeit
Wir freuen uns immer, wenn wir Ihnen ein tolles Angebot machen können. Diesen Monat haben wir uns für Sie richtig ins Zeug gelegt und können Ihnen jetzt das Neon 110 zum Sonderpreis ab 99,00 € statt 149,00 € anbieten.
Unser Neon 110 ist ein kompaktes Gerät zur Überwachung von Temperatur und Luftfeuchtigkeit. Mittels LAN-Anschluss stellt das Neon 110 die Messwerte überall in Ihrem Netzwerk bereit. Die initiale Einrichtung erfolgt komfortabel über das Webinterface, wo zudem auch die Messwerte eigesehen werden können.
Webinterface und Plugin für Nagios und Icinga
Im Falle einer Über- oder Unterschreitung der Messwerte kann das Neon 110 Alarm-Emails versenden. Durch die eingebaute XML-Schnittstelle lassen sich die Umweltparameter aber auch in jede beliebige Applikation importieren. Für Nagios und Icinga stellen wir ein Plugin bereit.
webinterface
Vergleichbare Lösungen kosten sonst über das Doppelte – greifen Sie zu!
Weitere Informationen, Screenshots und mehr finden Sie auf der Artikel-Seite im Online-Shop.
Teststellung gewünscht? Kein Problem!
Gerne bieten wir Ihnen auch eine kostenfreie Teststellung unserer Geräte an. Nehmen Sie einfach Kontakt zu uns auf und wir erklären Ihnen den Ablauf. Einfach. Unkompliziert.

Georg Mimietz
Georg Mimietz
Lead Support Engineer

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.

Neue Firmware für Neon110 verfügbar

Ab sofort steht für unser Neon110 Netzwerkthermometer eine neue Firmware (Version 1.5) bereit. Sie behebt einige Probleme in der Passwortverwaltung und lässt nun einige Sonderzeichen im Passwort zu. Vorher kam es zu Problemen, wenn Passworneon-110-netzwerksensor-fur-temperatur-und-luftfeuchtigkeitt Sonderzeichen enthielt. Das Gerät ließ sich in diesem Fall nicht mehr unlocken. Die Anforderung mit Sonderzeichen im Passwort kam bei einem unserer Kunden auf. Kurzer Hand haben wir die Anfrage mit dem Hersteller durchgesprochen und dieser lieferte eine entsprechende Anpassung via Softwareupdate. Die aktuelle Firmware für das Neon 110 können Sie sich hier herunter laden. In der Anleitung ist die Vorgehensweise für das Update ausführlich beschrieben.
Sie möchten auch eine angepasste Firmware für Ihr Gerät? Fragen Sie doch einfach einmal bei uns an, wir finden sicher eine Lösung für Ihre Anforderung.

neon-110-netzwerksensor-fur-temperatur-und-luftfeuchtigkeit (1)

Ansicht Webinterface Neon110

Georg Mimietz
Georg Mimietz
Lead Support Engineer

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.

Puppenschnur im XML-Baum verheddert

Wer sich schon mal mit Puppet und XML-Konfigurationsdateien beschäftigt hat, weiß das dies ein schwer umzusetzendes Vorhaben in Puppet ist. Es gibt zwar eine Linse für Augeas, wer aber eine komplette XML-Datei mit Puppet verwalten möchte, wird damit schnell wahnsinnig.
Ich hatte vor einigen Wochen das Glück, mich bei einem Kunden, näher mit der Konfiguration vom Tomcat beschäftigen zu dürfen. Dabei stand ich vor dem Problem, z.B. folgende Struktur als server.xml mit Puppet erzeugen zu müssen.

<Server>
  <Service name=Catalina>
    <Engine name=Catalina>
      <Host name=...>
        ...
      </Host>
      <Host name=...>
        ...
      </Host>
    </Engine>
  </Service>
</Server>

Wobei in den Host-Sektionen natürlich auch nochmals Schachtelungen vorkommen. Mein erster Lösungsansatz war, mit XML Referenzen auf eigenständige Dateien zu verweisen, die damit eingebunden werden. Dies führt nun aber zu einem recht unübersichtlichen Datei-Tohuwabohu.
Die jetzige Lösung macht sich die Eigenschaften des Puppet concat-Moduls zu nutze. Die einzelnen Fragmente werden auf dem Puppet-Agent jeweils als separate Datei in ein temporäres Verzeichnis geschrieben, z.B. nach /var/lib/puppet/concat/_etc_tomcat_server.xml/fragments. Das Attribut order von concat::fragment dient hierbei als Prefix für den Dateiname des entsprechenden Fragments. Sind alle Fragmente geschrieben, liest ein Skript alle Dateien mittels find, sortiert lexikalisch nach Dateinamen und fügt die Fragmente abschließend mittels cat in die Zieldatei zusammen, hier /etc/tomcat/server.xml.
Schaut man sich dieses find näher an, stellt man fest, dass es nicht tiefenbeschränkt ist, d.h. es durchsucht auch weitere Unterverzeichnisse. Diese können vorab mit einer files-Resource angelegt werden und im order-Attribut mit angegeben werden.

concat { '/etc/tomcat/server.xml':
  mode => '0644',
} ->
file { '/var/lib/puppet/concat/_etc_tomcat_server.xml/50_host_A':
  ensure => directory,
}
concat::fragment { 'engine-header':
  target => '/etc/tomcat/server.xml',
  content => "\n",
  order => '40',
}
concat::fragment { 'engine-footer':
  target => '/etc/tomcat/server.xml',
  content => "\n",
  order => '60',
}
concat::fragment { 'host_A-header':
  target => '/etc/tomcat/server.xml',
  content => "\n",
  order => '50_host_A/00',
  require => File['/var/lib/puppet/concat/_etc_tomcat_server.xml/50_host_A'],
}
concat::fragment { 'host_A-footer':
  target => '/etc/tomcat/server.xml',
  content => "\n",
  order => '50_host_A/99',
  require => File['/var/lib/puppet/concat/_etc_tomcat_server.xml/50_host_A'],
}

Analog für weitere Hosts. Zusätzliche Fragmente für Host A lassen sich nun zwischen dem Header und Footer einordnen. Dies soll erstmal nur die Idee vergegenwärtigen. Ein komplexeres Anwendungsbeispiel findet sich unter https://github.com/lbetz/netways-tomcat.
Auch ist zu bedenken, das auf unterschiedlichen Hosts das temporärere concat-Verzeichnis nicht immer am selben Ort zu finden ist. Hier schaft ein selbstgeschriebener Fact Abhilfe.

# vardir.rb
Facter.add(:vardir) do
  setcode do
    Puppet[:vardir]
  end
end
Lennart Betz
Lennart Betz
Senior Consultant

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.

Neu im NETWAYS-Online Store: Neon 110 Umweltüberwachung (Temp/RH)

543Wir von NETWAYS sind ständig auf der Suche nach neuen, tollen Produkten für unsere Kunden. Wir bieten ab sofort das All-in-One Messgerät von Sensormetrix an. Das Neon 110 ist ein simples, dennoch äußerst durchdachtes Gerät für die Überwachung von Temperatur und Luftfeuchtigkeit.

Für unschlagbare 179,00 € netto, zzgl. Versand erhalten Sie eine komplette Überwachungslösung – inkl. vormontiertem Temperatur- und Luftfeuchtigkeitssensor.
Im Vergleich: Das HWg-STE bietet ebenfalls für 179,00 € in der Basisvariante nur eine Temperaturüberwachung, punkten kann es jedoch mit flexibleren Einsatzmöglichkeiten in Hinsicht auf verschiedene Sensorlängen, Sensorvielfalt und SNMP-Fähigkeit. Das Neon 110 ist so wie es ist – funktioniert aber auch super.
Nachdem Sie das Neon geliefert bekommen haben, heißt es anschließen und loslegen – innerhalb von 5 Minuten sind alle wichtigen Einstellungen vorgenommen und das System ist einsatzbereit.
Die Messwerte werden bei einer Schwellwertüberschreitung per Mail versendet. Außerdem ist es hier auch wieder möglich, sich die Werte über das Webinterface anzeigen zu lassen. Mittels der XML-Schnittstelle können die Messwerte auch für eigene Lösungen verwendet werden – auch beim Neon wird Flexibilität groß geschrieben.
Wir haben uns auch die XML-Schnittstelle zu Nutze gemacht und entwickeln gerade ein Icinga/Nagios-Plugin – dieses wird es nächste Woche auf netways.org zu haben sein.
Auf der Produktseite im Online-Shop können Sie sich ebenfalls einige Screenshots und die XML-Schnittstelle ansehen. Alle weiteren technischen Details und Raffinessen gibt es dort außerdem genau nachzulesen.
Wir beginnen Anfang nächste Woche mit der Auslieferung der Geräte – wer also noch diese Woche bestellt – hat nächste Woche schon das Messgerät.
Falls noch Fragen bestehen, helfen wir wie immer hier

Georg Mimietz
Georg Mimietz
Lead Support Engineer

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.

Zend JSON-Ausgabe

Um JSON mit dem Zend auszuliefern, könnte man auf die harte Tour, Header selbst setzen, Daten enkodieren und layouts deaktvieren oder man nutzt Funktionalitäten, die das Framework schon bietet. Um zum Beispiel JSON direkt zu senden, bedient man sich Zend_Controller_Action_Helper_Json:

class TestController extends Zend_Controller_Action
{
    public function indexAction()
    {
        $data = array(
            'test' => true
        );
        /**
         * Call Zend_Controller_Action_Helper_Json::direct
         */
        $this->_helper->json($data);
    }
}

Über die Url ../test erhalten wir die Ausgabe in JSON inklusive dem korrekten Content-type application/json.
Nachteil dieses Aufruf ist, dass die dispatch loop sofort unterbrochen wird und somit eventuelle Erweiterungen durch Plugins nicht mehr aufgerufen werden.
Besser ist es, den ContextSwitch Action-Helfer zu benutzen, welcher XML und JSON unterstützt, layouts deaktiviert und Header enstrechend setzt:

class TestController extends Zend_Controller_Action
{
    public function init()
    {
        $this->_helper
             ->contextSwitch()
             ->addActionContext('index', 'json')
             ->initContext();
    }
    public function indexAction()
    {
        $this->view->test = true;
    }
}

Die JSON-Ausgabe ist nun über die Url ../test?format=json erreichbar.
Um sich den format-Parameter zu sparen, kann man für alle actions im Controller das json-Format erzwingen:

public function init()
{
    /**
     * Force json format
     */
    $this->_request->setParam('format', 'json');
    ...
}

Zum weiterlesen: Zend ContextSwitch

Eric Lippmann
Eric Lippmann
Lead Senior Developer

Eric kam während seines ersten Lehrjahres zu NETWAYS und hat seine Ausbildung bereits 2011 sehr erfolgreich abgeschlossen. Seit Beginn arbeitet er in der Softwareentwicklung und dort an den unterschiedlichen NETWAYS Open Source Lösungen, insbesondere inGraph und im Icinga Team an Icinga Web. Darüber hinaus zeichnet er sich für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.

Architekturstile: REST

Vor einiger Zeit sind wir ja bereits auf SOAP intensiv eingegangen. SOAP ist zwar zu Beginn oft Komplex und konfrontiert die Entwickler mit einer etwas anstrengenderen Lernkurve, spielt jedoch auf der Geraden den ein oder anderen Vorteil in Bezug auf komplexe Übermittlungen in heterogenen Umgebungen aus.
REST steht für REpresentational State Transfer und beschreibt ein Architekturmodell, dass man täglich an vielen Stellen des WWW, seinem logischen Vorbild, wiederfindet. Während SOAP “nur” ein Transfermedium von Nachrichten ist, hat REST eine konkrete Vorstellung wie mit entsprechenden Schnittstellen umgegangen wird.
Hierfür stehen die klassischen Web-Methoden GET, POST, PUT und DELETE zur Verfügung. Abhängig von Ihrer Verwendung ist somit auch die grundlegende Funktion beschrieben.
Ein Beispiel:

GET http://rest.service.de/hosts/server1/status

Hier ist klar zu erkennen, dass die Ressourcenauflösung über Pfade dazu verwendet wird ein Objekt eindeutig zu identifizieren und den Status zu ermitteln. Soll ein neuer Status hinzugefügt werden, kann das folglich mit einem POST-Request erfolgen. Die Ausgabe des REST-Kommandos ist im Vergleich zu SOAP nicht im Detail spezifiziert, jedoch wird häufig XML verwendet, da sich die Weiterverarbeitung deutlich einfacher gestaltet. Über den Verweis auf anderer REST-Ressourcen mit Hilfe der sogenannten XLinks’s können auch hierarchische Beziehungen abgebildet und aufgelöst werden.
In dieser Einfachheit liegt der klare Vorteil von REST, da sich der Entwickler, mit Ausnahme der strukturierten Verzeichnisauflösung, an keine definierten Übertragungsformate halten muss und die Anwendung leichtgewichtig gestalten kann. Daraus ergibt sich jedoch auch eine stark verzahnte Kommunikationsebene zwischen Client und Server, da der Spezifikation kein Routingmodell hinterlegt ist.
Die Entscheidung für SOAP oder REST ist, wie bereits im vorhergehenden Artikel erläutert, abhängig vom Bedarf an Komplexität und der Möglichkeit komplexere Transaktionen zu bündeln und zu routen. Der überwiegende Teil an Systemen wird jedoch leicht mit REST auskommen und von den agilen Möglichkeiten profitieren.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

Architekturstile: SOAP

Wie vor einigen Wochen versprochen, möchte ich heute einmal auf das SOAP-Protokoll eingehen. SOAP steht für Simple Object Access Protocol, besser gesagt stand. Seit den letzteren Versionen hat man dieses Akronym aufgrund der hohen Komplexität, die zugegeben mit Simple nicht viel zu tun hat, aufgegeben.
Als Protokoll beschreibt SOAP unter Nutzung von XML eher den Aufbau einer Nachricht als die eigentliche Übertragung. Eine SOAP-Nachricht besteht aus einer Hülle, dem so genannten SOAP-Envelop und beinhaltet einen entsprechenden Header und Body. Während der SOAP-Header optional ist, muss der Body ausgeführt sein und kann noch ein entsprechendes SOAP-Fault Element enthalten um Fehlersituationen zu übermitteln.
Ein Beispiel für eine gültige SOAP-Nachricht:

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body xmlns:m="http://www.icinga.org/status">
  <m:GetStatus>
    <m:ServerStatus>srv-lin-01</m:StockName>
  </m:GetStatus>
</soap:Body>
</soap:Envelope>

Zwar ist HTTP oder HTTPS der häufigste Standard um entsprechende Nachrichten zu übermitteln, es ist jedoch auch eine alternative Nutzung von JMS, SMTP oder anderen Transportmodellen möglich.
Im Unterschied zu REST, dazu bald mehr, ist SOAP kein leichtgewichtiges Unterfangen. Es Bedarf wohl definierten Schnittstellen und Namespaces um sich bei verschiedenen Services in größeren Umgebungen nicht in die Quere zu kommen und ist aufgrund des entsprechenden XML-Overheads bei der Übertragung von großen Datenmengen nicht besonders performant. Diese Nachteile verlieren durch immer größere Bandbreiten und entsprechende Performance jedoch zunehmend an Bedeutung und auch die entsprechende XML-Parser haben in Sachen Geschwindigkeit ordentlich zugelegt.
Der große Vorteil von SOAP liegt darin, dass ein entsprechender Service genau auf die Beantwortung bestimmter Requests vorbereitet werden muss und somit schon auf Schnittstellenebene gewisse Unstimmigkeiten eliminiert werden können. Ein “ungefähr” Request wird freundlich vom Server zurückgewiesen und vermeidet eine fehlerhafte Verarbeitung auf Definitionsebene.
Die beliebige Komplexität eines SOAP-Envelops ermöglicht jedoch die Zusammenfassung komplexer Transaktionen und Strukturen in einer Nachricht. So kann der Overhead der Einzelabfrage reduziert werden und komplexe Zusammenhänge einfacher dargestellt werden als durch Abbildung einer Vielzahl von REST-Requests.
Eine Entscheidung zugunsten von SOAP sollte nur bei Notwendigkeit der entsprechenden Komplexität fallen, ist dann aber oft auch sinnvoll.
Handle with Care!

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

MySQL Daten nach XML exportieren

Immer wieder findet man in Foren und verschiedenen Websites kleine Scripts, die eine MySQL-Tabelle in XML konvertieren. Bereits seit frühen 4er Versionen bietet MySQL dafür die Option –xml/ -X an, welche Ergebnisse der übergebenen Select-Anweisungen in standardkonforme XML-Dateien verwandelt, welche für viele Bedürfnisse ausreichen dürften.
Ein Beispiel:

mysql --xml -e "select alias, display_name, address from nagios.nagios_hosts limit 1,2"

gibt folgendes Ergebnis:

<?xml version="1.0"?>
<resultset statement="select alias, display_name, address from nagios.nagios_hosts limit 1,2
" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <row>
	<field name="alias">Business Processe</field>
	<field name="display_name">business_processes</field>
	<field name="address">10.6.255.99             # dummy IP</field>
  </row>
  <row>
	<field name="alias">untergeordnete Business Processe</field>
	<field name="display_name">business_processes_detail</field>
	<field name="address">10.6.255.99             # dummy IP</field>
  </row>
</resultset>

Auch mysqldump unterstützt die Ausgabe in XML, exportiert die Informationen jedoch aufgabengemäß in zusätzlichen Elementen mit Datenbank- und Tabelleninformationen.
Ein Beispiel:

mysqldump nagios nagios_dbversion --xml

gibt folgendes Ergebnis:

<?xml version="1.0"?>
<mysqldump xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<database name="nagios">
	<table_structure name="nagios_dbversion">
		<field Field="name" Type="varchar(10)" Null="NO" Key="" Default="" Extra="" />
		<field Field="version" Type="varchar(10)" Null="NO" Key="" Default="" Extra="" />
		<options Name="nagios_dbversion" Engine="InnoDB" Version="10" Row_format="Compact" Rows="1" Avg_row_length="16384" Data_length="16384" Max_data_length="0" Index_length="0" Data_free="0" Create_time="2009-09-11 12:04:09" Collation="latin1_swedish_ci" Create_options="" Comment="InnoDB free: 11264 kB" />
	</table_structure>
	<table_data name="nagios_dbversion">
	<row>
		<field name="name">ndoutils</field>
		<field name="version">1.4b7</field>
	</row>
	</table_data>
</database>
</mysqldump>
Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.