acl on logs, 389 strips effective rights mask.
by William
Hi,
We have a log monitoring system that we are attempting to give access to
be able to read our dirsrv access, error, and audit logs to. We have set
the default ACL on /var/log/dirsrv/slapd-inst/ to be:
# file: .
# owner: nobody
# group: nobody
user::rwx
user:splunk:r-x
group::rwx #effective:r-x
mask::r-x
other::---
default:user::rwx
default:user:splunk:r-x
default:group::rwx #effective:r-x
default:mask::r-x
default:other::---
When you touch a test file it correctly inherits the ACL:
# file: test
# owner: nobody
# group: nobody
user::rw-
user:splunk:r-x
group::rwx #effective:r-x
mask::r-x
other::---
However, once 389 rotates the logs the permissions are incorrectly set
to:
# file: access
# owner: nobody
# group: nobody
user::rw-
user:splunk:r-x #effective:---
group::rwx #effective:---
mask::---
other::---
IE the effective rights mask is stripped.
I believe that there is something that is happening in the 389 log
rotation process that causes this to be stripped, I just can't identify
what. Any advice would be appreciated.
Sincerely,
--
William <william(a)firstyear.id.au>
9 years, 2 months
MEP to manage existing groups
by William
Hi,
I have a directory that already contains manually created user posix
groups.
Say that I configure mep, with some template that looks at ou=People,
and creates entries in ou=Groups.
Creating some entry as a posixAccount in ou=People, will create a group
in ou=Group, and removal of the posixAccount will delete it.
However, I already have existing posixAccount and posixGroup objects in
both ou's. I would like to convert existing posixGroups to be managed by
MEP to allow the deletion step to work.
In theory, I would think that the addition of:
objectClass: posixGroup
objectClass: mepManagedEntry
mepManagedBy: <dn>
Would cause the change of <dn> to trigger an update of the posixGroup.
However this doesn't seem to be the case.
Is there a way to convert existing entries into managed ones without
delete / recreate cycles?
--
Sincerely,
William Brown
Server and Storage Services,
Technology Services
The University of Adelaide,
AUSTRALIA 5005
CRICOS Provider Number 00123M
-----------------------------------------------------------------------------
IMPORTANT: This message may contain confidential or legally privileged
information.
If you think it was sent to you by mistake, please delete all copies and
advise the sender.
For the purposes of the SPAM Act 2003, this email is authorised by The
University of Adelaide.
9 years, 2 months
CORE creation is not working
by Jordan, Phillip
So a few weeks back we installed the CORE RPM and we were able to get a test core file on our Dev environment, but dev is 1.2.11.15-32, and in prod we are unable to get the core to generate with version 1.2.11.15-48. We have had two failure where the dirsrv hangs and becomes unresponsive and need to get a CORE to see what is causing the issues.
When we installed the CORE RPM here are the additional setting we put in place:
sysctl -w fs.suid_dumpable=1
and ulimit -u unlimited
Can anyone suggest a reason for the CORE file not getting generated or why we can do a test core in Dev and not in prod? Also any know issues with the dirsrv service stopping or hanging with the -48 version?
Phillip Jordan
Lead Engineer, Web Hosting
555 W. Adams
Chicago, IL 60661
This email including, without limitation, the attachments, if any, accompanying this email, may contain information which is confidential or privileged and exempt from disclosure under applicable law. The information is for the use of the intended recipient. If you are not the intended recipient, be aware that any disclosure, copying, distribution, review or use of the contents of this email, and/or its attachments, is without authorization and is prohibited. If you have received this email in error, please notify us by reply email immediately and destroy all copies of this email and its attachments.
9 years, 2 months
admin-console issues
by Fernando Fuentes
Team,
Due to a small requirement by ovirt I had to change my nsslapd-minssf
from 0 to 1.
All of my systems continue to work as they use ssl.
But the admin-console is now unable to log in.
I keep getting a "unauthorized access" when I try to login.
If I put it back to 0 it works just fine.
I am sure I am missing a setting somewhere on the admin-console settings
to make this work.
Thank you for the help.
Regards,
--
Fernando Fuentes
Technical Lead & Systems Administrator
Email: ffuentes(a)aasteel.com
American Alloy Steel, Inc.
Houston, Texas
Website: http://www.aasteel.com
Phone: 713-462-8081
Fax: 713-462-0527
9 years, 2 months
Move Directory Service from /var to /opt/dirsrv - process
by Jordan, Phillip
We have fixed all the previous forum post and need to locate the way to move off of /var to /opt/dirsrv as we have created a new file system so that /var does not fill up. What is the best way to proceed in moving the files and services from /var to /opt/dirsrv? Will this have any impact on replication or will everything just get updated with the new path?
Thanks in advance.
Phillip Jordan
Lead Engineer, Web Hosting
This email including, without limitation, the attachments, if any, accompanying this email, may contain information which is confidential or privileged and exempt from disclosure under applicable law. The information is for the use of the intended recipient. If you are not the intended recipient, be aware that any disclosure, copying, distribution, review or use of the contents of this email, and/or its attachments, is without authorization and is prohibited. If you have received this email in error, please notify us by reply email immediately and destroy all copies of this email and its attachments.
9 years, 2 months
Announcing 389 Directory Server version 1.3.3.8 and 1.3.2.26
by Noriko Hosoi
The 389 Directory Server team is proud to announce 389-ds-base testing
version 1.3.3.8 for Fedora 21 and 1.3.2.26 for Fedora 20.
Highlights in the versions are supporting the TLS version 1.1 and newer
and disabling SSL version 3 and many bug fixes.
The SSL/TLS version range in the 389 Directory Server needs to be
matched with the one in the rest of the 389 family, 389 Directory
Password Synchronization, 389 Admin Server, and 389 Console. If you are
using any of them with 389 Directory Server, please upgrade the package
to the latest version listed in the Release Notes on port389.org, as well.
http://www.port389.org/docs/389ds/releases/release-notes.html
# 389 Console 1.1.9
<http://www.port389.org/docs/389ds/releases/release-console-1-1-9.html>
/(February 5, 2015)/
# 389 Directory Server 1.3.3.8
<http://www.port389.org/docs/389ds/releases/release-1-3-3-8.html>
/(February 5, 2015)/
# 389 Directory Server 1.3.2.26
<http://www.port389.org/docs/389ds/releases/release-1-3-2-26.html>
/(February 5, 2015)/
# 389 Admin Server 1.1.38
<http://www.port389.org/docs/389ds/releases/release-admin-1-1-38.html>
/(February 3, 2015)/
# 389 Directory Password Synchronization
<http://www.port389.org/docs/389ds/releases/release-passsync-1-1-6.html>
/(January 28 2015)/
We are very interested in your feedback!
Please provide feedback and comments to the 389-users mailing list:
https://admin.fedoraproject.org/mailman/listinfo/389-users.
Thank you,
389 Directory Server Team
9 years, 2 months
DS crashed /killed by OS
by ghiureai
Hi List,
After succesfully running with 389-DS in production for 3 months , we
had DS crashed this am , see OS errorlog for details, there are no erros
in DS . I would like to know if there are any DS cfg for memory garbage
collection etc
my OS :Linux 2.6.32-431.el6.x86_64 #1 SMP Thu Nov 21 13:35:52 CST 2013
x86_64 x86_64 x86_64 GNU/Linux
Out of memory: Kill process 2090 (ns-slapd) score 954 or sacrifice child
Feb 3 04:53:12 proc5-01 kernel: Killed process 2090, UID 500,
(ns-slapd) total-vm:27657260kB, anon-rss:15313560kB, file-rss:268kB
Pid: 2228, comm: puppetd Not tainted 2.6.32-431.el6.x86_64 #1
Feb 3 04:53:11 proc5-01 kernel: Call Trace:
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff810d05b1>] ?
cpuset_print_task_mems_allowed+0x91/0xb0
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff81122960>] ?
dump_header+0x90/0x1b0
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff8122798c>] ?
security_real_capable_noaudit+0x3c/0x70
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff81122de2>] ?
oom_kill_process+0x82/0x2a0
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff81122d21>] ?
select_bad_process+0xe1/0x120
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff81123220>] ?
out_of_memory+0x220/0x3c0
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff8112fb3c>] ?
__alloc_pages_nodemask+0x8ac/0x8d0
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff81167b9a>] ?
alloc_pages_vma+0x9a/0x150
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff8114980d>] ?
do_wp_page+0xfd/0x920
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff8114a499>] ?
__do_fault+0x469/0x530
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff8114a82d>] ?
handle_pte_fault+0x2cd/0xb00
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff8104eeb7>] ?
pte_alloc_one+0x37/0x50
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff8114b28a>] ?
handle_mm_fault+0x22a/0x300
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff8104a8d8>] ?
__do_page_fault+0x138/0x480
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff81282571>] ?
cpumask_any_but+0x31/0x50
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff81150240>] ?
unmap_region+0x110/0x130
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff8114e3ce>] ? remove_vma+0x6e/0x90
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff8152d45e>] ?
do_page_fault+0x3e/0xa0
Feb 3 04:53:11 proc5-01 kernel: [<ffffffff8152a815>] ? page_fault+0x25/0x30
Feb 3 04:53:11 proc5-01 kernel: Mem-Info:
Feb 3 04:53:11 proc5-01 kernel: Node 0 DMA per-cpu:
Feb 3 04:53:11 proc5-01 kernel: CPU 0: hi: 0, btch: 1 usd: 0
Feb 3 04:53:11 proc5-01 kernel: CPU 1: hi: 0, btch: 1 usd: 0
Feb 3 04:53:11 proc5-01 kernel: CPU 2: hi: 0, btch: 1 usd: 0
9 years, 2 months
changelog delete - Question
by Jordan, Phillip
So we manually deleted the changelog file and restarted the dirsrv process, it did create a new file so its active again. Prior to doing that we enabled limits, which were previously allowing unlimited file size. The question is does the changelog have any other data that we need to consider before doing these actions in production. The data in the directory is very static so its not a large environment where changes are occurring every second, so losing any data on that front is slim. The current file size is 1.1 gig and the data goes back years, due to not limiting the size.
Phillip Jordan
Lead Engineer, Web Hosting
555 W. Adams
Chicago, IL 60661
transunion.com <http://www.transunion.com/>
This email including, without limitation, the attachments, if any, accompanying this email, may contain information which is confidential or privileged and exempt from disclosure under applicable law. The information is for the use of the intended recipient. If you are not the intended recipient, be aware that any disclosure, copying, distribution, review or use of the contents of this email, and/or its attachments, is without authorization and is prohibited. If you have received this email in error, please notify us by reply email immediately and destroy all copies of this email and its attachments.
9 years, 2 months
No rule to make target 'ldap/admin/src/scripts/dbmon.sh'
by William
Hi,
I'm trying to build 389ds at the moment to get a better understanding of
the code, and also to think about writing some improvements to some
plugins.
When I run the build from both git master, and origin/389-ds-base-1.3.3,
I receive.
make[1]: *** No rule to make target 'ldap/admin/src/scripts/dbmon.sh',
needed by 'all-am'. Stop.
make[1]: Leaving directory '/home/william/development/ds'
Makefile:2968: recipe for target 'all' failed
I'm not 100% sure how to track this down, so some guidance on how to
hunt through this would be great.
Sincerely,
William
9 years, 2 months
Changecache db
by Jordan, Phillip
We deleted and recreated the changelog DB as it was not shrinking after setting a limit and restarting the dirsrv, a limit was not previous set. Any down side to doing this besides something that may have changed etc.
Phillip Jordan
Lead Engineer, Web Hosting
555 W. Adams
Chicago, IL 60661
transunion.com <http://www.transunion.com/>
This email including, without limitation, the attachments, if any, accompanying this email, may contain information which is confidential or privileged and exempt from disclosure under applicable law. The information is for the use of the intended recipient. If you are not the intended recipient, be aware that any disclosure, copying, distribution, review or use of the contents of this email, and/or its attachments, is without authorization and is prohibited. If you have received this email in error, please notify us by reply email immediately and destroy all copies of this email and its attachments.
9 years, 2 months
