I'm not sure wehter "compatible" is the best
explanation.
I think that "continue with the default" would suit better.
BTW: man setlocale(3) says:
On startup of the main program, the portable "C" locale is selected as
default. A program may be made portable to all locales by calling:
setlocale(LC_ALL, "");
Would you also mind to write integration test?
I can test on command line with:
[root@host ~]# LC_ALL="adasd" sss_cache -E
Error setting the locale
[root@host ~]# echo $?
5
LS

Thank you Lukas!
I added the integration test for this. I added
new file for tests that require LOCAL domain
only (no LDAP). I plan to add more tests here
later.
As we already discussed offline. I temporarily
worked around the issue with failing memcache
test by not removing the memcache files.
Nick asked me to provide some explanation on the
issue so I put it here, please correct me if I
say something wrong.
The problem seems to be that the nss client code only
checks validity of the memcache when the
memcache context is created. Long living
application only check the validity once and
then use file descriptor to manipulate the
cache until they are finished. Pytest is
one such application. If we use the python
pwd and grp wrappers, we initialize memcache
context in Pytest. If we later remove
the memcache files as part of teardown
and create new memcache files for new
tests, Pytest still uses the old file descriptors
so calls to pwd and grp wrappers will
work with the deleted memcache files.
See the attached patches.
Thanks!
Michal

Do we rely need to add debug messge to this file?
man setlocale says:
On startup of the main program, the portable "C" locale is selected as
default. A program may be made portable to all locales by calling:
setlocale(LC_ALL, "");
It does not say anything about checking return value after startup of the main
program. If you really want to print debug message then change debug level.
If we ignore such error then it is not aminor failure.

A) there is a git warning
/dev/shm/sssd/.git/rebase-apply/patch:13: space before tab in indent.
--without-semanage \
warning: 1 line adds whitespace errors.
B)
Why does it need to be in separate patch?
and the statement in commit message is not true:
"For now the libsemanage can not be used inside intgcheck tests"
We are able to run intgcheck after applying first two patches.

B)
Why does it need to be in separate patch?
and the statement in commit message is not true:
"For now the libsemanage can not be used inside intgcheck tests"
We are able to run intgcheck after applying first two patches.

The statement in the commit message is true, we can not
use libsemanage in the CI. The libsemanage functions
always fail in CI. The reason why we can run intgcheck
is because so far we have no tests, that would trigger
code path with libsemanage functions. But I am adding
such test in the next patch. If you prefer, I can
squash the two patches, but I do believe it should be
in separate patch, because it is change on its own
that may be reverted in the future and it is not
related to the purpose of the next patch.

Thank you.
It depends on how do we want to solve ticket
https://fedorahosted.org/sssd/ticket/1372. If we will change it globally then
we can. But on the other hand it might be good to inform user that messages
will not be localized. So you must decide yourself :-)

>
>>From 2b15daa0871ac7f3abadbeb33f115146c5cd1859 Mon Sep 17 00:00:00 2001
>>From: =?UTF-8?q?Michal=20=C5=BDidek?= <mzidek(a)redhat.com&gt;
>>Date: Tue, 20 Oct 2015 18:18:01 +0200
>>Subject: [PATCH 3/4] tests: Run intgcheck without libsemanage
>>
>>For now the libsemanage can not be used inside
>>intgcheck tests.
>>---
>>Makefile.am | 1 +
>>1 file changed, 1 insertion(+)
>>
>>diff --git a/Makefile.am b/Makefile.am
>>index 15d99ce..77a325a 100644
>>--- a/Makefile.am
>>+++ b/Makefile.am
>>@@ -2647,6 +2647,7 @@ intgcheck:
>> --prefix="$$prefix" \
>> --with-ldb-lib-dir="$$prefix"/lib/ldb \
>> --enable-intgcheck-reqs \
>>+ --without-semanage \
>> $(INTGCHECK_CONFIGURE_FLAGS); \
>> $(MAKE) $(AM_MAKEFLAGS); \
>> : Force single-thread install to workaround concurrency issues; \
>>--
>
>A) there is a git warning
>/dev/shm/sssd/.git/rebase-apply/patch:13: space before tab in indent.
> --without-semanage \
> warning: 1 line adds whitespace errors.
Fixed.
>
>B)
>Why does it need to be in separate patch?
>and the statement in commit message is not true:
>"For now the libsemanage can not be used inside intgcheck tests"
>We are able to run intgcheck after applying first two patches.
The statement in the commit message is true, we can not
use libsemanage in the CI. The libsemanage functions
always fail in CI. The reason why we can run intgcheck
is because so far we have no tests, that would trigger
code path with libsemanage functions. But I am adding
such test in the next patch. If you prefer, I can
squash the two patches, but I do believe it should be
in separate patch, because it is change on its own
that may be reverted in the future and it is not
related to the purpose of the next patch.

