Re: Minimal install diff from F16 to F19 (TC6)

[Davide Bolcioni]

On Monday, June 24, 2013 11:15:11 AM Glen Turner wrote:
> ...
>
> What we don't want is a scenario where configuring these protocols on
> servers has to be done by network engineers. We want them configured from
> a GUI and supervised by a master daemon. Let's call that "NetworkManager".

Suggestion: rip off all logic from said GUI and make it just a dumb shell on 
top of a family of binaries, each packaged separately, which it invokes as 
dictated by mouse clicks. The goal is to make said GUI expendable with no loss 
of functionality, and have multiple independent GUIs which cannot conflict. 
Same for the daemon, even more so, as the GUI exits when it is done but the 
daemon is always around so it has to be worth it.

This way, who has a use case for the GUI and/or daemon installs them, the 
others do not. Everybody is happy.

For example, desktops would almost surely install the GUI, while large scale 
deployments would hate having to use the GUI for anything. On the other hand 
some scenarios, such as simple home networks or stable enterprise setups, 
would have no use for the daemon.

Plus, you can write the binaries in a resource thrifty language, the daemon in 
a easily maintained language and the GUI each in its own language, toolkit or 
whatever. You could also introduce agents for distributed management, they 
would look like GUIs or daemons to the underlying layers. Oops, I said that.

Davide Bolcioni
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Davide Bolcioni]

On Thursday, June 20, 2013 02:38:37 PM Colin Walters wrote:
> On Thu, 2013-06-20 at 13:15 -0500, Chris Adams wrote:
> > I think most "traditional" system admins see a running NM daemon as an
> > additional point of failure in a static network.  If my server's network
> > setup is static, I don't want a daemon running attempting to "manage"
> > it.  If it has a bug, gets misconfigured, etc., it might do something to
> > screw up an otherwise working setup.
> 
> Yes, it's just not easy to do without creating race conditions.  Various
> other components use NetworkManager as an API, and if just called exit()
> arbitrarily it'd introduce the problems described here:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=11454
> 
> This point has been raised repeatedly, the developers are aware that
> it'd be nicer for NM to not show up in "ps" in these situations, but the
> reason it's not done is it's nontrivial and there are a lot of other
> things in the priority queue.

Maybe split off all functionality from the dbus daemon into separate binaries 
(off the top of 
my head, about a dozen, each in a separate package) and the dbus daemon uses 
system() to 
invoke the appropriate one when requested. Servers would just dispense with the 
daemon 
and invoke binaries directly in a startup script.

Davide Bolcioni
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Dan Williams]

On Sat, 2013-06-22 at 17:07 +0200, Till Maas wrote:
> On Fri, Jun 21, 2013 at 12:09:57PM -0500, Dan Williams wrote:
> 
> > > On the other hand, having NetworkManager available all the time enables 
> > > things like management tools to use its API to query system status, 
> > > instead of guessing it from kernel information and heuristic analysis of 
> > > some files under /etc.
> > 
> > Exactly.  And that's why we want to enhance NetworkManager to make
> > people *want* to use it instead of turning it off.
> 
> Features I am missing are:
> 
> - A possibility to make NM ignore an interface from the management
>   tools, which would allow to normally use NM but disable it if one
>   wants to configure a device on the command line. Having to disable
>   interfaces from /etc/sysconfig to be able to use them without NM
>   interfering makes it more cumbersome to use NM at all.

Instead of the previous "unmanaging" of interfaces, future NM will
simply handle changes made underneath it with /sbin/ip or anything else
by listening to kernel notifications.

> - Support NM not interfering with Wi-Fi attack tools such as
>   aircrack-ng, which might only be possible by ignoring the device
>   completely or by adding support to change devices into monitor mode
>   and select static of changing frequencies etc. Probably the features
>   airmon-ng provides would be necessary.

While not very smooth experience, NM will ignore them if you kill
wpa_supplicant.

> - Allow to create tun/tap devices, especially persisted ones with
>   permissions for users

Support for externally created tun/tap/gre/macvlan/macvtap/veth was
added last month, and if you have an ifcfg file with the interface's
name, NM can apply/clear the IP configuration on your command.  At some
point in the near future NM will be able to create all these too.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Glen Turner]

On 24/06/2013, at 9:00 PM, Chris Adams wrote:

> Once upon a time, Glen Turner said:
>> What we don't want is a scenario where configuring these protocols on 
>> servers has to be done by network engineers. We want them configured from a 
>> GUI and supervised by a master daemon. Let's call that "NetworkManager".
> 
> You think hundreds of servers (with untold numbers of VMs), or any
> complicated networking setups, are going to each have their network
> configuration managed by a GUI?

In that case I think the sysadmin will do what they do now. Run the GUI on 
their development box, look at the underlying NetworkManager configuration 
files it created, generalise them, and then farm them out using puppet.

What I am arguing against is the current situation where a server administrator 
has to configure each element of a network configuration, in one configuration 
file per protocol. It's bad enough as it is now, without data centre networking 
exploding the number of protocols seen by a VM host. The router experience has 
been that per-protocol configuration is a dead end. The lesson appears to be 
that it is better to deploy software which directly addresses use-cases (thus 
explaining some of the hype around OpenFlow). I see NetworkManager as the best 
tool to do that job on Linux.

To deploy a new network service you deploy the NetworkManager plugin, its 
dependencies, and a lightweight configuration file written by the NM GUI. I'd 
hope for a plugin ecosystem, since the number of use cases, and the variations 
on those, is pretty large.

With a use-case approach rather than a protocol configuration approach junior 
sysadmins don't also need to be network engineers in order to deploy networking 
features -- ranging from a protocol nightmare like MPLS-based data centre 
networking; to anycast networking for DNS; to IPVS and HA failover. This sort 
of mechanism also gives the opportunity to promote good practices which aren't 
done because they are too hard: such as placing management traffic in a 
preferenced tc class which will allow device management connectivity during a 
DoS, or running LLDP on physical interfaces to allow simple discovery of 
cabling mistakes; from the sysadmins point of view they just enable those 
plugins. Note that these are runtime plugins -- not configuration-time 
"wizards" -- if you have multiple plugins requiring the services of the BGP 
protocol then they should both succeed.

-glen

-- 
  Glen Turner 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Matthew Miller]

On Mon, Jun 24, 2013 at 04:05:35PM +0200, Nicolas Mailhot wrote:
> > The situation I described above is a feature, not a side-effect.> 
> It's a feature for the cloud infra provider. It's an antifeature for
> everyone else. There is value in providing more features infra-side. There
> is no value in restricting functionnalities vm-side to favor the infra.

Having managed reasonably large and complicated server infrastructures in
reasonably large and complicated network environments, running on both real
hardware and in virtual machines, I very much disagree. Sure, there are
corner cases where you want more flexibility, but for the majority, the
encapsulation of complexity is absolutely a good thing.



-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Reindl Harald]

