Re: [systemd-devel] systemd-networkd on by default?

2014-02-21 Thread Reindl Harald


Am 21.02.2014 04:41, schrieb Zbigniew Jędrzejewski-Szmek:
 On Fri, Feb 21, 2014 at 04:00:10AM +0100, Jason A. Donenfeld wrote:
 systemd-networkd seems to get started by default in 209. Why is this?
 What if I don't want to use it to manage my networks? Why does it have
 to be on by default?

 I think the reasoning was that it doesn't do anything by default (when
 there are no configuration files)

that is a bad reasoning

not a single process should be running if it has no job to do
for the sake of ressource usage, security and clean systems



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-networkd on by default?

2014-02-21 Thread Holger Schurig
I agree with Harald.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-networkd on by default?

2014-02-21 Thread Colin Guthrie
'Twas brillig, and Reindl Harald at 21/02/14 08:45 did gyre and gimble:
 
 
 Am 21.02.2014 04:41, schrieb Zbigniew Jędrzejewski-Szmek:
 On Fri, Feb 21, 2014 at 04:00:10AM +0100, Jason A. Donenfeld wrote:
 systemd-networkd seems to get started by default in 209. Why is this?
 What if I don't want to use it to manage my networks? Why does it have
 to be on by default?

 I think the reasoning was that it doesn't do anything by default (when
 there are no configuration files)
 
 that is a bad reasoning
 
 not a single process should be running if it has no job to do
 for the sake of ressource usage, security and clean systems

Well I kinda get that using it for containers and such like could be
useful, but I also suspect it should be bus or socket activated rather
than statically enabled... like localed, datetimed etc. Any reason to
enable it statically? (I guess it maybe has to do stuff by itself, but I
would figure udev should kick it in via the setup link built in in most
cases - but I guess that wouldn't work inside containers, so perhaps
this is where things break down and you need it statically enabled).

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-networkd on by default?

2014-02-21 Thread Reindl Harald


Am 21.02.2014 16:44, schrieb Colin Guthrie:
 'Twas brillig, and Reindl Harald at 21/02/14 08:45 did gyre and gimble:
 Am 21.02.2014 04:41, schrieb Zbigniew Jędrzejewski-Szmek:
 On Fri, Feb 21, 2014 at 04:00:10AM +0100, Jason A. Donenfeld wrote:
 systemd-networkd seems to get started by default in 209. Why is this?
 What if I don't want to use it to manage my networks? Why does it have
 to be on by default?

 I think the reasoning was that it doesn't do anything by default (when
 there are no configuration files)

 that is a bad reasoning

 not a single process should be running if it has no job to do
 for the sake of ressource usage, security and clean systems
 
 Well I kinda get that using it for containers and such like could be
 useful, but I also suspect it should be bus or socket activated rather
 than statically enabled... like localed, datetimed etc. Any reason to
 enable it statically? (I guess it maybe has to do stuff by itself, but I
 would figure udev should kick it in via the setup link built in in most
 cases - but I guess that wouldn't work inside containers, so perhaps
 this is where things break down and you need it statically enabled)

statically enabled is bad in general, containers are not a good
reason to enable something for everybody, many if not most people
never will use containers for several reasons and if it because
they use full-virtualization and move machines between different
also non-linux hosts

where i would support something new enabled by default is if
could *replace* something else like LSB network.service while
use it's ifcfg-configurations for backward compatibility and
test out if it really can replace all cases

if i can replace that below i start to be one of the first
production users in a complexer setup (one is the MAC of
the physical card, the other is what it becames before
fetch the IP from the ISP because you need to register
your MAC there, that's the same like MAC cloning
in small soho-routers)

DEVICE=eth1
HWADDR=68:05:ca:0d:62:c1
ONBOOT=yes
BOOTPROTO=dhcp
IPV6INIT=no
NM_CONTROLLED=no
USERCTL=no
PEERDNS=no
MACADDR=00:50:8d:b5:cc:de

but something hanging around unconfigured please no




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-networkd on by default?

2014-02-21 Thread Lennart Poettering
On Fri, 21.02.14 15:44, Colin Guthrie (gm...@colin.guthr.ie) wrote:

 'Twas brillig, and Reindl Harald at 21/02/14 08:45 did gyre and gimble:
  
  
  Am 21.02.2014 04:41, schrieb Zbigniew Jędrzejewski-Szmek:
  On Fri, Feb 21, 2014 at 04:00:10AM +0100, Jason A. Donenfeld wrote:
  systemd-networkd seems to get started by default in 209. Why is this?
  What if I don't want to use it to manage my networks? Why does it have
  to be on by default?
 
  I think the reasoning was that it doesn't do anything by default (when
  there are no configuration files)
  
  that is a bad reasoning
  
  not a single process should be running if it has no job to do
  for the sake of ressource usage, security and clean systems
 
 Well I kinda get that using it for containers and such like could be
 useful, but I also suspect it should be bus or socket activated rather
 than statically enabled... like localed, datetimed etc. Any reason to
 enable it statically? (I guess it maybe has to do stuff by itself, but I
 would figure udev should kick it in via the setup link built in in most
 cases - but I guess that wouldn't work inside containers, so perhaps
 this is where things break down and you need it statically enabled).

