Installationsmerkmal gesucht

[alex0801]

Hallo zusammen,

ich brauch für eine zu entwickelnde Anwendung (Java) ein eindeutiges Identifikationsmerkmal einer Linux-Installation.
Für den Windows-Client hab ich ein einfaches und ausreichend zuverlässiges Merkmal gefunden: Den Erstell-Zeitstempel von "c:\windows\". ich weiß, das ist auch nicht 100%ig, aber für mich ausreichend genug.

Dummerweise kennt ext3 und co. kein "Erstelldatum" für Verzeichnisse und Dateien, sondern nur ein "modifiziert am" und "zuletzt gelesen am".
Hab schon anderweitig dem Tipp bekommen mit udevinfo diverse Daten zur root-Partition abzufragen und das Ergebnis als Identifikationsmerkmal zu benutzen. Doch zum einen weiß ich nicht ob udevinfo auf jeden Standard Linux vorhanden ist, und zum anderen weiß ich nicht ob bei einem Paketupdate die Ausgabe vielleicht anders aussieht und somit sich das Merkmal auf einmal ändert.

"hostid" ist auch zu unzuverlässig. Auf 2 von 3 meiner Linux-Systeme (Ubuntu und Debian) ist die ID identisch. Die MAC-Adresse hatte ich auch schon in betracht gezogen. Aber oft schalten Laptopuser ihre unbenutzen Netzwerkdevices je nach Standort an oder aus, und damit ändern sich auch die für Java sichtbaren Adressen.

Letzten Endes kommts mir drauf an, eine Linuxinstallation von der nächsten zu unterscheiden. Ich hab kein Problem damit einen Konsolenbefehl auszuführen und das Ergebnis zu parsen. Nur sollte das Ergebnis nicht durch Updates verfälscht werden können und sich von anderen Installationen unterscheiden.

Fällt hierzu jemandem was passendes ein? Oder kann ich "beruhigt" udevinfo benutzen?

Gruß
Alex

[cosmac]

hi,

ext2/ext3 kennt ein ähnliches Datum: das Erstellungsdatum des Filesystems, auslesbar mit "tune2fs -l /dev/hdxy | grep created". Das ist auch nicht so leicht zu fälschen wie z.B. die UUID der root-Partition, die ja vom Namen her dafür optimal wäre.

Das Problem, dass z.B. udevinfo nicht installiert ist, sehe ich eigentlich nicht. Jede Anwendung hängt von anderen Paketen ab, also kann deine auch gewisse Pakete voraussetzen. Wenn das nicht geht, würde ich die fragliche Funktion direkt in mein Programm einbauen. Die nötigen Systemaufrufe ändern sich doch extrem selten und mit dem Quelltext von z.B. blkid oder tune2fs als Vorlage sollte das kein Problem sein.

Auf eine Abhängigkeit von udev würde ich mich allerdings nicht einlassen. Da hat sich in der Vergangenheit oft einiges geändert. Außerdem ist auf keinem meiner Rechner irgendwas udev-artiges installiert und deine Anwendung müsste schon lebenswichtig sein, bevor ich deswegen udev installiere.

[alex0801]

Prima. Danke. Ich werd's probieren.

- Alex

[catdog2]

ext2/ext3 kennt ein ähnliches Datum: das Erstellungsdatum des Filesystems, auslesbar mit "tune2fs -l /dev/hdxy | grep created".

Moment, man kann nicht davon ausgehen, dass ext2/3/4 benutzt wird. Es gibts ja noch andere Dateisysteme, die durchaus nicht selten benutzt werden.

Wenn das nicht geht, würde ich die fragliche Funktion direkt in mein Programm einbauen. Die nötigen Systemaufrufe ändern sich doch extrem selten und mit dem Quelltext von z.B. blkid oder tune2fs als Vorlage sollte das kein Problem sein.

Könnte in Java unter umständen problematisch werden, wenn ich mich nicht recht irre.

[alex0801]

>> Könnte in Java unter umständen problematisch werden, wenn ich mich nicht recht irre.
Jepp. Aber ich muss ja nicht den Source integrieren. Kann ja dort "abschauen".

ext2/ext3 ist schon okay. Das kann ich vorraussetzen.

Allerdings hat mir "tune2fs -l /dev/hdxy | grep created" einen Fehler ausgespuckt. Dem passen die Argumente scheinbar nicht (ja, ich war so schlau und hab /dev/sda(1), welches bei mir existent ist angegeben).

Ein weiteres Problem ist: "tune2fs" ist auf 2 von 3 meiner Testsysteme nicht "per default" installiert oder nicht per non-root zugänglich. Das einzige was ich vorraussetzen kann ist ein ext2/3 Dateisystem und eine passende Java-Installation und eine User-Umgebung (nicht root). Mehr darfs nicht sein. Ergo ist "tune2fs" nicht die Lösung.

Bin also noch kein Stückchen weiter. Leider. Gibts nicht irgendwas in /proc oder so an das ich mich klammern kann? Gibts vielleicht ein Verzeichnis oder eine Datei die garantiert nie angerührt wird, und somit das Datum im Dateisystem gleich bleibt?

Gruß
Alex