389-users August 2013

389-users@lists.fedoraproject.org

33 participants
35 discussions

Logging to syslog
by Tom Tucker 20 Aug '13

20 Aug '13

Is it possible to write 389 DS access, error and audit logs to a downstream syslog server ($syslog_server:514) ? I did some poking around in the UI and I can't seem to find anything like this. Thanks in advance, Tom

3 2

Re: [389-users] Need help setting up additional 389 Management Console Users/Admins
by Bright, Daniel 16 Aug '13

16 Aug '13

Dan, Thanks for the quick response, here is where I'm at now although I've made progress. I have removed the user from the Configuration Administrators group, and I have created an ACI that allows all to a specific OU under my domain root (ou=OU,dc=domain,dc=com). That being said, now when I logon to the management console as that administrative user, I don't see the root domain, all I see under the Directory tab is "schema", "monitor" and "config". I think I'm really close and I'm still messing around with ACI's, but is there anything you can point out that I might be doing wrong? Thanks, Daniel

1 0

Need help setting up additional 389 Management Console Users/Admins
by Bright, Daniel 16 Aug '13

16 Aug '13

All, Here is the goal I am trying to accomplish: I am trying to create an administrative user that has access to the 389 Management Console that has access to a single OU and can only modify objects within that OU. This user should not be able to modify anything outside of this OU, nothing in netscaperoot, nothing under schema, monitor or Config, and shouldn't be able to do anything on the Configuration or Tasks tab. If this is not possible then that's fine, I just need to know either way, so far I have been messing with ACIs and targetfilters etc... trying to get something working and I'm not having much success, any help with this is greatly appreciated. Regards, Daniel Bright

2 1

Question about installing on new servers
by harry.devine＠faa.gov 13 Aug '13

13 Aug '13

We have 2 new servers that we are bringing into our suite, and we'd like them to eventually take over the current 389-ds role. We currently have 2 servers that are running 1.2.1 on CentOS 5.7 64-bit, and the 2 new servers are being installed with RHEL 6.3 64-bit. What we'd ultimately like to see/have happen is: install 389-ds on the new servers set up replication to replicate the data from the 2 old servers to the 2 new servers point the underlying LDAP operations to the 2 new servers take the 2 old servers out of the mix Does anyone have any ideas or thoughts on if this is a good plan? And the best way to accomplish what we'd like to do? Thanks, Harry Devine Common ARTS Software Development AJM-245 (609)485-4218 Harry.Devine(a)faa.gov

3 4

Error with setup-ds-admin.pl -u
by Michael Gettes 12 Aug '13

12 Aug '13

Hi All, I'm finally trying to upgrade from 1.2.9.9 to ds-base = 1.2.11.15-20 on RHEL6 All is going well until I run the setup-ds-admin.pl -u The output from setup-ds-admin.pl -u is: Are you ready to set up your servers? [yes]: Registering the directory server instances with the configuration directory server . . . Beginning Admin Server reconfiguration . . . Registering admin server with the configuration directory server . . . Updating adm.conf with information from configuration directory server . . . libsepol.print_missing_requirements: piranha's global requirements were not met: type/attribute piranha_port_t (No such file or directory). libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory). /usr/sbin/semanage: Could not commit semanage transaction Error: command 'getsebool httpd_can_connect_ldap' failed - output [getsebool: SELinux is disabled] error []Exiting . . . Looks like stuff related to SELinux is getting in the way and we obviously have it disabled. I've googled about and can't seem to find anything relevant. Advice appreciated. I'd also appreciate perspective on whether or not I should be running what's in Fedora People Repos as a production server or should i just stick with what is base el6? thanks! /mrg Here is a yum list: # yum list | grep 389 389-admin.x86_64 1.1.29-1.el6 @epel-x86_64-server-6 389-admin-console.noarch 1.1.8-1.el6 @epel-x86_64-server-6 389-admin-console-doc.noarch 1.1.8-1.el6 @epel-x86_64-server-6 389-adminutil.x86_64 1.1.15-1.el6 @epel-x86_64-server-6 389-console.noarch 1.1.7-3.el5 installed 389-ds.noarch 1.2.2-1.el6 @epel-x86_64-server-6 389-ds-base.x86_64 1.2.11.15-14.el6_4 @rhel-x86_64-server-6 389-ds-base-libs.x86_64 1.2.11.15-14.el6_4 @rhel-x86_64-server-6 389-ds-console.noarch 1.2.6-1.el6 @epel-x86_64-server-6 389-ds-console-doc.noarch 1.2.6-1.el6 @epel-x86_64-server-6 389-dsgw.x86_64 1.1.10-1.el6 @epel-x86_64-server-6 389-admin.i686 1.1.29-1.el6 epel-x86_64-server-6 389-adminutil.i686 1.1.15-1.el6 epel-x86_64-server-6 389-adminutil-devel.i686 1.1.15-1.el6 epel-x86_64-server-6 389-adminutil-devel.x86_64 1.1.15-1.el6 epel-x86_64-server-6 389-ds-base.x86_64 1.2.11.15-20.el6_4 rhel-x86_64-server-6 389-ds-base-devel.i686 1.2.11.15-20.el6_4 rhel-x86_64-server-optional-6 389-ds-base-devel.x86_64 1.2.11.15-20.el6_4 rhel-x86_64-server-optional-6 389-ds-base-libs.i686 1.2.11.15-20.el6_4 rhel-x86_64-server-6 389-ds-base-libs.x86_64 1.2.11.15-20.el6_4 rhel-x86_64-server-6

