systemd - standard place to run stuff after the network is up?

Lennart Poettering mzerqung at 0pointer.de
Thu Oct 20 23:16:34 UTC 2011


On Thu, 20.10.11 07:46, Matthew Miller (mattdm at mattdm.org) wrote:

> 
> On Mon, Oct 17, 2011 at 07:10:04PM +0200, Lennart Poettering wrote:
> > In general doing something like this is a bit backwards since networks
> > come and go and come and go in todays world, and we also don't want to
> 
> This seems like a very desktop-focused view of things. I appreciate that
> that's important, but please keep the server room in mind as well. In our
> environment, the network is like electricity -- if it's down, nothing is
> running. Having the software designed to be robust against unexpected
> network glitches is very useful, but if design decisions are constantly made
> with the assumption that networks are a random transient resource, we'll end
> up conceding our place in the data center in exchange for an incredibly tiny
> slice of the desktop pie.

If software can deal with networks changing then this benefits
everybody, regardless which use case you have, i.e. whether it's a
server, a desktop, a laptop, a tablet or whatever else. While network
configuration is fairly static for servers, and very dynamic for
tablets, it's not a binary thing, and you get everything in between
too. 

Note that while servers seldom move physically, the network
configuration might still change from time to time. If we make our
software robust to deal with network changes, then we make its usage on
servers more robust as well for the cases where the admin accidentaly
trips of a cable, or he readjusts the wiring, or he renumbers his hosts,
or renames, them or moves them to a different domain, or introduces a
new DNS server, and so on, and so on.

And that writing software that can deal with network changes is a good
thing and doesn't make it useless for the server use case you can see by
looking at bind, a service that much of the internet is running on and
that is running in numerous enterprises, and that since a long long time
listens to netlink and readjusts itself to network configuration
changes. 

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the devel mailing list