[SSSD] Cannot start sssd from source [libsss_ldap_common.so: undefined symbol: ldap_tls_inplace]

[Amit Kumar]

Hello,

I build sssd-1.16.0-19 from source.

#./configure; make; make install

# /usr/local/sbin/sssd -i -d 1
ldb: unable to dlopen /usr/lib64/ldb/modules/ldb/memberof.la :
/usr/lib64/ldb/modules/ldb/memberof.la: invalid ELF header
ldb: unable to dlopen /usr/lib64/ldb/modules/ldb/memberof.la :
/usr/lib64/ldb/modules/ldb/memberof.la: invalid ELF header
(Mon Nov 19 12:49:31 2018) [sssd[be[atest.com]]] [dp_module_open_lib]
(0x0010): Unable to load module [ad] with path
[/usr/local/lib/sssd/libsss_ad.so]:
/usr/local/lib/sssd/libsss_ldap_common.so: undefined symbol:
ldap_tls_inplace
(Mon Nov 19 12:49:31 2018) [sssd[be[atest.com]]] [dp_load_module]
(0x0020): Unable to create DP module.
(Mon Nov 19 12:49:31 2018) [sssd[be[atest.com]]] [dp_target_init]
(0x0010): Unable to load module ad
(Mon Nov 19 12:49:31 2018) [sssd[be[atest.com]]] [dp_load_targets]
(0x0020): Unable to load target [id] [80]: Accessing a corrupted shared
library.
(Mon Nov 19 12:49:31 2018) [sssd[be[atest.com]]] [dp_init] (0x0020):
Unable to initialize DP targets [1432158209]: Internal Error
(Mon Nov 19 12:49:31 2018) [sssd[be[atest.com]]] [be_process_init]
(0x0010): Unable to setup data provider [1432158209]: Internal Error
(Mon Nov 19 12:49:31 2018) [sssd[be[atest.com]]] [main] (0x0010): Could
not initialize backend [1432158209]
ldb: unable to dlopen /usr/lib64/ldb/modules/ldb/memberof.la :
/usr/lib64/ldb/modules/ldb/memberof.la: invalid ELF header
(Mon Nov 19 12:49:31 2018) [sssd[be[atest.com]]] [dp_module_open_lib]
(0x0010): Unable to load module [ad] with path
[/usr/local/lib/sssd/libsss_ad.so]:
/usr/local/lib/sssd/libsss_ldap_common.so: undefined symbol:
ldap_tls_inplace
(Mon Nov 19 12:49:31 2018) [sssd[be[atest.com]]] [dp_load_module]
(0x0020): Unable to create DP module.
(Mon Nov 19 12:49:31 2018) [sssd[be[atest.com]]] [dp_target_init]
(0x0010): Unable to load module ad
(Mon Nov 19 12:49:31 2018) [sssd[be[atest.com]]] [dp_load_targets]
(0x0020): Unable to load target [id] [80]: Accessing a corrupted shared
library.
(Mon Nov 19 12:49:31 2018) [sssd[be[atest.com]]] [dp_init] (0x0020):
Unable to initialize DP targets [1432158209]: Internal Error
(Mon Nov 19 12:49:31 2018) [sssd[be[atest.com]]] [be_process_init]
(0x0010): Unable to setup data provider [1432158209]: Internal Error
(Mon Nov 19 12:49:31 2018) [sssd[be[atest.com]]] [main] (0x0010): Could
not initialize backend [1432158209]
ldb: unable to dlopen /usr/lib64/ldb/modules/ldb/memberof.la :
/usr/lib64/ldb/modules/ldb/memberof.la: invalid ELF header
(Mon Nov 19 12:49:33 2018) [sssd[be[atest.com]]] [dp_module_open_lib]
(0x0010): Unable to load module [ad] with path
[/usr/local/lib/sssd/libsss_ad.so]:
/usr/local/lib/sssd/libsss_ldap_common.so: undefined symbol:
ldap_tls_inplace
(Mon Nov 19 12:49:33 2018) [sssd[be[atest.com]]] [dp_load_module]
(0x0020): Unable to create DP module.
(Mon Nov 19 12:49:33 2018) [sssd[be[atest.com]]] [dp_target_init]
(0x0010): Unable to load module ad
(Mon Nov 19 12:49:33 2018) [sssd[be[atest.com]]] [dp_load_targets]
(0x0020): Unable to load target [id] [80]: Accessing a corrupted shared
library.
(Mon Nov 19 12:49:33 2018) [sssd[be[atest.com]]] [dp_init] (0x0020):
Unable to initialize DP targets [1432158209]: Internal Error
(Mon Nov 19 12:49:33 2018) [sssd[be[atest.com]]] [be_process_init]
(0x0010): Unable to setup data provider [1432158209]: Internal Error
(Mon Nov 19 12:49:33 2018) [sssd[be[atest.com]]] [main] (0x0010): Could
not initialize backend [1432158209]
(Mon Nov 19 12:49:36 2018) [sssd] [services_startup_timeout] (0x0020):
Providers did not start in time, forcing services startup!
ldb: unable to dlopen /usr/lib64/ldb/modules/ldb/memberof.la :
/usr/lib64/ldb/modules/ldb/memberof.la: invalid ELF header
ldb: unable to dlopen /usr/lib64/ldb/modules/ldb/memberof.la :
/usr/lib64/ldb/modules/ldb/memberof.la: invalid ELF header
ldb: unable to dlopen /usr/lib64/ldb/modules/ldb/memberof.la :
/usr/lib64/ldb/modules/ldb/memberof.la: invalid ELF header
(Mon Nov 19 12:49:36 2018) [sssd[ssh]] [sbus_client_init] (0x0020):
check_file failed for
[/usr/local/var/lib/sss/pipes/private/sbus-dp_atest.com].
(Mon Nov 19 12:49:36 2018) [sssd[ssh]] [sss_dp_init] (0x0010): Failed to
connect to monitor services.
(Mon Nov 19 12:49:36 2018) [sssd[ssh]] [sss_process_init] (0x0010):
fatal error setting up backend connector
(Mon Nov 19 12:49:36 2018) [sssd[ssh]] [ssh_process_init] (0x0010):
sss_process_init() failed
(Mon Nov 19 12:49:36 2018) [sssd[pam]] [sbus_client_init] (0x0020):
check_file failed for
[/usr/local/var/lib/sss/pipes/private/sbus-dp_atest.com].
(Mon Nov 19 12:49:36 2018) [sssd[pam]] [sss_dp_init] (0x0010): Failed to
connect to monitor services.
(Mon Nov 19 12:49:36 2018) [sssd[pam]] [sss_process_init] (0x0010):
fatal error setting up backend connector
(Mon Nov 19 12:49:36 2018) [sssd[pam]] [pam_process_init] (0x0010):
sss_process_init() failed
(Mon Nov 19 12:49:36 2018) [sssd[nss]] [sbus_client_init] (0x0020):
check_file failed for

[SSSD] About https://pagure.io/SSSD/sssd/issue/1898

[amit kumar]

Dear Devels,

The requirement I understand is to move files used by both
client(sss_client) & server to some special directory may be src/shared?
I believe these are common files used by both server &
client(sss_client) Hence movement is required?

I find 3 files having the header specified in Bug:
./src/util/murmurhash3.h
./src/util/io.h
./src/util/util_safealign.h

Is this the only task to be carried or addons on it?

-- 
Thanks
Amit Kumar
!!If you stumble, get back up. 
What happened yesterday, no longer matters.
Today is another day to move closer to your GOAL!!

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

[SSSD] Re: Regarding sssd.conf syntax check, going thru dinglib

[amit kumar]

Hello Lukas,

Thanks for response, yes we have ticket
https://pagure.io/SSSD/sssd/issue/416

But my query was regarding the design *how we parse smb.conf using
ding-lib.*

I am planing to provide a fix so that 'sssctl config-check' reports
something as this incorrect.
debug_level = uu
I found anything on RHS of = inside smb.conf is not validated?
Do we use # cat /root/ding-libs-0.6.0/ini/ini.d/mysssd.conf for
validation of contents, if yes {How}.

Hope I am clear with my question.

Many Thanks in Advance
Amit

On 03/29/2017 10:12 PM, Lukas Slebodnik wrote:
> On (29/03/17 19:13), amit kumar wrote:
>> Hello,
>>
>> *Present **Behavior*:
>> # vim  /usr/local/etc/sssd/sssd.conf
>> [sssd]
>> services = nss, pam
>> config_file_version = 2
>> domains = LDAP
>>
>> [domain/LDAP]
>> ldap_search_base = dc=example,dc=com
>> id_provider = ldap
>> *auth_provider = ldap9001**<== '**sssctl config_check' does not
>  ^^
> ATM it reports just an invalid option name
> and "auth_provider" is valid.
>
> Validating values need to be implemented.
> I think we have ticket somewhere.
>
> LS
> ___
> sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

-- 
Thanks
Amit Kumar
There are three ways to get something done:
  (1) Do it yourself.
  (2) Hire someone to do it for you.
  (3) Forbid your kids to do it.

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

[SSSD] Regarding sssd.conf syntax check, going thru dinglib

[amit kumar]

Hello,

*Present **Behavior*:
# vim  /usr/local/etc/sssd/sssd.conf
[sssd]
services = nss, pam
config_file_version = 2
domains = LDAP

[domain/LDAP]
ldap_search_base = dc=example,dc=com
id_provider = ldap
*auth_provider = ldap9001**<== '**sssctl config_check' does not
reports this1*
ldap_uri = ldap://server.example.com
ldap_id_use_start_tls = True
ldap_tls_cacert = /etc/openldap/certs/cacert.asc
*debug_level = tt**<== 'sssctl config_check' does not reports
this2
**klala =  1<== '**sssctl config_check' r**eports
thi*s3

*My **Interpretation*:
sss_ini_call_validators_errobj()//sssd/src/util/sss_ini.c
ini_rules_read_from_file(rules_path, _cfgobj);   
//rules_path=/usr/share/sssd/cfg_rules.ini{All _keywords on left
side of __assignment__are rules_ which are _read from cfg_rules.ini_
fills in struct ini_cfgobj}

*Why sssd does**reports 3*?Because rule is not present in cfg_rules.ini
*Why sssd doe**s not report 1,2*?May be
- Because there is no such check in ding-lib about values of options.
- OR Check is broken.I also find
# cat /root/ding-libs-0.6.0/ini/ini.d/mysssd.conf
[service]
# Options available to all services
debug_level = int, None, false<=Now
what's this syntax. If it takes int, then is this broken.


Please throw some light...

-- 
Thanks
Amit Kumar
There are three ways to get something done:
  (1) Do it yourself.
  (2) Hire someone to do it for you.
  (3) Forbid your kids to do it.

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

[SSSD] Re: https://pagure.io/SSSD/sssd/issue/3158 {where to find source code ini_rules_check(), may be sss_util.c}

[amit kumar]

Hello Michel,

Thanks for update.
I have cloned ding-lib.

Yes package has ini directory having ini_ functions.
*But still ini**_rule**s_check() function i**s not found*

# make install
Installs libini_config.so  & others.
But cannot see libsss_util.so getting installed.

Thanks

On 03/20/2017 02:22 PM, Michal Židek wrote:
> On 03/18/2017 02:39 PM, amit kumar wrote:
>> Hello,
>>
>> sssctl config-check does not show what file contains the problem
>> ./src/util/sss_ini.c:578:ret = ini_rules_check(rules_cfgobj,
>> data->sssd_config, NULL, *errobj*);
>> *errobj=*> This contains errorObjects which are thrown on screen.
>>
>> # grep -rwn . -e "ini_rules_check"
>> Binary file ./src/util/.libs/libsss_util_la-sss_ini.o matches
>> ./src/util/sss_ini.c:578:ret = ini_rules_check(rules_cfgobj,
>> data->sssd_config, NULL, errobj);
>> ./src/util/sss_ini.c:581:  "ini_rules_check failed %d
>> [%s]\n", ret, strerror(ret));
>> Binary file ./x86_64/src/util/.libs/libsss_util_la-sss_ini.o matches
>> Binary file ./x86_64/.libs/*libsss_util.so* matches<=Query[where
>> to find libsss_util.so source code (may be sss_util.c)]
>> Binary file ./x86_64/.libs/libsss_util.soT matches
>> Binary file ./.libs/libsss_util.so matches
>> Binary file ./.libs/libsss_util.soT matches
>>
>> I know libsss_util.so is created during reconfig & chmake, as it creates
>> x86_64.
>>
>
> Functions with ini_ prefix are from ding-libs (libini part
> to be more precise).
>
> Michal
> _______
> sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

-- 
Thanks
Amit Kumar
There are three ways to get something done:
  (1) Do it yourself.
  (2) Hire someone to do it for you.
  (3) Forbid your kids to do it.

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

[SSSD] https://pagure.io/SSSD/sssd/issue/3158 {where to find source code ini_rules_check(), may be sss_util.c}

[amit kumar]

Hello,

sssctl config-check does not show what file contains the problem
./src/util/sss_ini.c:578:ret = ini_rules_check(rules_cfgobj,
data->sssd_config, NULL, *errobj*);
*errobj=*> This contains errorObjects which are thrown on screen.

# grep -rwn . -e "ini_rules_check"
Binary file ./src/util/.libs/libsss_util_la-sss_ini.o matches
./src/util/sss_ini.c:578:ret = ini_rules_check(rules_cfgobj,
data->sssd_config, NULL, errobj);
./src/util/sss_ini.c:581:  "ini_rules_check failed %d
[%s]\n", ret, strerror(ret));
Binary file ./x86_64/src/util/.libs/libsss_util_la-sss_ini.o matches
Binary file ./x86_64/.libs/*libsss_util.so* matches<=Query[where
to find libsss_util.so source code (may be sss_util.c)]
Binary file ./x86_64/.libs/libsss_util.soT matches
Binary file ./.libs/libsss_util.so matches
Binary file ./.libs/libsss_util.soT matches

I know libsss_util.so is created during reconfig & chmake, as it creates
x86_64.

-- 
Thanks
Amit Kumar
There are three ways to get something done:
  (1) Do it yourself.
  (2) Hire someone to do it for you.
  (3) Forbid your kids to do it.

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

[SSSD] $ reconfig && chmake failed

[amit kumar]

PASS: refcount-tests
FAIL: fail_over-tests
PASS: find_uid-tests
PASS: auth-tests
PASS: ipa_ldap_opt-tests
PASS: ad_ldap_opt-tests
PASS: crypto-tests
PASS: util-tests
PASS: debug-tests
PASS: ipa_hbac-tests
PASS: sss_idmap-tests
PASS: responder_socket_access-tests
PASS: sysdb-tests
PASS: safe-format-tests
PASS: sysdb_ssh-tests
PASS: sbus_tests
PASS: sbus_codegen_tests
PASS: test_fo_srv
PASS: resolv-tests

Testsuite summary for sssd 1.14.90

# TOTAL: 83
# PASS:  82
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See ./test-suite.log
Please report to sssd-devel@lists.fedorahosted.org


# vim ./test_suite.log


   sssd 1.14.90: ./test-suite.log


# TOTAL: 83
# PASS:  82
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: fail_over-tests
=

Running suite(s): fail_over
50%: Checks: 2, Failures: 1, Errors: 0
../src/tests/fail_over-tests.c:162:F:FAIL_OVER
Tests:test_fo_resolve_service:0: ../src/tests/fail_over-tests.c:254:
Expected return of 0, got 110
FAIL fail_over-tests (exit status: 1)




-- 
Thanks
Amit Kumar
There are three ways to get something done:
  (1) Do it yourself.
  (2) Hire someone to do it for you.
  (3) Forbid your kids to do it.

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

[SSSD] Re: [sssd PR#100][synchronized] Updation of sssd-ad man page for case when dyndns_refresh_interval < 60 seconds

[amit kumar]

Hello,

kindly review https://github.com/SSSD/sssd/pull/100

commit f8f208f6f1a12e25d46b80459d87ae269924117d

Thanks


On 12/08/2016 11:12 AM, amitkumar50 wrote:
>URL: https://github.com/SSSD/sssd/pull/100
> Author: amitkumar50
>  Title: #100: Updation of sssd-ad man page for case when 
> dyndns_refresh_interval < 60 seconds
> Action: synchronized
>
> To pull the PR as Git branch:
> git remote add ghsssd https://github.com/SSSD/sssd
> git fetch ghsssd pull/100/head:pr100
> git checkout pr100
>
>
> ___
> 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] Updation of sssd-ad man page for case when dyndns_refresh_interval < 60 seconds #100

[amit kumar]

Hi,

https://github.com/SSSD/sssd/pull/100

I am planning to use this:
Note that lowest possible value is 60 seconds in-case if value is
provided less than 60, parameter will assume lowest value only.

Thanks

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

[SSSD] Feedback About probable Fix for sssd/ticket/1149

[amit kumar]

Hello,

_https://fedorahosted.org/sssd/ticket/1149

_Yes replacement of talloc_get_type() with talloc_get_type_abort() is
good move, reasons mentioned in description. Current sssd contains 773
occurrences of talloc_get_type.

I suppose Fix is: Replacing all 773 occurrences with
talloc_get_type_abort().

Sanity Test:

 1. # make intgchk
 2. Use case: Configuring AD trust using sssd.

My Queries:

 1. Is Fix correct?
 2. Does any other specific/corner test-case is required?

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

[SSSD] Re: Design document - Socket-activatable responders

[amit kumar]

Hey fabiano,

There are couple of spelling mistakes(*Bo**ld*) on DesignDoc Page:
https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders

consists in marking the service as started, increasing the services'
counter, getting the responder's *configuratiom*, <
he change in the responders' common code is quite trivial, just *chnage*
the sss_process_init code to call activate_unix_sockets()  <

Thanks

On 11/25/2016 04:34 AM, Fabiano Fidêncio wrote:
> On Thu, Nov 24, 2016 at 2:33 PM, Fabiano Fidêncio  wrote:
>> The design page is done [0] and it's based on this discussion [1] we
>> had on this very same mailing list. A pull-request with the
>> implementation is already opened [2].
>>
>> [0]: 
>> https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders
>> [1]: 
>> https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/
>> [2]: https://github.com/SSSD/sssd/pull/84
> Well, PR#94: https://github.com/SSSD/sssd/pull/94
>
>> The full text of c here:
>>
>> = Socket Activatable Responders =
>>
>> Related ticket(s):
>>  * https://fedorahosted.org/sssd/ticket/2243
>>  * https://fedorahosted.org/sssd/ticket/3129
>>
>> === Problem statement ===
>> SSSD has some responders which don't have to be running all the time,
>> but could be socket-activated instead in platforms where it's
>> supported. That's the case, for instance, for the IFP, ssh and sudo
>> responders.
>> Making these responders socket-activated would provide a better use
>> experience, as these services could be started on-demand when a client
>> needs them and exist after a period of inactivity. Currently the admin
>> has to explicitly list all the services that might potentially be
>> needed in the `services` section and the processes have to be running
>> all the time.
>>
>> === Use cases ===
>>
>>  sssctl  
>> As more and more features that had been added depending on the IFP
>> responder, we should make sure that the responder is activated on
>> demand and the admins doesn't have to activate it manually.
>>
>>  KCM 
>> The KCM responder is only seldom needed, when libkrb5 needs to access
>> the credentials store. At the same time, the KCM responder must be
>> running if the Kerberos credentials cache defaults to `KCM`.
>> Socket-activating the responder would solve both of these cases.
>>
>>  autofs 
>> The autofs responder is typically only needed when a share is about to
>> be mounted.
>>
>> === Overview of the solution ===
>> The solution agreed on the mailing list is to add a new unit for each
>> one of the responders. Once a responder is started, it will
>> communicate to the monitor in order to let the monitor know that it's
>> up and the monitor will do the registration of the responder, which
>> basically consists in marking the service as started, increasing the
>> services' counter, getting the responder's configuratiom, adding the
>> responder to the service's list.
>> A configurable idle timeout will be implemented in each responder, as
>> part of this task, in order to exit the responder in case it's not
>> used for a few minutes.
>>
>> === Implementation details ===
>> In order to achieve our goal we will need a small modification in
>> responders' common code in order to make it ready for
>> socket-activation, add some systemd units for each of the responders
>> and finally small changes in the monitor code in order to manage the
>> new activated service.
>>
>> The change in the responders' common code is quite trivial, just
>> chnage the sss_process_init code to call activate_unix_sockets()
>> istead of set_unix_socket(). Something like:
>> {{{
>> -ret = set_unix_socket(rctx, conn_setup);
>> +ret = activate_unix_sockets(rctx, conn_setup);
>> }}}
>>
>> The units that have to be added for each responder must look like:
>>
>> sssd-@respon...@.service.in:
>> {{{
>> [Unit]
>> Description=SSSD @responder@ Service responder
>> Documentation=man:sssd.conf(5)
>> Requires=sssd.service
>> PartOf=sssd.service
>> After=sssd.service
>>
>> [Install]
>> Also=sssd-@responder@.socket
>>
>> [Service]
>> ExecStart=@libexecdir@/sssd/sssd_@responder@ --uid 0 --gid 0 --debug-to-files
>> }}}
>>
>> sssd-@respon...@.socket.in:
>> {{{
>> [Unit]
>> Description=SSSD @responder@ Service responder socket
>> Documentation=man:sssd.conf(5)
>>
>> [Socket]
>> ListenStream=@pipepath@/@responder@
>>
>> [Install]
>> WantedBy=sockets.target
>> }}}
>>
>> Some responders may have more than one socket, which is the case of
>> PAM, so another unit will be needed.
>>
>> sssd-@respon...@-priv.socket.in:
>> {{{
>> [Unit]
>> Description=SSSD @responder@ Service responder private socket
>> Documentation=man:sssd.conf(5)
>>
>> [Socket]
>> ListenStream=@pipepath@/private/@responder@
>>
>> [Install]
>> WantedBy=sockets.target
>> }}}
>>
>> Last but not least, the IFP responder doesn't have a socket. It's
>> going to be D-Bus 

[SSSD] Re: Watchdog in the monitor process

[Amit Kumar]

Make sense..
Killing itself is not proper design.
Even systemd(Init process, system manager) has task of Managing
services/daemons running on system included in duty list.


Thanks Much!!!
Amit Kumar

On Sun, Nov 6, 2016 at 10:51 PM, Jakub Hrozek <jhro...@redhat.com> wrote:

> Hi,
>
> Currently the watchdog is enabled for all sssd processes, including the
> main sssd process. I admit I only realised that now that I was looking into
> one user report where upgrading the sssd database during package update
> took so long that the watchdog eventually killed the sssd process..oops..
>
> So we can either relax the watchdog during operations that we know might
> take a very long time (like upgrading huge cache files) or remove it
> altogether. I’m leaning towards the second option and just don’t setup the
> watchdog at all.
>
> Does anyone see a reason to keep the watchdog for the monitor? I think the
> watchdog in the current form makes sense only for “worker” processes where
> the monitor listens for SIGCHLD signals and restarts the services. I think
> for the monitor process it would make more sense to leverage some systemd
> functionality rather than kill itself :-)
> ___
> 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] 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 <fiden...@redhat.com>
wrote:

> On Wed, Oct 26, 2016 at 8:51 PM, Jakub Hrozek <jhro...@redhat.com> 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] Re: Help : Tickets suitable for newcomers

[Amit Kumar]

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

How to get around?

Thanks Much!!!
Amit Kumar

On Wed, Oct 26, 2016 at 6:48 PM, Fabiano Fidêncio <fiden...@redhat.com>
wrote:

> Amit,
>
> On Wed, Oct 26, 2016 at 2:40 PM, Amit Kumar <amitk...@redhat.com> wrote:
> >
> > Hi,
> > https://fedorahosted.org/sssd/ticket/1372
> >
> > Is this ticket still valid?
> > Owned by:pcech
> > Opened 4 years ago Last modified 3 months ago
> >
> > Which tickets should be picked?
> >
> > 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
> >
>
> Firstly, thanks for your interest to hack on SSSD!
>
> The ticket is still valid. If you want to discuss something about it
> feel free to join #sssd channel at freenode (be patient there, please,
> answers don't come as fast as some people want to, but they eventually
> come at some point ;-)) or even ask your question in the ticket you
> have mentioned.
>
> Also, we have an "easy fixes" tag[0] in our trac with bugs that are
> suitable for newcomers. Again, if you want to discuss something about
> those bugs, feel free to contact us on #sssd or through the ticket
> itself.
>
> [0]: https://fedorahosted.org/sssd/query?status=assigned=
> new=reopened=~easyfix=id=summary&
> col=type=status=priority=milestone=
> component=priority=34
>
> 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] Help : Tickets suitable for newcomers

[Amit Kumar]

Hi,
https://fedorahosted.org/sssd/ticket/1372

Is this ticket still valid?
Owned by: pcech
<https://fedorahosted.org/sssd/query?status=!closed=pcech>
Opened 4 years
<https://fedorahosted.org/sssd/timeline?from=2012-06-10T13%3A58%3A48Z=second>
 ago Last modified 3 months
<https://fedorahosted.org/sssd/timeline?from=2016-08-04T06%3A44%3A06Z=second>
 ago

Which tickets should be picked?

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