Re: Minimal install diff from F16 to F19 (TC6)
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)
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)
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)
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)
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 ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install diff from F16 to F19 (TC6)
Once upon a time, Glen Turner g...@gdt.id.au 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 li...@cmadams.net -- 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 [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)
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)
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 http://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)
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 ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install diff from F16 to F19 (TC6)
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)
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)
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 ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install diff from F16 to F19 (TC6)
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 http://www.gdt.id.au/~gdt/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install diff from F16 to F19 (TC6)
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)
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)
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 http://www.gdt.id.au/~gdt/-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install diff from F16 to F19 (TC6)
On Thu, Jun 20, 2013 at 01:15:37PM -0500, Chris Adams wrote: Once upon a time, Stephen Gallagher sgall...@redhat.com 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)
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)
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)
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)
Once upon a time, Florian Weimer fwei...@redhat.com 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 li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install diff from F16 to F19 (TC6)
On 06/21/2013 03:01 PM, Chris Adams wrote: Once upon a time, Florian Weimer fwei...@redhat.com 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)
Once upon a time, Florian Weimer fwei...@redhat.com 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 li...@cmadams.net -- 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 (psime...@redhat.com) said: From: Chris Adams li...@cmadams.net 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)
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)
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)
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
Re: Minimal install diff from F16 to F19 (TC6)
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)
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)
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)
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)
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 ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install diff from F16 to F19 (TC6)
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 http://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)
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)
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)
-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)
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:n 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 sgall...@redhat.com 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)
Once upon a time, Stephen Gallagher sgall...@redhat.com 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 li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install diff from F16 to F19 (TC6)
Once upon a time, Eric Smith brouh...@fedoraproject.org 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 li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install diff from F16 to F19 (TC6)
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:n 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)
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)
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:n 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)
Chris Adams (li...@cmadams.net) said: Once upon a time, Eric Smith brouh...@fedoraproject.org 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)
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 ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install diff from F16 to F19 (TC6)
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:n 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)
Once upon a time, Bill Nottingham nott...@redhat.com 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 li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install diff from F16 to F19 (TC6)
Once upon a time, Matthew Miller mat...@fedoraproject.org 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 li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install diff from F16 to F19 (TC6)
On Thu, 2013-06-20 at 13:59 -0500, Chris Adams wrote: Once upon a time, Bill Nottingham nott...@redhat.com 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)
On Thu, 2013-06-20 at 14:06 -0500, Chris Adams wrote: Once upon a time, Matthew Miller mat...@fedoraproject.org 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 li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minimal install diff from F16 to F19 (TC6)
From: Chris Adams li...@cmadams.net 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)
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)
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)
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)
On Thu, 20 Jun 2013 21:59:16 +0200 Reindl Harald h.rei...@thelounge.net 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)
Am 20.06.2013 22:14, schrieb Kevin Fenzi: On Thu, 20 Jun 2013 21:59:16 +0200 Reindl Harald h.rei...@thelounge.net 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)
On Thu, 2013-06-20 at 14:06 -0500, Chris Adams wrote: Once upon a time, Matthew Miller mat...@fedoraproject.org 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)
Once upon a time, Adam Williamson awill...@redhat.com 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 li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