Am 24.06.2013 13:08, schrieb Matthew Miller:
> On Mon, Jun 24, 2013 at 11:15:11AM +0930, Glen Turner wrote:
>> Sun's tagline of "the network is the computer" was true. But for servers
>> these days "the computer is the network" is also the case. It's nothing
>> for a server today to statically NAT or bridge IPv4 to VMs. Even in that
>> case it's best if the guest VM picks up its IPv4 addressing using DHCP.
>>
>> But in the future we'll want to do better than that: to move network
>> routing onto the server itself. These new "data centre ethernet" protocols
>> are not entirely implemented in kernel space. Some run quite complex BGP
>> and MPLS control planes; others run IS-IS control planes.
> 
> So, the converse is that as actual workloads move to VMs (let alone cloud),
> the host systems become a special case, and the "normal" case for a server
> tends to become much more simple: either a single interface probably with
> fixed-address DHCP, or in most complicated cases several interfaces on
> specific networks known by convention

yes, and all these setups are more than satisfied with network.service
and do not need more complexity with a running daemon like NM

they are also not affected from the interface-renamings and race-conditions
which are the reson for biosdevname and the new systemd-replacement because
typically in a VM you have even with multiple interfaces the same NIC type
and driver



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Nicolas Mailhot]

Le Lun 24 juin 2013 14:40, Matthew Miller a écrit :

> I'm not sure it's the "same reasoning" because I have no idea how what I
> said relates to replacing the BIOS wiith ESXi, but it's certainly the case
> that VMware has been hugely successful. And part of that success is
> because
> addressing the _problem_ of increased complexity on the individual
> servers.
> The situation I described above is a feature, not a side-effect.

It's a feature for the cloud infra provider. It's an antifeature for
everyone else. There is value in providing more features infra-side. There
is no value in restricting functionnalities vm-side to favor the infra.
The 'everything is a dumb system' vm view is nice on slideware but it does
not describe reality (let alone because some complex network scenarii are
the result of app needs, and there is zero value in shorting the system
layer to make apps talk to the hypervisor directly. If only because the
system layer is also an access control layer).

-- 
Nicolas Mailhot

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Matthew Miller]

On Mon, Jun 24, 2013 at 01:41:16PM +0200, Nicolas Mailhot wrote:
> > So, the converse is that as actual workloads move to VMs (let alone
> > cloud), the host systems become a special case, and the "normal" case
> > for a server tends to become much more simple: either a single interface
> > probably with fixed-address DHCP, or in most complicated cases several
> > interfaces on specific networks known by convention.
> That's a big assumption, just because the hypervisor is more complex does
> not mean vms get simpler (this is the same faulty reasoning that vmware
> made a few years past when it told everyone that esxi would replace bioses
> and systems would be reduced to their simplest expression — read give us
> your money, not to Microsoft or Red Hat). In fact I am quite certain vm
> complexity is a direct factor of management tools maturity, and people
> will continue to deploy the most complex configurations they can, as long
> as the tools let them. No one wants to delegate anything when the problem
> can be solved without delegation.

I'm not sure it's the "same reasoning" because I have no idea how what I
said relates to replacing the BIOS wiith ESXi, but it's certainly the case
that VMware has been hugely successful. And part of that success is because
addressing the _problem_ of increased complexity on the individual servers.
The situation I described above is a feature, not a side-effect.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Matthew Miller]

On Mon, Jun 24, 2013 at 01:22:03PM +0200, Reindl Harald wrote:
> yes, and all these setups are more than satisfied with network.service
> and do not need more complexity with a running daemon like NM

If you'd be interested in packaging and maintaining a network.service that
handles static addressing and DHCP using the configuration in
/etc/system-config/network-scripts, I'd be happy to take a look at it.


-- 
Matthew Miller   mat...@mattdm.org  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Nicolas Mailhot]

Le Lun 24 juin 2013 13:08, Matthew Miller a écrit :

> So, the converse is that as actual workloads move to VMs (let alone
> cloud),
> the host systems become a special case, and the "normal" case for a server
> tends to become much more simple: either a single interface probably with
> fixed-address DHCP, or in most complicated cases several interfaces on
> specific networks known by convention.

That's a big assumption, just because the hypervisor is more complex does
not mean vms get simpler (this is the same faulty reasoning that vmware
made a few years past when it told everyone that esxi would replace bioses
and systems would be reduced to their simplest expression — read give us
your money, not to Microsoft or Red Hat). In fact I am quite certain vm
complexity is a direct factor of management tools maturity, and people
will continue to deploy the most complex configurations they can, as long
as the tools let them. No one wants to delegate anything when the problem
can be solved without delegation.

Regards,

-- 
Nicolas Mailhot

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Emmanuel Seyman]

* Chris Adams [24/06/2013 06:30] :
>
> You think hundreds of servers (with untold numbers of VMs), or any
> complicated networking setups, are going to each have their network
> configuration managed by a GUI?

I believe Glen meant that in the sense "an admin is running a GUI app
on his workstation and the configuration get farmed out to the servers".

Emmanuel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Chris Adams]

Once upon a time, Glen Turner  said:
> What we don't want is a scenario where configuring these protocols on servers 
> has to be done by network engineers. We want them configured from a GUI and 
> supervised by a master daemon. Let's call that "NetworkManager".

You think hundreds of servers (with untold numbers of VMs), or any
complicated networking setups, are going to each have their network
configuration managed by a GUI?

-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Matthew Miller]

On Mon, Jun 24, 2013 at 11:15:11AM +0930, Glen Turner wrote:
> Sun's tagline of "the network is the computer" was true. But for servers
> these days "the computer is the network" is also the case. It's nothing
> for a server today to statically NAT or bridge IPv4 to VMs. Even in that
> case it's best if the guest VM picks up its IPv4 addressing using DHCP.
>
> But in the future we'll want to do better than that: to move network
> routing onto the server itself. These new "data centre ethernet" protocols
> are not entirely implemented in kernel space. Some run quite complex BGP
> and MPLS control planes; others run IS-IS control planes.

So, the converse is that as actual workloads move to VMs (let alone cloud),
the host systems become a special case, and the "normal" case for a server
tends to become much more simple: either a single interface probably with
fixed-address DHCP, or in most complicated cases several interfaces on
specific networks known by convention.



-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Richard W.M. Jones]

On Mon, Jun 24, 2013 at 11:15:11AM +0930, Glen Turner wrote:
> 
> On 22/06/2013, at 7:23 PM, Richard W.M. Jones wrote:
> > 
> > (2) Write a shell script that contains the ifconfig/route add (or ip ...)
> > commands they need and have it run at boot.  Most simple static
> > network configs are 2 or 3 commands at most.
>
> If you have a server in the tradition of UNIX workstations sure. But
> such simple networking isn't the case for some servers today, and
> it's hard to see that it will be the case in the future.

[complicated network stuff]

Then use NetworkManager for the complicated stuff!  The whole point
here is we're *not* talking about complicated network configuration.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Glen Turner]

On 22/06/2013, at 7:23 PM, Richard W.M. Jones wrote:
> 
> (2) Write a shell script that contains the ifconfig/route add (or ip ...)
> commands they need and have it run at boot.  Most simple static
> network configs are 2 or 3 commands at most.

If you have a server in the tradition of UNIX workstations sure. But such 
simple networking isn't the case for some servers today, and it's hard to see 
that it will be the case in the future.

Sun's tagline of "the network is the computer" was true. But for servers these 
days "the computer is the network" is also the case. It's nothing for a server 
today to statically NAT or bridge IPv4 to VMs. Even in that case it's best if 
the guest VM picks up its IPv4 addressing using DHCP.

But in the future we'll want to do better than that: to move network routing 
onto the server itself. These new "data centre ethernet" protocols are not 
entirely implemented in kernel space. Some run quite complex BGP and MPLS 
control planes; others run IS-IS control planes.

The ethernet link itself isn't remaining a simple thing either. Once you're 
running a few hundred servers then management protocols start to pay their way: 
LLDP ("what server is on this switch port?"), ethernet OAM ("help, the cable is 
running errors").

What we don't want is a scenario where configuring these protocols on servers 
has to be done by network engineers. We want them configured from a GUI and 
supervised by a master daemon. Let's call that "NetworkManager".

Now maybe Dan hasn't quite realised what he's signed up for here. But then 
again, there was a time when I despaired of Linux ever working with a 3G modem, 
whereas today it offers the best experience of all the operating systems.

-glen

-- 
 Glen Turner -- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Glen Turner]

On 21/06/2013, at 10:31 PM, Chris Adams wrote:
> 
> Current network information is available from the kernel and doesn't
> require "guessing".  Why would you code something to talk to some random
> daemon API (that may change) when you could talk directly to the source
> via the kernel netlink API?

The classic here being applications which look for NM messages to indicate that 
networking connectivity is available rather than waiting on the presence of 
non-directly connected routes in the routing table.

-glen-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Glen Turner]

On 21/06/2013, at 4:28 AM, Dan Williams wrote:
> 
> It's supported that for 4 or 5 years.  You don't need aliases at all,

Consider an anycast service where the alias interface reflects the availability 
of the service on the server. An OSPF or BGP daemon then advertises the address 
of the alias interface into the network.

You want to be able to up/down the alias interface independently of the other 
addressing on the physical interface. You don't want to remove the addressing 
-- from a the routing daemon's point of view there's a considerable difference 
between no addressing (an error) and down (a state).

And sure, this isn't a common desktop scenario. But as NetworkManager makes its 
way into servers...

-glen-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Till Maas]

On Fri, Jun 21, 2013 at 12:09:57PM -0500, Dan Williams wrote:

> > On the other hand, having NetworkManager available all the time enables 
> > things like management tools to use its API to query system status, 
> > instead of guessing it from kernel information and heuristic analysis of 
> > some files under /etc.
> 
> Exactly.  And that's why we want to enhance NetworkManager to make
> people *want* to use it instead of turning it off.

Features I am missing are:

- A possibility to make NM ignore an interface from the management
  tools, which would allow to normally use NM but disable it if one
  wants to configure a device on the command line. Having to disable
  interfaces from /etc/sysconfig to be able to use them without NM
  interfering makes it more cumbersome to use NM at all.

- Support NM not interfering with Wi-Fi attack tools such as
  aircrack-ng, which might only be possible by ignoring the device
  completely or by adding support to change devices into monitor mode
  and select static of changing frequencies etc. Probably the features
  airmon-ng provides would be necessary.

- Allow to create tun/tap devices, especially persisted ones with
  permissions for users

Should I file RFEs for these in Red Hat Bugzilla or is there a
better place to communicate them to?

Regards
Till
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Richard W.M. Jones]

On Thu, Jun 20, 2013 at 01:15:37PM -0500, Chris Adams wrote:
> Once upon a time, Stephen Gallagher  said:
> > Mind if I ask why you think this way about NetworkManager? The NM
> > currently shipping in Fedora 19 has full support for managing static
> > NICs, as well as bonding, bridging and VLAN support for enterprise
> > use-cases.
> 
> I think most "traditional" system admins see a running NM daemon as an
> additional point of failure in a static network.  If my server's network
> setup is static, I don't want a daemon running attempting to "manage"
> it.  If it has a bug, gets misconfigured, etc., it might do something to
> screw up an otherwise working setup.
> 
> I understand that some servers/setups may be able to take advantage of
> NM functionality, but assuming that all servers _need_ NM is too much.
> This is all IMHO of course.

I have no skin in this game, since I dislike both NM and the
"traditional" scripts.  Here's what I think they should do[*]:

(1) systemctl mask NetworkManager.service

(2) Write a shell script that contains the ifconfig/route add (or ip ...)
commands they need and have it run at boot.  Most simple static
network configs are 2 or 3 commands at most.

Rich.

[*] Not actually tried this outside of simple VMs ...

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Dan Williams]

On Fri, 2013-06-21 at 13:17 +0200, Florian Weimer wrote:
> On 06/20/2013 09:13 PM, Dan Williams wrote:
> > nmcli doesn't work unless NM is running, since it talks to NM to do
> > stuff, so it would be incompatible with NM setting things up and
> > quitting.
> 
> It could spawn NetworkManager as a subprocess and use the peer-to-peer 
> D-Bus protocol to talk to it.  I think quite a few other programs do 
> things this way.

True.  NM git master (F20) has done the peer-to-peer thing for a couple
months actually.  But we've previously not allowed NM to auto-spawn for
a number of good reasons, mostly because starting NM can touch stuff
that you may not want touched.  We're hoping to change that by the F20
timeframe, so we could revisit this.

> On the other hand, having NetworkManager available all the time enables 
> things like management tools to use its API to query system status, 
> instead of guessing it from kernel information and heuristic analysis of 
> some files under /etc.

Exactly.  And that's why we want to enhance NetworkManager to make
people *want* to use it instead of turning it off.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Dan Williams]

On Fri, 2013-06-21 at 13:42 +0200, Florian Weimer wrote:
> On 06/20/2013 08:01 PM, Stephen Gallagher wrote:
> > Mind if I ask why you think this way about NetworkManager? The NM
> > currently shipping in Fedora 19 has full support for managing static
> > NICs, as well as bonding, bridging and VLAN support for enterprise
> > use-cases.
> >
> > NetworkManager has historically been perceived as a desktop/laptop
> > tool but in its current incarnation it should be usable for all but
> > the most esoteric enterprise workloads.
> 
> To clarify, this currently only applies to the GUI tool, right?
> 
> I recently hosed my desktop installation and couldn't bring up the VPN 
> from the command line, using nmcli.  The nmcli manual page suggests that 
> feature parity with the GUI tools is not a goal ("It is not meant as a 
> full replacement for nm‐applet or other similar clients but as a 
> complementary utility to those programs."), and the lack of actual 
> device configuration facilities in nmcli reflects that.  In Fedora 19, 
> the referenced nm-settings(5) manual page is missing, too.

We should change that.  Note that you *can* bring up VPN connections
from the command-line if all the secrets are already available (which
means stored in /etc/NetworkManager/system-connections).  It's the
editing UI (which is different for each VPN) and requesting secrets
(which is important for the RH VPN of course) which isn't implemented
for the CLI.  But we plan on doing this in the near future.

Dan

> Even if you end up configuring interfaces the old way under 
> /etc/sysconfig/networking-scripts, NetworkManager still offers the 
> benefit of the centralized configuration parsing.  But on the non-GUI 
> interface, functionality is either well-hidden or still missing.
> 
> -- 
> Florian Weimer / Red Hat Product Security Team


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Bill Nottingham]

