New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fake Product UUID Case Sensitivity Incorrect on Rockstor 4 #2290
Comments
Also, probably for another day, but would it make sense to switch to a software id, something like /var/lib/dbus/machine-id instead? I came across this blog, while researching something else (yeah, it's kind of old, but still seems to apply): http://0pointer.de/blog/projects/ids.html |
@Hooverdan96 Yes I think we did consider this approach early on, but with the motherboard references we at least get, in the majority of cases, a re-install Appliance ID stability/persistence. Where as I think machine-id is static only for a particular install which is essentially equivalent to what we started with in the first place before we moved to the current motherboard reference. And this move was for the very reason of re-installs generating new id's each time. Take a look here for the early history: "Make Appliance UUID persistent" #1348 Plus I think the current 'method' is now established in our community and so serves well as-is; bar the issue here and the related fake uuids we've found. But on the idea of enhancements, I had considered having a file stashed say at rockstor.com that we could use as a live update of known fake uuids. That way as and when fake uuids were reported we could simply update that file so that folks wouldn't have to rely on an updated installer for fake uuid identification. Akin to the local and remove (repo) Rock-on references, only in reverse. But that is not directly related to this issue and we should probably discuss this idea on the forum to round out the file format etc. Plus I'd rather cut down on internet requirement rather than add to it but then again this is not critical or even needed in the majority of cases. Just dropping the idea in as per your own actions here for context really. |
@phillxnet All good points. I like the idea of a "central file" to manage the fake uuids, if that becomes feasible. Thanks for you extensive response. |
I'm currently working on this issue. |
Upon considering this issue/problem we have the following context: Newer kernels output lowercase; in line with https://tools.ietf.org/html/rfc4122 as does dmidecode: https://savannah.nongnu.org/bugs/index.php?53569 As from kernel 4.17 product_uuid output is lowercase: Our newer code / rpm-releases are only now released for Leap versions with kernels newer than this lowercase product uuid change, new installs of Rockstor 4 using supported versions of Leap only: Leap 15.2 onward as of this issue, will always produce lowercase Appliance ID's. It is also noteworthy that our existing fail-over to non persistent Appliance ID's in the even of identifying a 'fake' product uuid also, itself, generates lowercase Appliance IDs via hostid and Python2's uuid.uuid4()
I am therefore inclined to simply move the known fake produce uuids over to being lower case. This way we fix the issue at hand, 'failure to recognise a known fake uuid', and preserve our existing mechanism for generating an Appliance ID. Consequently I am to re-name this issue accordingly. N.B. this does not address the wider, but related issue that Rockstor 4 will generate a lower-case variant of what Rockstor 3 would on the same motherboard; assuming a non fake product id. However Appman does present a fix in this scenario via Appliance ID editing. |
…2290) As Rockstor 4 is associated with newer kernel versions by default, which in turn now produce lowercase product uuid's, we fail in the majority of cases to match against our mixed case tuple of know fake product uuids. Fix by normalising on lowercase in line with the sited uuid standard of: rfc4122 as per the kernel. Includes formatting clean-ups of the known fake product uuids. N.B. no functional change is made to how an existing install, of the same major version, generates it's Appliance ID.
…ensitivity_Incorrect_on_Rockstor_4 Fake Product UUID Case Sensitivity Incorrect on Rockstor 4 (#2290)
It seems Rockstor 4, or rather OpenSUSE generates the same UUID but in a different case to Centos.
The file /opt/rockstor/src/rockstor/system/osi.py detects the fake UUID but in a case sensitive way. This means that proper appliance IDs are not generated in RS4 for systems that present with a fake UUID.
The proper fix should make the Fake UUID detection process case insensitive. An alternative fix would be to list fake uuids in both upper and lower cases.
EDIT/ADDITION by @phillxnet:
Please see comment: #2290 (comment) for context of a refinement and name change to this issue. The issue of failing to identify known fake Product uuid's was tracked down to a change in 4.17 kernels onward. Hence we fail to match now in 4 when we did in 3. But as we no longer release for CentOS we can simply change our known fake uuid's over to lower case. We thus have 2 issues here; fake uuid detection, and Rockstor 3/4 appliance ID case change: upper/lower respectively. This issue is being considered as focused on the first of these. Appman can 'fix' the second via it's Appliance ID edit capability.
Linking to the associated forum thread for this issue: https://forum.rockstor.com/t/duplicate-appliance-ids-generated/7723/14
The text was updated successfully, but these errors were encountered: