monitord - LUA als Skriptsprache ?

[Buebchen]

Hallo @all,

nach langer Zeit habe ich nochmal ein wenig am monitord arbeiten können. Da immer wieder die Frage nach serverbasierten Funktionen aufkommt habe ich mir überlegt, ob es nicht Sinn macht LUA als Skriptsprache am Server einzuführen.

Die Integration scheint recht einfach zu sein. Vielleicht könnten die anderen Entwickler mal sagen, wie Sie das sehen.

Mögliche Stellen wo man LUA einsetzen könnte:

In den Socketthreads um z.B. Informationen zu verändern bevor sie weitergegeben werden (NA durch Notarzt ersetzen, RICs filtern, Um eigene Kommandos zu erstellen [ Client schickt an Server -> LUA erkennt das und führt eine Aktion aus] ...)
Im globalen Dispatcher um z.B. die Aufnahme zu starten / stoppen - oder auch im externe Programme aufzurufen.

wie genau die Integration gemacht wird muss man noch überlegen.

[Edit]
Da ich nicht weiss, wie lua mit verschiedene Threads harmoniert würde ich vorschlagen, daß erstmal am Globaldispatcher lua Skripte hängen. Damit sollten die meisten Funktion möglich sein. (Mal abgesehen von Custom-Commands von den Clients).

[nepomuck]

ob es nicht Sinn macht LUA als Skriptsprache am Server einzuführen.

Ich finde es keine gute Idee, neue Funktionen einführen zu wollen bevor die Alten überhaupt komplett implementiert wurden.

Allen voran fehlt die ursprünglich geplante History-Funktion. Darüber könnte ein Client vergangene Events nachfordern und beim Start beispielsweise den Staus der Fahrzeuge aus der Server-DB erhalten.

Das Protokoll dümpelt irgendwo zwischen Version 0,3 und 0,4 herum. Wir sollten langsam an den Punkt kommen, wo wir eine Art Stable-Release vom monitord und dem zugehörigen Protokoll festlegen. Dann haben wir eine solide Basis für die Client-Entwickler. (sofern es welche gibt -- ich arbeite seit ein paar Tagen übrigens wieder aktiv an einem Java-Frontend!)

Was LUA angeht sehe ich bei der bestehenden Architektur eigentlich keine Notwendigkeit, so etwas direkt in den Server zu integrieren. Die von dir vorgeschlagenen Features liessen sich in ein eigenständiges Filterprogramm einbauen, welches direkt auf dem Server läuft und via localhost:9333 mit dem Server spricht. Die "gefilterten" Werte gäbe der LUA-Layer dann mit dem Original-Protokoll z.B. auf Port 9334 aus.

Ein Client könnte dann entscheiden, ob er "RAW"- oder "Filtered"-Access zum Server haben will.

Anders gesagt: Ein monitord-Server wertet alle Daten auf einem Feuerwehr-Kanal aus. Der Client des neugieregen Funkwarts bekommt alle Daten aus dem Landkreis, wärend der Client in der Zentrale nur die Informationen zur eigenen Wehr sieht.

viele Grüße,
Andreas

[Buebchen]

Dann lass es mich anders formulieren: Aus persönlichem Interesse kann man den monitord demnächst mit LUA kompilieren. Wer das im configure nicht selektiert kann natürlich wie gehabt arbeiten.

Ein eigenes Frontend wäre etwas tolles. Das würde mich dann auch aus persönlichem Interesse dazu motivieren über eine Historie nachzudenken :)

[nepomuck]

Aus persönlichem Interesse kann man den monitord demnächst mit LUA kompilieren.

Wenn du das konkret brauchst ist das ja ok.

Ein eigenes Frontend wäre etwas tolles.

Code steht online (sieh neuen Post in diesem Forum).
Was "Tolles" ist das noch nicht -- aber zumindest mal ein Anfang.

Andreas

[Buebchen]

Notiz zum Thema lua:

In der Konfig kann man nun zwei scripts angeben:

?>

 Monitord 
 screen 
 DEBUG1 
 socketfilter.lua 
 pluginfilter.lua 

Diese Skripte müssen jeweils eine Funktion bereitstellen, die bei jedem Paket, das verteilt wird aufgerufen wird.

Für die Sockets ist das die function filter() - z.B. so:

-- SocketFilter.lua

--
-- Filter für den SocketServer - wird pro aktiven Client aufgerufen
-- 
-- Globales Array "arg" enthält die Daten vom Auswertermodul
--
-- Zusätzliche Werte im Array:
--
-- client_authenticated: 	0/1  (1=angemeldet)
-- client_ip:			IP-Adresse des Clients
-- client_loginname: 		Anmeldename
-- client_type:			fms32, crusader, monitord
--
-- Rückgabewert: 0 = an Client senden, 1= nicht an Client senden, alle anderen = an Client senden
--

