TinyAdmin: Gleichzeitiges Administrieren/Steuern von Hosts

[Trevanian]

TinyAdmin: Gleichzeitiges Administrieren/Steuern mehrerer Hosts

UPDATE: Mittlerweile in v0.3-2 - Stand: 19. Juni 2011

Hallo alle zusammen,

ich lese hier schon lange mit, konnte mich jedoch bisher nicht dazu bewegen, selbst einmal einen Beitrag zu verfassen. Jetzt habe ich jedoch etwas, für den ein oder anderen, vielleicht nützliches beizutragen.

Jeden Abend habe ich ein Update auf meinen Linux-Clients durchgeführt und musste mich dabei auf jedem einzeln per SSH einloggen und die Kommandos ausführen. Dies begann mir auf die Nerven zu gehen und so suchte ich nach einer Softwarelösung, mit der ich einfach und unkompliziert die Paketmanager mehrerer Hosts gleichzeitig zum update bewegen kann.

Leider wurde ich nicht fündig: Das Hauptproblem war, dass meine Hosts unterschiedliche Paketmanager nutzen. So programmierte ich, nach anfänglichem Geplänkel mit ein paar Shellskripten, meine eigene Software in Java. Dieser ist es egal, welcher Paketmanager am anderen Ende sitzt. Über ein GUI lässt sich bequem eine Serverliste warten, wo auch das Betriebssystem der einzelnen Hosts eingestellt werden kann. Über einen Knopfdruck lässt sich dann ein Softwareupdate, Reboot/Shutdown, Test/Ping, Wake-On-LAN oder aber selbst definierte Kommandos ausführen.

Die gewünschte Aufgabe wird dabei gleichmäßig auf bis zu 10 Prozesse verteilt und parallel abgearbeitet: So lassen sich unheimlich schnell viele unterschiedliche Distributionen mit nur einem Knopfdruck bedienen.

Bei Wünschen und Anregungen, postet bitte einfach hier und ich werde versuchen diese dann in die Software einfließen zu lassen. Neue Systeme, solange diese Un*x-ähnlich sind, lassen sich beispielsweise innerhalb weniger Minuten implementieren.
Wer also Nutzen daran findet, aber seine Distribution oder sonstige Dinge vermisst, dem bin ich gerne bereit zu helfen.

Natürlich steht die komplette Software unter der GNU GPLv2 und ist völlig Open Source. Auf der Seite findet sich sowohl der Sourcecode zum Download, als auch eine Java API Dokumentation zum Download oder direkten einsehen.

Name: TinyAdmin v0.2 BETA-1

Features:

• Verwalten Sie mehrere Server gleichzeitig und Verteilen Sie Ihre Aufgabe dabei auf bis zu 10 parallele Prozesse.
• Erstellen Sie eigene Kommandos: Passen Sie den auszuführenden Befehl für jedes unterstützte Betriebssystem selbst an und speichern Sie Ihre erstellten Kommandos.
• Schnell-Kommandos: Führen sie schnell und unkompliziert eigene, nicht os-spezifische, Befehle aus.
• Führen Sie alle Befehle wahlweise als root oder normaler Benutzer aus: Ihr Kommando wird dementsprechend automatisch für Sie angepasst.
• Standardkommandos: Führen Sie Softwareupdates auf vielen Hostcomputern parallel mit nur einem Klick durch, fahren Sie diese herunter, oder rebooten sie: All dies ohne selbst Befehle definieren zu müssen. Die Software arbeitet dabei automatisch mit dem Paketmanager des jeweiligen Hosts zusammen.
• Weckt fremde Hosts auf bzw. startet diese durch Versand eines Magic-Packets (Wake-On-LAN).
• Testen der Erreichbarkeit fremder Hosts, oder Sammeln von Pingstatistiken über diese.
• Unterstützt viele verschiedene Fremdrechner-Betriebssysteme (Mac OS X, Debian, Fedora, RedHat, CentOS, Mandriva).
• Sicheres Aufbewahren ihrer Passwörter auf der Festplatte durch effektive Verschlüsselung.
• Eigene SSH2-Implementierung: Es wird keine weitere Software benötigt. Das Programm arbeitet also auch unter Windows, obwohl dort kein SSH verfügbar ist.
• NEU IN V0.3: Erlaubt die freie Wahl des SSH-Ports für jeden Host und die Verwendung von Public Keyfiles.
• NEU IN v0.3: Schnell-Zugriff auf alle Funktionen und Befehle per TrayIcon.

DOWNLOAD: HIER KLICKEN

SCREENSHOTS:

 

[Trevanian]

Es scheint als hätte es viele Leute gestört, dass man mit der Software keine selbt erstellten Kommandos ausführen kann.

Um dem Abhilfe zu schaffen, habe ich nun Version 0.2 fertiggestellt. In dieser Version existieren zwei Sorten von Benutzer-eigenen Kommandos:

1. Betriebssystemabhängige Kommandos: Hier wird dem Kommando für jedes unterstützte Betriebssystem ein anderer Befehl zugeordnet. Wird das Kommando ausgeführt, verhält es sich also auf allen Betriebssystemen unterschiedlich.
2. Schnell-Befehle: Hier wird einfach das gleiche Kommando auf vielen Hosts gleichzeitig ausgeführt, ohne auf die Eigenarten der Betriebssysteme zu achten.

Zusätzlich lassen sich beide Kommandotypen wahlweise als root oder normaler Benutzer ausführen. Ist die Ausführung als root gewünscht, fügt die Anwendung an allen nötigen Stellen sudo bzw. das Sudo-Passwort ein.

Natürlich gab es auch diverse optische Verbesserungen und viele Bugfixes.

Leider ist die Software nach wie vor im Betastadium: Dies liegt darin, dass es mir an Testern mangelt. Ich kann nicht garantieren, dass die Software für alle angebotenen Betriebssysteme korrekt arbeitet, wenn ich sie nicht auf allen angebotenen Betriebssystemen getestet habe.

Wer also mal ein paar Minuten Zeit hat und zufällig eines der von der Software unterstützten Betriebssysteme nutzt, dem wäre ich für einen Test+Feedback sehr dankbar. Falls weiterhin jemand Wünsche hat, so werde ich diese Natürlich in die nächste Version einfließen lassen.

Den Startbeitrag habe ich entsprechend angepasst, dort finden sich auch neue Screenshots.

DOWNLOAD: HIER KLICKEN

 

[IceMatrix]

Es gibt zum Autoupdaten bereits diverse Tools. Die Gefahr die ich bei den Kommandos sehe ist, dass wenn es unterschiedliche Distributionen gibt, diese Kommandos zu diversen Problemen führen können.

z.B.
/etc/init.d/apache force-reload (debian)
/etc/init.d/httpd graceful (centos)
..

Gibt sicher noch diverse andere Fälle wo die Seiteneffekte größere Probleme bereiten.

Was ich persönlich aber vermisse (oder es ist nur auf den Screenshots nicht drauf) ist eine Key Authentication. Im professionellen Betrieb werden meistens keine Passwörter zum Login verwendet.

 

[Trevanian]

Hallo und danke für deine Antwort,

in der Tat fehlt momentan noch die key-authentication, sowie die Möglichkeit, selbst einen Port für SSH auszuwählen. Dies wird aber in das nächste Release einfließen.

Als nächstes würde mich interessieren, welche Tools zum auto-update Du meinst? Ich konnte keine Tools finden, die mit unterschiedlichen Paketmanagern gleichzeitig zurechtkommen: Deshalb habe ich das Programm ja überhaupt erst geschrieben. Falls Du das Einrichten von automatischen Updates auf den Servern selbst meinst, dann ist das natürlich etwas anderes. Ich wollte jedoch selbst bestimmen, wann ich den Knopf drücke und zudem entfällt die Konfigurationsarbeit für die einzelnen Maschinen. Das einzig mir bekannte Programm, welches ansatzweise in diese Richtung geht ist ClusterSSH (und dessen forks). Allerdings findet hier eben ja das Betriebssystem keine Berücksichtigung, sondern der Befehl wird einfach immer gleich ausgeführt.

Dein Beispiel mit Apache und den Befehlen habe ich irgendwie nicht ganz verstanden. Der Nutzer kann doch sehr wohl festlegen, dass ein semantischer Befehl (z.B. "Apache neustarten") dann auf Debian anders ausgeführt wird, als auf CentOS. Was für Probleme meinst Du genau?

Gruß,

Trev

 

[Grugeschu]

Mein Respekt ich bin sprachlos. Ein echt gute Idee. Sonst gehen alle Ansätze hin zur GUI oder automatischen Prozessen, doch diese will der Admin auch nicht immer. Da ist dein Tool echt der Hammer ;-). Super Lizenz und GUI. Danke!

Poste dein Programm doch noch in anderen Linuxlastigen Foren wie Unixboard.

 

[Trevanian]

@Kartoffel200

Vielen Dank für die Blumen! Freut mich, dass es Dir gefällt.

Bald ist Semesterende und meine Prüfungen fangen an, daher wir die Arbeit vorübergehend gedrosselt.
Ich wollte die Version mit Keyfiles und Portwahl eigentlich schon fertig haben, leider hat mich aber die Homepage aufgehalten. Ich werde allerdings trotz Prüfungsstress versuchen, die Version noch diese Woche fertig zu bekommen.

Folgende Verbesserungen werden integriert:

• Auswahl des Ports, auf dem der SSH-Server läuft.
• Nutzen von Keyfiles
• Die Software in den Tray minimieren und darüber schnell bedienen
• Verbesserung der Accessibility des GUIs: Leichteres Hinzufügen neuer Server etc.

Gruß,

Trev

 

[IceMatrix]

Als nächstes würde mich interessieren, welche Tools zum auto-update Du meinst? Ich konnte keine Tools finden, die mit unterschiedlichen Paketmanagern gleichzeitig zurechtkommen: Deshalb habe ich das Programm ja überhaupt erst geschrieben. Falls Du das Einrichten von automatischen Updates auf den Servern selbst meinst, dann ist das natürlich etwas anderes. Ich wollte jedoch selbst bestimmen, wann ich den Knopf drücke

Was verstehst du unter "Knopf drücken"?

Updater gibt es reichlich. Für Debian z.B. unattended-upgrades. Da kannst du sehr genau einstellen was upgedated werden darf und wann.

zudem entfällt die Konfigurationsarbeit für die einzelnen Maschinen

Nicht wirklich. Was verstehst du unter Konfigurationsarbeit? Ich glaube nicht dass du mit deinem Tool nen Apache-Server oder ähnliches konfigurieren kannst.

Für sowas wird im professionellen Betrieb auf Configuration Management gesetzt, z.B. Puppet oder cfengine. Das ist ein sehr komplexes Thema, besonders bei unterschiedlichen Betriebsumgebungen.

Dein Beispiel mit Apache und den Befehlen habe ich irgendwie nicht ganz verstanden.

Ja das Beispiel war unglücklich gewählt. Gemeint ist, dass der gleiche Befehl auf unterschiedlichen Systemen (selbst wenns die gleiche Distribution ist) sehr unterschiedliche Effekte haben kann. Unterschiede gibt es z.B. durch
1) Gleichnamige Binaries von unterschiedlichen Anbietern (Linux ist sehr heterogen)
2) Unterschiedliche Versionen der Binaries (Linux ist sehr heterogen)
3) Unterschiedliche Betriebszustände
4) Unterschiedliche Konfiguration
5) Unterschiedliche Prozessorarchitektur (i386 <-> amd64)

Wenn du einfach einen Befehl eingibst und ihn auf X Machinen ausführen lässt, dann wird es schwer nachvollziehbar sein, wenn es Fehler dabei gibt. Und Fehlerbehandlung ist gerade bei Servern enorm wichtig. In einem kommerziellen Produktivsystem würde man so ein Tool deshalb nie einsetzen.

Der Nutzer kann doch sehr wohl festlegen, dass ein semantischer Befehl (z.B. "Apache neustarten") dann auf Debian anders ausgeführt wird, als auf CentOS. Was für Probleme meinst Du genau?

