Hide Forgot
Description of problem: On CentOS 7 '-R' defines requested options. On Fedora 24 it is additional flag for DHCPv6 options and the original '-R' was replaced by '--requested-options'. This makes it uneasy for multi-distro applications which uses dhclient. Version-Release number of selected component (if applicable): dhcp-client-4.3.4-3.fc24.x86_64 Actual results: On CentOS 7 -R specifies requested options, on Fedora 24 it is an additional option for DHCPv6 specific flags. Expected results: Backward compatible API across distributions.
From bug #1357947, comment#2: We've always had a patch [1] for adding several options to dhclient and '-R' was one of them. In latest dhcp-4.3.4 upstream also added [2] a dhcpv6-only '-R' option to dhclient. This had already happened once, when upstream added '-I' and I had to rename our '-I' to '-C'. This time I had to rename our '-R' (because upstream has precedence) to something else and I chose long '--request-options'. I understand the issues it causes but I don't see any other way how to solve it. [1] http://pkgs.fedoraproject.org/cgit/rpms/dhcp.git/tree/dhcp-dhclient-options.patch [2] https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=commitdiff;h=c88dfebddd766d40dc29b50ede355ec3ecf2a463
Thanks for the fast response. Would it be possible to add '--request-options' as a full length alias for -R on older versions of dhclient?
For Fedora 23 sure, but for CentOS 7 you would need to fill a bug in CentOS bugzilla.
Great! Should I create two new bug entries and point them to this one or should I modify this entry for Fedora 23?
Create a bug at CentOS Bug Tracker pointing to this one and this one we can use to add it to F23.
Backporting will be nice, but it will not cover all scenarios. I do not really understand why breaking backwards compatibility has been accepted. It specifically breaks oVirt/RHV VDSM. Can the 'new' -R be accompanied with another flag that specify that this is the 'new' meaning? This way, older apps that use -R will not break and new apps that want to use the new -R, will just have to add another flag that mentions that compatibility breaks.
Ok, I think I understand now: this is due to downstream adding its own flags that later collided with upstream. I would suggest for the future, to have all these extensions through some imported conf file (yaml?) or perhaps add all extension flags with a prefix (like --extend-foo). Are there any recommendations on how we can use dhclient on Centos7/RHEL7 without having this problem? I mean, is there any other option to implement what -R does? We specifically need to mention that we are not interested in the route option.
(In reply to Edward Haas from comment #7) > Ok, I think I understand now: this is due to downstream adding its own flags > that later collided with upstream. Exactly > I would suggest for the future, to have all these extensions through some > imported conf file (yaml?) or perhaps add all extension flags with a prefix > (like --extend-foo). Yes, that's why I've changed it to long --request-options instead of one letter. But we most likely won't be adding any others, these have been there from ancient times. > Are there any recommendations on how we can use dhclient on Centos7/RHEL7 > without having this problem? I mean, is there any other option to implement > what -R does? > We specifically need to mention that we are not interested in the route > option. AFAIK the only other way is (see dhclient.conf man page) echo "request subnet-mask, broadcast-address, time-offset, routers, ...;" > /etc/dhclient/dhclient.conf Since the '-R' is the RHEL/Fedora only addition AFAIK not present on other distros I'd rather see you doing this. But if that's not the way you want to go, then I can change the -R to behave schizophrenically depending whether it's used with -6 or not. So '-6 -R' would be the new meaning and everything else ('-4 -R' or '-R') would mean request options.
(In reply to Jiri Popelka from comment #8) > (In reply to Edward Haas from comment #7) > > Ok, I think I understand now: this is due to downstream adding its own flags > > that later collided with upstream. > > Exactly > > > I would suggest for the future, to have all these extensions through some > > imported conf file (yaml?) or perhaps add all extension flags with a prefix > > (like --extend-foo). > > Yes, that's why I've changed it to long --request-options instead of one > letter. > But we most likely won't be adding any others, these have been there from > ancient times. > > > Are there any recommendations on how we can use dhclient on Centos7/RHEL7 > > without having this problem? I mean, is there any other option to implement > > what -R does? > > We specifically need to mention that we are not interested in the route > > option. > > AFAIK the only other way is (see dhclient.conf man page) > echo "request subnet-mask, broadcast-address, time-offset, routers, ...;" > > /etc/dhclient/dhclient.conf > Since the '-R' is the RHEL/Fedora only addition AFAIK not present on other > distros I'd rather see you doing this. > But if that's not the way you want to go, then I can change the -R > to behave schizophrenically depending whether it's used with -6 or not. > So '-6 -R' would be the new meaning and everything else ('-4 -R' or '-R') > would mean request options. We seem to be in a bad position already, adding non trivial solutions will probably add to the chaos. I think we can use dhclient.conf specific for our needs by providing our own tweaked configuration file (using -cf).
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.