Suche Anhaltspunkt für plattformübergreifende, "unique machine id" ...

[tuxedo]

Hallo zusammen,

stehe mal wieder vor nem kleinen Problemchen das mich seit geraumer Zeit beschäftigt.

Eine Serveranwendung muss Clientrechner unabhängig von der IP (die kann sich ändern) eindeutig identifizieren können. Hatte bisher dafür die MAC-Adressen (client) im System genutzt, diese in hex-string-form konkateniert, gehashed und als ID zum Server geschickt.

Hat prima funktioniert, bis der erste auf die Idee gekommen ist die WLAN-Karte im Notebook je nach Standort aus und einzuschalten. Aus Sicht von Java ist die MAC-Adresse dann "weg", bzw. "wieder da" wenn man die Karte wieder aktiviert.

Bin dann auf die gloreiche Idee gekommen, einfach den Zeitpunkt der Erstellung eines wichtigen Systempfads (z.b. c:\windows) zu nehmen und den zu hashen. Ist auch recht unwahrscheinlich dass die Zeitstempel auf mehreren Rechnern absolut identisch sind.

Unter Windows hat das funktioniert. Einfach "dir /TC c:\windows" gemacht, Ausgabe geparst und gut ist.

Aber Linux scheint sich nicht für das Erstell-Datum zu interessieren und merkt sich das nicht. Das Datum eines Verzeichnisses ändert sich wenn man darin eine Datei ändert oder anlegt --> doof.

Jetzt gehen mir wieder die Ideen aus.
Fällt noch jemand ein "Verfahren" ein, das kein JNA/JNI braucht (zur not geht das parsen eines betriebssystemeigenen Kommandozeilentools) und auf Windows, Linux und Mac anwendbar ist?!

Gruß
Alex

 

[Zed]

Ich würde ja sagen ab besten irgend eine ID die man aus der Hardware ausliest CpuId oder so aber wir reden von Java.

Bezieh dich evtl. auf eine Datei unter Linux die immer existiert

 

[tuxedo]

Was verstehst du unter "auf eine Datei beziehen"?

/etc gibts eigentlich immer. /usr/bin/ wohl auch.
Das wären aber Verzeichnisse. Auf Dateien selbst beziehen ist "gefährlich", da sie wohl auch durch Updates aktualisiert werden können.

Der "Erstell-Zeitstempel" eines Verzeichnisses existiert wie gesagt unter Linux nicht, wohl aber unter Windows. Im Falle von Windows könnte ich es ja so belassen. Aber woran mach ich das in Linux/MacOS fest?

Gibts vllt. in /proc oder so eine Datei die sich garantiert nie ändert?

- Alex

 

[HoaX]

Wie wäre es mit der Filesystem-ID? Oder auf aktuellen Systemen die FS-UUID des Rootfilesystems?

stat -c %i /
vol_id /dev/sda1

Ansonsten fällt mir noch udevinfo ein, darüber kommst du auch an Seriennummern und sonsten Kram der Hardware.
z.B. udevinfo -q all -n /dev/sda

 

[tuxedo]

Ich denke udevinfo ist am brauchbarsten. Vorher mit "mount" schauen welches Device auf "/" gemounted ist, das dann in udevinfo stecken, und die gesamte ausgabe hashen... Fertig.

Weißt du zufällig wie's mit der Verbreitung von udevinfo bei Standardinstallationen diverses Linux Derivate aussieht? Sprich: Wie sicher ist es, dass der Befehl existiert?

Gruß und soweit mal Danke,

Alex

[update]

Ähm, noch was: Wie sicher ist es dass udevinfo auch in einer aktuelleren Version (wieder das Update-Szenario) noch die gleiche Ausgabe liefert?

Andere Frage: Komm ich an solche Informationen auch ohne extra "Programm" ran? Also z.B. via /proc oder so ?!

 

[HoaX]

