The saga continues.. After finally getting the admin-server to run and just briefly verifying that the console would run from my windows machine but not being able to connect because of firewall issues, I'm now picking up the thread again. To briefly recap, there are firewall issues preventing me from connecting easily with the admin server on the machine running fedora-ds. Iow: I can reach the ldap port fine - but not the admin server. I have no control over the firewall, and getting an opening poked in it is turning out to be, if not difficult then at least time consuming. I've been trying to sneak around the problem by using ssh-tunneling for now. I can use this to successfully connect the client java console with the server. However, that's pretty much as far as I've been able to get. The Fedora Management Console opens and connects nicely. In the console view, I can see the rootnode of myldap.foo.com, as well as the ldap instance just beneath it and its "Server Group" node. However, if I expand this node and try to click on the "Administration Server" or "Directory Server" leafs, I get a long pause and then an error dialog saying: "Class Loader error: Failed to install a local copy of fedora-admserv-1.0.jar or one of its supporting files: Can not connect to http://myldap.foo.com:56789";. Initially,I was thrown off by the class loader heading, assuming I'd left the jar out of the classpath. The jar it's requestion is indeed not not the classpath, however, the jar in question is not included in the original startconsole script either (meaning I have no idea how the client would find it). In any case I get the exact same error when the jar's on the cp as well. The client then goes on to try and download the jar - which will not work as the windows machine I'm running it on does not have open internet access - intranet only. However the errmsg also mentions connection problems, and there's a lengthy delay when clicking the nodes in question consistent with a connection attempt that's blocked by, say, a firewall. I've since verified with Ethereal that the console does indeed try to bypass my ssh tunnel and instead hits the admin server directly, an attempt which is of course blocked by the firewall. In addition, connections to the ldap port are also attempted, though this is not a problem as that port is actually open. Maybe the reason why I can get this far in the first place. However, could anyone confirm that the connection url (in my case ssh tunnel at localhost:56789) is only used for the initial connect, and that later the admin client may try to establish a direct link to the correct url of the servernode? If so, is there any possible workaround for this, or will I basically need a firewall-opening? Or could it be a dependency/classpath problem after all? -- Regards, Audun
