Zitat:

---

Original geschrieben von hybrid

Ich habe gar kein Problem mit der Software, die die Server runterfährt...

---

Damit haette ich schon ein Problem. Diese Loesung skaliert nicht. Ich habe schon oefters Loesungen gesehen, bei denen ssh dazu verwendet wurde, auf einer groesseren Menge von Rechnern Aktionen auszuloesen. Und bei Operationen, die selten ausgeloest werden, stimmt dann, wenn es drauf ankommt, irgend etwas nicht (ssh keys, sudoers Einträge...). Die Performance von ssh beim Login ist dank des kryptographischen Overhead eher klebrig, wenn man viele Server hat.

Wenn man so etwas zuverlaessig machen will, muss man den fernen Systemen moeglichst viel Autonomie lassen. Am einfachsten schreibt man die Temperatur in einem Webserver auf dem System, welches mit dem Temperaturfuehler verbunden ist. Aber natuerlich atomar, also zum Beispiel "finde_t_von_avr > file.tmp && mv file.tmp file". Die "Clients" koennen dann diese Info z.B. via wget abholen, und koennen selbst entscheiden, was sie damit anfangen wollen.

Diese Loesung hat noch andere Vorteile:
1. Der T-Server muss nichts ueber die "Clients" wissen, d.h. ob ein Server langsam/schnell oder wie auch immer funktionieren soll muss man einzig und allein auf dem Client einrichten.
2. Man braucht keinerlei asynchrone Mechanismen, man muss nicht an verschiedene Hosts denken. Das Script wird also linear. Dann kann man die Zeitsteuerung zum Beispiel Cron überlassen, also auch nicht selber schreiben.

Eine Alternative ist, die Temperatur in eine Datenbank zu schreiben, und die Clients die Information dort abholen zu lassen, geht auch über ein PHP Script. So bekommt man auch gleich eine Historie. Habe solche Lösungen schon mit Meteo für den Temperaturfühler und die Datenbank realisiert (falls jemand eine Stations-Klasse für Meteo für diesen T-Fühler schreiben möchte, bin ich nicht abgeneigt...)

Geändert von Andreas Mueller am 07. Dezember 2005 um 19:35

Zitat:

---

Original geschrieben von Andreas Mueller

Damit haette ich schon ein Problem. Diese Loesung skaliert nicht.

---

Unser Serverraum auch nicht

Zitat:

---

Wenn man so etwas zuverlaessig machen will, muss man den fernen Systemen moeglichst viel Autonomie lassen.

---

Es geht um lokale Systeme. Unter zehn.
Aber ich sehe, was Du meinst.
Es wäre dann so, daß die Schleife (mit lokalem "shutdown") auf jedem der einbezogenen Systeme läuft und das die Systeme eben nicht an dem Temperatur-Fühler lauschen, sondern an seinem Temperatur-Proxy (T-Server).
Atomarität erreiche ich ganz automatisch, wenn ich das Programm, welches den AVR liest, auch gleich die Requests beantworten lasse. Ein kleiner select-basierter Server wäre was für die python-Ecke.

Jeder Client entscheidet für sich selbst, nach welcher Zeit / bei welcher Temperatur er abschaltet.

Nachteil momentan, die Temperatur wird nicht als Gradzahl geliefert, sondern als fünfstelliger Dezimalwert
(Summe aus 64 Messungen) Man kann also nicht mal eben zentral die Schwelle ändern.

Zitat:

---

(falls jemand eine Stations-Klasse für Meteo für diesen T-Fühler schreiben möchte, bin ich nicht abgeneigt...)

---

BRRRR, new style c++! Konnte ich mich nie für erwärmen. Habe in jedem Projekt -fno-rtti -fno-exceptions Bin böser printf-user. Andererseits will ich auf Klassen und Referenzen keinesfalls verzichten, auch nicht auf dem AVR. Na gut, 'ne Klasse braucht's bei diesem Projekt selbst mit Gewalt nicht.

Grüße
Malte

Geändert von hybrid am 07. Dezember 2005 um 22:14

So, ich habe mir das eben noch mal überlegt.
Nachteile der T-Server-Lösung: Je mehr Clients, desto höher die Last auf dem T-Server im Normalbetrieb.
Die Reaktionszeit lässt sich auch nur durch Erhöhung der Last verbessern.
Außderdem ist die Lösung erheblich aufwendiger und erfordert Software-Installation und -Wartung auf den Clients wohingegen ssh überall installiert ist und schon gemonitored wird.

Da ich Pragmatiker und kein Informatiker bin, werde ich die einfacherere und schnellere Lösung wählen.

Grüße,
Malte

Geändert von hybrid am 07. Dezember 2005 um 23:11

Zitat:

---

Original geschrieben von hybrid