3 2

ACL processing
by Russell Beall 12 Aug '13

12 Aug '13

I did a lot of work experimenting with 389 for use as a replacement to Sun SJES. Worked really well when I focused my efforts on the backend processing we do with Directory Manager, except for a few performance issues which are being addressed in bug reports. I thought sure I had done at least some load testing with service accounts. The service accounts must go through ACL processing, and we have a lot of ACLs. I'm not sure if I changed something, or if I just didn't quite test this feature enough, but now that I am doing more development work with service accounts, I am showing a huge processing hit taken if a service account is used as opposed to Directory Manager. This is on the order of a second and a half to respond to a simple base query, versus instantaneous. Our old SJES servers respond very snappily in comparison for this type of query. CPU usage for a single thread maxes out during the time spent waiting and I/O wait is zero, so I know that probably the bulk of time is being spent processing the ACLs. This is especially true if I turn on logging for ACL processing, then it takes a very long time, with one example taking about 9 minutes. It seems to be processing and reprocessing the ACLs many many times over. I think I must have changed something or done something wrong because I'm pretty sure I remember much quicker response times when using a service account in earlier testing. This is with 389-ds-base 1.2.10.14 on RedHat 6.2. This was an experimental version downloaded to check out a memory fragmentation option that was coded in, so maybe I just have a version that was mid ACL processing changes? Thanks for any help, Russ.

2 4

memberof plugin unreliable?
by Morgan Jones 12 Aug '13

12 Aug '13

I have a client running CentOS directory 8.2.8, CentOS 5. We have a two multi-masters with two read-only replicas. We enabled the memberof plugin and it shows group memberships unreliably at best. Is this a known issue or I am perhaps missing something? For example: ldapsearch -x -w pass -H ldaps://devldapm01.domain.net -D cn=directory\ manager -LLLb ou=groups,dc=domain,dc=org cn=orgfulladminaccess dn: cn=orgfulladminaccess,ou=groups,dc=domain,dc=org uniqueMember: uid=rfw,ou=employees,dc=domain,dc=org uniqueMember: uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot uniqueMember: uid=sathomas,ou=employees,dc=domain,dc=org uniqueMember: uid=rbateman,ou=employees,dc=domain,dc=org uniqueMember: uid=kacless,ou=employees,dc=domain,dc=org uniqueMember: uid=selectivesync,ou=employees,dc=domain,dc=org uniqueMember: uid=cverrill,ou=employees,dc=domain,dc=org uniqueMember: uid=morgan,ou=employees,dc=domain,dc=org uniqueMember: uid=fullAdminAccessUser,ou=people,dc=domain,dc=org objectClass: top objectClass: groupofuniquenames description: Group with full administrator access. cn: orgFullAdminAccess anderson:~ morgan$ Notice that just two users are returned when I search for memberof=cn=orgfulladminaccess... anderson:~ morgan$ ldapsearch -x -w pass -H ldaps://devldap01.domain.net -D cn=directory\ manager -LLLb dc=domain,dc=org memberof=cn=orgfulladminaccess,ou=groups,dc=domain,dc=org dn dn: uid=kacless,ou=employees,dc=domain,dc=org dn: uid=morgan,ou=employees,dc=domain,dc=org anderson:~ morgan$ ldapsearch -x -w pass -H ldaps://devldapm01.domain.net -D cn=directory\ manager -LLLb dc=domain,dc=org memberof=cn=orgfulladminaccess,ou=groups,dc=domain,dc=org dn dn: uid=kacless,ou=employees,dc=domain,dc=org dn: uid=morgan,ou=employees,dc=domain,dc=org I did consider this possibility but I struggle to believe that I have to set up partial replication throughout just to get memberof working: http://www.redhat.com/archives/fedora-directory-users/2009-November/msg0005… Here's the config on all four hosts; Masters: anderson:~ morgan$ ldapsearch -x -w pass -H ldaps://devldapm01.domain.net -D cn=directory\ manager -LLLb cn=config cn=memberof\ plugin dn: cn=MemberOf Plugin,cn=plugins,cn=config objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject cn: MemberOf Plugin nsslapd-pluginPath: libmemberof-plugin nsslapd-pluginInitfunc: memberof_postop_init nsslapd-pluginType: postoperation nsslapd-pluginEnabled: on nsslapd-plugin-depends-on-type: database memberofgroupattr: uniqueMember memberofattr: memberOf nsslapd-pluginId: memberof nsslapd-pluginVersion: 8.2.8 nsslapd-pluginVendor: CentOS nsslapd-pluginDescription: memberof plugin anderson:~ morgan$ ldapsearch -x -w pass -H ldaps://devldapm02.domain.net -D cn=directory\ manager -LLLb cn=config cn=memberof\ plugin dn: cn=MemberOf Plugin,cn=plugins,cn=config objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject cn: MemberOf Plugin nsslapd-pluginPath: libmemberof-plugin nsslapd-pluginInitfunc: memberof_postop_init nsslapd-pluginType: postoperation nsslapd-pluginEnabled: on nsslapd-plugin-depends-on-type: database memberofgroupattr: uniqueMember memberofattr: memberOf nsslapd-pluginId: memberof nsslapd-pluginVersion: 8.2.8 nsslapd-pluginVendor: CentOS nsslapd-pluginDescription: memberof plugin anderson:~ morgan$ read-only consumers: anderson:~ morgan$ ldapsearch -x -w pass -H ldaps://devldap01.domain.net -D cn=directory\ manager -LLLb cn=config cn=memberof\ plugin dn: cn=MemberOf Plugin,cn=plugins,cn=config objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject cn: MemberOf Plugin nsslapd-pluginPath: libmemberof-plugin nsslapd-pluginInitfunc: memberof_postop_init nsslapd-pluginType: postoperation nsslapd-pluginEnabled: on nsslapd-plugin-depends-on-type: database memberofgroupattr: uniquemember memberofattr: memberOf nsslapd-pluginId: memberof nsslapd-pluginVersion: 8.2.8 nsslapd-pluginVendor: CentOS nsslapd-pluginDescription: memberof plugin anderson:~ morgan$ ldapsearch -x -w pass -H ldaps://devldap02.domain.net -D cn=directory\ manager -LLLb cn=config cn=memberof\ plugin dn: cn=MemberOf Plugin,cn=plugins,cn=config objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject cn: MemberOf Plugin nsslapd-pluginPath: libmemberof-plugin nsslapd-pluginInitfunc: memberof_postop_init nsslapd-pluginType: postoperation nsslapd-pluginEnabled: on nsslapd-plugin-depends-on-type: database memberofgroupattr: uniquemember memberofattr: memberOf nsslapd-pluginId: memberof nsslapd-pluginVersion: 8.2.8 nsslapd-pluginVendor: CentOS nsslapd-pluginDescription: memberof plugin anderson:~ morgan$ thanks, -morgan

3 4

directory manager password changed
by Elizabeth Jones 06 Aug '13

06 Aug '13

my cn=directory manager password has somehow gotten changed or corrupted. I have a 389-console session open that I'm hoping I can use to reset directory manager back to where its supposed to be, but I don't know where in 389-console I would do this. Can anyone point me in the right direction? thanks - EJ

2 1

installing sogo with 389 directory server
by husam.shabeeb 05 Aug '13

05 Aug '13

Dear friends , Anyone can help me in installing Sogo with 389 directory server Thanks in advanced .. Best regards , husam

2 1

values not returned with "id" command
by Justin Edmands 02 Aug '13

02 Aug '13

Hey, Certainly new to migrations of LDAP. I migrated our old setup from OpenLDAP to 389 Directory Server. When using the "id" command on an LDAP client, it only returns uid,gid, and one group. It for some reason does not show all of the actual groups that the user is associated with. What is set to return these values and what setting ensures they are properly mapped from OpenLDAP to 389DS? *OpenLDAP example:* *uid=9999(jedmands) gid=100(users) groups=100(users),5000(manager),5001(linuxadmin),5002(storageadmin),5003(dbadmin),5004(webadmin),5006(it) * *389 DS Example:* *[root@389dsclient ~]# id jedmands uid=9999(jedmands) gid=100(users) groups=100(users)*

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users August 2013