Re: Bug#806949: ifupdown: some tweaks to networking.service

[Bob Proulx]

Michael Biebl wrote:
> schrieb Bob Proulx:
> > If a client system requires an NFS mounted file system then the admin
> > must configure the network to be "auto" and not "allow-hotplug".
> > The simple reason is that because otherwise it won't work. :-)
> 
> That's not quite acurate. The if-up.d hook scripts did work for
> allow-hotplug under sysvinit. It just meant, the NFS share was mounted
> at an arbitrary point during boot.
> So allow-hotplug and SysV init scripts with Required-Start: $network was
> not a good combination.

I am talking about the traditional sysvinit system here.  It needs
"auto" for it to work properly for NFS mounted file systems.

For example a small corporate workstation which requires a hard
mounted NFS mounted (no autofs) $HOME for a user to be able to log
into the system.  For that to happen then the network must be online
before the NFS mounts are attempted and before the user has a login
prompt available.  Environments such as that tend to use other hard
mounted NFS file systems other than $HOME too.  The easiest way to
ensure this is with "auto" for the network.  Although I am sure it is
possible to tinker something together in the event driven path through
"allow-hotplug" but that has never worked by default for me.  There
hasn't ever been an itch to scratch to make allow-hotplug to work in
that type of environment since there it doesn't make sense to have
$HOME on a sometimes-there sometimes-not-there interface.

> Under systemd mounting works a bit differently and fails hard if network
> is not yet up when the remote mounts are triggered.

I am not running systemd and my comments were concerning Jessie,
Wheezy and previous releases using sysvinit.  Jessie with sysvinit
seems the same to me as the previous releases in this behavior.

> So this is a regression compared to wheezy.

There are many facets and one must be careful to be specific about the
specific part of it.  As far as needing auto versus allow-hotplug I
don't see any regression on that particular facet of the issue.

Bob


signature.asc
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#806949: ifupdown: some tweaks to networking.service

[Michael Biebl]

Am 24.12.2015 um 00:29 schrieb Bob Proulx:
> Michael Biebl wrote:
>> schrieb Bob Proulx:
>>> If a client system requires an NFS mounted file system then the admin
>>> must configure the network to be "auto" and not "allow-hotplug".
>>> The simple reason is that because otherwise it won't work. :-)
>>
>> That's not quite acurate. The if-up.d hook scripts did work for
>> allow-hotplug under sysvinit. It just meant, the NFS share was mounted
>> at an arbitrary point during boot.
>> So allow-hotplug and SysV init scripts with Required-Start: $network was
>> not a good combination.
> 
> I am talking about the traditional sysvinit system here.  It needs
> "auto" for it to work properly for NFS mounted file systems.
> 
> For example a small corporate workstation which requires a hard
> mounted NFS mounted (no autofs) $HOME for a user to be able to log
> into the system.

allow-hotplug still works sufficiently under sysvinit. It will mount
$HOME as soon as the network is up. It just doesn't block boot.

So the worst thing that can happen is, that getty or gdm is already
started even though $HOME has not been mounted yet.

Under systemd, with allow-hotplug, having $HOME on NFS and the network
is not yet up, you'll be dropped into rescue mode.

That's a much worse error case then under sysvinit.

Michael



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#806949: ifupdown: some tweaks to networking.service

[Bob Proulx]

Martin Pitt wrote:
> Michael Biebl wrote:
> > I still think though, that we should consider allow-hotplug interfaces
> > when dealing with network-online.target.
> > 
> > The reason is, that the debian installer uses allow-hotplug by default.
> 
> Argh, this is indeed a tremendously bad default. So far I had the
> impression that "auto" is for "must be present for booting", and
> "allow-hotplug" is for "bring it up when present, but don't block on
> it on boot". But if the installer always uses allow-hotplug, then I
> think that completely defies trying to make any difference between the
> two.

