Uptime Project hört auf

[daric.de]

Warum editiertst Du Deinen Zweizeiler über mir raus um ihn unverändert nochmal unter mir einzufügen?

Ich hatte doch genau darauf geantwortet.

 

[Deleted member 11740]

Hä? Meinst du mich oder DeaD_EyE?

Keine Ahnung, falls du mich meinst: "Ich das war ich nicht". Der Andere ist Schuld! Nein du! Ruhe jetzt verdammt...

Bin mir jetzt nicht bewusst, was ich nach dir eingefügt haben sollte. Editiert habe ich bevor du editiert hast. Hab noch eine Beleidigung aus meinem Edit entfernt und etwas Arroganz hinzugefügt. So bin ich nicht.

 

[SirDodger]

Hallo, ich grüße Euch!
Bin über eine Suchmaschine bzgl. dieses Themas zu Euch gestoßen, stand damals ebenfalls vor "verschlossenen Türen" beim uptime-project.net

Ich habe daraufhin 2007 selbst ein Project dieser Art gestartet, allerdings eher im privaten Rahmen, das Original hatte ja in wenigen Jahren etliche Tausend aktive Mitglieder, aber vermutlich auch kräftig in Werbung investiert.

Ich habe eigentlich nur für mich selbst und einen weiteren kleinen Personenkreis ein Folgeproject auf die Beine gestellt, einfach um mit diesem "Hobby" weiter zu machen, dementsprechend auch nie wirklich aktiv Werbung dafür gemacht.

Das ganze läuft nun fast 7 Jahre und über die Suchmaschinen haben sich nicht wirklich viele Leute dort hin verirrt.

Dies hier soll kein Spam darstellen, ich Betreibe die Seite nicht-kommerziell und nahezu ohne Werbung.

Also nur als Hinweis, wer Interesse hat kann gerne mal nach uptime24 suchen und ein Feedback geben.

So, und nun schaue ich mich hier im Forum mal weiter um, habe ja selbst auch ein paar Server im Keller stehen, vielleicht kann ich mich ja noch nützlich machen hier!

Mal abgesehen davon, dass ich - 7 Jahre später - ein Uptime-Monitor total sinnbefreit finde ...
Viel sinnvoller sind Monitorlösungen, die deutlich mehr abdecken könnten.

Und aus purer Neugier heraus habe ich mir mal das Linux-Script angeschaut ...

1. Die "Erkennung" der Distribution würde auf keinen meiner 20 System funktionieren!
/etc/issue ist dafür einfach keine valide Datenbasis!
2. Ihr übertragt die Daten - inkl. PASSWORT - via http?
Unverschlüsselt?
Im Klartext?
Nicht mal als Hash?

Wie alt seid ihr? 20?

Sorry, aber allein auf der Basis habt ihr euch in meinen Augen komplett disqualifiziert!

Gruß aus Hamburg.

 

[daric.de]

Mal abgesehen davon, dass ich - 7 Jahre später - ein Uptime-Monitor total sinnbefreit finde ...

OK, da es eine freiwillige Sache ist spielt das ja erstmal keine Rolle, zumal ich wie gesagt keine Werbung dafür machen will, sondern Interesse an Feedback habe, so gesehen danke ich Dir schon mal das Du Dir die Mühe gemacht hast, überhaupt mal reinzuschauen.

Viel sinnvoller sind Monitorlösungen, die deutlich mehr abdecken könnten.

Hier wird es interessant, an welche weiteren Funktionalitäten hast Du gedacht? Ich bin offen für neues.

/etc/issue ist dafür einfach keine valide Datenbasis!

Auch hier, an Verbesserungsvorschlägen habe ich immer Interesse, für einen ersten Linux-Client der letztes Jahr veröffentlicht wurde, war dies eine einfache Lösung die auf den meisten Standarddistributionen funktioniert.

2. Ihr übertragt die Daten - inkl. PASSWORT - via http?
Unverschlüsselt?
Im Klartext?
Nicht mal als Hash?

Also, https fällt aus, viel zu teuer für so ein Fun-Project.
Eine verschlüsselte Übertragung wäre sicher eine Überlegung Wert, primär hatte ich diesen Einfachen Weg eingeschlagen, da man mit den Daten - sofern man sich die Mühe machen würde diese auf dem Weg zum Server abzufangen - nichts anfangen kann außer im schlimmsten Fall fremde Uptimes zu manipulieren.

