this patch is a hotfix for pam-srv-failing
Increasing the timeout to 30 seconds seems
to be enough. I do not want to make it too
big because the timeout is currently not
I'd like to talk to Sumit about what he thinks
the proper solution should be. I am not sure
if it times out because we do something
unnecessary in p11 child.
See the simple patch.
I might be in a strange and careless mood today, but here is something I
wanted to suggest since the time I saw the amount of logic that goes into SSSD
and is implemented in C.
What if we implement some of the complicated logic inside SSSD in Lua ?
Lua is a language specifically designed to be embedded. It grew into
popularity after it was embedded into World Of Warcraft. It was also embedded
and is still being embedded into a bunch of other games. However, games is far
from the only application for Lua.
Lua is a simple and lightweight language, yet with lots of flexibility -
grasping the essence of the whole reference manual  takes one evening and
it's an entertaining read. The VM is small and fast. In fact some people use
it on microcontrollers .
I personally embedded it into two C-based projects, one of which was already
quite big, and another was a rewrite of a smallish, but complicated C project.
In both cases, where before things were tedious and hard, they have become
easy and fun. The first project was on an embedded platform. I also had some
other, but smaller stuff done with it.
Generally, Lua gets put into the middle with outside interfaces and
performance-critical parts implemented in C. With a very simple interface to
and from C one can put boundaries wherever necessary. Yes, the interface is
simpler than Python's.
The process is this: you implement some C libraries (shared/static) which are
loadable from Lua (Lua->C interface) and then create a VM or several, load
some Lua code and call into it (C->Lua interface).
Some of the benefits are:
Clearer logic (higher level language)
Much less memory leaks and very little memory management (mostly in Lua->C
Faster development cycle (no compilation, edit and retry on a live daemon)
Potentially easy plugin interface (yay for admin scripts!)
Some of the drawbacks are:
More difficult to do low level stuff (so we just don't do that)
Lower performance than C (still good enough for games, and we can have the
critical parts in C easily)
Needs learning and development investment.
Regarding the development investment, due to low cost of C/Lua interface
implementation, it is practical to replace the relevant C code piece-by-piece,
provided pieces are not too small (say, 2KLOC and up).
Lastly, don't take this too seriously. I realise that this is disruptive and
hard. However if you ever feel like SSSD has grown too big and complex, ping
me, or just try Lua yourself :)
the attached patches fix #2742. The first one makes sure we can print
the certificate (or any binary attribute, really) safely. We only need
to make sure to escape the attribute values before saving them to sysdb,
because then ldb guarantees terminating them.
The second just switches the attribute value. I tested using this howto:
You'll also want to use a recent enough IPA version, one that fixes:
Then, on the client, call:
dbus-send --print-reply \
string:"$( openssl x509 < cert.pem )"
The result will be an object path.
Hi, it should work... :-) However, I wanted to make import as
transaction so no changes are made if some error occurs, but I had some
troubles with it so I gave up eventually.
Of course, it would be quite difficult to make it safe across domains
thus my intention was only to ensure that either all changes are done in
a domain or none. But still leaving the possibility that changes are
commited in one domain but cancelled in another.
I tried to start sysdb transaction on all used domains and then
commit/cancel it, writing some neat mechanism for it. However, I
occasionally run into a problem when data provider hangs when trying to
safe a user. It looked like some sort of race condition.
Unfortunately I managed to delete the code so I can't show it to you, I
think it would be a nice feature so if anyone familiar with ldb want to
step in, he's welcome.
As you can see in ticket #2748, there are some failures in test_memory_cache.
I was not bale to reproduce on my local machine and I didn't saw it before
because of other broken tests responder_cache_req-tests, pam-srv-tests.
I'm waiting from results from CI whether it will fail enev with attached patch.
there is a patchset that adds sss_unique_file with an optional
Attached are patches that use the function instead of mkstemp(). As you
can see in the patches, we already fix some bugs this way, especially
removing the tmpfiles left behind on error. In some cases, I also added
closing the fd on error.
please see 2 simple patches attached.
I could not find function to sanitize DN so it could be used as part of
filter (sanitize ()*/\...) so I had to write one.
sysdb_dn_sanitize is not the right choice,