_______________________________________________This email with all information contained herein or attached hereto may contain confidential and/or privileged information intended for the addressee(s) only. If you have received this email in error, please contact the sender and immediately delete this email in its entirety and any attachments thereto.
Does the native windows version of 389 management console keep logs of commands executed and their results anywhere?
If not is there a way to make it do so?
I am working on a project to migrate to 389 and I have an instance whereby if I select "restart directory server" from the tasks page I get a message
pop-up saying "Directory Server <instance-name> could not be restarted" but no explanation as to why.
I have other instances where this functionality works fine.
There doesn't appear to be anything in the access or error logs at the server end to signify the failed attempt.
Any way to trace the issue?
389-users mailing list -- email@example.com
To unsubscribe send an email to firstname.lastname@example.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://email@example.com
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Monday, May 17, 2021
[389-users] Re: 389 console on Windows - command logging
There isn't a console log, but there is all the activity from the HTTP server, in /var/log/dirsrv/admin-serv/access
The other possibility is to run the console in debug mode.
Note the Java console has been deprecated for more than a year, for a web UI and Python command line tools.
( RHDS-11.0 was released for RHEL-8.1 in 20191106 )
In that case, the web browser debug console shows the actions translated in the commands.
for the error "could not be restarted", you may want to review the LDAP server errors log in for example /var/log/dirsrv/slapd-*/errors , not the console actions log.
try to restart manually from the LDAP server's system, to verify this work properly.
also verify there is indeed a task created by the DS console, in the LDAP server's access log file, there may be an error code different from 0.
or verify the user used to log in the DS console has access to the restart functionality, try to log in as "cn=directory manager"
On Mon, May 17, 2021 at 2:05 PM Joe Fletcher <firstname.lastname@example.org> wrote: