[SSSD] [sssd PR#68][comment] MAN: Document different defaults for AD provider

[centos-ci]

  URL: https://github.com/SSSD/sssd/pull/68
Title: #68: MAN: Document different defaults for AD provider

centos-ci commented:
"""
Can one of the admins verify this patch?
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/68#issuecomment-256778568
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#68][comment] MAN: Document different defaults for AD provider

[centos-ci]

  URL: https://github.com/SSSD/sssd/pull/68
Title: #68: MAN: Document different defaults for AD provider

centos-ci commented:
"""
Can one of the admins verify this patch?
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/68#issuecomment-256778566
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#68][opened] MAN: Document different defaults for AD provider

[justin-stephenson]

   URL: https://github.com/SSSD/sssd/pull/68
Author: justin-stephenson
 Title: #68: MAN: Document different defaults for AD provider
Action: opened

PR body:
"""
Update man pages for any AD provider config options that differ from
ldap/krb5 provider back-end defaults.

Resolves:
https://fedorahosted.org/sssd/ticket/3214

I would appreciate any suggestions on improving the wording, I was hoping to be 
informative but concise.
"""

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/68/head:pr68
git checkout pr68
From 16ca7665d7efdf8d14bef7a128674fc934e5a7b7 Mon Sep 17 00:00:00 2001
From: Justin Stephenson 
Date: Thu, 27 Oct 2016 17:33:11 -0400
Subject: [PATCH] MAN: Document different defaults for AD provider

Update man pages for any AD provider config options that differ from
ldap/krb5 provider back-end defaults

Resolves:
https://fedorahosted.org/sssd/ticket/3214
---
 src/man/include/ad_modified_defaults.xml | 63 
 src/man/sssd-ad.5.xml| 19 +++---
 2 files changed, 77 insertions(+), 5 deletions(-)
 create mode 100644 src/man/include/ad_modified_defaults.xml

diff --git a/src/man/include/ad_modified_defaults.xml b/src/man/include/ad_modified_defaults.xml
new file mode 100644
index 000..c41b454
--- /dev/null
+++ b/src/man/include/ad_modified_defaults.xml
@@ -0,0 +1,63 @@
+
+MODIFIED DEFAULT OPTIONS
+
+Certain option defaults do not match their respective backend
+provider defaults, these option names and AD provider-specific
+defaults are listed below:
+
+
+KRB5 Provider
+
+
+
+krb5_validate = true
+
+
+
+
+krb5_use_enterprise_principal = true
+
+
+
+
+
+LDAP Provider
+
+
+
+ldap_schema = ad
+
+
+
+
+ldap_force_upper_case_realm = true
+
+
+
+
+ldap_id_mapping = true
+
+
+
+
+ldap_sasl_mech = gssapi
+
+
+
+
+ldap_referrals = false
+
+
+
+
+ldap_account_expire_policy = ad
+
+
+
+
+ldap_use_tokengroups = true
+
+
+
+
+
diff --git a/src/man/sssd-ad.5.xml b/src/man/sssd-ad.5.xml
index 8a2f4ad..8c29006 100644
--- a/src/man/sssd-ad.5.xml
+++ b/src/man/sssd-ad.5.xml
@@ -48,7 +48,7 @@
 addition servers from trusted domains are always auto-discovered.
 
 
-The AD provider accepts the same options used by the
+The AD provider enables SSSD to use the
 
 sssd-ldap
 5
@@ -56,12 +56,19 @@
 
 sssd-krb5
 5
- authentication provider with some exceptions described
-below.
+ authentication provider with optimizations for
+Active Directory environments. The AD provider accepts the same
+options used by the sssd-ldap and sssd-krb5 providers with some
+exceptions. However, it is neither necessary nor recommended to
+set these options.
 
 
-However, it is neither necessary nor recommended to set these
-options. The AD provider can also be used as an access, chpass,
+The AD provider primarily copies the traditional ldap and krb5
+provider default options with some exceptions, the differences
+are listed in the MODIFIED DEFAULT OPTIONS section.
+
+
+The AD provider can also be used as an access, chpass,
 sudo and autofs provider. No configuration of the access provider
 is required on the client side.
 
@@ -982,6 +989,8 @@ ad_gpo_map_deny = +my_pam_service
 
 
 
+http://www.w3.org/2001/XInclude; href="include/ad_modified_defaults.xml" />
+
 http://www.w3.org/2001/XInclude; href="include/failover.xml" />
 
 http://www.w3.org/2001/XInclude; href="include/service_discovery.xml" />
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#43][comment] RESPONDER: Enable sudoRule in case insen. domains​ (1.15)

[jhrozek]

  URL: https://github.com/SSSD/sssd/pull/43
Title: #43: RESPONDER: Enable sudoRule in case insen. domains​ (1.15)

jhrozek commented:
"""
On Thu, Oct 27, 2016 at 03:56:21AM -0700, Pavel Březina wrote:
> pbrezina requested changes on this pull request.
> 
> Hi, there is one indentation which can be simply fixed. Patches works so I 
> can ack them.
> 
> However, there is something that surprises me. If you set `case_sensitive = 
> preserving`, I would expect `sss_get_cased_name()` to return the original 
> format of the name. If this was true than you would have to also transform 
> `username` to lower in `sysdb_sudo_filter_userinfo()`. So before pushing 
> these patch: is this correct behaviour of `sss_get_cased_name()`?

I agree this should be checked, but if I remember correctly, at least
since 1.14 we should always use the lowercased name internally, but when
formatting the output name in the NSS responder we should use the
original case with a preserving domain.

"""

See the full comment at 
https://github.com/SSSD/sssd/pull/43#issuecomment-256685401
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#60][comment] Document ad_access_filter search for nested groups

[taupehat]

  URL: https://github.com/SSSD/sssd/pull/60
Title: #60: Document ad_access_filter search for nested groups

taupehat commented:
"""
@jhrozek I did not intend to remove anything from the last iteration. It's 
possible that I used the editor wrong. Do I need to delete the prior pull 
request and just create a new one with all changes in place?
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/60#issuecomment-256684610
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#65][comment] Fixing of nitpicks

[jhrozek]

  URL: https://github.com/SSSD/sssd/pull/65
Title: #65: Fixing of nitpicks

jhrozek commented:
"""
On Tue, Oct 25, 2016 at 09:28:27AM -0700, lslebodn wrote:
> lslebodn commented on this pull request.
> 
> 
> 
> > @@ -1104,7 +1104,6 @@ bool sss_krb5_realm_has_proxy(const char *realm)
>  
>  kerr = profile_get_values(profile, profile_path, );
>  if (kerr == PROF_NO_RELATION || kerr == PROF_NO_SECTION) {
> -kerr = 0;
>  goto done;
> 
> hmm,
> ```
> sh$ $git show cbf20090fa92cc9a6e31e3c903b21d020c519367
> tree cbf20090fa92cc9a6e31e3c903b21d020c519367

Sorry, I meant this one:
```
commit f0815f5dff315576c8d1b6fedf00165a4161f8c0
Author: Jakub Hrozek 
Date:   Fri Sep 4 10:30:03 2015 +0200

KRB5: Don't error out reading a minimal krb5.conf

With some setups, krb5.conf can be really minimal. In those cases, we
should ignore PROF_NO_RELATION and PROF_NO_SECTION and just return
"false" as in "no proxy" without a loud debug message.

Reviewed-by: Petr Cech 

diff --git a/src/util/sss_krb5.c b/src/util/sss_krb5.c
index e29c753..2d2dfc4 100644
--- a/src/util/sss_krb5.c
+++ b/src/util/sss_krb5.c
@@ -1103,7 +1103,10 @@ bool sss_krb5_realm_has_proxy(const char *realm)
 profile_path[1] = realm;
 
 kerr = profile_get_values(profile, profile_path, );
-if (kerr != 0) {
+if (kerr == PROF_NO_RELATION || kerr == PROF_NO_SECTION) {
+kerr = 0;
+goto done;
+} else if (kerr != 0) {
 DEBUG(SSSDBG_OP_FAILURE, "profile_get_values failed.\n");
 goto done;
 }
```

The commit message says that in that case we return false and even in 
retrospective it makes sense to me because the config doesn't have any related 
information to proxying.

"""

See the full comment at 
https://github.com/SSSD/sssd/pull/65#issuecomment-256683069
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#67][comment] UTIL: Unset O_NONBLOCK for ldap connection

[lslebodn]

  URL: https://github.com/SSSD/sssd/pull/67
Title: #67: UTIL: Unset O_NONBLOCK for ldap connection

lslebodn commented:
"""
On (27/10/16 02:03), Nikos Mavrogiannopoulos wrote:
>I don't quite understand what the fix is about nor how it relates to gnutls. 
>Is it about wrong handling of the client socket? To know whether the issue is 
>on the gnutls server, I'll need more information from the server side (gnutls 
>version, a run with GNUTLS_DEBUG_LEVEL set to 6 or more, and a capture of the 
>session).
>

Actually, this is not related to openldap server.
I tested debian client (libldap + gnutls) against rhel7 openldap server
(libldap + nss). So gnutls is not involved on server side.

The version of gnutls on client side(debian testing) is 3.5.5-2.

I will try to get some GNUTLS log from client.

LS

"""

See the full comment at 
https://github.com/SSSD/sssd/pull/67#issuecomment-256680099
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#48][comment] sssctl: Flags for commadn initialization

[lslebodn]

  URL: https://github.com/SSSD/sssd/pull/48
Title: #48: sssctl: Flags for commadn initialization

lslebodn commented:
"""
master:
* cbee11e912bb391ba254b0bac8c1159c1f634533

sssd-1-14:
* ec1829de7cd529c2c68b4bdb9b6d43ac6bb545d3

LS

"""

See the full comment at 
https://github.com/SSSD/sssd/pull/48#issuecomment-256679524
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#48][comment] sssctl: Flags for commadn initialization

[lslebodn]

  URL: https://github.com/SSSD/sssd/pull/48
Title: #48: sssctl: Flags for commadn initialization

lslebodn commented:
"""
ACK

"""

See the full comment at 
https://github.com/SSSD/sssd/pull/48#issuecomment-256677906
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] Re: fedorahosted.org sunset

[Jakub Hrozek]

On Fri, Sep 16, 2016 at 12:21:40PM +0200, Lukas Slebodnik wrote:
> +1 I can help with transition to Pagure.
> git hosting is not a problem and Nikolai voluntered to
> convert wiki to markdown in git

Sorry to restart an old thread, but..

I bought the sssd.io domain name. The intent is to have a simple but
pretty homepage like libssh.org or cmocka.org with links to documentation
which can itself be rendered from some git repository. The pages should
have zero or next-to-zero maintenance cost, so mostly static.

btw for now the domain is owned by me, but I'm totally fine transferring
the ownership to some shared account.
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] Should we use VMs or containers for (some) tests?

[Jakub Hrozek]

Hi,

I'm currently working on integration tests for the 'files' provider and
during this work I started to feel we are pushing the boundaries around our
test infrastructure already quite a bit. When SSSD talks over network to
a server, then we're more or less okay, but for some parts of SSSD, like
the files provider, we have to mock a lot of pieces and the end result
is that we are testing something that resembles the target system, but
probably has its own bugs. Additionally, we can't run some tests at all
(anything against IPA) and I suspect we'll be running into this sort of
a problem even more in the future.

So I'm interested in hearing what are other's thoughts on exploring how
to run some of our tests in a privileged environment, either in a VM or
in a container?

Our current tests have the big advantage of being able to provision a
test locally in a screen session, but maybe something similar would be
possible by e.g. running a screen in a container and attaching to its
tty.. And for "simple" tests like LDAP provider we could keep the current
infrastructure around.
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#46][comment] sss_client: Defer thread cancellation until completion of nss/pam operations

[sumit-bose]

  URL: https://github.com/SSSD/sssd/pull/46
Title: #46: sss_client: Defer thread cancellation until completion of nss/pam 
operations

sumit-bose commented:
"""
Here is the original reproducer/test program from 
https://fedorahosted.org/sssd/ticket/1460 written by Fedora user werkt  (I had 
to gzip it so that github likes it). I added a few fixes to remove some 
compiler warnings.

I verified that if the program was compiled without -DDISABLE_CANCEL it gets 
stuck with the old SSSD code without robust mutexes. With the new patch the 
reproducer works in both cases as expected.
[sss_client_hang.c.gz](https://github.com/SSSD/sssd/files/555662/sss_client_hang.c.gz)

"""

See the full comment at 
https://github.com/SSSD/sssd/pull/46#issuecomment-256621283
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#46][comment] sss_client: Defer thread cancellation until completion of nss/pam operations

[sumit-bose]

  URL: https://github.com/SSSD/sssd/pull/46
Title: #46: sss_client: Defer thread cancellation until completion of nss/pam 
operations

sumit-bose commented:
"""
Here is the original reproducer/test program from 
https://fedorahosted.org/sssd/ticket/1460 written by Fedora user werkt  (I had 
to gzip it so that github likes it). I added a few fixes to remove some 
compiler warnings.

I verified that if the program was compiled without -DDISABLE_CANCEL it gets 
stuck with the olsdSSSD code without robust mutexes. With the new patch the 
reproducer works in both cases as expected.
[sss_client_hang.c.gz](https://github.com/SSSD/sssd/files/555662/sss_client_hang.c.gz)

"""

See the full comment at 
https://github.com/SSSD/sssd/pull/46#issuecomment-256621283
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#39][comment] RESPONDER: Enable sudoRule in case insen. domains (1.13)

[pbrezina]

  URL: https://github.com/SSSD/sssd/pull/39
Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)

pbrezina commented:
"""
The patch looks good to me. I'd feel better if we somehow managed to backport 
patch that solves the fully qualified issue in 1.14 though.

I'm not that sure about simply appending domain qualification to sudoUser 
attributes. I don't recall all reasons why we did not do it, but it may be 
dangerous if you do not check the exact source where this users comes from. In 
theory you can have:
```ldif
sudoUser: my-u...@domain.com
sudoUser: my-user
```
Where `my-u...@domain.com` comes from domain that requires fully-qualified 
names and `my-user` is a local user.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/39#issuecomment-256619222
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#67][comment] UTIL: Unset O_NONBLOCK for ldap connection

[nmav]

  URL: https://github.com/SSSD/sssd/pull/67
Title: #67: UTIL: Unset O_NONBLOCK for ldap connection

nmav commented:
"""
I think from the above is clear that there must be some issue in the 
non-blocking support of libldap with gnutls, or that you are not using it 
properly. If you know you are using it properly and you know the offending 
calls, I could check them for their usage of gnutls and whether they are 
handling the non-blocking case (just post links to the offending code).
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/67#issuecomment-256617499
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#67][comment] UTIL: Unset O_NONBLOCK for ldap connection

[lslebodn]

  URL: https://github.com/SSSD/sssd/pull/67
Title: #67: UTIL: Unset O_NONBLOCK for ldap connection

lslebodn commented:
"""
> Could you explain what is the interaction between sssd and gnutls? Do you 
> pass the fd (which was set to non-blocking) or so to gnutls?

There is not direct interaction/usage between sssd and gnutls. It's done 
indirectly via libldap 
1. SOCK_STREAM socket is created by sssd
2. O_NONBLOCK is set on this socket
3. sssd creates connection to the ldap server (using connect syscall)
4. created socket descriptor is passed to the `ldap_init_fd` for initialisation 
of ldap handler which is used for any libldap operations.
5. If sssd is configured with ldap authentication then sssd tries to bind to 
the ldap server as user. Underneath, libldap will start_tls because we do not 
want to pass unencrypted password via network

Before sssd-1.14.0 we were unsetting O_NONBLOCK before 4th step. 

BTW these 5 steps work well with sssd-1.14 if lildap is compiled with openssl 
or moznss
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/67#issuecomment-256615534
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#67][comment] UTIL: Unset O_NONBLOCK for ldap connection

[nmav]

  URL: https://github.com/SSSD/sssd/pull/67
Title: #67: UTIL: Unset O_NONBLOCK for ldap connection

nmav commented:
"""
Could you explain what is the interaction between sssd and gnutls? Do you pass 
the fd (which was set to non-blocking) or so to gnutls?
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/67#issuecomment-256611358
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#67][comment] UTIL: Unset O_NONBLOCK for ldap connection

[nmav]

  URL: https://github.com/SSSD/sssd/pull/67
Title: #67: UTIL: Unset O_NONBLOCK for ldap connection

nmav commented:
"""
Could you explain what is the interaction between sssd and gnutls? Do you pass 
the fd (which was set to non-blocking) or so?
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/67#issuecomment-256611358
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#48][closed] sssctl: Flags for commadn initialization

[lslebodn]

   URL: https://github.com/SSSD/sssd/pull/48
Author: mzidek-rh
 Title: #48: sssctl: Flags for commadn initialization
Action: closed

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/48/head:pr48
git checkout pr48
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#48][+Pushed] sssctl: Flags for commadn initialization

[lslebodn]

  URL: https://github.com/SSSD/sssd/pull/48
Title: #48: sssctl: Flags for commadn initialization

Label: +Pushed
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] Re: Help : Tickets suitable for newcomers

[Pavel Březina]

On 10/27/2016 08:31 AM, Amit Kumar wrote:

Hey Fabiano,

Thanks for update..
I have posted detailed steps for:
1. Getting source Code
2. Doing Code Changes
3. Running Integration Tests...


Feel free to also checkout [1] and just run 'rebuild' when you want to 
build sssd.


[1] https://github.com/pbrezina/sssd-dev-utils



on [https://github.com/SSSD/sssd/pull/60]

if we can integrate them on contribute-link. That may help 1st timers in
builiding, Running Integration tests.

Thanks Much!!!
Amit Kumar


___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#67][comment] UTIL: Unset O_NONBLOCK for ldap connection

[lslebodn]

  URL: https://github.com/SSSD/sssd/pull/67
Title: #67: UTIL: Unset O_NONBLOCK for ldap connection

lslebodn commented:
"""
client log + gnutls debug
```
(Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [simple_bind_send] (0x0100): 
Executing simple bind as: uid=mof_user1,dc=example,dc=com
gnutls[5]: REC[0x6ae7d0]: Preparing Packet Application Data(23) with length: 86 
and min pad: 0
gnutls[9]: ENC[0x6ae7d0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
gnutls[11]: WRITE: enqueued 91 bytes for 0x64aec0. Total 91 bytes.
gnutls[11]: WRITE FLUSH: 91 bytes in buffer.
gnutls[11]: WRITE: wrote 91 bytes, 0 bytes left.
gnutls[5]: REC[0x6ae7d0]: Sent Packet[2] Application Data(23) in epoch 0 and 
length: 91
(Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [simple_bind_send] (0x2000): ldap 
simple bind sent, msgid = 2
(Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [sdap_op_add] (0x2000): New 
operation 2 timeout 6
(Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): 
Trace: sh[0x696940], connected[1], ops[0x696a90], ldap[0x698cf0]
(Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): 
Trace: end of ldap_result list
(Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): 
Trace: sh[0x696940], connected[1], ops[0x696a90], ldap[0x698cf0]
gnutls[10]: READ: Got 5 bytes from 0x64aec0
gnutls[10]: READ: read 5 bytes from 0x64aec0
gnutls[10]: RB: Have 0 bytes into buffer. Adding 5 bytes.
gnutls[10]: RB: Requested 5 bytes
gnutls[5]: REC[0x6ae7d0]: SSL 3.3 Handshake packet received. Epoch 0, length: 
1124
gnutls[5]: REC[0x6ae7d0]: Expected Packet Application Data(23)
gnutls[5]: REC[0x6ae7d0]: Received Packet Handshake(22) with length: 1124
gnutls[10]: READ: Got 1124 bytes from 0x64aec0
gnutls[10]: READ: read 1124 bytes from 0x64aec0
gnutls[10]: RB: Have 5 bytes into buffer. Adding 1124 bytes.
gnutls[10]: RB: Requested 1129 bytes
gnutls[5]: REC[0x6ae7d0]: Decrypted Packet[0] Handshake(22) with length: 1124
gnutls[3]: ASSERT: handshake.c[_gnutls_recv_hello_request]:3384
gnutls[3]: ASSERT: record.c[_gnutls_recv_in_buffers]:1323
gnutls[3]: ASSERT: record.c[_gnutls_recv_int]:1468
(Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [sdap_process_result] (0x0040): 
ldap_result error: [Can't contact LDAP server]
(Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [sdap_handle_release] (0x2000): 
Trace: sh[0x696940], connected[1], ops[0x696a90], ldap[0x698cf0], 
destructor_lock[0], release_memory[0]
(Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [remove_connection_callback] 
(0x4000): Successfully removed connection callback.
(Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [sdap_op_destructor] (0x1000): 
Abandoning operation 2
gnutls[5]: REC[0x6ae7d0]: Preparing Packet Application Data(23) with length: 8 
and min pad: 0
gnutls[9]: ENC[0x6ae7d0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
gnutls[11]: WRITE: enqueued 13 bytes for 0x64aec0. Total 13 bytes.
gnutls[11]: WRITE FLUSH: 13 bytes in buffer.
gnutls[11]: WRITE: wrote 13 bytes, 0 bytes left.
gnutls[5]: REC[0x6ae7d0]: Sent Packet[3] Application Data(23) in epoch 0 and 
length: 13
gnutls[11]: WRITE FLUSH: 0 bytes in buffer.
gnutls[3]: ASSERT: buffers.c[_gnutls_io_write_flush]:694
gnutls[5]: REC: Sending Alert[1|0] - Close notify
gnutls[5]: REC[0x6ae7d0]: Preparing Packet Alert(21) with length: 2 and min 
pad: 0
gnutls[9]: ENC[0x6ae7d0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
gnutls[11]: WRITE: enqueued 7 bytes for 0x64aec0. Total 7 bytes.
gnutls[11]: WRITE FLUSH: 7 bytes in buffer.
gnutls[11]: WRITE: wrote 7 bytes, 0 bytes left.
gnutls[5]: REC[0x6ae7d0]: Sent Packet[4] Alert(21) in epoch 0 and length: 7
(Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [dp_req_done] (0x0400): DP Request 
[PAM Authenticate #5]: Request handler finished [0]: Success
(Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [_dp_req_recv] (0x0400): DP Request 
[PAM Authenticate #5]: Receiving request data.
(Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [dp_req_destructor] (0x0400): DP 
Request [PAM Authenticate #5]: Request removed.
(Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [dp_req_destructor] (0x0400): 
Number of active DP request: 0
(Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [dp_method_enabled] (0x0400): 
Target selinux is not configured
(Thu Oct 27 11:49:01 2016) [sssd[be[LDAP]]] [dp_pam_reply] (0x1000): DP Request 
[PAM Authenticate #5]: Sending result [4][LDAP]
```
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/67#issuecomment-256591142
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#67][comment] UTIL: Unset O_NONBLOCK for ldap connection

[lslebodn]

  URL: https://github.com/SSSD/sssd/pull/67
Title: #67: UTIL: Unset O_NONBLOCK for ldap connection

lslebodn commented:
"""
and client + gnutls debug without O_NONBLOCK
```
(Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [simple_bind_send] (0x0100): 
Executing simple bind as: uid=mof_user1,dc=example,dc=com
gnutls[5]: REC[0xc31720]: Preparing Packet Application Data(23) with length: 86 
and min pad: 0
gnutls[5]: REC[0xc31720]: Sent Packet[2] Application Data(23) in epoch 1 and 
length: 115
(Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [simple_bind_send] (0x2000): ldap 
simple bind sent, msgid = 2
(Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [sdap_op_add] (0x2000): New 
operation 2 timeout 6
(Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): 
Trace: sh[0xc19510], connected[1], ops[0xc1fe40], ldap[0xc15f50]
(Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): 
Trace: end of ldap_result list
(Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): 
Trace: sh[0xc19510], connected[1], ops[0xc1fe40], ldap[0xc15f50]
gnutls[5]: REC[0xc31720]: SSL 3.3 Application Data packet received. Epoch 0, 
length: 73
gnutls[5]: REC[0xc31720]: Expected Packet Application Data(23)
gnutls[5]: REC[0xc31720]: Received Packet Application Data(23) with length: 73
gnutls[5]: REC[0xc31720]: Decrypted Packet[1] Application Data(23) with length: 
49
(Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [sdap_process_message] (0x4000): 
Message type: [LDAP_RES_BIND]
(Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [simple_bind_done] (0x2000): Server 
returned control [1.3.6.1.4.1.42.2.27.8.5.1].
(Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [simple_bind_done] (0x1000): 
Password Policy Response: expire [-1] grace [-1] error [No error].
(Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [simple_bind_done] (0x0400): Bind 
result: Success(0), no errmsg set
(Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [sdap_op_destructor] (0x2000): 
Operation 2 finished
(Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [auth_bind_user_done] (0x4000): 
Found ppolicy data, assuming LDAP password policies are active.
(Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [sdap_handle_release] (0x2000): 
Trace: sh[0xc19510], connected[1], ops[(nil)], ldap[0xc15f50], 
destructor_lock[0], release_memory[0]
(Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [remove_connection_callback] 
(0x4000): Successfully removed connection callback.
gnutls[5]: REC[0xc31720]: Preparing Packet Application Data(23) with length: 7 
and min pad: 0
gnutls[5]: REC[0xc31720]: Sent Packet[3] Application Data(23) in epoch 1 and 
length: 36
gnutls[3]: ASSERT: buffers.c[_gnutls_io_write_flush]:694
gnutls[5]: REC: Sending Alert[1|0] - Close notify
gnutls[5]: REC[0xc31720]: Preparing Packet Alert(21) with length: 2 and min 
pad: 0
gnutls[5]: REC[0xc31720]: Sent Packet[4] Alert(21) in epoch 1 and length: 31
gnutls[3]: ASSERT: buffers.c[_gnutls_io_write_flush]:694
gnutls[5]: REC: Sending Alert[1|0] - Close notify
gnutls[5]: REC[0xc31720]: Preparing Packet Alert(21) with length: 2 and min 
pad: 0
gnutls[3]: ASSERT: buffers.c[_gnutls_writev_emu]:462
gnutls[2]: WRITE: -1 returned from 0xbcbd60, errno: 9
gnutls[3]: ASSERT: buffers.c[errno_to_gerr]:228
gnutls[3]: ASSERT: buffers.c[_gnutls_io_write_flush]:720
gnutls[3]: ASSERT: record.c[_gnutls_send_tlen_int]:554
gnutls[3]: ASSERT: record.c[gnutls_bye]:302
gnutls[5]: REC[0xc31720]: Start of epoch cleanup
gnutls[5]: REC[0xc31720]: End of epoch cleanup
gnutls[5]: REC[0xc31720]: Epoch #1 freed
(Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [dp_req_done] (0x0400): DP Request 
[PAM Authenticate #3]: Request handler finished [0]: Success
(Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [_dp_req_recv] (0x0400): DP Request 
[PAM Authenticate #3]: Receiving request data.
(Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [dp_req_destructor] (0x0400): DP 
Request [PAM Authenticate #3]: Request removed.
(Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [dp_req_destructor] (0x0400): 
Number of active DP request: 0
(Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [dp_method_enabled] (0x0400): 
Target selinux is not configured
(Thu Oct 27 11:37:03 2016) [sssd[be[LDAP]]] [dp_pam_reply] (0x1000): DP Request 
[PAM Authenticate #3]: Sending result [0][LDAP]
```
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/67#issuecomment-256595910
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#67][comment] UTIL: Unset O_NONBLOCK for ldap connection

[lslebodn]

  URL: https://github.com/SSSD/sssd/pull/67
Title: #67: UTIL: Unset O_NONBLOCK for ldap connection

lslebodn commented:
"""
client log + gnutls debug
```
(Thu Oct 27 11:20:35 2016) [sssd[be[LDAP]]] [simple_bind_send] (0x0100): 
Executing simple bind as: uid=mof_user1,dc=example,dc=com
gnutls[5]: REC[0x1a380b0]: Preparing Packet Application Data(23) with length: 
85 and min pad: 0
gnutls[5]: REC[0x1a380b0]: Sent Packet[2] Application Data(23) in epoch 0 and 
length: 90
(Thu Oct 27 11:20:35 2016) [sssd[be[LDAP]]] [simple_bind_send] (0x2000): ldap 
simple bind sent, msgid = 2
(Thu Oct 27 11:20:35 2016) [sssd[be[LDAP]]] [sdap_op_add] (0x2000): New 
operation 2 timeout 6
(Thu Oct 27 11:20:35 2016) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): 
Trace: sh[0x1a30cc0], connected[1], ops[0x1a2f660], ldap[0x1a48b60]
(Thu Oct 27 11:20:35 2016) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): 
Trace: end of ldap_result list
(Thu Oct 27 11:20:36 2016) [sssd[be[LDAP]]] [sdap_process_result] (0x2000): 
Trace: sh[0x1a30cc0], connected[1], ops[0x1a2f660], ldap[0x1a48b60]
gnutls[5]: REC[0x1a380b0]: SSL 3.3 Handshake packet received. Epoch 0, length: 
1124
gnutls[5]: REC[0x1a380b0]: Expected Packet Application Data(23)
gnutls[5]: REC[0x1a380b0]: Received Packet Handshake(22) with length: 1124
gnutls[5]: REC[0x1a380b0]: Decrypted Packet[0] Handshake(22) with length: 1124
gnutls[3]: ASSERT: handshake.c[_gnutls_recv_hello_request]:3384
gnutls[3]: ASSERT: record.c[_gnutls_recv_in_buffers]:1323
gnutls[3]: ASSERT: record.c[_gnutls_recv_int]:1468
(Thu Oct 27 11:20:36 2016) [sssd[be[LDAP]]] [sdap_process_result] (0x0040): 
ldap_result error: [Can't contact LDAP server]
(Thu Oct 27 11:20:36 2016) [sssd[be[LDAP]]] [sdap_handle_release] (0x2000): 
Trace: sh[0x1a30cc0], connected[1], ops[0x1a2f660], ldap[0x1a48b60], 
destructor_lock[0], release_memory[0]
(Thu Oct 27 11:20:36 2016) [sssd[be[LDAP]]] [remove_connection_callback] 
(0x4000): Successfully removed connection callback.
(Thu Oct 27 11:20:36 2016) [sssd[be[LDAP]]] [sdap_op_destructor] (0x1000): 
Abandoning operation 2
gnutls[5]: REC[0x1a380b0]: Preparing Packet Application Data(23) with length: 8 
and min pad: 0
gnutls[5]: REC[0x1a380b0]: Sent Packet[3] Application Data(23) in epoch 0 and 
length: 13
gnutls[3]: ASSERT: buffers.c[_gnutls_io_write_flush]:694
gnutls[5]: REC: Sending Alert[1|0] - Close notify
gnutls[5]: REC[0x1a380b0]: Preparing Packet Alert(21) with length: 2 and min 
pad: 0
gnutls[5]: REC[0x1a380b0]: Sent Packet[4] Alert(21) in epoch 0 and length: 7
(Thu Oct 27 11:20:36 2016) [sssd[be[LDAP]]] [dp_req_done] (0x0400): DP Request 
[PAM Authenticate #5]: Request handler finished [0]: Success
(Thu Oct 27 11:20:36 2016) [sssd[be[LDAP]]] [_dp_req_recv] (0x0400): DP Request 
[PAM Authenticate #5]: Receiving request data.
(Thu Oct 27 11:20:36 2016) [sssd[be[LDAP]]] [dp_req_destructor] (0x0400): DP 
Request [PAM Authenticate #5]: Request removed.
(Thu Oct 27 11:20:36 2016) [sssd[be[LDAP]]] [dp_req_destructor] (0x0400): 
Number of active DP request: 0
(Thu Oct 27 11:20:36 2016) [sssd[be[LDAP]]] [dp_method_enabled] (0x0400): 
Target selinux is not configured
(Thu Oct 27 11:20:36 2016) [sssd[be[LDAP]]] [dp_pam_reply] (0x1000): DP Request 
[PAM Authenticate #5]: Sending result [4][LDAP]
(Thu Oct 27 11:20:36 2016) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x8c86e0
(Thu Oct 27 11:20:36 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 
0x8bbdb0
(Thu Oct 27 11:20:36 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching.
(Thu Oct 27 11:20:36 2016) [sssd[pam]] [pam_dp_process_reply] (0x0200): 
received: [4 (System error)][LDAP]
(Thu Oct 27 11:20:36 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply called 
with result [4]: System error.
(Thu Oct 27 11:20:36 2016) [sssd[pam]] [pam_reply] (0x0200): blen: 21
(Thu Oct 27 11:20:36 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
re-set for client [0x8c8d30][16]
gnutls[3]: ASSERT: buffers.c[_gnutls_io_write_flush]:694
gnutls[5]: REC: Sending Alert[1|0] - Close notify
gnutls[5]: REC[0x1a380b0]: Preparing Packet Alert(21) with length: 2 and min 
pad: 0
gnutls[3]: ASSERT: buffers.c[_gnutls_writev_emu]:462
gnutls[2]: WRITE: -1 returned from 0x19e78c0, errno: 9
gnutls[3]: ASSERT: buffers.c[errno_to_gerr]:228
gnutls[3]: ASSERT: buffers.c[_gnutls_io_write_flush]:720
gnutls[3]: ASSERT: record.c[_gnutls_send_tlen_int]:554
gnutls[3]: ASSERT: record.c[gnutls_bye]:302
gnutls[5]: REC[0x1a380b0]: Start of epoch cleanup
gnutls[5]: REC[0x1a380b0]: End of epoch cleanup
gnutls[5]: REC[0x1a380b0]: Epoch #0 freed
gnutls[5]: REC[0x1a380b0]: Epoch #1 freed
(Thu Oct 27 11:20:40 2016) [sssd[pam]] [pam_initgr_cache_remove] (0x2000): 
[mof_user1] removed from PAM initgroup cache
```
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/67#issuecomment-256591142
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to 

[SSSD] [sssd PR#57][comment] LDAP/AD: resolve domain local groups for remote users

[jhrozek]

  URL: https://github.com/SSSD/sssd/pull/57
Title: #57: LDAP/AD: resolve domain local groups for remote users

jhrozek commented:
"""
Thank you, this version reads better to me and still works fine (adding and 
removing the global group as well..)

So far ACK, I will push the patch once I'm able to re-run the downstream tests 
with this version.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/57#issuecomment-256588325
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#57][+Accepted] LDAP/AD: resolve domain local groups for remote users

[jhrozek]

  URL: https://github.com/SSSD/sssd/pull/57
Title: #57: LDAP/AD: resolve domain local groups for remote users

Label: +Accepted
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#67][comment] UTIL: Unset O_NONBLOCK for ldap connection

[nmav]

  URL: https://github.com/SSSD/sssd/pull/67
Title: #67: UTIL: Unset O_NONBLOCK for ldap connection

nmav commented:
"""
I don't quite understand what the fix is about nor how it relates to gnutls. Is 
it about wrong handling of the client socket? To know whether the issue is on 
the gnutls server, I'll need more information from the server side (gnutls 
version, a run with GNUTLS_DEBUG_LEVEL set to 6 or more, and a capture of the 
session).
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/67#issuecomment-256587092
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#67][comment] UTIL: Unset O_NONBLOCK for ldap connection

[lslebodn]

  URL: https://github.com/SSSD/sssd/pull/67
Title: #67: UTIL: Unset O_NONBLOCK for ldap connection

lslebodn commented:
"""
> Thank you for digging into this and finding the connection to gnutls. Do you 
> think this is an issue which should be solved in OpenLDAP or gnutls as well, 
> or is it really the responsibility of the caller to make sure O_NONBLOCK is 
> not set? If yes, is this documented?

Maybe Nikos would know @nmav
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/67#issuecomment-256585196
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#60][comment] Document ad_access_filter search for nested groups

[sumit-bose]

  URL: https://github.com/SSSD/sssd/pull/60
Title: #60: Document ad_access_filter search for nested groups

sumit-bose commented:
"""
Just a small nitpick. Can you put the URL into a  element like e.g. in 
https://github.com/SSSD/sssd/blob/master/src/man/sssd-ldap.5.xml#L1047 ? This 
will make sure the URL is formatted correctly with different output format.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/60#issuecomment-256583607
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#67][comment] UTIL: Unset O_NONBLOCK for ldap connection

[sumit-bose]

  URL: https://github.com/SSSD/sssd/pull/67
Title: #67: UTIL: Unset O_NONBLOCK for ldap connection

sumit-bose commented:
"""
Thank you for digging into this and finding the connection to gnutls. Do you 
think this is an issue which should be solved in OpenLDAP or gnutls as well, or 
is it really the responsibility of the caller to make sure O_NONBLOCK is not 
set? If yes, is this documented?

"""

See the full comment at 
https://github.com/SSSD/sssd/pull/67#issuecomment-256582670
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#49][+Changes requested] Try to match multiple results from an AD initgroups request against domain's search bases, too

[jhrozek]

  URL: https://github.com/SSSD/sssd/pull/49
Title: #49: Try to match multiple results from an AD initgroups request against 
domain's search bases, too

Label: +Changes requested
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#60][comment] Document ad_access_filter search for nested groups

[jhrozek]

  URL: https://github.com/SSSD/sssd/pull/60
Title: #60: Document ad_access_filter search for nested groups

jhrozek commented:
"""
The documentation now looks correct, I just wonder why did you remove the 
example paragraph in the last iteration of the patch? IMO it would be useful..
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/60#issuecomment-256576929
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#62][comment] PAM: add pam_response_filter option

[jhrozek]

  URL: https://github.com/SSSD/sssd/pull/62
Title: #62: PAM: add pam_response_filter option

jhrozek commented:
"""
retest this please
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/62#issuecomment-256572973
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] Re: Help : Tickets suitable for newcomers

[Amit Kumar]

Hey Fabiano,

Thanks for update..
I have posted detailed steps for:
1. Getting source Code
2. Doing Code Changes
3. Running Integration Tests...

on [https://github.com/SSSD/sssd/pull/60]

if we can integrate them on contribute-link. That may help 1st timers in
builiding, Running Integration tests.

Thanks Much!!!
Amit Kumar

On Thu, Oct 27, 2016 at 12:30 AM, Fabiano Fidêncio 
wrote:

> On Wed, Oct 26, 2016 at 8:51 PM, Jakub Hrozek  wrote:
> > On Wed, Oct 26, 2016 at 11:37:22PM +0530, Amit Kumar wrote:
> >> Hello,
> >> Thanks for response.
> >> I made code change in src/providers/ipa/ipa_access.c
> >> # make
> >> # make intgcheck
> >> configure: error: source directory already configured; run "make
> distclean"
> >> there first
> >> Makefile:27077: recipe for target 'intgcheck-prepare' failed
> >> make[1]: *** [intgcheck-prepare] Error 1
> >> make[1]: Leaving directory '/root/sssd'
> >> Makefile:27110: recipe for target 'intgcheck' failed
> >> make: *** [intgcheck] Error 2
> >
> > I presume you ran configure in the same directory as the sources? It's
> > better to use a parallel build directory. See the bash helper at
> > contrib/fedora/bashrc_sssd, it contains some macros that you can use..
>
> And here is a link explaining the best way to contribute to SSSD,
> which includes the bash helper mentioned by Jakub:
> https://fedorahosted.org/sssd/wiki/Contribute
>
> If you find something that's inconsistent there, feel free to propose
> a change and we will happily apply.
>
> Best Regards,
> --
> Fabiano Fidêncio
> ___
> sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
>
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#60][comment] Document ad_access_filter search for nested groups

[amitkumar50]

  URL: https://github.com/SSSD/sssd/pull/60
Title: #60: Document ad_access_filter search for nested groups

amitkumar50 commented:
"""
Thanks Islebodn . Conflicts are resolved..
Posting What I did may help some one.

Steps for 
1. Getting source Code
2. Doing Code Changes
3. Running Integration Tests...
[root@dlp] dnf -y install git
[root@dlp] git config --global user.name "GIVENNAME SURNAME"
[root@dlp] git config --global user.email "usern...@domain.com"
[root@dlp] git config --global color.ui auto//Enable Syntax 
highlighting
[root@dlp] dnf -y install meld//Tool for resolving Merge 
conflicts
[root@dlp] git config --global merge.tool meld
[root@dlp]# git clone https://git.fedorahosted.org/git/sssd.git 
[root@dlp]# cd sssd
[root@dlp sssd]# . contrib/fedora/bashrc_sssd
[root@dlp sssd]# dnf -y install rpm-build dnf-plugins-core libldb-devel
[root@dlp sssd]# contrib/fedora/make_srpm.sh//Create source rpm
[root@dlp sssd]# dnf builddep rpmbuild/SRPMS/sssd-*.src.rpm
//Install sssd dependencies
[root@dlp sssd]# reconfig && chmake
make[1]: Leaving directory '/root/sssd/x86_64'
[root@dlp x86_64]# pwd<=See Directory Changed Automatically
/root/sssd/x86_64
[root@dlp x86_64]# 
[root@dlp x86_64]# dnf install -y openldap-servers fakeroot
[root@dlp x86_64]# vim../src/providers/ipa/access_ipa.c
//Do some changes...
[root@dlp x86_64]# make
[root@dlp x86_64]# make  intgcheck
=== 119 passed in 302.77 seconds ===
make[1]: Leaving directory '/root/sssd/x86_64'
[root@dlp x86_64]# 
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/60#issuecomment-256557508
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org