On 22.8.2016 11:18, Joakim Tjernlund wrote: > On Mon, 2016-08-22 at 11:13 +0200, Petr Spacek wrote: >> On 22.8.2016 10:49, Ondrej Valousek wrote: >>> >>> I do not think this is a good patch - systematically. >>> Maybe better approach is to rather use gethostbyname() than gethostname(). >>> My 2 cents. >> >> Most importantly, this will work only for the simplest possible case where >> host name of the client is sub-domain of AD domain. >> >> It will break e.g. in this scenario: >> AD domain = example.net. >> Client's hostname = myclient.branch1.example.net. > > No, the patch will not touch hostname if it already have a "." in it.
Yes, but it means that we are back to to manual configuration. Even worse, if your client *is supposed* to have name "myclient.branch1.example.net." but you did not configure it explicitly, it will create DNS records for incorrect name "myclient.example.net.". >> Needles to say that it is perfectly valid to have client host name like >> client.unrelated.example.org. (not the .org at the end!). > > . at the end? That is new to me Sorry if I confused you. . at the end in DNS world denotes root DNS domain and thus end of fully specified DNS name. The trailing period is often omitted for brevity as a lot of software implicitly assumes that the name is fully qualified. Still, me and RFC 1034 like to spell it explicitly so it is clear what is absolute name and what is relative name with unspecified domain part (aka "origin"). Further reading on this topic can be found on https://tools.ietf.org/html/rfc1034#page-8 Petr^2 Spacek >> Having said that, I believe that SSSD should not try to be smarter in this >> area because it cannot do better without making wrong and surprising >> decisions >> in more complicated setups. >> >> Petr^2 Spacek >> >> >>> >>> -----Original Message----- >>> From: Joakim Tjernlund [mailto:[email protected]] >>> Sent: Monday, August 22, 2016 10:42 AM >>> To: [email protected] >>> Subject: [SSSD-users] Re: DDNS not working due to non FQDN hostname >>> >>> On Mon, 2016-08-22 at 10:23 +0200, Jakub Hrozek wrote: >>>> >>>> On Mon, Aug 22, 2016 at 08:16:36AM +0000, Ondrej Valousek wrote: >>>>> >>>>> >>>>> Ok, so you Jakub say that /etc/hostname should rather contain FQDN right? >>>> >>>> No, I'm saying that gethostname()/hostname should return a FQDN. >>>> You're likely to run into all kinds of issues anyway if your system is >>>> configured with shortnames. >>> >>> Seems to be different "standards", each distribution seems to have selected >>> some variant. >>> I think claiming that "gethostname()/hostname should return a FQDN" is THE >>> standard will not hold, but >>> some dists has adopted this to make life easier in some areas. >>> >>> I added this short patch to sssd which will at least try to do the right >>> thing: >>> >>> --- sssd-1.13.1/src/providers/ad/ad_common.c.org 2016-08-21 >>> 17:47:09.501079617 +0200 >>> +++ sssd-1.13.1/src/providers/ad/ad_common.c 2016-08-21 >>> 17:52:13.059669848 +0200 >>> @@ -397,6 +397,11 @@ >>> goto done; >>> } >>> hostname[HOST_NAME_MAX] = '\0'; >>> + /* If hostname is non FQDN, add ad_domain */ >>> + if (strchr(hostname,'.') == NULL) { >>> + strncat(hostname, ".", HOST_NAME_MAX - 1); >>> + strncat(hostname, domain, HOST_NAME_MAX - 1); >>> + } >>> DEBUG(SSSDBG_CONF_SETTINGS, >>> "Setting ad_hostname to [%s].\n", hostname); >>> ret = dp_opt_set_string(opts->basic, AD_HOSTNAME, hostname); >>>> >>>> >>>>> >>>>> >>>>> I was not sure what RedHat says in terms of "best practices" here. >>>> >>>> This is upstream list, the fact that my address ends with .redhat.com >>>> is irrelevant. >>>> >>>>> >>>>> >>>>> >>>>> But I agree the from the admin prospective, we ideally need to have >>>>> the same configuration in sssd.conf being shared by all hosts. >>>>> Ondrej _______________________________________________ sssd-users mailing list [email protected] https://lists.fedorahosted.org/admin/lists/[email protected]
