Bug 697877

see also https://bugzilla.redhat.com/show_bug.cgi?id=697877

As stated in the original bug, I don't think initscripts needs changed to always send something, as you are suggesting - it's a configuration parameter for the admin if needed.

Then how about the decision to change NM to _always_ send a hostname???
(even though it now may send a fqdn, which my original bug report is about)

Not fixing initscripts would make things inconsistent.

So for consistency's sake either fix initscripts or revert the NM change.
My patch makes things consistent and is a trivial patch.

I __very___ strongly believe in consistency :-)

So please reopen the bug

It changes behavior that's existed for 5-10 years; I don't think that's really appropriate. Why would you need to send the hostname each time?

See the original bugreport: DDNS

The change in behavior the _is_ acceptable for NM but not for initscripts?

Besides, sending the hostname each time is very much harmless.

Created attachment 493255 [details]
alternate patch

Here's a better solution - shorter, less complicated, faster, and doesn't somehow tie the user into requiring that a particular DHCP server support a different option based on how they define their own local hostname.

Does this work for you?

Created attachment 493267 [details]
new patch

Actually,

Both our patches wouldn't work, I checked them both.

There are 2 parts to this patch:
1- when the DHCP_HOSTNAME is _not_ set then use HOSTNAME
   (first 'if' block added)
2- when DHCP_HOSTNAME is a FQDN then use the -F dhclient option,
   otherwise use the -H dhclient option.
   (second 'if' block added)

The use of the -F and -H options can be found in
'man dhclient', which is quite specific about
the -H option:
'... The host-name string only contains the client's hostname prefix, ...'

This new patch fixes the currently wrong behavior in case DHCP_HOSTNAME
is a FQDN (2). I think this part is a _must-apply_.

The new patch adds functionality such that NM and initscripts are
consistent (1). I think this part is a _realy-really-want-it-applied_ :-)

(1) and (2) are independent can be applied separately.

If DHCP_HOSTNAME is a FQDN, that's administrator error, it doesn't need handled.

it isn't handled other than:

'gee, the administrator configured a FQDN, so I guess he'll really want that. let's instruct dhclient that it has to send a FQDN'

bill, you suddenly became very quiet.
any info on what you're going to do?

I stand by comment #6. Better to consistently exercise a single codepath rather than having client (mis)configuration exercise entirely different parts.

I don't quite understand the resistance against what I propose.
How's not doing things according to the spec better than what I propose?
I see that the -F exercises a different codepath, but come on, realistically, how different are they really?

By only every using the -H option you're effectively closing the door on doing things correctly.

If we change things now we have the opportunity to do it right...
We know the right solution.
Why not do it?

Also, in your patch you're still allowing out-of-spec behaviour: if DHCP_HOSTNAME is defined as a FQDN then the behaviour is wrong: a FQDN name is sent under the -H option.

(In reply to comment #12)
> I don't quite understand the resistance against what I propose.
> How's not doing things according to the spec better than what I propose?
> I see that the -F exercises a different codepath, but come on, realistically,
> how different are they really?
> 
> By only every using the -H option you're effectively closing the door on doing
> things correctly.

How so? We would always send the short hostname.

(That's always send the short hostname if DHCP_HOSTNAME is specified.)

> Also, in your patch you're still allowing out-of-spec behaviour: if
> DHCP_HOSTNAME is defined as a FQDN then the behaviour is wrong: a FQDN name is
> sent under the -H option.

Bill, look at '-H ${DHCP_HOSTNAME:-${HOSTNAME%%.*}}':
* this sends the configured DHCP_HOSTNAME is-as when it is defined; so when it is configured as a FQDN then a FQDN is sent under the -H option, which violates the spec.
* this sends the short hostname when DHCP_HOSTNAME is not defined, which is correct behaviour

Should be fixed with a simple:

[ -n "$DHCP_HOSTNAME" ] && DHCP_HOSTNAME=${DHCP_HOSTNAME%%.*} 

in expand_config().

ok. acceptable ;-)

The only thing left then is that we're blocking the FQDN (-F) scenario but I'm getting the feeling you're not eager to solve that one.

So combining comment 16 with your patch is fine with me then.

Could you do this for F14, F15, RHEL 5 and RHEL 6 please?

Hi Bill,

any progress on this bug?
NM pushed out an update for the issue and solved their bug for it (https://bugzilla.redhat.com/show_bug.cgi?id=694758).

If initscripts could also update then both initscripts and NM behaviour is again consistent.

thanks!

Fixed in git for rawhide, may make a F-15 update.

http://git.fedorahosted.org/git?p=initscripts.git;a=commitdiff;h=60ddb21fcdfb0594a35978aa0b04af4527c46d6e

thanks!

a F15 update would be much appreciated. :-)