Pavel Simerda (psime...@redhat.com) said: 
> > From: "Chris Adams" 
> > I prefer the "modern" secondaries vs. the old-style eth0:123, although I
> > have run into vendor software (such as the Plesk web hosting control
> > panel) that can't handle it.  I expect if that was the "one true way" in
> > some future version of RHEL, they'd adapt.
> 
> AFAIK with the current kernels, the only difference between aliased and
> non-aliased secondary addresses is Netlink's 'label' attribute.  If you
> want to add an address that would be seen through the alias API, you just
> need to assign it a label.  With libnl3 (used by NetworkManager), this is
> a matter of computing it and assigning it via rtnl_link_set_label(). 
> Currently we don't do that, as this for us this is unnecessary overhead,
> and as there is no known demand for it and also because the new-style
> multiple address API have been available for years.

Yeah - we have support for the label attribute in initscripts for backwards
compatibility with ifconfig/prior configuration, but we use ip/netlink for
all configuration.

Bill
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Chris Adams]

Once upon a time, Florian Weimer  said:
> The kernel does not know anything about interfaces which do not
> exist, possibly lacks information about interfaces which are not up,
> and has no concept whatsoever of DNS, DHCP (at least after boot) or
> OpenVPN or settings.

The idea of NM being able to go away is for static configurations, such
as servers, where there are no interfaces that don't exist.  If it
matters, it is up, and there's already plenty of library access to DNS.
-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Florian Weimer]

On 06/21/2013 03:01 PM, Chris Adams wrote:

Once upon a time, Florian Weimer  said:

On the other hand, having NetworkManager available all the time
enables things like management tools to use its API to query system
status, instead of guessing it from kernel information and heuristic
analysis of some files under /etc.


Current network information is available from the kernel and doesn't
require "guessing".  Why would you code something to talk to some random
daemon API (that may change) when you could talk directly to the source
via the kernel netlink API?


The kernel does not know anything about interfaces which do not exist, 
possibly lacks information about interfaces which are not up, and has no 
concept whatsoever of DNS, DHCP (at least after boot) or OpenVPN or 
settings.


--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Chris Adams]

Once upon a time, Florian Weimer  said:
> On the other hand, having NetworkManager available all the time
> enables things like management tools to use its API to query system
> status, instead of guessing it from kernel information and heuristic
> analysis of some files under /etc.

Current network information is available from the kernel and doesn't
require "guessing".  Why would you code something to talk to some random
daemon API (that may change) when you could talk directly to the source
via the kernel netlink API?
-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Florian Weimer]

On 06/20/2013 08:01 PM, Stephen Gallagher wrote:

Mind if I ask why you think this way about NetworkManager? The NM
currently shipping in Fedora 19 has full support for managing static
NICs, as well as bonding, bridging and VLAN support for enterprise
use-cases.

NetworkManager has historically been perceived as a desktop/laptop
tool but in its current incarnation it should be usable for all but
the most esoteric enterprise workloads.


To clarify, this currently only applies to the GUI tool, right?

I recently hosed my desktop installation and couldn't bring up the VPN 
from the command line, using nmcli.  The nmcli manual page suggests that 
feature parity with the GUI tools is not a goal ("It is not meant as a 
full replacement for nm‐applet or other similar clients but as a 
complementary utility to those programs."), and the lack of actual 
device configuration facilities in nmcli reflects that.  In Fedora 19, 
the referenced nm-settings(5) manual page is missing, too.


Even if you end up configuring interfaces the old way under 
/etc/sysconfig/networking-scripts, NetworkManager still offers the 
benefit of the centralized configuration parsing.  But on the non-GUI 
interface, functionality is either well-hidden or still missing.


--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Florian Weimer]

On 06/20/2013 09:13 PM, Dan Williams wrote:

nmcli doesn't work unless NM is running, since it talks to NM to do
stuff, so it would be incompatible with NM setting things up and
quitting.


It could spawn NetworkManager as a subprocess and use the peer-to-peer 
D-Bus protocol to talk to it.  I think quite a few other programs do 
things this way.


On the other hand, having NetworkManager available all the time enables 
things like management tools to use its API to query system status, 
instead of guessing it from kernel information and heuristic analysis of 
some files under /etc.


--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Chris Adams]

Once upon a time, Adam Williamson  said:
> Matthew's post about it was precisely what kicked off this sub-thread. I
> wonder if there is a theorem covering the topic of the minimum number of
> messages required in a thread before one is posted which is clearly
> unaware of the first one. =)

D'oh!  That's what I get for reading too fast.
-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Adam Williamson]

On Thu, 2013-06-20 at 14:06 -0500, Chris Adams wrote:
> Once upon a time, Matthew Miller  said:
> > Hence, the RFE -- a mode which sets up the above, and then goes away.
> 
> I had not seen that mode (or a request for it).  

Matthew's post about it was precisely what kicked off this sub-thread. I
wonder if there is a theorem covering the topic of the minimum number of
messages required in a thread before one is posted which is clearly
unaware of the first one. =)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Reindl Harald]

Am 20.06.2013 22:14, schrieb Kevin Fenzi:
> On Thu, 20 Jun 2013 21:59:16 +0200
> Reindl Harald  wrote:
> 
>> because i do *not* need it?
>> becuase i maintain around 30 fedora machines
>> because they are all wroking perfect
> 
> Thats great that that is your use case. 
> 
> Keep in mind that this list is talking about development of Fedora for
> ALL the people who use it. Try and think beyond your own use cases to
> what might be useful to others? 

*where* did i say anything against others usecases?

i *only* defent the attitude "We are on track to *replace* the "legacy"
network and firewall init scripts with these", not more and not less



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Kevin Fenzi]

On Thu, 20 Jun 2013 21:59:16 +0200
Reindl Harald  wrote:

> because i do *not* need it?
> becuase i maintain around 30 fedora machines
> because they are all wroking perfect

Thats great that that is your use case. 

Keep in mind that this list is talking about development of Fedora for
ALL the people who use it. Try and think beyond your own use cases to
what might be useful to others? 
 
> because it is utterly useless to have a long living process
> for static basic configurations running

Thus the reason for the mentioned RFE on a one-time mode that
configures and exits. 

kevin



signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Reindl Harald]

