Age | Commit message (Collapse) | Author |
|
Given a container "foo", that maps user id $UID to container user, using
user namespaces, this NSS module extenstion will now map the $UID to a
name "vu-foo-$TUID" for the translated UID $UID.
Similar, userns groups are mapped to "vg-foo-$TGID" for translated GIDs
of $GID.
This simple change should make userns users more discoverable. Also,
given that many tools like "adduser" check NSS before allocating a UID,
should lower the chance of UID range conflicts between tools.
|
|
man-pages: PR 384 rework
|
|
|
|
|
|
|
|
[@zonque: typo fixed, reported by @ronnychevalier]
|
|
[@zonque: Some minor nits fixed as pointed out by @ronnychevalier,
dropped class='sd-bus-errors' to fix python logic]
|
|
man: update and extend the various sd_bus_message_append_*() man pages
|
|
Some calls changed their signature since the man pages were written.
Also extend on a number of details.
|
|
python-system has moved to it's own repository:
https://github.com/systemd/python-systemd
|
|
man: sd-bus: typo fix
|
|
|
|
- Make sure that the IPv6PrivacyExtensions=yes results in
prefer-temporary, not prefer-public.
- Introduce special enum value "kernel" to leave setting unset, similar
how we have it for the IP forwarding settings.
- Bring the enum values in sync with the the strings we parse for them,
to the level this makes sense (specifically, rename "disabled" to
"no", and "prefer-temporary" to "yes").
- Make sure we really set the value to to "no" by default, the way it is
already documented in the man page.
- Fix whitespace error.
- Make sure link_ipv6_privacy_extensions() actually returns the correct
enum type, rather than implicitly casting it to "bool".
- properly size formatting buffer for ipv6 sysctl value
- Don't complain if /proc/sys isn't writable
- Document that the enum follows the kernel's own values (0 = off, 1 =
prefer-public, 2 = prefer-temporary)
- Drop redundant negating of error code passed to log_syntax()
- Manpage fixes
This fixes a number of issues from PR #417
|
|
Ipv6 private extensions
|
|
|
|
We refer to the same sysctl-setting twice, which is misleading. Correctly
list all global forwarding options. As we _always_ change the forwarding
setting on links, they will get disabled by default. The global sysctl
defaults thus will not have any effect.
|
|
Documentation updates
|
|
It turns out that since kernel 3.18 netfilter on bridged packets
is off anyway, so the example should be reworded (and the module
name updated).
|
|
https://bugzilla.redhat.com/show_bug.cgi?id=1144496
|
|
man: ProtectHome= protects /root as well
|
|
This facility was never a proper solution, but only papered over
real bugs in the kernel. There are no known sysfs "timing bugs"
since a long time.
|
|
|
|
|
|
Me again :) Just noticed one of these in a manpage and did another pass
to clean them up. See 16dad32e437fdf2ffca03cc60a083d84bd31886f for
explanation, though the link needs updating:
<http://transblawg.eu/2004/02/26/resp-and-other-non-existent-english-wordsnicht-existente-englische-worter/>
|
|
|
|
|
|
|
|
|
|
|
|
The bus proxy is multi-threaded now. Reflect that in the man pages.
|
|
|
|
|
|
|
|
man: revert dynamic paths for split-usr setups
|
|
This did not really work out as we had hoped. Trying to do this upstream
introduced several problems that probably makes it better suited as a
downstream patch after all. At any rate, it is not releaseable in the
current state, so we at least need to revert this before the release.
* by adjusting the path to binaries, but not do the same thing to the
search path we end up with inconsistent man-pages. Adjusting the search
path too would be quite messy, and it is not at all obvious that this is
worth the effort, but at any rate it would have to be done before we
could ship this.
* this means that distributed man-pages does not make sense as they depend
on config options, and for better or worse we are still distributing
man pages, so that is something that definitely needs sorting out before
we could ship with this patch.
* we have long held that split-usr is only minimally supported in order
to boot, and something we hope will eventually go away. So before we start
adding even more magic/effort in order to make this work nicely, we should
probably question if it makes sense at all.
|
|
A description of device_id lacked. We still need to do the other
udev_device_* man pages.
|
|
man: libudev - add description to udev_device_*
|
|
|
|
|
|
./configure --enable/disable-kdbus can be used to set the default
behavior regarding kdbus.
If no kdbus kernel support is available, dbus-dameon will be used.
With --enable-kdbus, the kernel command line option "kdbus=0" can
be used to disable kdbus.
With --disable-kdbus, the kernel command line option "kdbus=1" is
required to enable kdbus support.
|
|
man: explain max CPU load on cgtop
|
|
This adds man-pages for most of the libudev symbols we export. Similar
symbols are grouped together in a single man-page, with respective links
added. All man-pages contain the full skeleton including NAME, SYNOPSIS,
RETURN VALUE and SEE ALSO. However, most of them still lack the
DESCRIPTION part. This should be copied from the gtkdoc descriptions in
src/libudev/libudev*.[ch]. Any help is welcome! (the whole skeleton is
already done, so it's really just about the prose-part of the man-pages to
be written).
Missing from the man-pages are the following parts:
- udev_set_log_fn()
- udev_[gs]et_log_priority()
- udev_[gs]et_userdata()
- udev_list_entry_foreach()
- udev_device_get_seqnum()
- udev_device_get_usec_since_initialized()
- udev_util_encode_string()
These are considered legacy, afaik. If not, please feel free to add them
now!
Furthermore, udev-hwdb and udev-queue are not documented at all (for the
same reasons).
|
|
|
|
After all, we now moved sd-bus out of the kdbus conditional, hence the
man pages should be too.
|
|
|
|
As requested in #199.
|
|
As requested in #199.
|
|
Specifically: /etc/fstab overrides the units itself, but not the deps.
See #168.
|
|
|
|
We do not support '/run' for hwdb files. Drop it from the man-pages so
people don't accidentally use it.
This was reported by: Peter Hutterer <peter.hutterer@who-t.net>
|