Re: [systemd-devel] [question] networkd: Any support for hooks?
On Tue, 04.11.14 14:48, Dan Williams (d...@redhat.com) wrote: Can you be more specific what precisely you intend to hook in there? I'd really prefer if we could find different solutions for the common usecases. Example: I'd like to add interface to proper firewalld zone. Ideally it could be done by networkd itself (it just one dbus call: addInterface(in s zone, in s interface, …) based on new Zone=string setting in .netdev file. Hook can determine which zone interface should belong to and call firewall-cmd --zone=zone --add-interface=interface If firewalld shall be dynamic then it really should listen to rtnl on its own. It's the wrong way round, you don't want to to call into higher level software from lower level one. It's the higher level software that should subscribe to changes from the lower level software. firewalld can't get the information that WiFi network Starbucks should be locked down more than your home network. How is it supposed to get that information just listening to rtnl or other kernel events? The kernel doesn't care; the only source of that information is the connection manager. Well, even if the connection manager keeps track of information for that it should be firewalld that queries it from the connection manager, and not the connection manager calling out to firewalld. It's really not clean design to have the lower layers of the stack call out to the higher layers of the stack. It should be the higher layers that subscribe to the lower layers. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
On Thu, Oct 02, 2014 at 08:36:10AM +0200, Lennart Poettering wrote: On Wed, 01.10.14 21:36, Cameron Norman (camerontnor...@gmail.com) wrote: Hello, ifupdown [1], NetworkManager, and WICD all support hooks for when a network interface is configured or deconfigured (before and after these actions). Are there any plans to support something along these lines? If so, what will that look like? If there are no plans, how do networkd's developers feel about adding the feature (will not merge, or will accept patches, etc.) ? Can you be more specific what precisely you intend to hook in there? I'd really prefer if we could find different solutions for the common usecases. Example: I'd like to add interface to proper firewalld zone. Ideally it could be done by networkd itself (it just one dbus call: addInterface(in s zone, in s interface, …) based on new Zone=string setting in .netdev file. Hook can determine which zone interface should belong to and call firewall-cmd --zone=zone --add-interface=interface -- Tomasz Torcz Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes. -- Jim Gray ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
BOn Tue, 04.11.14 19:07, Tomasz Torcz (to...@pipebreaker.pl) wrote: On Thu, Oct 02, 2014 at 08:36:10AM +0200, Lennart Poettering wrote: On Wed, 01.10.14 21:36, Cameron Norman (camerontnor...@gmail.com) wrote: Hello, ifupdown [1], NetworkManager, and WICD all support hooks for when a 1;3409;0c network interface is configured or deconfigured (before and after these actions). Are there any plans to support something along these lines? If so, what will that look like? If there are no plans, how do networkd's developers feel about adding the feature (will not merge, or will accept patches, etc.) ? Can you be more specific what precisely you intend to hook in there? I'd really prefer if we could find different solutions for the common usecases. Example: I'd like to add interface to proper firewalld zone. Ideally it could be done by networkd itself (it just one dbus call: addInterface(in s zone, in s interface, …) based on new Zone=string setting in .netdev file. Hook can determine which zone interface should belong to and call firewall-cmd --zone=zone --add-interface=interface If firewalld shall be dynamic then it really should listen to rtnl on its own. It's the wrong way round, you don't want to to call into higher level software from lower level one. It's the higher level software that should subscribe to changes from the lower level software. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
On 11/04/2014 06:07 PM, Tomasz Torcz wrote: Example: I'd like to add interface to proper firewalld zone. Ideally it could be done by networkd itself (it just one dbus call: addInterface(in s zone, in s interface, …) based on new Zone=string setting in .netdev file. Hook can determine which zone interface should belong to and call firewall-cmd --zone=zone --add-interface=interface I dont think there is much future in firewalld hence I was looking into integrating nftables with systemd using it's kernel api since it seems like a nice feature to be able to add iptables rules to units,netdevices,containers JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
On Tue, 2014-11-04 at 19:40 +0100, Lennart Poettering wrote: BOn Tue, 04.11.14 19:07, Tomasz Torcz (to...@pipebreaker.pl) wrote: On Thu, Oct 02, 2014 at 08:36:10AM +0200, Lennart Poettering wrote: On Wed, 01.10.14 21:36, Cameron Norman (camerontnor...@gmail.com) wrote: Hello, ifupdown [1], NetworkManager, and WICD all support hooks for when a 1;3409;0c network interface is configured or deconfigured (before and after these actions). Are there any plans to support something along these lines? If so, what will that look like? If there are no plans, how do networkd's developers feel about adding the feature (will not merge, or will accept patches, etc.) ? Can you be more specific what precisely you intend to hook in there? I'd really prefer if we could find different solutions for the common usecases. Example: I'd like to add interface to proper firewalld zone. Ideally it could be done by networkd itself (it just one dbus call: addInterface(in s zone, in s interface, …) based on new Zone=string setting in .netdev file. Hook can determine which zone interface should belong to and call firewall-cmd --zone=zone --add-interface=interface If firewalld shall be dynamic then it really should listen to rtnl on its own. It's the wrong way round, you don't want to to call into higher level software from lower level one. It's the higher level software that should subscribe to changes from the lower level software. firewalld can't get the information that WiFi network Starbucks should be locked down more than your home network. How is it supposed to get that information just listening to rtnl or other kernel events? The kernel doesn't care; the only source of that information is the connection manager. Dan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
On Thu, 09.10.14 18:38, Cameron Norman (camerontnor...@gmail.com) wrote: actually not using avahi-autoipd is the way you really want to go. Especially since networkd will do IPv4LL setup for you anyway. Same applies to ethtool hooks since they should be done by link files and configured by udev. udev was indeed my first thought for ethtool, however how would the ethtool commands be hooked in on containers? Or is ethtool not relevant there? Which ethtool commands do you precisely need in your containers? I'd suggest adding support for useful ethtool commands directly to networkd, exposed via friendly configuration options, so that the fact that it is an ethtool command is just an implementation detail. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
On Fri, Oct 10, 2014 at 11:40 PM, Dale R. Worley wor...@alum.mit.edu wrote: From: Tom Gundersen t...@jklm.no What we do, however, is to expose the configuration state using the sd-network C API, which external programs can watch and react on (see how timesyncd and resolved currently works). In a situation where one wants to do what a hook does, having a separate daemon program that watches for an event and then invokes the hook when the event happens is not a good solution -- it replaces the hook with an entire daemon. I am not experienced, but from what little I know about systemd, the natural way would seem to be to write a new unit file with the appropriate dependencies. The event that should call the hook is when some unit finishes starting, and then the new unit would then be started. Well, in some cases you can do this. For instance, we have the network-online.target which gets triggered for some notion of online. However, if you want more fine-grained control than any of the existing units give you, you probably have to hook into rtnl/networkd/udev events to get precisely what you want. For any non-trivial setup, this is likely what you want anyway as you probably need to react to the network coming and going (and not only when it first gets configured). For a few examples of how this hook-up can be done, see networkd-wait-online, timesyncd and resolved in the systemd repo. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
On Fri, 10.10.14 17:40, Dale R. Worley (wor...@alum.mit.edu) wrote: From: Tom Gundersen t...@jklm.no What we do, however, is to expose the configuration state using the sd-network C API, which external programs can watch and react on (see how timesyncd and resolved currently works). In a situation where one wants to do what a hook does, having a separate daemon program that watches for an event and then invokes the hook when the event happens is not a good solution -- it replaces the hook with an entire daemon. I am not experienced, but from what little I know about systemd, the natural way would seem to be to write a new unit file with the appropriate dependencies. The event that should call the hook is when some unit finishes starting, and then the new unit would then be started. The new unit's ExecStart command would be the desired invocation of the hook. Does that make sense? If it does, it might be useful to write a beginner's guide on how to construct and insert such a unit into a system. Any synchronous hooks (regardless if implemented via direct callouts or via systemd units) are something I really want to avoid here. Networking is generally asynchronous, so pretending we could do things synchronously here sounds making a promise we can't keep, after all other apps usually watch connectivity directly via rtnl and such. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
On Fri, Oct 10, 2014 at 3:38 AM, Cameron Norman camerontnor...@gmail.com wrote: udev was indeed my first thought for ethtool, however how would the ethtool commands be hooked in on containers? Or is ethtool not relevant there? In a container you'll either have devices that you have moved in from the outside (these should be configured (by udev) before moving them inside), or virtual devices that are created from inside the container (which should be just created in the right way in the first place without the need to change their settings after they appear), so in general I would say that ethtool is not relevant in containers. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
On Thu, Oct 09, 2014 at 07:24:07AM +0200, Marcel Holtmann wrote: For the wpa_supplicant, we are going to fix that one with a proper daemon soon. Interesting. Can you shed some light on this? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
From: Tom Gundersen t...@jklm.no What we do, however, is to expose the configuration state using the sd-network C API, which external programs can watch and react on (see how timesyncd and resolved currently works). In a situation where one wants to do what a hook does, having a separate daemon program that watches for an event and then invokes the hook when the event happens is not a good solution -- it replaces the hook with an entire daemon. I am not experienced, but from what little I know about systemd, the natural way would seem to be to write a new unit file with the appropriate dependencies. The event that should call the hook is when some unit finishes starting, and then the new unit would then be started. The new unit's ExecStart command would be the desired invocation of the hook. Does that make sense? If it does, it might be useful to write a beginner's guide on how to construct and insert such a unit into a system. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
El mié, 8 de oct 2014 a las 10:24 , Marcel Holtmann mar...@holtmann.org escribió: Hi Cameron, ifupdown [1], NetworkManager, and WICD all support hooks for when a network interface is configured or deconfigured (before and after these actions). Are there any plans to support something along these lines? If so, what will that look like? If there are no plans, how do networkd's developers feel about adding the feature (will not merge, or will accept patches, etc.) ? I am sceptical to adding hooks, so would need a lot of convincing. What we do, however, is to expose the configuration state using the sd-network C API, which external programs can watch and react on (see how timesyncd and resolved currently works). Does the C API allow programs to temporarily stall bringing up or down the interface, or does it only deliver signals of if state? No it does not allow synchronous hooks. Only asynchronous notification is supported. Out of curiosity, where does your aversion to hooks come from? Does it add significant complication code wise, or is it more with respect to using networkd before any filesystems are mounted (thus the hook files would not be present)? Well, we want networkd to be clean and properly written, and I simply have the suspicion that if start allowing glueing in badly integrated stuff via shell scripts, we'll have a hard time to ever fix this again. I mean, network management solutions that shell out to external tools we have enough, but networkd is really not supposed to be like that. It shouldn't just be a glued together thing, but somewhat uniform. Ok, that is a good reason, what I had slightly imagined. Now that I have looked in the hook dirs of ifupdown more closely, I have noticed pretty much only async stuff, except for some ethtool, wpasupplicant, and avahi-autoipd scripts. The avahi-autoipd one seems like it may be misplaced, and is probably just fine in post-down (which is async, compared to down). actually not using avahi-autoipd is the way you really want to go. Especially since networkd will do IPv4LL setup for you anyway. Same applies to ethtool hooks since they should be done by link files and configured by udev. udev was indeed my first thought for ethtool, however how would the ethtool commands be hooked in on containers? Or is ethtool not relevant there? Thanks, -- Cameron ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
On Thu, 02.10.14 19:48, Cameron Norman (camerontnor...@gmail.com) wrote: On Wed, Oct 1, 2014 at 10:36 PM, Tom Gundersen t...@jklm.no wrote: Hi Cameron, On Thu, Oct 2, 2014 at 6:36 AM, Cameron Norman camerontnor...@gmail.com wrote: ifupdown [1], NetworkManager, and WICD all support hooks for when a network interface is configured or deconfigured (before and after these actions). Are there any plans to support something along these lines? If so, what will that look like? If there are no plans, how do networkd's developers feel about adding the feature (will not merge, or will accept patches, etc.) ? I am sceptical to adding hooks, so would need a lot of convincing. What we do, however, is to expose the configuration state using the sd-network C API, which external programs can watch and react on (see how timesyncd and resolved currently works). Does the C API allow programs to temporarily stall bringing up or down the interface, or does it only deliver signals of if state? No it does not allow synchronous hooks. Only asynchronous notification is supported. Out of curiosity, where does your aversion to hooks come from? Does it add significant complication code wise, or is it more with respect to using networkd before any filesystems are mounted (thus the hook files would not be present)? Well, we want networkd to be clean and properly written, and I simply have the suspicion that if start allowing glueing in badly integrated stuff via shell scripts, we'll have a hard time to ever fix this again. I mean, network management solutions that shell out to external tools we have enough, but networkd is really not supposed to be like that. It shouldn't just be a glued together thing, but somewhat uniform. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
On Wed, Oct 8, 2014 at 2:26 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 02.10.14 19:48, Cameron Norman (camerontnor...@gmail.com) wrote: On Wed, Oct 1, 2014 at 10:36 PM, Tom Gundersen t...@jklm.no wrote: Hi Cameron, On Thu, Oct 2, 2014 at 6:36 AM, Cameron Norman camerontnor...@gmail.com wrote: ifupdown [1], NetworkManager, and WICD all support hooks for when a network interface is configured or deconfigured (before and after these actions). Are there any plans to support something along these lines? If so, what will that look like? If there are no plans, how do networkd's developers feel about adding the feature (will not merge, or will accept patches, etc.) ? I am sceptical to adding hooks, so would need a lot of convincing. What we do, however, is to expose the configuration state using the sd-network C API, which external programs can watch and react on (see how timesyncd and resolved currently works). Does the C API allow programs to temporarily stall bringing up or down the interface, or does it only deliver signals of if state? No it does not allow synchronous hooks. Only asynchronous notification is supported. Out of curiosity, where does your aversion to hooks come from? Does it add significant complication code wise, or is it more with respect to using networkd before any filesystems are mounted (thus the hook files would not be present)? Well, we want networkd to be clean and properly written, and I simply have the suspicion that if start allowing glueing in badly integrated stuff via shell scripts, we'll have a hard time to ever fix this again. I mean, network management solutions that shell out to external tools we have enough, but networkd is really not supposed to be like that. It shouldn't just be a glued together thing, but somewhat uniform. Ok, that is a good reason, what I had slightly imagined. Now that I have looked in the hook dirs of ifupdown more closely, I have noticed pretty much only async stuff, except for some ethtool, wpasupplicant, and avahi-autoipd scripts. The avahi-autoipd one seems like it may be misplaced, and is probably just fine in post-down (which is async, compared to down). Thank you, -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
Hi Cameron, ifupdown [1], NetworkManager, and WICD all support hooks for when a network interface is configured or deconfigured (before and after these actions). Are there any plans to support something along these lines? If so, what will that look like? If there are no plans, how do networkd's developers feel about adding the feature (will not merge, or will accept patches, etc.) ? I am sceptical to adding hooks, so would need a lot of convincing. What we do, however, is to expose the configuration state using the sd-network C API, which external programs can watch and react on (see how timesyncd and resolved currently works). Does the C API allow programs to temporarily stall bringing up or down the interface, or does it only deliver signals of if state? No it does not allow synchronous hooks. Only asynchronous notification is supported. Out of curiosity, where does your aversion to hooks come from? Does it add significant complication code wise, or is it more with respect to using networkd before any filesystems are mounted (thus the hook files would not be present)? Well, we want networkd to be clean and properly written, and I simply have the suspicion that if start allowing glueing in badly integrated stuff via shell scripts, we'll have a hard time to ever fix this again. I mean, network management solutions that shell out to external tools we have enough, but networkd is really not supposed to be like that. It shouldn't just be a glued together thing, but somewhat uniform. Ok, that is a good reason, what I had slightly imagined. Now that I have looked in the hook dirs of ifupdown more closely, I have noticed pretty much only async stuff, except for some ethtool, wpasupplicant, and avahi-autoipd scripts. The avahi-autoipd one seems like it may be misplaced, and is probably just fine in post-down (which is async, compared to down). actually not using avahi-autoipd is the way you really want to go. Especially since networkd will do IPv4LL setup for you anyway. Same applies to ethtool hooks since they should be done by link files and configured by udev. For the wpa_supplicant, we are going to fix that one with a proper daemon soon. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
Op 2 okt. 2014, om 15:29 heeft Tom Gundersen t...@jklm.no het volgende geschreven: On Thu, Oct 2, 2014 at 2:20 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 02.10.14 13:00, Koen Kooi (k...@dominion.thruhere.net) wrote: Op 2 okt. 2014, om 07:36 heeft Tom Gundersen t...@jklm.no het volgende geschreven: Hi Cameron, On Thu, Oct 2, 2014 at 6:36 AM, Cameron Norman camerontnor...@gmail.com wrote: ifupdown [1], NetworkManager, and WICD all support hooks for when a network interface is configured or deconfigured (before and after these actions). Are there any plans to support something along these lines? If so, what will that look like? If there are no plans, how do networkd's developers feel about adding the feature (will not merge, or will accept patches, etc.) ? I am sceptical to adding hooks, so would need a lot of convincing. What we do, however, is to expose the configuration state using the sd-network C API, which external programs can watch and react on (see how timesyncd and resolved currently works). For specific hooks, we may want to integrate them directly upstream, but it really depends on what functionality you have in mind. For my use-case (fiber 'modem' doing PPPoE over vlan) I'd like to launch accelpppd to do PPPoE as soon as the vlan is up. That get me my internet back a few ms earlier when rebooting the modem :) Hmm, Tom has some patches adding native pppoe support to networkd (without pppd), iirc. Might be a better option to finish those. Tom? Yes, I have some WIP patches to do PPPoE directly from networkd [0]. If you are interested in using this, I'll clean it up and get it ready for merging/testing. I'm certainly interested, but I can't promise to test it in a timely fashion since it needs to run on my fiber modem. regards, Koen Cheers, Tom [0]: http://cgit.freedesktop.org/~tomegun/systemd/log/?h=ppp ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
On Wed, 01.10.14 21:36, Cameron Norman (camerontnor...@gmail.com) wrote: Hello, ifupdown [1], NetworkManager, and WICD all support hooks for when a network interface is configured or deconfigured (before and after these actions). Are there any plans to support something along these lines? If so, what will that look like? If there are no plans, how do networkd's developers feel about adding the feature (will not merge, or will accept patches, etc.) ? Can you be more specific what precisely you intend to hook in there? I'd really prefer if we could find different solutions for the common usecases. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
Op 2 okt. 2014, om 07:36 heeft Tom Gundersen t...@jklm.no het volgende geschreven: Hi Cameron, On Thu, Oct 2, 2014 at 6:36 AM, Cameron Norman camerontnor...@gmail.com wrote: ifupdown [1], NetworkManager, and WICD all support hooks for when a network interface is configured or deconfigured (before and after these actions). Are there any plans to support something along these lines? If so, what will that look like? If there are no plans, how do networkd's developers feel about adding the feature (will not merge, or will accept patches, etc.) ? I am sceptical to adding hooks, so would need a lot of convincing. What we do, however, is to expose the configuration state using the sd-network C API, which external programs can watch and react on (see how timesyncd and resolved currently works). For specific hooks, we may want to integrate them directly upstream, but it really depends on what functionality you have in mind. For my use-case (fiber 'modem' doing PPPoE over vlan) I'd like to launch accelpppd to do PPPoE as soon as the vlan is up. That get me my internet back a few ms earlier when rebooting the modem :) regards, Koen ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
On Thu, 02.10.14 13:00, Koen Kooi (k...@dominion.thruhere.net) wrote: Op 2 okt. 2014, om 07:36 heeft Tom Gundersen t...@jklm.no het volgende geschreven: Hi Cameron, On Thu, Oct 2, 2014 at 6:36 AM, Cameron Norman camerontnor...@gmail.com wrote: ifupdown [1], NetworkManager, and WICD all support hooks for when a network interface is configured or deconfigured (before and after these actions). Are there any plans to support something along these lines? If so, what will that look like? If there are no plans, how do networkd's developers feel about adding the feature (will not merge, or will accept patches, etc.) ? I am sceptical to adding hooks, so would need a lot of convincing. What we do, however, is to expose the configuration state using the sd-network C API, which external programs can watch and react on (see how timesyncd and resolved currently works). For specific hooks, we may want to integrate them directly upstream, but it really depends on what functionality you have in mind. For my use-case (fiber 'modem' doing PPPoE over vlan) I'd like to launch accelpppd to do PPPoE as soon as the vlan is up. That get me my internet back a few ms earlier when rebooting the modem :) Hmm, Tom has some patches adding native pppoe support to networkd (without pppd), iirc. Might be a better option to finish those. Tom? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
On Thu, Oct 2, 2014 at 2:20 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 02.10.14 13:00, Koen Kooi (k...@dominion.thruhere.net) wrote: Op 2 okt. 2014, om 07:36 heeft Tom Gundersen t...@jklm.no het volgende geschreven: Hi Cameron, On Thu, Oct 2, 2014 at 6:36 AM, Cameron Norman camerontnor...@gmail.com wrote: ifupdown [1], NetworkManager, and WICD all support hooks for when a network interface is configured or deconfigured (before and after these actions). Are there any plans to support something along these lines? If so, what will that look like? If there are no plans, how do networkd's developers feel about adding the feature (will not merge, or will accept patches, etc.) ? I am sceptical to adding hooks, so would need a lot of convincing. What we do, however, is to expose the configuration state using the sd-network C API, which external programs can watch and react on (see how timesyncd and resolved currently works). For specific hooks, we may want to integrate them directly upstream, but it really depends on what functionality you have in mind. For my use-case (fiber 'modem' doing PPPoE over vlan) I'd like to launch accelpppd to do PPPoE as soon as the vlan is up. That get me my internet back a few ms earlier when rebooting the modem :) Hmm, Tom has some patches adding native pppoe support to networkd (without pppd), iirc. Might be a better option to finish those. Tom? Yes, I have some WIP patches to do PPPoE directly from networkd [0]. If you are interested in using this, I'll clean it up and get it ready for merging/testing. Cheers, Tom [0]: http://cgit.freedesktop.org/~tomegun/systemd/log/?h=ppp ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
On Wed, Oct 1, 2014 at 10:36 PM, Tom Gundersen t...@jklm.no wrote: Hi Cameron, On Thu, Oct 2, 2014 at 6:36 AM, Cameron Norman camerontnor...@gmail.com wrote: ifupdown [1], NetworkManager, and WICD all support hooks for when a network interface is configured or deconfigured (before and after these actions). Are there any plans to support something along these lines? If so, what will that look like? If there are no plans, how do networkd's developers feel about adding the feature (will not merge, or will accept patches, etc.) ? I am sceptical to adding hooks, so would need a lot of convincing. What we do, however, is to expose the configuration state using the sd-network C API, which external programs can watch and react on (see how timesyncd and resolved currently works). Does the C API allow programs to temporarily stall bringing up or down the interface, or does it only deliver signals of if state? Out of curiosity, where does your aversion to hooks come from? Does it add significant complication code wise, or is it more with respect to using networkd before any filesystems are mounted (thus the hook files would not be present)? Cheers, -- Cameron ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
Hi Cameron, On Thu, Oct 2, 2014 at 6:36 AM, Cameron Norman camerontnor...@gmail.com wrote: ifupdown [1], NetworkManager, and WICD all support hooks for when a network interface is configured or deconfigured (before and after these actions). Are there any plans to support something along these lines? If so, what will that look like? If there are no plans, how do networkd's developers feel about adding the feature (will not merge, or will accept patches, etc.) ? I am sceptical to adding hooks, so would need a lot of convincing. What we do, however, is to expose the configuration state using the sd-network C API, which external programs can watch and react on (see how timesyncd and resolved currently works). For specific hooks, we may want to integrate them directly upstream, but it really depends on what functionality you have in mind. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