Siehe oben. Dazu kommt noch die Schwierigkeit, dass ein User erstmal den Sachverstand haben muss dies zu tun. Weitere Voraussetzung ist, dass unterschiedliche Distributionen auch äquivalente Befehle haben. Das muss auch nicht zwingend der Fall sein.
Die Chance dass etwas schief geht ist sehr hoch.

 

[Trevanian]

Was verstehst du unter "Knopf drücken"?

Ich meine selbst die Kontrolle über das Ausführen des Upgrades zu haben, also selbst den Upgrade(GUI)/Enter(Shell)-Knopf zu drücken. Ich habe auf meinem Debian Server zuvor automatische Upgrades eingerichtet und diese fanden, wie der Name schon sagt, automatisch statt. Mir gefällt es besser, wenn ich diese selbst ausführen kann und dabei immer sehe, was sich verändert, ohne später Logs zu lesen. Leider muss man sich dazu eben immer auf der Maschine einloggen.

Updater gibt es reichlich. Für Debian z.B. unattended-upgrades. Da kannst du sehr genau einstellen was upgedated werden darf und wann.

Ja, wie schon gesagt: Ich wollte keinen automatischen Upgrader, sondern selbst die Upgrades ausführen. Man kann nach wie vor bestimmte Packages sperren und wenn ich dann mein Programm ausführe, werden diese berücksichtigt.

Nicht wirklich. Was verstehst du unter Konfigurationsarbeit? Ich glaube nicht dass du mit deinem Tool nen Apache-Server oder ähnliches konfigurieren kannst.

Ich meinte damit das Einrichten automatischer Updates. Zum Konfigurieren eines Apaches
sollte man sich besser über die Shell einloggen, dafür ist mein Programm auch nicht gedacht.

Für sowas wird im professionellen Betrieb auf Configuration Management gesetzt, z.B. Puppet oder cfengine. Das ist ein sehr komplexes Thema, besonders bei unterschiedlichen Betriebsumgebungen.

Ich dachte mir schon, dass mein Programm in solchen Umgebungen keine Anwendung findet. Es ist zwar möglich damit in solchen Umgebungen zu arbeiten, aber es ist nicht komplex genug, um dort wirklich attraktiv zu sein. Ich will und kann auch garnicht mit solchen Anwendungen konkurieren.

Ja das Beispiel war unglücklich gewählt. Gemeint ist, dass der gleiche Befehl auf unterschiedlichen Systemen (selbst wenns die gleiche Distribution ist) sehr unterschiedliche Effekte haben kann. Unterschiede gibt es z.B. durch
1) Gleichnamige Binaries von unterschiedlichen Anbietern (Linux ist sehr heterogen)
2) Unterschiedliche Versionen der Binaries (Linux ist sehr heterogen)
3) Unterschiedliche Betriebszustände
4) Unterschiedliche Konfiguration
5) Unterschiedliche Prozessorarchitektur (i386 <-> amd64)

Derartige Feinheiten werden nicht berücksichtigt, da gebe ich Dir recht. Mein Programm differenziert lediglich nach Betriebssystem.

Wenn du einfach einen Befehl eingibst und ihn auf X Machinen ausführen lässt, dann wird es schwer nachvollziehbar sein, wenn es Fehler dabei gibt. Und Fehlerbehandlung ist gerade bei Servern enorm wichtig. In einem kommerziellen Produktivsystem würde man so ein Tool deshalb nie einsetzen.

Wenn der Fehler eine Fehlermeldung auf der Shell oder sonstige Verboseausgabe erzeugt, sieht man sie in meinem GUI. Wenn nicht, hat man in der Tat leider Pech gehabt.

Siehe oben. Dazu kommt noch die Schwierigkeit, dass ein User erstmal den Sachverstand haben muss dies zu tun. Weitere Voraussetzung ist, dass unterschiedliche Distributionen auch äquivalente Befehle haben. Das muss auch nicht zwingend der Fall sein.
Die Chance dass etwas schief geht ist sehr hoch.

