We have several systems using Jetway ITX motherboards, mainly NF9D and NF692G4 and NF692G6. For all Jetway systems the same Fireinfo-ID is generated, so there is only one Fireinfo-profile shared for all instances. Actually, we get exactly the same ID as the topic starter in this old thread here: https://community.ipfire.org/t/how-to-reset-fireinfo-profile-id/6388 So, the gathering of hardware-informations to generate a unique ID seems to be insufficient. At least for systems from this manufacturer.
Could you please send the output of this command: > sendprofile --hardware-string
(In reply to Michael Tremer from comment #1) > Could you please send the output of this command: > > > sendprofile --hardware-string Here we go: System 1: sendprofile --hardware-string 3b903780-4f79-1018-816e-aeb2724778a7#SSN System 2: sendprofile --hardware-string 3b903780-4f79-1018-816e-aeb2724778a7#SSN System 3: sendprofile --hardware-string 3b903780-4f79-1018-816e-aeb2724778a7#SSN I think the problem here is, that the manufacturer Jetway always uses the the "Product Name" and "UUID" for all boards of the series, even though the systems differ (system 3 has a different CPU for example). The output of dmidecode ist always the same for all three system: dmidecode | grep "Product Name: \|UUID: " Product Name: NF692 UUID: 3b903780-4f79-1018-816e-aeb2724778a7 Product Name: NF692 Actually when I do a diff of the "dmidecode" output of system 1 and 2, there only one line different and thats's the serial number of the installed RAM. System 1: Memory Device Serial Number: 31142517 System 2: Memory Device Serial Number: 31142599 For system 3 (with the other CPU), there are of course more alternating lines: Memory Device Serial Number: 31142599 Processor Information Family: Pentium ID: C9 06 05 00 FF FB EB BF Signature: Type 0, Family 6, Model 92, Stepping 9 Version: Intel(R) Pentium(R) CPU N4200 @ 1.10GHz Current Speed: 1100 MHz (I ommitted the lines that were equal) TL;DR: I think it's obviously not enough to rely on the DMI data. Maye collecting other hardware's serial numbers manually would be needed here to be able to fully distinguish between every unique system. What about the serial number of the system drive? I think about something like: udevadm info --query=all --name=/dev/sda | grep ID_SERIAL E: ID_SERIAL=KINGSTON_SUV500MS120G_50026B778261E280 E: ID_SERIAL_SHORT=50026B778261E280 These values are at least different on all my machines. HTH
For completeness, I also have a Jetway system, NF533-F and that has exactly the same --hardware -string as ChrisK listed.
(In reply to ChrisK from comment #2) > I think the problem here is, that the manufacturer Jetway always uses the > the "Product Name" and "UUID" for all boards of the series, even though the > systems differ (system 3 has a different CPU for example). Great. That is not how IDs work. > System 1: > > Memory Device > Serial Number: 31142517 > > System 2: > > Memory Device > Serial Number: 31142599 > > For system 3 (with the other CPU), there are of course more alternating > lines: Memory stuff is difficult I would say. That used to be changed a lot. Maybe that assumption is no longer true in 2022. > TL;DR: I think it's obviously not enough to rely on the DMI data. Maye > collecting other hardware's serial numbers manually would be needed here to > be able to fully distinguish between every unique system. > What about the serial number of the system drive? I think about something > like: > > udevadm info --query=all --name=/dev/sda | grep ID_SERIAL > E: ID_SERIAL=KINGSTON_SUV500MS120G_50026B778261E280 > E: ID_SERIAL_SHORT=50026B778261E280 We do use the serial number of the root drive as well. Where is the "SSN" part of the hardware ID coming from?
(In reply to Michael Tremer from comment #4) > > Where is the "SSN" part of the hardware ID coming from? This is the product_serial entry and the rest of the entry before the SSN is the product_uuid Jetway is clearly not following the meaning of the first u, unique, in uuid.
(In reply to Michael Tremer from comment #4) > We do use the serial number of the root drive as well. Actually, I don not see any "serial number" string in the JSON, nor any other lines in the code that collects hardware serial-numbers. /etc/init.d/fireinfo uses uuidgen which, by default, generates a random UUID. This ID is stored at /opt/pakfire/db/uuid which, for some reason, is not used by "sendprofile" later. The IDs stored at /opt/pakfire/db/uuid are different on all my systems. Why not using this as the base string for fireinfo's ID instead of the UUID stored in the DMI profile? System 1: cat /opt/pakfire/db/uuid a0f4104e-0683-4b2b-834c-a0dfd6526925 System 2: cat /opt/pakfire/db/uuid 35c2f5fc-8e92-4f84-ac75-fcd8fad67d25 System 3: cat /opt/pakfire/db/uuid 9b3e5eb8-aa9c-4c09-9929-24aa70e021da > Where is the "SSN" part of the hardware ID coming from? Like Adolf already said, it's the system's serial-number coming from the following DMI block: System Information Manufacturer: NF692 Product Name: NF692 Version: 1.0 Serial Number: SSN UUID: 3b903780-4f79-1018-816e-aeb2724778a7 Wake-up Type: Power Switch SKU Number: Default string Family: Default string
(In reply to ChrisK from comment #6) > (In reply to Michael Tremer from comment #4) > > > We do use the serial number of the root drive as well. > > Actually, I don not see any "serial number" string in the JSON, nor any > other lines in the code that collects hardware serial-numbers. We do not export it. The idea was, that fireinfo is using a static ID that does not change when a system is being re-installed. However, with vendors like Jetway, we cannot rely on those IDs. To not expose any of this data, we hash the IDs so that we have on unique string that always has the same length and is therefore easy to work with. > /etc/init.d/fireinfo uses uuidgen which, by default, generates a random UUID. > This ID is stored at /opt/pakfire/db/uuid which, for some reason, is not > used by "sendprofile" later. It is. If we cannot read any hardware information (for example on virtual machines), we use /opt/pakfire/db/uuid: https://git.ipfire.org/?p=oddments/fireinfo.git;a=blob;f=src/fireinfo/system.py;h=4c0b0a358734a473937e72ec62d11666914b1aa5;hb=HEAD#l274 If I would design this again, I would only use random UUIDs. > The IDs stored at /opt/pakfire/db/uuid are different on all my systems. Why > not using this as the base string for fireinfo's ID instead of the UUID > stored in the DMI profile? Because we would now change all IDs of all existing systems. And the downside of only using that file is that people clone systems which would then share the same ID. > > Where is the "SSN" part of the hardware ID coming from? > > Like Adolf already said, it's the system's serial-number coming from the > following DMI block: > > System Information > Manufacturer: NF692 > Product Name: NF692 > Version: 1.0 > Serial Number: SSN > UUID: 3b903780-4f79-1018-816e-aeb2724778a7 > Wake-up Type: Power Switch > SKU Number: Default string > Family: Default string LOL. I overlooked that. Sorry. Why do people even bother putting this garbage in there? Just put nothing. I will add those strings to the blacklist and so those systems should generate a new ID and hopefully work then. As things look, those systems will fall back to the pakfire UUID.
http://git.ipfire.org/?p=oddments/fireinfo.git;a=commit;h=33be9aa38d65dace9a61247f41ac3627a6750cce Author: Michael Tremer <michael.tremer@ipfire.org> system: Blacklist Jetway's product UUID Fixes: #12896 Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Could you guys please double-check these two patches: > https://git.ipfire.org/?p=oddments/fireinfo.git;a=commitdiff;h=33be9aa38d65dace9a61247f41ac3627a6750cce > https://git.ipfire.org/?p=oddments/fireinfo.git;a=commitdiff;h=09644b1fbc14d2fe76b9923c894fbbd4ad8f23b3
I patched system.py on my jetway system with the two patches and that gave me a different profile id but then got Error 404 oops, something went wrong when clicking the profile id link. I ran sendprofile --hardware-string on the command line and got the following error message sendprofile --hardware-string Traceback (most recent call last): File "/usr/bin/sendprofile", line 29, in <module> import fireinfo File "/usr/lib/python3.10/site-packages/fireinfo/__init__.py", line 23, in <module> from .system import System File "/usr/lib/python3.10/site-packages/fireinfo/system.py", line 277 continue ^^^^^^^^ So it doesn't appear to like the continue line but I am not familiar at all with python so have no idea what could be wrong.
(In reply to Adolf Belka from comment #10) > I patched system.py on my jetway system with the two patches and that gave > me a different profile id That statement was an error. The profile id was not changed on the fireinfo.cgi page.
I must have missed it the first time but there was an extra line in the error message from running the sendprofile command sendprofile --hardware-string Traceback (most recent call last): File "/usr/bin/sendprofile", line 29, in <module> import fireinfo File "/usr/lib/python3.10/site-packages/fireinfo/__init__.py", line 23, in <module> from .system import System File "/usr/lib/python3.10/site-packages/fireinfo/system.py", line 277 continue ^^^^^^^^ SyntaxError: 'continue' not properly in loop
Oops. Please try this: > https://git.ipfire.org/?p=oddments/fireinfo.git;a=commitdiff;h=4d74466456c0824663e10881f9deabcd1f4d32c3
That modification results in a working sendprofile command. sendprofile --hardware-string 022bf682-bda3-40a3-a57d-b4e95a4b36e9 and this is the value in /opt/pakfire/db/uuid However the profile id has not changed. That is still cb1c468b17369db11cde5b284d654c522703ea90 This is also the value listed in the scrollable box on the fireinfo.cgi page "profile_version": 0, "public_id": "cb1c468b17369db11cde5b284d654c522703ea90" If I run sendprofile --dump the public_id value shown is different. "profile_version": 0, "public_id": "452b59a7d8ee1b9a418e39e2a1170c8391153463" I searched in the IPFire code and realised that the public-ud and the profile are only updated after the fireinfo initscript is run so this either needs to be manually run or IPFire rebooted. I manually ran /etc/rc.d/init.d/fireinfo.start and my profile id has been updated to a new one. It now shows eacd45c214f799923afd53e6734086fbac3d4fa8 which should hopefully be different now from ChrisK's profile id.
(In reply to Adolf Belka from comment #14) > That modification results in a working sendprofile command. > > sendprofile --hardware-string > 022bf682-bda3-40a3-a57d-b4e95a4b36e9 > > and this is the value in /opt/pakfire/db/uuid Very good. Thanks for confirming. > I searched in the IPFire code and realised that the public-ud and the > profile are only updated after the fireinfo initscript is run so this either > needs to be manually run or IPFire rebooted. Yes, we generate the profile when we send it, but for showing on the web UI we do it once at boot time because it requires root permissions.
CCing Peter with request to merge this into c170.
(In reply to Adolf Belka from comment #14) > I manually ran /etc/rc.d/init.d/fireinfo.start and my profile id has been > updated to a new one. It now shows > eacd45c214f799923afd53e6734086fbac3d4fa8 > > which should hopefully be different now from ChrisK's profile id. It is indeed. Looks all good to me.
(In reply to Michael Tremer from comment #16) > CCing Peter with request to merge this into c170. https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=ac7f3c75aaa8077fe93e231f39b9e2ab96063076 https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=6dcfcc76ad3021f23877c48f95eeba27b88800d3 Ask and I shall deliver. :-)
https://blog.ipfire.org/post/ipfire-2-27-core-update-170-is-available-for-testing
Created attachment 1078 [details] attachment-3950126-0.html Sehr geehrte Damen und Herren, in der Zeit vom 29.07.2022 bis einschließlich 28.08.2022 bin ich nicht im Hause erreichbar. Bei Anliegen bezüglich der macio IT-Administration wenden Sie sich bitte an it-support@macio.de. Bitte beachten Sie, dass die Nachrichten nicht automatisch weitergeleitet werden. Vielen Dank. Mit freundlichen Grüßen Christian Keck Fon: +49 431 67072-0 Fax: +49 431 67072-29 Mail: it-support@macio.de<mailto:it-support@macio.de> macio GmbH - a cloudflight company | Kiel Am Kiel-Kanal 1 D-24106 Kiel www.macio.de<http://www.macio.de> macio | software engineering & user interface design Geschäftsführer: Alexander Friedel, Sven Schreier Amtsgericht Kiel, HRB 5832
https://blog.ipfire.org/post/ipfire-2-27-core-update-170-released