networkd has a set of config files that have [Match] sections in them
that described to which interface types they apply. networkd watches
network interfaces come and go and picks the config file with the
highest prio and apply that. If there is none it will not do anything
and leave the interface for other components. In addition to that it can
actually create devices based on .netdev files. 

What networkd does hence is dependent on devices showing up as well as
configuration files, and they do not map trivially against each
other. This means that we need to start networkd both when there is
config around and when net devices pop up. Now with the veth stuff there
will always be config around and on pretty much any system there will be
network interfaces around of some kind, hence it would tsart anyway by
default. And given that that is how it is we simply start it at boot,
because it is simpler, and less magic...

networkd does not currently have a client API, thus socket and bus
activation do not apply.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-networkd on by default?

2014-02-21 Thread Lennart Poettering
On Fri, 21.02.14 16:51, Reindl Harald (h.rei...@thelounge.net) wrote:

  Well I kinda get that using it for containers and such like could be
  useful, but I also suspect it should be bus or socket activated rather
  than statically enabled... like localed, datetimed etc. Any reason to
  enable it statically? (I guess it maybe has to do stuff by itself, but I
  would figure udev should kick it in via the setup link built in in most
  cases - but I guess that wouldn't work inside containers, so perhaps
  this is where things break down and you need it statically enabled)
 
 statically enabled is bad in general, containers are not a good
 reason to enable something for everybody, many if not most people
 never will use containers for several reasons and if it because
 they use full-virtualization and move machines between different
 also non-linux hosts

Tom changed git to not statically enable it anymore, but still enable it
by default.

 where i would support something new enabled by default is if
 could *replace* something else like LSB network.service while
 use it's ifcfg-configurations for backward compatibility and
 test out if it really can replace all cases

Well, the old network script is not part of LSB...

But yeah, networkd should already cover much of what ifcfg could do, but
not everything. There are some thing that'll be added shortly (like
dhcp6 support), but others we will never support, such as isdn...

 if i can replace that below i start to be one of the first
 production users in a complexer setup (one is the MAC of
 the physical card, the other is what it becames before
 fetch the IP from the ISP because you need to register
 your MAC there, that's the same like MAC cloning
 in small soho-routers)
 
 DEVICE=eth1
 HWADDR=68:05:ca:0d:62:c1
 ONBOOT=yes
 BOOTPROTO=dhcp
 IPV6INIT=no
 NM_CONTROLLED=no
 USERCTL=no
 PEERDNS=no
 MACADDR=00:50:8d:b5:cc:de

Yes, you can do that. drop in a .link file that looks something like this:

[Match]
MACAddress=68:05:ca:0d:62:c1

[Link]
MACAddress=00:50:8d:b5:cc:de
Name=foobar

With that the device will be matche against 68:05:ca:0d:62:c1 and when
that exists we will rename it to foobar and apply the address
00:50:8d:b5:cc:de to it.

Then, also drop in a .network file:

[Match]
Name=foobar

[Network]
DHCP=yes

And there you go.

(Note that the ethXYZ namespace is used by the kernel, we will not allow
renaming interfaces to that so that we never race against the
kernel. Hence the example above uses foobar as interface name instead.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] systemd-networkd on by default?

2014-02-20 Thread Jason A. Donenfeld
Hi folks,

systemd-networkd seems to get started by default in 209. Why is this?
What if I don't want to use it to manage my networks? Why does it have
to be on by default?

Jason
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-networkd on by default?

2014-02-20 Thread Umut Tezduyar Lindskog


 -Original Message-
 From: systemd-devel-boun...@lists.freedesktop.org [mailto:systemd-
 devel-boun...@lists.freedesktop.org] On Behalf Of Zbigniew Jedrzejewski-
 Szmek
 Sent: den 21 februari 2014 04:42
 To: Jason A. Donenfeld
 Cc: systemd Mailing List
 Subject: Re: [systemd-devel] systemd-networkd on by default?
 
 On Fri, Feb 21, 2014 at 04:00:10AM +0100, Jason A. Donenfeld wrote:
  Hi folks,
 
  systemd-networkd seems to get started by default in 209. Why is this?
  What if I don't want to use it to manage my networks? Why does it have
  to be on by default?
 I think the reasoning was that it doesn't do anything by default (when there
 are no configuration files), so it is safe to enable. Maybe it should be made
 conditional on the existence of configuration files.
 
 Zbyszek

It can also be disabled by configure flag --disable-networkd. 
Thanks,
Umut

 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel