sssd-devel September 2016

sssd-devel@lists.fedorahosted.org

18 participants
95 discussions

[sssd PR#11] SECRETS: Don't remove a container when it has children (edited)
by fidencio 01 Sep '16

01 Sep '16

fidencio's pull request #11: "SECRETS: Don't remove a container when it has children" was edited See the full pull-request at https://github.com/SSSD/sssd/pull/11 ... or pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/11/head:pr11 git checkout pr11

1 0

[sssd PR#11] SECRETS: Don't remove a container when it has children (synchronize)
by fidencio 01 Sep '16

01 Sep '16

fidencio's pull request #11: "SECRETS: Don't remove a container when it has children" was synchronize See the full pull-request at https://github.com/SSSD/sssd/pull/11 ... or pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/11/head:pr11 git checkout pr11

1 0

[sssd PR#10] UTIL: Remove support to libini older than 1.0.0 (comment)
by fidencio 01 Sep '16

01 Sep '16

lslebodn commented on a pull request """ On (01/09/16 08:35), fidencio wrote: >On Thu, Sep 1, 2016 at 2:10 PM, lslebodn <notifications(a)github.com> wrote: > >> On (01/09/16 04:32), Jakub Hrozek wrote: >> >On Thu, Sep 01, 2016 at 03:21:06AM -0700, fidencio wrote: >> >> On Thu, Sep 1, 2016 at 11:54 AM, lslebodn <notifications(a)github.com> >> wrote: >> >> > >> >> > On (31/08/16 23:18), fidencio wrote: >> >> > >libini 1.0.0 is part of ding-libs 0.3.0 and has been around since >> 2013. >> >> > >Even the old systems that we have to support already have a newer >> >> > >version of the library. RHEL6, for instance, has ding-libs 0.4.0 >> which >> >> > >provides libinit 1.1.0. >> >> > > >> >> > >By removing this code we also can stop depending on libcollection. >> >> > > >> >> > >Signed-off-by: Fabiano Fidêncio <fidencio(a)redhat.com> >> >> > >You can view, comment on, or merge this pull request online at: >> >> > > >> >> > > https://github.com/SSSD/sssd/pull/10 >> >> > > >> >> > >-- Commit Summary -- >> >> > > >> >> > > * UTIL: Remove support to libini older than 1.0.0 >> >> > > >> >> > >-- File Changes -- >> >> > > >> >> > > M configure.ac (1) >> >> > > M contrib/ci/deps.sh (1) >> >> > > M contrib/sssd.spec.in (1) >> >> > > D src/external/libcollection.m4 (9) >> >> > > M src/util/sss_ini.c (97) >> >> > > >> >> > >-- Patch Links -- >> >> > > >> >> > >https://github.com/SSSD/sssd/pull/10.patch >> >> > >https://github.com/SSSD/sssd/pull/10.diff >> >> > > >> >> > OpenSUSE LEAP has just ding-libs 0.3.0.1 in official repositories. >> >> > http://software.opensuse.org/package/ding-libs?search_term=ding-libs >> >> >> >> Yep. OpenSUSE LEAP has 0.3.0.1, Debian Stable (Jessie) has 0.4.0, >> >> latest Ubuntu LTS has 0.5.0. >> >> And all of them would be able to build SSSD with my patch without any >> issues. >> > >> >Two questions: >> > 1) how long until the distributions with too old ding-libs go out of >> > support? >> > >Hmm. Unfortunately I don't have an answer for you. >What are the major distributions that we want to support? Debian, Ubuntu >LTS, RHEL, SLES ...? > I would prefer if limited version of sssd (ldap + krb5 provider) could be compiled almost anywhere. (even old distributions) It is not only about major distributions. > >> > 2) since we will be (likely) supporting sssd-1-13 for the lifetime >> > of RHEL-6, can we say that the old distributions just use sssd-1-13? >> > >> libini_config-1.0 does not provide any new functionality >> which is not in libini_config < 1.0 >> > >> They have just a different API (and moreover libini_config-1.0 >> still provides old API) (at least from sssd POV) >> > >There's no new functionality, true. But there's a quite good API >simplification I agree that API is better. But feature wise are the same. So if we wanted to drop support for libini_config < 1.0 then we could drop support for libini_config-1.0. It would simplify more things in sssd However, OpenSUSE LEAP has just a libini_config-1.0 >and we can stop depending on libcollection. > libini_config-devel depends on libcollection-devel :-) and it's a very tiny dependency. sh$ rpm -q --requires libini_config-devel /usr/bin/pkg-config libbasicobjects-devel = 0.1.1-29.fc25 libcollection-devel = 0.7.0-29.fc25 libini_config = 1.3.0-29.fc25 libini_config.so.5()(64bit) libref_array-devel = 0.1.5-29.fc25 pkgconfig(basicobjects) pkgconfig(collection) pkgconfig(ref_array) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 We would not reduce our dependency chain. LS """ See the full comment at https://github.com/SSSD/sssd/pull/10#issuecomment-244127101

1 0

[sssd PR#11] SECRETS: Don't remove a container when it has children (synchronize)
by fidencio 01 Sep '16

01 Sep '16

1 0

[RFC] Cleaning up the IFP responder (mainly) and socket-activatable responders
by Fabiano Fidêncio 01 Sep '16

01 Sep '16

Howdy! Taking a look on https://fedorahosted.org/sssd/ticket/2395 seems that there are a few ways to achieve what's proposed by Simo and I'd like to discuss one of those before start implementing it. As far as I understand the bug, SSSD cannot be run as a non-root user because of IFP responder, which needs to be run as root in order to write to sssd.conf file. Simo's suggestion was to create a new service, which should be socket-activated, to handle this writing to sssd.conf part and Jakub's suggested to completely get rid of this part. However, Dmitri pointed out that we must have some service playing with sssd.conf as it's the way that cockpit and ansible can remotely manage the SSSD configuration. Okay, in order to actually start solving the issue I'd like to propose the follow steps: 1) Create a new service, still explicitly enabled in sssd.conf, that would take care of the managing the SSSD configuration. 2) Get rid of the code dealing with the SSSD configuration from the IFP responder. 3) Get rid of the OpenLMI specific code from the IFP responder Till this point the problem wasn't solved at all, but those seem to be the logical steps in order to make our own lives easier for working in the next two steps. 4) Make the new service (created in 1) socket-activated/bus-activated. 5) Make the IFP responder also bus-activated/socket-activated. So, does it sound like a reasonable way to approach the problem? If yes, I'd like to ask a few questions, mainly about items 4 and 5, as it eems that in order to achieve what we want, https://fedorahosted.org/sssd/ticket/2243 and https://fedorahosted.org/sssd/ticket/3129 have to be solved together, which seems to be a not so small task. So, do we have to care about systems that don't have systemd support? IOW, do we have to keep the current code and also add socket-activation? If yes, would it be explicitly enabled/disabled on configure time? Maybe a lame question, but what are the advantages of the socket-activation over the bus-activation approach (I still didn't look at any of those :-\)? Thanks in advance, -- Fabiano Fidêncio

4 3

[sssd PR#9] SYSDB: Removing of unused parametr (opened)
by fidencio 01 Sep '16

01 Sep '16

celestian's pull request #9: "SYSDB: Removing of unused parametr" was opened PR body: """ There were unused parameter struct ldb_message *cached_group in sysdb_store_group_attrs(). This parameter was introduced by 40de79d69860ec7f04bf7795bd88b641ec42fd23 SYSDB: Check if group attributes differ before saving a group """ See the full pull-request at https://github.com/SSSD/sssd/pull/9 ... or pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/9/head:pr9 git checkout pr9

1 5

[sssd PR#7] Fix initgroups with nested groups (+pushed)
by fidencio 01 Sep '16

01 Sep '16

sumit-bose's pull request #7: "Fix initgroups with nested groups" label *pushed* has been added See the full pull-request at https://github.com/SSSD/sssd/pull/7

1 0

[sssd PR#8] MAN: Document the ldap_user_gid_number option (opened)
by fidencio 01 Sep '16

01 Sep '16

jhrozek's pull request #8: "MAN: Document the ldap_user_gid_number option" was opened PR body: """ Some users, mostly those who cannot join the Linux machines to their AD domain resort to using the LDAP provider with ID mapping. But in order for that to work correctly, the ldap_user_gid_number option must be set correctly, otherwise SSSD complains about not finding the primary GID: (Fri Aug 26 13:34:10 2016) [sssd[be[dev]]] [sdap_save_user] (0x0020): Cannot get the GID for [someuser] in domain [extdev]. """ See the full pull-request at https://github.com/SSSD/sssd/pull/8 ... or pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/8/head:pr8 git checkout pr8

1 5

[sssd PR#7] Fix initgroups with nested groups (closed)
by fidencio 01 Sep '16

01 Sep '16

sumit-bose's pull request #7: "Fix initgroups with nested groups" was closed See the full pull-request at https://github.com/SSSD/sssd/pull/7 ... or pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/7/head:pr7 git checkout pr7

1 0

[sssd PR#7] Fix initgroups with nested groups (comment)
by fidencio 01 Sep '16

01 Sep '16

jhrozek commented on a pull request """ * master: 5bd3bef4a655fdfacd2f5df8a2343fe7bc68a771 """ See the full comment at https://github.com/SSSD/sssd/pull/7#issuecomment-244058146

1 0

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel September 2016