Konfiguration für einen Dienst

[hesch21]

Hallo

mir kommt einfach keine Idee mehr! Ich habe einen Dienst, der läuft auf bis zu 2'000 Clients bei demselben Kunden. Und dieser Dienst benötigt beim Start etwa zwanzig Konfigurations-Einstellungen (z.B. den Port und die IP des TCP/IP-Servers, mit dem der Dienst kommuniziert). Diese Einstellungen werden zentral im Steuerungsprogramm (TCP/IP-Server) definiert und zur Zeit in einer Konfigurationsdatei auf dem Server hinterlegt. Das ist eine CFG-Datei im Textformat, könnte aber auch eine XML- oder INI-Datei sein. Das spielt an sich keine Rolle.
Das Problem ist, dass die Datei eben vom Dienst aus gesehen 'irgendwo' auf dem Server liegt und vor allem seit Vista und mit W-7 der Zugriff vom Dienst aus auf die Datei nicht mehr funktioniert. Mit Rechten hat das nichts zu tun, sondern damit dass auch über einen UNC-Pfad der Dienst nicht auf's Netzwerk zugreifen kann.
Behelfsmässig habe ich nun die Datei einfach auf alle Clients kopiert, aber das ist wirklich keine Lösung. Auch wenn eine Software-Verteilung vorhanden ist, ist es doch blödsinnig, wenn man nach jeder Konfigurationsänderung die Datei an 2000 Clients verschicken muss.

Aber wie gesagt, ich komme auf keine Idee, wie man das anders lösen könnte. Wenn ich die Datei nicht bereits für den Aufbau der TCP/IP-Verbindung benötigen würde, könnte ich die Konfigurationsdaten über die TCP/IP abholen, aber eben.

Für jeden Tipp wäre ich wirklich dankbar.

[mkinzler]

Ein Dienst läuft in einem eigenen Benutzerkontext. dieser Benutzer benötigt den Zugriff auf die Netzressource

[himitsu]

Müssen denn alle Konfigurationen in dieser Datei gespeichert werden?

Es reicht ja überall nur das, was für die Kommunikation mit dem Server notwendig ist.
(es sei denn der Port ist fest und der Dienst sucht einfach das Netzwerk nach diesem Server ab)

Also die nötigsten Konfigurationen werden lokal in einer Datei oder in der Registry abgelegt
und alle anderen Konfigurationen kann sich der Dienst dann schön zentral direkt von der Server-Anwendung abrufen.

Irgendwo mußt du ja auch den Netzwerkpfad deinem Dienst mitteilen, wo er aktuell die Konfigurationsdatei holen soll. (oder ist das etwa hart einprogrammiert? :stupid: )

[Bummi]

Muss der Dienst als Systemdienst laufen, sonnst könntest Du per UNC-Pfad die Datei ziehen.
Ansonsten irgend ein Server HTTP/NamedPipes des ausliefern kann ?
Oder ein RunAs (nicht das von der Konsole) mit einem Batchaufruf ...

[mjustin]

Zitat:

Zitat von hesch21 (Beitrag 1185956)

Und dieser Dienst benötigt beim Start etwa zwanzig Konfigurations-Einstellungen (z.B. den Port und die IP des TCP/IP-Servers, mit dem der Dienst kommuniziert). Diese Einstellungen werden zentral im Steuerungsprogramm (TCP/IP-Server) definiert und zur Zeit in einer Konfigurationsdatei auf dem Server hinterlegt.
...
Für jeden Tipp wäre ich wirklich dankbar.

Mit diesem einfachen Verfahren können die Dienste (auf allen 2000) Clients komplett ohne lokale Konfiguration die Verbindung zum TCP/IP Server aufbauen:

• der TCP/IP Server sendet IP Multicast Nachrichten (UDP Broadcast), in denen er angibt unter welcher IP Adresse er installiert ist
• der Service auf dem Client verwendet beim Start UDP um diese Nachrichten zu empfangen
• der Client erfährt so wo der Server ist und kann eine Verbindung zu dessen IP Adresse herstellen
• der Client holt sich per HTTP GET Anforderung weitere Konfigurationsinformationen (oder über ein anderes Protokoll, das der Server anbietet)

alle dazu notwendigen Komponenten sind in Delphi bereits enthalten (Indy).

In einem Blogartikel habe ich beschrieben wie man damit zum Beispiel ActiveMQ Server im Netz findet:


Discover ActiveMQ brokers with Delphi and IP Multicast

[hesch21]

Hallo zusammen

voerst mal Danke für Eure Tipps. Am vernünftigstens tönt mir die Lösung von mjustin. Ich muss mir das nun noch genauer zu Gemüte führen. Vor allem interessiert mich dabei, wie stark man damit ein Netz belastet, wenn da der Server mehr oder weniger dauernd 'ins Blaue' hinaus sendet, damit sich die Clients 'anhängen' können. Aber ohne bereits etwas nachgeschaut zu haben, nehme ich mal an, dass da bei den Indys Parameter vorhanden sind, im das zu steuern.

[hesch21]

Hallo MJustin
ich habe jetzt ein wenig mit den Indy-Multicast-Koponenten geübt. Aber entweder bin ich mit Blindheit beschlagen oder es geht auch da nicht anders als dass der Client die Port-Nummer und IP (MulticastGroup) des Multicast-Servers wissen muss. Und nun verdrahte ich das wieder fest im Programm oder ich bin genau gleich weit wie zuvor. Ich muuss diese beiden Werte irgendwo (Registry, INI-Datei oder CFG-Datei) lokal auf auf den Rechnern haben.

Noch zu Bummi
Ja, der Dienst muss zwingend unter SYSTEM laufen.

Zu himitsu
Ich hatte ja erwähnt, dass ich ja die Idee hatte, die Daten über TCP/IP vom Server zu holen, nur bringt es nicht sehr viel, wenn trotzdem lokale Einstellungen gespeichert werden müssen. Aber es ist schon so, dass sich diese auf IP und Port reduzieren lassen. Und nein, der UNC-Pfad ist nicht fest verdrahtet sondern wird bei der Installation des Dienstes in die Registry gespeichert.

[mjustin]

Zitat:

Zitat von hesch21 (Beitrag 1186242)

Hallo MJustin
ich habe jetzt ein wenig mit den Indy-Multicast-Koponenten geübt. Aber entweder bin ich mit Blindheit beschlagen oder es geht auch da nicht anders als dass der Client die Port-Nummer und IP (MulticastGroup) des Multicast-Servers wissen muss.

Die Multicastgroup ist nicht die IP des Servers. Es ist eher eine "ID" für einen Service, zum Beispiel beim ActiveMQ Broker in der Standardkonfiguration die Adresse 239.255.2.3 - diese Adresse existiert nicht in meinem Netz.

Ich schaue mir mal den Indy UDP Server an, aber im Prinzip muss es so funktionieren wie ich es mit dem Apache ActiveMQ schon erfolgreich getestet und im Blog beschrieben habe:

Discover ActiveMQ brokers with Delphi and IP Multicast

[Bummi]

Die Idee des Broadcastens von mjustin hat einiges für sich, die Nachricht braucht ja nur alle Paar Sekunden gesendet werden und muss kaum mehr als die faktische IP/Port des Dienstes transportieren.

[himitsu]

Wäre es da nicht andersrum viel schöner?

- der Server lauscht die ganze Zeit nur rum
- kommt ein Client, sendet er einen Broadcast "hallo Server, wo bist du?"
- und dann antwortet der Sever dem Clienten und sie bauen die Verbindung auf

So müßte niemand ständig irgendwas rumspammen, in der Hoffung es könnte eventuell irgendwann mal jemand was wollen.