Ich denke udevinfo ist am brauchbarsten. Vorher mit "mount" schauen welches Device auf "/" gemounted ist, das dann in udevinfo stecken, und die gesamte ausgabe hashen... Fertig.

Weißt du zufällig wie's mit der Verbreitung von udevinfo bei Standardinstallationen diverses Linux Derivate aussieht? Sprich: Wie sicher ist es, dass der Befehl existiert?

udev kam mit Beginn der 2.5/2.6er Kernel, ist also schon ein paar Jahre her. Nomale Desktops sollten es haben, bei Servern wäre ich mir nicht so sicher.

Ähm, noch was: Wie sicher ist es dass udevinfo auch in einer aktuelleren Version (wieder das Update-Szenario) noch die gleiche Ausgabe liefert?

Andere Frage: Komm ich an solche Informationen auch ohne extra "Programm" ran? Also z.B. via /proc oder so ?!

Auf immer die selbe Ausgabe würde ich mich nicht verlassen wollen. Gezielt einzelne Werte raussaugen ist besser imo. An die ganzen Werte solltest du auch über /proc bzw /sys kommen, allerdings stehen die da auch nicht immer so schön als Klartext wie bei udevinfo ... und setzt natürlich ebenso einen 2.6er Kernel voraus.


edit: evtl. interessant für dich: http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf

 

[tuxedo]

Hi,

2.6er Kernel kann ich vorraussetzen. Server kann ich ausschließen. Von daher passt das.

"Immer einen speziellen Wert rauspicken": Naja, wenn sich die Formatierung der Ausgabe ändert, klappt das mit dem rauspicken nicht mehr so.

Da hab ich dann lieber etwas kryptisches das immer an der gleichen Stelle liegt und immer gleich ist/bleibt.

Werd mir die PDF mal zu gemüte führen. Danke soweit mal.

Gruß
Alex

 

[HoaX]

Einzelne Zeilen bleiben schon gleich, nur auf die Gesamtformatierung und Reihenfolge ... würde ich mich nicht verlassen wollen. Wir greppen z.B. die Seriennummer von USB-Sticks aus der Ausgabe und gab bisher nicht wirklich Probleme damit.

 

[tuxedo]

Hab nochmal geschaut. Eine Menge informationen zu Festplatten etc. lassen sich aus /sys/... Unter anderem Hersteller und Modell der Platte. Während udevinfo die Seriennummer der Platte rausbekommt, hab ich sie im /sys/ Pfad vergeblich gesucht.

Jetzt ist nur noch die Frage wie man am besten an die Root-Platte dran kommt. Sprich: Woher weiß ich dass "/" nach /dev/sda1 oder /dev/hda1 eingehängt ist?

"mount" parsen wäre eine Möglichkeit. /etc/fstab parsen eine andere. Oder hat jemand eine zuverlässigere, einfachere Idee?


- Alex

 

[HoaX]

/proc/mounts ?

 

[tuxedo]

Oh, da hätte ich ja auch selbst drauf kommen können... hmmpf.

 

[fjord]

Mal ganz dumm gefragt: wenn du eh schon eine Client Server Architektur hast, warum vergibt der Server dann nicht einfach eindeutige IDs an neue Clients, diese speichern die sich irgendwo und melden sich dann beim nächsten mal wieder damit?

 

[tuxedo]

Das hab ich mir auch schon überlegt. Aber dann bin ich abhängig von dieser gespeicherten ID. Mal abgesehen davon, dass der Client mit "Normal Benutzer" Rechten läuft und ich keine zentrale Stelle am Client habe wo alle Benutzer gleichermaßen schreiben können (ok, ließe sich einrichten, aber das kann ich nicht vorraussetzen. Ich kann nur ein "Standardsystem" vorraussetzen), fällt diese Technik eben flach.

Pro Rechnerbenutzer ginge das. Aber mit gehts wirklich um den Rechner/Client, und nicht um den Benutzer.

- Alex