Auf der einen Seite beklagst Du mangelnde Einstellungsmöglichkeiten für den Betrieb professionellen Betrieb, hast dann aber Bedenken bei "dummen" Usern? Es wird wohl jeder erkennen, der diese Software benutzten möchte, dass man für jedes OS einen eigenen Befehl definieren kann: Gerade damit werbe ich ja .
Zum anderen: falls es den Befehl für das vom Benutzer erstellte Kommando nicht in der gleichen, semantischen Bedeutung auf einem anderen Betriebssystem gibt, dann kann der Nutzer das Feld einfach frei lassen.
Wo ist hier das Problem? Rein theoretisches Beispiel: Der Benutzer erstellt einen neuen Befehl: "Apache neustarten". Leider stellt er entsetzt fest, dass es auf "Distribution X" keine Möglichkeit gibt, Apache über die Shell neu zu starten. Was macht er also? Er lässt das Feld frei. Ich frage mich allerdings, wieso es nicht überall einen äquivalenten Befehl geben sollte? Es muss ja nicht nur ein Befehl sein, der Nutzer kann mit "&&" beliebig viele zusammenhängen.

Gruß,

Trev

 

[Trevanian]

Release von v0.3

Viele Leute wollten die Software nicht nutzen, da sie nur mit Keyfiles arbeiten oder aber zumindest SSH auf einem anderen Port als 22 laufen haben.

Dem wirke ich hiermit entgegen: v0.3 erlaubt das Setzen des SSH-Ports für jeden(!) Host, sowie die Verwendung eines entsprechenden Keyfiles.

Zudem verfügt die Software nun über ein TrayIcon, mit dem sich schnell und unkompliziert alle Funktionen und Befehle nutzen lassen, während die Software minimiert bleibt.

Weiterhin wurde das Hinzufügen/Bearbeiten neuer Hosts deutlich überarbeitet und sollte nun übersichtlicher und Benutzerfreundlicher sein.
Die Geschwindigkeit der Anwendung konnte ich weiter steigern und es gab einige Bugfixes.

Viel Spass damit! :-)

Gruß,

Trev

 

[Trevanian]

UPDATE:
Soeben habe ich TinyAdmin v0.3-2 veröffentlicht und empfehle jedem dringend ein Update, da in der alten Version eine (wie ich finde) kritische Sicherheitslücke besteht.
Hatte sich ein Angreifer Zugang zum Computer des Nutzers verschafft, bestanden folgende Gefahren im Hinblick auf die durch meine Anwendung gespeicherten Daten:

• Es waren nur die Passwörter verschlüsselt gespeichert, nicht jedoch Daten wie z.B. die IP-Adressen/Hostnamen: dies zeigte dem Angreifer weitere Ziele auf (z.B. für DDoS-Attacken) und erleichterte durch weitere Informationen (wie z.B. den Benutzernamen) auch direkte Angriffe.
• Das für die Verschlüsselung verwendete Passwort war fest in die Anwendung integriert: mit einem Java-Decompiler lies es sich einfach aus dem .jar auslesen und somit konnte der Angreifer die Daten entschlüsseln.

Folgende Änderungen gibt es:

• Wahl eines Passwortes durch den Benutzer und Verschlüsselung aller Einstellungen (statt nur der Passwörter).
• Die Anwendung drängt sich nicht mehr in den Vordergrund.
• "First-Start-Wizzard" hilft dem Benutzer beim ersten Start der Anwendung bei der Konfiguration.
• Wenn man im Einstellungsmenü unter dem Punkt "Kommandos" einen der Befehle des gewählten Kommandos editiert und einfach auf "Speichern" klickt, ohne vorher die Veränderung an der Tabellen-Zelle mit "Enter" zu bestätigen, wird die Änderung nun trotzdem übernommen.

Wie immer freue ich mich auf Feedback und neue Vorschläge!

DOWNLOAD: klick mich.
(Hinweis: Eventuell habt ihr noch die alte Page im Cache, falls ihr also "v0.3-2" nicht findet, ladet bitte die Seiten neu.)

Gruß,

Trev

 

[Deathcore]

Sehr geiles tool!

Als kleine Anmerkung:

wenn ihr ein Server ohne Sudo habt müsst ihr dennoch das SUDO passwort eintragen

 

[Trevanian]

Hallo Deathcore,

freut mich dass dir das Tool gefällt!