Am 20.06.2013 20:55, schrieb Matthew Miller:
> On Thu, Jun 20, 2013 at 01:15:37PM -0500, Chris Adams wrote:
>>> Mind if I ask why you think this way about NetworkManager? The NM
>>> currently shipping in Fedora 19 has full support for managing static
>>> NICs, as well as bonding, bridging and VLAN support for enterprise
>>> use-cases.
>> I think most "traditional" system admins see a running NM daemon as an
>> additional point of failure in a static network.  If my server's network
>> setup is static, I don't want a daemon running attempting to "manage"
>> it.  If it has a bug, gets misconfigured, etc., it might do something to
>> screw up an otherwise working setup.
> 
> Hence, the RFE -- a mode which sets up the above, and then goes away.
> 
> There are significant advantages to having a single code path for network
> configuration on the system -- easier support, simpler documenation, easier
> administration between multiple systems, easier development of new
> distribution features overall

this is simply the wrong road

why do we have multiple desktops?
why do we have a ton of text-editors?
why do we have different mail-programs?
why do we have differnet web-browsers?

because they are useful in different ways as well as configs
working since decades for network-setup and firewalling




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Reindl Harald]

Am 20.06.2013 17:37, schrieb Matthew Miller:
> On Thu, Jun 20, 2013 at 05:08:48PM +0200, Reindl Harald wrote:
>>> We are on track to replace the "legacy" network and firewall init scripts
>>> with these. It's a slow track, but that's the direction
>> *do not* remove iptables.service for a lot od reason explained
>> often enough as well as NM is utterly useless on servers and
>> workstations with several *static* configured NIC's
> 
> Well, like I just said, it's a slow track. I certainly am vigorously opposed
> to removing it before the replacement has the same functionality and
> reliability

NM does not need to have functionality on servers, the opposite is true
firewalld does not need to have functionality on servers, the opposite is true

especially in case of iptables.service in fact firewalld doe snothing
else than write iptables-rules, they are written on thousands of machines
in large and over years maintained SHELL-SCRIPTS often *distributed*
over 10, 20, 30 machines with $HOSTNAME conditions

you do not need to replace this, hence iptables.service does nothing
else than load the this way written rules at startup



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Reindl Harald]

Am 20.06.2013 20:01, schrieb Stephen Gallagher:
>> *do not* remove iptables.service for a lot od reason explained 
>> often enough as well as NM is utterly useless on servers and 
>> workstations with several *static* configured NIC's
> 
> 
> Mind if I ask why you think this way about NetworkManager? The NM
> currently shipping in Fedora 19 has full support for managing static
> NICs, as well as bonding, bridging and VLAN support for enterprise
> use-cases.
> 
> NetworkManager has historically been perceived as a desktop/laptop
> tool but in its current incarnation it should be usable for all but
> the most esoteric enterprise workloads

because i do *not* need it?
becuase i maintain around 30 fedora machines
because they are all wroking perfect

because it is utterly useless to have a long living process
for static basic configurations running




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Pavel Simerda]

> From: "Chris Adams" 
> I prefer the "modern" secondaries vs. the old-style eth0:123, although I
> have run into vendor software (such as the Plesk web hosting control
> panel) that can't handle it.  I expect if that was the "one true way" in
> some future version of RHEL, they'd adapt.

AFAIK with the current kernels, the only difference between aliased and 
non-aliased secondary addresses is Netlink's 'label' attribute. If you want to 
add an address that would be seen through the alias API, you just need to 
assign it a label. With libnl3 (used by NetworkManager), this is a matter of 
computing it and assigning it via rtnl_link_set_label(). Currently we don't do 
that, as this for us this is unnecessary overhead, and as there is no known 
demand for it and also because the new-style multiple address API have been 
available for years.

Pavel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Dan Williams]

On Thu, 2013-06-20 at 14:06 -0500, Chris Adams wrote:
> Once upon a time, Matthew Miller  said:
> > Hence, the RFE -- a mode which sets up the above, and then goes away.
> 
> I had not seen that mode (or a request for it).  That would be nice.  In
> a perfect world (hah!), replacing "ifup" and "ifdown" with scripts that
> just make the appropriate "nmcli" (or whatever) calls would be awesome,
> as long as NM supports all the old functionality.

nmcli doesn't work unless NM is running, since it talks to NM to do
stuff, so it would be incompatible with NM setting things up and
quitting.

> > There are significant advantages to having a single code path for network
> > configuration on the system -- easier support, simpler documenation, easier
> > administration between multiple systems, easier development of new
> > distribution features overall. But the condition you give is very important
> > too -- that's why the "traditional" system is still there in parallel right
> > now.
> 
> That would be cool; I understand reducing methods reduces support
> overhead.  Please don't take my email as throwing stones; I was trying
> to _not_ do that, just point out why in some situations sysadmins
> sometimes avoid NM.

And we'd love to understand those situations and see what we can do to
make sysadmins happier with NM.  Including things like cooperating with
changes made to interfaces underneath NM, server-type config options
(locking connections via interface name, manual config updates instead
of watching files, not creating default DHCP connections for ethernet
interfaces, etc).

Dan

> I understand that the old-style network scripts are a maze of twisty
> little passages, all different, and trying to replace all the
> functionality that people use is not trivial.
> -- 
> Chris Adams 


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Dan Williams]

On Thu, 2013-06-20 at 13:59 -0500, Chris Adams wrote:
> Once upon a time, Bill Nottingham  said:
> > No, it does not support that at this time. Also note that (if I'm
> > remembering right) NM adds all aliases as secondary IP addresses, not as
> > ':x' style additional devices.
> 
> I prefer the "modern" secondaries vs. the old-style eth0:123, although I
> have run into vendor software (such as the Plesk web hosting control
> panel) that can't handle it.  I expect if that was the "one true way" in
> some future version of RHEL, they'd adapt.
> 
> For anybody doing shared web hosting, bulk IP address configuration
> (however they end up configured) is a must though.  I certainly don't
> want to have to add a /24 one address at a time.

This is great feedback to have and something that NM should add support
for.  I've filed https://bugzilla.gnome.org/show_bug.cgi?id=702773 for
it.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Chris Adams]

Once upon a time, Matthew Miller  said:
> Hence, the RFE -- a mode which sets up the above, and then goes away.

I had not seen that mode (or a request for it).  That would be nice.  In
a perfect world (hah!), replacing "ifup" and "ifdown" with scripts that
just make the appropriate "nmcli" (or whatever) calls would be awesome,
as long as NM supports all the old functionality.

> There are significant advantages to having a single code path for network
> configuration on the system -- easier support, simpler documenation, easier
> administration between multiple systems, easier development of new
> distribution features overall. But the condition you give is very important
> too -- that's why the "traditional" system is still there in parallel right
> now.

That would be cool; I understand reducing methods reduces support
overhead.  Please don't take my email as throwing stones; I was trying
to _not_ do that, just point out why in some situations sysadmins
sometimes avoid NM.

I understand that the old-style network scripts are a maze of twisty
little passages, all different, and trying to replace all the
functionality that people use is not trivial.
-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Chris Adams]

Once upon a time, Bill Nottingham  said:
> No, it does not support that at this time. Also note that (if I'm
> remembering right) NM adds all aliases as secondary IP addresses, not as
> ':x' style additional devices.

