[sssd PR#540][opened] Fix python3 issue in the integration test
by sumit-bose
URL: https://github.com/SSSD/sssd/pull/540
Author: sumit-bose
Title: #540: Fix python3 issue in the integration test
Action: opened
PR body:
"""
With this patch the integration tests can run with python3.
To test make sure $(PYTHON2) in src/tests/intg/Makefile.am is replaced with
$(PYHTON3). Additionally the required python3 modules like e.g. python3-pytest,
python3-pyldap or python3-ldb must st installed.
At startup pytest will print a status line like
platform linux -- Python 3.5.4, pytest-2.9.2, py-1.4.34, pluggy-0.3.1 -- /usr/bin/python3
where you can check if python3 is really used for testing.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/540/head:pr540
git checkout pr540
6 years
[sssd PR#542][opened] KCM: Use json_loadb() when dealing with sss_iobuf data
by fidencio
URL: https://github.com/SSSD/sssd/pull/542
Author: fidencio
Title: #542: KCM: Use json_loadb() when dealing with sss_iobuf data
Action: opened
PR body:
"""
As sss_iobuf data is *non* NULL terminated, we have to use json_loadb()
passing the data's length instead of just using json_loads().
Due to this issue, when running sssd-kcm under valgrind and performing a
`kinit foo` a bunch of erros like the following one could be seen:
==2638== Conditional jump or move depends on uninitialised value(s)
==2638== at 0x57DB678: stream_get.part.3 (load.c:172)
==2638== by 0x57DB9CA: stream_get (load.c:643)
==2638== by 0x57DB9CA: lex_get (load.c:246)
==2638== by 0x57DB9CA: lex_scan (load.c:601)
==2638== by 0x57DC56A: parse_json.constprop.7 (load.c:904)
==2638== by 0x57DC6AB: json_loads (load.c:959)
==2638== by 0x11ABEA: ??? (in /usr/libexec/sssd/sssd_kcm)
==2638== by 0x11AEF0: ??? (in /usr/libexec/sssd/sssd_kcm)
==2638== by 0x125D4A: ??? (in /usr/libexec/sssd/sssd_kcm)
==2638== by 0x12623B: ??? (in /usr/libexec/sssd/sssd_kcm)
==2638== by 0x9BCD71F: epoll_event_loop (tevent_epoll.c:728)
==2638== by 0x9BCD71F: epoll_event_loop_once (tevent_epoll.c:930)
==2638== by 0x9BCBBA6: std_event_loop_once (tevent_standard.c:114)
==2638== by 0x9BC7FEC: _tevent_loop_once (tevent.c:725)
==2638== by 0x9BC820A: tevent_common_loop_wait (tevent.c:848)
Resolves:
https://pagure.io/SSSD/sssd/issue/3687
Signed-off-by: Fabiano Fidêncio <fidencio(a)redhat.com>
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/542/head:pr542
git checkout pr542
6 years
Allowing local ssh login when using sssd
by Richard Sharpe
Hi folks,
It seems that once we are joined to a domain, ssh logins with local
accounts no longer work. When we unjoin from the domain, they start
working again.
When not joined to a domain our sssd.conf file looks like this:
[sssd]
services = nss, pac
domains =
config_file_version = 2
When joined to a domain, our sssd.conf file looks like this:
[sssd]
services = nss, pac
domains = win.ad.test
config_file_version = 2
[domain/win.ad.test]
ad_domain = win.ad.test
krb5_realm = WIN.AD.TEST
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
default_shell = /bin/bash
ldap_sasl_authid = PD00050568C6FE8$
ldap_id_mapping = False
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = ad
ad_hostname = PD00050568C6FE8.win.ad.test
dyndns_update = False
ldap_schema = rfc2307bis
-------------------------------
Does anyone have any ideas on how to allow local ssh logins when
joined to a domain?
--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)
6 years, 1 month
KCM talking to secrets over REST API (or not)
by Jakub Hrozek
Hi,
last week, me, some other SSSD developers and Robbie looked at how the KCM server in its current state can be debugged and what the current issues are. One thing that stood out was that because every Kerberos operation now requires a round-trip between libkrb5 to sssd-kcm and then to sssd-secrets via the REST API, there are several components involved which makes the setup brittle. In addition, the marshalling of each request into JSON and sending it over the sssd-secrets REST API adds a bit of an overhead.
In a follow-up e-mail thread, Simo suggested that instead of using the REST API, sssd-kcm might access the sssd-secrets database directly. I wanted to discuss this potential change with the other developers.
As I’ve been thinking about Simo’s proposal, it actually makes sense to me. The pros and cons as I see them are:
[+] less complexity. We would get rid of the whole JSON marshalling code and wouldn’t have to allow on a second socket-activated deamon.
[+] better performance. Again, no JSON marshalling, but in the past we were working around the REST API not providing a PATCH verb, so KCM had to serialize requests to make sure two concurrent PUT requests don’t step over one another.
[+] the “proprietary” API between KCM and secrets could be augmented more easily to allow e.g. introspection and quota management better.
We wanted to allow some form of introspection and if we confine ourselves to the REST API, I can’t think of another way of answering “how much of their quota is UID X using" except adding a KCM-specific REST API endpoint anyway.
[-] we would have to define a private API between secrets and KCM. The REST API already has a nice router (or multiplexer if you will) to route the different HTTP verbs into internal sssd-secrets actions, e.g HTTP GET into retrieving a secret.
[-] overall allowing to write to the secrets database via the REST API seems somewhat cleaner
Are there other opinions on the matter? Should we go ahead and change the design to write to the database directly?
6 years, 1 month
New sbus implementation
by Pavel Březina
Hi team,
as you know, I have been working on this occasionally for a long time
now. The code can be found at [1].
It is completely new implementation of our internal D-Bus API called
sbus. I took all the good things started by Steff Walter few years ago
and made them better and more flexible. In short, it is everything you
ever wanted and you will not use D-Bus with it at all.
There is a large README.md in the repo, that contains complete list of
features, explanation why I started working on this and what I wanted to
achieve. There is also shorter list of some chosen benefits to the SSSD
project so you can get the general idea without going through the all
feature list.
I really believe that this will be a big step forward for SSSD project
as it will make the code much simpler and testable and it will allow us
to extend our D-Bus interface both external and internal. It will give
us the opportunity to improve the InfoPipe responder (and finally allow
us to implement write interface) but it also allows us to improve the
communications between providers, responders and even tools --
especially sssctl.
There is also a showcase application so you can see most of the features
at work. All is described in the readme file.
It lacks unit tests at the moment. I would like to get some help from
you in this area, we should talk about it in the meeting or here. If we
choose to integrate this with our codebase, we should talk about
schedule and test plan.
Also, I would like to strip it from SSSD's dependencies eventually and
release it as a public library. But that will not happen in near future.
I hope you will like it.
Pavel.
[1] https://github.com/pbrezina/sbus
6 years, 1 month
[sssd PR#534][opened] test_ca: add empty index.txt.attr file
by sumit-bose
URL: https://github.com/SSSD/sssd/pull/534
Author: sumit-bose
Title: #534: test_ca: add empty index.txt.attr file
Action: opened
PR body:
"""
Although is does not harm because 'openssl ca' creates the
index.tx.tattr file with a suitable content automatically this patch
adds the file to the test_CA directory to silence a message like:
Can't open ./index.txt.attr for reading, No such file or directory
139867607979840:error:02001002:system library:fopen:No such file or
directory:crypto/bio/bss_file.c:74:fopen('./index.txt.attr','r')
139867607979840:error:2006D080:BIO routines:BIO_new_file:no such
file:crypto/bio/bss_file.c:81:
which is show by recent versions of OpenSSL.
Related to https://pagure.io/SSSD/sssd/issue/3436
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/534/head:pr534
git checkout pr534
6 years, 1 month