If a client system requires an NFS mounted file system then the admin
must configure the network to be "auto" and not "allow-hotplug".
The simple reason is that because otherwise it won't work. :-)

When the debian-installer initially installs a system there is no
dependency upon an NFS file system.  It is okay to have allow-hotplug
be the default used by the d-i.  It is a lowest common denominator and
works for most systems.  However if the admin then configures the
system to use a remotely mounted NFS file system part of that
configuration must be to set the interface to "auto" requiring it to
be present.  That's okay.  That is the way it has been for every
release since "allow-hotplug" arrived.

It is also possible to set up other types of mounting such as through
an automounter using autofs, amd, or other systems.  Each of those
will have their own specific needs that must be taken into
consideration.  If someone requires a hotplugged network system and
also wants remote mounting they can set it up but there isn't any
standard configuration for it and they will need to be responsible for
the complexity of it.  Trying to create a magic system that handles
every possible combination will end up failing and just creating a
mess.

Bob


signature.asc
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#806949: ifupdown: some tweaks to networking.service

[Guus Sliepen]

On Mon, Dec 21, 2015 at 05:57:39PM +0100, Michael Biebl wrote:

> In addition to
> [Install]
> WantedBy=network-online.target
> 
> you also need
> [Unit]
> Before=network-online.target

Ok.

> It also looks like the
> /etc/systemd/system/network-online.target.wants/networking.service
> was not created here when I upgraded from 0.8.2

Hm, you are right. It is installed when I upgrade from < 0.8 or purge
and reinstall.

> This looks like a bug in init-system-helpers.
> 
> Guus, can you please verify that and file a bug against
> init-systemd-helpers if so.

It doesn't look like init-systemd-helpers is used at all. I guess this
is only invoked when dh-systemd is used. I'll try to add
dh_systemd_enable to debian/rules and see if that does what needs to be
done during an upgrade.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#806949: ifupdown: some tweaks to networking.service

[Michael Biebl]

Am 21.12.2015 um 22:30 schrieb Guus Sliepen:
> On Mon, Dec 21, 2015 at 05:57:39PM +0100, Michael Biebl wrote:

>> It also looks like the
>> /etc/systemd/system/network-online.target.wants/networking.service
>> was not created here when I upgraded from 0.8.2
> 
> Hm, you are right. It is installed when I upgrade from < 0.8 or purge
> and reinstall.
> 
>> This looks like a bug in init-system-helpers.
>>
>> Guus, can you please verify that and file a bug against
>> init-systemd-helpers if so.
> 
> It doesn't look like init-systemd-helpers is used at all. I guess this
> is only invoked when dh-systemd is used. I'll try to add
> dh_systemd_enable to debian/rules and see if that does what needs to be
> done during an upgrade.

I wasn't aware you didn't use init-system-helpers. Didn't look
explicitly at the maintainer scripts.

i-s-h should handle such updates to the .service file, that's one reason
why we recommend its use.

Regards,
Michael



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#806949: ifupdown: some tweaks to networking.service

[Michael Biebl]

Am 20.12.2015 um 22:37 schrieb Michael Biebl:
> Am 20.12.2015 um 22:23 schrieb Guus Sliepen:
>> On Sun, Dec 20, 2015 at 08:48:07PM +0100, Michael Biebl wrote:
>>
>>> Guus already suggested to simply add
>>>  WantedBy=network-online.target
>>>
>>> This would be a partial solution and better then nothing, I guess.
>>
>> Since noone is against this, I'll go for this option. If I understand
>> systemd correctly, I can just add a ifupdown-network-online.service
>> later that also has a WantedBy=network-online.target, and only when both
>> that one and networking.service has started will network-online.target
>> be considered reached.

In addition to
[Install]
WantedBy=network-online.target

you also need
[Unit]
Before=network-online.target

The second bit is missing in your upload.

It also looks like the
/etc/systemd/system/network-online.target.wants/networking.service
was not created here when I upgraded from 0.8.2

