2 Replies Latest reply on Jun 15, 2013 12:32 PM by JimKlimov

    davadmin does not work with a GF instance without admin server


      When installing an OCUCS 7u2 system, there is a problem that Calendar davserver can't easily coexist with Convergence iwc web-application (both wanting to be root contexts IIRC), so the easiest solution is to have them installed into different JVMs - either as a different server on a different port in the same OS, or as a different application server in another OS published with the same common port on a different IP address (another Solaris local zone in our case). For some reason, simply different virtual hosts in one JVM did not cut it.
      The setup which seemed to work for us was that we set up the initial application server with everything except davserver, and in another zone created an instance for this server which was attached to the initial server via a node-agent. So this appserver domain has two instances for applications, running different sets of applications, with same ports on different hosts, and the admin server instance is only on the host without davserver.

      The problem:

      We recently wanted to add some calendaring entries with davadmin utility, and found that it refused to connect to this server - seemingly due to the lack of an GF admin server on the calendar host, and lack of dav urls on the host with the admin server.
      We've tried to fake presence of an admin server by forwarding some of its ports (8686, 4848), but have not succeeded so far in this direction.

      So, the question is: should we expect davadmin to work in such setup (and which configuration should we change to make it work), or does it implicitly expect to work only with a davserver which is hosted on its domain admin server?
        • 1. Re: davadmin does not work with a GF instance without admin server
          davadmin is definitely not my area of expertise but it should be possible. davadmin communicates with the CS Server using JMX, which is there by default in any JVM so there should not be any need for an admin server.

          Did you check whether the values in davadmin.properties (see https://wikis.oracle.com/display/CommSuite/Calendar+Server+7+Command-Line+Utilities#CalendarServer7Command-LineUtilities-ClifileProperties) make sense with regards to your particular configuration ?
          Are you running davadmin from the same machine (zone instance) where the CS Server is running ?
          • 2. Re: davadmin does not work with a GF instance without admin server

            I believe I did not follow up on this response (thanks, though). So far the server was left as is - that is, as a node-agent driven instance on a different node than the domain's master server. davadmin locally or remotely does not work despite many attempts to vary configurations, short of reinstalling the calendar server's web-container as an individual domain with its local admin server instance.


            It may also be relevant that the node agent does not seem to be trusted by admin server during its log in to the master-server to pull configs, etc., though the admin-server can view and seemingly manage the node-agent's state, etc. Over my years with Sun Appserver/Glassfish I haven't seen such behavior, but we did not pursue this either for the deployment. Errors messages in detailed logs, if any, during davadmin runs do not point to such "distrust", however. So it is just a "gut feeling" that they may be related.


            The initial quest (import of calendar data) was solved by other means with WCAP import, so such reinstallation of nodes was put off.