staging.inyokaproject.org

Danke für den interessanten Artikel!

Ich selber arbeite in einem kleinen Unternehmen, in dem zur Zeit viel mit Raspberry Pis experimentiert wird. Ist eine nette Plattform für Anwendungen wie die hier gezeigte. Wir selber suchen nach einer kostenünstigen Möglichkeit, ähnliche Messaufgaben zu automatisieren.

Allerdings muss ich feststellen, dass der "professionelle" Einsatz des Raspberry Pi schnell an Grenzen stößt, die das Ganze nicht mehr ganz so professionell machen. Es mangelt dem Pi an Zertifikaten (elektromagnetische Prüfung und dgl.), die im industriellen Einsatz von den Auftraggebern häufig gefordert werden. Okay, das kann man mit entsprechenden Tests vielleicht noch umschiffen.

In unseren Anwendungsfeldern begegnen wir zur Zeit allerdings häufig den Grenzen der Hardwarekonzepte. Aus meiner Sicht ist die Verwendung der SD-Karte ein großes Manko, denn diese haben nur eine (mit industriellen Maßstäben gemessene) überschaubare Anzahl von Lese- und Schreibzyklen. Uns sind die ersten Raspberry Pis mit Speicherproblemen schon nach wenigen Monaten Dauerfeuer ausgestiegen. Umgelegt auf unsere Anwendungsfelder würde das bedeuten, dass wir alle zwei bis drei Jahre im Rahmen einer Wartung die SD-Karte tauschen müssten. Unsere Kunden erwarten eine deutlich längere wartungsfreie Haltbarkeit. Der Kostenvorteil der Plattform würde nämlich andernfalls durch die personalintensive Wartung mehr als aufgefressen werden.

In diesem Zusammenhang muss ich auch den Produktzyklus der Raspberry-Foundation beklagen. Eine Langzeitverfügbarkeit ist nicht mal ansatzweise gegeben. Etwa im Jahresrhytmus werden komplett neue Modelle aufgelegt, die nur bedingt abwärtskompatibel sind und uns vor gewichtige Designprobleme stellen. Das fängt bei Sachen wie dem Formfaktor an, zieht sich über Sachen wie Stromverbrauch und Anschlüsse und endet bei Problemen wie der Wärmeerzeugung, die aufgrund der Neuplatzierung von Prozessoren und anderen Wärmequellen nur sehr schwer im Gehäusedesign berücksichtigt werden kann.

Ich kenne zwar auch die Raspberry Pis für industrielle Zwecke ("Compute Module"), die in einen SODIMM-Sockel passen. Diese umgehen die Problematik der SD-Karte, weil sie einen Flash-Speicher haben. Allerdings wird auch hier keine Langzeitverfügbarkeit garantiert.

Wir kommen immer mehr zu dem Schluß, dass der Raspberry Pi für den unseren professionellen Einsatz wenig bis gar nicht geeignet ist. Es gibt alternative Einplatinenlösungen, mit der wir auf der deutlich sichereren Seite sind.

Das soll aber niemand vom Experimentieren abhalten, denn genau dafür ist Raspberry Pi ja gedacht.

Schönen Gruß
Mumpitz

@1: Vielen Dank für den sehr interessanten Gegenbericht aus dem Unternehmensbereich. So etwas finde ich immer interessant, denn auch die Erkenntnis, dass etwas aus bestimmten Gründen nicht eingesetzt werden kann, hilft anderen, die vor der gleichen Entscheidung stehen.

@1: Hallo und vielen Dank für deinen Erfahrungsbericht. In der Tat kam für mich nie die Frage auf, ob der Raspi-SHT21 evtl. auch für den Vertrieb an unsere Partner geeignet sei. Denn ich fürchtete mich vor dem Supportaufkommen.

Unsere Firma hat eine eigene IT-Abteilung. Falls in einem unserer Pis die SD-Karte ausfällt, oder mal ein Neztteil kaputt geht, können wir diese Teile sehr schnell ersetzen. Befindet sich die Hardware an einem ganz anderen Ort, sieht die Sache schon wieder anders aus. Ich persönlich hätte auch keine große Lust losfahren zu müssen, um irgendwo eine SD-Karte zu tauschen.

Daher sehe ich den Raspi-SHT21 auch nicht als Produkt, sondern eher als Projekt für Menschen, die ihn selbst einrichten und notfalls reparieren können.

Mumpitz, habt ihr in eurer Firma evtl. auch schon mal mit Komponenten von Tinkerforge 🇩🇪 experimentiert? Diese werben dafür, dass ihre Produkte auch für industrielle Anwendungen geeignet sind.

Mumpitz, habt ihr in eurer Firma evtl. auch schon mal mit Komponenten von Tinkerforge experimentiert?

@3: Nein, Tinkerforge ist mir neu, danke für den Hinweis.

Wir haben derzeit testweise Einplatinenrechner von drei anderen Herstellern im Haus, die alle erforderlichen Zertifikate beibringen. Ich darf leider keine Namen nennen, weil wir uns damit exklusive Rechte gefährden könnten.

Was ich sagen kann ist, dass wir die drei Hersteller aufgrund von Preisrecherche ausgewählt haben. Ihre in Frage kommenden Einplatinenrechner liegen in einem für meinen Chef kaufmnnisch akzeptablen Preis-Leistungs-Verhältnis. Bei der Recherche sind meine Kollegen und ich auf mindestens 20 Firmen gestoßen, die Einplatinenrechner für industrielle Zwecke anbieten; in der Regel aber für mindetens den fünffachen Preis eines Raspberry Pi bei gleicher Leistung – was den Erfolg des Pi und seiner Derivate erklären mag. [Nun ja, eine Zertifizierung ist auch nicht ganz billig.]

In Kürze findet in Nürnberg eine Fachmesse zum Thema statt, die Embedded World. Ich selber kann leider nicht dort sein, bin aber sehr gespannt darauf, was meine Kollegen berichten werden.

Schönen Gruß
Mumpitz

Sensor ist schon bestellt zum testen.

Da ich meine Azubis eine Virtuelle Raspberry PI Firma als Projekt aufgedrückt habe (echte PCs sind teuer) und Nagios auch ein Bestandteil bei uns ist, wird er das auch umsetzten können. Der Lernefekt ist gut und ein USB mdadm Raid 6 hat auch was.

Das noch als Wassersensor (für Wassergekühlte Server Schränke war die Steigerung) um Wassereinbruch an kritischen stellen zu erkennen. TOP wäre das noch als Rauchmelder im Serverraum.

DANKE

Das noch als Wassersensor (für Wassergekühlte Server Schränke war die Steigerung) um Wassereinbruch an kritischen stellen zu erkennen. TOP wäre das noch als Rauchmelder im Serverraum.

@5: Wo ist das Problem? An den GPIO-Pins kann man sehr leicht einen AD-Wandler ansprechen, bevorzugt über das I²C- oder das SPI-Protokoll. Entsprechende ICs sind für einen kleinen Euro zu haben. Damit hat man eine universelle Schnittstelle, mit der man den Verlauf von Spannungen verfolgen kann.

Für die Wasserstandsmeldung kann man entweder eine Kurzschlussstrecke bauen, bei der der Wasserstand zwei Elektroden kurzsschließt. Der dadurch entstehende Widerstandssprung führt zu einem Spannunssprung, den man am Raspberry abfängt und als Alarm weiterverwarbeiten kann. roll:.

Die professionellere Lösüng wäre ein Kalt- oder Heißleiter, der durch Kontakt mit dem Kühlmedium einen Temperatursprung erfährt und so seinen Widerstand ändert, was wiederum den geünschten Spannungssprung zur Folge hat. Vorteil dieser Lösung wären die vorhersehbaren Ströme.

Der Rauchmelder kann auf dem gleichen Messprinzip beruhen, mit dem auch Haushalts-Ruachmelder funktionieren. Eine Infrarot- oder eine Laserdiode senden einen gerichteten Strahl aus. Außerhalb dieses Strahls befindet sich eine passende Empängerdiode, die also normalerweise kein Signal führt. Rauchpartikel streuen das Licht der Senderdiode in die Empfängerdiode und lösen einen Alarm aus. Kann man selbr basteln, oder man greift auf der Platine eines handelsüblichen Melders das Alarmsignal, das normalerweise auf den Piezo-Lautsprecher geht, ab und wertet es mit dem Raspberry aus.

