Windows-Dienste überwachen

[Pirf2]

Servus,

ich steh von einem "Google-Problem": Trotz langjähriger Web-Erfahrung, finde ich für mein Problem keine Antworten, obwohl es sie mit Sicherheit gibt, und warum? Weil ich nicht die passenden Suchbegriffe finde! Egal, Problem:

Ich schreibe ein Java-Utility zum Remote-Monitoren und Melden von Serverproblemen. Außer Ping und anderem Kleinkram, möchte ich auch Windows-Dienste und Prozesse auf ihren Zustand hin abfragen. Jede Menge Utilities machen das, auch ohne große Authentifizierung und sonst was, Win scheint diese Informationen ziemlich freizügig bereitzustellen. Aber wie komm ich da dran??? Sind das RPC-Calls? Wenn ja was für welche? Das einzig brauchbar quelloffene, was ich gefunden habe, war in Perl und nutzt dort eine vorhandene Lib (Win32::Services). Gibts vielleicht auch schon für Java fertige Libs für sowas?

Und wo wir schon mal dabei sind, später möchte ich auch auf Solaris-Maschinen laufende Prozesse abfragen. Geht das zufällig so ähnlich? Oder gibts da gar nen übergreifenden Standard?

Danke!

Greetz,
Pirf2

[Lokadamus - nixBock]

mmm...

Das gesuchte Protokoll dürfe SNMP sein. Damit Windows aber die Informationen bereitstellt, muss auch der Dienst für SNMP gestartet sein. Ob der Dienst allerdings zum Standard von Windows gehört, weiss ich nicht. Windows hat dann noch den Dienst WMI, welcher die gleichen Informationen bereitstellt, aber propritär ist ... unter Linux kann man mit Nino (http://nino.sourceforge.net/nino/index.html) oder Nagios (http://www.nagios.org/) diese Sachen abfragen. Nino kann wohl auch WMI. Für Nagios gibt es auch einige Erweiterungen und ein paar Schwesterprojekte, aber ob es WMI frisst, weiss ich nicht. Ebenso ist es immer wieder ein Krampf die Mibs herauszufinden :(. Nino hab ich noch nicht eingesetzt, zu wenig Zeit zum Testen :( ...

[Pirf2]

Danke, mit den paar Stichworten kann ich schon mal einiges weitersuchen. SNMP kann ich sicherlich universeller einsetzen, aber ich schau mal, ob ich für die Windows-Beobachtung eine Java-WMI-Klasse finde.

[Gast]

Dafür gibt's ganz normale Win32-APIs. Schau mal in der MSDN nach diesen APIs:

OpenSCManager
OpenService
EnumServiceStatus
QueryServiceConfig
CloseServiceHandle

Das müssten eigentlich alle sein, die du brauchst um eine Liste aller Dienste mit Ihrem Status und so ziemlich allem rauszufinden, was Windows zu einem Dienst rausrückt.

[Pirf2]

Danke, aber die API-Funktionen hatte ich auch schon gefunden. Problem ist nur, wie ich die per Remote aufrufen kann - weiß ich schon generell nicht, noch weniger von Java aus. Ich habe jetzt einiges über RPC-Calls rausbekommen, und daß es da ein svcctl-Interface gibt, daß die Kommunikation für den SCM regelt... aber noch nicht so richtig verstanden, was das alles ist, und wie das geht. RFCs oder sowas scheints dazu jedenfalls nicht zu geben, scheint eher alles MS-proprietär zu sein.

[Pirf2]

Ok, nachdem ich mit einem Paket "jarapac" nicht weitergekommen bin, das sehr vielversprechende IDL-Definitionen für SVCCTL enthielt, weil ich letztere nicht in Javaklassen kompilieren konnte, bin ich jetzt bei Pipes via "jcifs" angelangt. Ich fass es mal zusammen, wo meine beiden Baustellen steckengeblieben sind:

1. Es gibt 2 IDL-Compiler "midlc". Der eine ist von MS, Bestandteil des Plattform-SDK, und spuckt nur C Code aus. Der zweite wird von ein oder zwei Leuten im Rahmen des Samba-Projects als eigenes Paket entwickelt, aber der ist noch Alpha, es gibt ihn nur als Source, und ich kriege die ganzen Libs und Pfade, die der zum selbst-kompilieren braucht, unter Windows hinten und vorne nicht zusammen. Eine Linux-Binary könnte ich mir daheim evtl. bauen, aber die bringt mir hier wohl nix.
Aber ohne die svcctl.idl (die übrigens an einigen Stellen durchs Internet geistert) zu kompilieren, kriege ich dieses Interface in Java nicht verwendet. Dabei macht der Compiler offenbar nur aus *.idl -> *.java. Aber diese Klasse irgendwo zu finden? Pustekuchen.

2. Mit Hilfe des jcifs-Pakets, daß auch bei Samba mitentwickelt wird, und das als lib auch von o.g. jarapac mitgenutzt wird, lassen sich Named Pipes zu Windows aufbauen, egal ob remote oder lokal. Das macht wohl auch obige Variante, die einem dann aber gleich schöne, leistungsfähige Funktionen auf Objektbasis darauf anbietet um Dienste zu starten, zu beenden etc. Gut, wenn das bei mir nicht geht, ich sollte auch mit den Pipes direkt klarkommen. Ich will ja nur eine Anfrage hinpumpen, und aus der Antwort herauslesen, ob der Dienst läuft oder nicht. Aber darüber finde ich NULL Dokumentation, und Reverse mit dem Ethereal bin ich auch nicht viel weitergekommen. Jemand da ne Idee?

Bin auch für jede andere Idee dankbar! Lediglich den Tip, via Cmd-Ausführung ein W32-Utility (psservice oder scm) zu starten, und den Output zu parsen, habe ich schon bekommen. Aber erstens finde ich das extrem uncool, und zweitens hätte ich gerne, daß mein Scanning-Tool auch auf anderen Plattformen läuft (nur die Zielrechner müssen halt mit dem jeweiligen Scan-Plugin zusammenpassen, aber nicht die Scan-Plattform).

THX,
Pirf2

[fabnet2k]

da gabs doch mal so ein tool im verwaltungsmanager oder ?

[Sephiroth]

Danke, mit den paar Stichworten kann ich schon mal einiges weitersuchen. SNMP kann ich sicherlich universeller einsetzen, aber ich schau mal, ob ich für die Windows-Beobachtung eine Java-WMI-Klasse finde.
Hast du mal http://jawinproject.sourceforge.net/ probiert? Das bietet afaik WMI Klassen an.

beispiel: http://forums.belution.com/en/java/000/003/41.shtml

[Pirf2]

da gabs doch mal so ein tool im verwaltungsmanager oder ?

Der kann (ungefähr) das was ich will - aber ich würde es gerne selbst können... ;-)
Nein, mein Javatool soll sehr modular werden, also auf der einen Seite beliebige Scan-Plugins fressen (Ping, Win-Dienste, Solaris-Prozesse, später auch Plugins die auf der Gegenseite ein eigenes Util erfordern), und auf der anderen Seite Output-Plugins (Screen, Log, eMail, SMS). Und am Ende möchte ich das ganze gerne Quelloffen machen. Von daher möchte ich möglichst saubere Lösungen implementieren, und die Verwendung von externen cmd-Tools oder Windows-Programmen gehört nicht unbedingt dazu.