Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support
On Tue, 2014-05-27 at 13:39 +0200, David Herrmann wrote: I strongly disagree. One major example is Wifi-P2P which requires a DHCP-Server for ad-hoc P2P connections. A network-daemon manages the local address-space, so it should also be responsible of assigning those ranges to an ad-hoc DHCP server. In most current network-solutions it is awfully hard to integrate ad-hoc DHCP networks. Yes, everyone can configure a static pre-assigned DHCP range, but that's not going to work with dynamically created networks. This includes p2p-connections like Wifi-P2P, but also stuff like tethering, virtual devices and containers. I strongly agree with David here. Any form of tethering or WiFi P2P in addition to uplink network setup involving DHCPv4 clients just becomes impossible to maintain in a consistent way if the client and server parts are loosely coupled. With the wild west of IPv4 private addressing there needs to be a consistent and quick way of reacting to the newly acquired IPv4 subnet should it conflict with the existing one(s) handed out locally by the DHCPv4 server. This of course applies towards the client end usage as a virtual server/container setup is a more strictly controlled environment. Cheers, Patrik ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support
On Tue, 27.05.14 14:48, Tollef Fog Heen (tfh...@err.no) wrote: ]] Lennart Poettering If we set up links (and especially, create them like we do for veth), then hel, yeah we should be prepared to make sure everybody gets an address on it. Should we also include BGP, OSPF, RIP, ISIS (and their IPv6 variants) to make sure it's possible to push routes? I don't see that these are really that common on most Linux machines, except on border systems. I mean, they are uncommon enough that I never in my life touched a system with these in place, I must admit... I take DHCPv6 and IPv6 RA are a given that'll be implemented. Yes. 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] [PATCH 17/17] networkd: add dhcp server support
On Tue, 27.05.14 22:14, Kirill Elagin (kirela...@gmail.com) wrote: The container usecase alone is already the reason why I am so very sure I want this stuff, and that it needs to be in networkd, and just work. I want this fully automatic, so that we can create a hundred of veth tunnels, and trivially easy (simply by setting DHCPServer=yes for their .network file) make them automatically configured, passing the relevant configuration bits on. I'm sorry to intervene, but there are other ways to configure containers and similar stuff. I mean, systemd is great because it pioneered so many cool things. Why can't we do something new? For example, prohibit IPv4 for containers and VMs and require them to use IPv6 with link-local we don't really ever prohibit anything. People can do whatever they want to do... That said, I think IPv4 connectivity is kinda important if we ever want to minimize the differences between container-based virtualization and normal systems. I want containers to be as close to a real OS as possible and that includes being able to communicate with the usual internet. I mean, we will have a strong focus on making things work with IPv6 nicely, and I have the suspicion we can make a number of things nicer with Ipv6 than with IPv4 (since we could automatically assign an externally routable IPv6 address for each container, which is not really doable for IPv4). addresses which will eliminate the need for any kind of configuration. Pushing IPv6 forward is a good idea. But, well, if you find this unacceptable, what's wrong with IPv4LL? Ipv4LL is inherently not routable. We want something here though that can talk to the internet if it wants to. DHCP is complex (well, not _that_ complex, but still) and it's not always required. E.g. IPv6 networks can live without DHCP by using link-local addresses and, say, some basic NDP. It seems to me that IPv4LL should suffice for all the “container use-cases”. DHCP is actually one of the simplest protocols I am aware of... 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] [PATCH 17/17] networkd: add dhcp server support
Hi Zbyszek,
On 27 May 2014 04:38, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl
wrote:
On Mon, May 26, 2014 at 09:39:46PM +0200, Tom Gundersen wrote:
When enabled in [Network] it will set up a dhcp server on the
interface, listening
on one of its statically configured IPv4 addresses and with a fixed
size pool of
leases determined from it.
Hi Tom,
before looking at the code, a couple of general questions:
- does the DHCP server have to be part of networkd? Isn't the job
of acquiring addresses and giving out addresses separate and shouldn't
two different processes be responsible?
As the dhcp library will need (eventually) a lot of state from networkd and
to hook into various events, I think having it integrated will make our
lives much easier. However, as all the logic lives in the library,
splitting it out later (when we know exactly how it will all look) should
not be a problem if that ends up making more sense.
- why the fixed limit of 32 addresses? Shouldn't the default be to give
out all possible addresses except for the server one.
This should be configurable, but until we have figure out the syntax I just
hard coded this to make it easy to test.
[Match]
Name=ve-arch-tree
[Network]
Address=192.168.12.5/24
DHCPServer=yes
[Route]
Gateway=192.168.12.5
Destination=192.168.12.0/24
In this case we will configure ve-arch-tree with the address
192.168.12.5 and
hand out addresses in the range 192.168.12.6 - 192.168.12.38.
In the future, we should (as suggested by Lennart) introduce a syntax
to pick the
server address automatically.
---
src/network/networkd-link.c | 101
++-
src/network/networkd-network-gperf.gperf | 1 +
src/network/networkd.h | 5 ++
3 files changed, 93 insertions(+), 14 deletions(-)
diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
index 6677b94..b80a002 100644
--- a/src/network/networkd-link.c
+++ b/src/network/networkd-link.c
@@ -174,19 +174,6 @@ void link_drop(Link *link) {
return;
}
-static int link_enter_configured(Link *link) {
-assert(link);
-assert(link-state == LINK_STATE_SETTING_ROUTES);
-
-log_info_link(link, link configured);
-
-link-state = LINK_STATE_CONFIGURED;
-
-link_save(link);
-
-return 0;
-}
-
static void link_enter_unmanaged(Link *link) {
assert(link);
@@ -227,6 +214,16 @@ static int link_stop_clients(Link *link) {
}
}
+if (link-network-dhcp_server) {
+assert(link-dhcp_server);
+
+k = sd_dhcp_server_stop(link-dhcp_server);
+if (k 0) {
+log_warning_link(link, Could not stop DHCPv4
server: %s, strerror(-r));
+r = k;
+}
+}
+
return r;
}
@@ -245,6 +242,37 @@ static void link_enter_failed(Link *link) {
link_save(link);
}
+static int link_enter_configured(Link *link) {
+int r;
+
+assert(link);
+assert(link-network);
+assert(link-state == LINK_STATE_SETTING_ROUTES);
+
+
+if (link-network-dhcp_server) {
+log_debug_link(link, offering DHCPv4 leases);
+
+r = sd_dhcp_server_start(link-dhcp_server);
+if (r 0) {
+log_warning_link(link, could not start DHCPv4
server
+ instance: %s, strerror(-r));
+
+link_enter_failed(link);
+
+return 0;
+}
+}
+
+log_info_link(link, link configured);
+
+link-state = LINK_STATE_CONFIGURED;
+
+link_save(link);
+
+return 0;
+}
+
static int route_handler(sd_rtnl *rtnl, sd_rtnl_message *m, void
*userdata) {
Link *link = userdata;
int r;
@@ -1663,7 +1691,52 @@ static int link_configure(Link *link) {
}
}
-if (link_has_carrier(link-flags, link-kernel_operstate)) {
+if (link-network-dhcp_server) {
+Address *address;
+
+r = sd_dhcp_server_new(link-dhcp_server,
link-ifindex);
+if (r 0)
+return r;
+
+r = sd_dhcp_server_attach_event(link-dhcp_server,
NULL, 0);
+if (r 0)
+return r;
+
+LIST_FOREACH(addresses, address,
+ link-network-static_addresses) {
+struct in_addr pool_start;
+
+if (address-family != AF_INET)
+continue;
+
+/* currently this is picked essentially at
random */
+
Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support
2014-05-27 4:38 GMT+02:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl: On Mon, May 26, 2014 at 09:39:46PM +0200, Tom Gundersen wrote: When enabled in [Network] it will set up a dhcp server on the interface, listening on one of its statically configured IPv4 addresses and with a fixed size pool of leases determined from it. Hi Tom, before looking at the code, a couple of general questions: - does the DHCP server have to be part of networkd? Isn't the job of acquiring addresses and giving out addresses separate and shouldn't two different processes be responsible? I have to agree with Zbigniew here. This looks like feature creep. Also, IIRC, the scope of networkd was to establish network connections in a minimal environment, like an initramfs. I'm pretty sure we don't need a DHCP server in a initramfs... Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support
On Tue, May 27, 2014 at 12:41 PM, Michael Biebl mbi...@gmail.com wrote: 2014-05-27 4:38 GMT+02:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl: On Mon, May 26, 2014 at 09:39:46PM +0200, Tom Gundersen wrote: When enabled in [Network] it will set up a dhcp server on the interface, listening on one of its statically configured IPv4 addresses and with a fixed size pool of leases determined from it. Hi Tom, before looking at the code, a couple of general questions: - does the DHCP server have to be part of networkd? Isn't the job of acquiring addresses and giving out addresses separate and shouldn't two different processes be responsible? I have to agree with Zbigniew here. This looks like feature creep. As I already stated, if it turns out that things will be simpler with this separate, we could easily make that change later. I do agree with Marcel that that is unlikely though. Also, IIRC, the scope of networkd was to establish network connections in a minimal environment, like an initramfs. I'm pretty sure we don't need a DHCP server in a initramfs... networkd should be usable in a minimal environment, like an initramfs. However, we also target other simple setups like virtualization/containers (inside and outside, which is what this feature is mainly meant for). Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support
Hi On Tue, May 27, 2014 at 12:41 PM, Michael Biebl mbi...@gmail.com wrote: 2014-05-27 4:38 GMT+02:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl: before looking at the code, a couple of general questions: - does the DHCP server have to be part of networkd? Isn't the job of acquiring addresses and giving out addresses separate and shouldn't two different processes be responsible? I have to agree with Zbigniew here. This looks like feature creep. I strongly disagree. One major example is Wifi-P2P which requires a DHCP-Server for ad-hoc P2P connections. A network-daemon manages the local address-space, so it should also be responsible of assigning those ranges to an ad-hoc DHCP server. In most current network-solutions it is awfully hard to integrate ad-hoc DHCP networks. Yes, everyone can configure a static pre-assigned DHCP range, but that's not going to work with dynamically created networks. This includes p2p-connections like Wifi-P2P, but also stuff like tethering, virtual devices and containers. Besides, the DHCP-server implementation isn't that much more complex than the client-side. I mean ConnMan requires ~1000 lines for that, I haven't looked at Toms patches so far, though. I'd really like to hear why exactly you guys think this is feature-creep? Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support
On Tue, 27.05.14 13:39, David Herrmann (dh.herrm...@gmail.com) wrote: Hi On Tue, May 27, 2014 at 12:41 PM, Michael Biebl mbi...@gmail.com wrote: 2014-05-27 4:38 GMT+02:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl: before looking at the code, a couple of general questions: - does the DHCP server have to be part of networkd? Isn't the job of acquiring addresses and giving out addresses separate and shouldn't two different processes be responsible? I have to agree with Zbigniew here. This looks like feature creep. I strongly disagree. One major example is Wifi-P2P which requires a DHCP-Server for ad-hoc P2P connections. A network-daemon manages the local address-space, so it should also be responsible of assigning those ranges to an ad-hoc DHCP server. In most current network-solutions it is awfully hard to integrate ad-hoc DHCP networks. Yes, everyone can configure a static pre-assigned DHCP range, but that's not going to work with dynamically created networks. This includes p2p-connections like Wifi-P2P, but also stuff like tethering, virtual devices and containers. Besides, the DHCP-server implementation isn't that much more complex than the client-side. I mean ConnMan requires ~1000 lines for that, I haven't looked at Toms patches so far, though. I'd really like to hear why exactly you guys think this is feature-creep? Fully agree. In many ways, if people complain about a dhcp server in networkd, then it's like complaining about the fact that pppd also can assign addresses to the other side... Michael, Cristian, I don't see you complaining about the IP assigning bits in pppd either! ;-) If we set up links (and especially, create them like we do for veth), then hel, yeah we should be prepared to make sure everybody gets an address on it. 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] [PATCH 17/17] networkd: add dhcp server support
2014-05-27 14:00 GMT+02:00 Lennart Poettering lenn...@poettering.net: In many ways, if people complain about a dhcp server in networkd, then it's like complaining about the fact that pppd also can assign addresses to the other side... I don't see pppd implementing a DHCP server. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support
]] Lennart Poettering If we set up links (and especially, create them like we do for veth), then hel, yeah we should be prepared to make sure everybody gets an address on it. Should we also include BGP, OSPF, RIP, ISIS (and their IPv6 variants) to make sure it's possible to push routes? I take DHCPv6 and IPv6 RA are a given that'll be implemented. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support
Hi, On 27/05/14 13:50, Lennart Poettering wrote: On Mon, May 26, 2014 at 09:39:46PM +0200, Tom Gundersen wrote: When enabled in [Network] it will set up a dhcp server on the interface, listening on one of its statically configured IPv4 addresses and with a fixed size pool of leases determined from it. Hi Tom, before looking at the code, a couple of general questions: - does the DHCP server have to be part of networkd? Isn't the job of acquiring addresses and giving out addresses separate and shouldn't two different processes be responsible? I am very sure this should be in networkd. [snip] That sounds reasonable. However, to be honest, I've never really understood why networkd needs to be part of systemd in the first place. It seems to me that it would work just as well as a separate package with its own releases. To me as a downstream that would be preferable, since such a package can be upgraded (mostly) independently from systemd. For instance, in NixOS we can upgrade dhcpcd or wpa_supplicant pretty much in isolation from the rest of the system; but getting the latest networkd would require getting the latest systemd, which is typically a much bigger step since it potentially impacts much more of the system. You often point out (correctly) that systemd is not monolithic as it consists of dozens of separate programs. But it *is* a monolithic package: those dozens of programs can only be upgraded as a set. Remember that the goal here is not to write another ldap enabled monstrosity. A package becomes a monstrosity one small feature at a time. (And one person's bloat is another person's essential feature.) For instance, networkd currently lacks a WPA supplicant, which you surely need in a modern system. So should systemd accrete a WPA supplicant? How about Bluetooth support? Etc. etc. I mean, is there any concrete criterion about what should or shouldn't go into systemd? -- Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support
El 27/05/14 10:04, Eelco Dolstra escribió: ¿ That sounds reasonable. However, to be honest, I've never really understood why networkd needs to be part of systemd in the first place. For the start, to share a large amount code.. It seems to me that it would work just as well as a separate package with its own releases. That's a bad idea.. it will only cause it to grow in size, increase complexity etc.etc. You often point out (correctly) that systemd is not monolithic as it consists of dozens of separate programs. But it *is* a monolithic package: those dozens of programs can only be upgraded as a set. That's not true. I am running timesyncd with systemd 210.. of course that requires to know what you are doing. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support
El 27/05/14 07:39, David Herrmann escribió: I strongly disagree. One major example is Wifi-P2P which requires a DHCP-Server for ad-hoc P2P connections. OOk. that convinced me, thanks.. -- Cristian I don't know the key to success, but the key to failure is trying to please everybody. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support
On Tue, May 27, 2014 at 2:48 PM, Tollef Fog Heen tfh...@err.no wrote: ]] Lennart Poettering If we set up links (and especially, create them like we do for veth), then hel, yeah we should be prepared to make sure everybody gets an address on it. Should we also include BGP, OSPF, RIP, ISIS (and their IPv6 variants) to make sure it's possible to push routes? The sarcasm is not lost on me, but just for the record, I'd say those are out-of-scope. I take DHCPv6 and IPv6 RA are a given that'll be implemented. The client side is mostly done (by Patrik). If you are interested in working on the server-side, do get in touch so we can coordinate the efforts. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support
]] Tom Gundersen On Tue, May 27, 2014 at 2:48 PM, Tollef Fog Heen tfh...@err.no wrote: ]] Lennart Poettering If we set up links (and especially, create them like we do for veth), then hel, yeah we should be prepared to make sure everybody gets an address on it. Should we also include BGP, OSPF, RIP, ISIS (and their IPv6 variants) to make sure it's possible to push routes? The sarcasm is not lost on me, but just for the record, I'd say those are out-of-scope. I'm actually both sarcastic and serious. Almost all the machines I manage have full BGP tables and run routing daemons. I take DHCPv6 and IPv6 RA are a given that'll be implemented. The client side is mostly done (by Patrik). If you are interested in working on the server-side, do get in touch so we can coordinate the efforts. I currently don't have time for this, I'm afraid. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support
On 05/27/2014 03:20 PM, Tom Gundersen wrote: On Tue, May 27, 2014 at 2:48 PM, Tollef Fog Heentfh...@err.no wrote: ]] Lennart Poettering If we set up links (and especially, create them like we do for veth), then hel, yeah we should be prepared to make sure everybody gets an address on it. Should we also include BGP, OSPF, RIP, ISIS (and their IPv6 variants) to make sure it's possible to push routes? The sarcasm is not lost on me, but just for the record, I'd say those are out-of-scope. I would beg the differ you will need this to be able to properly support containers, isolating them to their own vlans etc. I would have gone the route of implementing this into a separated systemd network server ( optionally being hidden from the network itself for security reasons which is required ) and have networkd tightly integrated and communicate with that server but you seem to be wanting to integrate all of this into networkd which does not lessen the requirements just complicates configuring them a bit more. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support
The container usecase alone is already the reason why I am so very sure I want this stuff, and that it needs to be in networkd, and just work. I want this fully automatic, so that we can create a hundred of veth tunnels, and trivially easy (simply by setting DHCPServer=yes for their .network file) make them automatically configured, passing the relevant configuration bits on. I'm sorry to intervene, but there are other ways to configure containers and similar stuff. I mean, systemd is great because it pioneered so many cool things. Why can't we do something new? For example, prohibit IPv4 for containers and VMs and require them to use IPv6 with link-local addresses which will eliminate the need for any kind of configuration. Pushing IPv6 forward is a good idea. But, well, if you find this unacceptable, what's wrong with IPv4LL? DHCP is complex (well, not _that_ complex, but still) and it's not always required. E.g. IPv6 networks can live without DHCP by using link-local addresses and, say, some basic NDP. It seems to me that IPv4LL should suffice for all the “container use-cases”. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support
Am 27.05.2014 20:14, schrieb Kirill Elagin: The container usecase alone is already the reason why I am so very sure I want this stuff, and that it needs to be in networkd, and just work. I want this fully automatic, so that we can create a hundred of veth tunnels, and trivially easy (simply by setting DHCPServer=yes for their .network file) make them automatically configured, passing the relevant configuration bits on. I'm sorry to intervene, but there are other ways to configure containers and similar stuff. I mean, systemd is great because it pioneered so many cool things. Why can't we do something new? For example, prohibit IPv4 for containers and VMs and require them to use IPv6 with link-local addresses which will eliminate the need for any kind of configuration. Pushing IPv6 forward is a good idea. But, well, if you find this unacceptable, what's wrong with IPv4LL? because people are using containers to reflect the real life out there? that means IPv4 for a very very long time that means *dual stack* for a very very long time how do you imagine building up a comlex network structure within containers for simulations and after figure out things take them for production and only replace the network segments? if someone starts with something new followed by prohibit things which are just in use and working he only can be wrong signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support
On Tue, 27.05.14 14:28, Michael Biebl (mbi...@gmail.com) wrote: 2014-05-27 14:00 GMT+02:00 Lennart Poettering lenn...@poettering.net: In many ways, if people complain about a dhcp server in networkd, then it's like complaining about the fact that pppd also can assign addresses to the other side... I don't see pppd implementing a DHCP server. Of course, that's what they do. They call it differently though ipcp-accept-remote and stuff. Pretty much the same stuff: it configures pppd to not use static IP address configuration, but dynamic one, assigned by the peer, much like dhcp works. 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] [PATCH 17/17] networkd: add dhcp server support
On Tue, 27.05.14 16:04, Eelco Dolstra (eelco.dols...@logicblox.com) wrote: I am very sure this should be in networkd. [snip] That sounds reasonable. However, to be honest, I've never really understood why networkd needs to be part of systemd in the first place. It seems to me that it Well, it shares a lot of code with the rest of systemd, and the rest of systemd inetgrate with it in many ways. For example, timsyncd is able to follow network state changes and only do NTP when there's actually an IP address up. Or it can recieve NTP servers via DHCP, and so on. or you have all that integration for the initrd and the early boot environment. would work just as well as a separate package with its own releases. To me as a No, it wouldn't, we couldn't share much of our code, we couldn't simply rely on the various interfaces between the components, we'd enter dependency hell. The reason why something like networkd so quickly became useful and at its minimal footprint is precisely that we can share so much code and systemd's trove of utility functions makes it so easy to write code. downstream that would be preferable, since such a package can be upgraded (mostly) independently from systemd. For instance, in NixOS we can upgrade dhcpcd or wpa_supplicant pretty much in isolation from the rest of the system; but getting the latest networkd would require getting the latest systemd, which is typically a much bigger step since it potentially impacts much more of the system. Well, philosophically, I think the major weakness of the current Linux system is the fact that everything can be upgraded completely independently. That makes it incredibly hard to test anything it explodes the test matrix, annd it makes it equally hard for developers to target the OS, since they never know what they will be runnin on. You are welcome to split systemd up into multiple packages when you package it, but it's an absolute requirement that you always update them in sync. You often point out (correctly) that systemd is not monolithic as it consists of dozens of separate programs. But it *is* a monolithic package: those dozens of programs can only be upgraded as a set. Well, that's a weird definition of monolithic. But yeah, we *absolutely* require that systemd and its components is updated in sync. That's a core design principle of what we do. Remember that the goal here is not to write another ldap enabled monstrosity. A package becomes a monstrosity one small feature at a time. (And one person's bloat is another person's essential feature.) For instance, networkd currently lacks a WPA supplicant, which you surely need in a modern system. So should systemd accrete a WPA supplicant? How about Bluetooth support? Etc. etc. I mean, is there any concrete criterion about what should or shouldn't go into systemd? That is always a good question, and a hard one to answer. But it's usually a question of specific vs. generic. IP configuration and stuff is generic, inherently so. Hardware like Bluetooth is specific in my eyes, so it's beyond the line. But yeah, systemd is a *platform*, and we will cover the bits sooner or later, than the ajority of systems will obviously need. And for me DHCP is one of those things... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 17/17] networkd: add dhcp server support
When enabled in [Network] it will set up a dhcp server on the interface,
listening
on one of its statically configured IPv4 addresses and with a fixed size pool of
leases determined from it.
Example:
[Match]
Name=ve-arch-tree
[Network]
Address=192.168.12.5/24
DHCPServer=yes
[Route]
Gateway=192.168.12.5
Destination=192.168.12.0/24
In this case we will configure ve-arch-tree with the address 192.168.12.5 and
hand out addresses in the range 192.168.12.6 - 192.168.12.38.
In the future, we should (as suggested by Lennart) introduce a syntax to pick
the
server address automatically.
---
src/network/networkd-link.c | 101 ++-
src/network/networkd-network-gperf.gperf | 1 +
src/network/networkd.h | 5 ++
3 files changed, 93 insertions(+), 14 deletions(-)
diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
index 6677b94..b80a002 100644
--- a/src/network/networkd-link.c
+++ b/src/network/networkd-link.c
@@ -174,19 +174,6 @@ void link_drop(Link *link) {
return;
}
-static int link_enter_configured(Link *link) {
-assert(link);
-assert(link-state == LINK_STATE_SETTING_ROUTES);
-
-log_info_link(link, link configured);
-
-link-state = LINK_STATE_CONFIGURED;
-
-link_save(link);
-
-return 0;
-}
-
static void link_enter_unmanaged(Link *link) {
assert(link);
@@ -227,6 +214,16 @@ static int link_stop_clients(Link *link) {
}
}
+if (link-network-dhcp_server) {
+assert(link-dhcp_server);
+
+k = sd_dhcp_server_stop(link-dhcp_server);
+if (k 0) {
+log_warning_link(link, Could not stop DHCPv4 server:
%s, strerror(-r));
+r = k;
+}
+}
+
return r;
}
@@ -245,6 +242,37 @@ static void link_enter_failed(Link *link) {
link_save(link);
}
+static int link_enter_configured(Link *link) {
+int r;
+
+assert(link);
+assert(link-network);
+assert(link-state == LINK_STATE_SETTING_ROUTES);
+
+
+if (link-network-dhcp_server) {
+log_debug_link(link, offering DHCPv4 leases);
+
+r = sd_dhcp_server_start(link-dhcp_server);
+if (r 0) {
+log_warning_link(link, could not start DHCPv4 server
+ instance: %s, strerror(-r));
+
+link_enter_failed(link);
+
+return 0;
+}
+}
+
+log_info_link(link, link configured);
+
+link-state = LINK_STATE_CONFIGURED;
+
+link_save(link);
+
+return 0;
+}
+
static int route_handler(sd_rtnl *rtnl, sd_rtnl_message *m, void *userdata) {
Link *link = userdata;
int r;
@@ -1663,7 +1691,52 @@ static int link_configure(Link *link) {
}
}
-if (link_has_carrier(link-flags, link-kernel_operstate)) {
+if (link-network-dhcp_server) {
+Address *address;
+
+r = sd_dhcp_server_new(link-dhcp_server, link-ifindex);
+if (r 0)
+return r;
+
+r = sd_dhcp_server_attach_event(link-dhcp_server, NULL, 0);
+if (r 0)
+return r;
+
+LIST_FOREACH(addresses, address,
+ link-network-static_addresses) {
+struct in_addr pool_start;
+
+if (address-family != AF_INET)
+continue;
+
+/* currently this is picked essentially at random */
+r = sd_dhcp_server_set_address(link-dhcp_server,
+ address-in_addr.in);
+if (r 0)
+return r;
+
+/* offer 32 addresses starting from the address
following the server address */
+pool_start.s_addr =
htobe32(be32toh(address-in_addr.in.s_addr) + 1);
+r = sd_dhcp_server_set_lease_pool(link-dhcp_server,
+ pool_start, 32);
+
+break;
+}
+
+/* TODO:
+r = sd_dhcp_server_set_router(link-dhcp_server,
+ main_address-in_addr.in);
+if (r 0)
+return r;
+
+r = sd_dhcp_server_set_prefixlen(link-dhcp_server,
+ main_address-prefixlen);
+if (r 0)
+return r;
+*/
+}
+
+if (link_has_carrier(link-flags, link-operstate)) {
r = link_acquire_conf(link);
if
Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support
On Mon, May 26, 2014 at 09:39:46PM +0200, Tom Gundersen wrote:
When enabled in [Network] it will set up a dhcp server on the interface,
listening
on one of its statically configured IPv4 addresses and with a fixed size pool
of
leases determined from it.
Hi Tom,
before looking at the code, a couple of general questions:
- does the DHCP server have to be part of networkd? Isn't the job
of acquiring addresses and giving out addresses separate and shouldn't
two different processes be responsible?
- why the fixed limit of 32 addresses? Shouldn't the default be to give
out all possible addresses except for the server one?
Zbyszek
Example:
[Match]
Name=ve-arch-tree
[Network]
Address=192.168.12.5/24
DHCPServer=yes
[Route]
Gateway=192.168.12.5
Destination=192.168.12.0/24
In this case we will configure ve-arch-tree with the address 192.168.12.5 and
hand out addresses in the range 192.168.12.6 - 192.168.12.38.
In the future, we should (as suggested by Lennart) introduce a syntax to pick
the
server address automatically.
---
src/network/networkd-link.c | 101
++-
src/network/networkd-network-gperf.gperf | 1 +
src/network/networkd.h | 5 ++
3 files changed, 93 insertions(+), 14 deletions(-)
diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
index 6677b94..b80a002 100644
--- a/src/network/networkd-link.c
+++ b/src/network/networkd-link.c
@@ -174,19 +174,6 @@ void link_drop(Link *link) {
return;
}
-static int link_enter_configured(Link *link) {
-assert(link);
-assert(link-state == LINK_STATE_SETTING_ROUTES);
-
-log_info_link(link, link configured);
-
-link-state = LINK_STATE_CONFIGURED;
-
-link_save(link);
-
-return 0;
-}
-
static void link_enter_unmanaged(Link *link) {
assert(link);
@@ -227,6 +214,16 @@ static int link_stop_clients(Link *link) {
}
}
+if (link-network-dhcp_server) {
+assert(link-dhcp_server);
+
+k = sd_dhcp_server_stop(link-dhcp_server);
+if (k 0) {
+log_warning_link(link, Could not stop DHCPv4
server: %s, strerror(-r));
+r = k;
+}
+}
+
return r;
}
@@ -245,6 +242,37 @@ static void link_enter_failed(Link *link) {
link_save(link);
}
+static int link_enter_configured(Link *link) {
+int r;
+
+assert(link);
+assert(link-network);
+assert(link-state == LINK_STATE_SETTING_ROUTES);
+
+
+if (link-network-dhcp_server) {
+log_debug_link(link, offering DHCPv4 leases);
+
+r = sd_dhcp_server_start(link-dhcp_server);
+if (r 0) {
+log_warning_link(link, could not start DHCPv4
server
+ instance: %s, strerror(-r));
+
+link_enter_failed(link);
+
+return 0;
+}
+}
+
+log_info_link(link, link configured);
+
+link-state = LINK_STATE_CONFIGURED;
+
+link_save(link);
+
+return 0;
+}
+
static int route_handler(sd_rtnl *rtnl, sd_rtnl_message *m, void *userdata) {
Link *link = userdata;
int r;
@@ -1663,7 +1691,52 @@ static int link_configure(Link *link) {
}
}
-if (link_has_carrier(link-flags, link-kernel_operstate)) {
+if (link-network-dhcp_server) {
+Address *address;
+
+r = sd_dhcp_server_new(link-dhcp_server, link-ifindex);
+if (r 0)
+return r;
+
+r = sd_dhcp_server_attach_event(link-dhcp_server, NULL, 0);
+if (r 0)
+return r;
+
+LIST_FOREACH(addresses, address,
+ link-network-static_addresses) {
+struct in_addr pool_start;
+
+if (address-family != AF_INET)
+continue;
+
+/* currently this is picked essentially at random */
+r = sd_dhcp_server_set_address(link-dhcp_server,
+ address-in_addr.in);
+if (r 0)
+return r;
+
+/* offer 32 addresses starting from the address
following the server address */
+pool_start.s_addr =
htobe32(be32toh(address-in_addr.in.s_addr) + 1);
+r = sd_dhcp_server_set_lease_pool(link-dhcp_server,
+ pool_start, 32);
+
+break;
+
Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support
El 26/05/14 22:38, Zbigniew Jędrzejewski-Szmek escribió: On Mon, May 26, 2014 at 09:39:46PM +0200, Tom Gundersen wrote: When enabled in [Network] it will set up a dhcp server on the interface, listening on one of its statically configured IPv4 addresses and with a fixed size pool of leases determined from it. Hi Tom, before looking at the code, a couple of general questions: - does the DHCP server have to be part of networkd? Yeah IMHO the dhcp server should be a separate daemon, that of course does not preclude it from sharing code with networkd. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 17/17] networkd: add dhcp server support
Hi Cristian, When enabled in [Network] it will set up a dhcp server on the interface, listening on one of its statically configured IPv4 addresses and with a fixed size pool of leases determined from it. Hi Tom, before looking at the code, a couple of general questions: - does the DHCP server have to be part of networkd? Yeah IMHO the dhcp server should be a separate daemon, that of course does not preclude it from sharing code with networkd. that is not a good idea. Why would you make the DHCP server a separate daemon. That is just asking for trouble. The only way to provide a proper integration is if the DHCP server is part of systemd-networkd. Otherwise you are just wasting time in trying to figure out on how to handle configuration and update of states between two daemon. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