Was genau meinst Du damit, dass man ein Sudo-Passwort eintragen muss, wenn der Server kein Sudo hat? Das beunruhigt mich jetzt etwas
Falls Du also einen Fehler gefunden haben solltest, beschreibe das Ganze bitte nochmals genauer! Danke Dir schonmal im Voraus.

Gruß,

Trev


P.S. Die Software kann nun auch direkt über die Hauptseite der Homepage per Java Webstart gestartet und getestet werden. Sie läuft zwar in einer Sandbox, ist aber voll funktionsfähig.

 

[Deathcore]

so ich erkläre mein gebrummel mal kurz

ich trage als benutzer direkt den root ein und dessen passwort. Dennoch muss ich das rootpassword erneut als sudopassword eingetragen um z.b. Updates zufahren. Ich denke nicht das es ein Programmierfehler ist aber es widerspricht zumindestens meiner Logik

Das kannste ja ganz einfach mit IF abfangen...

 

[Trevanian]

@Deathcore

Ich habe das Ganze jetzt mal ausgetestet und kann dieses Verhalten leider nicht bestätigen. Habe hier mal kurz ein 1mb großes Video gemacht: klick mich.
Das Video ist ziemlich grottig, aber ich glaube man kann ungefähr erkennen was passiert.
Wie Du siehst, funktionert bei mir das Update als root und zwar ganz ohne sudo-Passwort.

Hast Du irgendetwas anders gemacht? Welches Betriebssystem läuft auf dem Server?

Gruß,

Trev

 

[Deathcore]

Das neuste Debian. Ich kontrolliere nochmal schnell was ich gemacht hab.

 

[Trevanian]

Wie schauts aus? Fehlalarm? Bug? Was ist es denn nun?

Ich würds gerne lösen

Gruß,

Trev

 

[Deathcore]

Fehlalarm.

Sorry für die Panik. Cooles Tool bei wachsender Anzahl an Linuxservern auf der Arbeit kommt das sicher aufn Rechner...

 

[Trevanian]

Na dann bin ich ja beruhigt.

Ich habe mir dennoch das ganze Hinzufügen/Entfernen/Bearbeiten von Hosts nochmal genau angeschaut und dabei einige Bugs entdeckt.

Jetzt muss ich zwar erstmal Prüfungen schreiben, aber so ca. Ende Juli/Mitte August wird dann die neue Version rausgehen

Gruß,

Trev

 

[Xile]

Super Tool,

werde es heute Abend direkt bei meinem Homeserver testen...

Was cool wäre wenn man eigene Betriebssysteme anlegen könnte und auch die Standardkommandos (Reboot, Shutdown,etc) für die einzelnen Betriebssysteme ändern könnte! Habe an der Arbeit einige SLES11 Systeme... die fehlen unter den Betriebssystemen...!

 

[Trevanian]

@XILE

Danke für deine Anregungen, ich habe lange auf jemanden gewartet, der über die Betriebssysteme meckert: Jetzt habe ich wieder einen Grund etwas zu ändern

Deine Vorschläge werden in die Nächste Version aufgenommen, versprochen
Diese erscheint voraussichtlich Ende Juli/Mitte August.

Was ich jedoch von Dir bräuchte, wären einige Informationen zu deinem Betriebssystem:

• Wie lautet das -einzeilige- update/upgrade Kommando? (z.B. apt-get update && apt-get upgrade)
• Wie lautet das der Reboot Befehl? (z.B. reboot)
• Wie lautet der Shutdown-Befehl? (z.B. shutdown -h now)
• Nutzt das System sudo? Kann ich also z.B. einfach sagen: "sudo apt-get update && sudo apt-get upgrade" ?
• Ist die Ausgabe von (Fehler-)meldungen auf Deutsch oder Englisch? Also z.B. "Authetifizierung gescheitert" oder eben "Authentication failed". Dies ist wichtig für meine Message-Facility, welche Fehlermeldungen auswertet und generiert.
• Wie lautet der konkrete Name des Betriebssystems?

Wenn ich all diese Informationen habe, kann ich dein OS in die Software aufnehmen. Leider kann ich es nicht selbst testen und muss mich daher voll auf deine Angaben verlassen.

Gruß,

Trev