Extracts the three command-log response subs and drives them. It checks the
request classification, the redaction of a bare passwd value, a secret split
across callbacks in either order, the password-content fallback, that a benign
response is kept, and that the finalizer preserves an earlier command's response
on a shared connection. It fails hard if a sub cannot be extracted.
The test runs the real NodeRange code. It sends a ^ range that a
two-argument open would run as a command and checks the command does not
run. It also reads a real comment-only file to show the operator still
works.
The command assertion fails against the previous behavior.
build-ubunturepo guarded builds with a single host-global, fail-fast lock at
/var/lock/xcatbld.lock (`flock -n`). Two builds on one host -- e.g. the devel and
stable Ubuntu CD lanes on xcat-master-ub -- therefore collided on that one lock and
the loser exited 1 with "Can't get lock ...", failing the whole pipeline, even though
each lane builds from its own checkout into its own DEST and they share nothing.
build-ubunturepo builds its packages in-place in its own source checkout (it rewrites
debian/changelog and debian/control, drops *.orig.tar.gz at the checkout root and runs
dpkg-buildpackage inside the package dirs), so the resource two concurrent builds
actually contend for is the checkout, not the host. Key the lock on the checkout path
($curdir): builds of the SAME checkout still fail-fast (they would corrupt each other
in-place), while builds of DISTINCT checkouts get distinct locks and run in parallel.
The lock file stays on the local /var/lock (reliable flock, unlike the NFS/virtiofs
checkout) and the source tree is left byte-pristine.
Add xCAT-test/unit/build_ubunturepo_lock.t, which extracts the lock block from the
script verbatim and asserts: the lock path is /var/lock/xcatbld-<hash-of-checkout>.lock
and deterministic per checkout; a second build of the same checkout fails fast; two
distinct checkouts acquire their locks concurrently.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
Run redact_password rather than inspecting its source, so that a secret which
survives is a failure here rather than something the shape of the code hides.
Each supported way of writing an assignment is exercised, including the table
qualified form and spaces around the equals sign, together with the positional
flag that the per-command table handles.
The expected set is derived from Schema.pm rather than repeated, so an attribute
added there with a secret column fails this test instead of quietly reaching the
logs, and the test bails if that mapping cannot be parsed so it cannot pass
vacuously. Detail that is not secret is asserted to survive, since redacting it
would cost the log its usefulness without protecting anything.
Add a regression case to dhcp_kea_plugin_intent.t for a node whose mac
table entry uses the *NOIP* sentinel on a secondary NIC
("mac1|mac2!*NOIP*"). The mocked getipaddr resolves every name (including
the literal *NOIP*), so the only thing that can keep the node to a single
reservation is an explicit *NOIP* skip in kea_node_reservations() and
kea_node_reservations6(). The test asserts exactly one v4 and one v6
reservation, for the real NIC, with no reservation carrying *NOIP* as a
hostname -- covering both the "bogus second reservation" and the
"unresolved reservation aborts makedhcp" failure modes.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
merge_core_repos already assembles the multi-arch core and runs the full
finalize tail (index -> sign -> final metadata -> write_release_alias, in the
required order so the xCAT-release-latest alias lands AFTER metadata and stays
out of the repo index). The preceding commit restored a separate finalize_core
sub purely to satisfy xcat_release_package.t, which grepped for
'sub finalize_core { ... $dir ... }'. That left two overlapping entry points:
--finalize-core (finalize one pre-assembled dir) and --merge-core-repos
(assemble N per-arch dirs THEN finalize) -- the former a strict subset of the
latter, with no in-tree or CI caller.
Consolidate on the single assemble+finalize path: inline the finalize tail into
merge_core_repos, drop sub finalize_core and the --finalize-core getopt/dispatch,
and update xcat_release_package.t to assert the stable alias is created after the
final metadata pass inside merge_core_repos ($out). Behaviour is unchanged (merge
already wrote the alias); only the redundant finalize_core interface is removed.
xcat_release_package.t 26/26; perl -c clean.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
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>
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.
wait_for_provision caps how long retry_install polls for a node to reach
'booted' after each rinstall. Measured healthy provisions in devel-cd #22 boot
well inside this window (diskless ~6-8 min, diskfull ~8-16 min), so 30 min was
mostly slack that only lengthened the give-up time on a genuinely failing node.
Drop it to 20 min: still above the ~16-min diskfull install, while shrinking each
failed attempt's cost (6 min fixed sleep + 20 poll = 26 min vs 36). Combined with
the 3->2 attempt default, a fully-failing case's retry stack drops substantially.
Trade-off noted: the margin over a slow-under-load diskfull install is now tighter.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
retry_install.sh retries a node provision $times (default 3) x 30 min. The flat
diskless/diskfull cases each call it multiple times, so when a node genuinely
fails to come up the retries stack to ~3.5-4 h per case (measured: a single
contention-flaked el8-x86 diskless burned 14181s in devel-cd #22), which both
balloons the CD wall-clock and delays the red verdict.
Two attempts still absorbs a one-off transient (a single slow/failed netboot)
while halving the worst-case retry time (3->2 tries per call). Callers that pass
an explicit count (e.g. the negative-provision check that passes 1) are
unaffected -- only the default changes.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
Vinícius Ferrão
Daniel Hilst
Vinícius Ferrão