The main problem is that after few weeks you might not remeber
why this line was added. The commit message does not have enought details
about problems with libsemanage. Which test is affected by this isssue,
We do not know when this "workaround" might be reverted ...
Usually, one-liner should be explain much more then big patch.
because it's not obvius from a patch why we need it.
BTW At least tracking ticket for this issue should be mentioned in commit
message.
LS

>>
>> >From 2b15daa0871ac7f3abadbeb33f115146c5cd1859 Mon Sep 17 00:00:00 2001
>>> From: =?UTF-8?q?Michal=20=C5=BDidek?= <mzidek(a)redhat.com&gt;
>>> Date: Tue, 20 Oct 2015 18:18:01 +0200
>>> Subject: [PATCH 3/4] tests: Run intgcheck without libsemanage
>>>
>>> For now the libsemanage can not be used inside
>>> intgcheck tests.
>>> ---
>>> Makefile.am | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/Makefile.am b/Makefile.am
>>> index 15d99ce..77a325a 100644
>>> --- a/Makefile.am
>>> +++ b/Makefile.am
>>> @@ -2647,6 +2647,7 @@ intgcheck:
>>> --prefix="$$prefix" \
>>> --with-ldb-lib-dir="$$prefix"/lib/ldb \
>>> --enable-intgcheck-reqs \
>>> + --without-semanage \
>>> $(INTGCHECK_CONFIGURE_FLAGS); \
>>> $(MAKE) $(AM_MAKEFLAGS); \
>>> : Force single-thread install to workaround concurrency issues; \
>>> --
>>
>> A) there is a git warning
>> /dev/shm/sssd/.git/rebase-apply/patch:13: space before tab in indent.
>> --without-semanage \
>> warning: 1 line adds whitespace errors.
>
> Fixed.
>
>>
>> B)
>> Why does it need to be in separate patch?
>> and the statement in commit message is not true:
>> "For now the libsemanage can not be used inside intgcheck tests"
>> We are able to run intgcheck after applying first two patches.
>
> The statement in the commit message is true, we can not
> use libsemanage in the CI. The libsemanage functions
> always fail in CI. The reason why we can run intgcheck
> is because so far we have no tests, that would trigger
> code path with libsemanage functions. But I am adding
> such test in the next patch. If you prefer, I can
> squash the two patches, but I do believe it should be
> in separate patch, because it is change on its own
> that may be reverted in the future and it is not
> related to the purpose of the next patch.
>
The main problem is that after few weeks you might not remeber
why this line was added. The commit message does not have enought details
about problems with libsemanage. Which test is affected by this isssue,
We do not know when this "workaround" might be reverted ...
Usually, one-liner should be explain much more then big patch.
because it's not obvius from a patch why we need it.
BTW At least tracking ticket for this issue should be mentioned in commit
message.

Ok. I created a tracking ticket for it and added it to the
commit message. Not sure if we should deffer it or move to
some more distant milestone. We will probably not spend time
with it soon.

