[SSSD] Cannot start sssd from source [libsss_ldap_common.so: undefined symbol: ldap_tls_inplace]
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
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
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
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}
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}
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
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
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
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
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
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ênciowrote: >> 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
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
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
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
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