Lukas,

Thank you for your reply and inquiry.

First, to answer your question; yes, we have been using the 
default_domain_suffix for some time.  I am not sure what you mean by 
previously, but it is currently implemented and has been implemented prior to 
our 1.13 -> 1.14 upgrade.

And yes, I am assessing a possible software regression at the current moment. 
It might be related to the default_domain_suffix you are inquiring about.  
Basically I am getting inconsistent results on invocation of the id command 
with specifying the username as ‘username’ or ‘username@fqdn’ on a client 
running 1.14 against a DC running 1.13 (i.e. no way to reliably invoke id 
against a trusted domain account).  Sometimes the command will return a result, 
and sometimes it will not.  Looking at nss debug logs it appears that a 
duplicate fqdn is being appended to the nss query as show here (as 
@bsdad.uchicago....@bsdad.uchicago.edu<mailto:bsdad.uchicago....@bsdad.uchicago.edu>).
  This lookup fails.

(Fri Jul 15 06:53:07 2016) [sssd[nss]] [get_dp_name_and_id] (0x0400): Not a 
LOCAL view, continuing with provided values.
(Fri Jul 15 06:53:07 2016) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing 
request for 
[0x41e750:1:mjarsu...@bsdad.uchicago.edu<mailto:mjarsu...@bsdad.uchicago.edu>@bsdad.uchicago.edu]
(Fri Jul 15 06:53:07 2016) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): 
Creating request for 
[bsdad.uchicago.edu<http://bsdad.uchicago.edu>][0x1][BE_REQ_USER][1][name=mjarsu...@bsdad.uchicago.edu<mailto:name=mjarsu...@bsdad.uchicago.edu>:-]
(Fri Jul 15 06:53:07 2016) [sssd[nss]] [sbus_add_timeout] (0x2000): 0x7d0860
(Fri Jul 15 06:53:07 2016) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): 
Entering request 
[0x41e750:1:mjarsu...@bsdad.uchicago.edu<mailto:mjarsu...@bsdad.uchicago.edu>@bsdad.uchicago.edu]
(Fri Jul 15 06:53:07 2016) [sssd[nss]] [sbus_remove_timeout] (0x2000): 0x7d0860
(Fri Jul 15 06:53:07 2016) [sssd[nss]] [sbus_dispatch] (0x4000): dbus conn: 
0x7a1730
(Fri Jul 15 06:53:07 2016) [sssd[nss]] [sbus_dispatch] (0x4000): Dispatching.
(Fri Jul 15 06:53:07 2016) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got reply 
from Data Provider - DP error code: 0 errno: 0 error message: Success
(Fri Jul 15 06:53:07 2016) [sssd[nss]] [sss_ncache_check_str] (0x2000): 
Checking negative cache for 
[NCE/USER/bsdad.uchicago.edu/mjarsu...@bsdad.uchicago.edu<mailto:NCE/USER/bsdad.uchicago.edu/mjarsu...@bsdad.uchicago.edu>]
(Fri Jul 15 06:53:07 2016) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): 
Requesting info for 
[mjarsu...@bsdad.uchicago.edu<mailto:mjarsu...@bsdad.uchicago.edu>]
(Fri Jul 15 06:53:07 2016) [sssd[nss]] [ldb] (0x4000): Added timed event 
"ltdb_callback": 0x7bb560

Right now I am considering snapshotting our DC, upgrading the sssd to 1.14 on 
it, flushing the cache on DC and client (both 1.14), and re-testing.

If you have any insight on resolving this issue I’d be interested in hearing 
your thoughts.

Best,

Dan

On Jul 15, 2016, at 6:13 AM, Lukas Slebodnik 
<lsleb...@redhat.com<mailto:lsleb...@redhat.com>> wrote:

On (14/07/16 21:23), Sullivan, Daniel [AAA] wrote:
Justin,

Thank you for taking the time to reply to me; I really appreciate your 
willingness to help.

Upgrading to sssd1.14 (from the copr repo) on the client seems to have fixed 
this problem across the board.  I don’t have a system that is currently broken 
to capture this data, but if it is important for you to have the log data to 
try and resolve this bug I could try to obtain it for you by purposely try to 
induce the issue by upgrading another system and hoping the bug presents 
itself, and then capture the data.  Please advise if you would like me to 
attempt this.

I was really frustrated by this bug and am happy that I can consider this issue 
resolved.  Please let me know if you would like me to try and capture the data 
as you described.

I am glad that 1.14 works for you :-)
But there might be other bugs. I know about few regressions.

BTW about the HBAC issue, did you use the default_domain_suffix previously?

LS


********************************************************************************
This e-mail is intended only for the use of the individual or entity to which
it is addressed and may contain information that is privileged and confidential.
If the reader of this e-mail message is not the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this
communication is prohibited. If you have received this e-mail in error, please 
notify the sender and destroy all copies of the transmittal. 

Thank you
University of Chicago Medicine and Biological Sciences 
********************************************************************************

-- 
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

Reply via email to