I'm working on pam_sss.so tests and I ran into a problem that I don't
know how to solve best.
tl;dr, I would like to set different environment variables for different
tests in order to set up cwrap libraries differently per-test.
I can't use setenv() in the test itself, because that's too late, I need
the variables to be set when __attribute__(constructor) is run, so normally
at program startup, when the libraries are loaded.
With cmake it's easy, use set(TEST_ENVIRONMENT). But with autotools, I
only found two ways:
- TESTS_ENVIRONMENT - this is fine, but it's per Makefile.am. So I
would have to split the tests more, into pam_wrapper tests that also
require uid_wrapper, tests that only require pam_wrapper, ...
- LOG_COMPILER - this allows to run a wrapper script before a test
that receives the test name as argv. So this is pretty much what I
want except this is a feature new to automake 1.12, which would
rule out both RHEL-6 and Ubuntu Trusty (which is used by Travis)
So I'm really leaning towards creating a src/tests/cwrap/pwrap/Makefile.am
and src/tests/cwrap/pwrap_root/Makefile.am. The downside of multiple
Makefile.am files is that there is some code duplication and the build
takes longer. But I still think there is enough interest (from us and from
our users) to support git master on old platforms. I can file a ticket to
remove this and use LOG_COMPILER when we drop support for RHEL-6 and old
If you disagree, please reply, otherwise I'm going to send a patch with
42% code coverage, up from 0% last week. Woo!
please see attached patch set which contains some refactoring which is
in my opinion quite safe. It doesn't touch the recursive call of
pam_reply() as I think that changing that would be more risky change.
the attached patches are my proposal to fix
I haven't tested them past make check yet, because I'm not sure I like
them myself :) but at the same time I can't see a better way to keep
track of the servers and let callers set state of servers.
The most ugly thing so far IMO is the fo_internal_owner member. I would
prefer to instead have a fo_server_wrap structure that would be used for
the server_list, but I didn't want to do a large change before we agree
the refcount is a good idea at all.
The other ugly side-effect is that we need to be sure that nobody calls
talloc_free on the fo_server structure. Instead, only the parent context
can be freed (that's also what the first patch is about).
Attached patches reduce count of compiled ".c" files
from 935 -> 815 (almost 9%). This reduction is achieved
in deduplication of compiling "*.c" files in tests.
BTW the tests were compiled 4 times in our CI script.
* make tests
* mock build
* make distcheck
* code coverage
The result saving will not be 9% of time due to parallel build
but it still worth. (and Makefile.am is simpler)
We have 19 patches in 1.11 branch on top of latest release (1.11.7)
I went through bugs filed against 1.11 branch and filter
crashes and the most important bugs.
Attached are cherrry-picked patches from 1.12/master
So we can release the latest 1.11 version. It will be just a bug-fix release.
So some conservative distribution can use it or in another words.
we don't want have 1.11 branch neither in unreleased not in unclosed state :-)
BTW I test packages with LDAP KRB5 and AD test. Of course there are any
regressions because it is a bug fix only release.
Here is a patch set fixing some things in integration tests and adding more
* Adding/removing a user/group/membership with rfc2307(bis) schema.
* Filtering users/groups with rfc2307(bis) schema.
* The effect of override_homedir option.
* The effect of fallback_homedir option.
* The effect of override_shell option.
* The effect of shell_fallback option.
* The effect of default_shell option.
* The effect of vetoed_shells option.
These are pretty basic, but I think they're good for the start.
Suggestions for more tests are welcome :)
NOTE: These still break test_memory_cache.py as seen in the attached log file.
We need to figure out why and do something with it. Otherwise, the
tests work fine.
I noticed this bug while working on the SSH fix with
default_domain_suffix. It turns out our filter_users/filter_groups don't
work well in this scenario, which might have effect on the server load
even. Attached are patches that re-initialize negcache with filter_lists
contents after the subdomains are (re)discovered. All patches have