sssd-devel April 2014

sssd-devel@lists.fedorahosted.org

22 participants
87 discussions

[INI] Ding-libs, controversial points in the design to allow merging configuration snippets
by Dmitri Pal 15 Apr '14

15 Apr '14

Hello, This is the continuation of the discussion of the following design page: https://fedorahosted.org/sssd/wiki/DesignDocs/ding-libs/INIConfigMerge I see three controversial items in this design based on the previous discussion: a) Merging values This horse has been beaten in the other thread. The answer is simple. If we can make SSSD to make a change to not use lists or domains or providers as Simo suggest we can remove this consideration from the merge design. If we can't then we need to make it optionally available in the merge logic. To make a final decision here we need Jakub's input on how hard it is to implement Simo's idea. c) Snippets in a directory vs. snippets in a subdirectory per application. The design is built around the fact that it is better to put snippets into different subdirectories per source/application that updated them so that we can make sure that different sources of config info do not step on each other. We also can jail the config files with SELinux and allow different access to different subdirectories. This is a deviation from the current approaches where all snippets are supposed to go into a single directory. IMO this is quite limiting and I see an opportunity to change it for better. However if people agree with Simo that this is too over engineered and complicated I can understand. It is in fact more complex. So chime in. If you think single directory is good enough so be it. d) .merge files I do not like them either. If we: a) Can avoid value merges b) Will require each snippet to have a section header ( the problem is really the fact that INI automatically generates one called "default" if there is none so it is hard to say whether the parse filled the blank or the snippet section really is called "[default]"). I think I can work around it but it would require a change that I wanted to avoid with the design. c) Do not allow overwrites we can drop the .merge files. They are needed to support any of the three use cases above. I am mostly concerned about the last one because allowing overwrites on per section basis was something was requested in one of the RFEs. However here is how we can work around this because IMO it is a corner case. - The merge code will read snippets from a single directory. - It will inspect the name. If the name is <xxx>.over.conf then it will treat this file as the snippet that the author of the snippet wants to use to overwrite sections in the original config file. If the name of the file is <yyyy>.conf it will user it to do additive merge. If file has any other extension it will be ignored. Common rules about snippets: - Snippets must have a section defined - absence will cause an error and snippet will be ignored - Snippets can't have the same section defined in more than one .conf file. If same name is detected it will be treated as a collision and all snippets will be ignored Additional rules about <xxx>.over.conf: - Snippets of this kind will be applied only on top of the core config file and only if the application is running in the mode that allows such overwrite. - The overwrite will be done on the section by section basis, i.e. no merging of the values between the two sections (though merge logic supports this too) - If there is more than one section in the file then each section will be processed according to these rules If we go with something like this we can avoid .merge files and rely on the naming convention. Is this acceptable? I though not, this is why I invented .merge files but if we think this way is better I am fine with it. Next week I am traveling, I will have some time to do prototyping while I am flying so I want to get to consensus before the end of the week. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc.

4 12

Use a shorter retry timeout for failed SRV
by Pavel Reichl 14 Apr '14

14 Apr '14

Hello, please see attached patch. While testing this patch I have noticed a little asymmetry: While SSSD being offline I added SRV record so resolving could success: Call of 'getent passwd user@ad-domain ' results in 'Cannot proceed, provider is offline'. but calling 'getent passwd user' will try to resolve services and ends up online (then previous call will obviously succeed too). Pavel Reichl

2 7

Announcing SSSD 1.11.5.1
by Jakub Hrozek 14 Apr '14

14 Apr '14

