Logging to syslog
by Tom Tucker
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
10 years, 8 months
Re: [389-users] Need help setting up additional 389 Management Console Users/Admins
by Bright, Daniel
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
10 years, 8 months
Need help setting up additional 389 Management Console Users/Admins
by Bright, Daniel
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
10 years, 8 months
Question about installing on new servers
by harry.devine＠faa.gov
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
10 years, 8 months
Error with setup-ds-admin.pl -u
by Michael Gettes
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
10 years, 8 months
ACL processing
by Russell Beall
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.
10 years, 8 months
memberof plugin unreliable?
by Morgan Jones
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/msg00...
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
10 years, 8 months
directory manager password changed
by Elizabeth Jones
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
10 years, 8 months
values not returned with "id" command
by Justin Edmands
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)*
10 years, 9 months