Nick asked me to provide some explanation on the
issue so I put it here, please correct me if I
say something wrong.
The problem seems to be that the nss client code only
checks validity of the memcache when the
memcache context is created. Long living
application only check the validity once and
then use file descriptor to manipulate the
cache until they are finished. Pytest is
one such application. If we use the python
pwd and grp wrappers, we initialize memcache
context in Pytest. If we later remove
the memcache files as part of teardown
and create new memcache files for new
tests, Pytest still uses the old file descriptors
so calls to pwd and grp wrappers will
work with the deleted memcache files.

Thanks, Michal!
However, how come there is a difference when the test has/doesn't have the
LDAP enumeration before clearing the cache?
See the last message in "intg: Add more LDAP tests" thread.
Nick
P.S. I tried not removing the cache file and it doesn't seem to help much -
now it passes sometimes, but still fails most of the time. You can try
the test in the message mentioned above. This is the addition I made for
keeping the cache:
diff --git a/src/tests/intg/ldap_test.py b/src/tests/intg/ldap_test.py
index cdd8c8d..86d0854 100644
--- a/src/tests/intg/ldap_test.py
+++ b/src/tests/intg/ldap_test.py
@@ -30,6 +30,7 @@ import ldap
import pytest
import ds_openldap
import ldap_ent
+import re
from util import *
LDAP_BASE_DN = "dc=example,dc=com"
@@ -191,7 +192,8 @@ def cleanup_sssd_process():
pass
subprocess.call(["sss_cache", "-E"])
for path in os.listdir(config.DB_PATH):
- os.unlink(config.DB_PATH + "/" + path)
+ if re.match("^cache_.*\\.ldb$", path) is None:
+ os.unlink(config.DB_PATH + "/" + path)
for path in os.listdir(config.MCACHE_PATH):
os.unlink(config.MCACHE_PATH + "/" + path)

On 10/21/2015 07:28 PM, Michal Židek wrote:
> Nick asked me to provide some explanation on the
> issue so I put it here, please correct me if I
> say something wrong.
>
> The problem seems to be that the nss client code only
> checks validity of the memcache when the
> memcache context is created. Long living
> application only check the validity once and
> then use file descriptor to manipulate the
> cache until they are finished. Pytest is
> one such application. If we use the python
> pwd and grp wrappers, we initialize memcache
> context in Pytest. If we later remove
> the memcache files as part of teardown
> and create new memcache files for new
> tests, Pytest still uses the old file descriptors
> so calls to pwd and grp wrappers will
> work with the deleted memcache files.
Thanks, Michal!
However, how come there is a difference when the test has/doesn't have the
LDAP enumeration before clearing the cache?
See the last message in "intg: Add more LDAP tests" thread.
Nick
P.S. I tried not removing the cache file and it doesn't seem to help much -
now it passes sometimes, but still fails most of the time. You can
try
the test in the message mentioned above. This is the addition I
made for
keeping the cache:
diff --git a/src/tests/intg/ldap_test.py b/src/tests/intg/ldap_test.py
index cdd8c8d..86d0854 100644
--- a/src/tests/intg/ldap_test.py
+++ b/src/tests/intg/ldap_test.py
@@ -30,6 +30,7 @@ import ldap
import pytest
import ds_openldap
import ldap_ent
+import re
from util import *
LDAP_BASE_DN = "dc=example,dc=com"
@@ -191,7 +192,8 @@ def cleanup_sssd_process():
pass
subprocess.call(["sss_cache", "-E"])
for path in os.listdir(config.DB_PATH):
- os.unlink(config.DB_PATH + "/" + path)
+ if re.match("^cache_.*\\.ldb$", path) is None:
+ os.unlink(config.DB_PATH + "/" + path)
for path in os.listdir(config.MCACHE_PATH):
os.unlink(config.MCACHE_PATH + "/" + path)

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is the one :)
Hi Nick!
Not the sysdb cache. You need to keep the
memcache files (in config.MCACHE_PATH).
The sysdb cache can (and should be) deleted.
Michal