You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description:
When adding a user or group without defining a uidNumber/gidNumber, it results in "Cannot get domain info". [[BR]] [[BR]]
With a Range defined:[[BR]]
I would expect a better error message such as "UID/GID is required" or even "The selected UID/GID is outside all domain ranges"[[BR]] [[BR]]
With a Range undefined: [[BR]]
I would expect the user or group to be added successfully with the next available ID number. Just like the shadow utils. [[BR]] [[BR]]
This bug is present when attempting to run the sss_tools against an SSSD configuration with no provider=local domain configured.
We are currently debating whether to remove the ability to add a legacy user or group with the sss_tools. If we decide to do this, the error message will be changed to reflect that no local domain can be found.
If we decide to leave the legacy add/remove support in place, we will change the initialization code here to reflect that a provider=files domain is permissible.
Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/112
Description:
When adding a user or group without defining a uidNumber/gidNumber, it results in "Cannot get domain info". [[BR]] [[BR]]
With a Range defined:[[BR]]
I would expect a better error message such as "UID/GID is required" or even "The selected UID/GID is outside all domain ranges"[[BR]] [[BR]]
With a Range undefined: [[BR]]
I would expect the user or group to be added successfully with the next available ID number. Just like the shadow utils. [[BR]] [[BR]]
Version Tested:
sssd-2009081709-0.fc11.i586
Comments
Comment from sgallagh at 2009-08-18 15:40:16
This bug is present when attempting to run the sss_tools against an SSSD configuration with no provider=local domain configured.
We are currently debating whether to remove the ability to add a legacy user or group with the sss_tools. If we decide to do this, the error message will be changed to reflect that no local domain can be found.
If we decide to leave the legacy add/remove support in place, we will change the initialization code here to reflect that a provider=files domain is permissible.
component: SSSD => sss_tools
milestone: SSSD 1.0 => Iteration 7
owner: somebody => jhrozek
Comment from jhrozek at 2009-08-25 15:03:01
Fields changed
status: new => assigned
Comment from jhrozek at 2009-09-08 22:44:41
As per #167 we are removing the functionality altogether. Fix was present in patchset sent for review, must remove it in next iteration.
doc: => 0
docupdated: => 0
resolution: => wontfix
status: assigned => closed
tests: => 0
testsupdated: => 0
Comment from jgalipea at 2017-02-24 15:02:55
Metadata Update from @jgalipea:
The text was updated successfully, but these errors were encountered: