attached simple patch is a result of "Fedora end of life"
message for related Fedora ticket.
If you have an idea about better names I will be glad to change them.
BTW shoulw we also remove this part from function
attached patch proposes solution for leaking memory when non-existing netgroup is looked up.
1st patch is just for testing - just call 'pkill -SIGUSR1 sssd_nss' and talloc report will be generated in /tmp/sssd_nss_talloc_report_full.
For details about the bug please see commit message in 2nd patch.
User who reported the bug confirmed that so far it seems that memory leak has been fixed and he didn't report any side effects.
please see simple test adding test for https://fedorahosted.org/sssd/ticket/2922.
Sumit proposed to test if mapping of UNIX MAX_ID + 1 fails to be mapped to SID.
Without patch for #2922 test fails otherwise test passes.
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.
This ticket is little bit related to #2855
I searched a little bit and here is a small sumary of
using autofs + atomic (containers)
>We have a pull request in RUNC to eliminate our patch.
>A second feature of this pull request would be to allow us to pass in
>the MOUNT_SHARED flag
>This would allow us to modify the hosts mount table from inside of a
>container. With this feature
>we would be able to run a service like autofs inside of a container but
>have it modify the HOST
>file system and those of other containers.
>I think if we want to get autofs to work on "atomic host" we need to run
>it in a container.
The attached patch will reduce dependency tree in such container.
I created patch with separate pacakge because "sss" is not by default
in nsswithc.conf for "automount". But this file could be part of sssd-client
but on the other hand automount directly dlopen libsss_autofs.so
I'm not sure which solution would be better.
I'm starting implementing tlog  configuration interfaces and would like
to know what you'd like to use best in SSSD.
Among tlog parameters are:
Path to the shell to start
The text for the warning about the session being recorded
Logging latency, seconds - how long to cache recorded data before logging
Maximum log message payload, bytes
Log target (file / syslog / perhaps journald later)
Log target options:
I guess out of these only a few would be controlled by SSSD.
I'd like to have three interfaces implemented:
Configuration file in /etc, in JSON (tlog needs it anyway)
Ideally, all the parameters should be controllable from any of them, but the
setting priority would be as above.
Our main use case for the start would require faking tlog as the shell in
nss_sss, passing the real shell in pam_sss via an environment variable and
letting the administrator configure the rest via the configuration file.
Command-line interface would be used to support "login" asking for login
shell, ssh doing the same and passing commands to execute, and testing.
Later we might want to add more parameters passed via pam_sss and environment
SSSD may also choose to write the tlog config file, but I think that it's
better to leave that for the administrators and only use environment
variable(s) from pam_sss instead.
Regarding that, I'm actually thinking about simply accepting the same data as
configuration file provides via an environment variable. I.e. in JSON. It
wouldn't need to be complete, and will be overlaid on top of what was read
from the configuration file. So for the start pam_sss would need to pass this,
Later it might grow into something like this:
"warning": "WARNING! Your session is being recorded!\n",
The above would require implementing JSON string escaping, but it's not
difficult and pretty much the same as C string escaping everyone's familiar
with (see http://json.org).
The alternatives are:
* Supplying all the possible options via separate environment variables.
That would require documenting them separately.
* Having an environment variable containing command-line options instead.
However, the latter would require handling word-splitting and unquoting
the same way shell does, and that's non-trivial without asking an actual
shell to do it. Whereas tlog already has a JSON parser.
So would the above be suitable for SSSD? Would pam_sss be OK with passing more
parameters, than just the shell to start? Do you have any other ideas,
objections? Please write!