[sssd PR#247][opened] Subdomain inherit
by mzidek-rh
URL: https://github.com/SSSD/sssd/pull/247
Author: mzidek-rh
Title: #247: Subdomain inherit
Action: opened
PR body:
"""
I tested if the options that work in subdomain inherit also work in trusted domain section in sssd.conf. Most seem to work without any changes in the code except for two. With these two patches only one that does not work remains (I wanted to send patchset that adds all the options, but I got stuck on the option that sets the ldap principal, so I am sending this in the meantime).
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/247/head:pr247
git checkout pr247
5 years, 11 months
[sssd PR#531][opened] Add the needed machinery to have automated builds for our COPR repos
by fidencio
URL: https://github.com/SSSD/sssd/pull/531
Author: fidencio
Title: #531: Add the needed machinery to have automated builds for our COPR repos
Action: opened
PR body:
"""
As the title says, these patches are introducing the needed machinery to have automated builds for our COPR repos.
The next steps are:
- On Pagure, someone who has admin rights will have to:
- Go to the project's web page: https://pagure.io/SSSD/sssd
- Click in the "Settings" button
- Go down to the "Hook" section
- Click in the "Fedmsg" field
- Check the "Active" checkbox
- Click in the "Update" button
- On COPR:
- Go to the each project's webpage:
- https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-13/
- https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-14/
- To be created
- https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-16/
- https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-master/
- Go to the "Packages" tab
- Click in "sssd" package
- In "Default Build Source" section, click in the "Edit" button
- In the SCM tab do:
- Type: Git
- Clone url: https://pagure.io/SSSD/sssd.git
- Committish: <branch name> (eg, master, sssd-1-13, sssd-1-14, ...)
- In the "How to build SRPM from the source" section, select:
- make srpm
- Click in the "Submit" button
After those steps, a new push would trigger a new copr build to the project.
The OSes that we're targeting are:
- el (all version, all arches)
- fedora (all versions, all arches)
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/531/head:pr531
git checkout pr531
5 years, 11 months
[sssd PR#464][opened] SYSDB: Properly handle name/gid override when using domain resolution order
by fidencio
URL: https://github.com/SSSD/sssd/pull/464
Author: fidencio
Title: #464: SYSDB: Properly handle name/gid override when using domain resolution order
Action: opened
PR body:
"""
When using name/gid override together with domain resolution order the
mpg name/gid may be returned instead of the overridden one.
In order to avoid that, let's add a check in case the domain supports
mpg so we can ensure that the originalADname and originalADgidNumber
attributes are the very same as the ones searched and then normally
proceed with the current flow in the code. In case those are not the
same, we *must* follow the code path for the non-mpg domains and then
return the proper values.
Resolves: https://pagure.io/SSSD/sssd/issue/3595
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/464/head:pr464
git checkout pr464
5 years, 11 months
[sssd PR#511][opened] Do not shutdown KCM/Secrets responders when activities are happening ...
by fidencio
URL: https://github.com/SSSD/sssd/pull/511
Author: fidencio
Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
Action: opened
PR body:
"""
Firstly, I'd like to make it **explicit** that this PR is **missing tests**, but I won't write them down till we have an agreement whether the proposed patches do look right/good.
Basically, while trying to reproduce https://pagure.io/SSSD/sssd/issue/3470 I've noticed that both secrets and kcm responders were going down due to the responder_idle_timeout expiring ... even with a lot of activities happening on them.
Does this approach look right? If yes, then, what would be the easiest way to test:
- A responder actually goes down after x seconds;
- Any activity on that responder will make the responder alive for more x seconds;
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/511/head:pr511
git checkout pr511
5 years, 11 months
[sssd PR#128][opened] Fix group renaming issue when "id_provider = ldap" is set
by fidencio
URL: https://github.com/SSSD/sssd/pull/128
Author: fidencio
Title: #128: Fix group renaming issue when "id_provider = ldap" is set
Action: opened
PR body:
"""
Those two patches fix https://bugzilla.redhat.com/show_bug.cgi?id=1401241
The sssd.conf used in order to reproduce this issue looks like:
```
[sssd]
config_file_version = 2
services = nss, pam
domains = ad.fidencio.lan
[nss]
[pam]
[domain/ad.fidencio.lan]
ad_domain = ad.fidencio.lan
krb5_realm = AD.FIDENCIO.LAN
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
ldap_referrals = false
enumerate = false
id_provider = ldap
#id_provider = ad
auth_provider = krb5
chpass_provider = krb5
access_provider = ldap
ldap_sasl_mech = GSSAPI
ldap_schema = ad
ldap_user_object_class = user
ldap_user_home_directory = unixHomeDirectory
ldap_user_principal = userPrincipalName
ldap_group_object_class = group
ldap_access_order = expire
ldap_account_expire_policy = ad
ldap_force_upper_case_realm = true
```
The reproducer can be found in the bug report.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/128/head:pr128
git checkout pr128
5 years, 12 months