The 47 test files under xCAT-test/unit/ were shipped but almost never
executed on a pull request. Only three hand-written xcattest cases
reached them -- dhcp_unit, ipmi_unit and xcatprobe_unit -- and each
proved a single glob against the installed copy, so the majority of the
suite had never run at all. Real drift went unnoticed as a result:
ubuntu_subiquity_template.t still asserted the pre-86e77bcd7 shape of
compute.subiquity.tmpl and failed against the current template.
Run `prove xCAT-test/unit/*.t` directly from github_action_xcat_test.pl.
The tests resolve xCAT modules and fixture files relative to the repo
root through FindBin, so they must be proved from the checkout and not
from /opt/xcat/share/xcat/tools/autotest/unit; install_xcat() chdir's
away, hence the getcwd() captured up front. The step runs after the
install because the suite needs the perl dependencies xCAT pulls in
(Net::DNS, XML::Simple) and a usable xCAT database.
Drop the three prove testcases so their tests do not run twice, and
refresh the two stale ubuntu_subiquity_template.t assertions: the
identity section is now intentional (86e77bcd7) and the MAC
normalization gained cut filters ahead of the tr (c6e38483f), which the
loosened regex plus a new assertion for the suffix stripping now cover.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
(cherry picked from commit a0d2322b71)
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>
(cherry picked from commit f0a879491d)
formatNetmask() uses its first argument immediately (inet_aton($mask),
2**$mask, hex $mask) with no check that it is defined. Callers that pass an
undefined mask trigger "Use of uninitialized value" warnings and a
meaningless result instead of a clean failure.
Return undef up front when $mask is not defined.
Recovered from the unmerged lenovobuild branch (original acbbeb86).
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
(cherry picked from commit 2d294ae8f7)
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>
(cherry picked from commit 6da5efd29a)
When nodehm.conserver is a hostname, rcons compared that name directly against
the management node's local IP addresses, so the "conserver is this host"
check never matched and rcons connected via `-s` (a remote confluent session)
even when the conserver was the local host. Resolve the name to an address
with getent first so the comparison works.
Recovered from the unmerged lenovobuild branch (original faa767e5).
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
(cherry picked from commit bdf8ec36db)
tcons opens an rcons console per node in a tiled tmux session. On tmux 3.x
(shipped by all currently supported platforms) it no longer works:
* The session was named "tcons.$$". Modern tmux treats "." as the
session:window.pane target separator, so "tmux attach -t tcons.$$" is
parsed as session "tcons", pane "$$" and fails with "can't find
session"/"can't find pane" -- tcons cannot attach to the session it
just created. Rename it to "tcons_$$".
* The per-node "tmux select-pane", "tmux split" and "tmux select-layout"
commands had no target. When tcons is run from inside an existing tmux
session (the common case) they act on the caller's current session
instead of the detached tcons session, splitting the operator's own
window. Target every command explicitly at the tcons session.
* Move the pane-border-status option inside the loop so the console title
is set on each pane as it is created.
Validated on tmux next-3.4: the reworked script builds a 3-pane tiled
session with no errors, whereas the previous version's dotted session name
is unaddressable ("can't find pane").
Recovered from the unmerged lenovobuild branch (originals 5107b6ba1,
cefefa7d1, 6c72a2707, e040d24bb).
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
(cherry picked from commit dda7605028)
replaycons chose the confluent console log directory
(/var/log/confluent/consoles) whenever the confetty binary happened to be
present. On a host that has confluent installed but runs conserver as the
active console service, that directory is empty and replaycons could not find
the log. Gate on the site table's consoleservice attribute instead -- the
same setting rcons uses -- so replaycons reads /var/log/confluent/consoles
only when confluent is actually the configured console service.
Recovered from the unmerged lenovobuild branch (originals 3ce4d81b3, 57f6ddd38).
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
(cherry picked from commit 21da014ed7)
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>
(cherry picked from commit 60bd6e7cd9)
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>
(cherry picked from commit a0dfc3343a)
For each secondary NIC in NICSTOBRINGUP, doxcat backgrounds a loop that polls
`ethtool $nic` until the link reports "detected: yes" before running dhclient.
A NIC that is never connected keeps that loop (and its `sleep 5`) running for
the life of the genesis environment, leaking background shells and needlessly
churning.
Add a second exit condition so each loop also stops once /tmp/netinitted
exists, and touch that file once the boot NIC has completed network init. A
link that never appears no longer waits indefinitely.
Recovered from the unmerged lenovobuild branch (original 9ece12e4).
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
(cherry picked from commit f24457cddf)
The genesis boot script sleeps 20 seconds unconditionally with the comment
"wait for NIC initialization", but that wait exists solely for System P LE
(ppc64) hardware discovery -- the surrounding section is explicitly ppc64
only. Every x86_64 and aarch64 node therefore pays a needless 20s delay on
each genesis boot.
Move the sleep inside the `[[ ${ARCH} =~ ppc64 ]]` block so only ppc64 waits.
Applied to the base script and both dracut_105 (el, ubuntu) variants.
Recovered from the unmerged lenovobuild branch (original d0916d9d).
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
(cherry picked from commit 32149f10f4)
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>
(cherry picked from commit 9dd025bf05)
Daniel Hilst
xcat2-backport-automation[bot]
Vinícius Ferrão
Vinícius Ferrão