Hi,
the attached patches implement fetching the keytab for one-way trusts on each sssd restart. This is in order for admin to be able to call service sssd restart and have fresh keytabs in case the trust was re-established in the meantime.
Even though retrieving the keytabs is quite expensive operation, restarting the sssd instance on the IPA server should be quite rare.
On Thu, Jul 30, 2015 at 09:46:11PM +0200, Jakub Hrozek wrote:
Hi,
the attached patches implement fetching the keytab for one-way trusts on each sssd restart. This is in order for admin to be able to call service sssd restart and have fresh keytabs in case the trust was re-established in the meantime.
Even though retrieving the keytabs is quite expensive operation, restarting the sssd instance on the IPA server should be quite rare.
Sorry, I shouldn't be sending patches before Coverity results arrive. Attached version fixes error handling in the first patch and fixes an unused variable in the second one.
On 07/30/2015 09:52 PM, Jakub Hrozek wrote:
On Thu, Jul 30, 2015 at 09:46:11PM +0200, Jakub Hrozek wrote:
Hi,
the attached patches implement fetching the keytab for one-way trusts on each sssd restart. This is in order for admin to be able to call service sssd restart and have fresh keytabs in case the trust was re-established in the meantime.
Even though retrieving the keytabs is quite expensive operation, restarting the sssd instance on the IPA server should be quite rare.
Sorry, I shouldn't be sending patches before Coverity results arrive. Attached version fixes error handling in the first patch and fixes an unused variable in the second one.
Hi, the code looks good. I just have an idea to move the talloc destructor that ensure the temporary file will get unlinked into sss_unique_file.
We can provide a talloc context there and setup a destructor if requested. Something like:
sss_unique_file(owner, file) if owner != NULL talloc_set_destructor
On Fri, Aug 07, 2015 at 12:22:39PM +0200, Pavel Březina wrote:
On 07/30/2015 09:52 PM, Jakub Hrozek wrote:
On Thu, Jul 30, 2015 at 09:46:11PM +0200, Jakub Hrozek wrote:
Hi,
the attached patches implement fetching the keytab for one-way trusts on each sssd restart. This is in order for admin to be able to call service sssd restart and have fresh keytabs in case the trust was re-established in the meantime.
Even though retrieving the keytabs is quite expensive operation, restarting the sssd instance on the IPA server should be quite rare.
Sorry, I shouldn't be sending patches before Coverity results arrive. Attached version fixes error handling in the first patch and fixes an unused variable in the second one.
Hi, the code looks good. I just have an idea to move the talloc destructor that ensure the temporary file will get unlinked into sss_unique_file.
We can provide a talloc context there and setup a destructor if requested. Something like:
sss_unique_file(owner, file) if owner != NULL talloc_set_destructor
Hi,
please see the attached patches. Since the unique file code is not totally trivial (even though tested) I will move using the sss_unique_file() interface in other sssd code into a different patchset -- I would like to apply these patches to downstream and changing the mkstemp() calls might be too risky there.
On 08/12/2015 02:20 PM, Jakub Hrozek wrote:
On Fri, Aug 07, 2015 at 12:22:39PM +0200, Pavel Březina wrote:
On 07/30/2015 09:52 PM, Jakub Hrozek wrote:
On Thu, Jul 30, 2015 at 09:46:11PM +0200, Jakub Hrozek wrote:
Hi,
the attached patches implement fetching the keytab for one-way trusts on each sssd restart. This is in order for admin to be able to call service sssd restart and have fresh keytabs in case the trust was re-established in the meantime.
Even though retrieving the keytabs is quite expensive operation, restarting the sssd instance on the IPA server should be quite rare.
Sorry, I shouldn't be sending patches before Coverity results arrive. Attached version fixes error handling in the first patch and fixes an unused variable in the second one.
Hi, the code looks good. I just have an idea to move the talloc destructor that ensure the temporary file will get unlinked into sss_unique_file.
We can provide a talloc context there and setup a destructor if requested. Something like:
sss_unique_file(owner, file) if owner != NULL talloc_set_destructor
Hi,
please see the attached patches. Since the unique file code is not totally trivial (even though tested) I will move using the sss_unique_file() interface in other sssd code into a different patchset -- I would like to apply these patches to downstream and changing the mkstemp() calls might be too risky there.
Ack.
On Thu, Aug 13, 2015 at 09:52:40AM +0200, Pavel Březina wrote:
On 08/12/2015 02:20 PM, Jakub Hrozek wrote:
On Fri, Aug 07, 2015 at 12:22:39PM +0200, Pavel Březina wrote:
On 07/30/2015 09:52 PM, Jakub Hrozek wrote:
On Thu, Jul 30, 2015 at 09:46:11PM +0200, Jakub Hrozek wrote:
Hi,
the attached patches implement fetching the keytab for one-way trusts on each sssd restart. This is in order for admin to be able to call service sssd restart and have fresh keytabs in case the trust was re-established in the meantime.
Even though retrieving the keytabs is quite expensive operation, restarting the sssd instance on the IPA server should be quite rare.
Sorry, I shouldn't be sending patches before Coverity results arrive. Attached version fixes error handling in the first patch and fixes an unused variable in the second one.
Hi, the code looks good. I just have an idea to move the talloc destructor that ensure the temporary file will get unlinked into sss_unique_file.
We can provide a talloc context there and setup a destructor if requested. Something like:
sss_unique_file(owner, file) if owner != NULL talloc_set_destructor
Hi,
please see the attached patches. Since the unique file code is not totally trivial (even though tested) I will move using the sss_unique_file() interface in other sssd code into a different patchset -- I would like to apply these patches to downstream and changing the mkstemp() calls might be too risky there.
Ack.
Thank you; pushed to master: d95bcfe23c574de7b6b7b44b52a0d4db5cc8529a db5f9ab3feb85aa444eab20428ca2b98801b6783
sssd-devel@lists.fedorahosted.org