Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/20

• Created at 2009-04-15 19:10:29 by sgallagh
• Closed as Fixed
• Assigned to sgallagh

There are several components of the SSSD that will require translation, primarily in the command-line tools and --help parameters.

Once the conversion to using Automake is completed, we will be able to start implementing gettext for these strings.

Comments

Comment from sgallagh at 2009-04-27 13:51:02

Fields changed

owner: somebody => sgallagh

Comment from sgallagh at 2009-05-26 19:52:37

Work in progress, now that the automake conversion is complete.

status: new => assigned

Comment from sgallagh at 2009-05-28 20:50:21

Framework has been created for the sss_clients.

Still to do: SSSD server and tools.

Comment from sgallagh at 2009-06-17 15:09:42

The SSSD daemon has been updated for internationalization support.

Fixed in [ad4e495]

fixedin: => 0.5.0
milestone: SSSD 1.0 => Iteration 5
resolution: => fixed
status: assigned => closed
version: => 0.3.3

Comment from jgalipea at 2009-09-25 15:16:44

Fields changed

doc: => 0
docupdated: => 0
tests: => 1
testsupdated: => 0

Comment from dpal at 2012-01-19 02:11:07

Fields changed

rhbz: => 0

Comment from sgallagh at 2017-02-24 14:45:53

Metadata Update from @sgallagh:

• Issue assigned to sgallagh
• Issue set to the milestone: Iteration 5

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/5

• Created at 2009-03-17 15:55:29 by sgallagh
• Closed as Fixed
• Assigned to sgallagh

Currently, we only update the sysdb cache when the cache timeout has expired. This means that the client must wait until a cache refresh of the entry completes.

In order to reduce the frequency that we block the clients for refreshes, we will implement an out-of-band update. If the client requests data that is available in the cache, we will return it immediately; if the time between now and the timeout period is less than half of the timeout interval, we will trigger a cache update behind the scenes, so that the next time a request is made, the cache will be more recent.

In a busy system (requests are received at least twice as often as the cache times out), this will significantly reduce cache update delay.

In a slow system (requests are received less often than the cache timeout), there will be no difference between this approach and the current implementation.

The worst-case scenario (that of the busy system) is that we will make twice as many cache requests to the back-end provider.

Comments

Comment from simo at 2009-03-17 16:10:04

I'd like to see this as an optional feature and probably disabled by default.
If someone sees minor delays as a problem they may decide to turn this option up, but by default this would only generate more load on the system and more traffic on the network unnecessarily. IMO.

Comment from sgallagh at 2009-06-16 16:55:58

Deferred for future optimization.

fixedin: =>
milestone: Iteration 2 => Deferred

Comment from sgallagh at 2009-07-01 16:56:07

Fields changed

milestone: Deferred => Iteration 6

Comment from sgallagh at 2009-08-12 16:02:26

Fields changed

status: new => assigned

Comment from sgallagh at 2009-08-14 15:20:15

Marking this bug as a blocker to 0.5.0 release.

priority: major => blocker

Comment from sgallagh at 2009-08-17 17:25:25

We've determined that to do this job correctly requires some refactoring of the nsssrv_cmd.c functions. This is a bigger job than is feasible in the 0.5.0 schedule, so I'm dropping the priority. It will be fixed immediately after 0.5.0.

component: SSSD => Data Provider
priority: blocker => major

Comment from sgallagh at 2009-08-24 17:20:11

Fields changed

milestone: SSSD 0.5.0 => SSSD 0.6.0

Comment from sgallagh at 2009-09-09 16:42:40

Fixed in ab66a19

HOWTO and manpages have been updated to include references to the new EntryCacheNoWaitRefreshTimeout.

When testing this feature, it is important to do so with enumerate = false, as the enumeration processing will hide this enhancement.

doc: => 1
docupdated: => 1
fixedin: => 0.6.0
resolution: => fixed
status: assigned => closed
tests: => 1
testsupdated: => 0

Comment from dpal at 2012-01-19 02:16:07

Fields changed

rhbz: => 0

Comment from sgallagh at 2017-02-24 14:58:24

Metadata Update from @sgallagh:

• Issue assigned to sgallagh
• Issue set to the milestone: SSSD 0.6.0

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/33

• Created at 2009-04-30 17:40:01 by mnowak
• Closed as Invalid
• Assigned to nobody

On one of the NSS tests https://fedoraproject.org/wiki/Test_Day:2009-04-30_SSSD#NSS_Tests I received twice some sort of timeout:

dhcp-lab-124 ~ # getent group |grep nativelocaluser
[sssd] [ping_check] (0): A service PING returned an error [org.freedesktop.DBus.Error.NoReply], closing connection.
nativelocaluser:x:5000:
dhcp-lab-124 ~ # server_sort:Unable to register control with rootdse!
asq: Unable to register control with rootdse!
[sssd] [global_checks_handler] (0): Unknown child (11276) did exit

But second attempt worked.

sssd-0.3.2-2.fc11.x86_64

Comments

Comment from sgallagh at 2009-04-30 17:48:50

This may have been caused by the LDAP server taking too long to return the full list. Try uncommenting the timeout=60 line in the [domains/LDAP] section of the sssd.conf

Comment from sgallagh at 2009-05-28 20:24:12

Request for more information has gone unanswered for a month. Closing as WORKSFORME.

resolution: => worksforme
status: new => closed

Comment from dpal at 2012-01-19 02:22:46

Fields changed

rhbz: => 0

Comment from mnowak at 2017-02-24 14:41:34

Metadata Update from @mnowak:

• Issue set to the milestone: SSSD 1.0

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/7

• Created at 2009-03-18 14:17:55 by sgallagh
• Closed as Fixed
• Assigned to sgallagh

As the subject says, currently we do not return magic private groups for users in a domain that supports them when enumerating or searching for a group.

e.g. If we have user 'testuser1' in the LOCAL domain,

getent group |grep testuser1

returns no results. Neither does:

getent group testuser1

Comments

Comment from sgallagh at 2009-03-18 14:50:43

The problem is that the default settings for the LOCAL domain sets the value of magicPrivateGroups to '1' rather than 'TRUE', so it is not enabled.

Patch submitted for review.

owner: simo => sgallagh
status: new => assigned

Comment from sgallagh at 2009-03-18 17:00:22

Fixed by commit [dd4568a]

Changed the defaults to properly set magicPrivateGroups to 'TRUE'

resolution: => fixed
status: assigned => closed

Comment from dpal at 2012-01-19 02:21:56

Fields changed

rhbz: => 0

Comment from sgallagh at 2017-02-24 15:07:33

Metadata Update from @sgallagh:

• Issue assigned to sgallagh
• Issue set to the milestone: SSSD 1.0

It should be ocumented that domain_resolution_order should be preferred over 'default_domain_suffix'.
Perhaps 'default_domain_suffix' should be declared as "deprecated".

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/38

• Created at 2009-05-14 15:24:53 by jhrozek
• Closed as Fixed
• Assigned to sgallagh

With the current code in monitor.c, all providers are checked for the presence of "provider = " directive in the corresponding domain configuration. But there is no provider for LOCAL which results in some problems:

During startup, add_new_provider() fails and the LOCAL domain is not added to the list of active providers. This also manifests as the "[sssd] [add_new_provider] (0): Could not get provider configuration for [LOCAL]" error message.

During update of configuration, the LOCAL domain is found in the config file, but not in the old config, which makes the update_monitor_config function fail with "Service entry missing data".

The plan is probably to add a backend for LOCAL, or, at least in the meantime, special-case LOCAL domain.

Comments

Comment from sgallagh at 2009-05-14 18:01:02

After discussion with Simo, there is no reason to build a backend for LOCAL. We will instead treat LOCAL as a special case and ensure that it is properly included into the service list.

Assigning this bug to myself.

owner: somebody => sgallagh
status: new => assigned

Comment from sgallagh at 2009-05-26 14:26:05

Fixed in [d6b65c3]

milestone: SSSD 1.0 =>
resolution: => fixed
status: assigned => closed
version: 0.3.3 => 0.4

Comment from dpal at 2012-01-19 02:10:06

Fields changed

rhbz: => 0

Comment from jhrozek at 2017-02-24 14:36:34

Metadata Update from @jhrozek:

• Issue assigned to sgallagh

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/19

• Created at 2009-04-13 20:09:10 by sgallagh
• Closed as Invalid
• Assigned to simo

SSSD should have a config-file option to suppress the password field from NSS getpw* requests to a proxy back-end.

For example, NIS presents the encrypted password to anyone performing a getpwnam() call, but if we're using an NIS domain within SSSD, it should be possible to prevent outputting that field, despite the fact that the NIS server sends it to the SSSD.

Comments

Comment from simo at 2009-04-14 15:21:45

Have you tried using
store-legacy-passwords = FALSE ?

Comment from sgallagh at 2009-04-14 15:46:22

I haven't been able to reproduce this issue since I originally saw it. I think I may have been misconfigured. Closing as worksforme.

resolution: => worksforme
status: new => closed

Comment from dpal at 2012-01-19 02:09:35

Fields changed

rhbz: => 0

Comment from sgallagh at 2017-02-24 15:09:01

Metadata Update from @sgallagh:

• Issue assigned to simo

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/27

• Created at 2009-04-29 14:19:02 by zmraz
• Closed as Fixed
• Assigned to jhrozek

After first start of sssd I got ok and 0 exit code, but then appears lots of debug/error messages on concole. Shouldn't them be on the error log and thus init script end with fail?

[sssd] [add_new_provider] (0): Could not get provider configuration for [LOCAL]
server_sort:Unable to register control with rootdse!
server_sort:Unable to register control with rootdse!
server_sort:Unable to register control with rootdse!
server_sort:Unable to register control with rootdse!
asq: Unable to register control with rootdse!
asq: Unable to register control with rootdse!
asq: Unable to register control with rootdse!
server_sort:Unable to register control with rootdse!
asq: Unable to register control with rootdse!
server_sort:Unable to register control with rootdse!
asq: Unable to register control with rootdse!

Comments

Comment from sgallagh at 2009-04-29 14:26:39

These are erroneous error messages generated by libldb, one of our dependencies. They are not indicative of any failure in the SSSD, as we are not using the features they warn about.

Leaving this ticket open to find a way to suppress displaying these erroneous messages, but lowering the priority.

owner: somebody => simo
priority: major => minor

Comment from simo at 2009-04-30 15:33:59

I think we should address this in the initscripts for now and redirect stderr to a log file or to /dev/null
Once we will integrate the Event Logging API we will have means to redirect stuff by changing the configuration.

Reassigning to Jakub that is already working in the init scripts area.

owner: simo => jhrozek

Comment from jhrozek at 2009-05-10 22:09:05

Resolved in r4146c660af61cca7f3c4bcd89d810de1d34bae0a

resolution: => fixed
status: new => closed

Comment from dpal at 2012-01-19 02:22:23

Fields changed

rhbz: => 0

Comment from zmraz at 2017-02-24 14:33:33

Metadata Update from @zmraz:

• Issue assigned to jhrozek
• Issue set to the milestone: SSSD 1.0

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/4

• Created at 2009-03-17 15:49:50 by sgallagh
• Closed as Invalid
• Assigned to sgallagh

Currently, InfoPipe can only return data that has been previously cached in the sysdb. We need InfoPipe to be able to query the Data Provider and update the cache if it is out-of-date or not present.

Comments

Comment from sgallagh at 2009-05-26 19:50:59

InfoPipe will not be continuing in its current incarnation. Closing as WONTFIX.

resolution: => wontfix
status: new => closed

Comment from sgallagh at 2017-02-24 14:44:47

Metadata Update from @sgallagh:

• Issue assigned to sgallagh
• Issue set to the milestone: Iteration 2

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/9

• Created at 2009-03-19 16:23:06 by dwalsh
• Closed as Fixed
• Assigned to simo

This is going to use up a huge amount of screen realestate.

If I do ls -l in an 80 character terminal I do not want to see files owned

You are wasting valuable terminal space and giving the vast majority of users no added value.

-rw-rw-r--. 1 [email protected] [email protected] 9427 2009-03-16 16:37 NEWS
-rw-rw-r--. 1 [email protected] [email protected] 2043 2009-03-16 16:37 omf.make

Comments

Comment from simo at 2009-03-19 19:59:24

This is easier said than done.

The problem is: how do you distinguish user 'foobar' in /etc/passwd from user 'foobar' coming down from ldap ? (And you may have multiple ldap servers you get users from)

Now, as done in winbind, we have plans to allow for omitting the domain qualifier on the default backend, although it is really not ideal.

If we can always fully qualify the user name then you do not risk username collisions.

The problem reflects into login managers, what user do you try to login if you pass "foobar" at the login prompt ?

Comment from dwalsh at 2009-03-19 20:55:37

Well I think there should be a default domain for a machine. If I setup nssldap now, I don't see domains being returned. The default domain should not have an extension, just like I don't need to kinit [email protected], I only kinit dwalsh. I don't think you will make me specify my domain at login time, unless I am logging into a machine on a different domain. So UID owned by the default domain should not have the realm.

I can't imagine having to chown [email protected]:[email protected] foo

People will balk at this.

Comment from simo at 2009-03-19 21:21:51

Yes as said we have plans to provide a default domain option.

Yet the question of what to do if a local user conflict with a domain user persist.

One way is to test if a domain user conflicts with a local user and filter out the domain user.
The problem is what do you do if the local user is added after the domain user have been in use for some time ?
Right now nss will just return the first user found in getpwnam() and just duplicate users in getpwent() (same for groups), I guess I will just have to do the same ... although it really sucks (NSS that is).

Simo.

Comment from sgallagh at 2009-04-27 13:49:48

Fields changed

owner: somebody => simo

Comment from simo at 2009-04-30 15:31:52

Ok, forgot to close this ticket some time ago, we now have means to configure whether we want the user name fully qualified or not.

resolution: => fixed
status: new => closed

Comment from dpal at 2012-01-19 02:22:03

Fields changed

rhbz: => 0

Comment from dwalsh at 2017-02-24 14:56:16

Metadata Update from @dwalsh:

• Issue assigned to simo
• Issue set to the milestone: SSSD 1.0

Master branch should eventually drop support of libnss as a crypto backend.

Steps would be:
(I)

1. switch default to OpenSSL
2. warn about deprecation in the case NSS is selected during configuration
3. announce deprecation in the release notes of next upstream release

(II) finally remove support of libnss in (next+1) upstream release

A lot of packages require libsss_certmap.so without good reason.
This should be untangled.

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/24

• Created at 2009-04-22 14:39:12 by jhrozek
• Closed as Fixed
• Assigned to sgallagh

After every startup, sssd_nss segfaults, but reconnects and works fine after that because it starts before sssd_dp:

[sssd[nss]] [sbus_add_connection] (5): Adding connection 1DC0EB0
[sssd[nss]] [sbus_add_conn_watch] (5): 1DC1280: 11, 2=WRITE
[sssd[nss]] [sbus_new_connection] (1): Failed to open connection: name=org.freedesktop.DBus.Error.NoServer, message=Failed to connect to socket /var/lib/sss/pipes/private/sbus-dp: Connection refused
[sssd[nss]] [sss_dp_conn_reconnect] (4): Failed to reconnect [5(Input/output error)]!
[sssd[nss]] [sss_dp_conn_reconnect] (4): Retrying in 5 seconds

And after that:

[sssd[dp]] [sbus_new_server] (3): D-BUS Server listening on unix:path=/var/lib/sss/pipes/private/sbus-dp,guid=1bacb1008d25b3137903500a49eef2e7

I haven't been able to get a backtrace so far because I haven't been able to reproduce the race condition in gdb.

Is it a good idea to start the Data Provider service first, wait for the startup and then queue the other services asynchronously as we do now?

The other part of fix would of course be don't segfault NSS when reconnecting.

Comments

Comment from sgallagh at 2009-04-22 14:51:25

Fields changed

owner: somebody => sgallagh
status: new => assigned
version: 0.3.1 => 0.3.2

Comment from sgallagh at 2009-04-30 15:27:40

Fixed by commit [f7e3265]

resolution: => fixed
status: assigned => closed

Comment from dpal at 2012-01-19 02:09:43

Fields changed

rhbz: => 0

Comment from jhrozek at 2017-02-24 15:06:32

Metadata Update from @jhrozek:

• Issue assigned to sgallagh

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/10

• Created at 2009-03-24 19:56:42 by sgallagh
• Closed as Fixed
• Assigned to sgallagh

SBUS has a feature to enable reconnection to a D-BUS server when it goes away.

Allow the NSS Responder to reconnect to the Data Provider if the latter dies.

Comments

Comment from sgallagh at 2009-03-26 19:37:35

Fields changed

status: new => assigned

Comment from sgallagh at 2009-04-14 23:07:01

Fixed in commit [ecd4114]

milestone: Iteration 2 => Iteration 3
resolution: => fixed
status: assigned => closed

Comment from dpal at 2012-01-19 02:10:36

Fields changed

rhbz: => 0

Comment from sgallagh at 2017-02-24 14:31:19

Metadata Update from @sgallagh:

• Issue assigned to sgallagh
• Issue set to the milestone: Iteration 3

Pagure had these for verifying the release tarball, could github have them as well?

Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1827432

Description of problem:

When the /etc/passwd or /etc/group file is replaced by another file, sssd no longer monitors that file for inotify events, and reloads no longer occur when the files are modified.


When the file is modified in-place, the events are still received, and reloads still occur.


Version-Release number of selected component (if applicable):

	sssd-2.0.0-43.el8.x86_64


How reproducible:

	easy, see below