Wenn ich die Übertragung jetzt verschlüsseln würde, dann wäre dies "nur" ein Schutz für die User die für alles mögliche die gleichen Passwörter verwenden und so evtl. gefährdet wären. Dennoch hast Du natürlich Recht mit Deiner Kritik.

Habe ich noch andere Gefahren nicht berücksichtigt? Auch hier lerne ich gern dazu, auch wenn ich keine 20 mehr bin.

 

[Alderon]

Du kannst mal bei startssl.com schauen, dort kostet das Zertifikat nichts.
Und selbst ein selbst signiertes wäre noch besser als gar keines.

 

[Deleted member 11740]

1. Die "Erkennung" der Distribution würde auf keinen meiner 20 System funktionieren!
/etc/issue ist dafür einfach keine valide Datenbasis!

Na dann Liste mal auf du Spezialist. Du hättest ja auch schreiben können, was eine valide Datenbasis ist.

Die Implementierung von platform in Python ist mit Kommentaren 1655 Zeilen lang. Anstatt jetzt das Rad neu zu erfinden, könnte man ja einfach das Python-Modul verwenden, was standardmäßig dabei ist.

Das als Shell-Script zu implementieren, macht bestimmt Spaß. Sicherlich gibt es aber auch schon ein fertiges Shellscript, was diese Aufgabe sehr gut erfüllt.

 

[killerbees19]

Na dann Liste mal auf du Spezialist. Du hättest ja auch schreiben können, was eine valide Datenbasis ist.

Die Erkennung über die issue/issue.net Datei ist als primäre Quelle nicht klug.
Als Alternative sage ich nur einmal lsb-release bzw. dessen Datenquelle

Das ist zwar nicht überall per Default verfügbar, lässt sich aber meistens nachinstallieren. Und falls das auch nicht möglich oder gewünscht ist, kann man immer noch eine Fallback-Variante zur Erkennung im Script einbauen. Das kann als allerletzter Ausweg dann immer noch die issue/issue.net Datei sein.

EDIT: Oder halt gleich die Python-Methode…


MfG Christian

 

[SirDodger]

Also, https fällt aus, viel zu teuer für so ein Fun-Project.

http://startssl.com

Eine verschlüsselte Übertragung wäre sicher eine Überlegung Wert, primär hatte ich diesen Einfachen Weg eingeschlagen, da man mit den Daten - sofern man sich die Mühe machen würde diese auf dem Weg zum Server abzufangen - nichts anfangen kann außer im schlimmsten Fall fremde Uptimes zu manipulieren.

Es geht hier nicht um "im schlimmsten Fall fremde Uptimes zu manipulieren" sondern um Datenschutz!
Du möchtest, das sich jemand bei dir registriert und überträgst die Anmeldedaten unverschüsselt?
Jetzt versuche einfach mal nachzuvollziehen, wie viele User einfach zu faul sind, sich für jeden Service separate Zugangsdaten / Emailadressen zusammenzustellen ...

Und schon sind wir aus der obigen Nummer "im schlimmsten Fall fremde Uptimes zu manipulieren" raus ...

Mein Tipp zur Authentifizierung:
Baue mit sha1( Username + Password + Salt + what-ever ) einen simplen hash und nutze den zur Authentifizierung.
Daraus lässt sich mit einiger Sicherheit nichts ableiten und die Daten deiner User wären deutlich sicherer.
Du kannst ebenso eine REST-API auf deinem Server implementieren und im HTTP-Header Keys, Auth-Codes und sonst noch für Kram unterbringen, statt das in eine Requestvariable zu packen.
Es gibt so viele Möglichkeiten einen sichereren Webservice anzubieten ...

Das bash-Script müsste man nicht ändern, wenn man z.B. eine rc Datei mit den Konfigurationselementen nutzt.

Statt /etc/issue(.net) zu nutzen, nimm /etc/lsb-release oder /usr/bin/lsb_release.
Funktioniert allerdings nur unter Linux, wenn das lsb Packet installiert wurde.

...

MfG

 

[Deleted member 11740]

Die Python-Methode sucht nach Dateien in /etc, die unter anderem release im Dateinamen haben und liest dann den Inhalt aus. Was ich eigentlich damit sagen wollte, dass es nicht die Methode gibt um festzustellen, welche Distribution/OS auf dem PC installiert ist. Jeder Distributor kocht sein eigenes Süppchen, dann kommen noch die BSD-Varianten hinzu, OS von denen ich mal was gehört habe wie Solaris, AIX usw. Achja, Windows hätten wir da auch noch.

