Topic
  • 4 replies
  • Latest Post - ‏2011-04-13T19:55:36Z by SystemAdmin
VinceW
VinceW
6 Posts

Pinned topic adminctl not finding correct document root directory

‏2011-04-12T17:13:58Z |
We are planning to run the IHS web server on a remote web server farm w/o a nodeagent executing on the servers. We want the plugin to be managed by WAS. Reading through InfoCenter it states that the admin task must be started and webserver definitions defined in WAS for this to happen. When we start the adminctl and try to access the homepage the following error is generated:

Fri Apr 08 16:26:38 2011 error http://client 130.42.62.202 client denied by server configuration: /usr/IBMIHS
Fri Apr 08 16:26:45 2011 error http://client 130.42.62.202 client denied by server configuration: /usr/IBMIHS
Fri Apr 08 16:31:22 2011 error http://client 130.42.62.202 client denied by server configuration: /usr/IBMIHS

I'm not sure where the default document root of /usr/IBMIHS is coming from? Is this something that should/needs to be modified at install?
Updated on 2011-04-13T19:55:36Z at 2011-04-13T19:55:36Z by SystemAdmin
  • SystemAdmin
    SystemAdmin
    462 Posts

    Re: adminctl not finding correct document root directory

    ‏2011-04-12T19:35:32Z  
    Are you trying to access the IHS Admin Server from a browser instead of indirectly via the WAS Admin Console?

    Your error below is what happens when you access the IHS admin server directly on the HTTP port used for remote management by WAS. There is no user-accessible UI there.

    The /usr/IBMIHS is the compiled-in default DocumentRoot. When the IHS admin server receives a request that doesn't look like a remote WAS Admin Console administration request (does not begin with /ibmsail) it falls through to the default static-file serving code in Apache. The IHS admin server is configured to reject static requests, resulting in your errorlog entry.

    To reiterate -- once you setup the IHS Admin Server, you should not try to hit it directly in a browser. This is the piece that allows the WAS Admin Console (or wsadmin) to interact with the unmanaged IHS system.
  • VinceW
    VinceW
    6 Posts

    Re: adminctl not finding correct document root directory

    ‏2011-04-13T17:52:22Z  
    Thanks for the info. InfoCenter isn't describing what I hope to find or I haven't done the correct search to be able to find it. I have a webserver definition defined in the WAS console listening on port 8008 which is the admin server. It shows green in WAS so it is communicating. I have defined it and identify it as unmanaged. I can generate/propagate the plugin. I am assuming when applications are deployed to this remote web server WAS will know to generate/propagate the plugin. Is this a correct assumption?

    Where does the htpasswd come in? Does that just need to be created but we never actually use it? I don't see where it is requesting me to enter the userid/password in the webserver definition. As you stated very succinctly, we have no access to admin via HTTP so what is the value of this?
  • RamVennam
    RamVennam
    10 Posts

    Re: adminctl not finding correct document root directory

    ‏2011-04-13T18:14:36Z  
    • VinceW
    • ‏2011-04-13T17:52:22Z
    Thanks for the info. InfoCenter isn't describing what I hope to find or I haven't done the correct search to be able to find it. I have a webserver definition defined in the WAS console listening on port 8008 which is the admin server. It shows green in WAS so it is communicating. I have defined it and identify it as unmanaged. I can generate/propagate the plugin. I am assuming when applications are deployed to this remote web server WAS will know to generate/propagate the plugin. Is this a correct assumption?

    Where does the htpasswd come in? Does that just need to be created but we never actually use it? I don't see where it is requesting me to enter the userid/password in the webserver definition. As you stated very succinctly, we have no access to admin via HTTP so what is the value of this?
    VinceW,

    For unmanaged web server definitions:

    1) The green - running indication next to the web server definition in the WAS console indicates that WAS is able to see the web server (not the admin server) running on the specified port (80?). The admin server and its port (8008) does not have a role in this status indication.

    2) The admin server is used to issue start and stop commands to the web server.

    3) In most cases, the admin server is also used to Propagate the plugin from the WAS system to the IHS system. It is also used to transfer other files back and forth.

    4) The port, username, and password for the admin server can be configured in the console by going to Web servers > webserver1 > Remote Web server management. You should have been asked for this information in Step 3 of the wizard, when you were creating the web server definition in the WAS console.
  • SystemAdmin
    SystemAdmin
    462 Posts

    Re: adminctl not finding correct document root directory

    ‏2011-04-13T19:55:36Z  
    • VinceW
    • ‏2011-04-13T17:52:22Z
    Thanks for the info. InfoCenter isn't describing what I hope to find or I haven't done the correct search to be able to find it. I have a webserver definition defined in the WAS console listening on port 8008 which is the admin server. It shows green in WAS so it is communicating. I have defined it and identify it as unmanaged. I can generate/propagate the plugin. I am assuming when applications are deployed to this remote web server WAS will know to generate/propagate the plugin. Is this a correct assumption?

    Where does the htpasswd come in? Does that just need to be created but we never actually use it? I don't see where it is requesting me to enter the userid/password in the webserver definition. As you stated very succinctly, we have no access to admin via HTTP so what is the value of this?
    VinceW -- in addition to Ram's reply:

    In the last Beta refresh, i believe the installer prompts for the HTTP Basic Auth user/pass that authenticates the WAS admin console to the IHS Admin server. it's an optional step, but the IHS admin server requires authentication to succeed.

    THe install answers effectively causes IHS/bin/htpasswd to be run with an output file of conf/admin.passwd -- you can generate additional user/password pairs by using htpasswd yourself.