This looks like a bug in init-system-helpers.

Guus, can you please verify that and file a bug against
init-systemd-helpers if so.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#806949: ifupdown: some tweaks to networking.service

[Guus Sliepen]

On Sun, Dec 20, 2015 at 08:48:07PM +0100, Michael Biebl wrote:

> Guus already suggested to simply add
>  WantedBy=network-online.target
> 
> This would be a partial solution and better then nothing, I guess.

Since noone is against this, I'll go for this option. If I understand
systemd correctly, I can just add a ifupdown-network-online.service
later that also has a WantedBy=network-online.target, and only when both
that one and networking.service has started will network-online.target
be considered reached.

> The reason is, that the debian installer uses allow-hotplug by default.
> And mounting remote file systems under systemd requires a properly
> hooked up network-online.target.
> Which means, for the vast majority of users with remote (NFS) mounts we
> currently ship a broken setup.

Does the installer support configuring a Debian system which uses a NFS
mount?

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#806949: ifupdown: some tweaks to networking.service

[Michael Biebl]

Am 14.12.2015 um 08:38 schrieb Martin Pitt:
> In order to not deviate too much from this schema, I'd prefer
> ifupdown-wait-online to do the same, i. e. wait until all "ifup"s of
> your "auto" interfaces are done. This will respect the configuration
> and not second-guess the admin. Thus in practical terms this indeed
> should mean nothing else than "networking.service is running", no? So
> at first sight just adding a WantedBy=network-online.target now makes
> sense, as it will do just that and not block sysinit.target any more.

Guus already suggested to simply add
 WantedBy=network-online.target

This would be a partial solution and better then nothing, I guess.

I still think though, that we should consider allow-hotplug interfaces
when dealing with network-online.target.

The reason is, that the debian installer uses allow-hotplug by default.
And mounting remote file systems under systemd requires a properly
hooked up network-online.target.
Which means, for the vast majority of users with remote (NFS) mounts we
currently ship a broken setup.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#806949: ifupdown: some tweaks to networking.service

[Guus Sliepen]

On Sat, Dec 12, 2015 at 05:18:36PM +0100, Tollef Fog Heen wrote:

> > So network-online.target is very ill-defined, and I'd rather not see
> > anything depending on it, but if we have to, I'd like something that is
> > as conservative as possible.
> 
> I think we should have something that's fairly conservative, yes.  «As
> possible» is too strict.  We shouldn't try calling home by default, for
> instance.

I agree with that. Attached is a script that can wait in a few different
ways:

- Wait for a route to be added (not necessarily a default route)
- Wait for an address to respond to ping packets
- Do nothing

Maybe I could add an option to wait for a specific interface to get a
(non-link-local) address assigned. But let me know if you have comments.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


wait-online.sh
Description: Bourne shell script


signature.asc
Description: Digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#806949: ifupdown: some tweaks to networking.service

[Tollef Fog Heen]

]] Guus Sliepen 

> offline() {
>   ip -4 r s | grep -q ^default && return 1
>   ip -6 r s | grep -q ^default && return 1
>   return 0
> }