=== SSSD 1.11.5.1 === The SSSD team is proud to announce the release of version 1.11.5.1 of the System Security Services Daemon. As always, the source is available from https://fedorahosted.org/sssd RPM packages will be made available for Fedora 19, 20 and rawhide shortly. == Feedback == Please provide comments, bugs and other feedback via the sssd-devel or sssd-users mailing lists: https://lists.fedorahosted.org/mailman/listinfo/sssd-devel https://lists.fedorahosted.org/mailman/listinfo/sssd-users == Highlights == * Fixes an issue producing the systemd unit file while building from the tarball. * Fixes a regression that caused a segfault when connecting to a Samba 4 domain controller. == Tickets Fixed == https://fedorahosted.org/sssd/ticket/2311 sssd crashes after upgrade from 1.11.4 to 1.11.5 when using a samba4 domain https://fedorahosted.org/sssd/ticket/2314 sssd-1.11.5-1.fc20 has wrong systmd service file == Detailed Changelog == Jakub Hrozek (3): * Updating the version for the 1.11.6 release * Setting the version to 1.11.5.1 for the release * Updating the translations for the 1.11.5.1 release Lukas Slebodnik (1): * AUTOMAKE: Do not include makefile generated files into tarball Stephen Gallagher (1): * AD Provider: Fix crash looking up forest on Samba 4

2 4

[PATCH] AUTOMAKE: Do not include makefile generated files into
by Lukas Slebodnik 11 Apr '14

11 Apr '14

ehlo, patches for master and 1-11 branchare attached. Resolves: https://fedorahosted.org/sssd/ticket/2314 how to test: #generate tarball with "make distcheck" #move tarball to another directory #extract tarball #change dir to sssd-$(VERSION) ./configure --with-initscript=systemd --prefix=/usr make # look into generated file src/sysv/systemd/sssd.service ./configure --with-initscript=systemd --prefix=/usr --exec-prefix=/usr/local # do not run make clean make # look into generated file src/sysv/systemd/sssd.service # it should be changed LS

2 10

success with 1.11.5 on openSUSE
by steve 10 Apr '14

10 Apr '14

Builds fine on openSUSE 13.1 and all working with AD. Thanks to all for the effort. Steve

2 2

[PATCH] AD Provider: Fix crash looking up forest on Samba 4
by Stephen Gallagher 10 Apr '14

10 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We were assuming that the forest had been looked up by netlogon, but this is not available on Samba 4 domains. We need to check that the forest is NULL and force the lookup. Resolves: https://fedorahosted.org/sssd/ticket/2311 This is a regression in 1.11.5 when interacting with Samba 4 domain controllers. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNFwN0ACgkQeiVVYja6o6PEMQCfYIh/y9GWl0XGdnXPDyyR7ABQ nDQAniz4a7bYy77ZcG2OrMRoVH58rZ85 =EvTA -----END PGP SIGNATURE-----

3 3

[PATCH] tests: Don't set the check fork mode explicitly
by Jakub Hrozek 10 Apr '14

10 Apr '14

A small fix for the sbus unit tests in master.

2 2

having trouble linking with libsamba-security (but only sometimes)
by Yassir Elley 09 Apr '14

09 Apr '14

Hi all, I have been using a samba function (string_to_sid) in my gpo code and have had no trouble so far compiling and linking my libsss_ad.so gpo code. I simply needed to apply the following patches, which includes having to declare the string_to_sid function before it is used in the file. --- /dev/null +++ b/src/providers/ad/ad_gpo.c @@ @@ + + bool string_to_sid(struct dom_sid *sidout, const char *sidstr); + --- a/Makefile.am +++ b/Makefile.am @@ @@ libsss_ad_la_SOURCES = \ src/providers/ad/ad_access.h \ + src/providers/ad/ad_gpo.c \ + src/providers/ad/ad_gpo.h \ src/providers/ad/ad_opts.h \ However, now that I'm creating a gpo unit test (using the same string_to_sid function), the linker fails with the following message: /usr/bin/ld: src/tests/cmocka/ad_gpo_tests-test_ad_gpo.o: undefined reference to symbol 'string_to_sid@@SAMBA_4.1.5' /usr/bin/ld: note: 'string_to_sid@@SAMBA_4.1.5' is defined in DSO /usr/lib64/samba/libsamba-security.so so try adding it to the linker command line /usr/lib64/samba/libsamba-security.so: could not read symbols: Invalid operation I applied the following patches to get ad_gpo_test.c, which allowed me to compile successfully, but the link failed with the above message. --- a/Makefile.am +++ b/Makefile.am @@ @@ if HAVE_CMOCKA ad_access_filter_tests \ + ad_gpo_tests \ ad_common_tests \ @@ @@ ad_access_filter_tests_LDADD = \ +ad_gpo_tests_SOURCES = \ + $(sssd_be_SOURCES) \ + src/util/sss_ldap.c \ + src/util/sss_krb5.c \ + src/util/find_uid.c \ + src/util/user_info_msg.c \ + src/providers/ad/ad_common.c \ + src/tests/cmocka/test_ad_gpo.c +ad_gpo_tests_CFLAGS = \ + $(AM_CFLAGS) \ + $(SYSTEMD_LOGIN_CFLAGS) \ + $(NDR_NBT_CFLAGS) \ + -DUNIT_TESTING +ad_gpo_tests_LDADD = \ + $(PAM_LIBS) \ + $(CMOCKA_LIBS) \ + $(SSSD_LIBS) \ + $(CARES_LIBS) \ + $(KRB5_LIBS) \ + $(SSSD_INTERNAL_LTLIBS) \ + $(SYSTEMD_LOGIN_LIBS) \ + $(NDR_NBT_LIBS) \ + libsss_ldap_common.la \ + libsss_idmap.la \ + libsss_krb5_common.la \ + libsss_ad.la \ + libsss_test_common.la + ad_common_tests_SOURCES = \ If I apply the following patch, I am able to compile and link successfully!!: --- a/Makefile.am +++ b/Makefile.am @@ -1625,7 +1625,10 @@ ad_gpo_tests_CFLAGS = \ $(SYSTEMD_LOGIN_CFLAGS) \ $(NDR_NBT_CFLAGS) \ -DUNIT_TESTING +ad_gpo_tests_LDFLAGS = \ + -rpath $(libdir)/samba ad_gpo_tests_LDADD = \ + $(libdir)/samba/libsamba-security.so \ $(PAM_LIBS) \ $(CMOCKA_LIBS) \ I am confused by a few things: * Why do we need to explicitly add libsamba-security.so (and -rpath) to the linker line for the gpo tests, but not for libsss_ad.so * The patch that allows the gpo_tests to link/compile might not be portable b/c it assumes that libsamba-security.so is in $(libdir)/samba for all distributions. Is that a valid assumption? * One of the issues seems to be that the linker only looks in $(libdir) and $(libdir)/sssd, which is why adding the rpath works. Is this really the first time that we are using a library not in $(libdir) or $(libdir)/sssd. In other words, I would have expected this to have happened before (i.e. linking against a library not in the default locations). * Presumably, the libsss_ad.so gpo code links successfully because it is pulling in a library (which is internally pulling in libsamba-security), but I'm not sure which library that is. Any ideas? * Is there a better solution for getting the gpo tests to link? Thanks, Yassir.

7 8

SSSD ticket #2214
by Michal Židek 09 Apr '14

09 Apr '14

Hello, I was looking at https://fedorahosted.org/sssd/ticket/2214 I did not know about C being that paranoid with nested pointers to const data when passed as function arguments (I probably don't use const as often as I should, so I never bumped into this problem before). Good explanation on what the problem is can be found here: http://c-faq.com/ansi/constmismatch.html I have searched the web and read some materials on how to solve this issue, but could not find any elegant solution that would accept both 'char **' and 'const char **' without warnings (if you know about some way, please tell me). Than I tried to turn all the data that we pass as arguments 2 or 3 to these functions into 'const char**', but in many cases it is not possible and we would have to cast them to const. This spawns another warning during compilation: warning: to be safe all intermediate pointers in cast from 'char **' to 'const char **' must be 'const' qualified Which does not look good as well, so if nobody is against, I will close the ticket as 'wontfix'. Michal

5 6

[ding-libs] Patches for #2267, build issue and tight loop
by Dmitri Pal 08 Apr '14

08 Apr '14

Hello, The following patches address the request to be able to read config data from a memory buffer rather than a file. Ticket: https://fedorahosted.org/sssd/ticket/2267 It also addresses a build problem that I found on my system and fixes a tight loop in parsing when we ignore errors and file is empty. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/

5 28

← Newer
1
2
3
4
5
6
7
8
9
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel April 2014