Nachteil momentan, die Temperatur wird nicht als Gradzahl geliefert, sondern als fünfstelliger Dezimalwert
(Summe aus 64 Messungen) Man kann also nicht mal eben zentral die Schwelle ändern.

---

Kein Problem: zentral verwendest Du ein PHP-Script, welches in einer Datenbank die Schwelle für den gerade anfragenden Server (Du hast ja seine IP-Adresse in den Request-Attributen) nachsieht, und die aktuelle Temperatur. Diese beiden Dinge lieferst dem Anfrager aus, dann kann er selber entscheiden, ob er die aus der Datenbank gelieferte Limite auch OK findet. So bekommst Du zentrale Konfiguration bei dezentraler Entscheidung. Als Konfigurationsanwendung kannst Du phpMyAdmin verwenden, d.h. du musst fast nichts selber schreiben.

Zitat:

---

Atomarität erreiche ich ganz automatisch, wenn ich das Programm, welches den AVR liest, auch gleich die Requests beantworten lasse. Ein kleiner select-basierter Server wäre was für die python-Ecke.

---

Warum überhaupt einen Server schreiben, wenn man schon einen auf dem System hat. Ausserdem haben Temperatur lesen und Requests bearbeiten nichts miteinander zu tun, und sollten daher auch nicht im gleichen Programm vorkommen (Eine Aufgabe - ein Werkzeug, keine eierlegenden Windows-Wollmilchsäue). Ganz abgesehen vom völlig verschiedenen Zeitverhalten von serieller Schnittstelle und Internet-Abfrage.

Zitat:

---

erfordert Software-Installation und -Wartung auf den Clients wohingegen ssh überall installiert ist

---

ssh erfordert Key-Installation und Wartung auf den Clients... So richtig gross ist der Unterschied zwischen einem
Key-File und und einem einzelnen Script-File nun wirklich nicht.

Zitat:

---

Original geschrieben von Andreas Mueller
Kein Problem: zentral verwendest Du ein PHP-Script, welches in einer Datenbank die Schwelle für den

---

Ich will kein PHP-Script.

Zitat:

---

Warum überhaupt einen Server schreiben, wenn man schon einen auf dem System hat.

---

Weil man kann Außerdem wer sagt denn, daß ich einen Web-Server mit Datenbank und PHP auf dem Ding am laufen haben will?

Zitat:

---

Ausserdem haben Temperatur lesen und Requests bearbeiten nichts miteinander zu tun, und sollten daher auch nicht im gleichen Programm vorkommen

---

Für einen Temperatur-Proxy halte ich das für zulässig. Besser ein edit: Programmpaket wie python und ein kleines, elegantes Programm als ein Konglomerat aus Multi-Megabyte-Paketen und edit: mehreren etwas kleineren aber uneleganten Programmen

Zitat:

---

ssh erfordert Key-Installation und Wartung auf den Clients...

---

Das ist aber schon so. Da müssen wir keine Extra-Arbeit Leisten.
Ich habe Deine Methode ja auch schon anprogrammiert (Server ist fertig und läuft )

Du vergisst einen großen Vorteil Deiner Methode. Man kann von Überall nachsehen, wie warm (oder im Sommer, wie kühl) es im Serverraum ist

Die Dateien sind als txt gespeichert und müssen als py gespeichert werden.
Außerdem verwende ich eine Tabsize von 4

Konfiguration: Anhang: config.txt
Server: Anhang: tempproxy.txt

Grüße
Malte

Geändert von hybrid am 09. Dezember 2005 um 16:22

Zitat:

---

Original geschrieben von hybrid

Besser ein kleines Programm als ein Konglomerat aus Multi-Megabyte-Paketen und einem etwas kleineren Programm

---

$ du -sH /usr/local/lib/python2.3/
39M /usr/local/lib/python2.3
$ find /usr/local/lib/python2.3/ -print | wc -l
2530

Python ist aber auf unseren Servern IMMER installiert. Im Gegensatz zu PHP/Apache/mySQL


Grüße
Malte

PS: Vielleich sollte ich, um die Informatikerseele zu quälen, die ssh-Befehle zum shutdown einfach in den Tempproxy einbauen?

Geändert von hybrid am 09. Dezember 2005 um 13:58

Zitat:

---

Original geschrieben von hybrid

Python ist aber auf unseren Servern IMMER installiert. Im Gegensatz zu PHP/Apache/mySQL

---

Andere Umgebungen, andere Sitten :-)

Gibt es Distros OHNE Python??

Zitat:

---

Original geschrieben von hybrid

Gibt es Distros OHNE Python??

---

Gibt es Distros ohne Apache/PHP/MySQL?

Apache + Perl sind in einer Solaris Installation vorhanden, Python fehlt.