can't start dirsrv-admin service after reboot
by DaV
Hi guys,
I am facing an issue of can't start dirsrv-admin service after reboot
389ds server.Can anyone help me? Thank in advance.
It seems that some files missing after 389ds server reboot.
OS:
CentOS Linux release 7.5.1804 (Core)
Packages:
389-ds-base-1.3.7.5-24.el7_5.x86_64
389-admin-console-doc-1.1.12-1.el7.noarch
389-adminutil-1.1.21-2.el7.x86_64
389-ds-base-libs-1.3.7.5-24.el7_5.x86_64
389-admin-1.1.46-1.el7.x86_64
389-admin-console-1.1.12-1.el7.noarch
389-ds-console-doc-1.2.16-1.el7.noarch
389-ds-1.2.2-6.el7.noarch
389-console-1.1.18-1.el7.noarch
389-ds-console-1.2.16-1.el7.noarch
389-dsgw-1.1.11-5.el7.x86_64
/var/log/dirsrv/admin-serv/error
[Mon Oct 01 04:41:14.628926 2018] [mpm_worker:notice] [pid 1515:tid
139888393697408] AH00295: caught SIGTERM, shutting down[Mon Oct 01 20:15:10.124133 2018] [:warn] [pid 1498:tid 140057745549440]
NSSSessionCacheTimeout is deprecated. Ignoring.[Tue Oct 02 00:12:12.064065 2018] [:warn] [pid 1506:tid 140717522962560]
NSSSessionCacheTimeout is deprecated. Ignoring.[Tue Oct 02 01:24:15.688367 2018] [:warn] [pid 1486:tid 140470383057024]
NSSSessionCacheTimeout is deprecated. Ignoring.[Tue Oct 02 01:24:15.764891 2018] [:notice] [pid 1486:tid
140470383057024] Access Host filter is: *.seczone.com[Tue Oct 02 01:24:15.764904 2018] [:notice] [pid 1486:tid
140470383057024] Access Address filter is: *[Tue Oct 02 01:24:15.789117 2018] [:warn] [pid 1487:tid 140470383057024]
NSSSessionCacheTimeout is deprecated. Ignoring.[Tue Oct 02 01:24:15.789651 2018] [mpm_worker:notice] [pid 1487:tid
140470383057024] AH00292: Apache/2.4.6 (CentOS) configured -- resuming
normal operations[Tue Oct 02 01:24:15.789670 2018] [core:notice] [pid 1487:tid
140470383057024] AH00094: Command line: '/usr/sbin/httpd -f /etc/dirsrv/admin-
serv/httpd.conf'[Tue Oct 02 01:24:15.793251 2018] [:notice] [pid 1489:tid
140470383057024] Access Host filter is: *.seczone.com[Tue Oct 02 01:24:15.793278 2018] [:notice] [pid 1489:tid
140470383057024] Access Address filter is: *[Tue Oct 02 02:05:48.933732 2018] [mpm_worker:notice] [pid 1487:tid
140470383057024] AH00295: caught SIGTERM, shutting down
systemctl status dirsrv-admin -l
● dirsrv-admin.service - 389 Administration Server.
Loaded: loaded (/usr/lib/systemd/system/dirsrv-admin.service;
enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Wed 2018-10-03 17:34:52 CST;
1h 6min ago Process: 3290 ExecStart=/usr/sbin/httpd -k start -f /etc/dirsrv/admin-
serv/httpd.conf (code=exited, status=1/FAILURE)
Oct 03 17:34:52 vdi-ds-1 systemd[1]: Starting 389 Administration
Server....Oct 03 17:34:52 vdi-ds-1 httpd[3290]: httpd: Could not open
configuration file /etc/dirsrv/admin-serv/httpd.conf: No such file
or directoryOct 03 17:34:52 vdi-ds-1 systemd[1]: dirsrv-admin.service: control
process exited, code=exited status=1Oct 03 17:34:52 vdi-ds-1 systemd[1]: Failed to start 389
Administration Server..Oct 03 17:34:52 vdi-ds-1 systemd[1]: Unit dirsrv-admin.service entered
failed state.Oct 03 17:34:52 vdi-ds-1 systemd[1]: dirsrv-admin.service failed.
Sincerely,
--
DaV
5 years, 6 months
Memberof Not populating
by John Trump
I am using 389-ds on RHEL6. None of my users have the memberof attribute
visible when I view their accounts via admin console. I added the attribute
to my own account but it is not being auto-populated. How do I get the
memberof attribute assigned to all of my users and have it auto-populated?
5 years, 6 months
Re: 389 DS Access Log
by William Brown
On Thu, 2018-10-11 at 16:36 +0000, Paul Whitney wrote:
> Is there a way to prevent LDAP filters from being truncated in the
> Access Log, even as a temporary measure?
Sadly, we allocated a fix length buffer for the log, if it exceeds, we
have to truncate. There has been a long standing desire to rewrite
logging, which will likely happen when I am re-employed to work on 389
full time. (At this time I do not have a role working on 389 which has
stalled many of my objectives for improvement of the server).
--
Sincerely,
William
5 years, 6 months
389 DS Access Log
by Paul Whitney
Is there a way to prevent LDAP filters from being truncated in the Access Log, even as a temporary measure?
Thanks,
Paul M. Whitney
RHCSA, VCP, CISSP, Security+
Chesapeake IT Consulting, Inc.
2680 Tobacco Rd
Chesapeake Beach, MD 20732
Work: 443-492-2872
Cell: 410.493.9448
Email: paul.whitney(a)chesapeake-it.com<mailto:paul.whitney@chesapeake-it.com>
CONFIDENTIALITY NOTICE
The information contained in this facsimile or electronic message is confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this facsimile message to the intended recipient, you are hereby notified that any dissemination, or copying of this communication is strictly prohibited. If this message contains non-public personal information about any consumer or customer of the sender or intended recipient, you are further prohibited under penalty of law from using or disclosing the information to any third party by provisions of the federal Gramm-Leach-Bliley Act. If you have received this facsimile or electronic message in error, please immediately notify us by telephone and return or destroy the original message to assure that it is not read, copied, or distributed by others.
5 years, 6 months
Announcing 389 Directory Server 1.3.8.10
by Mark Reynolds
389 Directory Server 1.3.8.10
The 389 Directory Server team is proud to announce 389-ds-base version
1.3.8.10
Fedora packages are available on Fedora 27.
https://koji.fedoraproject.org/koji/taskinfo?taskID=30171199
<https://koji.fedoraproject.org/koji/taskinfo?taskID=30171199>
Bodhi
https://bodhi.fedoraproject.org/updates/FEDORA-2018-a857a4758e
<https://bodhi.fedoraproject.org/updates/FEDORA-2018-a857a4758e>
The new packages and versions are:
* 389-ds-base-1.3.8.10-1
Source tarballs are available for download at Download
389-ds-base Source
<https://releases.pagure.org/389-ds-base/389-ds-base-1.3.8.10.tar.bz2>
Highlights in 1.3.8.10
* Bug and security fixes
Installation and Upgrade
See Download <https://www.port389.org/docs/389ds/download.html> for
information about setting up your yum repositories.
To install, use *yum install 389-ds* yum install 389-ds After install
completes, run *setup-ds-admin.pl* if you have 389-admin installed,
otherwise please run *setup-ds.pl* to set up your directory server.
To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run
*setup-ds-admin.pl -u* if you have 389-admin installed, otherwise please
run *setup-ds.pl* to update your directory server/admin
server/console information.
See Install_Guide
<https://www.port389.org/docs/389ds/legacy/install-guide.html> for more
information about the initial installation, setup, and upgrade
See Source <https://www.port389.org/docs/389ds/development/source.html>
for information about source tarballs and SCM (git) access.
Feedback
We are very interested in your feedback!
Please provide feedback and comments to the 389-users mailing list:
https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject...
If you find a bug, or would like to see a new feature, file it in our
Pagure project: https://pagure.io/389-ds-base
* Bump version to 1.3.8.10
* Ticket 49969 - DOS caused by malformed search operation (part 2)
5 years, 6 months
Profiling discussion
by William Brown
Hi everyone,
I have opened a discussion on the 389-devel list about future profiling
tools for 389. We want to be able to improve and read metrics from the
server so we know where to focus performance improvements.
It would be great if you could provide some ideas of things you'd like
to see here, or in the thread on 389-devel (that thread may be more
implementation specific). For example, I'd like to see timings of how
long each plugin takes in an operation, and I'd like to be able to see
how indexes were applied to queries.
Any other ideas?
--
Sincerely
William
5 years, 6 months
Announcing 389 Directory Server 1.3.8.9
by Mark Reynolds
389 Directory Server 1.3.8.9
The 389 Directory Server team is proud to announce 389-ds-base version
1.3.8.9
Fedora packages are available on Fedora 27.
https://koji.fedoraproject.org/koji/taskinfo?taskID=30150274
<https://koji.fedoraproject.org/koji/taskinfo?taskID=30150274>
Bodhi
https://bodhi.fedoraproject.org/updates/FEDORA-2018-143c134572
<https://bodhi.fedoraproject.org/updates/FEDORA-2018-143c134572>
The new packages and versions are:
* 389-ds-base-1.3.8.9-1
Source tarballs are available for download at Download
389-ds-base Source
<https://releases.pagure.org/389-ds-base/389-ds-base-1.3.8.9.tar.bz2>
Highlights in 1.3.8.9
* Bug and security fixes
Installation and Upgrade
See Download <https://www.port389.org/docs/389ds/download.html> for
information about setting up your yum repositories.
To install, use *yum install 389-ds* yum install 389-ds After install
completes, run *setup-ds-admin.pl* if you have 389-admin installed,
otherwise please run *setup-ds.pl* to set up your directory server.
To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run
*setup-ds-admin.pl -u* if you have 389-admin installed, otherwise please
run *setup-ds.pl* to update your directory server/admin
server/console information.
See Install_Guide
<https://www.port389.org/docs/389ds/legacy/install-guide.html> for more
information about the initial installation, setup, and upgrade
See Source <https://www.port389.org/docs/389ds/development/source.html>
for information about source tarballs and SCM (git) access.
Feedback
We are very interested in your feedback!
Please provide feedback and comments to the 389-users mailing list:
https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject...
If you find a bug, or would like to see a new feature, file it in our
Pagure project: https://pagure.io/389-ds-base
* Bump version to 1.3.8.9
* Ticket 49969 - DOS caused by malformed search operation (security fix)
* Ticket 49954 - On s390x arch retrieved DB page size is stored as
size_t rather than uint32_t
* Ticket 49937 - Log buffer exceeded emergency logging msg is not
thread-safe (security fix)
* Ticket 49932 - Crash in delete_passwdPolicy when persistent search
connections are terminated unexpectedly
5 years, 6 months
error moving an user
by Alberto Viana
Hey Guys,
389 version: 389-Directory/1.3.7.4.20170912git26a9426 B2017.255.1330
I'm trying to move one of my users to another OU and I see this kind of
error:
Error while moving entry
- [LDAP: error code 1 - Operations Error]
java.lang.Exception: [LDAP: error code 1 - Operations Error]
at
In the log I see:
[20/Mar/2018:14:12:27.172553808 -0300] - ERR - ldbm_back_modrdn -
SLAPI_PLUGIN_BE_TXN_POST_MODRDN_FN plugin returned error but did not set
SLAPI_RESULT_CODE
I thought that was related to my windows replication, but I disabled it and
I'm still getting the error.
Any clues?
5 years, 6 months
