glassfish
  1. glassfish
  2. GLASSFISH-16289

[UB]Need warning about using administrative users with SSH and Windows 2008, Vista, 7

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 3.1
    • Fix Version/s: 3.1.1
    • Component/s: docs
    • Labels:
      None
    • Environment:

      Description

      I'm trying to evaluate different application servers for our next generation production infrastructure. This issue is preventing me from even evaluating Glassfish. I have been working on this for several days, and I'm about ready to scratch it and move to a different product. I was really excited about Glassfish 3.1, but so far I've only been disappointed.

      Steps to configure:
      1. Install and configure Cygwin SSH per the instructions in the high availability guide
      2. Install Glassfish on Server 1 and configure DAS (with a Windows service)
      3. Install Glassfish on Server 2 and configure nothing
      4. Open up admin console at http://server1:4848 and sign in
      5. Create node2 on Server 2 using admin console (localhost-domain1 node on Server 1, aka node1, has already been created)
      6. Copy default config (I named it aspgrp01-config), add JK Connector network interface with JK enabled, add system property for JK connector port
      7. Create a cluster aspgrp01 and reference aspgrp01-config
      8. Create instances s01instance01 and s01instance02 on node1 (server1) in cluster aspgrp01
      9. Create instances s02instance01 and s02instance02 on node2 (server2) in cluster aspgrp01
      10. Create Windows services on server1 for server1 instances using "asadmin create-instance..."
      11. Create Windows services on server2 for server2 instances using "asadmin create-instance..."
      12. Start all four instances (start cluster)

      Problem 1:
      On Server 2 only, the D:\Glassfish\glassfish\nodes\node2\s02instance01\docroot and D:\Glassfish\glassfish\nodes\node2\s02instance02\docroot directories are not created. (The analog directories on Server 1 are properly created.) Because of this, when deploying applications to the cluster, the applications only deploy to the instances on Server 1. They do not deploy in the instances on Server 2 (instead, for those two instances only, you get a "failed to deploy" "fix your application and redeploy" message). Can go to both Server 1 instance URLs directly and interact with the application without any errors. Cannot on Server 2. Both Server 2 instances "require restart" with the pending change of deploying the application. No number of restarts or stop-starts make the "require restart" message go away. Cannot undeploy application from those two instances because it is not deployed. Cannot attempt to deploy application to those two instances again because it says it is already deployed. Only choice is to delete and recreate the instances, but this does not make the root issue go away.

      Workaround 1:
      Before attempting to deploy an application to the cluster, copy the "docroot" directory from one of the instances on Server 1 and paste it into the instances on Server 2. Deployment succeeds. Application deploys and starts services on all four instances.

      Problem 2:
      On Server 2 only, JSP files do not compile. The environments and JVMs on both servers are identical, so this is not the issue here. There is no Windows firewall and no anti-virus installed. If I went to the "/appname/do/config/login" URL in my application directly on each instance, I could interact with the application without any errors on both Server 1 instances, but on Server 2 instances I get an error that the RequestDispatcher for /jsp/config/login.jsp could not be loaded. I investigated the JSP generation directories, and on Server 1 found directories this deep:

      D:\Glassfish\glassfish\nodes\node1\s01instance01\generated\jsp\appname\org\apache\jsp\jsp\config
      D:\Glassfish\glassfish\nodes\node1\s01instance02\generated\jsp\appname\org\apache\jsp\jsp\config

      However, on Server 2 they only go this deep:

      D:\Glassfish\glassfish\nodes\node1\s01instance01\generated\jsp\appname
      D:\Glassfish\glassfish\nodes\node1\s01instance02\generated\jsp\appname

      This leads me to believe that for some reason, Glassfish is not compiling JSPs on the instances on Server 2. All four instances have "appname\loader_[number]" dirctories. No errors are logged in server.log at ALL, except for the "could not load RequestDispatcher" error, which does not indicate WHY JSP files aren't being compiled, only THAT they aren't being compiled.

      Workaround 2:
      No known workaround that I could find. This obviously needs to be fixed, but a workaround would sure be helpful for me to continue my evaluations.

      Also, see forum entry: http://www.java.net/forum/topic/glassfish/glassfish/deployment-problem-glassfish-31-remote-instances

        Activity

        Hide
        Tom Mueller added a comment -

        I gather from your previous comment that the clustered instances are working correctly now.

        WRT #1, I agree. I'm going to change this to a doc bug to get some information about this added somewhere. However, if nodes directory for GlassFish is under the user's directory under \Users, then the user doesn't actually have to run as Administrator.

        WRT #2, when an SSH node is local to the DAS, the SSH call is short-circuited for efficiency, and the DAS calls the command directly. So this is why you were not seeing the issue on server 1.

        WRT #3, the behavior that I've seen with the virtual filesystem on Windows is indeed very strange. One program that is writing a file will not get any error from the operating system that it wasn't able to actually write the file, but then the file isn't actually in the file system. So in the case of "docroot" being missing, I suspect that the synchronization code thought that it successfully wrote the file, so it didn't report it as an error. However, when the web container started, it did report the error that the docroot was missing.

        Regarding secure admin, there are more details about this in the documentation here:
        http://download.oracle.com/docs/cd/E18930_01/html/821-2435/gkofl.html

        The short story is that in 3.1, the security for remote administration was improved by prohibiting remote connections to the DAS by default. Since the create-local-instance command makes a remote connection to the DAS, secure admin has to be enabled to allow the connection. The reason why this isn't needed when using SSH is because the SSH connection is used to establish a secure connection from the instance back to the DAS.

        Now that you have SSH working correctly, you can use the disable-secure-admin command to remove that feature. However, if you want to invoke any asadmin commands remotely, then you'll need it again.

        Show
        Tom Mueller added a comment - I gather from your previous comment that the clustered instances are working correctly now. WRT #1, I agree. I'm going to change this to a doc bug to get some information about this added somewhere. However, if nodes directory for GlassFish is under the user's directory under \Users, then the user doesn't actually have to run as Administrator. WRT #2, when an SSH node is local to the DAS, the SSH call is short-circuited for efficiency, and the DAS calls the command directly. So this is why you were not seeing the issue on server 1. WRT #3, the behavior that I've seen with the virtual filesystem on Windows is indeed very strange. One program that is writing a file will not get any error from the operating system that it wasn't able to actually write the file, but then the file isn't actually in the file system. So in the case of "docroot" being missing, I suspect that the synchronization code thought that it successfully wrote the file, so it didn't report it as an error. However, when the web container started, it did report the error that the docroot was missing. Regarding secure admin, there are more details about this in the documentation here: http://download.oracle.com/docs/cd/E18930_01/html/821-2435/gkofl.html The short story is that in 3.1, the security for remote administration was improved by prohibiting remote connections to the DAS by default. Since the create-local-instance command makes a remote connection to the DAS, secure admin has to be enabled to allow the connection. The reason why this isn't needed when using SSH is because the SSH connection is used to establish a secure connection from the instance back to the DAS. Now that you have SSH working correctly, you can use the disable-secure-admin command to remove that feature. However, if you want to invoke any asadmin commands remotely, then you'll need it again.
        Hide
        Tom Mueller added a comment -

        The root cause of this issue ended up being that a non-administrative user was being used on an SSH node when the nodes directory was on the D: drive which requires administrative access to write. The presence of the virtual file system feature in Windows service to obscure this issue.

        I'm changing this to be a doc bug so that we can document the need somewhere in the SSH related documentation for GlassFish that if a directory other than the users home directory is being used, then the SSH user needs to be setup to be an Administrator.

        Show
        Tom Mueller added a comment - The root cause of this issue ended up being that a non-administrative user was being used on an SSH node when the nodes directory was on the D: drive which requires administrative access to write. The presence of the virtual file system feature in Windows service to obscure this issue. I'm changing this to be a doc bug so that we can document the need somewhere in the SSH related documentation for GlassFish that if a directory other than the users home directory is being used, then the SSH user needs to be setup to be an Administrator.
        Hide
        Paul Davies added a comment -

        [UB]: Fix affects unbundled documentation.

        Show
        Paul Davies added a comment - [UB] : Fix affects unbundled documentation.
        Hide
        scatari added a comment -

        Approving for tracking and inclusion in 3.1.1.

        Show
        scatari added a comment - Approving for tracking and inclusion in 3.1.1.
        Hide
        Paul Davies added a comment -

        The attached file contains the fix for this issue. This fix will be published in the next library update.

        Show
        Paul Davies added a comment - The attached file contains the fix for this issue. This fix will be published in the next library update.

          People

          • Assignee:
            Paul Davies
            Reporter:
            Nick Williams
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: