On Apr 19, 2020, at 7:13 PM, William Brown
<wbrown@suse.de<mailto:wbrown@suse.de>> wrote:
On 18 Apr 2020, at 07:19, CHAMBERLAIN James
<James.CHAMBERLAIN@3ds.com<mailto:James.CHAMBERLAIN@3ds.com>> wrote:
Hi all,
Thank you all for your help. I’ve gotten DNA working. I’ll be doing some further work to
convince myself that I understand exactly what I did that got it working and can replicate
it; but in the meantime, I had a question or two.
Do I correctly understand RHDS 11 Administration Guide, section 7.4.3.1, to mean that if I
want to have DNA manage uidNumber and gidNumber separately using different ranges, I’ll
need to create two instances of the plugin?
Yes, but I'd advise against it. gidnumber and uidnumbers are effectively equivalent in
linux/unix.
Consider you have a generic users group like:
william:students
alice:students
etc.
Well, now on every system you have to change the umasks to remove generic write from the
group, else everyone can access everyone elses things. I believe there are also some
rights from groups that may allow ptracing and other things.
This is why on FreeIPA they use the MEP to generate a user private group on the fly for
every user. It's best to have every account generate just a gidnumber, and then
duplicate that to the uidnumber for users only.
I've considered a weird but via option would actually be a sssd.conf where you have
ldap_user_uid_number point at gidNumber, and add posixGroup to every posixAccount, so you
only need gidNumbers ….
My case may be an edge case these days. We make extensive use of groups to grant multiple
users access to common files. We don’t do generic groups and groups never overlap; nor do
user accounts ever change groups.
I’m not finding dsconf on CentOS 7, including under “yum whatprovides ‘*/dsconf’”. Am I
missing something? Was this tool released in something more recent than 1.3.7.5-28?
The dsconf and friends are centos 8 only, with 389-ds 1.4., I think mark said this in a
different follow up.
Thanks for this note, both Mark and William.
I suspect that the key differences between my original setup and what’s working now are
the establishment of a dnaSharedCfgDN and non-overlapping initial ranges. My original
test setup was a single master server, which didn’t need these things. It was suggested
that I may need to include the attribute I wanted DNA to manage as part of creating an
entry, and that I should give it dnaMagicRegen's value. However, this does not appear
that it’s necessary - I was able to add a test user without specifying a uidNumber and DNA
generated it for me.
Thanks,
James
On Apr 16, 2020, at 1:38 PM, CHAMBERLAIN James
<James.CHAMBERLAIN@3ds.com<mailto:James.CHAMBERLAIN@3ds.com>> wrote:
Hi Thierry,
The thing is, while this is on the production multi-master cluster, it’s not being used
yet. Any new entries being added have uidNumber set explicitly, except for my test entry.
I’ve been trying a few things and have a different error message now but the same result.
I’ll update the thread shortly with further details.
Best regards,
James
On Apr 16, 2020, at 1:23 PM, thierry bordaz
<tbordaz@redhat.com<mailto:tbordaz@redhat.com>> wrote:
Hi James,
I would guess that the allocated range is exhausted, means next value reached maxValue.
Possibly part of the range was taken by an other replica.
You can try to get more details with
ldapmodify -D "cn=directory manager" -W
dn: cn=config
changetype: modify
replace: nsslapd-accesslog-level
nsslapd-acceslog-level: 260 (default level 256 plus 4 for internal operations)
-
replace: nsslapd-plugin-logging
nsslapd-plugin-logging: on
and lookup at the entry ldapsearch -D DM... -b "cn=UID numbers,cn=Distributed Numeric
Assignment Plugin,cn=plugins,cn=config" -s base nscpentrywsi
best regards
thierry
On 4/13/20 8:41 PM, CHAMBERLAIN James wrote:
Hi Mark,
Thanks for getting back to me. After adjusting nsslapd-errorlog-level, here’s what I’ve
got.
# grep dna-plugin /var/log/dirsrv/slapd-example/errors
[13/Apr/2020:14:30:00.480608036 -0400] - DEBUG - dna-plugin - _dna_pre_op_add - dn does
not match filter
[13/Apr/2020:14:30:00.486700059 -0400] - DEBUG - dna-plugin - _dna_pre_op_add - adding
uidNumber to uid=testuser1,ou=People,dc=example,dc=com as -2
[13/Apr/2020:14:30:00.559245389 -0400] - DEBUG - dna-plugin - _dna_pre_op_add - retrieved
value 0 ret 1
[13/Apr/2020:14:30:00.561303217 -0400] - ERR - dna-plugin - _dna_pre_op_add - Failed to
allocate a new ID!! 2
[13/Apr/2020:14:30:00.571360868 -0400] - DEBUG - dna-plugin - dna_pre_op - Operation
failure [1]
And here’s the DNA config:
dn: cn=UID numbers,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
objectClass: top
objectClass: extensibleObject
cn: UID numbers
dnaType: uidNumber
dnamaxvalue: 100000
dnamagicregen: 0
dnafilter: (objectclass=posixAccount)
dnascope: dc=example,dc=com
dnanextvalue: 25000
dn: cn=GID numbers,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
objectClass: top
objectClass: extensibleObject
cn: GID numbers
dnaType: gidNumber
dnamaxvalue: 100000
dnamagicregen: 0
dnafilter: (objectclass=posixGroup)
dnascope: dc=example,dc=com
dnanextvalue: 25000
Best regards,
James
On Apr 13, 2020, at 2:25 PM, Mark Reynolds
<mreynolds@redhat.com<mailto:mreynolds@redhat.com>> wrote:
Enabling plugin logging will provide a little more detail about what is going wrong:
ldapmodify -D "cn=directory manager" -W
dn: cn=config
changetype: modify
replace: nsslapd-errorlog-level
nsslapd-errorlog-level: 65536
After running the test you can disable the debug plugin logging by setting the log level
to zero.
Then share what information is logging when you add a new user. This is most likely a
configuration error so hopefully we can find out what went wrong in your set up. Can you
also provide the DNA config entries?
Thanks,
Mark
On 4/13/20 1:50 PM, CHAMBERLAIN James wrote:
Hi all,
I’m trying to use the DNA plugin to add uidNumbers on posixAccounts. Everything worked
fine in testing, but now that it’s in production I’m seeing the following error:
ERR - dna-plugin -_dna_pre_op_add - Failed to allocate a new ID!! 2
I’ve followed the advice in the knowledge base
(
https://access.redhat.com/solutions/875133), about adding an equality index with an
nsMatchingRule of integerOrderingMatch, but have not seen any difference in the server’s
behavior. Any ideas what I should try next?
Thanks,
James
This email and any attachments are intended solely for the use of the individual or entity
to whom it is addressed and may be confidential and/or privileged.
If you are not one of the named recipients or have received this email in error,
(i) you should not read, disclose, or copy it,
(ii) please notify sender of your receipt by reply email and delete this email and all
attachments,
(iii) Dassault Systèmes does not accept or assume any liability or responsibility for any
use of or reliance on this email.
Please be informed that your personal data are processed according to our data privacy
policy as described on our website. Should you have any questions related to personal data
protection, please contact 3DS Data Protection Officer at
3DS.compliance-privacy@3ds.com<mailto:3DS.compliance-privacy@3ds.com>
For other languages, go to
https://www.3ds.com/terms/email-disclaimer
_______________________________________________
389-users mailing list --
389-users@lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>
To unsubscribe send an email to
389-users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
--
389 Directory Server Development Team
This email and any attachments are intended solely for the use of the individual or entity
to whom it is addressed and may be confidential and/or privileged.
If you are not one of the named recipients or have received this email in error,
(i) you should not read, disclose, or copy it,
(ii) please notify sender of your receipt by reply email and delete this email and all
attachments,
(iii) Dassault Systèmes does not accept or assume any liability or responsibility for any
use of or reliance on this email.
Please be informed that your personal data are processed according to our data privacy
policy as described on our website. Should you have any questions related to personal data
protection, please contact 3DS Data Protection Officer at
3DS.compliance-privacy@3ds.com<mailto:3DS.compliance-privacy@3ds.com><mailto:3DS.compliance-privacy@3ds.com>
For other languages, go to
https://www.3ds.com/terms/email-disclaimer
_______________________________________________
389-users mailing list --
389-users@lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>
To unsubscribe send an email to
389-users-leave@lists.fedoraproject.org<mailto:389-users-leave@lists.fedoraproject.org>
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
_______________________________________________
389-users mailing list --
389-users@lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>
To unsubscribe send an email to
389-users-leave@lists.fedoraproject.org<mailto:389-users-leave@lists.fedoraproject.org>
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
This email and any attachments are intended solely for the use of the individual or entity
to whom it is addressed and may be confidential and/or privileged.
If you are not one of the named recipients or have received this email in error,
(i) you should not read, disclose, or copy it,
(ii) please notify sender of your receipt by reply email and delete this email and all
attachments,
(iii) Dassault Systèmes does not accept or assume any liability or responsibility for any
use of or reliance on this email.
Please be informed that your personal data are processed according to our data privacy
policy as described on our website. Should you have any questions related to personal data
protection, please contact 3DS Data Protection Officer at
3DS.compliance-privacy@3ds.com<mailto:3DS.compliance-privacy@3ds.com><mailto:3DS.compliance-privacy@3ds.com>
For other languages, go to
https://www.3ds.com/terms/email-disclaimer
_______________________________________________
389-users mailing list --
389-users@lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>
To unsubscribe send an email to
389-users-leave@lists.fedoraproject.org<mailto:389-users-leave@lists.fedoraproject.org>
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
This email and any attachments are intended solely for the use of the individual or entity
to whom it is addressed and may be confidential and/or privileged.
If you are not one of the named recipients or have received this email in error,
(i) you should not read, disclose, or copy it,
(ii) please notify sender of your receipt by reply email and delete this email and all
attachments,
(iii) Dassault Systèmes does not accept or assume any liability or responsibility for any
use of or reliance on this email.
Please be informed that your personal data are processed according to our data privacy
policy as described on our website. Should you have any questions related to personal data
protection, please contact 3DS Data Protection Officer at
3DS.compliance-privacy@3ds.com<mailto:3DS.compliance-privacy@3ds.com><mailto:3DS.compliance-privacy@3ds.com>
For other languages, go to
https://www.3ds.com/terms/email-disclaimer
_______________________________________________
389-users mailing list --
389-users@lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>
To unsubscribe send an email to
389-users-leave@lists.fedoraproject.org<mailto:389-users-leave@lists.fedoraproject.org>
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-users mailing list --
389-users@lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>
To unsubscribe send an email to
389-users-leave@lists.fedoraproject.org<mailto:389-users-leave@lists.fedoraproject.org>
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
This email and any attachments are intended solely for the use of the individual or entity
to whom it is addressed and may be confidential and/or privileged.
If you are not one of the named recipients or have received this email in error,
(i) you should not read, disclose, or copy it,
(ii) please notify sender of your receipt by reply email and delete this email and all
attachments,
(iii) Dassault Systèmes does not accept or assume any liability or responsibility for any
use of or reliance on this email.
Please be informed that your personal data are processed according to our data privacy
policy as described on our website. Should you have any questions related to personal data
protection, please contact 3DS Data Protection Officer at
3DS.compliance-privacy@3ds.com<mailto:3DS.compliance-privacy@3ds.com>
For other languages, go to
https://www.3ds.com/terms/email-disclaimer