https://github.com/libguestfs/libguestfs/issues/121
We use dhclient to get a DHCP address inside a minimal appliance. To get this out of the way: NetworkManager or systemd are not options.
It seems as if the ISC dhcp package has been EOL'd upstream:
I wonder what our plans are for this package, such as whether we are recommending moving to dhcpcd:
https://roy.marples.name/projects/dhcpcd
(we package this already, as does Debian), or another suggested replacement, or if another team is going to maintain the code, or if we will just keep packaging the last ISC version in Fedora?
Rich.
On Tue, May 30, 2023 at 11:10 AM Richard W.M. Jones rjones@redhat.com wrote:
https://github.com/libguestfs/libguestfs/issues/121
We use dhclient to get a DHCP address inside a minimal appliance. To get this out of the way: NetworkManager or systemd are not options.
It seems as if the ISC dhcp package has been EOL'd upstream:
I wonder what our plans are for this package, such as whether we are recommending moving to dhcpcd:
https://roy.marples.name/projects/dhcpcd
(we package this already, as does Debian), or another suggested replacement, or if another team is going to maintain the code, or if we will just keep packaging the last ISC version in Fedora?
Upstream has replace it with Kea: https://www.isc.org/kea/
On 30/05/2023 11:41, Peter Robinson wrote:
On Tue, May 30, 2023 at 11:10 AM Richard W.M. Jones rjones@redhat.com wrote:
https://github.com/libguestfs/libguestfs/issues/121
We use dhclient to get a DHCP address inside a minimal appliance. To get this out of the way: NetworkManager or systemd are not options.
It seems as if the ISC dhcp package has been EOL'd upstream:
I wonder what our plans are for this package, such as whether we are recommending moving to dhcpcd:
https://roy.marples.name/projects/dhcpcd
(we package this already, as does Debian), or another suggested replacement, or if another team is going to maintain the code, or if we will just keep packaging the last ISC version in Fedora?
Upstream has replace it with Kea: https://www.isc.org/kea/
That's a server - it doesn't replace the client component.
Tom
* Richard W. M. Jones:
I wonder what our plans are for this package, such as whether we are recommending moving to dhcpcd:
systemd-networkd has an integrated DHCP client, hasn't it?
Thanks, Florian
On 30/05/2023 11:57, Florian Weimer wrote:
- Richard W. M. Jones:
I wonder what our plans are for this package, such as whether we are recommending moving to dhcpcd:
systemd-networkd has an integrated DHCP client, hasn't it?
It does yes, and it's what I use on most machines.
Tom
On Tue, May 30, 2023 at 10:57 AM Florian Weimer fweimer@redhat.com wrote:
systemd-networkd has an integrated DHCP client, hasn't it?
Yes (and I have migrated a number of my systems to using systemd-networkd), but Richard said systemd is not an option.
On Tue, May 30, 2023 at 11:05:39AM +0000, Gary Buhrmaster wrote:
On Tue, May 30, 2023 at 10:57 AM Florian Weimer fweimer@redhat.com wrote:
systemd-networkd has an integrated DHCP client, hasn't it?
Yes (and I have migrated a number of my systems to using systemd-networkd), but Richard said systemd is not an option.
We really need just a dhcp client, no baggage.
Rich.
On Tue, May 30, 2023 at 11:08 AM Richard W.M. Jones rjones@redhat.com wrote:
We really need just a dhcp client, no baggage.
Busybox distributes Udhcpc, a small dhcp client intended for embedded systems, and perhaps might be a longer term viable solution for minimal appliances.
And while I never looked at them, both perl and python have dhcp client libraries that might be able to be part of a possible solution.
Once upon a time, Richard W.M. Jones rjones@redhat.com said:
It seems as if the ISC dhcp package has been EOL'd upstream:
I'm a little surprised that nobody has forked this to continue maintaining it. dhcpd is widely used, and kea is far from a drop-in replacement.
On Tue, 30 May 2023 at 08:46, Chris Adams linux@cmadams.net wrote:
Once upon a time, Richard W.M. Jones rjones@redhat.com said:
It seems as if the ISC dhcp package has been EOL'd upstream:
I'm a little surprised that nobody has forked this to continue maintaining it. dhcpd is widely used, and kea is far from a drop-in replacement.
It is also not sexy software and you have to deal with a very hornery set of bug reports where everything going wrong in any office is of course blamed on DHCP. [You also need to know about the deep intricacies of a ton of flags and settings which may have stated RFC uses but have been misused for decades because some hardware decided to reuse a flag for a boot-time option. You 'fix' an issue and you usually find you broke some key infrastructure no one 'knew' about except someone who retired 4 to 10 years ago.
With that, I can see why ISC is 'burying' the software for some poor sucker to take up.
* Chris Adams:
Once upon a time, Richard W.M. Jones rjones@redhat.com said:
It seems as if the ISC dhcp package has been EOL'd upstream:
I'm a little surprised that nobody has forked this to continue maintaining it. dhcpd is widely used, and kea is far from a drop-in replacement.
It's … just not very good. A lot of the logic resides in a shell script that runs as root, uses bash arithmetic expansion, and processes untrusted data from the network. That's not a good combination at all.
Thanks, Florian
Once upon a time, Florian Weimer fweimer@redhat.com said:
- Chris Adams:
Once upon a time, Richard W.M. Jones rjones@redhat.com said:
It seems as if the ISC dhcp package has been EOL'd upstream:
I'm a little surprised that nobody has forked this to continue maintaining it. dhcpd is widely used, and kea is far from a drop-in replacement.
It's … just not very good. A lot of the logic resides in a shell script that runs as root, uses bash arithmetic expansion, and processes untrusted data from the network. That's not a good combination at all.
Well, I was really talking about dhcpd, not dhclient.
On Tue, 30 May 2023 at 14:45, Chris Adams linux@cmadams.net wrote:
Once upon a time, Florian Weimer fweimer@redhat.com said:
- Chris Adams:
Once upon a time, Richard W.M. Jones rjones@redhat.com said:
It seems as if the ISC dhcp package has been EOL'd upstream:
I'm a little surprised that nobody has forked this to continue maintaining it. dhcpd is widely used, and kea is far from a drop-in replacement.
It's … just not very good. A lot of the logic resides in a shell script that runs as root, uses bash arithmetic expansion, and processes untrusted data from the network. That's not a good combination at all.
Well, I was really talking about dhcpd, not dhclient.
Yes. My apologies to you and everyone else. You said that several times and I just went blathering on dhcpd versus dhclient.
On Tue, May 30, 2023 at 11:09:39AM +0100, Richard W.M. Jones wrote:
https://github.com/libguestfs/libguestfs/issues/121
We use dhclient to get a DHCP address inside a minimal appliance. To get this out of the way: NetworkManager or systemd are not options.
It seems as if the ISC dhcp package has been EOL'd upstream:
I wonder what our plans are for this package, such as whether we are recommending moving to dhcpcd:
https://roy.marples.name/projects/dhcpcd
(we package this already, as does Debian), or another suggested replacement, or if another team is going to maintain the code, or if we will just keep packaging the last ISC version in Fedora?
Personally, I see dhcpcd is the logical option here. It's a nice and simple client and actively maintained. It is disconnected from any particular init system making it appealing for appliances and other special use cases.
Given ISC dropping dhclient, we should probably be doing the same in Fedora.
On Tue, May 30, 2023 at 10:11:21AM -0400, David Cantrell wrote:
On Tue, May 30, 2023 at 11:09:39AM +0100, Richard W.M. Jones wrote:
https://github.com/libguestfs/libguestfs/issues/121
We use dhclient to get a DHCP address inside a minimal appliance. To get this out of the way: NetworkManager or systemd are not options.
It seems as if the ISC dhcp package has been EOL'd upstream:
I wonder what our plans are for this package, such as whether we are recommending moving to dhcpcd:
https://roy.marples.name/projects/dhcpcd
(we package this already, as does Debian), or another suggested replacement, or if another team is going to maintain the code, or if we will just keep packaging the last ISC version in Fedora?
Personally, I see dhcpcd is the logical option here. It's a nice and simple client and actively maintained. It is disconnected from any particular init system making it appealing for appliances and other special use cases.
Given ISC dropping dhclient, we should probably be doing the same in Fedora.
This seems like the best plan, although we should probably communicate it somehow and find out what Fedora packages are affected. A Fedora systemwide change maybe.
Rich.
This activity has been started ~3 years ago: https://fedoraproject.org/wiki/Changes/dhclient_deprecation#Dependencies and some dependencies have been cleaned up (dracut iirc) since then.
On Tue, May 30, 2023 at 5:14 PM Richard W.M. Jones rjones@redhat.com wrote:
On Tue, May 30, 2023 at 10:11:21AM -0400, David Cantrell wrote:
On Tue, May 30, 2023 at 11:09:39AM +0100, Richard W.M. Jones wrote:
https://github.com/libguestfs/libguestfs/issues/121
We use dhclient to get a DHCP address inside a minimal appliance. To get this out of the way: NetworkManager or systemd are not options.
It seems as if the ISC dhcp package has been EOL'd upstream:
I wonder what our plans are for this package, such as whether we are recommending moving to dhcpcd:
https://roy.marples.name/projects/dhcpcd
(we package this already, as does Debian), or another suggested replacement, or if another team is going to maintain the code, or if we will just keep packaging the last ISC version in Fedora?
Personally, I see dhcpcd is the logical option here. It's a nice and simple client and actively maintained. It is disconnected from any particular init system making it appealing for appliances and other special use cases.
Given ISC dropping dhclient, we should probably be doing the same in Fedora.
This seems like the best plan, although we should probably communicate it somehow and find out what Fedora packages are affected. A Fedora systemwide change maybe.
NetworkManager has defaulted to it's own dhcp client by default for some time and systemd-networkd has it's own as well, I suspect actual users are quite minimal. I'm not sure if anything like cloud-init uses it but I also doubt it.
On 5/31/23 9:18 AM, Peter Robinson wrote:
NetworkManager has defaulted to it's own dhcp client by default for some time and systemd-networkd has it's own as well, I suspect actual users are quite minimal. I'm not sure if anything like cloud-init uses it but I also doubt it.
I'll come out of my shell to cough up as one of those "minimal" users. I'm using it only on a single server that is still using "network-scripts" for network management. Yes, I know they are deprecated. I wouldn't be surprised if there are a few other "network-scripts" users. The scripts call dhclient.
It would be nice if a change notice went out about it.
This email is not intended to be a "-1" or other negative response. I will end up changing network management to something else.
I'm not using NetworkManager due to an issue with IPv6 and SLAAC. Clients under the server get an initial SLAAC IP from NetworkManager, but after the IP expires they never get a new IP. I've asked upstream about it and didn't get anywhere. Granted, this was 3 years ago now. Maybe things are better and I can try NetworkManager again... or systemd-networkd.
Michael Cronenworth wrote on Wed, May 31, 2023 at 10:47:24AM -0500:
I'm not using NetworkManager due to an issue with IPv6 and SLAAC. Clients under the server get an initial SLAAC IP from NetworkManager, but after the IP expires they never get a new IP. I've asked upstream about it and didn't get anywhere. Granted, this was 3 years ago now. Maybe things are better and I can try NetworkManager again... or systemd-networkd.
Could that be the ipv6 "privacy" features?
There are two settings I'm aware of: * ipv6.ip6-privacy ; that generates a random address regularly which will be used for outgoing connections by default (2); it can be changed to generate it or not use by default or not generate it at all
* ipv6.addr-gen-mode ; that sets the "main" stable address and should default to stable-privacy, which ought to be stable but you can set it to eui64 to generate from mac if it doesn't work. In particular I think stable-privacy uses the connection's uuid, which is random if you leave it all up to defaults for ethernet (defaults to generating an in-memry config with dhcp at every boot afaiu); that shouldn't change on renew but perhaps there's been some other similar fuzziness to it.
This probably has already been explained when you brought up the issue so I'm going to assume there was another problem, but in case it helps feel free to give it a try. (Not that I have anything against systemd-networkd, I use both depending on the need for dynamic settings (e.g. laptop with wireless moving around) or not)