EDIT:
Serverseitig würde ich auch eher dazu tendieren komplett auf eine vernünftige dynamische Sprache zu setzen. Bau mal mit Shellscript eine REST-API bzw. die Abfrage. Ich meine das geht sogar mit wget/curl, ist aber ziemlich hässlich.

 

[daric.de]

Ich habe mich ja mal mit der StartSSL Geschichte befasst, zu dem sinnvollen Nutzen ist es ja auch eine interressante Sache.

Aber: Wie bekomme ich denn ein einfach gehaltenes Script dazu, eine sichere Verbindung aufzubauen? Die Kommunikation findet ja nicht über einen Webbrowser statt. Ist komplettes Neuland für mich und eine eigene Recherche hat mich jetzt nicht so wirklich schlau gemacht.

Gibts da ne halbwegs fertige Verbindungsschnittstelle die man einbauen könnte?


Zu der bemängelten OS Erkennung: Bisher hat diese Variante bei 99% aller teilnehmenden Linux-Systeme gut funktioniert.
Ich möchte vorerst nicht auf Pakete zurückgreifen, die nicht auf allen Systemen verfügbar sind bzw. diese nachinstalliert werden müssen.
Da gibt es andere Baustellen die mir derzeit wichtiger sind als eine verbesserte Betriebssystemerkennung, von der momentan (k)einer einen Vorteil hätte. Wird erstmal aufgeschoben, bleibt aber im Hinterkopf.

 

[Deleted member 11740]

Einen Webserver mit SSL aufsetzen und eine Webapplikation laufen lassen und das Script via POST die Daten übermitteln lassen.

Wget und Curl können das z.B.

Alternativ eine vernünftige Sprache wählen, die es ermöglicht sauberen Code zu schreiben. Das was man in Shell-Scripts macht, ist nicht gerade einfach zu warten.

 

[daric.de]

Mittlerweile wurde das ganze Project auf eine gesicherte SSL Verbindung umgestellt, vielen Dank nochmal an dieser Stelle für den Anstoß.

Was mich aber jetzt noch interessieren würde, was Ihr (in dem Fall Du, SirDodger) unter sinnvollen Monitorlösungen versteht.

Ich hatte ja schon mal mit dem Gedanken gespielt, so eine Art von Uptime-Robot zu implementieren, mit dem man nicht den eigenen Rechner, sondern Webserver überwacht und dessen Verfügbarkeit protokolliert.

Allerdings gibt es sowas natürlich schon, wäre dennoch eine nette Ergänzung und würde zum Thema passen.

Aber wie gesagt, ich bin neugierig an was Ihr sonst noch gedacht hättet in Sachen sinnvolle Monitorlösungen?

 

[SirDodger]

Ich habe mich ja mal mit der StartSSL Geschichte befasst, zu dem sinnvollen Nutzen ist es ja auch eine interressante Sache.

Aber: Wie bekomme ich denn ein einfach gehaltenes Script dazu, eine sichere Verbindung aufzubauen? Die Kommunikation findet ja nicht über einen Webbrowser statt. Ist komplettes Neuland für mich und eine eigene Recherche hat mich jetzt nicht so wirklich schlau gemacht.

curl

Gibts da ne halbwegs fertige Verbindungsschnittstelle die man einbauen könnte?

curl

 

[SirDodger]

Mittlerweile wurde das ganze Project auf eine gesicherte SSL Verbindung umgestellt, vielen Dank nochmal an dieser Stelle für den Anstoß.

Was mich aber jetzt noch interessieren würde, was Ihr (in dem Fall Du, SirDodger) unter sinnvollen Monitorlösungen versteht.

nagios, icinga, check-mk, ... such dir was aus

Ich hatte ja schon mal mit dem Gedanken gespielt, so eine Art von Uptime-Robot zu implementieren, mit dem man nicht den eigenen Rechner, sondern Webserver überwacht und dessen Verfügbarkeit protokolliert.

Allerdings gibt es sowas natürlich schon, wäre dennoch eine nette Ergänzung und würde zum Thema passen.

Aber wie gesagt, ich bin neugierig an was Ihr sonst noch gedacht hättet in Sachen sinnvolle Monitorlösungen?

Zumindest nagios (und das daraus hervorgegangene icinga) kann weitaus mehr als eine Uptime überwachen.

Google sei deine Freundin ...