2:04 p.m.
In case anyone missed it, FESCo's minutes have this:
"AGREED: FESCo expects the Tech specs/docs from working groups by
March 3rd at the latest"
So, we've been off meetings and stuff for three weeks now, we probably
should kick back into gear soon :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
6:13 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/19/2014 03:04 PM, Adam Williamson wrote:
In case anyone missed it, FESCo's minutes have this:
"AGREED: FESCo expects the Tech specs/docs from working groups by
March 3rd at the latest"
So, we've been off meetings and stuff for three weeks now, we
probably should kick back into gear soon :)
Sorry folks, I've been offline for the last two weeks due to a death
in the family and haven't been able to drive this. Has any progress
been made in my absence off-list?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMF8YMACgkQeiVVYja6o6P3QwCfWXquqQ9IahmcbmH+9e3a/MDF
42UAoKNKUJ2kllyE2u/NseLsWIMf3MFT
=cGxX
-----END PGP SIGNATURE-----
12:12 p.m.
On Thu, 2014-02-20 at 07:13 -0500, Stephen Gallagher wrote:
On 02/19/2014 03:04 PM, Adam Williamson wrote:
> In case anyone missed it, FESCo's minutes have this:
>
> "AGREED: FESCo expects the Tech specs/docs from working groups by
> March 3rd at the latest"
>
> So, we've been off meetings and stuff for three weeks now, we
> probably should kick back into gear soon :)
>
Sorry folks, I've been offline for the last two weeks due to a death
in the family and haven't been able to drive this. Has any progress
been made in my absence off-list?
Not hugely, no - I think we were all kind of waiting for you or someone
else to start driving :( Different sets of us showed up around meeting
time each week, I think, and we never quite had quorum.
I just saw the following pass by from Dan Williams on an RH internal
list, posting it here as I'm quite sure Dan wouldn't mind:
"You might install NetworkManager-config-server, which drops some
server-type config files into /etc/NetworkManager/conf.d that do things
like ignoring the carrier on all interfaces and ensuring NM never
creates the default DHCP connections that are useful on desktops. There
are other options in there, like making NM stop
touching /etc/resolv.conf if you know you never need to update it. See
"man NetworkManager.conf" for more details on all these options."
sounds like something we might want?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
12:24 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/20/2014 01:12 PM, Adam Williamson wrote:
On Thu, 2014-02-20 at 07:13 -0500, Stephen Gallagher wrote:
> On 02/19/2014 03:04 PM, Adam Williamson wrote:
>> In case anyone missed it, FESCo's minutes have this:
>>
>> "AGREED: FESCo expects the Tech specs/docs from working groups
>> by March 3rd at the latest"
>>
>> So, we've been off meetings and stuff for three weeks now, we
>> probably should kick back into gear soon :)
>>
>
> Sorry folks, I've been offline for the last two weeks due to a
> death in the family and haven't been able to drive this. Has any
> progress been made in my absence off-list?
Not hugely, no - I think we were all kind of waiting for you or
someone else to start driving :( Different sets of us showed up
around meeting time each week, I think, and we never quite had
quorum.
I just saw the following pass by from Dan Williams on an RH
internal list, posting it here as I'm quite sure Dan wouldn't
mind:
"You might install NetworkManager-config-server, which drops some
server-type config files into /etc/NetworkManager/conf.d that do
things like ignoring the carrier on all interfaces and ensuring NM
never creates the default DHCP connections that are useful on
desktops. There are other options in there, like making NM stop
touching /etc/resolv.conf if you know you never need to update it.
See "man NetworkManager.conf" for more details on all these
options."
sounds like something we might want?
Very much so. This is something Dan and I talked about at DevConf,
actually. One of the things we'd probably want to do in each of the
various Products is break out our default configurations into a
subpackage that be pulled in by the respective Product release package
as a way to install differing defaults. NetworkManager was the
poster-child for this idea, though I expect there are plenty of other
services that could benefit from this as well.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMGSF0ACgkQeiVVYja6o6NFZgCfVlZDeJAeyVqu7iAC3w8ay/I8
NAMAoINVJv+jaTtwHDUWkDPex+eMOmf5
=qq2z
-----END PGP SIGNATURE-----
7:05 p.m.
On Thu, Feb 20, 2014 at 10:12 AM, Adam Williamson <awilliam(a)redhat.com> wrote:
"You might install NetworkManager-config-server, which drops
some
server-type config files into /etc/NetworkManager/conf.d that do things
like ignoring the carrier on all interfaces and ensuring NM never
creates the default DHCP connections that are useful on desktops. There
are other options in there, like making NM stop
touching /etc/resolv.conf if you know you never need to update it. See
"man NetworkManager.conf" for more details on all these options."
sounds like something we might want?
That's presuming Fedora Server will prefer NetworkManager over the new
systemd v209 network units, which are quickly reaching parity and have
some nice service integration capability.
7:14 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/20/2014 08:05 PM, David Timothy Strauss wrote:
On Thu, Feb 20, 2014 at 10:12 AM, Adam Williamson
<awilliam(a)redhat.com> wrote:
> "You might install NetworkManager-config-server, which drops
> some server-type config files into /etc/NetworkManager/conf.d
> that do things like ignoring the carrier on all interfaces and
> ensuring NM never creates the default DHCP connections that are
> useful on desktops. There are other options in there, like
> making NM stop touching /etc/resolv.conf if you know you never
> need to update it. See "man NetworkManager.conf" for more
> details on all these options."
>
> sounds like something we might want?
That's presuming Fedora Server will prefer NetworkManager over the
new systemd v209 network units, which are quickly reaching parity
and have some nice service integration capability.
For the immediate future, I'd like to say that, yes, Fedora Server
will be supporting NetworkManager. This is in large part due to its
maturity and extremely powerful public D-BUS API. That's not to say
that networkd won't be an option in the future, but at this point in
time, I think we'll probably want to go with the known quantity.
Would you mind going into more detail about why you think we might
want to pick systemd network units, though? Last I had heard
(admittedly a while ago), there were no plans for it to support any of
the more complicated network setups like bridging and multipath, which
are pretty much showstoppers in my mind for a server.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMGqGAACgkQeiVVYja6o6PZDQCfYgn+Y674e5uj++US1gODbNoA
2fwAn0GDH+jn3Ikq7NVvX0uFdizv/Iuc
=W64s
-----END PGP SIGNATURE-----
7:34 p.m.
On Thursday, February 20, 2014 08:14:08 PM Stephen Gallagher wrote:
On 02/20/2014 08:05 PM, David Timothy Strauss wrote:
> On Thu, Feb 20, 2014 at 10:12 AM, Adam Williamson
>
> <awilliam(a)redhat.com> wrote:
>> "You might install NetworkManager-config-server, which drops
>> some server-type config files into /etc/NetworkManager/conf.d
>> that do things like ignoring the carrier on all interfaces and
>> ensuring NM never creates the default DHCP connections that are
>> useful on desktops. There are other options in there, like
>> making NM stop touching /etc/resolv.conf if you know you never
>> need to update it. See "man NetworkManager.conf" for more
>> details on all these options."
>>
>> sounds like something we might want?
>
> That's presuming Fedora Server will prefer NetworkManager over the
> new systemd v209 network units, which are quickly reaching parity
> and have some nice service integration capability.
For the immediate future, I'd like to say that, yes, Fedora Server
will be supporting NetworkManager. This is in large part due to its
maturity and extremely powerful public D-BUS API. That's not to say
that networkd won't be an option in the future, but at this point in
time, I think we'll probably want to go with the known quantity.
Would you mind going into more detail about why you think we might
want to pick systemd network units, though? Last I had heard
(admittedly a while ago), there were no plans for it to support any of
the more complicated network setups like bridging and multipath, which
are pretty much showstoppers in my mind for a server.
According to "[systemd-devel] [ANNOUNCE] systemd 209" [1], it looks like some
of the server-level options are available.
I would also like to see support for this as well.
-A
1. http://lists.freedesktop.org/archives/systemd-devel/2014-February/017146....
--
Anthony - http://messinet.com - http://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
2:29 a.m.
Am 21.02.2014 02:14, schrieb Stephen Gallagher:
Would you mind going into more detail about why you think we might
want to pick systemd network units, though?
because it is more lightweight compared to NM and already
there by sharing code with other services - i know nobody
who is running NM on a server
Last I had heard
(admittedly a while ago), there were no plans for it to support any of
the more complicated network setups like bridging and multipath, which
are pretty much showstoppers in my mind for a server
type systemd-networkd leads to
http://www.freedesktop.org/software/systemd/man/systemd-networkd.service....
DHCP
A boolean. When true, enables basic DHCPv4 support.
Address
A static IPv4 or IPv6 address and its prefix length, separated by a "/"
character. The format of the address
must be as described in inet_pton(3) . This is a short-hand for an [Address] section only
containing an Address key
(see below).
Gateway
The gateway address, which must be in the format described in inet_pton(3) . This is a
short-hand for a [Route]
section only containing a Gateway key.
DNS
A DNS server address, which must be in the format described in inet_pton(3) .
Bridge
The name of the bridge to add the link to.
Bond
The name of the bond to add the link to.
VLAN
The name of a VLAN to create on the link. This option may be specified more than
once.
even that german news article talks about bridges, VLAN and bonding
http://www.heise.de/open/meldung/Init-Plattform-Systemd-regelt-jetzt-Netz...
8 a.m.
Am 21.02.2014 14:29, schrieb Jóhann B. Guðmundsson:
On 02/20/2014 06:12 PM, Adam Williamson wrote:
> sounds like something we might want?
I would say no since systemd networkd is the future for servers.
Network Manager should go away on server installs it never work properly and nobody used
it
i agree here - NM is not the replacement for network.service on servers
it's not needed in case of statical configured network cards and
systemd-networkd promises to be a sane future replacement
http://www.freedesktop.org/software/systemd/man/systemd-networkd.service....
it's also work to migrate network.service configurations dealing with
brdiges, VPN, routings and so on but it's tighter integrated in systemd
which over the long covers the basic operating system besides the kernel
8:11 a.m.
On Fri, Feb 21, 2014 at 8:29 AM, Jóhann B. Guðmundsson
<johannbg(a)gmail.com> wrote:
Network Manager should go away on server installs it never work
properly
and nobody used it
No, you are wrong.
Red Hat Enterprise Linux 7(.0) will default to NetworkManager, and even
if all resources that are presently on NetworkManager were dropped
today and focused on networkd, we'd still need a long ongoing
investment in actively maintaining it both for the ongoing server case
*and* for the client case (GNOME is deeply invested in NM).
8:21 a.m.
Am 21.02.2014 15:11, schrieb Colin Walters:
On Fri, Feb 21, 2014 at 8:29 AM, Jóhann B. Guðmundsson
<johannbg(a)gmail.com> wrote:
> Network Manager should go away on server installs it never work properly and nobody
used it
No, you are wrong.
Red Hat Enterprise Linux 7(.0) will default to NetworkManager, and even if all resources
that are presently on
NetworkManager were dropped today and focused on networkd, we'd still need a long
ongoing investment in actively
maintaining it both for the ongoing server case *and* for the client case (GNOME is
deeply invested in NM)
you missed the "on server installs"
so the question is valid in case we talk about *Fedora server*, F21 is delayed because
Fedora.next / Fedora products and so systemd-209 should not be the target for F21 and
even considered for F20 in it's release cycle after systemd-208 is not that bugfree
that RHEL7 defaults to NM is no argumentation for Fedora
systemd-209 simply was not available for RHEL7 target
the same as systemd was not for RHEL6 which uses hence upstart
8:35 a.m.
On Fri, Feb 21, 2014 at 9:21 AM, Reindl Harald <h.reindl(a)thelounge.net>
wrote:
you missed the "on server installs"
No, I didn't.
that RHEL7 defaults to NM is no argumentation for Fedora
We can pretend they're separate things, but in reality...RHEL7 will act
as a powerful "center of gravity". For new features that will land in
key infrastructure such as libvirt, firewalld, and GNOME, all of these
will need to work with NM. Any development work that is possibly
earmarked for backporting to RHEL7 will need to work with NM.
Anyone can drop in, wave their hands and say "networkd is the future" -
but the reality is that the existing OSes and investment in them don't
just disappear when new code is written.
I personally still work on RHEL6 maintenance, even when I'm writing
*brand new* code in say glib, I look at whether it would work on RHEL6,
and take that under consideration.
Even just for servers, networkd would require Anaconda work, libvirt
work, and really some sort of transition code for existing config
files. The benefit would have to be *really good* to be worth the cost
of going back to having two network stacks.
9:13 a.m.
On Fri, 2014-02-21 at 15:21 +0100, Reindl Harald wrote:
Am 21.02.2014 15:11, schrieb Colin Walters:
> On Fri, Feb 21, 2014 at 8:29 AM, Jóhann B. Guðmundsson <johannbg(a)gmail.com>
wrote:
>> Network Manager should go away on server installs it never work properly and
nobody used it
>
> No, you are wrong.
>
> Red Hat Enterprise Linux 7(.0) will default to NetworkManager, and even if all
resources that are presently on
> NetworkManager were dropped today and focused on networkd, we'd still need a
long ongoing investment in actively
> maintaining it both for the ongoing server case *and* for the client case (GNOME is
deeply invested in NM)
you missed the "on server installs"
so the question is valid in case we talk about *Fedora server*, F21 is delayed because
Fedora.next / Fedora products and so systemd-209 should not be the target for F21 and
even considered for F20 in it's release cycle after systemd-208 is not that bugfree
that RHEL7 defaults to NM is no argumentation for Fedora
systemd-209 simply was not available for RHEL7 target
the same as systemd was not for RHEL6 which uses hence upstart
We can look at systemd-networkd in a distant future when it will be
proven to do what a generic server install needs.
However its time is not now.
NM has been enhanced to work in a great many situations, it includes
comprehensive support for all the situations systemd-networkd started
supporting and many more. It has a comprehensive CLI, TUI and even GUI
interface for administration that is completely lacking in systemd and
it has been tested and improved for a long time.
It can be easily integrated with things like cockpit as it offers a
broad dbus API.
People are working on getting deep integration so that NM can provide
out of the box DNSSEC support for the whole system too (try to install
dnssec-trigger on your F20 machine now to get a taste of it).
Etc, etc...
I do not think systemd will reach that level of functionality (and
probably never should, it makes no sense to duplicate all this work).
Systemd-networkd will probably be usable in some specialized cases (like
getting network in network boot systems or other well defined and
confined situations) but is not a general purpose network management
tool now, so it shouldn't be our default choice at the moment.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
11:57 a.m.
On Fri, 2014-02-21 at 15:21 +0100, Reindl Harald wrote:
Am 21.02.2014 15:11, schrieb Colin Walters:
> On Fri, Feb 21, 2014 at 8:29 AM, Jóhann B. Guðmundsson <johannbg(a)gmail.com>
wrote:
>> Network Manager should go away on server installs it never work properly and
nobody used it
>
> No, you are wrong.
>
> Red Hat Enterprise Linux 7(.0) will default to NetworkManager, and even if all
resources that are presently on
> NetworkManager were dropped today and focused on networkd, we'd still need a
long ongoing investment in actively
> maintaining it both for the ongoing server case *and* for the client case (GNOME is
deeply invested in NM)
you missed the "on server installs"
so the question is valid in case we talk about *Fedora server*, F21 is delayed because
Fedora.next / Fedora products and so systemd-209 should not be the target for F21 and
even considered for F20 in it's release cycle after systemd-208 is not that bugfree
that RHEL7 defaults to NM is no argumentation for Fedora
systemd-209 simply was not available for RHEL7 target
the same as systemd was not for RHEL6 which uses hence upstart
It's taken, what, 7-8 Fedora cycles, 3-4 years, and one entire RHEL
cycle for NetworkManager to be in a state where RH considers it
acceptable as a default for RHEL 7.
Why are we assuming systemd-networkd shows up and will be good enough
for us overnight? Has anyone who's saying it's The Future and we should
switch to it immediately even run it yet?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
12:06 p.m.
Am 21.02.2014 18:57, schrieb Adam Williamson:
On Fri, 2014-02-21 at 15:21 +0100, Reindl Harald wrote:
>
> Am 21.02.2014 15:11, schrieb Colin Walters:
>> On Fri, Feb 21, 2014 at 8:29 AM, Jóhann B. Guðmundsson <johannbg(a)gmail.com>
wrote:
>>> Network Manager should go away on server installs it never work properly and
nobody used it
>>
>> No, you are wrong.
>>
>> Red Hat Enterprise Linux 7(.0) will default to NetworkManager, and even if all
resources that are presently on
>> NetworkManager were dropped today and focused on networkd, we'd still need a
long ongoing investment in actively
>> maintaining it both for the ongoing server case *and* for the client case (GNOME
is deeply invested in NM)
>
> you missed the "on server installs"
>
> so the question is valid in case we talk about *Fedora server*, F21 is delayed
because
> Fedora.next / Fedora products and so systemd-209 should not be the target for F21
and
> even considered for F20 in it's release cycle after systemd-208 is not that
bugfree
>
> that RHEL7 defaults to NM is no argumentation for Fedora
> systemd-209 simply was not available for RHEL7 target
> the same as systemd was not for RHEL6 which uses hence upstart
It's taken, what, 7-8 Fedora cycles, 3-4 years, and one entire RHEL
cycle for NetworkManager to be in a state where RH considers it
acceptable as a default for RHEL 7.
fine - and that is why RHEL is irrelevant in the context
Why are we assuming systemd-networkd shows up and will be good
enough
for us overnight?
why not?
* nobody is porting "network.service" to a systemd-unit
* NM is a no-go for most people on servers i know (except Simon)
Has anyone who's saying it's The Future and we should
switch to it immediately even run it yet?
dow w ehave a systemd-209 somewhere
frankly i can't await to start testing systemd-networkd and get rid of
systemd-208 on Fedora, things can only get better like with systemd-208
12:09 p.m.
On Fri, 2014-02-21 at 19:06 +0100, Reindl Harald wrote:
> It's taken, what, 7-8 Fedora cycles, 3-4 years, and one
entire RHEL
> cycle for NetworkManager to be in a state where RH considers it
> acceptable as a default for RHEL 7.
fine - and that is why RHEL is irrelevant in the context
I don't see how that follows.
> Why are we assuming systemd-networkd shows up and will be good
enough
> for us overnight?
why not?
Er................are you serious?
I don't tend to deploy software on my servers because I'm just guessing
it'll work.
* nobody is porting "network.service" to a systemd-unit
* NM is a no-go for most people on servers i know (except Simon)
I'd run it on mine if I was deploying them today. It's a lot better than
it used to be for server use. Which makes sense, because its initial
design focus was desktop use, and once that was in good shape, server
side was worked on.
> Has anyone who's saying it's The Future and we should
> switch to it immediately even run it yet?
dow w ehave a systemd-209 somewhere
http://koji.fedoraproject.org/koji/buildinfo?buildID=499417 - build
failed on ARM. But if you haven't even built it locally and tried it
yet...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
12:16 p.m.
Am 21.02.2014 19:09, schrieb Adam Williamson:
On Fri, 2014-02-21 at 19:06 +0100, Reindl Harald wrote:
> do we have a systemd-209 somewhere
http://koji.fedoraproject.org/koji/buildinfo?buildID=499417 - build
failed on ARM. But if you haven't even built it locally and tried it
yet...
that's not the point
* currently nobody knows details but many have qualified guesses
* systemd replaced much complexer things than network.service
* on 99 out of 100 servers you don't want more than network.service
* on 99 out of 100 servers you don't want the NM dependency-chain
* you have all the systemd code already in the system
* you can expect systemd controls systemd-networkd.service better than
the old fashinoed LSB network.service i expect it to work relieable
* we are talking about *future*
so you won't get people like me in a direction to accept NM at all
well, we had to suck systemd in F15 and survived
so *now* that we survived we want to have it finished
have systemd finished means no LSB/SysV-Init service on the system
the payback have NM instead network.service is not accepted
guess what happens the next few years
people running Fedora on static network interfaces and hate
NetworkManager as much someone can hate software will use it
anyways - the same people would even write there own ifup
systemd-units if "network.service" would get dropped without
a replacement which is not NM
12:36 p.m.
On Fri, 2014-02-21 at 19:16 +0100, Reindl Harald wrote:
Am 21.02.2014 19:09, schrieb Adam Williamson:
> On Fri, 2014-02-21 at 19:06 +0100, Reindl Harald wrote:
>> do we have a systemd-209 somewhere
>
> http://koji.fedoraproject.org/koji/buildinfo?buildID=499417 - build
> failed on ARM. But if you haven't even built it locally and tried it
> yet...
that's not the point
* currently nobody knows details but many have qualified guesses
* systemd replaced much complexer things than network.service
* on 99 out of 100 servers you don't want more than network.service
* on 99 out of 100 servers you don't want the NM dependency-chain
* you have all the systemd code already in the system
* you can expect systemd controls systemd-networkd.service better than
the old fashinoed LSB network.service i expect it to work relieable
* we are talking about *future*
so you won't get people like me in a direction to accept NM at all
well, we had to suck systemd in F15 and survived
so *now* that we survived we want to have it finished
have systemd finished means no LSB/SysV-Init service on the system
the payback have NM instead network.service is not accepted
Let me correct you here, *you* do not accept it, and that is fine, you
can configure your system to use systemd-networkd, report on how it
works and in due time we can consider it to become a default for Fedora
Server.
but At *this* moment you do not even know if it will really work or not,
because it can't even be compiled for Fedora, so let's table for more
discussion in a 3 months or so, ok ?
guess what happens the next few years
I do not have crystal balls.
people running Fedora on static network interfaces and hate
NetworkManager as much someone can hate software will use it
anyways - the same people would even write there own ifup
systemd-units if "network.service" would get dropped without
a replacement which is not NM
This is the same argument people had against systemd.
People will hate it and won't know how to work w/o sysv.
Sorry I do not care for fear mongering, thank you.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
12:48 p.m.
Am 21.02.2014 19:36, schrieb Simo Sorce:
On Fri, 2014-02-21 at 19:16 +0100, Reindl Harald wrote:
>
> Am 21.02.2014 19:09, schrieb Adam Williamson:
>> On Fri, 2014-02-21 at 19:06 +0100, Reindl Harald wrote:
>>> do we have a systemd-209 somewhere
>>
>> http://koji.fedoraproject.org/koji/buildinfo?buildID=499417 - build
>> failed on ARM. But if you haven't even built it locally and tried it
>> yet...
>
> that's not the point
>
> * currently nobody knows details but many have qualified guesses
> * systemd replaced much complexer things than network.service
> * on 99 out of 100 servers you don't want more than network.service
> * on 99 out of 100 servers you don't want the NM dependency-chain
> * you have all the systemd code already in the system
> * you can expect systemd controls systemd-networkd.service better than
> the old fashinoed LSB network.service i expect it to work relieable
> * we are talking about *future*
>
> so you won't get people like me in a direction to accept NM at all
> well, we had to suck systemd in F15 and survived
> so *now* that we survived we want to have it finished
> have systemd finished means no LSB/SysV-Init service on the system
> the payback have NM instead network.service is not accepted
Let me correct you here, *you* do not accept it
not only i, but skip that details because it leads to a flamewar
but At *this* moment you do not even know if it will really work or
not,
because it can't even be compiled for Fedora
so let's table for more discussion in a 3 months or so, ok ?
agreed
> guess what happens the next few years
I do not have crystal balls
in that context i do - NM will not be accepted for people
satisfied with a simple "ifcfg-eth0" the past, currently
and in the future
> people running Fedora on static network interfaces and hate
> NetworkManager as much someone can hate software will use it
> anyways - the same people would even write there own ifup
> systemd-units if "network.service" would get dropped without
> a replacement which is not NM
This is the same argument people had against systemd.
People will hate it and won't know how to work w/o sysv.
the difference is that from F15 on it was *impossible* to stay
at SysvInit, otherwise i would have started use it with F16/F17
but given that that time back Fedora had outdated kernels not
supporting the onobrad-NIC of sandy-bridge machines at all and
the display froze all day long you needed to upgrade a fresh
installed F14 to F15 wihtout any choice
Sorry I do not care for fear mongering, thank you
there is no fear
we need a lightweight replacement for network.service
maybe not now but in the to so far future and before someone claims
"network.service is no nolger maintained hust use NM"
8:06 a.m.
On Fri, Feb 21, 2014 at 07:16:54PM +0100, Reindl Harald wrote:
* systemd replaced much complexer things than network.service
Don't underestimate the complexity of the network startup scripts. There are
a lot of edge cases and weird conditions encoded the years of cruft that has
built up around the shell scripts and surely in networkmanager as well. I'm
sure networkd will handle the simple cases nicely, but experience indicates
that it'll be several years before all of the non-obvious problems get
ironed out -- things which looked trivial to deal with in the rewrite but
which actually have a gotcha.
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
8:08 a.m.
Am 24.02.2014 15:06, schrieb Matthew Miller:
On Fri, Feb 21, 2014 at 07:16:54PM +0100, Reindl Harald wrote:
> * systemd replaced much complexer things than network.service
Don't underestimate the complexity of the network startup scripts. There are
a lot of edge cases and weird conditions encoded the years of cruft that has
built up around the shell scripts and surely in networkmanager as well. I'm
sure networkd will handle the simple cases nicely, but experience indicates
that it'll be several years before all of the non-obvious problems get
ironed out -- things which looked trivial to deal with in the rewrite but
which actually have a gotcha
i did not said anything else
but to replace network.service on machines with one or two interface
and a static IP on them with no further magic it's the more lightweight
one than NetworkManager
9 a.m.
On 02/21/2014 02:11 PM, Colin Walters wrote:
On Fri, Feb 21, 2014 at 8:29 AM, Jóhann B. Guðmundsson
<johannbg(a)gmail.com> wrote:
> Network Manager should go away on server installs it never work
> properly and nobody used it
No, you are wrong.
Red Hat Enterprise Linux 7(.0) will default to NetworkManager
This is Fedora not RHEL
JBG
9:16 a.m.
On Fri, 2014-02-21 at 15:00 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 02:11 PM, Colin Walters wrote:
> On Fri, Feb 21, 2014 at 8:29 AM, Jóhann B. Guðmundsson
> <johannbg(a)gmail.com> wrote:
>> Network Manager should go away on server installs it never work
>> properly and nobody used it
>
> No, you are wrong.
>
> Red Hat Enterprise Linux 7(.0) will default to NetworkManager
This is Fedora not RHEL
What Colin meant is that because of RHEL the NetworkManager team has
done a lot of work for the Server case and NM is currently in a better
position to be used for Servers.
It has a funded team to work on it and to care for Server specific
cases.
The systemd-networkd support, at the moment, is a limited tool for some
special cases and arguably should remain just that.
So at the moment NM is the best technical choice for us too.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
9:19 a.m.
On 02/21/2014 03:16 PM, Simo Sorce wrote:
What Colin meant is that because of RHEL the NetworkManager team has
done a lot of work for the Server case and NM is currently in a better
position to be used for Servers.
No it's not
It has a funded team to work on it and to care for Server specific
cases.
Irrelevant to Fedora and perhaps RH should start re-allocating resources
to networkd
The systemd-networkd support, at the moment, is a limited tool for some
special cases and arguably should remain just that.
So at the moment NM is the best technical choice for us too.
I thought the .next and wg effort was aiming for the "future" not basing
itself on to be obsoleted technology.
Networkd is going to be providing the network infrastructure for
embedded/server
JBG
9:33 a.m.
On Fri, 2014-02-21 at 15:19 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 03:16 PM, Simo Sorce wrote:
> What Colin meant is that because of RHEL the NetworkManager team has
> done a lot of work for the Server case and NM is currently in a better
> position to be used for Servers.
No it's not
Without qualification I will treat this statement as meaningless and
ignore it.
> It has a funded team to work on it and to care for Server
specific
> cases.
Irrelevant to Fedora and perhaps RH should start re-allocating resources
to networkd
It is very relevant to Fedora which upstream projects are funded and for
what work, because Fedora does not do very much Upstream work, it is a
downstream from this POV.
I appreciate you like systemd-networkd however *that* doesn't matter.
Right now NM is a better technical choice.
> The systemd-networkd support, at the moment, is a limited tool
for some
> special cases and arguably should remain just that.
>
> So at the moment NM is the best technical choice for us too.
I thought the .next and wg effort was aiming for the "future" not basing
itself on to be obsoleted technology.
Well before you declare NM as "obsolete" you need to prove that it is.
Networkd is going to be providing the network infrastructure for
embedded/server
at the moment Networkd can be classified as "immature", so it can be the
basis for a Fedora Server. Once that situation will change we can
certainly revisit this.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
9:57 a.m.
On 02/21/2014 03:33 PM, Simo Sorce wrote:
On Fri, 2014-02-21 at 15:19 +0000, "Jóhann B. Guðmundsson"
wrote:
> On 02/21/2014 03:16 PM, Simo Sorce wrote:
>> It has a funded team to work on it and to care for Server specific
>> cases.
> Irrelevant to Fedora and perhaps RH should start re-allocating resources
> to networkd
It is very relevant to Fedora which upstream projects are funded and for
what work, because Fedora does not do very much Upstream work, it is a
downstream from this POV.
Care to clarify that statement as in how is this more relevant to Fedora
as opposed to any other downstreams that package and ship NM and any
other project for that matter.
I appreciate you like systemd-networkd however *that* doesn't matter.
Right now NM is a better technical choice.
>> The systemd-networkd support, at the moment, is a limited tool for some
>> special cases and arguably should remain just that.
>>
>> So at the moment NM is the best technical choice for us too.
>
> I thought the .next and wg effort was aiming for the "future" not basing
> itself on to be obsoleted technology.
Well before you declare NM as "obsolete" you need to prove that it is.
Like is being done with openlmi and cockpit compared to everything that
exist out there.
> Networkd is going to be providing the network infrastructure for
> embedded/server
at the moment Networkd can be classified as "immature", so it can be the
basis for a Fedora Server. Once that situation will change we can
certainly revisit this.
And openlmi and cockpit are considered being mature?
JBG
10:11 a.m.
On Fri, 2014-02-21 at 15:57 +0000, "Jóhann B. Guðmundsson" wrote:
And openlmi and cockpit are considered being mature?
They're not attempting to replace existing functionality - they're
conceptually addons on top of a core. With Cockpit you are definitely
expected to still use ssh, for example.
10:12 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/21/2014 10:57 AM, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 03:33 PM, Simo Sorce wrote:
> On Fri, 2014-02-21 at 15:19 +0000, "Jóhann B. Guðmundsson"
> wrote:
>> On 02/21/2014 03:16 PM, Simo Sorce wrote:
>>> It has a funded team to work on it and to care for Server
>>> specific cases.
>> Irrelevant to Fedora and perhaps RH should start re-allocating
>> resources to networkd
> It is very relevant to Fedora which upstream projects are funded
> and for what work, because Fedora does not do very much Upstream
> work, it is a downstream from this POV.
Care to clarify that statement as in how is this more relevant to
Fedora as opposed to any other downstreams that package and ship NM
and any other project for that matter.
>
> I appreciate you like systemd-networkd however *that* doesn't
> matter. Right now NM is a better technical choice.
>
>>> The systemd-networkd support, at the moment, is a limited
>>> tool for some special cases and arguably should remain just
>>> that.
>>>
>>> So at the moment NM is the best technical choice for us too.
>>
>> I thought the .next and wg effort was aiming for the "future"
>> not basing itself on to be obsoleted technology.
> Well before you declare NM as "obsolete" you need to prove that
> it is.
Like is being done with openlmi and cockpit compared to everything
that exist out there.
>
>> Networkd is going to be providing the network infrastructure
>> for embedded/server
> at the moment Networkd can be classified as "immature", so it can
> be the basis for a Fedora Server. Once that situation will change
> we can certainly revisit this.
And openlmi and cockpit are considered being mature?
Different layering levels. Cockpit and OpenLMI are technologies that
provide a useful high-level view into the system. If they have bugs or
are broken, there are plenty of low-level fallbacks (such as SSH and
config file mangling) that can take their place. The networking stack
is fundamental plumbing and should therefore be treated with more care.
I'm not against investigating networkd as a future solution for Fedora
Server. I think it has a lot of potential. Unfortunately, right now
it's "immature" in the sense that it doesn't even build in Fedora
because it lacks support on some architectures[1]. That's a
non-starter in my opinion.
[1]
http://lists.freedesktop.org/archives/systemd-devel/2014-February/017146....
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMHewAACgkQeiVVYja6o6MlvQCfW6DzgNgQE/VW5Hmc/INCFzbO
q8gAnA6rl7WNVqthEDf7bgniOtr/iZY7
=xqIy
-----END PGP SIGNATURE-----
10:19 a.m.
On Fri, 2014-02-21 at 15:57 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 03:33 PM, Simo Sorce wrote:
> On Fri, 2014-02-21 at 15:19 +0000, "Jóhann B. Guðmundsson" wrote:
>> On 02/21/2014 03:16 PM, Simo Sorce wrote:
>>> It has a funded team to work on it and to care for Server specific
>>> cases.
>> Irrelevant to Fedora and perhaps RH should start re-allocating resources
>> to networkd
> It is very relevant to Fedora which upstream projects are funded and for
> what work, because Fedora does not do very much Upstream work, it is a
> downstream from this POV.
Care to clarify that statement as in how is this more relevant to Fedora
as opposed to any other downstreams that package and ship NM and any
other project for that matter.
It is as relevant to Fedora as to any other distribution.
*you* said "Irrelevant to Fedora" and I said it is not true, what else
do you need ?
> I appreciate you like systemd-networkd however *that*
doesn't matter.
> Right now NM is a better technical choice.
>
>>> The systemd-networkd support, at the moment, is a limited tool for some
>>> special cases and arguably should remain just that.
>>>
>>> So at the moment NM is the best technical choice for us too.
>>
>> I thought the .next and wg effort was aiming for the "future" not
basing
>> itself on to be obsoleted technology.
> Well before you declare NM as "obsolete" you need to prove that it is.
Like is being done with openlmi and cockpit compared to everything that
exist out there.
I do not understand this statement, but it sounds like a strawman, so I
will just ignore it for now.
>> Networkd is going to be providing the network infrastructure
for
>> embedded/server
> at the moment Networkd can be classified as "immature", so it can be the
> basis for a Fedora Server. Once that situation will change we can
> certainly revisit this.
And openlmi and cockpit are considered being mature?
Irrelevant strawman, nobody is proposing to use openlmi or cockpit to
replace working, mature, available software.
Please stick to valid arguments or avoid trolling (yes I said trolling,
this last paragraph clearly is, as it draws in stuff that has nothing to
do with the conversation at hand).
Simo.
--
Simo Sorce * Red Hat, Inc * New York
10:47 a.m.
On 02/21/2014 04:19 PM, Simo Sorce wrote:
Irrelevant strawman, nobody is proposing to use openlmi or cockpit
to
replace working, mature, available software.
Relevant in the way that you dont need NM to configure "enterprise" (
bridging/bonding etc ) networking so maturity in NM is irrelevant I
would say.
JBG
11:01 a.m.
On Fri, 2014-02-21 at 16:47 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 04:19 PM, Simo Sorce wrote:
> Irrelevant strawman, nobody is proposing to use openlmi or cockpit to
> replace working, mature, available software.
Relevant in the way that you dont need NM to configure "enterprise" (
bridging/bonding etc ) networking so maturity in NM is irrelevant I
would say.
Ok, can you tell me how do you configure Team Bonding or IP over
Infiniband with systemd-networkd ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
12:08 p.m.
On 02/21/2014 05:01 PM, Simo Sorce wrote:
On Fri, 2014-02-21 at 16:47 +0000, "Jóhann B. Guðmundsson"
wrote:
> On 02/21/2014 04:19 PM, Simo Sorce wrote:
>> Irrelevant strawman, nobody is proposing to use openlmi or cockpit to
>> replace working, mature, available software.
> Relevant in the way that you dont need NM to configure "enterprise" (
> bridging/bonding etc ) networking so maturity in NM is irrelevant I
> would say.
Ok, can you tell me how do you configure Team Bonding or IP over
Infiniband with systemd-networkd ?
systemd-networkd supports configuring local network interfaces
statically or via DHCP as well as being capable of bringing up bridges,
VLANs, and bonding if that's what you are wondering and you configure
those by creating .netdev file and define which you want with kind= as in
foo.netdev
[NetDev]
Name=$bar
Kind=bond/bridge/vlan
Then you go about creating relevant related .link and .network units
just watch out that it wont collide with ethXYZ namespace used by the kernel
IPoIB is not supported at this moment and you did not need NM to do that
anyway just like the rest so...
JBG
12:33 p.m.
On Fri, 2014-02-21 at 18:08 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 05:01 PM, Simo Sorce wrote:
> On Fri, 2014-02-21 at 16:47 +0000, "Jóhann B. Guðmundsson" wrote:
>> On 02/21/2014 04:19 PM, Simo Sorce wrote:
>>> Irrelevant strawman, nobody is proposing to use openlmi or cockpit to
>>> replace working, mature, available software.
>> Relevant in the way that you dont need NM to configure "enterprise" (
>> bridging/bonding etc ) networking so maturity in NM is irrelevant I
>> would say.
> Ok, can you tell me how do you configure Team Bonding or IP over
> Infiniband with systemd-networkd ?
systemd-networkd supports configuring local network interfaces
statically or via DHCP as well as being capable of bringing up bridges,
VLANs, and bonding if that's what you are wondering and you configure
those by creating .netdev file and define which you want with kind= as in
foo.netdev
[NetDev]
Name=$bar
Kind=bond/bridge/vlan
Then you go about creating relevant related .link and .network units
just watch out that it wont collide with ethXYZ namespace used by the kernel
IPoIB is not supported at this moment and you did not need NM to do that
anyway just like the rest so...
Ok so your answer boils down to:
"I do not know how to do that, but here is a blurb taken from the
general FAQ about how to configure something (but not what was asked)."
This is apparently sufficient to declare systemd-networkd done and ready
for Fedora Server ... OK!
Excuse me if I am a bit skeptical, and will ignore further arguments on
this for the time being.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
1:29 p.m.
On Fri, 2014-02-21 at 19:04 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 06:33 PM, Simo Sorce wrote:
> Ok so your answer boils down to:
> "I do not know how to do that, but here is a blurb taken from the
> general FAQ about how to configure something (but not what was asked)."
You are one piece of work when someone responds to you.
I guess I'll take that as a compliment.
Thanks you :-)
Simo.
--
Simo Sorce * Red Hat, Inc * New York
1:33 p.m.
On 02/21/2014 07:29 PM, Simo Sorce wrote:
On Fri, 2014-02-21 at 19:04 +0000, "Jóhann B. Guðmundsson"
wrote:
> >On 02/21/2014 06:33 PM, Simo Sorce wrote:
>> > >Ok so your answer boils down to:
>> > >"I do not know how to do that, but here is a blurb taken from the
>> > >general FAQ about how to configure something (but not what was
asked)."
> >
> >You are one piece of work when someone responds to you.
I guess I'll take that as a compliment.
It was not meant as such but you not figuring that out comes of as no
surprise to me :)
JBG
1:38 p.m.
Am 21.02.2014 20:33, schrieb Jóhann B. Guðmundsson:
On 02/21/2014 07:29 PM, Simo Sorce wrote:
> On Fri, 2014-02-21 at 19:04 +0000, "Jóhann B. Guðmundsson" wrote:
>> >On 02/21/2014 06:33 PM, Simo Sorce wrote:
>>> > >Ok so your answer boils down to:
>>> > >"I do not know how to do that, but here is a blurb taken from
the
>>> > >general FAQ about how to configure something (but not what was
asked)."
>> >
>> >You are one piece of work when someone responds to you.
> I guess I'll take that as a compliment.
It was not meant as such but you not figuring that out comes of as no surprise to me :)
please stop that
thank you!
1:38 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri 21 Feb 2014 02:33:57 PM EST, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 07:29 PM, Simo Sorce wrote:
> On Fri, 2014-02-21 at 19:04 +0000, "Jóhann B. Guðmundsson"
> wrote:
>>> On 02/21/2014 06:33 PM, Simo Sorce wrote:
>>>>> Ok so your answer boils down to: "I do not know how to do
>>>>> that, but here is a blurb taken from the general FAQ
>>>>> about how to configure something (but not what was
>>> asked)."
>>>
>>> You are one piece of work when someone responds to you.
> I guess I'll take that as a compliment.
It was not meant as such but you not figuring that out comes of as
no surprise to me :)
This branch of the thread is closed.
I remind people to please consult
http://fedoraproject.org/code-of-conduct before posting.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMHq1EACgkQeiVVYja6o6O2KwCgrIKVuc851srOzMoRtzNogiVw
yPUAn2itTjj2Sc2Coi8zMh/wXMdkB65y
=T4TO
-----END PGP SIGNATURE-----
9:26 a.m.
On Fri, 2014-02-21 at 15:00 +0000, "Jóhann B. Guðmundsson" wrote:
This is Fedora not RHEL
Since Fedora is the upstream for Red Hat Enterprise Linux, there needs
to be a mechanism by which feedback can be provided from downstream to
upstream.
I am using this mailing list as that mechanism.
9:25 a.m.
On 02/21/2014 03:26 PM, Colin Walters wrote:
On Fri, 2014-02-21 at 15:00 +0000, "Jóhann B. Guðmundsson"
wrote:
> This is Fedora not RHEL
Since Fedora is the upstream for Red Hat Enterprise Linux, there needs
to be a mechanism by which feedback can be provided from downstream to
upstream.
I am using this mailing list as that mechanism.
RHEL and it's needs should not dictate and decide the direction of
Fedora and as soon as it does Fedora stops being "sponsored" project...
JBG
9:34 a.m.
Hi Jóhann,
On Fri, 2014-02-21 at 15:25 +0000, "Jóhann B. Guðmundsson" wrote:
RHEL and it's needs should not dictate and decide the direction
of
Fedora and as soon as it does Fedora stops being "sponsored" project...
I think an objective read of my communication thus far would show that I
personally am not trying to dictate and decide (or am I seeing anyone
else do so) but to have a *conversation*.
You can't seriously have expected to be able to drop in and say
"networkd is the future!" and have everyone nod their head silently...
Networking is a very complex topic.
Did you know for example that Microsoft has done some research on using
wireless in data centers? Yes, really:
http://research.microsoft.com/pubs/157700/flyways_sigcomm11.pdf
10 a.m.
On 02/21/2014 03:34 PM, Colin Walters wrote:
You can't seriously have expected to be able to drop in and say
"networkd is the future!" and have everyone nod their head silently...
Networking is a very complex topic.
Does not change the fact that networkd is replacing the legacy network
initscript and it's purpose as well as few things else so networkd is
the future and shipping multiple networking solution for
embedded/servers/cloud/containers makes no sense.
I would not be surprised that networkd will be ready enough for
replacement in F22
JBG
10:09 a.m.
On Fri, 2014-02-21 at 16:00 +0000, "Jóhann B. Guðmundsson" wrote:
I would not be surprised that networkd will be ready enough for
replacement in F22
If you're saying the goal is for networkd to kill off network.service
entirely - then I'm definitely in favor of that. I think that's only
realistic though if there were a parser for the old RH ifconfig files to
translate to networkd.
Anyways, there are other sides to this discussion - I'm very hopeful
that the DHCP client library work inside networkd can be reused by
NetworkManager for example.
But do also expect some cool stuff from the NM side - for example, the
kdbus work should allow it to finally exit when unused if you just have
say a static IP, without race conditions.
8:08 a.m.
On Fri, Feb 21, 2014 at 11:09:47AM -0500, Colin Walters wrote:
But do also expect some cool stuff from the NM side - for example,
the
kdbus work should allow it to finally exit when unused if you just have
say a static IP, without race conditions.
And I will be very happy. https://bugzilla.redhat.com/show_bug.cgi?id=863515
:)
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
10:16 a.m.
On Fri, 2014-02-21 at 16:00 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 03:34 PM, Colin Walters wrote:
> You can't seriously have expected to be able to drop in and say
> "networkd is the future!" and have everyone nod their head silently...
> Networking is a very complex topic.
Does not change the fact that networkd is replacing the legacy network
initscript and it's purpose as well as few things else so networkd is
the future and shipping multiple networking solution for
embedded/servers/cloud/containers makes no sense.
I would not be surprised that networkd will be ready enough for
replacement in F22
Maybe you should go and check what NM can do today before writing it off
or before thinking systemd-networkd will be mature in the short term.
There is a very good reason why it took time for NM to become really
usable on servers, and that's because exotic network configurations are
fiendishly difficult to describe and manage.
And the exotic configurations are found on servers.
So by all means, let's watch what happens with systemd-networkd, but at
the moment it is not something I would base my work on.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
10:36 a.m.
Am 21.02.2014 17:16, schrieb Simo Sorce:
On Fri, 2014-02-21 at 16:00 +0000, "Jóhann B. Guðmundsson"
wrote:
> On 02/21/2014 03:34 PM, Colin Walters wrote:
>> You can't seriously have expected to be able to drop in and say
>> "networkd is the future!" and have everyone nod their head silently...
>> Networking is a very complex topic.
>
> Does not change the fact that networkd is replacing the legacy network
> initscript and it's purpose as well as few things else so networkd is
> the future and shipping multiple networking solution for
> embedded/servers/cloud/containers makes no sense.
>
> I would not be surprised that networkd will be ready enough for
> replacement in F22
Maybe you should go and check what NM can do today before writing it off
or before thinking systemd-networkd will be mature in the short term
nobody said replace NM everywhere
* replace network.service is the topic
* nobody i know is using NM on servers
* they all continue to use LSB network.service for good reasons
you do not need a complex software like NM on a server with one
or two static configured ethernet cards and nothing else
________________________________________________
go away with all that dependencies on my servers
Installing:
NetworkManager
Installing for dependencies:
ModemManager-glib
NetworkManager-glib
avahi-autoipd
libndp
libnl3
ppp
wpa_supplicant
________________________________________________
go away with all the dependencies on my full featured workstation
running BIND as nameserver, hostapd with 2 instances and a own
DHCP server for both, OpenVPN, httpd, dbmail, MariaDB and what not
all or network services, firewalls and routings
Installing:
NetworkManager
Installing for dependencies:
ModemManager-glib
avahi-autoipd
dnsmasq
libndp
ppp
wpa_supplicant
10:51 a.m.
On Fri, 2014-02-21 at 17:36 +0100, Reindl Harald wrote:
Am 21.02.2014 17:16, schrieb Simo Sorce:
> On Fri, 2014-02-21 at 16:00 +0000, "Jóhann B. Guðmundsson" wrote:
>> On 02/21/2014 03:34 PM, Colin Walters wrote:
>>> You can't seriously have expected to be able to drop in and say
>>> "networkd is the future!" and have everyone nod their head
silently...
>>> Networking is a very complex topic.
>>
>> Does not change the fact that networkd is replacing the legacy network
>> initscript and it's purpose as well as few things else so networkd is
>> the future and shipping multiple networking solution for
>> embedded/servers/cloud/containers makes no sense.
>>
>> I would not be surprised that networkd will be ready enough for
>> replacement in F22
>
> Maybe you should go and check what NM can do today before writing it off
> or before thinking systemd-networkd will be mature in the short term
nobody said replace NM everywhere
* replace network.service is the topic
* nobody i know is using NM on servers
Hello my name is Simo.
Now you know someone who does :)
* they all continue to use LSB network.service for good reasons
you do not need a complex software like NM on a server with one
or two static configured ethernet cards and nothing else
________________________________________________
go away with all that dependencies on my servers
Installing:
NetworkManager
Installing for dependencies:
ModemManager-glib
NetworkManager-glib
avahi-autoipd
libndp
libnl3
ppp
wpa_supplicant
________________________________________________
go away with all the dependencies on my full featured workstation
running BIND as nameserver, hostapd with 2 instances and a own
DHCP server for both, OpenVPN, httpd, dbmail, MariaDB and what not
all or network services, firewalls and routings
Installing:
NetworkManager
Installing for dependencies:
ModemManager-glib
avahi-autoipd
dnsmasq
libndp
ppp
wpa_supplicant
We can look into whether these dependencies are excessive or not,
orwhether they can be made conditional instead of hard, for the people
that want minimal installs.
I do not think this is necessarily a bit problem.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
3711
days inactive
3716
days old
server@lists.fedoraproject.org
47 comments
9 participants
participants (9)
-
Adam Williamson -
Anthony Joseph Messina -
Colin Walters -
David Timothy Strauss -
Jóhann B. Guðmundsson -
Matthew Miller -
Reindl Harald -
Simo Sorce -
Stephen Gallagher