Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
On Wed, Nov 6, 2013 at 12:32 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 06.11.13 02:57, Tom Gundersen (t...@jklm.no) wrote: Gateway=192.168.1.1 Address=label@192.168.1.23/24 Address=fe80::9aee:94ff:fe3f:c618/64 Hmm, what's the plan regarding confguration of scopes and other attributes of addresses? Is the label@ syntax your invention or has this been used elsewhere (I am not opposed to the syntax, just curious). Good question. The @ syntax is my invention, but i'm very happy to change it if anyone has a better suggestion. For the other properties we might want, I would really like to find a syntax to get them all on one line. I'll try figure out a more or less exhaustive list of the properties we might want to support and suggest a syntax for it. In the meantime I'll commit this without the label@ support, as the rest should be uncontroversial, and then we can add back the labeling when we are sure it is the way we want it. I have my suspicions that that won't work out since there already are quite a few properties for addresses, no? There's scope, flags, label. For Point-To-Point stuff the address needs to be paired with a local one, and in other cases with a broadcast address. We should at least try to normalize this into different sections, no? Something that might work is to allow seperate [Address] sections for the complicated cases on top of Address= for the usual cases? I now pushed this stuff out, and I agree that we will end up needing separate [Address] (and also [Route]) sections in addition to the simple Address=address/prefixlen and Gateway=address in the [Network] section. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
On Thu, 07.11.13 01:45, Tom Gundersen (t...@jklm.no) wrote: On Wed, Nov 6, 2013 at 7:56 AM, Holger Winkelmann [TP] h...@travelping.com wrote: We really like to see this direct, how ever would it not better to join efforts for network management. I.e. arch Linux claims with netctl [1] to do network management the systems way. and there are a few other attempts to do network managent. I.e. netconfd [2] of openWRT is doing network management (kind of monolitic) as a daemon as well which can be configured via Bus RPC. (OK ubus in this case). Not to mention the desktop centric network manager. We have looked at and discussed various alternatives, in particular with the connman guys. However, none of the existing solutions seem amendable to what we want for the server/initrd, some are too simplistic and e.g. does not really allow for handling the global state that we will need, or compartmentalizes too much the different protocols/state machines, whilst others simply have a different focus (see Marcel's email in this thread as to why connman's focus is different from networkd's and why it makes sense to keep them separate). To clarify this: systemd-networkd is supposed to cover the initrd, container, server and (some) embedded usecases. However, use NM or connman for the interactive stuff (like wlans and suchlike) you need on laptops/desktops and mobile. The idea is that this can work jointly with NM/connman in some ways or another. For example you can make use of .link files even with interfaces that otherwise are handled by connman/NM, but for IP config you have to chose one. 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] [RFC][PATCH] networkd: add a basic network daemon
Hi, To clarify this: systemd-networkd is supposed to cover the initrd, container, server and (some) embedded usecases. However, use NM or connman for the interactive stuff (like wlans and suchlike) you need on laptops/desktops and mobile. Will this cover the UseCase of having a DHCP enabled Interface which starts asking for IP if the interface is coming up? or is this already considered as interactive uses case? in embedded this is often a standard configuration as such devices don't have a interactive interface and assigning a IP via DHCP makes the live much easier. currently we integrate http://0pointer.de/lennart/projects/ifplugd/ The idea is that this can work jointly with NM/connman in some ways or another. For example you can make use of .link files even with interfaces that otherwise are handled by connman/NM, but for IP config you have to chose one. Lennart -- Lennart Poettering, Red Hat -- Holger Winkelmann ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
On Thu, Nov 7, 2013 at 4:03 PM, Holger Winkelmann [TP] h...@travelping.com wrote: To clarify this: systemd-networkd is supposed to cover the initrd, container, server and (some) embedded usecases. However, use NM or connman for the interactive stuff (like wlans and suchlike) you need on laptops/desktops and mobile. Will this cover the UseCase of having a DHCP enabled Interface which starts asking for IP if the interface is coming up? or is this already considered as interactive uses case? in embedded this is often a standard configuration as such devices don't have a interactive interface and assigning a IP via DHCP makes the live much easier. A native and fast DHCP client will be part of it, yes, it is needed in the initrd. Not sure though when we will get there though.. currently we integrate http://0pointer.de/lennart/projects/ifplugd/ Urks, the 90s calling. :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
A native and fast DHCP client will be part of it, yes, it is needed in the initrd. Not sure though when we will get there though. nice to hear. and right, having it in initrd is nice too. currently we integrate http://0pointer.de/lennart/projects/ifplugd/ Urks, the 90s calling. :) Yes, embedded was so old style before... Kay -- Holger Winkelmann ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
good morning,
We really like to see this direct, how ever would it not better to join
efforts for network management. I.e. arch Linux claims with netctl [1]
to do network management the systems way. and there are a few other
attempts to do network managent. I.e. netconfd [2] of openWRT is doing
network management (kind of monolitic) as a daemon as well which can
be configured via Bus RPC. (OK ubus in this case). Not to mention
the desktop centric network manager.
Can somebody explain the goals of systemd-networkd? If this just a small
basic tool will be replaced if more features are required or a new attempt
to for general network management?
[1] https://wiki.archlinux.org/index.php/netctl
https://github.com/joukewitteveen/netctl
[2] http://wiki.openwrt.org/doc/techref/netifd
BR,
Holger
- Original Message -
On Wed, 06.11.13 01:33, Tom Gundersen (t...@jklm.no) wrote:
Short-term TODO:
- make rtnl calls asynchronous
Don't wait for too long for this! The longer you wait the more code you
have to rework for this. And you shouldn't underestimate how complex
changes from sync to async are...
Gateway=192.168.1.1
Address=label@192.168.1.23/24
Address=fe80::9aee:94ff:fe3f:c618/64
Hmm, what's the plan regarding confguration of scopes and other
attributes of addresses? Is the label@ syntax your invention or has
this been used elsewhere (I am not opposed to the syntax, just curious).
+sd_event_add_io(m-event,
+udev_monitor_get_fd(m-udev_monitor),
+EPOLLIN,
+manager_dispatch_link_udev,
+(void *)m,
+m-udev_event_source);
Missing return value check! (and cast to void* is unnecessary, in C
all pointers automatically downgrade to void* without casting anyway)
+if (r 0) {
+log_warning(Colud not parse config file %s: %s,
filename, strerror(-r));
^^ Typo
+return r;
+} else
+log_debug(Parsed configuration file %s, filename);
+
+network-filename = strdup(filename);
OOM check missing!
+static void networks_free(Manager *manager) {
+Network *network, *network_next;
+
+if (!manager)
+return;
+
+LIST_FOREACH_SAFE(networks, network, network_next,
manager-networks) {
+network_free(network);
+}
I usually just use:
while ((network = manager-networks))
network_free(free);
Which should do the job too.
+struct Link {
+uint64_t ifindex;
Hmm is this really an uint64_t? if_nametoindex(3) suggestes it's an
unsigned?
But yeah, looks great. Commit.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Holger Winkelmann
Managing Director
email: h...@travelping.com
phone: +49-391-819099-223
mobil: +49-171-5594745
http://www.linkedin.com/in/hwinkel
- enabling your networks -
Travelping GmbH phone: +49-391-8190990
Roentgenstr. 13 fax: +49-391-819099299
D-39108 Magdeburg email: i...@travelping.com
GERMANY web: http://www.travelping.com
Company Registration: Amtsgericht Stendal Reg No.: HRB 10578
Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780
--
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
Hi Auke, This daemon listens for and configures network devices tagged with 'systemd-networkd'. By default, no devices are tagged so this daemon can safely run in parallel with existing network daemons/scripts. Networks are configured in /etc/systemd/network/*.network. The first .network file that matches a given link is applied. The matching logic is similar to the one for .link files, but additionally supports matching on interface name. The mid-term aim is to provide an alternative to ad-hoc scripts currently used in initrd's and for wired setups that don't change much (e.g., as seen on servers/and some embedded systems). Currently, static addresses and a gateway can be configured, mostly as a proof of concept. I expect to expand on this as soon as we are agreed on the basic design. Comments, testing and contributions greatly appreciated! alright, I'll comment, but it took me 5 minutes to clear the coffee off my monitor... Looking at the feature list, why are you not contributing to connman instead? It seems you're going to be duplicating a ton of code And connman does what your goal is, meaning you can pre-provision static configurations without any of the more involved dependencies. It has a DBus interface for status, configuration etc I'm frankly shocked a bit, not sure what to say. Maybe this is a great thing, but, without a doubt someone will want to convert this code long term into connman / NM, and at that point we have 3 standards, not 2. Best to try and stick to 2 standards and fix the one that has the best long-term prospective value. I have a little bit different viewpoint here. I do not look at what are the low-level technical tasks or the implementation, I look at the users. We have two types of users for networking. The first type is sysadmins and the second type is end users. These two groups are as different as it gets in their use cases and how they expect things to be done. When I look at sysadmins, then you target servers, datacenters, could and containers. So headless systems that are not mobile. They are mainly Ethernet based and configure once and not worry about anymore. As an extra added benefit some of these have to configure everything as early as the initramfs. And they want simple configuration files and command line tools. Looking at end users, I see desktop, laptops, phones and all these embedded devices like thermostats, fridges and whatever you can think of. Things where networking can mean also WiFi, cellular even sensor networks like Bluetooth 6loWPAN. It is a dynamic world and needs configuration that is targeted for non-technical people. And end users need a nice UI for their needs. It is also not one UI, there will be many and so APIs need to be simple and designed for that user base in mind. You normally do not take your 12-core Xeon server to the coffee shop around the corner and want to use its public WiFi with a hotspot login. If you do, please take a picture ;) Trying to smash these together seems rather crazy to me. I looks simple in the beginning, but the devil is in the details. There is a reason why ConnMan stayed out of the datacenter world. So the way I see it is that networkd should own the initramfs and sysadmin side of things. And ConnMan will handle the end user side. What this means is that both work in harmony together. Think of it like this, the system boots with networkd in initramfs and then you either start networkd for taking over the initramfs configuration and running in datacenter mode. Or you start ConnMan for running in desktop mode. It is a little bit over-simplified, but I think you get the basic idea. So networkd and ConnMan for example will share a lot of code. And what we will be doing is to contribute the shared pieces into networkd. One prime example is DHCP of course. And the rest we will figure out as networkd progresses. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
On 11/06/2013 09:37 AM, Marcel Holtmann wrote: Looking at the feature list, why are you not contributing to connman instead? It seems you're going to be duplicating a ton of code And connman does what your goal is, meaning you can pre-provision static configurations without any of the more involved dependencies. It has a DBus interface for status, configuration etc I'm frankly shocked a bit, not sure what to say. Maybe this is a great thing, but, without a doubt someone will want to convert this code long term into connman / NM, and at that point we have 3 standards, not 2. Best to try and stick to 2 standards and fix the one that has the best long-term prospective value. I have a little bit different viewpoint here. I do not look at what are the low-level technical tasks or the implementation, I look at the users. We have two types of users for networking. The first type is sysadmins and the second type is end users. These two groups are as different as it gets in their use cases and how they expect things to be done. When I look at sysadmins, then you target servers, datacenters, could and containers. So headless systems that are not mobile. They are mainly Ethernet based and configure once and not worry about anymore. As an extra added benefit some of these have to configure everything as early as the initramfs. And they want simple configuration files and command line tools. Looking at end users, I see desktop, laptops, phones and all these embedded devices like thermostats, fridges and whatever you can think of. Things where networking can mean also WiFi, cellular even sensor networks like Bluetooth 6loWPAN. It is a dynamic world and needs configuration that is targeted for non-technical people. And end users need a nice UI for their needs. It is also not one UI, there will be many and so APIs need to be simple and designed for that user base in mind. You normally do not take your 12-core Xeon server to the coffee shop around the corner and want to use its public WiFi with a hotspot login. If you do, please take a picture ;) Trying to smash these together seems rather crazy to me. I looks simple in the beginning, but the devil is in the details. There is a reason why ConnMan stayed out of the datacenter world. So the way I see it is that networkd should own the initramfs and sysadmin side of things. And ConnMan will handle the end user side. What this means is that both work in harmony together. Think of it like this, the system boots with networkd in initramfs and then you either start networkd for taking over the initramfs configuration and running in datacenter mode. Or you start ConnMan for running in desktop mode. It is a little bit over-simplified, but I think you get the basic idea. So networkd and ConnMan for example will share a lot of code. And what we will be doing is to contribute the shared pieces into networkd. One prime example is DHCP of course. And the rest we will figure out as networkd progresses. Regards Marcel Have you completed your recherche on all the existing implementations for network configuration? Have you already looked at netifd? Its authors looked at conman and at NM and decided to write netifd. Its for Wi-Fi and complex configurations, yet the same guys also wrote procd, which is similar to systemd. Its for embedded, so its tiny. Also, what about Bluetooth? It is wireless and requires some low-level thing, that is Core OS-ish. Regards, ScotX [1] http://wiki.openwrt.org/doc/techref/netifd ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
'Twas brillig, and Kok, Auke-jan H at 06/11/13 02:08 did gyre and gimble: alright, I'll comment, but it took me 5 minutes to clear the coffee off my monitor... Looking at the feature list, why are you not contributing to connman instead? AFAIK, Tom has had plenty discussions with Marcel and Daniel on the connman side. I actually made sure Tom met Daniel in Edinburgh a couple weeks ago for this reason! So I don't think you need to worry too much about conman vs. systemd-networkd rather think of it as a rather collaborative effort in general. Quite where all the code and shared bits live in the end I don't know but I think this process is going about things in the right way to come to a good end-solution. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
Hi Lennart,
+struct Link {
+uint64_t ifindex;
Hmm is this really an uint64_t? if_nametoindex(3) suggestes it's an
unsigned?
actually using if_nametoindex() is bad idea as well. That should be turned into
an async RTNL call as well. We better just cache the ifname to ifindex mapping
internally and then just do a lookup.
The problem with RTNL is that there are some global locks in there. So if you
are really unlucky, then either glibc uses and ioctl that blocks and it uses
internally netlink synchronously. If you serialize all RTNL netlink
communication via asynchronous calls, then you never have to worry about that
lock affecting you.
And for the ifindex type, the one that is communicated over RTNL netlink is the
one that counts. Everything else is just some ancient leftover. And I bet you
find tons of differences everywhere. I personally have not found a single truth.
Regards
Marcel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
On Wed, Nov 6, 2013 at 1:32 PM, Lennart Poettering lenn...@poettering.net wrote: I have my suspicions that that won't work out since there already are quite a few properties for addresses, no? There's scope, flags, label. For Point-To-Point stuff the address needs to be paired with a local one, and in other cases with a broadcast address. We should at least try to normalize this into different sections, no? Hmm, when is explicitly setting the broadcast address ever necessary? -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
On 11/06/2013 03:00 PM, Lennart Poettering wrote: On Wed, 06.11.13 14:14, Mantas Mikulėnas (graw...@gmail.com) wrote: On Wed, Nov 6, 2013 at 1:32 PM, Lennart Poettering lenn...@poettering.net wrote: I have my suspicions that that won't work out since there already are quite a few properties for addresses, no? There's scope, flags, label. For Point-To-Point stuff the address needs to be paired with a local one, and in other cases with a broadcast address. We should at least try to normalize this into different sections, no? Hmm, when is explicitly setting the broadcast address ever necessary? There are some cases like that in hosting setups where people play games with this so that they can use tiny subnets while packing hosts as close as they can wihouting losing one (or two) adresses in each subnet for broadcast (and as network address)... Interesting first time I hear of this and I assume these games became unnecessary with ipv6 thus no need to keep Broadcast around no? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
On Wed, 06.11.13 15:09, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 11/06/2013 03:00 PM, Lennart Poettering wrote: On Wed, 06.11.13 14:14, Mantas Mikulėnas (graw...@gmail.com) wrote: On Wed, Nov 6, 2013 at 1:32 PM, Lennart Poettering lenn...@poettering.net wrote: I have my suspicions that that won't work out since there already are quite a few properties for addresses, no? There's scope, flags, label. For Point-To-Point stuff the address needs to be paired with a local one, and in other cases with a broadcast address. We should at least try to normalize this into different sections, no? Hmm, when is explicitly setting the broadcast address ever necessary? There are some cases like that in hosting setups where people play games with this so that they can use tiny subnets while packing hosts as close as they can wihouting losing one (or two) adresses in each subnet for broadcast (and as network address)... Interesting first time I hear of this and I assume these games became unnecessary with ipv6 thus no need to keep Broadcast around no? Well, IPv4 will be with us for a long time still, so we cannot just make it go away, just because it might not be that important with IPv6 anymore... 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] [RFC][PATCH] networkd: add a basic network daemon
On 11/06/2013 12:33 AM, Tom Gundersen wrote: [Match] MACAddress= Path= Driver= Type= Name= [Network] Description= [IP] Gateway=192.168.1.1 Address=label@192.168.1.23/24 Address=fe80::9aee:94ff:fe3f:c618/64 Hmm.. Cant we try to follow the same construct as the other units? Something like this perhaps ( I think these for case cover more less the most common parts )... The default device present spawn *when link is detected* unit Type=dhcp network@network device.network [Unit] Description=Network device %I [Service] Type=|dhcp Rest provided by dhcp |The administrator configurable unit Type=Static em1.network [Unit] Description=Network device em1 [Service] Type=static Address=192.168.0.1/24 [Install] WantedBy=multi-user.target The administrator configurable unit Type=bridge bridge0.network [Unit] Description=Network device bridge 0 Master=em1 Slave=em2 [Service] Type=bridge [Install] WantedBy=multi-user.target The administrator configurable unit Type=bridge bond0.network [Unit] Description=Network device bonding 0 Master=bond0 Slave=em1,em2 [Service] Type=bonding Address=192.168.0.1/24 [Install] WantedBy=multi-user.target ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
On Wed, Nov 6, 2013 at 1:32 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Kok, Auke-jan H at 06/11/13 02:08 did gyre and gimble: alright, I'll comment, but it took me 5 minutes to clear the coffee off my monitor... Looking at the feature list, why are you not contributing to connman instead? AFAIK, Tom has had plenty discussions with Marcel and Daniel on the connman side. I actually made sure Tom met Daniel in Edinburgh a couple weeks ago for this reason! I guess I'm at fault for not attending those conferences ... So I don't think you need to worry too much about conman vs. systemd-networkd rather think of it as a rather collaborative effort in general. Quite where all the code and shared bits live in the end I don't know but I think this process is going about things in the right way to come to a good end-solution. Sorry if my post seemed out of line - I'm happy to see the thread here with comments from everyone that answer my concern and questions, and knowing that this was well coordinated now makes me quite positive about this effort. Marcel and me have certainly struggled with the problem that happens when you attempt to bring connman into a more server-like environment, so, I'm very pleased to see that there is a significant effort to bring an appropriate solution in this space that actually involves connman as well. Thanks! Auke PS Marcel - Now we just need to figure out what to do with that JavaScript engine for pacrunner and get it working ;^) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
Hi. This daemon is an offline daemon: it exposes no means for controlling it that other programs or users can manipulate. It is a standalone program that does what it does and cannot be spoken to. A DBus interface is, IMO, absolutely essential, and discussing your work without that ability to talk about how this software is going to operate with other systems, is premature and not productive. What particular new configuration system you make, what it does, is shaped first by what and how it can tell the outside world about what it's up to. Right now, it tells the outside world nothing and has no external interface. I'd love to see a DBus introspection document describing plans for what this program can either be brought to report, or what capabilities it can let other programs play with. -rektide ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
At Wed, 6 Nov 2013 07:56:32 +0100 (CET), Holger Winkelmann [TP] wrote: how ever would it not better to join efforts for network management. I.e. arch Linux claims with netctl [1] to do network management the systems way. ... [1] https://wiki.archlinux.org/index.php/netctl https://github.com/joukewitteveen/netctl For what it's worth, the author, Tom Gundersen, is one of the Arch Linux developers. Happy hacking, ~ Luke Shumaker ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
On Wed, Nov 6, 2013 at 5:00 AM, David Strauss da...@davidstrauss.net wrote: Another critical feature for server configs is bonding. It's possible right from Kickstart and with the normal configurations in Fedora. We use it on every bare-metal server we manage to get HA networking. Bonding (or probably teaming instead) is something we definitely want. Though I'll personally be working on the items in the TODO list first. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
On Wed, Nov 6, 2013 at 3:13 AM, Jan Engelhardt jeng...@inai.de wrote: On Wednesday 2013-11-06 02:57, Tom Gundersen wrote: Gateway=192.168.1.1 Address=label@192.168.1.23/24 Address=fe80::9aee:94ff:fe3f:c618/64 The @ syntax is my invention, but i'm very happy to change it if anyone has a better suggestion. Be sure to support Address=192.168.1.23/24 Because honestly, most people don't need more than the address and mask. Yes, this will definitely be supported, and everything else will be optional. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
On Wed, 06.11.13 01:33, Tom Gundersen (t...@jklm.no) wrote:
Short-term TODO:
- make rtnl calls asynchronous
Don't wait for too long for this! The longer you wait the more code you
have to rework for this. And you shouldn't underestimate how complex
changes from sync to async are...
Gateway=192.168.1.1
Address=label@192.168.1.23/24
Address=fe80::9aee:94ff:fe3f:c618/64
Hmm, what's the plan regarding confguration of scopes and other
attributes of addresses? Is the label@ syntax your invention or has
this been used elsewhere (I am not opposed to the syntax, just curious).
+sd_event_add_io(m-event,
+udev_monitor_get_fd(m-udev_monitor),
+EPOLLIN,
+manager_dispatch_link_udev,
+(void *)m,
+m-udev_event_source);
Missing return value check! (and cast to void* is unnecessary, in C
all pointers automatically downgrade to void* without casting anyway)
+if (r 0) {
+log_warning(Colud not parse config file %s: %s,
filename, strerror(-r));
^^ Typo
+return r;
+} else
+log_debug(Parsed configuration file %s, filename);
+
+network-filename = strdup(filename);
OOM check missing!
+static void networks_free(Manager *manager) {
+Network *network, *network_next;
+
+if (!manager)
+return;
+
+LIST_FOREACH_SAFE(networks, network, network_next,
manager-networks) {
+network_free(network);
+}
I usually just use:
while ((network = manager-networks))
network_free(free);
Which should do the job too.
+struct Link {
+uint64_t ifindex;
Hmm is this really an uint64_t? if_nametoindex(3) suggestes it's an unsigned?
But yeah, looks great. Commit.
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] [RFC][PATCH] networkd: add a basic network daemon
On Wed, Nov 6, 2013 at 2:25 AM, Lennart Poettering
lenn...@poettering.net wrote:
On Wed, 06.11.13 01:33, Tom Gundersen (t...@jklm.no) wrote:
Short-term TODO:
- make rtnl calls asynchronous
Don't wait for too long for this! The longer you wait the more code you
have to rework for this. And you shouldn't underestimate how complex
changes from sync to async are...
Yeah, it's top of the list ;-)
Gateway=192.168.1.1
Address=label@192.168.1.23/24
Address=fe80::9aee:94ff:fe3f:c618/64
Hmm, what's the plan regarding confguration of scopes and other
attributes of addresses? Is the label@ syntax your invention or has
this been used elsewhere (I am not opposed to the syntax, just curious).
Good question. The @ syntax is my invention, but i'm very happy to
change it if anyone has a better suggestion. For the other properties
we might want, I would really like to find a syntax to get them all on
one line. I'll try figure out a more or less exhaustive list of the
properties we might want to support and suggest a syntax for it. In
the meantime I'll commit this without the label@ support, as the
rest should be uncontroversial, and then we can add back the labeling
when we are sure it is the way we want it.
+sd_event_add_io(m-event,
+udev_monitor_get_fd(m-udev_monitor),
+EPOLLIN,
+manager_dispatch_link_udev,
+(void *)m,
+m-udev_event_source);
Missing return value check! (and cast to void* is unnecessary, in C
all pointers automatically downgrade to void* without casting anyway)
+if (r 0) {
+log_warning(Colud not parse config file %s: %s,
filename, strerror(-r));
^^ Typo
+return r;
+} else
+log_debug(Parsed configuration file %s, filename);
+
+network-filename = strdup(filename);
OOM check missing!
+static void networks_free(Manager *manager) {
+Network *network, *network_next;
+
+if (!manager)
+return;
+
+LIST_FOREACH_SAFE(networks, network, network_next,
manager-networks) {
+network_free(network);
+}
I usually just use:
while ((network = manager-networks))
network_free(free);
Which should do the job too.
+struct Link {
+uint64_t ifindex;
Hmm is this really an uint64_t? if_nametoindex(3) suggestes it's an
unsigned?
But yeah, looks great. Commit.
Thanks, will fix up your comments and commit.
Cheers,
Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
On Tue, Nov 5, 2013 at 4:33 PM, Tom Gundersen t...@jklm.no wrote: This daemon listens for and configures network devices tagged with 'systemd-networkd'. By default, no devices are tagged so this daemon can safely run in parallel with existing network daemons/scripts. Networks are configured in /etc/systemd/network/*.network. The first .network file that matches a given link is applied. The matching logic is similar to the one for .link files, but additionally supports matching on interface name. The mid-term aim is to provide an alternative to ad-hoc scripts currently used in initrd's and for wired setups that don't change much (e.g., as seen on servers/and some embedded systems). Currently, static addresses and a gateway can be configured, mostly as a proof of concept. I expect to expand on this as soon as we are agreed on the basic design. Comments, testing and contributions greatly appreciated! alright, I'll comment, but it took me 5 minutes to clear the coffee off my monitor... Looking at the feature list, why are you not contributing to connman instead? It seems you're going to be duplicating a ton of code And connman does what your goal is, meaning you can pre-provision static configurations without any of the more involved dependencies. It has a DBus interface for status, configuration etc I'm frankly shocked a bit, not sure what to say. Maybe this is a great thing, but, without a doubt someone will want to convert this code long term into connman / NM, and at that point we have 3 standards, not 2. Best to try and stick to 2 standards and fix the one that has the best long-term prospective value. Cheers, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
On Wednesday 2013-11-06 02:57, Tom Gundersen wrote: Gateway=192.168.1.1 Address=label@192.168.1.23/24 Address=fe80::9aee:94ff:fe3f:c618/64 The @ syntax is my invention, but i'm very happy to change it if anyone has a better suggestion. Be sure to support Address=192.168.1.23/24 Because honestly, most people don't need more than the address and mask. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
Another critical feature for server configs is bonding. It's possible right from Kickstart and with the normal configurations in Fedora. We use it on every bare-metal server we manage to get HA networking. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