I prefer the "modern" secondaries vs. the old-style eth0:123, although I
have run into vendor software (such as the Plesk web hosting control
panel) that can't handle it.  I expect if that was the "one true way" in
some future version of RHEL, they'd adapt.

For anybody doing shared web hosting, bulk IP address configuration
(however they end up configured) is a must though.  I certainly don't
want to have to add a /24 one address at a time.

-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Dan Williams]

On Thu, 2013-06-20 at 12:13 -0600, Eric Smith wrote:
> Does NM in F19 support statically assigning multiple subnets to the
> same physical interface, WITHOUT using VLANs?  I often need that on
> server machines, and wasn't able to figure out any way to do it with
> NM on F17, but I haven't yet tried it on F19.

It's supported that for 4 or 5 years.  You don't need aliases at all,
you just add more IP addresses to your ifcfg file and NM applies them to
the interface.

ADDRESS2=10.0.0.1
PREFIX2=8
ADDRESS3=4.5.6.7
PREFIX3=29

> With the old-style network configuration, it was easy to manually
> configure this by creating /etc/sysconfig/network-scripts/eth3:
> config files.  Also, it was very easy to automate creating and
> removing them, while I have yet to be successful scripting changes to
> NM configurations, though probably I'm overlooking some simple way of
> doing that.

Aliases came about because the kernel APIs (and ifconfig) couldn't
handle multiple addresses on a single interface.  That hasn't been the
case for like 8 or 10 years though, since netlink happened, and thus you
can add as many as you want via NM or /sbin/ip or whatever.  Aliases
haven't been required for years.

> Previously it has seemed that the old-style network configuration was
> more robust than NM, though not as user-friendly. However, I know that
> NM has been getting more robust over time, so that may no longer be
> true.

We want NM to be *capable* of working on servers with static
configuration, and we want NM not to do anything surprising in these
setups.  Whether an admin chooses to leave NM enabled or not is up to
them, but we hope to add enough value that many *will* leave it enabled,
either for remote administration, or a consistent interface to configure
networking on the machine instead of 10 different tools, or an
easier-to-use CLI than /sbin/ip + vi/emacs + config files, or whatever.
That's where we're going.

I did some screencast demos for some of these features and posted them
to the Fedora NM wiki pages if you're interested in see where we're
going:

https://fedoraproject.org/wiki/Tools/NetworkManager#Servers

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Matthew Miller]

On Thu, Jun 20, 2013 at 01:15:37PM -0500, Chris Adams wrote:
> > Mind if I ask why you think this way about NetworkManager? The NM
> > currently shipping in Fedora 19 has full support for managing static
> > NICs, as well as bonding, bridging and VLAN support for enterprise
> > use-cases.
> I think most "traditional" system admins see a running NM daemon as an
> additional point of failure in a static network.  If my server's network
> setup is static, I don't want a daemon running attempting to "manage"
> it.  If it has a bug, gets misconfigured, etc., it might do something to
> screw up an otherwise working setup.

Hence, the RFE -- a mode which sets up the above, and then goes away.

There are significant advantages to having a single code path for network
configuration on the system -- easier support, simpler documenation, easier
administration between multiple systems, easier development of new
distribution features overall. But the condition you give is very important
too -- that's why the "traditional" system is still there in parallel right
now.



-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Bill Nottingham]

Chris Adams (li...@cmadams.net) said: 
> Once upon a time, Eric Smith  said:
> > Does NM in F19 support statically assigning multiple subnets to the
> > same physical interface, WITHOUT using VLANs?  I often need that on
> > server machines, and wasn't able to figure out any way to do it with
> > NM on F17, but I haven't yet tried it on F19.
> 
> Also, does NM do the "bulk"-style IP alias adding?  The old-style
> network service can handle a "range" file for adding addresses that is
> much easier to config/manage than adding 400 individual IP addresses.

No, it does not support that at this time. Also note that (if I'm
remembering right) NM adds all aliases as secondary IP addresses, not as
':x' style additional devices.

Bill
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Colin Walters]

On Thu, 2013-06-20 at 12:13 -0600, Eric Smith wrote:
> Does NM in F19 support statically assigning multiple subnets to the
> same physical interface, WITHOUT using VLANs?

Yes.  You can easily do this in the GNOME Control center, just try it.
Click "Manual", and then the "+" will allow adding multiple IPv4 (or
IPv6) addresses to a single interface.

> With the old-style network configuration, it was easy to manually
> configure this by creating /etc/sysconfig/network-scripts/eth3:
> config files. 

As Tomaz mentions that's the legacy way; what NM writes into the
network-scripts when you do the above is the modern way.

>  Also, it was very easy to automate creating and
> removing them, while I have yet to be successful scripting changes to
> NM configurations, though probably I'm overlooking some simple way of
> doing that.

The new nmcli will help here...could possibly land in a post-release
update.  But if you look at what NM writes for the above you can see how
it works:

HWADDR=52:54:00:98:A4:04
TYPE=Ethernet
BOOTPROTO=none
IPADDR0=10.76.76.76
PREFIX0=24
GATEWAY0=10.0.0.1
IPADDR1=10.42.42.42
PREFIX1=24
GATEWAY1=10.42.42.1
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME="Wired connection 2"
UUID=f5480bfe-f4df-4cc9-ab7d-ccb778a6727a
ONBOOT=yes




-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Colin Walters]

On Thu, 2013-06-20 at 13:15 -0500, Chris Adams wrote:

> I think most "traditional" system admins see a running NM daemon as an
> additional point of failure in a static network.  If my server's network
> setup is static, I don't want a daemon running attempting to "manage"
> it.  If it has a bug, gets misconfigured, etc., it might do something to
> screw up an otherwise working setup.

Yes, it's just not easy to do without creating race conditions.  Various
other components use NetworkManager as an API, and if just called exit()
arbitrarily it'd introduce the problems described here:

https://bugs.freedesktop.org/show_bug.cgi?id=11454

This point has been raised repeatedly, the developers are aware that
it'd be nicer for NM to not show up in "ps" in these situations, but the
reason it's not done is it's nontrivial and there are a lot of other
things in the priority queue.

> I understand that some servers/setups may be able to take advantage of
> NM functionality, but assuming that all servers _need_ NM is too much.
> This is all IMHO of course.

It's not about "all", but about having a plan, executing on it and
staying on top of major regressions.  There's been a fair amount of
continual improvement, and stuff like the revamped nmcli should help a
lot.



-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Tomasz Torcz]

On Thu, Jun 20, 2013 at 12:13:54PM -0600, Eric Smith wrote:
> Does NM in F19 support statically assigning multiple subnets to the
> same physical interface, WITHOUT using VLANs?  I often need that on
> server machines, and wasn't able to figure out any way to do it with
> NM on F17, but I haven't yet tried it on F19.

  I think it does, since few releases. If you use proper syntax:
# grep IPADDRn /usr/share/doc/initscripts-9.47/sysconfig.txt
(note the ‘n‘)

