[SSSD] Running tests with different environment

Sumit Bose sbose at redhat.com
Wed Oct 21 07:20:50 UTC 2015


On Tue, Oct 20, 2015 at 10:15:06PM +0200, Jakub Hrozek wrote:
> On Tue, Oct 20, 2015 at 05:17:49PM +0300, Nikolai Kondrashov wrote:
> > Hi Jakub,
> > 
> > On 10/19/2015 09:43 PM, Jakub Hrozek wrote:
> > >I'm working on pam_sss.so tests[1] 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
> > >Ubuntu versions...
> > >
> > >If you disagree, please reply, otherwise I'm going to send a patch with
> > >per-test Makefile...
> > 
> > Ah, so these are unit tests, not integration tests?
> 
> I'm working on both, actually. The first part is more or less an
> isolated unit test of all the options that pam_sss supports. The reason
> is that some options (2FA, smart cards, ...) are not really easily
> testable without a mock back end, at the moment we only have openldap in
> the integration tests.
> 
> The next step I will start right after I finish this part is integration
> tests that will exercise LDAP authentication, password change and maybe
> authorisation if there's time left.
> 
> > 
> > I'm not sure I understood everything right, sorry, but perhaps you can find
> > something useful in contrib/ci/run, contrib/ci/make-check-wrap and
> > contrib/ci/valgrind-condense where CI matches and handles particular tests
> > differently regardless of whether LOG_COMPILER is supported or not.  Ping me
> > if you need help figuring out what's going on there.
> 
> So more or less I wanted to have two tests and wanted to run the first
> as (simplified):
>     PAM_WRAPPER=1 ./src/tests/cwrap/pam_sss_wrapper-tests
> and other as:
>     PAM_WRAPPER=1 UID_WRAPPER=1 ./src/tests/cwrap/pam_sss_wrapper-root--tests
> 
> but it occured to me that I can always start with UID wrapper, just drop
> privileges if I need a strictly non-root test. It's a bit of a hack :-)
> but since the root is fake anyway, I think it's acceptable.
> 
> > 
> > Granted this is from outside the build, but maybe you can concoct something
> > from inside as well.
> 
> I think this might work as well; thank you!

I had a short look at libtool. Since we use it during 'make check' not
the actual binaries are called but a libtool generated wrapper script.
If it would be possible to set the environment variables here they would
be visible for the binary at startup.

Libtool has the concept of 'executable wrappers' to support cygwin and
similar environments but I didn't found an easy way to add own wrapper
here.

Adding the variables directly in the generated wrapper scripts would be
quite a hack. But maybe it would be possible if we add our own version
of build/ltmain.sh where the wrapper scripts are generated in
func_emit_wrapper()?

So, I'm afraid this is not a direct answer to your question but maybe
libtool might be useful here.

bye,
Sumit

> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel


More information about the sssd-devel mailing list