Mein Buchtipp: "Die elektronische Welt mit Raspberry Pi entdecken" von Erik Bartmann führt Schritt für Schritt an den Eigenbau solcher Projekte ran. Wasserstands- und Rauchmelder sind da zwar nicht drin, es wird aber das Prinzip der Spannungsmessung über ICs erklärt, mit Bauanleitung für eine Experimentierplatine. Das Buch richtet sich an Laien, die noch nie vorher gelötet haben und holt sie meines Erachtens nach sehr gut bei Null ab. Im Buch wird auch das Ansprechen der GPIO-Pins über Python oder C++ beschrieben. Vielleicht also für Eure Virtuelle Firma gut geeignet.

Schönen Gruß
Mumpitz

@6: Hallo Mumpitz

Das Prob ist mein unvermögen in Elektrischer hinsicht sowie Unfähigkeit zu Programieren, wenn ich Zeit habe ist Scripten weniger das Prob .. nur hab ich halt keine 😉

Deine Anregungen sind gut, nur für mich nicht umsetztbar. Der Buchtip hat was, da müsste man eben nur viel Zeit investieren. Deine Idee werde ich aufgreifen, doch zuviel Zeit bleibt nicht für Lehrplam (Ausbildungsrahmenplan ist zu beachten), da gehört auch für den AZUBI viel private Initiative dazu, was ohne Begeisterung für den PI schwer ist (auch die AZUBI Vergütung schlägt da durch .. mal sehen ob ich es durchbringen kann, der Lehrerfolg ist ja wohl eindeutig und ist nur durch die Phantasie begrenzt) Nützliche Anwendungsfälle lassen sich bestimmt genügend generieren.

Anmerken möchte ich an der Stelle das man bei der Nutzung von Postfix, nrpe-server und SSH sich in diesem Fall eine FW des RASPI mit ansehen sollte. Die Ports müssen von extern dicht gemacht werden. Ich habe nach der Standardinstallation mit OpenVAS (hab es nicht auf den neusten Stand gebracht) einen Scan laufen lassen, das Ergebnis am Ende. Für den Betrieb in einer Serverlandschaft sollte man da etwas nachbessern.

Bei Gelegenheit werde ich noch mit anderen Sicherheitscanern den Webdienst abtasten, Nikto wäre da mein erster Anlauf. Oder einfach den Webdienst abschalten, wo kein Dieinst da kein Einfallstor. Wäre der Lighthttp ein einfallstor wäre das uncool, auch wenn ich ncoh so gerne auf die Webseite schauen möchte um nde Status einfach abzugreifen (für User besser und einfacher)

Egal wie auch immer, ich finde es ein Tolles Projekt, was sehr vielfälltig einsetzbar ist.

Hier der Report von OpenVAS nach der Standard Installation ohne Anpassungen.

Summary

This document reports on the results of an automatic security scan. The report first summarises the results found. Then, for each host, the report describes every issue found. Please consider the advice given in each description, in order to rectify the issue.

Vendor security updates are not trusted.

Overrides are on. When a result has an override, this report uses the threat of the override.

Notes are included in the report.

This report might not show details of all issues that were found. It only lists hosts that produced issues. Issues with the threat level "Debug" are not shown.

This report contains all 29 results selected by the filtering described above. Before filtering there were 29 results.
Scan started: 	Fri Feb 27 16:52:30 2015
Scan ended: 	Fri Feb 27 18:48:56 2015
Host Summary
Host 	Start 	End 	High 	Medium 	Low 	Log 	False Positive
192.168.1.205 	Feb 27, 16:52:42 	Feb 27, 18:48:56 	2 	1 	2 	24 	0
Total: 1 			2 	1 	2 	24 	0
Results per Host
Host 192.168.1.205
Scanning of this host started at: 	2015-02-27T16:52:42Z
Number of results: 	29
Port Summary for Host 192.168.1.205
Service (Port) 	Threat Level
smtp (25/tcp) 	High
ssh (22/tcp) 	High
ntp (123/udp) 	Low
bootpc (68/udp) 	Log
general/CPE-T 	Log
general/HOST-T 	Log
general/tcp 	Log
general/udp 	Log
http (80/tcp) 	Log
Security Issues for Host 192.168.1.205
smtp (25/tcp)
High (CVSS: 7.2)
NVT: SMTP antivirus scanner DoS (OID: 1.3.6.1.4.1.25623.1.0.11036)