As a default, this is fine. It can't be the only way to do it, though.
(I have hosts with a full routing table and hence no default route, and
I have hosts where the default route is not in the local table, but in
the default table.

[...]

> So network-online.target is very ill-defined, and I'd rather not see
> anything depending on it, but if we have to, I'd like something that is
> as conservative as possible.

I think we should have something that's fairly conservative, yes.  «As
possible» is too strict.  We shouldn't try calling home by default, for
instance.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#806949: ifupdown: some tweaks to networking.service

[Michael Biebl]

Am 07.12.2015 um 13:31 schrieb Guus Sliepen:

> Now that we have a proper systemd service
> for ifupdown, could we just add WantedBy=network-online.target to
> networking.service? The only difference to me seems that your script
> waits until ifup has configured at least one interface, while the simple
> WantedBy line waits until all auto interfaces have been configured.

I think that my PoC waits for both types is an important difference.

Also, in general, I think it's better if we split the device activation
and the "waiting for the network to be up" into separate services.

The benefit here is, that other services, that don't need
network-online.target would not be blocked unnecessarily during boot.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#806949: ifupdown: some tweaks to networking.service

[Guus Sliepen]

On Thu, Dec 10, 2015 at 01:59:42PM +0100, Michael Biebl wrote:

> > Now that we have a proper systemd service
> > for ifupdown, could we just add WantedBy=network-online.target to
> > networking.service? The only difference to me seems that your script
> > waits until ifup has configured at least one interface, while the simple
> > WantedBy line waits until all auto interfaces have been configured.
> 
> I think that my PoC waits for both types is an important difference.

That's true.

> Also, in general, I think it's better if we split the device activation
> and the "waiting for the network to be up" into separate services.
> 
> The benefit here is, that other services, that don't need
> network-online.target would not be blocked unnecessarily during boot.

I don't understand this. Are services that don't need
network-online.target blocked by networking.service in some way?

Anyway, if we are going for a script that polls stuff, then why not
decouple it completely from ifupdown or whatever networking framework is
used, and do the following?

#!/bin/sh
TIMEOUT=30

offline() {
ip -4 r s | grep -q ^default && return 1
ip -6 r s | grep -q ^default && return 1
return 0
}

i=0
while offline; do
if [ $i = $TIMEOUT ] ; then
break
fi
i=$(($i+1))
sleep 1
done

Which is just waiting until we have a default route. It can be made to
respond more quickly by using the "ip monitor" command. It's still not
perfect, but in general it's a better default criterion for being online
than "a network interface was configured". For example, the following
/e/n/i would cause your script to think the network is online:

iface foo inet manual

Or if you have a LAN and WAN interface, and the WAN interface is getting
a DHCP address which can take some time, and a LAN interface which is
configured statically, in which case some other service that waits for
network-online.target might start too early and only bind to the LAN
interface's address.

Of course, in the case of NFS mounts you typically do that over a LAN
and don't care about the WAN at that point (and maybe your server will
never get a default gateway route on purpose). In this case, you'd
actually want to wait until NFS server's IP address becomes routable,
and then start the mount command.

So network-online.target is very ill-defined, and I'd rather not see
anything depending on it, but if we have to, I'd like something that is
as conservative as possible.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#806949: ifupdown: some tweaks to networking.service

[Michael Biebl]

Am 10.12.2015 um 15:12 schrieb Guus Sliepen:
> On Thu, Dec 10, 2015 at 01:59:42PM +0100, Michael Biebl wrote:

>> The benefit here is, that other services, that don't need
>> network-online.target would not be blocked unnecessarily during boot.
> 
> I don't understand this. Are services that don't need
> network-online.target blocked by networking.service in some way?

This used to be the case, since /etc/init.d/networking was a rcS init
script, i.e. is started in sysinit.target.

Every service which as DefaultDependencies=yes (the majority) get's an
implicit dependency on sysinit.target. So making networking.service
block for the network to be configured would block at least all
DefaultDependencies=yes services.

I just noticed that you moved networking.service into multi-user.target,
so this might not be a concern anymore, unless something from
rcS/sysinit.target pulls in networking.service.

> Anyway, if we are going for a script that polls stuff, then why not
> decouple it completely from ifupdown or whatever networking framework is
> used, and do the following?

..

> Which is just waiting until we have a default route. It can be made to
> respond more quickly by using the "ip monitor" command. It's still not
> perfect, but in general it's a better default criterion for being online
> than "a network interface was configured".

Interesting idea.
This would be one way to do it.

> So network-online.target is very ill-defined, and I'd rather not see
> anything depending on it, but if we have to, I'd like something that is
> as conservative as possible.