> With the old-style network configuration, it was easy to manually
> configure this by creating /etc/sysconfig/network-scripts/eth3:

  That's an old style aliases, not multiple addresses for one interface.

-- 
Tomasz Torcz   72->|   80->|
xmpp: zdzich...@chrome.pl  72->|   80->|

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Chris Adams]

Once upon a time, Eric Smith  said:
> Does NM in F19 support statically assigning multiple subnets to the
> same physical interface, WITHOUT using VLANs?  I often need that on
> server machines, and wasn't able to figure out any way to do it with
> NM on F17, but I haven't yet tried it on F19.

Also, does NM do the "bulk"-style IP alias adding?  The old-style
network service can handle a "range" file for adding addresses that is
much easier to config/manage than adding 400 individual IP addresses.
-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Chris Adams]

Once upon a time, Stephen Gallagher  said:
> Mind if I ask why you think this way about NetworkManager? The NM
> currently shipping in Fedora 19 has full support for managing static
> NICs, as well as bonding, bridging and VLAN support for enterprise
> use-cases.

I think most "traditional" system admins see a running NM daemon as an
additional point of failure in a static network.  If my server's network
setup is static, I don't want a daemon running attempting to "manage"
it.  If it has a bug, gets misconfigured, etc., it might do something to
screw up an otherwise working setup.

I understand that some servers/setups may be able to take advantage of
NM functionality, but assuming that all servers _need_ NM is too much.
This is all IMHO of course.

-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Eric Smith]

Does NM in F19 support statically assigning multiple subnets to the
same physical interface, WITHOUT using VLANs?  I often need that on
server machines, and wasn't able to figure out any way to do it with
NM on F17, but I haven't yet tried it on F19.

With the old-style network configuration, it was easy to manually
configure this by creating /etc/sysconfig/network-scripts/eth3:
config files.  Also, it was very easy to automate creating and
removing them, while I have yet to be successful scripting changes to
NM configurations, though probably I'm overlooking some simple way of
doing that.

Previously it has seemed that the old-style network configuration was
more robust than NM, though not as user-friendly. However, I know that
NM has been getting more robust over time, so that may no longer be
true.

Eric


On Thu, Jun 20, 2013 at 12:01 PM, Stephen Gallagher  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/20/2013 11:08 AM, Reindl Harald wrote:
>>
>>
>> Am 20.06.2013 17:01, schrieb Matthew Miller:
>>> On Thu, Jun 20, 2013 at 11:52:54AM +0200, Harald Hoyer wrote:
 And why is NetworkManager and firewalld in the minimal
 install?
>>>
>>> We are on track to replace the "legacy" network and firewall init
>>> scripts with these. It's a slow track, but that's the direction
>>
>> *do not* remove iptables.service for a lot od reason explained
>> often enough as well as NM is utterly useless on servers and
>> workstations with several *static* configured NIC's
>>
>
> Mind if I ask why you think this way about NetworkManager? The NM
> currently shipping in Fedora 19 has full support for managing static
> NICs, as well as bonding, bridging and VLAN support for enterprise
> use-cases.
>
> NetworkManager has historically been perceived as a desktop/laptop
> tool but in its current incarnation it should be usable for all but
> the most esoteric enterprise workloads.
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlHDQ18ACgkQeiVVYja6o6Me0wCeNYAGhOf1YSn+x9nlBVqNWewF
> t9oAn2u80JWIyr/PV3jL5H6LLfXMFQC5
> =UPum
> -END PGP SIGNATURE-
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/20/2013 11:08 AM, Reindl Harald wrote:
> 
> 
> Am 20.06.2013 17:01, schrieb Matthew Miller:
>> On Thu, Jun 20, 2013 at 11:52:54AM +0200, Harald Hoyer wrote:
>>> And why is NetworkManager and firewalld in the minimal
>>> install?
>> 
>> We are on track to replace the "legacy" network and firewall init
>> scripts with these. It's a slow track, but that's the direction
> 
> *do not* remove iptables.service for a lot od reason explained 
> often enough as well as NM is utterly useless on servers and 
> workstations with several *static* configured NIC's
> 

Mind if I ask why you think this way about NetworkManager? The NM
currently shipping in Fedora 19 has full support for managing static
NICs, as well as bonding, bridging and VLAN support for enterprise
use-cases.

NetworkManager has historically been perceived as a desktop/laptop
tool but in its current incarnation it should be usable for all but
the most esoteric enterprise workloads.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlHDQ18ACgkQeiVVYja6o6Me0wCeNYAGhOf1YSn+x9nlBVqNWewF
t9oAn2u80JWIyr/PV3jL5H6LLfXMFQC5
=UPum
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Michael Cronenworth]

On 06/20/2013 10:37 AM, Matthew Miller wrote:
> Well, like I just said, it's a slow track. I certainly am vigorously opposed
> to removing it before the replacement has the same functionality and
> reliability.

... and resource usage. Having Python fully loaded for a firewall isn't
my first choice.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Reindl Harald]

Am 20.06.2013 17:01, schrieb Matthew Miller:
> On Thu, Jun 20, 2013 at 11:52:54AM +0200, Harald Hoyer wrote:
>> And why is NetworkManager and firewalld in the minimal install?
> 
> We are on track to replace the "legacy" network and firewall init scripts
> with these. It's a slow track, but that's the direction

*do not* remove iptables.service for a lot od reason explained
often enough as well as NM is utterly useless on servers and
workstations with several *static* configured NIC's



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Matthew Miller]

On Thu, Jun 20, 2013 at 05:08:48PM +0200, Reindl Harald wrote:
> > We are on track to replace the "legacy" network and firewall init scripts
> > with these. It's a slow track, but that's the direction
> *do not* remove iptables.service for a lot od reason explained
> often enough as well as NM is utterly useless on servers and
> workstations with several *static* configured NIC's

Well, like I just said, it's a slow track. I certainly am vigorously opposed
to removing it before the replacement has the same functionality and
reliability.


-- 
Matthew Miller   mat...@mattdm.org  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Matthew Miller]

On Thu, Jun 20, 2013 at 11:52:54AM +0200, Harald Hoyer wrote:
> And why is NetworkManager and firewalld in the minimal install?

We are on track to replace the "legacy" network and firewall init scripts
with these. It's a slow track, but that's the direction.

Overall, I'm in favor of having a single code path for network and firewall
configuration. As I understand from the NetworkManager developers, a mode
where NetworkManager does the basic configuration in the initramfs and then
goes away is in development. If that can also hand-off to a simple dhcp
client, I think we're in pretty good shape for the simple case.

Here's my RFE https://bugzilla.redhat.com/show_bug.cgi?id=863515

Firewalld needs a *lot* more work in this area. Here's _that_ RFE:
https://bugzilla.redhat.com/show_bug.cgi?id=876683

As discussed before the F18 release, firewalld was initially proposed as a
"default" for F18, but actually crept in as mandatory, since Anaconda uses
it. One can remove it after the install, or in kickstart post.

