On 02/10/2011 07:45 AM, Christopher Wood wrote: > 11;rgb:0000/0000/0000On Wed, Feb 09, 2011 at 05:49:28PM -0700, Rich Megginson > wrote: >> On 02/09/2011 07:59 AM, Christopher Wood wrote: >>> On Tue, Feb 08, 2011 at 06:14:27PM -0700, Rich Megginson wrote: >>>> On 02/08/2011 04:11 PM, Christopher Wood wrote: >>>>> These bugs are almost exactly the issue I'm experiencing: >>>>> >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=430499 >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=442103 >>>>> >>>>> In my case, the admin server on host1 can use the "Manage Certificates" >>>>> button on the admin server, and the directory server installed on the >>>>> same host. So the bug is not happening to me. >>>>> >>>>> However, I get "java.net.ConnectException: Connection refused" when I use >>>>> the "Manage Certificates" button on host2's directory server that I >>>>> registered with host1's admin server. >>>>> >>>>> I don't get any output on the console when I repeat this procedure having >>>>> run 389-console from the command line. I don't see anything immediately >>>>> obvious under /var/log/dirsrv/*/errors on both servers. I can run >>>>> ldapsearch against ldaps://host1 and ldaps://host2. >>>>> >>>>> Would you list denizens possibly have any hints as to how to troubleshoot >>>>> this? >>>> 389-console -D 9 -f console.log - paste the log to fpaste.org or >>>> similar - be sure to remove or obscure any sensitive information - >>>> post the link here >>> Thank you, I appreciate it. >>> >>> The full paste: http://fpaste.org/mgYb/ >>> >>> My procedure was to run 389-console with the above command line, click >>> "Manage Certificates" in the directory server on the same host as the admin >>> server ("host1"), then close that and click "Manage Certificates" in the >>> directory server on the other host ("host2"). >>> >>> Just from reading along as I clicked buttons, it appears that the console >>> is trying to itself talk to an admin server on host2. There is no admin >>> server running on that host since I registered the directory server on >>> host2 with the admin server on host1. >> Even if you use setup-ds-admin.pl to create a directory server and >> register it with another configuration directory server, there >> always has to be one admin server running on each machine. The >> admin server executes CGIs, such as the log viewer, server process >> management, etc. - tasks that must be done outside of the directory >> server process. >>> ResourceSet: found in cache >>> loader9690857:com.netscape.management.client.security.securityResource >>> CommManager> New CommRecord >>> (http://host2.mycompany.com:3389/admin-serv/tasks/configuration/SecurityOp) >>> java.net.ConnectException: Connection refused >> The admin server should always be running, unless you explicitly >> shut it down. > In my case (host1 having admin/ds and host2 just having ds), I registered > host2's directory server with host1's config directory server. However, > host2's admin server failed to start. From /var/log/dirsrv/admin-serv/error > when I try to start it manually: > > [root@host2 admin-serv]# cat /var/log/dirsrv/admin-serv/error > [Wed Feb 09 13:01:29 2011] [crit] host_ip_init(): PSET failure: Failed to > create PSET handle (pset error = ) > Configuration Failed > [Thu Feb 10 09:22:51 2011] [crit] host_ip_init(): PSET failure: Failed to > create PSET handle (pset error = ) > Configuration Failed Start the admin server like this: /usr/sbin/start-ds-admin -e debug then post the admin server error log > > From /tmp/setuphtlOC3.log on host2 (I chose a "Typical" (2) setup): > > [11/02/09:13:01:28] - [Setup] Info Starting admin server . . . > [11/02/09:13:01:29] - [Setup] Fatal Failed to create and configure the admin > server > [11/02/09:13:01:29] - [Setup] Fatal Exiting . . . > > That happened every time when in the setup-ds-admin.pl stage on something > other than host1 where I would pick ldaps://host1/o=NetscapeRoot as the > configuration directory server url. Of course, for the setup on host1 I set > everything up with basically defaults and added the encryption later. Not > certain if that's pertinent, though. > > I'm starting to think that I've misread something in the install docs, will > re-read. > >>> admserv version = null >>> >>> >>>>> -- >>>>> 389 users mailing list >>>>> 389-us...@lists.fedoraproject.org >>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>> -- >>> 389 users mailing list >>> 389-us...@lists.fedoraproject.org >>> https://admin.fedoraproject.org/mailman/listinfo/389-users >> > -- > 389 users mailing list > 389-us...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