I guess everyone agrees that network-online.target (or $network in LSB)
is an ill-conceived concept [1] and should only be used if the software
in question can't be fixed to deal with dynamic networking, where
devices and networks can come and go.

Michael

[1] http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#806949: ifupdown: some tweaks to networking.service

[Martin Pitt]

Hello,

Michael Biebl [2015-12-03 21:38 +0100]:
> >> Yes. The only problem though is that it requires the admin to correctly
> >> specify which interfaces are "auto" and which are "hotplug", because
> >> ifupdown cannot really figure that out itself. And there might be some
> >> cases where a virtual interface depends on one or more hotpluggable
> >> ones.
> 
> I actually think this ifupdown-wait-online service should block for
> allow-hotplug devices as well.

But then we must not use that from networking.service or anywhere else
from the boot sequence. The whole point of "allow-hotplug" is that
these devices may not be present at boot (USB devices).

> Some time ago, I hacked together a little PoC [1].

Indeed, this would be nice to integrate, and it's much more elegant
than the shell polling hack that we have in Ubuntu. Guus, would you
consider adopting this, so that we have a "wait-online" tool for all
three of ifupdown, NM, and networkd?

Thanks,

Martin


-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#806949: ifupdown: some tweaks to networking.service

[Michael Biebl]

Am 04.12.2015 um 09:35 schrieb Martin Pitt:
> Hello,
> 
> Michael Biebl [2015-12-03 21:38 +0100]:
 Yes. The only problem though is that it requires the admin to correctly
 specify which interfaces are "auto" and which are "hotplug", because
 ifupdown cannot really figure that out itself. And there might be some
 cases where a virtual interface depends on one or more hotpluggable
 ones.
>>
>> I actually think this ifupdown-wait-online service should block for
>> allow-hotplug devices as well.
> 
> But then we must not use that from networking.service or anywhere else
> from the boot sequence. The whole point of "allow-hotplug" is that
> these devices may not be present at boot (USB devices).

In theory, I agree. In practice, the debian-installer has used
allow-hotplug for all devices since a few release cycles.

So I assume the vast majority of users has allow-hotplug in their
/e/n/i, even for "internal" devices (onboard, PCI, etc).


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#806949: ifupdown: some tweaks to networking.service

[Guus Sliepen]

On Thu, Dec 03, 2015 at 01:06:01PM +0100, Martin Pitt wrote:

> many thanks for adding a native networking.service! Michael and I
> found some corrections and tweaks to be made,

Thanks for having a look at it. I'm still quite new to SystemD, so any
help there is welcome :)

> and we would also like
> to remove the /lib/systemd/system/networking.service.d/systemd.conf
> drop-in.

Great.

>  - Add Wants=network.target instead. It's passive target too, and as
>networking.service is a provider it needs to pull it in.
> 
>  - Add Before=network.target. This is important during shutdown to
>avoid stopping networking.service before any consumer of it (e. g.
>NFS, apache, etc.) -- otherwise shutting down these might hang due
>to cutting the network too early.

Ah, that clarifies things for me.

>  - Add After=local-fs.target. Depending on a read-only root partition
>might not be enough, as there might be actions in /e/n/i which
>require a writable root, or other mounted partitions. The current
>sysvinit file has "Required-Start: $local_fs" and we should
>probably keep that until we are really sure that we can drop it.

ifupdown itself only writes to /run/network, but indeed any plugins
might require a writable root.

>  - Add After=apparmor.service. Apparmor needs to run very early as it
>commonly installs profiles for network-facing software like
>dhcp-client. Note that this is a no-op when apparmor isn't being
>used, as there is no Wants= (i. e. just ordering, no dependency).

No problem. Are there other such services that might require loading
before ifupdown? SELinux?

>  - Drop systemd-udev-settle.service. Please let's not do this
>unconditionally.  udev-settle is a really bad workaround for software 
> which does not
>know about hotplugging, it's racy, might take a long time
>unnecessarily, and isn't required at all when one does not actually
>use ifupdown.
> 
>The init.d script does this conditionally at least:
> 
>   if [ -n "$(ifquery --list --exclude=lo)" ] || [ -n "$(ifquery --list 
> --allow=hotplug)" ]; then
>   udevadm settle || true
> 
>Although this looks overzealous to me -- I thought the intention
>was to make sure that all "static" interfaces are present before
>you start ifup'ing them, i. e. for the "auto" class. We
>specifically want "allow-hotplug" devices to *not* block the boot,
>only for the "auto" ones, no?
> 
>So if you want to keep the current approach, I suggest adding this
>instead:
> 
>ExecStartPre=-/bin/sh -c '[ -n "$(ifquery --list --exclude=lo)" ] && 
> udevadm settle'

Ok, in that case it might be nice to add --read-environment to ifquery
as well, so EXCLUDE_INTERFACES will be read. Something like this?

ExecStartPre=-/bin/sh -c '[ "$CONFIGURE_INTERFACES" != no ] && [ -n "$(ifquery 
--list --read-environment --exclude=lo)" ] && udevadm settle'

>In the medium term I'd be interested in cleaning this up, though.
>IMHO there needs to be a proper ifupdown-wait-online.service which
>just starts the virtual interfaces, let all the real ones be
>handleld by udev hotplug rules, and just waits until all "auto"
>services are up. This avoids the race condition and unnecessary
>blocking on udev settle. But this should be discussed in a separate
>bug, and I'll also send one for moving the "allow-hotplug" handling
>bits into ifupdown (where they fit much better than in the udev
>package).

Yes. The only problem though is that it requires the admin to correctly
specify which interfaces are "auto" and which are "hotplug", because
ifupdown cannot really figure that out itself. And there might be some
cases where a virtual interface depends on one or more hotpluggable
ones.

>But the above just mimics what the sysvinit script does, so it's a
>good iteration. :-)

Yes. I'll start preparing 0.8.2 :)

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#806949: ifupdown: some tweaks to networking.service

[Martin Pitt]

Hey Guus,

thanks for the quick answer! Nice to see that ifupdown is not
abandoned any more, great work!

Guus Sliepen [2015-12-03 13:44 +0100]:
> >  - Add After=local-fs.target. Depending on a read-only root partition
> >might not be enough, as there might be actions in /e/n/i which
> >require a writable root, or other mounted partitions. The current
> >sysvinit file has "Required-Start: $local_fs" and we should
> >probably keep that until we are really sure that we can drop it.
> 
> ifupdown itself only writes to /run/network, but indeed any plugins
> might require a writable root.

You are the expert there, so if that's the only assumption that hook
code can make, it's fine to drop. I added local-fs.target to do what
the init.d script does, so it's not a regression in terms of
dependencies.  I don't know which assumptions plugins or if-up.d/
scripts can make about the system, so it might be that this can be
relaxed to just "root fs is writable" or even drop it completely. But
then again, local-fs.target doesn't appear to be an unreasonable
assumption.

> >  - Add After=apparmor.service. Apparmor needs to run very early as it
> >commonly installs profiles for network-facing software like
> >dhcp-client. Note that this is a no-op when apparmor isn't being
> >used, as there is no Wants= (i. e. just ordering, no dependency).
> 
> No problem. Are there other such services that might require loading
> before ifupdown? SELinux?

systemd has native support for loading SELinux profiles, so that
shouldn't be required. At some point it should learn how to natively
load AppArmor profiles during early boot too (the Ubuntu security team
is working on that), but until then we need to rely on the external
apparmor.service.

I'm not aware of other MAC systems that need this.

