Two small robustness fixes for bmcsetup:
- After changing the BMC network port on IBM boards (IPMIMFG 2), the BMC LAN
configuration was not yet ready; add a 15s settle before continuing. Gated
inside the IBM branch, so no other vendor is affected.
- Set a password longer than 16 characters using ipmitool's 20-byte form, but
only when the password actually exceeds 16 chars, so a BMC that supports only
16-byte passwords is never asked for a length it cannot store.
Recovered from the unmerged lenovobuild branch (949532f3, 78fa7758; the password
change adapted to use the 20-byte form only for long passwords).
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
Intel Walker Pass (S9200WK) boards in dedicated-LAN mode use IPMI channel 3;
the auto-detect loop does not find it. Set the channel explicitly for these
boards, gated on IPMIMFG=343 && XPROD=149, and extend the existing S2600BP
channel-setaccess (343/124) to cover 149 as well.
Gated on the Intel manufacturer/product IDs, so no other BMC is affected.
Not lab-validated (no Walker Pass hardware available).
Recovered from the unmerged lenovobuild branch (2357c298).
The original Lenovo SR635/SR655 (IPMI manufacturer 19046, product 1287) use an
AMI "TSM" BMC reached over a LAN-over-USB interface, which needs OEM raw commands
to bring the interface up, select the LAN channel, and restart TSM networking
once configured. Add a dedicated vendor branch for it -- gated on the same
IPMIMFG/XPROD check the script already uses for IBM, Dell, Supermicro, OpenPOWER
and other Lenovo machines -- plus a udev rule and helper that bring up the USB
NIC (169.254.0.120) so in-band ipmitool can reach the TSM. The user-slot
auto-scan is skipped for these machines, which use a fixed slot.
Everything is behind IPMIMFG=19046 && XPROD=1287 (or the 046b:ffb0 USB device),
so no other BMC is affected.
Recovered from the unmerged lenovobuild branch (922dfe18, 42357f9d, 02da8a6b,
765e2ad3, 408cf2b3), adapted to master's bmcsetup structure. The global MD5 LAN
auth removal that rode along in 42357f9d is intentionally left out -- SR635/SR655
IPMI authentication is already handled in master by #7586 (retry cipher suite 3
on a zero RAKP2 HMAC), so dropping MD5 for all BMCs is neither needed nor wanted
here.
Not lab-validated: this targets the original SR635/SR655 (product 1287); no such
machine was available to test (an SR635 V3 reports product 1601 and uses a
different, directly-reachable BMC). The code is gated so it cannot affect other
hardware.
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
bmcsetup unconditionally re-set the BMC IP source, address, netmask, gateway
and VLAN on every run. On a re-run or re-discovery where the BMC is already
configured, that re-applies settings needlessly and can briefly churn the BMC
network. Read the current value first and only issue the set when it differs;
the VLAN check maps an "off" target to the "Disabled" the BMC reports.
Validated read-only on a Lenovo ThinkSystem SR635 (MegaRAC BMC): the address
and VLAN guards evaluate to skip when the target matches the current value.
Recovered from the unmerged lenovobuild branch (fd194005); the RD350-specific
snooze and manufacturer-ID hunks are omitted as master's vendor handling has
since diverged.
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
bmcsetup iterated every user slot and retried ipmitool user disable for slots that were already disabled. Lenovo XCC reports those attempts as Invalid data field in request, so discovery can spend minutes retrying no-op disables.
Read the current user table once per BMC, keep the old fallback when the table cannot be read, and disable only non-target slots whose IPMI Msg flag is true. Also use the loop's current username when resolving the target slot and keep the intended userslot 2 fallback assignment.
Fixesxcat2/xcat-core#5065
Add optional values to ipmi.bmcport to support more fine-grained
configuration for Dell servers, and mirror the `ipmitool delloem`
capabilities:
lan set <Mode>
sets the NIC Selection Mode :
dedicated, shared with lom<idx>
lan set <Shared Failover Mode>
sets the shared Failover Mode :
shared with failover lom<idx>
shared with failover all loms,
shared with failover none.
This patch introduces the possibility to provide 3 (space-separated)
values for ipmi.bmcport:
1st value: 0 = shared / 1 = dedicated
2nd value shared LOM (1-4) (0 or no value means first available LOM)
3rd value: failover LOM (1-4) (0 means no failover, no value means all LOMs)
To ensure maximum compatibility with the default 0/1 shared/dedicated
scheme, the 2nd and 3rd values are optional, and will retain the
previous behavior when not specified.
Examples:
ipmi.bmcport value BMC interface configuration
0 Shared with first available interface, failover with
all LOMs (catch-all mode)
0 1 Shared with LOM1, failover all LOMs
0 1 2 Shared with LOM1, failover LOM2
0 2 0 Shared with LOM2, no failover
1 Dedicated
* bmcsetup: revert previous meaning of bmcport for Dell servers, to
conform with other server types: 0=shared, 1=dedicated
* bmcsetup: remove dependency on `ipmitool delloem` and use raw cmds instead
ipmitool delloem may not work on all Dell server generations,
functionnality depends on ipmitool versions (see
https://github.com/ipmitool/ipmitool/issues/18).
So removing thatdependency and using raw IPMI commands seems more robust.
Don't check $LOCKEDUSERS at all, instead fall back to userslot 2 as a last resort if the user doesn't already exist, and the automatic slot detection doesn't find an unlocked slot. This is essentially what was happening in the older version of the script before #6380 as $LOCKEDUSERS was only ever referenced here.
Also move setting the username before setting privileges and access levels, as those steps fail if done before username is set for the slot.
Instead of relying on hard coded offsets, query each slot's status with ```ipmitool channel getaccess``` and use the first slot that is unlocked.
This fixes an issue on certain Cray x86 nodes that have arbitrary locked IPMI user slots.
RH7/Centos7 and recent versions of fedora relocate `/*bin/*` into `/usr/*bin/`. This causes
conflicts for upgrades against xCAT-genesis-scripts-* packages which expect the `/bin` a to be
a directory while `xCAT-genesis-base-*` packages provide a link. Relocating all files into `/usr`
fixes that conflict and allows a clean upgrade from all old versions.
Daniel Hilst
Vinícius Ferrão
Kilian Cavalotti
Kilian Cavalotti
besawn
Obihörnchen
adorsey-NOAA
Mark Gurevich
GONG Jie
Samveen Gulati