[PATCH] DATA_PROVIDER: BE_REQ as string in log message
by Petr Cech
Hi,
I investigated the situation around the log message, which mentioned
Lukas. I prepared this patch. The result is that the original message
> [sssd[be[cygnus.dev]]] [be_get_account_info] (0x0200): Got request
for [0x1001][1][name=celestian]
changed to
> [sssd[be[cygnus.dev]]] [be_get_account_info] (0x0200): Got request
for [0x1001][FAST BE_REQ_USER][1][name=celestian]
A)
I would like to ask if mark 'FAST' is useful, or if I should remove it.
B)
While writing a patch Lukas noticed another similar logging messages
> [sssd[pam]] [sss_dp_get_account_msg] (0x0400): Creating request for
[LDAP][3][1][name=mof_user6]
I investigated it. This is the same thing -- BE_REQ_*, but it is no
longer in the provider, but in the responder. Can you please advise me
where I could the function 'be_req2str' write?
The first message is coming from
> src/providers/data_provider_be.c --> be_get_account_info,
the second is from
> src/responder/common/responder_dp --> sss_dp_get_account_msg
Thanks.
Petr
8 years, 7 months
[PATCH] Workaround for dyndns_test_ok failiure on mips(el). Child part has finished before the child handler was created.
by Jurica Stanojkovic
Hello,
Package sssd_1.11.5.1-1 on Debian FTBFS for mips and mipsel.
https://buildd.debian.org/status/fetch.php?pkg=sssd&arch=mips&ver=1.11.5....
https://buildd.debian.org/status/fetch.php?pkg=sssd&arch=mipsel&ver=1.11....
dyndns_test_ok is failing with following log:
[ RUN ] dyndns_test_ok(Tue Jul 8 15:53:55:004476 2014) [sssd] [be_nsupdate_args] (0x0200): (Tue Jul 8 15:53:55:004521 2014) [sssd] [child_handler_setup] (0x2000): nsupdate auth type: GSS-TSIGSetting up signal handler up for pid [21397](Tue Jul 8 15:53:55:004693 2014) [sssd] [__wrap_execv] (0x0200): nsupdate success test case(Tue Jul 8 15:53:55:004825 2014) [sssd] [__wrap_execv] (0x1000): Child exiting with status 0(Tue Jul 8 15:53:55:005275 2014) [sssd] [child_handler_setup] (0x2000): Signal handler set up for pid [21397](Tue Jul 8 15:54:55:837623 2014) [sssd] [write_pipe_handler] (0x0020): write failed [32][Broken pipe].(Tue Jul 8 15:54:55:837801 2014) [sssd] [nsupdate_child_stdin_done] (0x1000): Sending nsupdate data complete(Tue Jul 8 15:54:55:837869 2014) [sssd] [nsupdate_child_stdin_done] (0x0040): Sending nsupdate data failed [32]: Broken pipe(Tue Jul 8 15:54:55:837947 2014) [sssd] [be_nsupdate_done] (0x0040): nsupdate child execution failed [1432158228]: Dynamic DNS update failed(Tue Jul 8 15:54:55:837985 2014) [sssd] [dyndns_test_ok] (0x1000): Child request returned [1432158228]: Unknown error 14321582280x555d0014 != 0../src/tests/cmocka/test_dyndns.c:222: error: Failure![ FAILED ] dyndns_test_okChild part has finished before the child handler was created.
I have created and attached a patch which is workaround for this issue.
Could someone please take a look and comment this?
Thank you!
Sincerely,
Jurica
8 years, 7 months
[PATCH] SYSDB: Index the objectSIDString attribute
by Jakub Hrozek
Hi,
the attached patch was confirmed to work, so the code review should be
easy. But because it adds an index to objectSID, which all AD objects
have, there are two catches:
1) How log the upgrade takes
2) How much the database grows
To test, I created an AD instance with 10.000 users and 10.000 groups
(adcli is great for this type of testing btw). Fetched all groups and
users with the old db, then ran the upgrade.
On a VM running on my local laptop (granted, it has an SSD drive), the
upgrade takes 10 seconds. The default systemd startup timeout
(DefaultTimeoutStartSec) seems to be 90 seconds, which sounds OK to me.
The size, though, has nearly doubled. This is backup before upgrade:
[root@adclient ~]# du -sh /root/cache_win.trust.test.ldb
47M /root/cache_win.trust.test.ldb
And this is the cache after I upgraded:
[root@adclient ~]# du -sh /var/lib/sss/db/cache_win.trust.test.ldb
97M /var/lib/sss/db/cache_win.trust.test.ldb
Unfortunately, I don't see us having another option than doing the
upgrade. For attributes that are indexed, an index miss means that ldb
is not going to search sequentially, but just return not found -- so
adding indexes for newly added entries is not possible.
I would like to document that for huge databases (tens of thousands of
cached entries), the timeout might need to be raised during the upgrade
and than for deployments whose cache resides in tmpfs, the cache size
might grow.
Is everyone OK with this?
8 years, 7 months
[PATCH] Remove trailing whitespace
by Pavel Reichl
Hello,
please see trivial patch attached. I noticed some whitespace in source
file, so I did some grepping and decided to remove it as we already were
almost 100 % trailing whitespace free.
Thanks
8 years, 8 months
Code style -- for loop iterative variables initial declaration
by Petr Cech
Hi everyone,
I would like to ask you what you think about the initialization of
iterative variables in forloops. I know that present code style does not
allow it. But how I recognized, we use C99, and this feature is here now.
(example)
Instead of:|
|||# inti;
# for(i =0;...)|||
we could write:
||# for(inti =0;...)|
I see an advantage in limiting the validity of such variables. That
means higher code readability. Disadvantages I searched but did not find.
Regards
Petr
8 years, 8 months