And you're absolutely right to focus in this, as these two packages are
definitely the cause of most of the growth in minimal, and pull in most of
the odd stuff that doesn't feel like it belongs at that level. So, in
addition to the above, reducing/splitting the dependencies would be
valuable.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Remi Collet]

Le 20/06/2013 12:18, Harald Hoyer a écrit :
> On 06/20/2013 11:59 AM, Remi Collet wrote:
>> Le 20/06/2013 11:52, Harald Hoyer a écrit :
>>> $ rpm -q --whatrequires json-c
>>> no package requires json-c
>>
>> Probably should try
>>
>> $ rpm -q --whatrequires \
>>   "libjson.so.0()(64bit)" \
>>   "libjson-c.so.2()(64bit)"
>>
>> => pulseaudio, abrt, libreport, ...
>>
>> Remi.
>>
> 
> This cries for the compile option "-Wl,--as-needed"

I think I have explain that when updated to 0.11.

libjson.so is just a artefact to allow applications build with it to
continue to work.

libjson-c.so is the correct library
(renamed by upstream because of name conflicts with other projects).

So, if an application is link with -ljson it will fail and need a fix.

As usually, correct way is to use pkg-config output

$ pkg-config --cflags json-c
-I/usr/include/json-c

$ pkg-config --libs json-c
-ljson-c

And, for compatibility, to avoid to much problem

$ pkg-config --libs json
-ljson-c


Notice : this layer will be dropped in the future.

Remi.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Harald Hoyer]

On 06/20/2013 11:59 AM, Remi Collet wrote:
> Le 20/06/2013 11:52, Harald Hoyer a écrit :
>> $ rpm -q --whatrequires json-c
>> no package requires json-c
> 
> Probably should try
> 
> $ rpm -q --whatrequires \
>   "libjson.so.0()(64bit)" \
>   "libjson-c.so.2()(64bit)"
> 
> => pulseaudio, abrt, libreport, ...
> 
> Remi.
> 

This cries for the compile option "-Wl,--as-needed"

$ ldd /usr/lib64/pulse-3.0/modules/module-bluetooth-policy.so
linux-vdso.so.1 =>  (0x7fff0c3f1000)
libpulsecore-3.0.so => /lib64/libpulsecore-3.0.so (0x7f990c91e000)
libltdl.so.7 => /lib64/libltdl.so.7 (0x7f990c713000)
libsamplerate.so.0 => /lib64/libsamplerate.so.0 (0x7f990c3a7000)
libspeexdsp.so.1 => /lib64/libspeexdsp.so.1 (0x7f990c194000)
liborc-0.4.so.0 => /lib64/liborc-0.4.so.0 (0x7f990bf11000)
libtdb.so.1 => /lib64/libtdb.so.1 (0x7f990bcff000)
libpulse.so.0 => /lib64/libpulse.so.0 (0x7f990bab5000)
libjson.so.0 => /lib64/libjson.so.0 (0x7f990b8b2000)
libpulsecommon-3.0.so => /usr/lib64/pulseaudio/libpulsecommon-3.0.so
(0x7f990b64a000)
libX11-xcb.so.1 => /lib64/libX11-xcb.so.1 (0x7f990b448000)
libX11.so.6 => /lib64/libX11.so.6 (0x7f990b10c000)
libxcb.so.1 => /lib64/libxcb.so.1 (0x7f990aeee000)
libICE.so.6 => /lib64/libICE.so.6 (0x7f990acd2000)
libSM.so.6 => /lib64/libSM.so.6 (0x7f990aac9000)
libXtst.so.6 => /lib64/libXtst.so.6 (0x7f990a8c3000)
libwrap.so.0 => /lib64/libwrap.so.0 (0x7f990a6b8000)
libsndfile.so.1 => /lib64/libsndfile.so.1 (0x7f990a458000)
libasyncns.so.0 => /lib64/libasyncns.so.0 (0x7f990a252000)
libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x7f990a00c000)
libcap.so.2 => /lib64/libcap.so.2 (0x7f9909e06000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f9909bea000)
librt.so.1 => /lib64/librt.so.1 (0x7f99099e2000)
libdl.so.2 => /lib64/libdl.so.2 (0x7f99097dd000)
libm.so.6 => /lib64/libm.so.6 (0x7f99094db000)
libc.so.6 => /lib64/libc.so.6 (0x7f990911b000)
/lib64/ld-linux-x86-64.so.2 (0x00374460)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f9908f04000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x7f9908ccd000)
libjson-c.so.2 => /lib64/libjson-c.so.2 (0x7f9908ac1000)
libXau.so.6 => /lib64/libXau.so.6 (0x7f99088bd000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x7f99086b7000)
libXext.so.6 => /lib64/libXext.so.6 (0x7f99084a5000)
libXi.so.6 => /lib64/libXi.so.6 (0x7f9908295000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x7f990807b000)
libgsm.so.1 => /lib64/libgsm.so.1 (0x7f9907e6f000)
libFLAC.so.8 => /lib64/libFLAC.so.8 (0x7f9907c2b000)
libvorbisenc.so.2 => /lib64/libvorbisenc.so.2 (0x7f990775b000)
libvorbis.so.0 => /lib64/libvorbis.so.0 (0x7f990752d000)
libogg.so.0 => /lib64/libogg.so.0 (0x7f9907326000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x7f990710b000)
libattr.so.1 => /lib64/libattr.so.1 (0x7f9906f06000)
libfreebl3.so => /lib64/libfreebl3.so (0x7f9906c99000)



-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Harald Hoyer]

On 06/20/2013 11:59 AM, Remi Collet wrote:
> Le 20/06/2013 11:52, Harald Hoyer a écrit :
>> $ rpm -q --whatrequires json-c
>> no package requires json-c
> 
> Probably should try
> 
> $ rpm -q --whatrequires \
>   "libjson.so.0()(64bit)" \
>   "libjson-c.so.2()(64bit)"
> 
> => pulseaudio, abrt, libreport, ...
> 
> Remi.
> 

Doh.. yes, sorry.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Remi Collet]

Le 20/06/2013 11:52, Harald Hoyer a écrit :
> $ rpm -q --whatrequires json-c
> no package requires json-c

Probably should try

$ rpm -q --whatrequires \
  "libjson.so.0()(64bit)" \
  "libjson-c.so.2()(64bit)"

=> pulseaudio, abrt, libreport, ...

Remi.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Minimal install diff from F16 to F19 (TC6)

[Harald Hoyer]

On 06/20/2013 09:21 AM, Adam Williamson wrote:
> As it may be interesting and I have the data on hand, here's the package
> diff between a minimal install of F16 and a minimal install of F19. F16
> has 203 packages (I think it's really 202 but I somehow got an extra one
> into my test), F19 TC6 has 238.
> 

Hmm, some suspicious candidates.

json-c?

$ rpm -q --whatrequires json-c
no package requires json-c


make for package: 1:openssl-1.0.1e-4.fc19.x86_64


Hmm, why does NetworkManager have a hard requirement for these?
avahi-autoipd
ppp
dnsmasq

And why is NetworkManager and firewalld in the minimal install?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel