DHCPd had lots of patches, please bump (we already have the security patches btw.): * Remove infinite loop in token_print_indent_concat(). * Validate the argument to the -p option. * The notorious 'option ... larger than buffer' log line, which is seen in some malformed DHCP client packets, was modified. It now logs the universe name, and does not log the length values (which are bogus corruption read from the packet anyway). It also carries a hopefully more useful explanation. * The db-time-format option was documented in manpages. * Using reserved leases no longer results in 'lease with binding state free not on its queue' error messages, thanks to a patch from Frode Nordahl. * A parser bug was fixed that segfaulted if site-option-space was tried to be used interchangeably with vendor-option-space. * Two uninitialized stack structures are now memset to zero, thanks to patch from David Cantrell at Red Hat. * The update-conflict-detection feature would leave an FQDN updated without a DHCID (still currently implemented as a TXT RR). This would cause later expiration or release events to fail to remove the domain name. The feature now also inserts the client's up to date DHCID record, so records may safely be removed at expiration or release time. Thanks to a patch submitted by Christof Chen. * Memory leak in the load_balance_mine() function is fixed. This would leak ~20-30 octets per DHCPDISCOVER packet while failover was in use and in normal state. * Various compilation fixes have been included for the memory related DEBUG #defines in includes/site.h. * Fixed setting hostname in Linux hosts that require hostname argument to be double-quoted. Also allow server-provided hostname to override hostnames 'localhost' and '(none)'. * Added client support for setting interface MTU and metric, thanks to Roy "UberLord" Marples . * Fixed failover reconnection retry code to continue to retry to reconnect rather than restarting the listener. * Fixed a bug where an OMAPI socket disconnection message would not result in scheduling a failover reconnection, if the link had not negotiated a failover connect yet (e.g.: connection refused, asynch socket connect() timeouts). * A bug was fixed that caused the 'conflict-done' state to fail to be parsed in failover state records. * A stack overflow vulnerability was fixed in dhclient that could allow remote attackers to execute arbitrary commands as root on the system, or simply terminate the client, by providing an over-long subnet-mask option. CERT VU#410676 - CVE-2009-0692 * Versions 3.0.x syntax with multiple name->code option definitions is now supported. Note that, similarly to 3.0.x, for by-code lookups only the last option definition is used. * Fixed a bug where a time difference of greater than 60 seconds between a failover pair could cause the primary to crash on contact with the secondary. Thanks to a patch from Steinar Haug. * Secondary servers in a failover pair will now perform ddns removals if they had performed ddns updates on a lease that is expiring, or was released through the primary. As part of the same fix, stale binding scopes will now be removed if a change in identity of a lease's active client is detected, rather than simply if a lease is noticed to have expired (which it may have expired without a failover server noticing in some situations). * A patch supplied by David Cantrell at RedHat was applied that detects invalid calling parameters given to the ns_name_ntop() function. Specifically, it detects if the caller passed a pointer and size pair that causes the pointer to integer-wrap past zero. * Fixed a fenceposting bug when a client had two host records configured, one using 'uid' and the other using 'hardware ethernet'. CVE-2009-1892
Also 4.1.1-p1: http://ftp.isc.org/isc/dhcp/dhcp-4.1.1-P1-RELNOTES
*** Bug 296806 has been marked as a duplicate of this bug. ***
4.2.0 has been released too.
*** Bug 295637 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > Also 4.1.1-p1: > http://ftp.isc.org/isc/dhcp/dhcp-4.1.1-P1-RELNOTES > DHCP 4.1.1-P1 is a current production release. please, bump ebuild to 4.1.1-P1
btw, I tired of waiting ebuild release and make my own ebuild. Its available at http://code.google.com/p/barzog-gentoo-overlay/
We're about to migrate our DHCP infrastructure from some ancient Solaris boxes to Gentoo linux systems and I was looking into the state of isc dhcp in Gentoo. I see version 4 is hard-masked; not just unstable, but hard-masked, which seems odd. I came across this bug and thought it might be a good place to ask about that status. From package.mask: # The v4 branch of DHCP has a new build system and a "minimal" dhclient-only # build is not yet supported. The IPv6 support seems a bit rough at the edges # as well. As such, this is for the adventurous only. # Bug reports are welcome if they carry patches. it seems two reasons are mentioned, a new build system with no minimal client only build, and rough IPv6 support. As I understand, dhcpcd is the recommended dhcp client, so not having a client-only build doesn't seem to warrant hard-masking. And while the support for IPv6 in 4 may be perhaps rough, you don't have to use it, and version 3 has *no* IPv6 support, so it's not like you're losing anything. Not being able to avail of the new features and improvements for IPv4 in dhcp 4 because IPv6 isn't perfected yet doesn't seem quite right. ISC dhcp 4.1.1-P1 is considered a current production release and is one of the two recommended releases on the project home page. The other, 3.1-ESV, is the extended support version intended for sites that can't upgrade readily and are forced to run crusty old versions of software. That obviously doesn't describe Gentoo users ;)... Would it be possible to at least move dhcp 4 to unstable, rather than hard-masked? And hopefully get it on the road to being marked stable? The original masking was done well over a year ago for the initial release of 4.0.0, and much has changed since then. Thanks for the consideration...
chainsaw: you put dhcp4 in p.mask 18 months ago, what's your status on it? henson: (In reply to comment #7) > As I understand, dhcpcd is the recommended dhcp client, so not having a > client-only build doesn't seem to warrant hard-masking. Err, I don't follow. dhcpcd is in a separate package. > ISC dhcp 4.1.1-P1 is considered a current production release and is one of the > two recommended releases on the project home page. The other, 3.1-ESV, is the > extended support version intended for sites that can't upgrade readily and are > forced to run crusty old versions of software. That obviously doesn't describe > Gentoo users ;)... I've added 3.1.3 and 3.1-ESV to the tree in the meanwhile.
(In reply to comment #8) > henson: > (In reply to comment #7) > > As I understand, dhcpcd is the recommended dhcp client, so not having a > > client-only build doesn't seem to warrant hard-masking. > Err, I don't follow. dhcpcd is in a separate package. I think that was his point. In gentoo if you only need a dhcp-client dhcpcd is currently the recommended one. So I think he meant that it is probably not that many people using net-misc/dhcp only for dhclient.
(In reply to comment #9) > I think that was his point. In gentoo if you only need a dhcp-client dhcpcd is > currently the recommended one. So I think he meant that it is probably not > that many people using net-misc/dhcp only for dhclient. Exactly; as I said, one of the two reasons given for the hard mask was "a new build system with no minimal client only build" -- given that probably few people want/need such a minimal client only build, it doesn't seem a strong justification for preventing access to the new features of the actual server.
If the dev who hardmasked dhcp 4 is MIA, perhaps somebody else could unmask it? I'm currently running 4.1.2 in production with no problems, using the ebuild at http://code.google.com/p/barzog-gentoo-overlay/ with the version changed from 4.1.1 to 4.1.2. The changes between the current hard masked 4.1.0 and the overlay ebuild are pretty minor if a dev wanted to update portage with a newer ebuild. dhcpd 4.x is long past production ready, while it might still warrant being marked unstable the hard mask seems undesirable at this point. Thanks...
http://solor.mihgroup.eu.org/dhcp-4.2.0_p2.ebuild.tar.gz This is package with DHCP 4.2.0 P2 ebuild and files for local overlay... it has also new init script that knows how to work as both ipv4/ipv6 dhcp server... probably needs some fixes but it works for me without any errors for past week or so, but i guess it needs some better sanity checks for config files... Also 4.2.0 can assign ipv6 addresses by mac addresses finaly and not only by duids, major feature in my eyes, since im having stateful dhcpv6 assigning and then everytime i reinstalled some system i needed to fix dhcp server to correct duid or fix duid on reinstalled client, now finaly i can forget about this! You should really bump dhcp to version 4.2.+ asap if not for any other reason, for reason of having only one program for both dhcp and dhcpv6 server!
Created attachment 257722 [details] dhcp-4.2.0_p2.ebuild + files + new init script
(In reply to comment #13) > Created an attachment (id=257722) [details] > dhcp-4.2.0_p2.ebuild + files + new init script init script (dhcpd.init3) does not work
(In reply to comment #14) > > init script (dhcpd.init3) does not work > yes i know it has some bugs unless you use both dhcp.conf and dhcp6.conf (dhcp server for both ipv4 & ipv6 they need to be seperated). it would need some sanity checks, but this should be fixed when its added to portage... i do have bit changed script already so it doesnt error out if some config file is missing, but like i said, should be fixed when its added to repo... i also attached new init, however its still not 100% bug free :)
Created attachment 260710 [details] fixed init
Is there any policy for what to do about a hard masked package when the dev who masked it is MIA? While it would be great to get a fresh 4.2 ebuild stabled or even unstable in portage, it would be nice to at least remove the hard mask, which interferes with even local ebuilds in overlays... Thanks...
*** Bug 353420 has been marked as a duplicate of this bug. ***
dhcp-4.2.1 is in the tree. if any enhancements were missed, file a new bug for each relevant one.
