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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
While it is currently possible to either not set MACAddressPolicy or set
it to a value different from "persistent" or "random", it is not obvious
that a user can do so. Add a policy, "none", which simply retains kernel
MAC addresses (same as not filling in the policy at all) and document it
so that users are aware of this setting.
Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
This should clear up some confusion in
https://github.com/systemd/systemd/issues/717.
This basically copies the description from systemd.unit to this
man page. Masking can happen also in /run, so strike the part
about /etc, and also add the magic work "mask".
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.
Two of the bits in the MAC address are set unconditioanlly, and the rest is randomized,
make this clear in the documentation (as it currently read as if it was all random).
In particular, use /lib/systemd instead of /usr/lib/systemd in distributions
like Debian which still have not adopted a /usr merge setup.
Use XML entities from man/custom-entities.ent to replace configured paths while
doing XSLT processing of the original XML files. There was precedent of some
files (such as systemd.generator.xml) which were already using this approach.
This addresses most of the (manual) fixes from this patch:
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/Fix-paths-in-man-pages.patch?h=experimental-220
The idea of using generic XML entities was presented here:
http://lists.freedesktop.org/archives/systemd-devel/2015-May/032240.html
This patch solves almost all the issues, with the exception of:
- Path to /bin/mount and /bin/umount.
- Generic statements about preference of /lib over /etc.
These will be handled separately by follow up patches.
Tested:
- With default configure settings, ran "make install" to two separate
directories and compared the output to confirm they matched exactly.
- Used a set of configure flags including $CONFFLAGS from Debian:
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/rules
Installed the tree and confirmed the paths use /lib/systemd instead of
/usr/lib/systemd and that no other unexpected differences exist.
- Confirmed that `make distcheck` still passes.
This has been requested repeatedly, so let's give it a go. We explicitly do not allow matching
on names that have already been changed (from a previous udev run, or otherwise), and matching
on unpredictable names (ethX) is discouraged (but not currently disallowed).
We also currently allow:
[Match]
Name=veth0
[Link]
Name=my-name0
SomeOtherSetting=true
Which means that the link file will be applied the first time it is invoked, but
not on subsequent invocations, which may be surprising.
Newer kernels export meta-information about the origin of an ifname. Respect this
from the ifname rename logic. We do not rename any interfaces that was originally
named by userspace, nor once which have already been renamed from userspace.
Moreover, we optionally do not (the default) rename interfaces which the kernel
claims to have named in a predictable way.
