IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
glibc now has Suggests:glibc-minimal-langpack, so we don't
need to mention it ourselves.
--repo=… is a nicer alternative to --disablerepo=* --enablerepo=….
It also avoids the issue with quoting.
Let's exclude weak deps, but install systemd-networkd, so the container
can configure networking if necessary.
This is supposed to be used by package/image builders such as mkosi to
speed up building, since it allows us to suppress sync() inside a
container.
This does what Debian's eatmydata tool does, but for a container, and
via seccomp (instead of LD_PRELOAD).
systemd-socket-activate has supported such a mode since
5e65c93a43. '--setenv=FOO=$FOO' is a fairly
common use in scripts, and it's nicer to do this automatically without worrying
about quoting and whatnot.
https://github.com/systemd/mkosi/pull/765 added the same to 'mkosi --environment='.
Explicitly document the behavior introduced in #7437: when picking a new
UID shift base with "-U", a hash of the machine name will be tried
before falling back to fully random UID base candidates.
The old code was only able to pass the value 0 for the inheritable
and ambient capability set when a non-root user was specified.
However, sometimes it is useful to run a program in its own container
with a user specification and some capabilities set. This is needed
when the capabilities cannot be provided by file capabilities (because
the file system is mounted with MS_NOSUID for additional security).
This commit introduces the option --ambient-capability and the config
file option AmbientCapability=. Both are used in a similar way to the
existing Capability= setting. It changes the inheritable and ambient
set (which is 0 by default). The code also checks that the settings
for the bounding set (as defined by Capability= and DropCapability=)
and the setting for the ambient set (as defined by AmbientCapability=)
are compatible. Otherwise, the operation would fail in any way.
Due to the current use of -1 to indicate no support for ambient
capability set the special value "all" cannot be supported.
Also, the setting of ambient capability is restricted to running a
single program in the container payload.
We should avoid duplicating lengthy description of very similar concepts.
--root-hash-sig follows the same semantics as RootHashSig=, so just refer
the reader to the other man page. --root-hash doesn't implement the same
features as RootHash=, so we can't fully replace the description, but let's
give the user a hint to look at the other man page too.
For #17177.
By default we'll run a container in --console=interactive and
--console=read-only mode depending if we are invoked on a tty or not so
that the container always gets a /dev/console allocated, i.e is always
suitable to run a full init system /as those typically expect a
/dev/console to exist).
With the new --console=autopipe mode we do something similar, but
slightly different: when not invoked on a tty we'll use --console=pipe.
This means, if you invoke some tool in a container with this you'll get
full inetractivity if you invoke it on a tty but things will also be
very nicely pipeable. OTOH you cannot invoke a full init system like
this, because you might or might not become a /dev/console this way...
Prompted-by: #17070
(I named this "autopipe" rather than "auto" or so, since the default
mode probably should be named "auto" one day if we add a name for it,
and this is so similar to "auto" except that it uses pipes in the
non-tty case).
Since cryptsetup 2.3.0 a new API to verify dm-verity volumes by a
pkcs7 signature, with the public key in the kernel keyring,
is available. Use it if libcryptsetup supports it.
https://tools.ietf.org/html/draft-knodel-terminology-02https://lwn.net/Articles/823224/
This gets rid of most but not occasions of these loaded terms:
1. scsi_id and friends are something that is supposed to be removed from
our tree (see #7594)
2. The test suite defines an API used by the ubuntu CI. We can remove
this too later, but this needs to be done in sync with the ubuntu CI.
3. In some cases the terms are part of APIs we call or where we expose
concepts the kernel names the way it names them. (In particular all
remaining uses of the word "slave" in our codebase are like this,
it's used by the POSIX PTY layer, by the network subsystem, the mount
API and the block device subsystem). Getting rid of the term in these
contexts would mean doing some major fixes of the kernel ABI first.
Regarding the replacements: when whitelist/blacklist is used as noun we
replace with with allow list/deny list, and when used as verb with
allow-list/deny-list.
dm-verity support in dissect-image at the moment is restricted to GPT
volumes.
If the image a single-filesystem type without a partition table (eg: squashfs)
and a roothash/verity file are passed, set the verity flag and mark as
read-only.
It's not that I think that "hostname" is vastly superior to "host name". Quite
the opposite — the difference is small, and in some context the two-word version
does fit better. But in the tree, there are ~200 occurrences of the first, and
>1600 of the other, and consistent spelling is more important than any particular
spelling choice.
The default value was described at the end of two long paragraphs.
Make the first para self contained, and move the description of --console=pipe
into the second para.
To access a shell on a disk image, the man page on Fedora-29 says to
run: `systemd-nspawn -M Fedora-Cloud-Base-28-1.1.x86_64.raw`. Let's
try.
List existing images:
$> machinectl list-images | awk '{print $1,$2}';
NAME TYPE
Fedora-Cloud-Base-30… raw
1 images
Now invoke `systemd-nspawn` as noted in the man page:
$> systemd-nspawn -M Fedora-Cloud-Base-30-1.2.x86_64.raw
No image for machine 'Fedora-Cloud-Base-30-1.2.x86_64.raw'.
Removing the ".raw" extension launches the image and gives a shell.
Update the man page to reflect that.
Frantisek Sumsal on #systemd (Freenode) noted the reason: "In older
versions systemd -M accepted both image-name.raw and image-name as a
valid image names, however, on Fedora 29 (systemd-239) with all the
BTRFS stuff around it accepts only -M image-name (without the
extension)"
- - -
While at it, update the fedora_{latest_version, cloud_release}
variables.
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
No other changes, just some reshuffling and adding of section headers
(well, admittedly, I changed some "see above" and "see below" in the
text to match the new order.)
