Specifying the test number manually is tedious and prone to errors (as
recently proven). Since we have all the necessary data to work out the
test number, let's do it automagically.
We should test both serialization and deserialization works properly.
But the serialization/deserialization code is deeply entwined with the
manager state, and I think quite a bit of refactoring will be required before
this is possible. But let's at least add this simple test for now.
After 4b30f2e135, reading stable_secret
sysctl property fails with -ENOMEM, instead of -EIO.
This is due to read_full_virtual_file() uses read() as the backend while
read_one_line_file() uses fgetc(). And each functions return different
error on fails.
Anyway, the failure is harmless here. So, the log message and comment is
updated.
Closes one of the issues in #19410.
Previously, we'd generally attempt the operation first, without any
passwords, and only query for a password if that operation then fails
and asks for one. This is done to improve compatibility with
password-less authentication schemes, such as security tokens and
similar.
This patch modifies this slightly: if a password can be acquired cheaply
via the keyring password cache, the $CREDENTIALS_PATH credential store,
or the $PASSWORD/$PIN environment variables, acquire it *before* issuing
the first requested.
This should save us a pointless roundtrip, and should never hurt.
We want to use the result in a shell pipeline hence use -P mode (pipe
mode) instead of -t mode (interactive tty mode) for systemd-run.
This shouldn't change much about the test, but is slightly more correct
(and quicker).
We have to invoke the tests as superuser, and not being able to read
the journal as the invoking user is annoying. I don't think there are
any security considerations here, since the invoking user can already
put arbitrary code in the Makefile and test scripts which get executed
with root privileges.
Let's enable this in all tools that intend to write to the OS images.
It's not conditionalized for now, as there already is conditionalization
in the existance or absence of the flag in the GPT partition table (and
it's opt-in), hence it should be OK to just enable this by default for
now if the flag is set.
systemd-repart can grow partitions dynamically at boot, but it won't
grow the file systems inside them. In /etc/fstab you can request that
via x-systemd.growfs. So far we didn't have a nice scheme for images
with GPT auto-discovery however, and that meant in particular in tools
such as systemd-nspawn the file systems couldn't be grown automatically.
Let's address this: let's define a new GPT partition flag that can be
set for our partition types. If set it indicates that the file system
should be grown to the partition size on mount.
This commit adds the flag and adds code to discover it when dissecting
images. There's no code yet to actually do something about it.
Let's rename MountpointsFlags → MountPointFlags. In most of our codebase
we name things mount_point/MountPoint rather than mountpoint/Mountpoint,
do so here too.
Also, prefix the enum values with "MOUNT_". The fact the enum values
weren#t prefixed was pretty unique in our codebase, and pretty
surprising. Let's fix that.
This is just refactoring, no actual change in behaviour
The logic to query test state was rather complex. I don't quite grok the point
of ret=$((ret+1))… But afaics, the precise result was always ignored by the
caller anyway.
We would remove stuff only if successful, so repeated invocations would
trivially fail.
Also drop "-f", so that if we expect to remove something, it must be there.
oomd works way better with swap, so let's make the test less flaky by
configuring a swap device for it. This also allows us to drop the ugly
`cat`s from the load-generating script.
I found myself often looking for a quick way to determine "the local IP
address", and then being lost in the "ip addr" output to find for the
right one to use. This is supposed to help a bit with that. Let's
introduce a new special hostname "_outbound" with semantics similar to
"_gateway" that resolves to addresses that are the closest I could come
up with that maps to "the" local IP address.
This adds a small helper, similar in style to local_addresses() and
local_gateways() that determines the local "outbound" addresses.
What's an "outbound" address supposed to be? The local IP addresses that
are the most likely used for outbound communication. It's determined
by using connect() towards the default gws on an UDP socket, and then
reading the address of the socket this caused it to be bound to.
This is not the "public" or "external" IP address of the local system,
and is not supposed to be. It's just the local IP addresses that are
likely the ones going to be used by the local IP stack for
communication with other hosts.
Frantisek Sumsal
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Luca Boccassi
Lennart Poettering
jiangchuangang