Design Discussion: Periodic task API
by Pavel Březina
I've been assigned ticket https://fedorahosted.org/sssd/ticket/1713:
[RFE] Add a task to the SSSD to periodically refresh cached entries
I have recently created a ticket (#1891) to unite API for managing
periodic tasks. We already quite a periodic task (enumeration, sudo,
dyndns, #1713) when each of them implements custom API.
None of these are generic enough to be used for #1713 so I will have to
create a new one. I'm not suggesting to refactor the old code now, that
will be done when #1891 is scheduled.
But I think it is a good idea to create the generic one now instead of a
new feature-specific. It will be basically the same amount of work.
I wrote a design document:
https://fedorahosted.org/sssd/wiki/DesignDocs/PeriodicTasks
10 years, 11 months
[PATCH] New dynamic DNS update options
by Jakub Hrozek
Hi,
the attached patches implement a couple of new dynamic DNS options. The
AD dyndns code will be just a wrapper around these options.
[PATCH 1/5] dyndns: new option dyndns_refresh_interval
This new options adds the possibility of updating the DNS entries
periodically regardless if they have changed or not. This feature
will be useful mainly in AD environments where the Windows clients
periodically update their DNS records.
There is one place (in IPA dyndns code in this patch but also in AD code
later on) that I wanted to discuss specifically. It may happen that the
periodic update would trigger going online in which case the online
callback would fire and another dyndns update would be invoked as an
online callback. To prevent a race between these two updates, there is
an interval, currently hardcoded to 60 seconds that would just make the
next update quit without doing anything. Ideas on how to fix the problem
without a hardcoded timeout are welcome.
[PATCH 2/5] resolver: Return PTR record as string
Having the possibility to format a PTR record based on an A/AAAA record
is a requirement to update the PTR records.
Includes a unit test.
[PATCH 3/5] dyndns: New option dyndns_update_ptr
https://fedorahosted.org/sssd/ticket/1832
While some servers, such as FreeIPA allow the PTR record to be
synchronized when the forward record is updated, other servers,
including Active Directory, require that the PTR record is synchronized
manually.
This patch adds a new option, dyndns_update_ptr that automatically
generates appropriate DNS update message for updating the reverse zone.
The PTR update is performed separately from the forward record update
mostly because the current IPA dyndns code allows the zone to be
specified in the message, so another zone must be updated using another
message.
This option is off by default in the IPA provider.
[PATCH 4/5] dyndns: new option dyndns_use_tcp
https://fedorahosted.org/sssd/ticket/1831
Adds a new option that can be used to force nsupdate to only use TCP to
communicate with the DNS server.
[PATCH 5/5] dyndns: new option dyndns_auth
This options is mostly provided for future expansion. Currently it is
undocumented and both IPA and AD dynamic DNS updates default to
GSS-TSIG. Allowed values are GSS-TSIG and none.
10 years, 12 months
[PATCH] Make the dynamic DNS updates backend-agnostic
by Jakub Hrozek
These two patches depend on patches in that decouple the memory checking
from the check tool.
[PATCH 1/2] Refactor dynamic DNS updates
Provides two new layers instead of the previous IPA specific layer
1) dp_dyndns.c -- a very generic dyndns layer on the DP level. Its purpose
it to make it possible for any back end to use dynamic DNS updates.
2) sdap_dyndns.c -- a wrapper around dp_dyndns.c that utilizes some
LDAP-specific features like autodetecting the address from the LDAP
connection.
Also converts the dyndns code to new specific error codes.
The DP layer includes unit tests that also make sure that
https://fedorahosted.org/sssd/ticket/1802 is fixed.
[PATCH 2/2] Convert IPA-specific options to be back-end agnostic
This patch introduces new options for dynamic DNS updates that are not
specific to any back end. The current ipa dyndns options are still
usable, just with a deprecation warning.
These options will be reused in the AD dynamic DNS updates code.
10 years, 12 months
RADIUS provider
by Ondra Hujňák
Hi,
I added RADIUS client part to rad provider. It communicates with
server now and gets response (Access-Accept or Access-Reject).
All changes are available in rad branch of my github repository:
https://github.com/hujon/sssd.git
I used completely new krad library from Kerberos, so it depends
on krb5-libs and verto now. Because in f19 updates there is old
version with different API you need to install packages from koji:
http://koji.fedoraproject.org/koji/buildinfo?buildID=410384
However when I get response, callback is correctly called,
I call be_req_terminate but the result doesn't reach su, so it
just timeouts and denies access every time.
This is a part of my log:
[be_pam_handler] (0x0100): Got request with the following data
[pam_print_data] (0x0100): command: PAM_AUTHENTICATE
[pam_print_data] (0x0100): domain: RAD
[pam_print_data] (0x0100): user: test
[sssd[be[RAD]]] [pam_print_data] (0x0100): service: su
[sssd[be[RAD]]] [pam_print_data] (0x0100): tty: pts/0
[sssd[be[RAD]]] [pam_print_data] (0x0100): ruser: ondra
[sssd[be[RAD]]] [pam_print_data] (0x0100): rhost:
[sssd[be[RAD]]] [pam_print_data] (0x0100): authtok type: 1
[sssd[be[RAD]]] [pam_print_data] (0x0100): newauthtok type: 0
[sssd[be[RAD]]] [pam_print_data] (0x0100): priv: 0
[sssd[be[RAD]]] [pam_print_data] (0x0100): cli_pid: 14218
[sssd[be[RAD]]] [rad_auth_send] (0x0400): Sending request
[sssd[be[RAD]]] [rad_auth_done] (0x0400): Permission granted for user test.
[sssd[be[RAD]]] [rad_auth_done] (0x0400): Callback terminating be_req.
[sssd[be[RAD]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, <NULL>) [Success]
[sssd[be[RAD]]] [be_pam_handler_callback] (0x0100): Sending result [0][RAD]
[sssd[be[RAD]]] [be_pam_handler_callback] (0x0100): Sent result [0][RAD]
[sssd[be[RAD]]] [rad_auth_done] (0x0400): Callback freeing req.
If you have any idea what's wrong or any other comments about
my code I'll be glad to know ;)
Ondrej
10 years, 12 months
[PATCH] Fix segmentation fault in test_io.
by Lukas Slebodnik
I wanted to revie som patches, but test failed with unrelated issue to revieved
patch.
------------------------------------------
[ RUN ] test_sss_open_cloexec_success
mkstemp failed
fd != -1
ERROR: ../sssd/src/tests/cmocka/test_io.c:81 Failure!
[ FAILED ] test_sss_open_cloexec_success
[ RUN ] test_sss_open_cloexec_fail
[ OK ] test_sss_open_cloexec_fail
[ RUN ] test_sss_openat_cloexec_success
mkstemp failed
11
[ FAILED ] test_sss_openat_cloexec_success
[ RUN ] test_sss_openat_cloexec_fail
/bin/sh: line 5: 12545 Segmentation fault (core dumped) LDB_MODULES_PATH=/dev/shm/sssd_build/ldb_mod_test_dir ${dir}$tst
FAIL: test-io
------------------------------------------
Attached patch fix this bug.
LS
10 years, 12 months
