Boot URLs handed to nodes always carried an explicit :80 even when the HTTP
server listens on the default port. grub2.pm already omits the port when it is
80; make the xNBA, genesis and DHCP boot URLs consistent with it.
$portsuffix is empty when site.httpport is unset or 80 and ":<port>" otherwise,
so a non-default port is unchanged. Covers the ISC and Kea paths in dhcp.pm,
xnba.pm, mknb.pm, and the Kea xNBA client classes in BootPolicy.pm.
dhcp_boot_policy.t and mknb_xcatd_address.t follow the new URLs and gain cases
for a non-default and an unset port. The floating-address guard in
mknb_xcatd_address.t also drops :80 so that it keeps matching.
Recovered from the unmerged lenovobuild branch (cd61fd9d, a2f77ea9, 1035841b,
b7db0e2, 792fe6d).
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
Running rspconfig against an mgt=ipmi node with no option fell through to the
generic "Unsupported command: rspconfig " message (with an empty option),
which does not tell the user what is wrong. Detect the empty option in
preprocess_request and report that options are required.
Recovered from the unmerged lenovobuild branch (original 08ae94bd).
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
nodestat -f runs fping to reach the nodes; if the fping package is not
installed the pipe yielded no output and nodestat silently returned an empty
result. Check that an fping binary exists before running it and emit an
explicit "must install fping" error otherwise.
Recovered from the unmerged lenovobuild branch (original f0c88182), reworked
to test for the binary directly: the original inferred fping's presence from
whether the pipe produced output, which false-positived (reporting fping
missing) when fping was present but every node was unresolvable -- caught in
lab validation.
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
The FRU key sort used only `$a <=> $b`, a numeric comparison that returns 0
for the non-numeric FRU field names, leaving them in hash-iteration order.
That order is randomized per process, so `rinv <node> all` printed its fields
in a different order on each run. Add `$a cmp $b` as a tiebreaker so the
output is stable.
Recovered from the unmerged lenovobuild branch (original 9cd3fac6).
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
noderes.netboot is parsed as grub2-<protocol> and validated with
/^http|tftp$/, which reads as (^http)|(tftp$) and so also accepts values
such as https, httpx and xtftp.
A value that passes but is not exactly "http" then falls through to
set root=$grub2protocol,$serverip, which drops site.httpport, so the mistake
surfaces as a confusing grub2 failure at boot instead of the "Invalid netboot
method" error this check exists to give. grub2-https cannot work in any case,
since only "insmod http" is emitted.
Supported values are unchanged: grub2, grub2-http and grub2-tftp.
nodeset aborted with "Unable to find pxelinux.0 from syslinux" when neither
the copy under the tftp directory nor the one under XCATROOT existed. Only
legacy BIOS clients chain pxelinux and not every distribution still ships
syslinux, so a UEFI-only environment could not run nodeset at all.
Copy pxelinux.0 when it is available and warn, rather than fail, when it is not.
Recovered from the unmerged lenovobuild branch (4f0a5106), which skipped
silently; warn so the missing loader is still reported.
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
blade.pm's preprocess_request iterates the mp table during 'findme' discovery.
Because many node types populate the mp table, non-blade nodes were being
scanned as if they were BladeCenter/Flex blades. Skip a node during findme
unless its nodetype is 'blade'.
Scoped to blade.pm's findme path and gated on nodetype, so only blade discovery
is affected; the existing whole-request findme handling (already-processed
short-circuit) is a separate check and is unchanged.
Not lab-validated (no BladeCenter/Flex MPA available).
Recovered from the unmerged lenovobuild branch (6573d8f9).
reseat_node opens an IPMI session to the FPC/CMM to reseat a node. The FPC
needs packets sent without maxpending flow-control, but that state is only held
transiently. Add a persistent per-session 'neverwait' flag, set it on the FPC
reseat session, and honor it in sendpayload.
The flag defaults off, so it is a no-op for every other IPMI session; only the
FPC reseat path opts in. (The lenovobuild original also reworked the shared
login/admin_level_set nowait handling; that part is left out to avoid changing
flow-control for all BMCs.)
Not lab-validated (no NeXtScale FPC/CMM available).
Recovered from the unmerged lenovobuild branch (eda85df3, neverwait hunks only).
UEFI ESXi netboot needs esxboot-x64.efi under /xcat. When it was not
already staged, mkcommonboot left it missing; copy it from the install media's
efi/boot/bootx64.efi if that exists and the target does not.
Additive and ESXi-only (esx.pm mkcommonboot): it only copies when the target is
absent and the source is present. The original commit also dropped a
"bootmode ne install" guard whose own comment warns the installer croaks; that
hunk is intentionally left out.
Not lab-validated (no ESXi provisioning environment available).
Recovered from the unmerged lenovobuild branch (6931200d, esxboot hunk only).
The energy-manager (IEM) command handler treated response code 0xcb as the
'not present / not supported' signal. Some BMCs return 0xc1 for the same
condition, which was left unhandled. Accept 0xc1 as well.
Recovered from the unmerged lenovobuild branch (06d7097).
The rinv firmware-inventory path detects a Lenovo IMM by matching the firmware
build-ID prefix (yuoo, 1aoo, tcoo). Some IMM firmware families report a tei, cdi
or psi prefix and were therefore not recognized as an IMM. Add them.
Recovered from the unmerged lenovobuild branch (e50cf37, 201b2de).
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
ddns.pm's DNS-update send has a 3-try retry loop, but it only retried on
NOTAUTH and -- on the final attempt -- the `next` fell out of the loop without
reporting failure. makedns then printed "Completed updating DNS records." and
"DNS setup is completed" even when the update was never accepted.
Two problems this causes:
- SERVFAIL was never retried. named routinely replies SERVFAIL transiently
right after a zone (re)load, before the zone is ready to accept dynamic
updates; the update succeeds a second or two later. This reliably breaks real
flat-cluster provisioning on el9/el10, where the test case's makedns -n runs
right after named reloads the zone with the new compute node.
- A persistent NOTAUTH/SERVFAIL (retries exhausted) was silently swallowed and
reported as success, so a genuinely failed DNS update looked like it worked.
Extract the batch send into send_ddns_update(), which retries NOTAUTH and
SERVFAIL (pausing on SERVFAIL), returns 0 only on NOERROR, and otherwise emits
the error and returns 1. Both batch-send sites now `return 1 if
send_ddns_update(...)`, so a real failure aborts add_or_delete_records instead
of falsely reporting success.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
Modern x86-64 UEFI firmware (including OVMF and recent iPXE) reports DHCP
client architecture 00:07, but the xNBA network-boot conditionals only matched
00:09. A UEFI node would load xnba.efi, re-request with user-class xNBA and
arch 00:07, fail to match, and be handed xnba.efi again -- an endless boot
loop. Accept 00:07 alongside 00:09 in the xNBA UEFI branches of both the
network-level (addnet) and node-level (addnode) dhcpd statements.
Validated on an OVMF UEFI client: it progresses from xnba.efi to the .uefi
genesis config and boots, instead of looping on xnba.efi.
Recovered from the unmerged lenovobuild branch (5d697b5c, 86b0e12e).
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
The DNS-managed-networks check used my_ip_facing($net->{net}), which only
returns local addresses on the interface directly facing that network. A
nameserver that is a local address reachable via a different (routed)
interface was therefore treated as external, and the network was wrongly
dropped from ddns management.
Use thishostisnot(), which recognizes any local address regardless of the
interface, and keep the existing <xcatmaster> and site-nameserver special
cases.
Recovered from the unmerged lenovobuild branch (original 3c343f83), adapted
to preserve those special cases: lab validation showed the original replaced
them wholesale, which would exclude any network whose nameserver is the
literal <xcatmaster> token (thishostisnot('<xcatmaster>') is true).
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
nodech's ^= operator removed only a single literal value, so
"nodech n1 groups^=a,b" tried to strip the combined string "a,b" and left the
individual groups in place. Split the value on commas and remove each piece.
Recovered from the unmerged lenovobuild branch (original 95c78b33).
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
nodech's ,= operator appended the whole right-hand side as one value, so
"nodech n1 groups,=a,b" added the literal "a,b" and its duplicate check only
compared against that combined string. Split the value on commas and add each
piece individually, skipping any already present.
Recovered from the unmerged lenovobuild branch (original 086b0c0d).
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
`ip -6 route` output for ECMP/multipath routes carries `nexthop` continuation
lines, and a `default` route has no network prefix. donets() treated both as
networks and added bogus entries to the networks table. Skip them alongside
the existing link-local/unreachable/via/lo filtering.
Recovered from the unmerged lenovobuild branch (original 7094ba0c).
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
donets() only skips the exact address 'fe80::/64' when scanning routes, so a
link-local route with any other prefix (e.g. a longer fe80:: subnet) is added
to the networks table as a bogus network. Match any fe80:: prefix instead of
the single literal value.
Recovered from the unmerged lenovobuild branch (original 8b79cf85).
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
The BIOS (pcfg) boot config writes the kernel BOOTIF as `${netX/machyp}`, a
legacy gPXE spelling, while the UEFI (ucfg) config for the same node already
uses the iPXE-native `${netX/mac:hexhyp}`. xNBA is built from iPXE, whose
documented format is `mac:hexhyp`.
This is a consistency / standards-compliance alignment, not a fix for broken
behaviour: the shipped xNBA still honours the old `machyp` alias -- confirmed
by a real legacy-BIOS PXE boot, which came up fine with the stock spelling.
The change brings the BIOS path in line with the UEFI path and the documented
iPXE syntax, so both paths use one form and neither relies on a deprecated
gPXE alias.
Validated on a throwaway EL9 xCAT cluster: a legacy-BIOS client PXE-booted
with the patched config and genesis came up.
Recovered from the unmerged lenovobuild branch (original 85ce5b7e).
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
getzonesfornet() derives the number of reverse-zone nibbles as
$nibbs = $maskbits / 4, then decrements it once per hex nibble of the network
prefix. For a sub-nibble (not 4-bit-aligned) IPv6 mask $nibbs can go negative
before the padding loop, and `while ($nibbs)` then never terminates: it keeps
decrementing past zero while appending "0." to $rev, spinning forever and
growing the string until the process is killed.
Make the padding loop `while ($nibbs > 0)` so it can never run away, and
return early only when $nibbs is genuinely negative. $nibbs == 0 is the normal
nibble-aligned case (e.g. a /64) and must still emit its reverse zone.
Recovered from the unmerged lenovobuild branch (original 0e070cd2). The
original guarded with `$nibbs < 1`, which also dropped the valid $nibbs == 0
case and left standard /64 subnets with no reverse zone; corrected to
`$nibbs < 0` after lab validation on a real provisioning cluster.
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
mknb writes the compressed genesis filesystem by streaming cpio output
straight onto the final path in $tftpdir/xcat (genesis.fs.$arch.lzma or .gz).
When two mknb/nodeset runs target a shared $tftpdir at once, one run reads or
overwrites the other's half-written image, producing a corrupt genesis.fs and
failed netboots.
Write each image to a uniquely-suffixed temporary file
(xCAT::Utils::genpassword(24)) and File::Copy::move() it into place. move()
within the same directory is a rename, so the final path only ever appears
complete. Both modules are already imported by mknb.pm.
Recovered from the unmerged lenovobuild branch (originals c651e7b8 and its
fix da0723f2, which switched the suffix to genpassword after the first
attempt only produced a single character). master lacks the branch's xz
path, so only the lzma and gzip paths are adjusted here.
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
Daniel Hilst
Vinícius Ferrão
Vinícius Ferrão