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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
NM_CONTROLLED should always be set together with DISABLED;
otherwise, it's possible to reach the state where
DISABLED=no but NM_CONTROLLED=yes, and have the interface
controlled by both NM and etcnet.
When renaming HOSTNAME in the alterator, switches managing interface to etcnet.
This creates problems for users.
This partial reverts commit d4170557c2.
This reverts commit 226a2395e5.
Users are getting upset about NetworkManager being unable to
configure "System EthX" connections that are meant to set up
with "acc" (which isn't obvious at all).
See-also: https://forum.altlinux.org/index.php?topic=42519.0
Brief version: otherwise DNS resolving might fail to perform
until dnsmasq service restart or system reboot (ouch!).
The problem:
1) NetworkManager requires dnsmasq;
2) dnsmasq can win a race against dhcpcd on ethernet.
The result:
1) /etc/resolv.conf looks fine;
2) dnsmasq is running;
3) resolving beyond /etc/hosts fails.
Suggested-by: Mikhail Efremov <sem@altlinux.org>
The common problem was network-config-subsystem getting
resolved into something completely wrong (like net-scripts
or systemd-networkd) *before* it got specified precisely;
let's just avoid the common cause, that is, a metapackage.
See-also: https://bugzilla.altlinux.org/show_bug.cgi?id=30806
It's not much use for it to stay without the actual
pointer to the place where NM GUIs are referenced,
I've almost started out implementing the "missing"
bit myself right now :-/
Putting any configuration into /etc/net/ifaces/lo/resolv.conf
makes etcnet *overwrite* /etc/resolv.conf, while putting that
into /etc/resolv.conf itself makes e.g. vzctl --nameserver
*append* to what's been specified.
Reported-by: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
Refer to net-dns feature where appropriate
(it actually started out as an extension of
net feature but the reasons to separate it
quickly became apparent to me).
These are aimed to test the modules.d/ and auto-pickup
implementation as well as to present an example.
At least 50-net might change (or just get renamed to avoid
auto-pickup) some day as the "net" feature's meaning is
to provide networking upon bootup and these modules are
only needed within stage1 if we're going to netboot;
and that's quite different thing.
armh-cubox bits are prone to get renamed/generalized too
since e.g. ArmadaXP based server images are going to need
this as well.
This needs further refinement regarding p7/t7 specifically:
NM behaviour regarding defaults differs in sisyphus and this
has led to livecds booting with DHCP networking but installed
systems booting without configured interfaces.
Non-GUI packages moved to base+nm pkglist to enable standalone
installation of those; and GTK bits left in desktop+nm for use
by images lacking their own new and improved(tm) variant.
Note that both GNOME3 and KDE4 aren't lacking anymore.
50-setup-network was a hasty hack (surprise!) that used to do
what net and net-eth features have been created to do since;
just drop the duplicated crufty code.
Unconditional resolver setup isn't done now: those with static
setup are better off doing it explicitly, and those with DHCP
should be fine already.
NB: /etc/hosts *is* fine within setup package *but* hasher will
overwrite it with a copy of host's one; let's reset contents
to initial at least until hasher gets fixed and the fix is
rather deployed in the wild.
The service and initscript have "connmand" name
while the package is called "connman" indeed.
Shame on me; this became apparent
while building regular-e18-sysv.
A bit longer version is: add the script which cares to protect
the interfaces which has been brought up during NFS root bootup
already from being tampered with by NetworkManager so as to avoid
losing network with networked rootfs.
This is to avoid NM messing with network interface
involved in NFS root filesystem being operational
(see alterator-netinst); thanks sem@ for the hint.
Intro: NetworkManager-wait-online.service would, well, wait
for some network interface to become online or for timeout
to kick in.
Problem: if a LiveCD is tested in offline environment
that timeout will only impede the boot.
Proposed solution: use/net/nm/nodelay target has been implemented
to disable that service as proposed by sem@ and done in Simply;
"+nm" target changed to be an alias to this one.
...net uses services, not services use net. That is,
"network" is a service that needs to be enabled by the
now-existing mechanism of "services" feature, don't be
fooled by "network services" here.
