Incorrect detection of architecture 32/64 bits (breaking change)
We are not correctly detecting node architecture. What we really report on today is the architecture used to build the perl in the agent - and it is just by luck if most of the time, that match to architecture of the node.
So we need to change the way we get arch and report on it. We also need to normalise the result to make usable in group search.
We are going to use https://stackoverflow.com/questions/15036909/clang-how-to-list-supported-target-architectures as reference names.
Fusion provides // we change to:
- amd64 => x86_64
- PowerPC if OS == AIX => ppc64
- PowerPC (other cases) => ppc
- 64-bit / 32-bit (windows) => x86_64 / x86
- things with x86_64 / x86 / ix86 in their name => x86_64 / x86 / ix86
- IA-64, i[3-9]86, x86, x86_64, arm.*, other => same name in lower case
For reference, the trigger was:
An Ubuntu 14.04 32 bits is displayed as
"Operating System Architecture Description: x86_64-linux-thread-multi"
in the web interface
Processor architecture is correctly detected as i386 thought
Attached, the inventory
The command arch returns what is expected
# arch i686
#1 Updated by Nicolas CHARLES 12 months ago
- Severity set to Major - prevents use of part of Rudder | no simple workaround
tag ARCHNAME is filed by output of command
the system perl returns
# perl -V:archname archname='i686-linux-gnu-thread-multi-64int';
our perl is
# /opt/rudder/bin/perl -V:archname archname='x86_64-linux-thread-multi';
So (at least on debian like) we are misdetecting 32 and 64 bits
This is more problematic than just display error, as this info is used by FusionInventory to select which perl module to run for inventory
#2 Updated by Nicolas CHARLES 12 months ago
- Severity deleted (
Major - prevents use of part of Rudder | no simple workaround)
# file /opt/rudder/bin/perl /opt/rudder/bin/perl: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=51e76f93b4baac55d41edfa7368ccf71c98e4b59, stripped
#4 Updated by François ARMAND 11 months ago
Some more information:
In some (but not all, and for now we don't know exactly on which), the Fusion reports contains both:
<HARDWARE> <ARCHNAME>x86_64-linux-thread-multi</ARCHNAME> ... </HARDWARE>
<OPERATINGSYSTEM> <ARCH>i686</ARCH> ... </OPERATINGSYSTEM>
So we could use the second one, which is what we need / want.
There is still three things to take care of in that case:
- 1/ we need to be sure that all supported agent version have a fusion that fill that ARCH attribute
- 2/ we need to be sure to correctly migrate existing groups using "ARCH" (with the case of API, and certainly a compatibility option to add for them)
- 3/ that does not solve the problem that Fusion is not using the correct information for its own internal decision making.
#6 Updated by François ARMAND 11 months ago
So, after some more research:
- linux has the ARCH field at least since rudder 2.11, with the correct content (i686, x86_64)
- windows get 32-bits, 64-bits
- AIX does not have the field at all
- rasperry get the expected content ("armv7l")
So, I propose to just use the new field, with ppc64, i686, x86_64, etc. If the field ARCH is not present, try to infer the correct content from OS or HARDWARE/ARCHNAME.
The group search is a free input field, so nothing to change here.
We will need to make a breaking change annoucement in the release note for 4.1.
We will also need to look for "aix-thread-mutli, armv7l-linux-thread-multi, MSWin32-x64-multi-thread, (well, anything not looking like ".x64.*") and try to migrate it and make a big warning in logs.
#11 Updated by François ARMAND 11 months ago
- Status changed from In progress to Pending technical review
- Assignee changed from François ARMAND to Vincent MEMBRÉ
- Pull Request set to https://github.com/Normation/ldap-inventory/pull/123
#13 Updated by François ARMAND 11 months ago
- Status changed from Pending technical review to Pending release
Applied in changeset ldap-inventory|3f50c5589b394d894b6f93baa4af5b6d2151c183.
#15 Updated by Vincent MEMBRÉ 10 months ago
- Status changed from Pending release to Released
- Priority changed from 67 to 66
This bug has been fixed in Rudder 4.1.10 and 4.2.4 which were released today.
- 4.1.10: Announce Changelog
- 4.2.4: Announce Changelog
- Download: https://www.rudder-project.org/site/get-rudder/downloads/