| Age | Commit message (Collapse) | Author |
|---|
|
Beef up the assert to protect against passing null to strlen.
Found with scan-build.
|
|
When the user specifies --with-tty-gid= then we should honour that and
write it to the snippet, too.
|
|
|
|
|
|
|
|
static files
systemd-sysusers is a tool to reconstruct /etc/passwd and /etc/group
from static definition files that take a lot of inspiration from
tmpfiles snippets. These snippets should carry information about system
users only. To make sure it is not misused for normal users these
snippets only allow configuring UID and gecos field for each user, but
do not allow configuration of the home directory or shell, which is
necessary for real login users.
The purpose of this tool is to enable state-less systems that can
populate /etc with the minimal files necessary, solely from static data
in /usr. systemd-sysuser is additive only, and will never override
existing users.
This tool will create these files directly, and not via some user
database abtsraction layer. This is appropriate as this tool is supposed
to run really early at boot, and is only useful for creating system
users, and system users cannot be stored in remote databases anyway.
The tool is also useful to be invoked from RPM scriptlets, instead of
useradd. This allows moving from imperative user descriptions in RPM to
declarative descriptions.
The UID/GID for a user/group to be created can either be chosen dynamic,
or fixed, or be read from the owner of a file in the file system, in
order to support reconstructing the correct IDs for files that shall be
owned by them.
This also adds a minimal user definition file, that should be
sufficient for most basic systems. Distributions are expected to patch
these files and augment the contents, for example with fixed UIDs for
the users where that's necessary.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
There might be implementations around where the network-online logic
might not talk to any network configuration service (and thus not have
to wait for it), hence let's explicitly order network-online.target
after network.target to avoid any ambiguities.
|
|
|
|
|
|
|
|
|
|
network-pre.target is a passive target that should be pulled in by
services that want to be executed before any network is configured (for
example: firewall scrips).
network-pre.target should be ordered before all network managemet
services (but not be pulled in by them).
network-pre.target should be order after all services that want to be
executed before any network is configured (and be pulled in by them).
|
|
|
|
|
|
|
|
systemd-journal
Also, don't apply access mode recursively to /var/log/journal/*/, since
that might be quite large, and should be correct anyway.
|
|
|
|
directories they are contained in
|
|
files/directories
This way it makes a lot more sense to specify an access mode for "Z"
lines.
|
|
|
|
|
|
If two lines refer to paths that are suffix and prefix of each other,
then always process the prefix first, the suffix second. In all other
cases strictly process rules in the order they appear in the files.
This makes creating /var/run as symlink to /run a lot more fun, since it
is automatically created first.
|
|
should be prefixed with arg_
|
|
such as /var
|
|
Let's allow booting up with /var empty. Only create the most basic
directories to get to a working directory structure and symlink set in
/var.
|
|
|
|
"m" so far has been a non-globbing version of "z". Since this makes it
quite redundant, let's get rid of it. Remove "m" from the man pages,
beef up "z" docs instead, and make "m" nothing more than a compatibility
alias for "z".
|
|
|
|
|
|
|
|
|
|
Not that it really would have any effect on the generated code, but
let's not confuse people...
|
|
It was forgotten in b1e90ec515408aec2702522f6f68c4920b56375b
See https://bugs.freedesktop.org/show_bug.cgi?id=79582
|
|
The return value from udev_enumerate_scan_devices was stored but
never used. I assume this was meant to be checked.
|
|
since v212 calling systemctl status without arguments
will show a overall system state
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=77092
On Thu, Jun 05, 2014 at 08:37:20AM +0200, Lennart Poettering wrote:
> The patch is line-broken, please send an uncorrupted patch!
I am very sorry, I forgot that my client limits line width. I will use
mutt now on.
> clamp_brightness() clamps the brightness value to the range of the
> actual device. This is a recent addition that was added to deal with
> driver updates where the resolution is changed. I don't think this part
> should be dropped for LED devices. The clamp_brightness() call hence
> should be called unconditionally, however, internally it should use a
> different min_brightness value if something is an !backlight devices...
Thank you for explanation, this sounds very reasonable to me. Please,
see updated patch:
|
|
|
|
The current vm detection lacks the distinction between Xen dom0 and Xen domU.
Both, dom0 and domU are running inside the hypervisor.
Therefore systemd-detect-virt and the ConditionVirtualization directive detect
dom0 as a virtual machine.
dom0 is not using virtual devices but is accessing the real hardware.
Therefore dom0 should be considered the virtualisation host and not a virtual
machine.
https://bugs.freedesktop.org/show_bug.cgi?id=77271
|
|
felt compelled to send in fixes for the obvious typos
|
|
|
|
|
|
Arguments were wrong order, no?
This fixes commits:
e918a1b5a94f270186dca59156354acd2a596494
3d06f4183470d42361303086ed9dedd29c0ffc1b
|
|
|
