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,
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?
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.
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
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?
Common ARTS Software Development
I'm finally trying to upgrade from 184.108.40.206 to ds-base = 220.127.116.11-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?
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 18.104.22.168-14.el6_4 @rhel-x86_64-server-6
389-ds-base-libs.x86_64 22.214.171.124-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 126.96.36.199-20.el6_4 rhel-x86_64-server-6
389-ds-base-devel.i686 188.8.131.52-20.el6_4 rhel-x86_64-server-optional-6
389-ds-base-devel.x86_64 184.108.40.206-20.el6_4 rhel-x86_64-server-optional-6
389-ds-base-libs.i686 220.127.116.11-20.el6_4 rhel-x86_64-server-6
389-ds-base-libs.x86_64 18.104.22.168-20.el6_4 rhel-x86_64-server-6
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 22.214.171.124 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,
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
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?
*389 DS Example:*
*[root@389dsclient ~]# id jedmands
uid=9999(jedmands) gid=100(users) groups=100(users)*