> >ExecStartPre=-/bin/sh -c '[ -n "$(ifquery --list --exclude=lo)" ] && 
> > udevadm settle'
> 
> Ok, in that case it might be nice to add --read-environment to ifquery
> as well, so EXCLUDE_INTERFACES will be read. Something like this?
> 
> ExecStartPre=-/bin/sh -c '[ "$CONFIGURE_INTERFACES" != no ] && [ -n 
> "$(ifquery --list --read-environment --exclude=lo)" ] && udevadm settle'

Sure!

> >In the medium term I'd be interested in cleaning this up, though.
> >IMHO there needs to be a proper ifupdown-wait-online.service which
> >just starts the virtual interfaces, let all the real ones be
> >handleld by udev hotplug rules, and just waits until all "auto"
> >services are up. This avoids the race condition and unnecessary
> >blocking on udev settle. But this should be discussed in a separate
> >bug, and I'll also send one for moving the "allow-hotplug" handling
> >bits into ifupdown (where they fit much better than in the udev
> >package).
> 
> Yes. The only problem though is that it requires the admin to correctly
> specify which interfaces are "auto" and which are "hotplug", because
> ifupdown cannot really figure that out itself. And there might be some
> cases where a virtual interface depends on one or more hotpluggable
> ones.

A statically configured "auto" bridge depending on allow-hotplug
interfaces sounds weird to me -- what should the semantics of that be?
But indeed the syntax allows doing that. What does ifup -a do if it
encounters this and one of the dependent devices does not exist? I
figure it just writes an error, but there's nothing to re-attempt
stating the composite device once one of its dependencies comes up?

Other things like networkd or NM have an internal understanding of
this hierarchy, but this is harder to do with ifupdown indeed. So for
now, the conditional udevsettle if there are configured interfaces
seems ok.

Just for the record, Ubuntu has a fairly different approach there: It
never supported "allow-hotplug" really, udev rules dynamically bring
up both "auto" and "allow-hotplug" devices, and there is an
implementation of "ifup-wait-all-auto.service" similar to
systemd-networkd-wait-all-auto.service that waits for all "auto"
interfaces in /e/n/i to be up for up to 2 minutes, and then continues
the boot. I don't know the exact reasoning why this was done back then
(this dates back to the upstart work from Scott and Stèphane), but
apparently it was found to be a more robust approach.

I'm not saying that this is necessarily better, just wanted to mention
it that it exists.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#806949: ifupdown: some tweaks to networking.service

[Michael Biebl]

Hi Guus

Am 03.12.2015 um 13:44 schrieb Guus Sliepen:
> On Thu, Dec 03, 2015 at 01:06:01PM +0100, Martin Pitt wrote:
> 
>> many thanks for adding a native networking.service! Michael and I
>> found some corrections and tweaks to be made,
> 
> Thanks for having a look at it. I'm still quite new to SystemD, so any

Just minor nitpick from the peanut gallery: Upstream wants it to be
called systemd, not SystemD.

> No problem. Are there other such services that might require loading
> before ifupdown? SELinux?

Should we order networking.service after

- systemd-sysctl.service
  applies sysctl settings from /etc/sysctl.{conf,d/}
- systemd-modules-load.service
  loads kernel modules specified in /etc/modules, /etc/modules-load.d/



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#806949: ifupdown: some tweaks to networking.service

[Guus Sliepen]

On Thu, Dec 03, 2015 at 03:51:14PM +0100, Michael Biebl wrote:

> Just minor nitpick from the peanut gallery: Upstream wants it to be
> called systemd, not SystemD.

Oops.

> > No problem. Are there other such services that might require loading
> > before ifupdown? SELinux?
> 
> Should we order networking.service after
> 
> - systemd-sysctl.service
>   applies sysctl settings from /etc/sysctl.{conf,d/}
> - systemd-modules-load.service
>   loads kernel modules specified in /etc/modules, /etc/modules-load.d/

That sounds like a good idea. Ifupdown itself and most of the plugins
would normally work fine without those dependencies, but an admin might
intentionally put something in there that is expected to be set/loaded
before networking is brought up. I'll just err on the safe side.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers