[Freeipa-users] Sudo entry not found by sssd in the cache db
Pavel Březina
pbrezina at redhat.com
Tue Sep 29 11:49:25 UTC 2015
On 09/15/2015 09:10 AM, Molnár Domokos wrote:
>
> "Molnár Domokos" <kretebe at freemail.hu> írta:
>
> On 09/14/2015 03:08 PM, Pavel Březina wrote:
>> On 09/11/2015 02:40 PM, Molnár Domokos wrote:
>>> Full log attached.
>>> "Molnár Domokos" <kretebe at freemail.hu> írta:
>>>
>>>
>>> "Pavel Březina" <pbrezina at redhat.com> írta:
>>>
>>> On 09/09/2015 09:31 PM, Molnár Domokos wrote:
>>> > I have a working IPA server and a working client
>>> config on an OpenSuse
>>> > 13.2 with the following versions:
>>> > nappali:~ # rpm -qa |grep sssd
>>> > sssd-tools-1.12.2-3.4.1.i586
>>> > sssd-krb5-1.12.2-3.4.1.i586
>>> > python-sssd-config-1.12.2-3.4.1.i586
>>> > sssd-ipa-1.12.2-3.4.1.i586
>>> > sssd-1.12.2-3.4.1.i586
>>> > sssd-dbus-1.12.2-3.4.1.i586
>>> > sssd-krb5-common-1.12.2-3.4.1.i586
>>> > sssd-ldap-1.12.2-3.4.1.i586
>>> > sssd is confihured for nss, pam, sudo
>>> > There is a test sudo rule defined in the ipa server,
>>> which applies to
>>> > user "doma". However when the user tries to use sudo
>>> the rule does not
>>> > work.
>>> > doma at nappali:/home/doma> sudo ls
>>> > doma's password:
>>> > doma is not allowed to run sudo on nappali. This
>>> incident will be reported.
>>> > The corresponding log in the sssd_sudo.log is this:
>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]]
>>> [sss_cmd_get_version] (0x0200):
>>> > Received client version [1].
>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]]
>>> [sss_cmd_get_version] (0x0200):
>>> > Offered version [1].
>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]]
>>> [sss_parse_name_for_domains]
>>> > (0x0200): name 'doma' matched without domain, user is doma
>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]]
>>> [sss_parse_name_for_domains]
>>> > (0x0200): name 'doma' matched without domain, user is doma
>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]]
>>> [sudosrv_cmd_parse_query_done]
>>> > (0x0200): Requesting default options for [doma] from
>>> [<ALL>]
>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]]
>>> [sudosrv_get_user] (0x0200):
>>> > Requesting info about [doma at szilva]
>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]]
>>> > [sudosrv_get_sudorules_query_cache] (0x0200):
>>> Searching sysdb with
>>> >
>>> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]]
>>> > [sudosrv_get_sudorules_query_cache] (0x0200):
>>> Searching sysdb with
>>> > [(&(objectClass=sudoRule)(|(name=defaults)))]
>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]]
>>> [sss_parse_name_for_domains]
>>> > (0x0200): name 'doma' matched without domain, user is doma
>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]]
>>> [sss_parse_name_for_domains]
>>> > (0x0200): name 'doma' matched without domain, user is doma
>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]]
>>> [sudosrv_cmd_parse_query_done]
>>> > (0x0200): Requesting rules for [doma] from [<ALL>]
>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]]
>>> [sudosrv_get_user] (0x0200):
>>> > Requesting info about [doma at szilva]
>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]]
>>> > [sudosrv_get_sudorules_query_cache] (0x0200):
>>> Searching sysdb with
>>> >
>>> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]]
>>> > [sudosrv_get_sudorules_query_cache] (0x0200):
>>> Searching sysdb with
>>> >
>>> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))]
>>> > (Wed Sep 9 21:25:30 2015) [sssd[sudo]] [client_recv]
>>> (0x0200): Client
>>> > disconnected!
>>> > This seems perfectly OK with one exception. The query
>>> against the sysdb
>>> > does not find the entry. This is strange because the
>>> entry is there.
>>> > Log in sssd.log:
>>> > (Wed Sep 2 08:52:13 2015) [sssd]
>>> [sysdb_domain_init_internal] (0x0200):
>>> > DB File for szilva: /var/lib/sss/db/cache_szilva.ldb
>>> > So we know that the sysdb is
>>> /var/lib/sss/db/cache_szilva.ldb
>>> > Running the exact same query seen above in the
>>> sssd_sudo.log against the
>>> > db returns:
>>> > ldbsearch -H /var/lib/sss/db/cache_szilva.ldb
>>> >
>>> "(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))"
>>> > asq: Unable to register control with rootdse!
>>> > # record 1
>>> > dn: name=Doma_ls,cn=sudorules,cn=custom,cn=szilva,cn=sysdb
>>> > cn: Doma_ls
>>> > dataExpireTimestamp: 1441830262
>>> > entryUSN: 20521
>>> > name: Doma_ls
>>> > objectClass: sudoRule
>>> > originalDN: cn=Doma_ls,ou=sudoers,dc=szilva
>>> > sudoCommand: ls
>>> > sudoHost: nappali.szilva
>>> > sudoRunAsGroup: ALL
>>> > sudoRunAsUser: ALL
>>> > sudoUser: doma
>>> > distinguishedName:
>>> name=Doma_ls,cn=sudorules,cn=custom,cn=szilva,cn=sysdb
>>> > # returned 1 records
>>> > # 1 entries
>>> > # 0 referrals
>>> > This confirms that the entry is indeed there in the
>>> db. Why is it found
>>> > with ldbsearch and why does sssd_sudo not find it?
>>> > I am pretty much stuck with this one. Anyone has an idea?
>>> >
>>> >
>>> Hi,
>>> this is strange. Can you provide the logs with debug
>>> level set to 0x3ff0
>>>
>>> please? Can you also send it as an attachment? Thanks!
>>>
>>> Sure. Here it is. Now I can see that the rule is returned. The
>>> question is why the rule does not match. Anyway much better :)
>>
>> Hi, thanks for the logs. Since the rule is returned, we will get
>> more information from sudo logs. Can you please enable sudo
>> logging by putting the following line into /etc/sudo.conf?
>>
>> Debug sudo /var/log/sudo_debug all at trace
>>
>> Run sudo and send us /var/log/sudo_debug? Thanks
>
> Thanks for the tip with the proper debug syntax - I was unable to
> get a single log item out of sudo before.
>
> I think I have found something. This is the relevant part of the
> output of all at debug (you need this not trace I think):
>
> Sep 14 22:13:39 sudo[2314] username=doma
> Sep 14 22:13:39 sudo[2314] domainname=NULL
> Sep 14 22:13:39 sudo[2314] state |= USERMATCH
> Sep 14 22:13:39 sudo[2314] Received 1 rule(s)
> Sep 14 22:13:39 sudo[2314] -> sudo_sss_filter_result @ ./sssd.c:175
> Sep 14 22:13:39 sudo[2314] in_res=0xb7c9c1b8, count=1, act=INCLUDE
> Sep 14 22:13:39 sudo[2314] emalloc: cnt=1
> Sep 14 22:13:39 sudo[2314] -> sudo_sss_result_filterp @ ./sssd.c:648
> Sep 14 22:13:39 sudo[2314] -> sudo_sss_check_host @ ./sssd.c:556
> Sep 14 22:13:39 sudo[2314] val[0]=nappali.szilva
> Sep 14 22:13:39 sudo[2314] -> addr_matches @ ./match_addr.c:206
> Sep 14 22:13:39 sudo[2314] -> addr_matches_if @ ./match_addr.c:61
> Sep 14 22:13:39 sudo[2314] <- addr_matches_if @ ./match_addr.c:71 :=
> false
> Sep 14 22:13:39 sudo[2314] IP address nappali.szilva matches local
> host: false @ addr_matches() ./match_addr.c:217
> Sep 14 22:13:39 sudo[2314] <- addr_matches @ ./match_addr.c:218 := false
> Sep 14 22:13:39 sudo[2314] -> netgr_matches @ ./match.c:941
> Sep 14 22:13:39 sudo[2314] netgroup appali.szilva has no leading '+'
> Sep 14 22:13:39 sudo[2314] <- netgr_matches @ ./match.c:953 := false
> Sep 14 22:13:39 sudo[2314] -> hostname_matches @ ./match.c:776
> Sep 14 22:13:39 sudo[2314] host nappali matches sudoers pattern
> nappali.szilva: false @ hostname_matches() ./match.c:788
> Sep 14 22:13:39 sudo[2314] <- hostname_matches @ ./match.c:789 := false
> Sep 14 22:13:39 sudo[2314] sssd/ldap sudoHost 'nappali.szilva' ... not
> Sep 14 22:13:39 sudo[2314] <- sudo_sss_check_host @ ./sssd.c:591 :=
> false
> Sep 14 22:13:39 sudo[2314] <- sudo_sss_result_filterp @ ./sssd.c:654
> := 0
> Sep 14 22:13:39 sudo[2314] reallocating result: 0xb7cb1900 (count: 1
> -> 0)
> Sep 14 22:13:39 sudo[2314] <- sudo_sss_filter_result @ ./sssd.c:221
> := 0xb7c9e410
> Sep 14 22:13:39 sudo[2314] u_sss_result=(0xb7c9c1b8, 1) =>
> f_sss_result=(0xb7c9e410, 0)
> Sep 14 22:13:39 sudo[2314] <- sudo_sss_result_get @ ./sssd.c:728 :=
> 0xb7c9e410
> Sep 14 22:13:39 sudo[2314] searching SSSD/LDAP for sudoers entries
> Sep 14 22:13:39 sudo[2314] Done with LDAP searches
>
>
> And here is the code from match.c.
>
> bool
> hostname_matches(const char *shost, const char *lhost, const char
> *pattern)
> {
> debug_decl(hostname_matches, SUDO_DEBUG_MATCH)
> const char *host;
> bool rc;
>
> host = strchr(pattern, '.') != NULL ? lhost : shost;
> if (has_meta(pattern)) {
> rc = !fnmatch(pattern, host, FNM_CASEFOLD);
> } else {
> rc = !strcasecmp(host, pattern);
> }
> sudo_debug_printf(SUDO_DEBUG_DEBUG|SUDO_DEBUG_LINENO,
> "host %s matches sudoers pattern %s: %s",
> host, pattern, rc ? "true" : "false");
> debug_return_bool(rc);
> }
>
> By the look of it it should match. I tried to find out how shost and
> lhost get their values - these are macros to a member of the
> sudo_user struct but that part is not debugged. Only thing I can
> confirm is that I do not get the
>
> log_warning(MSG_ONLY, N_("unable to resolve host %s"), user_host);
>
> from line 816 of sudoers.c.
>
> I also checked the hosts file and there I do have the
>
> 192.168.110.3 nappali nappali.szilva
>
> entry.
>
> Still stuck whit this.
> On 09/14/2015 03:08 PM, Pavel Březina wrote:
> On 09/11/2015 02:40 PM, Molnár Domokos wrote:
> Full log attached.
> "Molnár Domokos" írta:
>
>
> "Pavel Březina" írta:
>
> On 09/09/2015 09:31 PM, Molnár Domokos wrote:
>
> > I have a working IPA server and a working client config on an OpenSuse
> > 13.2 with the following versions:
> > nappali:~ # rpm -qa |grep sssd
> > sssd-tools-1.12.2-3.4.1.i586
> > sssd-krb5-1.12.2-3.4.1.i586
> > python-sssd-config-1.12.2-3.4.1.i586
> > sssd-ipa-1.12.2-3.4.1.i586
> > sssd-1.12.2-3.4.1.i586
> > sssd-dbus-1.12.2-3.4.1.i586
> > sssd-krb5-common-1.12.2-3.4.1.i586
> > sssd-ldap-1.12.2-3.4.1.i586
> > sssd is confihured for nss, pam, sudo
>
> > There is a test sudo rule defined in the ipa server, which applies to
> > user "doma".
> However when the user tries to use sudo the rule does not
> > work.
> > doma at nappali:/home/doma> sudo ls
> > doma's password:
> > doma is not allowed to run sudo on nappali.
> This incident will be reported.
> > The corresponding log in the sssd_sudo.log is this:
> > (Wed Sep
> 9 21:25:25 2015) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
> > Received client version [1].
> > (Wed Sep
> 9 21:25:25 2015) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
> > Offered version [1].
> > (Wed Sep
> 9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
>
> > (0x0200): name 'doma' matched without domain, user is doma
> > (Wed Sep
> 9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
>
> > (0x0200): name 'doma' matched without domain, user is doma
> > (Wed Sep
> 9 21:25:25 2015) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
> > (0x0200): Requesting default options for [doma] from []
> > (Wed Sep
> 9 21:25:25 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):
> > Requesting info about [doma at szilva]
> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]]
>
> > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
>
> > [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp
> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]]
>
> > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
> > [(&(objectClass=sudoRule)(|(name=defaults)))]
> > (Wed Sep
> 9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
>
> > (0x0200): name 'doma' matched without domain, user is doma
> > (Wed Sep
> 9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains]
>
> > (0x0200): name 'doma' matched without domain, user is doma
> > (Wed Sep
> 9 21:25:25 2015) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
> > (0x0200): Requesting rules for [doma] from []
> > (Wed Sep
> 9 21:25:25 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):
> > Requesting info about [doma at szilva]
> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]]
>
> > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
>
> > [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp
> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]]
>
> > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
>
> > [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))]
> > (Wed Sep
> 9 21:25:30 2015) [sssd[sudo]] [client_recv] (0x0200): Client
> > disconnected!
>
> > This seems perfectly OK with one exception. The query against the sysdb
>
> > does not find the entry. This is strange because the entry is there.
> > Log in sssd.log:
> > (Wed Sep
> 2 08:52:13 2015) [sssd] [sysdb_domain_init_internal] (0x0200):
> > DB File for szilva: /var/lib/sss/db/cache_szilva.ldb
>
> > So we know that the sysdb is /var/lib/sss/db/cache_szilva.ldb
>
> > Running the exact same query seen above in the sssd_sudo.log against the
> > db returns:
> > ldbsearch -H /var/lib/sss/db/cache_szilva.ldb
> >
> "(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))"
> > asq: Unable to register control with rootdse!
> > # record 1
> > dn: name=Doma_ls,cn=sudorules,cn=custom,cn=szilva,cn=sysdb
> > cn: Doma_ls
> > dataExpireTimestamp: 1441830262
> > entryUSN: 20521
> > name: Doma_ls
> > objectClass: sudoRule
> > originalDN: cn=Doma_ls,ou=sudoers,dc=szilva
> > sudoCommand: ls
> > sudoHost: nappali.szilva
> > sudoRunAsGroup: ALL
> > sudoRunAsUser: ALL
> > sudoUser: doma
>
> > distinguishedName: name=Doma_ls,cn=sudorules,cn=custom,cn=szilva,cn=sysdb
> > # returned 1 records
> > # 1 entries
> > # 0 referrals
>
> > This confirms that the entry is indeed there in the db. Why is it found
> > with ldbsearch and why does sssd_sudo not find it?
> > I am pretty much stuck with this one. Anyone has an idea?
> >
> >
> Hi,
>
> this is strange. Can you provide the logs with debug level set to 0x3ff0
>
> please? Can you also send it as an attachment? Thanks!
>
> Sure. Here it is. Now I can see that the rule is returned. The
> question is why the rule does not match. Anyway much better :)
>
> Hi, thanks for the logs. Since the rule is returned, we will get more information from sudo logs. Can you please enable sudo logging by putting the following line into /etc/sudo.conf?
>
> Debug sudo /var/log/sudo_debug all at trace
>
> Run sudo and send us /var/log/sudo_debug? Thanks
>
> Thanks for the tip with the proper debug syntax - I was unable to get a single log item out of sudo before.
>
> I think I have found something. This is the relevant part of the output of all at debug (you need this not trace I think):
>
> Sep 14 22:13:39 sudo[2314] username=doma
> Sep 14 22:13:39 sudo[2314] domainname=NULL
> Sep 14 22:13:39 sudo[2314] state |= USERMATCH
> Sep 14 22:13:39 sudo[2314] Received 1 rule(s)
> Sep 14 22:13:39 sudo[2314] -> sudo_sss_filter_result @ ./sssd.c:175
> Sep 14 22:13:39 sudo[2314] in_res=0xb7c9c1b8, count=1, act=INCLUDE
> Sep 14 22:13:39 sudo[2314] emalloc: cnt=1
> Sep 14 22:13:39 sudo[2314] -> sudo_sss_result_filterp @ ./sssd.c:648
> Sep 14 22:13:39 sudo[2314] -> sudo_sss_check_host @ ./sssd.c:556
> Sep 14 22:13:39 sudo[2314] val[0]=nappali.szilva
> Sep 14 22:13:39 sudo[2314] -> addr_matches @ ./match_addr.c:206
> Sep 14 22:13:39 sudo[2314] -> addr_matches_if @ ./match_addr.c:61
> Sep 14 22:13:39 sudo[2314]
> Sep 14 22:13:39 sudo[2314] IP address nappali.szilva matches local host: false @ addr_matches() ./match_addr.c:217
> Sep 14 22:13:39 sudo[2314]
> Sep 14 22:13:39 sudo[2314] -> netgr_matches @ ./match.c:941
> Sep 14 22:13:39 sudo[2314] netgroup appali.szilva has no leading '+'
> Sep 14 22:13:39 sudo[2314]
> Sep 14 22:13:39 sudo[2314] -> hostname_matches @ ./match.c:776
> Sep 14 22:13:39 sudo[2314] host nappali matches sudoers pattern nappali.szilva: false @ hostname_matches() ./match.c:788
> Sep 14 22:13:39 sudo[2314]
> Sep 14 22:13:39 sudo[2314] sssd/ldap sudoHost 'nappali.szilva' ... not
> Sep 14 22:13:39 sudo[2314]
> Sep 14 22:13:39 sudo[2314]
> Sep 14 22:13:39 sudo[2314] reallocating result: 0xb7cb1900 (count: 1 -> 0)
> Sep 14 22:13:39 sudo[2314]
> Sep 14 22:13:39 sudo[2314] u_sss_result=(0xb7c9c1b8, 1) => f_sss_result=(0xb7c9e410, 0)
> Sep 14 22:13:39 sudo[2314]
> Sep 14 22:13:39 sudo[2314] searching SSSD/LDAP for sudoers entries
> Sep 14 22:13:39 sudo[2314] Done with LDAP searches
>
>
> And here is the code from match.c.
>
> bool
> hostname_matches(const char *shost, const char *lhost, const char *pattern)
> {
> debug_decl(hostname_matches, SUDO_DEBUG_MATCH)
> const char *host;
> bool rc;
>
> host = strchr(pattern,'.') != NULL ? lhost : shost;
> if (has_meta(pattern)) {
> rc = !fnmatch(pattern, host, FNM_CASEFOLD);
> } else {
> rc = !strcasecmp(host, pattern);
> }
> sudo_debug_printf(SUDO_DEBUG_DEBUG|SUDO_DEBUG_LINENO,
> "host %s matches sudoers pattern %s: %s",
> host, pattern, rc ? "true" : "false");
> debug_return_bool(rc);
> }
>
> By the look of it it should match. I tried to find out how shost and lhost get their values - these are macros to a member of the sudo_user struct but that part is not debugged. Only thing I can confirm is that I do not get the
>
> log_warning(MSG_ONLY, N_("unable to resolve host %s"), user_host);
>
> from line 816 of sudoers.c.
>
> I also checked the hosts file and there I do have the
>
> 192.168.110.3 nappali nappali.szilva
>
> entry.
>
> Still stuck whit this.
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
> Additional info. In match.c
>
> 780 host = strchr(pattern, '.') != NULL ? lhost : shost;
>
> if the pattern contains a '.' then lhost is used, which is then
>
> 784 rc = !strcasecmp(host, pattern);
>
> compared with the pattern. In our case - from the debug log - host is
> "nappali" while the pattern is "nappali.szilva".
>
> Clearly from some reason lhost does not contain the fqdn as it should. I
> also tested the set_fqdn at line 806 in sudoers.c with this code:
>
> void
> main(void)
> {
> struct addrinfo *res0, hint;
> char *p;
> char *user_host, *user_shost;
>
> user_host=malloc(500);
> user_shost=malloc(500);
>
> memset(&hint, 0, sizeof(hint));
> hint.ai_family = PF_UNSPEC;
> hint.ai_flags = AI_FQDN;
> if (getaddrinfo("nappali", NULL, &hint, &res0) != 0) {
> printf("unable to resolve host %s", user_host);
> } else {
> user_host = strdup(res0->ai_canonname);
> printf ("Canonname, user_host: %s,
> %s\n",res0->ai_canonname,user_host);
> if ((p = strchr(user_host, '.')) != NULL)
> user_shost = strndup(user_host, (size_t)(p - user_host));
> else
> user_shost = user_host;
> }
> printf("Shost: %s\n",user_shost);
> }
>
> This outputs on the host in question:
>
> doma at nappali:/home/doma> cc test.c
> doma at nappali:/home/doma> ./a.out
> Canonname, user_host: nappali.szilva, nappali.szilva
> Shost: nappali
>
> Seems OK.
>
> Any idea?
Hi, I'm sorry for a late delay. Did you manage to create any progress on
this?
More information about the Freeipa-users
mailing list