Use the relay DHCP agent information as basis for
subnet comparison instead of self, when present.
Use the candidate prefix length verbatim since the
relay will offer no hint as to the 'proper' prefix
length for the target segment.
Instead of overwriting the SSH public code for the node concatenate all
found SSH keys together in one file.
Signed-off-by: Adrian Reber <areber@redhat.com>
Utilities that expected /dev/pts will now be satisfied,
as a new /dev/pts is mounted.
Further, systemd added a check in various utilities that
was fouled by the previous method of appearing to have a
root filesystem.
Before, after chroot, we would bind mount / to itself, and this
made things using /proc/mounts, /proc/self/mountinfo, df, mount,
etc happy that there is a real looking root filesystem.
However, by doing it after the chroot, systemd could statx on '..' and
get a different mnt id than /. So it had to be done prior to the
chroot. However it also had to be done before other mounts as
bind mounting over it would block the submounts.
This more closely imitates the initramfs behavior, where '/' starts life
as a 'real' filesystem before being mounted up and switched into.
This behavior was made to imitate the 'start_root.c' behavior as that
seems to be more broadly successful.
If an asynchronous handler is slow to
enroll a target while another target causes an iteration
of the snoop loop, the various modified structures
had been discarded in the interim.
Now persist the data structures iteration to iteration,
using 'clear()' to empty them rather than getting
brand new data structures each loop.
For XCC3, change to generic redfish onboarding mechanism.
Extend the generic mechanism to be more specific in some
ways that the XCC3 is pickier about. However, it's just reiteration
of what should have already have been the case.
V4 Lenovo servers will have XCC3, and will have differences
and mark an unambiguously redfish capable onboarding process.
For now identify XCC3 variants and mark them, stubbing them
to the xcc handler.
An XCC3 handler will be made basing on the generic redfishbmc handler
with accomodations for XCC specific data (e.g. DeviceDescription
attributes and the Lenovo default user/password choice).
While stock OpenBmc does not care about subprotocols,
some implementations use it as a carrier for the XSRF-TOKEN.
Since base OpenBmc ignores it, we just offer it to any implementation
just in case.
Provide mechanism for administrator to place a custom
key for potential interactive recovery into
/var/lib/confluent/private/os/<profile>/pending/luks.key
If not provided, generate a unique one for each install.
Either way, persist the key in /etc/confluent/luks.key, to
facilitate later resealing if the user wants (clevis nor systemd
prior to 256 supports unlock via TPM2, so keyfile is required
for now).
Migrating to otherwise escrowed passphrases and/or sealing to
specific TPMs will be left to operators and/or third parties.