The file 42.zip was sent 2 times. If there is an antivirus in your MTA, it might
have crashed. Please check its status right now, as it is
not possible to do so remotely

References
BID: 	3027
ssh (22/tcp)
High (CVSS: 9.0)
NVT: SSH Brute Force Logins with default Credentials (OID: 1.3.6.1.4.1.25623.1.0.103239)

Summary:
A number of known default credentials is tried for log in via SSH protocol.
Solution:
Change the password as soon as possible.
It was possible to login with the following credentials <User>:<Password>
pi:raspberry

smtp (25/tcp)
Medium (CVSS: 5.0)
NVT: Check if Mailserver answer to VRFY and EXPN requests (OID: 1.3.6.1.4.1.25623.1.0.100072)

'VRFY root' produces the following answer: 252 2.0.0 root 

References
Other:
	URL:http://cr.yp.to/smtp/vrfy.html
ntp (123/udp)
Low (CVSS: 0.0)
NVT: NTP read variables (OID: 1.3.6.1.4.1.25623.1.0.10884)

Summary:
 A NTP (Network Time Protocol) server is listening on this port.

smtp (25/tcp)
Low (CVSS: 7.5)
NVT: SMTP too long line (OID: 1.3.6.1.4.1.25623.1.0.11270)

 Summary:
 Some antivirus scanners dies when they process an email with a 
too long string without line breaks.
Such a message was sent. If there is an antivirus on your MTA,
it might have crashed. Please check its status right now, as 
it is not possible to do it remotely

bootpc (68/udp)
Log
NVT: (OID: 0)

Open port.

general/CPE-T
Log (CVSS: 0.0)
NVT: CPE Inventory (OID: 1.3.6.1.4.1.25623.1.0.810002)

192.168.1.205|cpe:/a:postfix:postfix
192.168.1.205|cpe:/a:php:php:5.4.36
192.168.1.205|cpe:/a:openbsd:openssh:6.0p1
192.168.1.205|cpe:/o:debian:debian_linux

general/HOST-T
Log (CVSS: 0.0)
NVT: Host Summary (OID: 1.3.6.1.4.1.25623.1.0.810003)

traceroute:192.168.1.50,?
TCP ports:80,22,25
UDP ports:68,123

general/tcp
Log (CVSS: 7.8)
NVT: 3com switch2hub (OID: 1.3.6.1.4.1.25623.1.0.80103)

Fake IP address not specified. Skipping this check. 

general/tcp
Log (CVSS: 0.0)
NVT: DIRB (NASL wrapper) (OID: 1.3.6.1.4.1.25623.1.0.103079)

DIRB could not be found in your system path.
OpenVAS was unable to execute DIRB and to perform the scan you
requested.
Please make sure that DIRB is installed and is
available in the PATH variable defined for your environment.

general/tcp
Log (CVSS: 0.0)
NVT: arachni (NASL wrapper) (OID: 1.3.6.1.4.1.25623.1.0.110001)

Arachni could not be found in your system path.
OpenVAS was unable to execute Arachni and to perform the scan you
requested.
Please make sure that Arachni is installed and that arachni is
available in the PATH variable defined for your environment.

general/tcp
Log (CVSS: 0.0)
NVT: Nikto (NASL wrapper) (OID: 1.3.6.1.4.1.25623.1.0.14260)

Nikto could not be found in your system path.
OpenVAS was unable to execute Nikto and to perform the scan you
requested.
Please make sure that Nikto is installed and that nikto.pl or nikto is
available in the PATH variable defined for your environment.

general/tcp
Log (CVSS: 0.0)
NVT: Traceroute (OID: 1.3.6.1.4.1.25623.1.0.51662)

Here is the route from 192.168.1.50 to 192.168.1.205:
192.168.1.50
?

general/tcp
Log (CVSS: 0.0)
NVT: Checks for open tcp ports (OID: 1.3.6.1.4.1.25623.1.0.900239)

Open TCP ports: 80, 22, 25

general/udp
Log (CVSS: 0.0)
NVT: Checks for open udp ports (OID: 1.3.6.1.4.1.25623.1.0.103978)

Open UDP ports: 68, 123

http (80/tcp)
Log
NVT: (OID: 0)

Open port.

http (80/tcp)
Log (CVSS: 0.0)
NVT: HTTP Server type and version (OID: 1.3.6.1.4.1.25623.1.0.10107)

The remote web server type is :
lighttpd/1.4.31 

http (80/tcp)
Log (CVSS: 0.0)
NVT: Services (OID: 1.3.6.1.4.1.25623.1.0.10330)

A web server is running on this port

http (80/tcp)
Log (CVSS: 0.0)
NVT: PHP Version Detection (OID: 1.3.6.1.4.1.25623.1.0.800109)

Detected PHP version: 5.4.36
Location: tcp/80
CPE: cpe:/a:php:php:5.4.36
Concluded from version identification result:
X-Powered-By: PHP/5.4.36-0+deb7u3 

http (80/tcp)
Log (CVSS: 0.0)
NVT: wapiti (NASL wrapper) (OID: 1.3.6.1.4.1.25623.1.0.80110)

wapiti could not be found in your system path.
OpenVAS was unable to execute wapiti and to perform the scan you
requested.
Please make sure that wapiti is installed and that wapiti is
available in the PATH variable defined for your environment.

ntp (123/udp)
Log
NVT: (OID: 0)

Open port.

smtp (25/tcp)
Log
NVT: (OID: 0)

Open port.

smtp (25/tcp)
Log (CVSS: 0.0)
NVT: SMTP Server type and version (OID: 1.3.6.1.4.1.25623.1.0.10263)

Remote SMTP server banner :
220 raspberrypi ESMTP Postfix (Debian/GNU) 
This is probably: Postfix
Detected Postfix version: unknown
Location: 25/tcp
CPE: cpe:/a:postfix:postfix

smtp (25/tcp)
Log (CVSS: 0.0)
NVT: SMTP STARTTLS Detection (OID: 1.3.6.1.4.1.25623.1.0.103118)

The remote Mailserver supports the STARTTLS command.

smtp (25/tcp)
Log (CVSS: 0.0)
NVT: Services (OID: 1.3.6.1.4.1.25623.1.0.10330)

An SMTP server is running on this port
Here is its banner : 
220 raspberrypi ESMTP Postfix (Debian/GNU) 

ssh (22/tcp)
Log
NVT: (OID: 0)

Open port.

ssh (22/tcp)
Log (CVSS: 0.0)
NVT: SSH Protocol Versions Supported (OID: 1.3.6.1.4.1.25623.1.0.100259)

The remote SSH Server supports the following SSH Protocol Versions:
1.99
2.0
SSHv2 Fingerprint: 66:20:d5:da:61:d7:ba:59:41:84:39:3f:a9:1e:86:32

ssh (22/tcp)
Log (CVSS: 0.0)
NVT: SSH Server type and version (OID: 1.3.6.1.4.1.25623.1.0.10267)

Detected SSH server version: SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2
Remote SSH supported authentication: publickey,password
Remote SSH banner: 
(not available)
CPE: cpe:/a:openbsd:openssh:6.0p1
Concluded from remote connection attempt with credentials:
  Login: OpenVAS
  Password: OpenVAS

ssh (22/tcp)
Log (CVSS: 0.0)
NVT: Services (OID: 1.3.6.1.4.1.25623.1.0.10330)

An ssh server is running on this port

This file was automatically generated.

Hallo.

Der Benutzer megazocker hat sich bei mir gemeldet und mir einen Verbesserungsvorschlag übermittelt:

megazocker schrieb:

[...] Ich hätte da noch einen Verbesserungsvorschlag (ich bin nicht der Held beim Scipten) Es kann ja auch zu kalt werden im Kühlschrank also ein unterer Grenzwert für Temperatur wäre toll.[...]

Auf seinen Wunsch hin, hab ich die Funktion in die Version 1.3.0 🇩🇪 eingebaut.

Guten Morgen,

soeben wurde die Version 1.4.0 🇩🇪 des Raspi-SHT21 veröffentlicht.

Diese Version enthält neue Funktionen zum Versand der Logs per E-Mail. Der E-Mail-Versand kann nun einfach über das logrotate-Script konfiguriert werden.

MfG
Tronde

Guten Abend,

mittlerweile gibt es Version 2.0.0 🇩🇪 des Raspi-SHT21.

Alle Neuerungen werden auf der Release-Seite beschrieben. Darüber hinaus wurde auch das Projekt-Wiki erweitert.

MfG
Tronde