Steps to Reproduce:


	(the customer's use case included modifying with 'vi', however the following is a scriptable reproducer of the same)


run sssd with debugging to watch for when inotify events occur (debug-level 0x3400 appears to log all of the needed debug messages related to the inotify events):

	# /usr/sbin/sssd -i --logger=stderr --debug-level=0x3400 2>&1 | tee /var/tmp/out
	...


	# getent group g10000
	# echo "g10000:x:10000: >> /etc/group
	# getent group g10000
	g10000:x:10000:

(sssd reloads /etc/group)

	# cp /etc/group /etc/group.new
	# echo g10001:x:10001: >> /etc/group.tmp
	# mv -f /etc/group.tmp /etc/group

(sssd reloads /etc/group)

	# echo g10002:x:10002: >> /etc/group

(sssd does not reload /etc/group)


can also test with:
	# touch /etc/group
	(because no inotify watch exists for this file, no reload is triggered)


Actual results:

	/etc/group is not immediately reloaded


Expected results:

	/etc/group is reloaded when modified


Additional info:


To correct the bug, when the inotify watch on /etc detects that /etc/passwd or /etc/group has been replaced, the watch for the old inode needs to be removed, and a new watch should be added for the new file.


when the watched file is replaced, the following inotify events may be generated *for the watch on the replaced file*

	<Event dir=False mask=0x4 maskname=IN_ATTRIB name='' path=/etc/group pathname=/etc/group wd=1 >
	<Event dir=False mask=0x400 maskname=IN_DELETE_SELF name='' path=/etc/group pathname=/etc/group wd=1 >
	<Event dir=False mask=0x8000 maskname=IN_IGNORED name='' path=/etc/group pathname=/etc/group wd=1 >


and the following inotify events may be generated *for the watch on the /etc directory*

	<Event cookie=32102 dir=False mask=0x40 maskname=IN_MOVED_FROM name=group.new path=/etc pathname=/etc/group.new wd=1 >
	<Event cookie=32102 dir=False mask=0x80 maskname=IN_MOVED_TO name=group path=/etc pathname=/etc/group src_pathname=/etc/group.new wd=1 >
	<Event dir=False mask=0x20 maskname=IN_OPEN name=group path=/etc pathname=/etc/group wd=1 >
	<Event dir=False mask=0x1 maskname=IN_ACCESS name=group path=/etc pathname=/etc/group wd=1 >
	<Event dir=False mask=0x10 maskname=IN_CLOSE_NOWRITE name=group path=/etc pathname=/etc/group wd=1 >


currently only these events are enabled and received for the file:
	<Event dir=False mask=0x400 maskname=IN_DELETE_SELF name='' path=/etc/group pathname=/etc/group wd=1 >
	<Event dir=False mask=0x8000 maskname=IN_IGNORED name='' path=/etc/group pathname=/etc/group wd=1 >

and this event for the directory:
	<Event cookie=32102 dir=False mask=0x80 maskname=IN_MOVED_TO name=group path=/etc pathname=/etc/group wd=1 >

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/36

• Created at 2009-04-30 21:36:16 by jlaska
• Closed as Fixed
• Assigned to nobody

Testing with sssd-0.3.3-3.fc11.x86_64

Steps to reproduce

1. /etc/init.d/sssd status
   {{{sssd (pid 1977) is running...}}}

2. /etc/init.d/sssd stop
   {{{[sssd] [sig_term] (0): SIGTERM: killing children}}}

3. /etc/init.d/sssd status

Actual Result

{{{sssd dead but pid file exists}}}

Expected Result

{{{sssd is stopped}}}

Comments

Comment from jhrozek at 2009-05-14 15:27:43

This was closed in rb348e98e47d3ef287fed4d2e272bbf08540e0295

resolution: => fixed
status: new => closed

Comment from dpal at 2012-01-19 02:22:59

Fields changed

rhbz: => 0

Comment from jlaska at 2017-02-24 14:37:04

Metadata Update from @jlaska:

• Issue set to the milestone: SSSD 1.0

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/15

• Created at 2009-04-01 15:29:48 by sgallagh
• Closed as Fixed
• Assigned to simo

Attempting to perform NSS getpwname (getent passwd username@LDAPDOMAIN) results in a segmentation fault in the ldap back-end.

Comments

Comment from simo at 2009-04-01 15:44:20

The LDAP backend still does not support NSS queries, we still use the proxy+nss_ldap backend for that atm.
That shouldn't cause a segfault of course, I have sent a patch to the list that will avoid the segfaults.

status: new => assigned

Comment from simo at 2009-04-01 15:44:37

Fields changed

component: LDAP Provider => Data Provider
priority: major => critical

Comment from simo at 2009-04-13 15:12:13

I have separated auth and identity backend types, so this should not be possible anymore by design.

resolution: => fixed
status: assigned => closed

Comment from dpal at 2012-01-19 02:10:31

Fields changed

rhbz: => 0

Comment from sgallagh at 2017-02-24 14:59:47

Metadata Update from @sgallagh:

• Issue assigned to simo
• Issue set to the milestone: Iteration 2

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/28

• Created at 2009-04-29 14:49:05 by zmraz
• Closed as Fixed
• Assigned to jhrozek

Please use correct exit codes and status in sssd initscript according to LSB standarts. ( http://intranet.corp.redhat.com/ic/intranet/InitscriptsSpec.html )

Example:
[root@becks sssd]# service sssd start
Starting sssd: [ OK ]
[root@becks sssd]# [sssd] [confdb_init_db] (0): Parse error reading configuration file [/etc/sssd/sssd.conf]
Parsing errors and warnings in file: /etc/sssd/sssd.conf
Warning (5) on line 1: Equal sign is missing.
[sssd] [monitor_process_init] (0): ConfDB initialization has failed [Input/output error]

[root@becks sssd]# echo $?
0
[root@becks sssd]# ps -e | grep sss
[root@becks sssd]#

Comments

Comment from zmraz at 2009-04-29 14:50:04

Sorry for that formatting.

[root@becks sssd]# service sssd start
Starting sssd:                                             [  OK  ]
[root@becks sssd]# [sssd] [confdb_init_db] (0): Parse error reading configuration file [/etc/sssd/sssd.conf]
Parsing errors and warnings in file: /etc/sssd/sssd.conf
Warning (5) on line 1: Equal sign is missing.
[sssd] [monitor_process_init] (0): ConfDB initialization has failed [Input/output error]

[root@becks sssd]# echo $?
0
[root@becks sssd]# ps -e | grep sss
[root@becks sssd]#

Comment from sgallagh at 2009-04-29 15:11:12

Jakub, please take a look at this.

owner: somebody => jhrozek

Comment from jhrozek at 2009-05-26 16:20:12

The initscript issue was fixed in r3624d766f6098b998a6b60f89285f18faaf8dc61 but also this bug revealed more serious bugs concerning startup and daemonization (for instance r9df9359312ebb29e0a9b5c6db0cb0a195194f49e and rb348e98e47d3ef287fed4d2e272bbf08540e0295)

So thanks for the bug report!

resolution: => fixed
status: new => closed

Comment from dpal at 2012-01-19 02:22:32

Fields changed

rhbz: => 0

Comment from zmraz at 2017-02-24 14:32:42

Metadata Update from @zmraz:

• Issue assigned to jhrozek
• Issue set to the milestone: SSSD 1.0

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/29

• Created at 2009-04-29 14:59:57 by zmraz
• Closed as Fixed
• Assigned to sgallagh

If there is bad configuration file present (I had there some html content), while trying to start sssd, the bad database files are created and sssd is not started. When I change the conf file, sssd cannot start because of the bad db files. Why they are even created, when 1, there is bad conf file, 2, the sssd process does not even start.

The workaround can be to delete the bad created db files and start sssd with correct conf file again.

Comments

Comment from sgallagh at 2009-04-29 15:12:30

Assigning this to myself. I thought I prevented this from happening.

owner: somebody => sgallagh
priority: major => critical
status: new => assigned

Comment from simo at 2009-04-29 15:13:56

zmraz please attach your corrupted config file (and maybe the config.ldb that is generated) so that we can reproduce the issue

Comment from zmraz at 2009-04-29 15:23:17

Corrupted sssd.conf
sssd.conf

Comment from zmraz at 2009-04-29 15:24:23

Bad database file
config.ldb

Comment from zmraz at 2009-04-29 15:26:11

And I got this error after with correct sssd.conf (provided for testday)

[root@becks sssd]# service sssd start
server_sort:Unable to register control with rootdse!       [  OK  ]
[sssd] [confdb_create_base] (0): Failed to initialize DB (68,[Entry @ATTRIBUTES already exists]), aborting!

Comment from sgallagh at 2009-04-29 15:27:21

I have been able to reproduce the error. I will look into this immediately.

Comment from sgallagh at 2009-04-30 15:23:55

Fixed in commit [a3d6555]

resolution: => fixed
status: assigned => closed

Comment from dpal at 2012-01-19 02:22:35

Fields changed

rhbz: => 0

Comment from zmraz at 2017-02-24 15:00:08

Metadata Update from @zmraz:

• Issue assigned to sgallagh
• Issue set to the milestone: SSSD 1.0

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/25

• Created at 2009-04-22 15:32:45 by jhrozek
• Closed as Fixed
• Assigned to sbose

Scenario:
- create a LOCAL user via sss_useradd
- log in as the user and attempt to change the password as the user
- This will prompt you for your current password, enter a wrong password, then enter a new one
- sssd_pam will segfault, the user's prompt will say passwd: Permission denied

Backtrace attached.

Comments

Comment from jhrozek at 2009-04-22 15:33:05

sssd_pam backtrace
sssd_pam-PASSWORD.txt

Comment from sbose at 2009-04-23 10:00:37

Fixed by commit 46e41c1b8cf6fc03c827ceea011833ba47b45db7

resolution: => fixed
status: new => closed

Comment from dpal at 2012-01-19 02:09:50

Fields changed

rhbz: => 0

Comment from jhrozek at 2017-02-24 14:44:42

Metadata Update from @jhrozek:

• Issue assigned to sbose

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/22

• Created at 2009-04-16 18:15:51 by simo
• Closed as Fixed
• Assigned to simo

PAM just guesses the domain based on the string sent in from user space, but does not actually check the user exist nor finds out the right domain if multiple domains use non-fully qualified names.

Comments

Comment from simo at 2009-04-16 18:33:57

Fields changed

status: new => assigned
version: 0.3.0 => 0.3.1

Comment from simo at 2009-04-17 21:08:09

Fix pushed

resolution: => fixed
status: assigned => closed

Comment from dpal at 2012-01-19 02:22:14

Fields changed

rhbz: => 0

Comment from simo at 2017-02-24 15:02:52

Metadata Update from @Simo:

• Issue assigned to simo
• Issue set to the milestone: SSSD 1.0

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/8

• Created at 2009-03-18 14:40:10 by sgallagh
• Closed as Fixed
• Assigned to simo

Group definition:

dn: name=localtestgroup,cn=groups,cn=LOCAL,cn=sysdb
objectClass: group
name: localtestgroup
gidNumber: 1000
createTimestamp: 1237380469
member: name=myinfpuser225,cn=users,cn=LOCAL,cn=sysdb
distinguishedName: name=localtestgroup,cn=groups,cn=LOCAL,cn=sysdb

User definition:

dn: name=myinfpuser225,cn=users,cn=LOCAL,cn=sysdb
objectClass: user
name: myinfpuser225
uidNumber: 1001
gidNumber: 1001
fullName: INFP User
gecos: INFP User
homeDirectory: /home/myinfpuser
loginShell: /usr/infshell
createTimestamp: 1237380594
memberof: name=localtestgroup,cn=groups,cn=LOCAL,cn=sysdb
distinguishedName: name=myinfpuser225,cn=users,cn=LOCAL,cn=sysdb

Performing getgrnam behaves as expected:

[sgallagh@sgallagh sssd]$ getent group localtestgroup
localtestgroup:x:1000:myinfpuser225

Performing getgrent does not:

[sgallagh@sgallagh sssd]$ getent group|grep localtestgroup
localtestgroup@LOCAL:x@LOCAL:1000:user225

Comments

Comment from simo at 2009-03-27 15:56:36

Fixed last week

resolution: => fixed
status: new => closed

Comment from dpal at 2012-01-19 02:22:00

Fields changed

rhbz: => 0

Comment from sgallagh at 2017-02-24 15:09:13

Metadata Update from @sgallagh:

• Issue assigned to simo
• Issue set to the milestone: SSSD 1.0

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/34

• Created at 2009-04-30 18:26:01 by simo
• Closed as Invalid
• Assigned to simo

This error is thrown by sssd_nss:
[sssd[nss]] [nss_cmd_detgrgid_callback] (0): No matching domain found for [10056], fail!

In sssd.conf the domain named LDAP has range 10000-15000

Comments

Comment from sgallagh at 2009-06-02 22:14:09

Unable to reproduce. We believe this was fixed incidentally during other NSS work.

fixedin: => 0.4.0
resolution: => worksforme
status: new => closed

Comment from dpal at 2012-01-19 02:22:52

Fields changed

rhbz: => 0

Comment from simo at 2017-02-24 14:48:36

Metadata Update from @Simo:

• Issue assigned to simo
• Issue set to the milestone: SSSD 1.0

I'm having an issue getting a maprule to work properly. It looks like sssd isn't sanitizing certificate attributes prior to issuing the ldap search. In this example, parentheses in the Subject DN are causing an ldap search error "Bad search filter." At the end of the example, I show the Bad search filter result from sssd and a working ldapsearch with backslash-escaped parentheses.

Additionally, altSecurityIdentities in LDAP stores a space between UID (OID...) and CN. AD is able to find and match the certificate to user when the Certificate uses a + to separate these values. I don't know if this is a standard transformation or if sssd could support a user-configurable transformation like !ad for certain character adjustments?

The smartcard is an US Government HSPD-12/PIV card.

certificate (sssctl cert-show):

Issuer: OU=Entrust Managed Services SSP CA,OU=Certification Authorities,O=Entrust,C=US
Subject: UID=1337+CN=JOHN GALT (Affiliate),OU=Department of Authentication,O=U.S. Government,C=US

SAN type: ntPrincipalName
  [email protected]

LDAP:

altSecurityIdentities: X509:<I>C=US,O=Entrust,OU=Certification Authorities,OU=Entrust Managed Services SSP CA<S>C=US,O=U.S. Government,OU=Department of Authentication,OID.0.9.2342.19200300.100.1.1=1337 CN=JOHN GALT (Affiliate)

sssd.conf certmap:

[certmap/lol.gov/smartcard]
matchrule = <EKU>msScLogin<SAN:ntPrincipalName>^[0-9]+@FEDIDCARD\.GOV$
maprule = (altSecurityIdentities=X509:<I>{issuer_dn!ad}<S>{subject_dn!ad})
domains = lol.gov

sdap_attrs_add_ldap_attr:

Adding altSecurityIdentities [X509:<I>C=US,O=Entrust,OU=Certification\20Authorities,OU=Entrust\20Managed\20Services\20SSP\20CA<S>C=US,O=U.S.\20Government,OU=Department\20of\20Authentication,OID.0.9.2342.19200300.100.1.1=1337\20CN=JOHN\20GALT\20\28Affiliate\29] to attributes of [[email protected]].

sss-certmap ldap search:

[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(&(altSecurityIdentities=X509:<I>C=US,O=Entrust,OU=Certification Authorities,OU=Entrust Managed Services SSP CA<S>C=US,O=U.S. Government,OU=Department of Authentication,OID.0.9.2342.19200300.100.1.1=1337+CN=JOHN GALT (Affiliate))(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))(localAuthEnabled=TRUE))] [ou=linux,dc=lol,dc=gov].
[sdap_get_generic_ext_step] (0x0080): ldap_search_ext failed: Bad search filter

ldapsearch (working):

ldapsearch -x -b ou=linux,dc=lol,dc=gov '(&(&(altSecurityIdentities=X509:<I>C=US,O=Entrust,OU=Certification Authorities,OU=Entrust Managed Services SSP CA<S>C=US,O=U.S. Government,OU=Department of Authentication,OID.0.9.2342.19200300.100.1.1=1337 CN=JOHN GALT \(Affiliate\))(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))(localAuthEnabled=TRUE))'

Steps to Reproduce:

[nss]
filter_groups = root
filter_users = root, admin

$ id admin
id: ‘admin’: no such user
-- as expected, user 'admin' is filtered out

$ adduser test

$ id admin
uid=1389800000(admin) gid=1389800000(admins) groups=1389800000(admins)
-- user is not filtered anymore.

Initially reported as: https://bugzilla.redhat.com/show_bug.cgi?id=1824323

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/12

• Created at 2009-03-24 20:40:48 by sgallagh
• Closed as Fixed
• Assigned to sgallagh

responder_cmd.h has an implementation of nss_ctx that varies from nss_ctx in nsssrv.h.

It is inappropriate for responder_cmd.h to be using an nss_ctx anyway. It should really be a responder_ctx. sss_process_init() should be updated similarly.

Comments

Comment from sgallagh at 2009-03-24 20:46:27

Fields changed

status: new => assigned

Comment from sgallagh at 2009-03-26 19:36:25

Fixed by commit [a5ce26e]

resolution: => fixed
status: assigned => closed

Comment from dpal at 2012-01-19 02:22:10

Fields changed

rhbz: => 0

Comment from sgallagh at 2017-02-24 14:21:42

Metadata Update from @sgallagh:

• Issue assigned to sgallagh
• Issue set to the milestone: SSSD 1.0

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/18

• Created at 2009-04-10 15:41:43 by sgallagh
• Closed as Fixed
• Assigned to dpal

The INI parser can read in an INI file and it can retrieve specific entries from a section, but it needs two additional features urgently.

In a config file, there will not always be a fixed number of sections, so we need a function to return an array of strings listing all the section names present in the collection.

Furthermore, there will not always be a fixed number of attributes present in a particular setting (for example, in the SSSD we will only include the "command" attribute for a service if we want to call a binary other than the default)

So we need:

inicfg_get_sections(struct collection_item *ini_config,
                    char ***section_array, int *section_count);

inicfg_get_attributes(struct collection_item *ini_config,
                      const char *section,
                      char ***attributes, int *attr_count);

Comments

Comment from sgallagh at 2009-04-10 16:00:20

Fields changed

description: The INI parser can read in an INI file and it can retrieve specific entries from a section, but it needs two additional features urgently.

In a config file, there will not always be a fixed number of sections, so we need a function to return an array of strings listing all the section names present in the collection.

Furthermore, there will not always be a fixed number of attributes present in a particular setting (for example, in the SSSD we will only include the "command" attribute for a service if we want to call a binary other than the default)

So we need:
inicfg_get_sections(struct collection_item *ini_config,
char ***section_array, int *section_count);

inicfg_get_attributes(struct collection_item *ini_config,
const char *section,
char ***attributes, int *attr_count); => The INI parser can read in an INI file and it can retrieve specific entries from a section, but it needs two additional features urgently.

In a config file, there will not always be a fixed number of sections, so we need a function to return an array of strings listing all the section names present in the collection.

Furthermore, there will not always be a fixed number of attributes present in a particular setting (for example, in the SSSD we will only include the "command" attribute for a service if we want to call a binary other than the default)

So we need:
{{{
inicfg_get_sections(struct collection_item *ini_config,
char ***section_array, int *section_count);

inicfg_get_attributes(struct collection_item *ini_config,
const char *section,
char ***attributes, int *attr_count);
}}}

Comment from dpal at 2009-04-10 17:35:33

Fields changed

status: new => assigned

Comment from dpal at 2009-04-13 18:30:54

Functions have been provided.

resolution: => fixed
status: assigned => closed

Comment from sgallagh at 2009-04-13 18:59:46

Fixed in commit [24967bd]

Comment from dpal at 2012-01-19 02:11:03

Fields changed

rhbz: => 0

Comment from sgallagh at 2017-02-24 15:03:36

Metadata Update from @sgallagh:

• Issue assigned to dpal
• Issue set to the milestone: Iteration 3

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/14

• Created at 2009-03-27 15:56:21 by sgallagh
• Closed as Fixed
• Assigned to sgallagh

Discussions with administrators have resulted in a decision to convert from using the confdb (with ldb-tools) to .ini files for configuration.

We will be retaining the confdb interface internally, but we need to read in (and be notified on changes to) a configuration file.

Comments

Comment from sgallagh at 2009-03-27 15:57:21

Notes for implementation:
Include a 1-2 second delay before rereading the configuration so that multiple sequential changes do not trigger multiple signals to reconfigure.

status: new => assigned

Comment from sgallagh at 2009-04-13 15:12:31

Fixed by commit [4626af1]

milestone: SSSD 1.0 => Iteration 3
resolution: => fixed
status: assigned => closed

Comment from dpal at 2012-01-19 02:10:54

Fields changed

rhbz: => 0

Comment from sgallagh at 2017-02-24 14:43:45

Metadata Update from @sgallagh:

• Issue assigned to sgallagh
• Issue set to the milestone: Iteration 3

Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1800564 and https://bugzilla.redhat.com/show_bug.cgi?id=1829470

sssd.api.conf and sssd.api.d/* are only used by python-sssdconfig, not by sssd-common they currently belong to.

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/17

• Created at 2009-04-10 15:21:01 by sgallagh
• Closed as Fixed
• Assigned to dpal

If the config file to be parsed does not exist, config_from_file should return ENOENT and leave it up to the calling function whether this should be treated as an error.

Currently, config_from_file returns an empty collection instead.

Comments

Comment from sgallagh at 2009-04-10 15:27:07

Addendum: the returned error_list should also report that the file was not found if print_file_parsing_errors is called.

Comment from sgallagh at 2009-04-10 15:27:07

Addendum: the returned error_list should also report that the file was not found if print_file_parsing_errors is called.

Comment from sgallagh at 2009-04-10 15:27:07

Addendum: the returned error_list should also report that the file was not found if print_file_parsing_errors is called.

Comment from dpal at 2009-04-10 19:21:40

Fields changed

status: new => assigned

Comment from dpal at 2009-04-10 19:21:40

Fields changed

status: new => assigned

Comment from dpal at 2009-04-10 19:21:40

Fields changed

status: new => assigned

Comment from dpal at 2009-04-10 19:23:05

I do not agree with the addendum: this is not a file parsing error. It should not be a part of the error list.

Comment from dpal at 2009-04-10 19:23:05

I do not agree with the addendum: this is not a file parsing error. It should not be a part of the error list.

Comment from dpal at 2009-04-10 19:23:05

I do not agree with the addendum: this is not a file parsing error. It should not be a part of the error list.

Comment from dpal at 2009-04-13 18:30:16

The main issue was fixed. [[BR]]
Steve agreed that the requirement mentioned in the addendum is not the right expectation.

resolution: => fixed
status: assigned => closed

Comment from dpal at 2009-04-13 18:30:16

The main issue was fixed. [[BR]]
Steve agreed that the requirement mentioned in the addendum is not the right expectation.

resolution: => fixed
status: assigned => closed

Comment from dpal at 2009-04-13 18:30:16

The main issue was fixed. [[BR]]
Steve agreed that the requirement mentioned in the addendum is not the right expectation.

resolution: => fixed
status: assigned => closed

Comment from sgallagh at 2009-04-13 18:58:40

Fixed in commit [b531c18]

Comment from sgallagh at 2009-04-13 18:58:40

Fixed in commit [b531c18]

Comment from sgallagh at 2009-04-13 18:58:40

Fixed in commit [b531c18]

Comment from dpal at 2012-01-19 02:10:59

Fields changed

rhbz: => 0

Comment from dpal at 2012-01-19 02:10:59

Fields changed

rhbz: => 0

Comment from dpal at 2012-01-19 02:10:59

Fields changed

rhbz: => 0

Comment from sgallagh at 2017-02-24 14:55:16

Metadata Update from @sgallagh:

• Issue assigned to dpal
• Issue set to the milestone: Iteration 3

Comment from sgallagh at 2017-03-01 16:08:40

Metadata Update from @sgallagh:

• Issue set to the milestone: void (was: Iteration 3)

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/31

• Created at 2009-04-30 16:07:01 by sgallagh
• Closed as Fixed
• Assigned to sbose

If there is no TLS CA Cert available for communication with the LDAP server (or /etc/ldap.conf has "ssl off"), SSSD will not authenticate.

Comments

Comment from sbose at 2009-06-15 16:25:20

This was fixed with commit e7514de. The option tls_reqcert for the native LDAP backend can be used in the same way as the corresponding option from /etc/ldap.conf

fixedin: => 0.4.0
resolution: => fixed
status: new => closed

Comment from dpal at 2012-01-19 02:22:39

Fields changed

rhbz: => 0

Comment from sgallagh at 2017-02-24 14:49:23

Metadata Update from @sgallagh:

• Issue assigned to sbose
• Issue set to the milestone: SSSD 1.0

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/1

• Created at 2009-03-17 14:30:45 by sgallagh
• Closed as Fixed
• Assigned to sgallagh

Start sssd with -d 4 (or higher). Watch until the ping interval occurs. You should see all of the configured components pinged at the same time.

Now, kill one of them with a SIGTERM (I killed the Data Provider). It will automatically restart.

Watch the output in the console. It will be pinged once with all of the other services, and again at a different time. Kill it again and you will see three pings, etc.

We need to ensure that we remove the original ping request when restarting the service, else in a very long-running situation we could end up wasting a lot of time processing pings.

Comments

Comment from sgallagh at 2009-03-17 15:11:03

Fields changed

component: component1 => Service Monitor

Comment from sgallagh at 2009-03-27 13:39:45

Fixed by commit [403c91f]

resolution: => fixed
status: new => closed

Comment from dpal at 2012-01-19 02:08:39

Fields changed

rhbz: => 0

Comment from sgallagh at 2017-02-24 15:07:08

Metadata Update from @sgallagh:

• Issue assigned to sgallagh

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/32

• Created at 2009-04-30 17:38:41 by simo
• Closed as Fixed
• Assigned to sbose

We need to capture auth problem in /var/log/secure so that admins have a clue about why auth is failing.

Long term, might get fixed easily when we integrate ELAPI

Comments

Comment from sgallagh at 2009-06-12 13:31:56

Fields changed

fixedin: =>
owner: somebody => sbose

Comment from jgalipea at 2009-08-14 20:22:10

Fields changed

priority: major => critical

Comment from sgallagh at 2009-08-14 21:49:15

Moving to bugfix-only development until after 0.5.0. Lowering priority.

priority: critical => major
version: 1.0 => 0.4.1

Comment from sbose at 2009-08-31 15:30:28

fixed with 697733a

resolution: => fixed
status: new => closed

Comment from sgallagh at 2009-09-01 16:52:03

Fields changed

doc: => 0
docupdated: => 0
fixedin: => 0.6.0
tests: => 0
testsupdated: => 0

Comment from jgalipea at 2009-09-22 17:56:42

Fields changed

tests: 0 => 1

Comment from jgalipea at 2009-09-23 16:11:39

I am not seeing auth failures in /var/log/messages?

Comment from sgallagh at 2009-09-24 13:40:48

Fields changed

resolution: fixed =>
status: closed => reopened

Comment from sgallagh at 2009-09-24 13:41:51

We are going to handle this differently in the short-term.

For right now, we will add an option to write debug information to debug logs (specifiable in the sssd.conf).

Sorry, but this will change your tests.

owner: sbose => jhrozek
status: reopened => new

Comment from sbose at 2009-09-24 13:54:44

I think we have a double misunderstanding here. jgalipea was looking for messages from pam_sss in /var/log/messages, but they appear in /var/log/secure, because pam_sss logs with LOG_AUTHPRIV. This bug is not related to the debug information written by the sssd components.

Comment from sgallagh at 2009-09-24 13:59:00

Ah, my mistake. I misunderstood.

owner: jhrozek => sbose

Comment from sgallagh at 2009-09-24 13:59:29

Jenny, you need to parse /var/log/secure for these messages instead of /var/log/messages.

resolution: => fixed
status: new => closed

Comment from jgalipea at 2009-10-07 22:01:21

adding check for authentication failure messages in /var/log/secure for permission denied automated authentication tests.

tests: 1 => 0

Comment from jgalipea at 2009-10-08 15:33:07

Fields changed

testsupdated: 0 => 1

Comment from dpal at 2012-01-19 02:22:42

Fields changed

rhbz: => 0

Comment from simo at 2017-02-24 14:36:45

Metadata Update from @Simo:

• Issue assigned to sbose
• Issue set to the milestone: SSSD 1.0

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/11

• Created at 2009-03-24 19:57:13 by sgallagh
• Closed as Fixed
• Assigned to sgallagh

SBUS has a feature to enable reconnection to a D-BUS server when it goes away.

Allow the PAM Responder to reconnect to the Data Provider if the latter dies.

Comments

Comment from sgallagh at 2009-03-24 20:02:10

Working on this bug.

Fixing copy-paste error in the summary.

status: new => assigned
summary: Implement auto-reconnection of the NSS Responder to the Data Provider => Implement auto-reconnection of the PAM Responder to the Data Provider

Comment from sgallagh at 2009-03-26 19:37:09

Fixed by commit [0793b52]

resolution: => fixed
status: assigned => closed

Comment from dpal at 2012-01-19 02:10:26

Fields changed

rhbz: => 0

Comment from sgallagh at 2017-02-24 14:53:28

Metadata Update from @sgallagh:

• Issue assigned to sgallagh
• Issue set to the milestone: Iteration 2

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/16

• Created at 2009-04-02 16:43:19 by sgallagh
• Closed as Fixed
• Assigned to sgallagh

We need to convert to using Automake to prepare for the use of gettext.

Comments

Comment from sgallagh at 2009-04-02 17:16:29

Fields changed

status: new => assigned

Comment from sgallagh at 2009-05-13 13:38:19

Import libreplace macro files into server tree
0003-Import-libreplace-macro-files-into-server-tree.patch

Comment from sgallagh at 2009-05-13 13:39:09

Convert SSSD to Automake build system
0004-Convert-SSSD-to-Automake-build-system.patch

Comment from sgallagh at 2009-05-26 14:24:31

As of version 0.4.0, we are building using Automake. There are a few remaining bugs, but those will be addressed each in their own ticket, so marking this as fixed.

milestone: Iteration 2 =>
resolution: => fixed
status: assigned => closed
version: 0.3.0 => 0.4

Comment from dpal at 2012-01-19 02:09:31

Fields changed

rhbz: => 0

Comment from sgallagh at 2017-02-24 15:08:11

Metadata Update from @sgallagh:

• Issue assigned to sgallagh

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/21

• Created at 2009-04-16 15:38:50 by sgallagh
• Closed as Fixed
• Assigned to simo

My sssd.conf (erroneously) had the following ranges set:
LOCAL: 500 - 5000
LEGACYLOCAL: 5000 - 10000

I created a new user "localuser" in the LOCAL domain. It received UID 5000.
I logged in as this user using "su - localuser" and ran the command "whoami"

"whoami: cannot find name for user ID 5000"

I examined the SSSD logs and saw this:

[sssd[nss]] [accept_fd_handler] (4): Client connected!
[sssd[nss]] [nss_cmd_getpwuid] (4): Requesting info for [5000@LOCAL]
[sssd[nss]] [nss_cmd_getpwuid] (4): Requesting info for [5000@LEGACYLOCAL]
[sssd[nss]] [nss_cmd_getpwuid] (4): Uid [5000] does not exist in domain [LDAP]! (id out of range)
[sssd[nss]] [nss_cmd_getpwuid] (4): Uid [5000] does not exist in domain [PRIVATELDAP]! (id out of range)
[sssd[nss]] [nss_dp_send_acct_req] (4): Sending request for [LEGACYLOCAL][1][core][idnumber=5000]
[sssd[nss]] [nss_cmd_getpwuid_callback] (2): No results for getpwuid call
[sssd[nss]] [client_recv] (5): Client disconnected!
[sssd[nss]] [sbus_conn_read_write_handler] (6): Connection is open for read/write.
[sssd[nss]] [sbus_dispatch] (6): conn: 1E96DD0
[sssd[nss]] [sbus_dispatch] (6): Dispatching.

When I corrected the overlap in the configuration, the user was detected properly, however it appears to be a bug that the getpwuid routine continues searching subsequent domains once it finds a valid user. Apparently here, it checked the LOCAL domain, found it, then checked the LEGACYLOCAL domain and overwrote the results.

Comments

Comment from sgallagh at 2009-04-16 15:42:59

Fields changed

description: My sssd.conf (erroneously) had the following ranges set:
LOCAL: 500 - 5000
LEGACYLOCAL: 5000 - 10000

I created a new user "localuser" in the LOCAL domain. It received UID 5000.
I logged in as this user using "su - localuser" and ran the command "whoami"
"whoami: cannot find name for user ID 5000"

I examined the SSSD logs and saw this:

[sssd[nss]] [accept_fd_handler] (4): Client connected!
[sssd[nss]] [nss_cmd_getpwuid] (4): Requesting info for [5000@LOCAL]
[sssd[nss]] [nss_cmd_getpwuid] (4): Requesting info for [5000@LEGACYLOCAL]
[sssd[nss]] [nss_cmd_getpwuid] (4): Uid [5000] does not exist in domain [LDAP]! (id out of range)
[sssd[nss]] [nss_cmd_getpwuid] (4): Uid [5000] does not exist in domain [PRIVATELDAP]! (id out of range)
[sssd[nss]] [nss_dp_send_acct_req] (4): Sending request for [LEGACYLOCAL][1][core][idnumber=5000]
[sssd[nss]] [nss_cmd_getpwuid_callback] (2): No results for getpwuid call
[sssd[nss]] [client_recv] (5): Client disconnected!
[sssd[nss]] [sbus_conn_read_write_handler] (6): Connection is open for read/write.
[sssd[nss]] [sbus_dispatch] (6): conn: 1E96DD0
[sssd[nss]] [sbus_dispatch] (6): Dispatching.

When I corrected the overlap in the configuration, the user was detected properly, however it appears to be a bug that the getpwuid routine continues searching subsequent domains once it finds a valid user. Apparently here, it checked the LOCAL domain, found it, then checked the LEGACYLOCAL domain and overwrote the results. => My sssd.conf (erroneously) had the following ranges set:
LOCAL: 500 - 5000
LEGACYLOCAL: 5000 - 10000

I created a new user "localuser" in the LOCAL domain. It received UID 5000.
I logged in as this user using "su - localuser" and ran the command "whoami"

"whoami: cannot find name for user ID 5000"

I examined the SSSD logs and saw this:
{{{
[sssd[nss]] [accept_fd_handler] (4): Client connected!
[sssd[nss]] [nss_cmd_getpwuid] (4): Requesting info for [5000@LOCAL]
[sssd[nss]] [nss_cmd_getpwuid] (4): Requesting info for [5000@LEGACYLOCAL]
[sssd[nss]] [nss_cmd_getpwuid] (4): Uid [5000] does not exist in domain [LDAP]! (id out of range)
[sssd[nss]] [nss_cmd_getpwuid] (4): Uid [5000] does not exist in domain [PRIVATELDAP]! (id out of range)
[sssd[nss]] [nss_dp_send_acct_req] (4): Sending request for [LEGACYLOCAL][1][core][idnumber=5000]
[sssd[nss]] [nss_cmd_getpwuid_callback] (2): No results for getpwuid call
[sssd[nss]] [client_recv] (5): Client disconnected!
[sssd[nss]] [sbus_conn_read_write_handler] (6): Connection is open for read/write.
[sssd[nss]] [sbus_dispatch] (6): conn: 1E96DD0
[sssd[nss]] [sbus_dispatch] (6): Dispatching.
}}}
When I corrected the overlap in the configuration, the user was detected properly, however it appears to be a bug that the getpwuid routine continues searching subsequent domains once it finds a valid user. Apparently here, it checked the LOCAL domain, found it, then checked the LEGACYLOCAL domain and overwrote the results.

Comment from simo at 2009-04-16 18:33:35

Fields changed

resolution: => fixed
status: new => closed
version: => 0.3.1

Comment from dpal at 2012-01-19 02:09:38

Fields changed

rhbz: => 0

Comment from sgallagh at 2017-02-24 14:52:41

Metadata Update from @sgallagh:

• Issue assigned to simo

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/13

• Created at 2009-03-27 13:44:18 by sgallagh
• Closed as Fixed
• Assigned to sgallagh

Currently, SSSD services read in their configuration at startup and must be shut down and restarted in order to adopt new configuration values.

Instead, we should be able to trigger an on-demand reload of the configuration live, so that there is no interruption in services.

Comments

Comment from sgallagh at 2009-03-27 13:44:56

Working on the monitor first.

status: new => assigned

Comment from sgallagh at 2009-04-13 15:09:49

Fixed in commit [baf568c]

milestone: Iteration 2 => Iteration 3
resolution: => fixed
status: assigned => closed

Comment from dpal at 2012-01-19 02:10:40

Fields changed

rhbz: => 0

Comment from sgallagh at 2017-02-24 14:37:44

Metadata Update from @sgallagh:

• Issue assigned to sgallagh
• Issue set to the milestone: Iteration 3

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/37

• Created at 2009-05-14 14:55:16 by sgallagh
• Closed as Fixed
• Assigned to dpal

The INI Parser API should be opaque as to what its internal storage looks like. Instead of returning collection_items, it should be returning opaque ini_config_items (probably a typedef for collection_item, internally).

Furthermore, there should be a free_ini_config() function that acts as a wrapper around delete_collection.

This will give us more flexibility in the future if we decide to change the underlying data type from "collection" to something else.

Comments

Comment from dpal at 2009-07-15 00:06:04

The wrappers were created:
commit 09c4b07

After discussion we decided not to hide the "struct collection_item *" from the caller so this part won't be fixed.

fixedin: => 0.5.0
resolution: => fixed
status: new => closed

Comment from dpal at 2009-07-15 00:06:04

The wrappers were created:
commit 09c4b07

After discussion we decided not to hide the "struct collection_item *" from the caller so this part won't be fixed.

fixedin: => 0.5.0
resolution: => fixed
status: new => closed

Comment from dpal at 2009-07-15 00:06:04

The wrappers were created:
commit 09c4b07

After discussion we decided not to hide the "struct collection_item *" from the caller so this part won't be fixed.

fixedin: => 0.5.0
resolution: => fixed
status: new => closed

Comment from dpal at 2012-01-19 02:10:02

Fields changed

rhbz: => 0

Comment from dpal at 2012-01-19 02:10:02

Fields changed

rhbz: => 0

Comment from dpal at 2012-01-19 02:10:02

Fields changed

rhbz: => 0

Comment from sgallagh at 2017-02-24 14:29:15

Metadata Update from @sgallagh:

• Issue assigned to dpal

Comment from sgallagh at 2017-03-01 16:08:01

Metadata Update from @sgallagh:

• Issue set to the milestone: void

The line I'm referring to:

It uses 'SSSDBG_MINOR_FAILURE', which means this is already seen at debug level 3. In some environments this is triggered very regularly and therefore I'd believe this should be moved to debug level 5 (using 'SSSDBG_FUNC_DATA') instead.

Or is this really a minor failure and one should investigate this closer and if so, what exactly?

Thanks!

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/35

• Created at 2009-04-30 21:29:30 by jlaska
• Closed as Invalid
• Assigned to jhrozek

While testing https://fedorahosted.org/sssd/wiki/Fedora_11_Test_Day/PAM_Local_Native using sssd-0.3.3-3.fc11.x86_64, and executing step#5 to create a local user, I get the following error:

# useradd validlocaluser -u 4999
[sssd[nss]] [nss_cmd_getpwuid_callback] (0): No matching domain found for [4999], fail!
[sssd[nss]] [nss_cmd_getgrgid_callback] (0): No matching domain found for [4999], fail!

Also interesting, after observing the above message I:

1. attempt to useradd again, this fails as expected

2. attempt to userdel, this passed as expected

3. attempt to useradd, this fails ... unexpected

   useradd validlocaluser -u 4999

   useradd: user validlocaluser exists

   userdel -r validlocaluser

   useradd validlocaluser -u 4999

   useradd: user validlocaluser exists

   getent passwd validlocaluser

   validlocaluser:x:4999:4999::/home/validlocaluser:/bin/bash

Comments

Comment from sgallagh at 2009-05-26 17:47:11

Jakub, would you mind having a look at this?

owner: somebody => jhrozek

Comment from sgallagh at 2009-06-02 22:14:27

Unable to reproduce. We believe this was fixed incidentally during other NSS work.

fixedin: => 0.4.0
resolution: => worksforme
status: new => closed

Comment from dpal at 2012-01-19 02:22:55

Fields changed

rhbz: => 0

Comment from jlaska at 2017-02-24 14:50:05

Metadata Update from @jlaska:

• Issue assigned to jhrozek
• Issue set to the milestone: SSSD 1.0

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/6

• Created at 2009-03-18 13:38:09 by sgallagh
• Closed as Invalid
• Assigned to simo

I created a user using the !InfoPipe !CreateUser interface. Its internal representation in the LDB is:

dn: name=myinfpuser225,cn=users,cn=LOCAL,cn=sysdb
objectClass: user
name: myinfpuser225
uidNumber: 1011
gidNumber: 1011
fullName: INFP User
homeDirectory: /home/myinfpuser
loginShell: /usr/infshell
createTimestamp: 1236694637
distinguishedName: name=myinfpuser225,cn=users,cn=LOCAL,cn=sysdb

When I run 'getent passwd myinfpuser225' I get back:

er225@LOCAL:x:1011:1852406125::/home/myinfpuser:/usr/infshell

Comments

Comment from sgallagh at 2009-03-18 13:40:17

Reformatting summary using WikiText for readibility.

description: I created a user using the InfoPipe CreateUser interface. Its internal representation in the LDB is:
dn: name=myinfpuser225,cn=users,cn=LOCAL,cn=sysdb
objectClass: user
name: myinfpuser225
uidNumber: 1011
gidNumber: 1011
fullName: INFP User
homeDirectory: /home/myinfpuser
loginShell: /usr/infshell
createTimestamp: 1236694637
distinguishedName: name=myinfpuser225,cn=users,cn=LOCAL,cn=sysdb

When I run 'getent passwd myinfpuser225' I get back:
er225@LOCAL:x:1011:1852406125::/home/myinfpuser:/usr/infshell
=> I created a user using the !InfoPipe !CreateUser interface. Its internal representation in the LDB is:
{{{
dn: name=myinfpuser225,cn=users,cn=LOCAL,cn=sysdb
objectClass: user
name: myinfpuser225
uidNumber: 1011
gidNumber: 1011
fullName: INFP User
homeDirectory: /home/myinfpuser
loginShell: /usr/infshell
createTimestamp: 1236694637
distinguishedName: name=myinfpuser225,cn=users,cn=LOCAL,cn=sysdb
}}}
When I run 'getent passwd myinfpuser225' I get back:
{{{
er225@LOCAL:x:1011:1852406125::/home/myinfpuser:/usr/infshell
}}}

Comment from simo at 2009-03-18 13:47:02

You used a pre-1.2.0 nss client with a new sssd daemon.
That kind of stuff happens because your client is still expecting some calues to be 64 bit in length when they are 32 bit.
Make sure you install all components from the same build.

Comment from sgallagh at 2009-03-18 13:56:41

Simo was correct. I was running with the wrong NSS client library. Closing this bug as WORKSFORME.

resolution: => worksforme
status: new => closed

Comment from dpal at 2012-01-19 02:21:52

Fields changed

rhbz: => 0

Comment from sgallagh at 2017-02-24 14:54:43

Metadata Update from @sgallagh:

• Issue assigned to simo
• Issue set to the milestone: SSSD 1.0

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/39

• Created at 2009-05-25 16:25:58 by jhrozek
• Closed as Fixed
• Assigned to sgallagh

Upon start, sssd errors out on libsss_proxy.so with this error message:

[sssd[be[proxy]]] [load_id_backend] (0): Unable to load proxy module with path (/usr/lib64/sssd/libsss_proxy.so), error: /usr/lib64/sssd/libsss_proxy.so: undefined symbol: s3crypt_gen_salt
[sssd[be[proxy]]] [be_process_init] (0): fatal error initializing data providers
[sssd[be[proxy]]] [main] (0): Could not initialize backend [79]

This is a clean SSSD checkout with proxy domain defined as:

[domains/LEGACYLOCAL]
description = LOCAL migration domain
enumerate = 3 
minId = 500 
maxId = 4999
magicPrivateGroups = FALSE
legacy = TRUE

provider = proxy
libName = files
libPath = libnss_files.so.2

Comments

Comment from jhrozek at 2009-05-25 18:25:46

18:24 < simo_> jhrozek, please assign to sgallagh with critical priority

owner: somebody => sgallagh
priority: major => critical

Comment from simo at 2009-05-25 18:26:34

Fields changed

priority: critical => blocker
version: 0.3.1 => 0.4

Comment from sgallagh at 2009-05-26 14:26:29

Fields changed

status: new => assigned

Comment from sgallagh at 2009-05-26 17:37:43

Fixed in [260425e]

resolution: => fixed
status: assigned => closed

Comment from dpal at 2012-01-19 02:23:03

Fields changed

rhbz: => 0

Comment from jhrozek at 2017-02-24 14:47:23

Metadata Update from @jhrozek:

• Issue assigned to sgallagh
• Issue set to the milestone: SSSD 1.0

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/40

• Created at 2009-05-26 17:41:26 by simo
• Closed as Fixed
• Assigned to sgallagh

The current build process is way too verbose it simply hides away all useful gcc errors and warnings.

Make the build as little verbose as possible and just let gcc errors and warnings to come out.

A default make --quiet is a good idea.

Being able to trigger verbose builds with a configure option would also be nice for when you have to check build issues.

Comments

Comment from sgallagh at 2009-05-26 17:46:02

Fields changed

owner: somebody => sgallagh
status: new => assigned

Comment from sgallagh at 2009-06-04 19:43:18

Fixed in [ce584e4]

fixedin: => 0.4.0
resolution: => fixed
status: assigned => closed

Comment from dpal at 2012-01-19 02:23:06

Fields changed

rhbz: => 0

Comment from simo at 2017-02-24 14:53:07

Metadata Update from @Simo:

• Issue assigned to sgallagh
• Issue set to the milestone: SSSD 1.0

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/3

• Created at 2009-03-17 15:24:12 by sgallagh
• Closed as Invalid
• Assigned to sgallagh

Please ping me in #freeipa if you receive this ticket.

Comments

Comment from sgallagh at 2009-03-17 15:36:26

One last try, now that I've fixed the email addresses.

Please ping me in #freeipa when you get this.

owner: somebody => sgallagh
status: new => assigned

Comment from sgallagh at 2009-03-17 15:38:03

CC-list is working (finally) Closing this fake ticket.

resolution: => invalid
status: assigned => closed
version: => 0.2.1

Comment from dpal at 2012-01-19 02:09:24

Fields changed

rhbz: => 0

Comment from sgallagh at 2017-02-24 14:46:40

Metadata Update from @sgallagh:

• Issue assigned to sgallagh

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/30

• Created at 2009-04-29 15:58:09 by sgallagh
• Closed as Fixed
• Assigned to simo

These were found when compiling on Fedora 11 (which is using GCC 4.4.0)

Compiling responder/nss/nsssrv_cmd.c
responder/nss/nsssrv_cmd.c: In function ‘nss_cmd_getinit_callback’:
responder/nss/nsssrv_cmd.c:2827: warning: ‘ret’ may be used uninitialized in this function
responder/nss/nsssrv_cmd.c: In function ‘nss_cmd_getpwnam_callback’:
responder/nss/nsssrv_cmd.c:288: warning: ‘ret’ may be used uninitialized in this function
responder/nss/nsssrv_cmd.c: In function ‘nss_cmd_setgrent_callback’:
responder/nss/nsssrv_cmd.c:2306: warning: ‘ret’ may be used uninitialized in this function
responder/nss/nsssrv_cmd.c: In function ‘nss_cmd_setpwent_callback’:
responder/nss/nsssrv_cmd.c:954: warning: ‘ret’ may be used uninitialized in this function
responder/nss/nsssrv_cmd.c: In function ‘nss_cmd_getpwuid_callback’:
responder/nss/nsssrv_cmd.c:657: warning: ‘ret’ may be used uninitialized in this function

Comments

Comment from sgallagh at 2009-04-29 15:58:23

Fields changed

description: These were found when compiling on Fedora 11 (which is using GCC 4.4.0)

Compiling responder/nss/nsssrv_cmd.c
responder/nss/nsssrv_cmd.c: In function ‘nss_cmd_getinit_callback’:
responder/nss/nsssrv_cmd.c:2827: warning: ‘ret’ may be used uninitialized in this function
responder/nss/nsssrv_cmd.c: In function ‘nss_cmd_getpwnam_callback’:
responder/nss/nsssrv_cmd.c:288: warning: ‘ret’ may be used uninitialized in this function
responder/nss/nsssrv_cmd.c: In function ‘nss_cmd_setgrent_callback’:
responder/nss/nsssrv_cmd.c:2306: warning: ‘ret’ may be used uninitialized in this function
responder/nss/nsssrv_cmd.c: In function ‘nss_cmd_setpwent_callback’:
responder/nss/nsssrv_cmd.c:954: warning: ‘ret’ may be used uninitialized in this function
responder/nss/nsssrv_cmd.c: In function ‘nss_cmd_getpwuid_callback’:
responder/nss/nsssrv_cmd.c:657: warning: ‘ret’ may be used uninitialized in this function
=> These were found when compiling on Fedora 11 (which is using GCC 4.4.0)
{{{
Compiling responder/nss/nsssrv_cmd.c
responder/nss/nsssrv_cmd.c: In function ‘nss_cmd_getinit_callback’:
responder/nss/nsssrv_cmd.c:2827: warning: ‘ret’ may be used uninitialized in this function
responder/nss/nsssrv_cmd.c: In function ‘nss_cmd_getpwnam_callback’:
responder/nss/nsssrv_cmd.c:288: warning: ‘ret’ may be used uninitialized in this function
responder/nss/nsssrv_cmd.c: In function ‘nss_cmd_setgrent_callback’:
responder/nss/nsssrv_cmd.c:2306: warning: ‘ret’ may be used uninitialized in this function
responder/nss/nsssrv_cmd.c: In function ‘nss_cmd_setpwent_callback’:
responder/nss/nsssrv_cmd.c:954: warning: ‘ret’ may be used uninitialized in this function
responder/nss/nsssrv_cmd.c: In function ‘nss_cmd_getpwuid_callback’:
responder/nss/nsssrv_cmd.c:657: warning: ‘ret’ may be used uninitialized in this function
}}}

Comment from simo at 2009-04-30 15:30:47

Fields changed

resolution: => fixed
status: new => closed

Comment from sgallagh at 2009-04-30 15:34:18

Sorry, I didn't realize until after the code was committed that there were also similar warnings in the negative cache code that need to be fixed.

Compiling responder/nss/nsssrv_nc.c
responder/nss/nsssrv_cmd.c: In function ‘nss_cmd_getinit_callback’:
responder/nss/nsssrv_cmd.c:2960: warning: ‘ret’ may be used uninitialized in this function
responder/nss/nsssrv_cmd.c: In function ‘nss_cmd_getpwnam_callback’:
responder/nss/nsssrv_cmd.c:417: warning: ‘ret’ may be used uninitialized in this function
responder/nss/nsssrv_cmd.c: In function ‘nss_cmd_getpwuid_callback’:
responder/nss/nsssrv_cmd.c:774: warning: ‘ret’ may be used uninitialized in this function

resolution: fixed =>
status: closed => reopened

Comment from jhrozek at 2009-05-14 15:51:23

Simo did fix these in r4f88dcb91128aae87c8c2d95446d5303a1b0620f

The compilation produces no errors or warning as of now (F11, gcc 4.4.0).

resolution: => fixed
status: reopened => closed

Comment from dpal at 2012-01-19 02:09:55

Fields changed

rhbz: => 0

Comment from sgallagh at 2017-02-24 14:32:41

Metadata Update from @sgallagh:

• Issue assigned to simo

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/26

• Created at 2009-04-22 15:35:35 by sbose
• Closed as Fixed
• Assigned to jhrozek

The configuration should be checked for overlaps in the uid/gid ranges of different domains.

Comments

Comment from sgallagh at 2009-04-27 13:53:08

Jakub, please take a look at this one.

We probably want this to be a configuration error that can be overridden by a commandline option. Having overlapping domains is possible but extremely unwise.

owner: somebody => jhrozek

Comment from jhrozek at 2009-05-21 15:59:37

Fixed in rb39e818e616a773ea7c2098b9077be97d2e06f91

resolution: => fixed
status: new => closed

Comment from dpal at 2012-01-19 02:22:20

Fields changed

rhbz: => 0

Comment from sbose at 2017-02-24 14:25:19

Metadata Update from @sbose:

• Issue assigned to jhrozek
• Issue set to the milestone: SSSD 1.0

man sssd.conf:

use_fully_qualified_names
...
Default: FALSE (TRUE if default_domain_suffix is used)

It should describe that for trusted domain (sub-domains) this option defaults to 'TRUE'

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/23

• Created at 2009-04-16 19:31:35 by simo
• Closed as Fixed
• Assigned to jhrozek

the sss_tools should invoke system tools to create users when uid/gid < 500 or when the LOCAL domain uses a legacy files provider in migration scenarios.

Comments

Comment from sgallagh at 2009-04-27 13:50:36

Fields changed

owner: somebody => jhrozek

Comment from jhrozek at 2009-05-10 22:10:28

Resolved in rc1a1b0464b5fad4daa9868b846182ad391f716a2

resolution: => fixed
status: new => closed

Comment from dpal at 2012-01-19 02:22:17

Fields changed

rhbz: => 0

Comment from simo at 2017-02-24 14:54:00

Metadata Update from @Simo:

• Issue assigned to jhrozek
• Issue set to the milestone: SSSD 1.0

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/2

• Created at 2009-03-17 15:19:55 by sgallagh
• Closed as Fixed
• Assigned to sgallagh

In the event that an SBUS service dies, any other SSSD service that relies on this connection needs to be able to reconnect to it once the service restarts. Additionally, we want the clients to be able to queue their requests until the service is available again, so that no data loss occurs (unless the client reaches its timeout).

Comments

Comment from sgallagh at 2009-03-17 15:21:18

Working on this issue.

Current progress: I have implemented the reconnection logic and tested it on the Data Provider <--> Backend connections.

Still to do: NSS and PAM connections to the Data Provider.

status: new => assigned

Comment from sgallagh at 2009-03-17 15:48:05

Fields changed

component: Service Monitor => SBUS

Comment from sgallagh at 2009-03-24 20:00:27

Fixed by commits
- [6a3ca34] - Add reconnection logic to the SBUS
- [76c4a8c] - Enable autoreconnection of Data Provider Backends to the Data Provider

resolution: => fixed
status: assigned => closed

Comment from dpal at 2012-01-19 02:10:15

Fields changed

rhbz: => 0

Comment from sgallagh at 2017-02-24 14:48:29

Metadata Update from @sgallagh:

• Issue assigned to sgallagh
• Issue set to the milestone: Iteration 2