local sperrliste = {"1111111", "2222222"} ;

function myfilterFMS32()
	for index,testwert in pairs(sperrliste) do 
		if (testwert==arg["ric"]) then
			return 1
		end
	end
	return 0 ;
end
	
function filter() 
local dummyValue=1 ;

-- wird für jedes Telegramm (pocsag, fms, zvei) aufgerufen
	if (arg["client_type"]=="fms32") then
		return myfilterFMS32() ;
	end
	
	if (arg["client_type"]=="crusader") then
		-- nix
		dummyValue=2 ;
	end

	if (arg["client_type"]=="monitord") then
		-- nix
		dummyValue=3 ;
	end	
		
	return 0;
end

für die plugins ( bisher nur das mysql plugin ) es es die function pluginfilter. Der Name des plugins wird in der monitord.xml definiert (name="mysql", name="mysql1", ...). Man kann also auch mehrere mysql Plugins laden um die Daten in einzelne DBs zu schreiben. Anhand des Namen kann man dann unterschiedliche Daten sperren oder passieren lassen.

-- pluginfilter.lua

--
-- Filter für den SocketServer - wird pro aktiven Client aufgerufen
-- 
-- Globales Array "arg" enthält die Daten vom Auswertermodul
--
-- Zusätzliche Werte im Array:
--
-- plugin_name:			z.B. mysql (aus monitord.xml)
--
-- Rückgabewert: 0 = an Client senden, 1= nicht an Client senden, alle anderen = an Client senden
--

local sperrliste = {"1111111", "2222222"} ;

function pluginFilter()
	if (arg["plugin_name"]=="mysql1") then
		for index,testwert in pairs(sperrliste) do 
			if (testwert==arg["ric"]) then
				return 1
			end
		end
	end
	return 0 ;
end

den Inhalt des arg Array kann man einsehen, wenn man sich im Debugmodus das Protokoll anschaut. Ich schreibe das hier, damit ich später selbst noch weiss, was ich getan habe :)

Wichtig: Es muss LUA Version 5.1 oder höher sein !

[mdi]

Moinmoin,

ich habe ein Problem... ;).

Eben habe ich mir die Geschichte anschauen wollen und den monitord mit LUA (--with-lua) compiliert. Scheinbar interessiert es ihn aber überhaupt nicht, dass er den socketfilter nutzen soll - weder im Log erscheint ein Hinweis darauf, dass LUA jetzt etwas tut, noch wird die Ausgabe gefiltert (selbst bei "return 1" als einziger Funktionsinhalt). Gibt es a) etwas zu beachten und b) woran kann man sehen, dass arbeitet?

Edit: Es tut. LUA-Sourcen laden, im MSYS make install und dann ab dafür. Woran man sehen kann, dass LUA arbeitet? Print-Ausgabe, steht dann im monitord-Fenster. os.execute() läuft auch auf einem Windows XP SP3.

Viele Grüße
Martin

[frank34]

Hallo Leute,
habe monitord auf einem WinXP System laufen. Geht prima.
Jetzt habe ich das pluginfilter.lua angepasst.

Rufe ich monitord direkt im Verzeichnis C:\Programme\monitord auf wird auch alles so gefiltert wie ich es möchte.

Installiere ich monitord aber als Dienst wird keine Filterung vorgenommen.

Muss ich in monitord.xml noch einen Pfad angeben, wo das lua script steht ???

Grüsse Frank

[mdi]

Hallo Frank,

dass das schonmal prima läuft an sich, ist gut - danke auch für dieses Feedback :)!

Die pluginfilter.lua sollte in dem Verzeichnis liegen, in dem auch der monitord liegt. Ich erinnere mich dunkel, dass bei Installation als Dienst Probleme mit (relativen) Pfaden auftreten können. Das heißt, es ist am geschicktesten, in der monitord.xml absoulte Pfade anzugeben (nicht ./pluginfilter.lua - sondern c:\programme\monitord\pluginfilter.lua, natürlich an Abhängigkeit der jeweiligen Gegebenheiten und Pfade).

Genauer herausbekommen kannst Du das, in dem Du den Loglevel auf "DEBUG" stellst, dann erscheinen beim Start des Dienstes im Logfile Meldungen wie: "successfully loaded filterskript pluginfilter.lua" oder halt "not found: pluginfilter.lua" (vergleichbar, ich hab den genauen Text nicht im Kopf...).

Ich hoffe, das hilft Dir erstmal :)?!

Viele Grüße
Martin