Uploaded image for project: 'Derby'
  1. Derby
  2. DERBY-4786

Shutdown command without username and password should work with mixed client and network server releases.

Details

    • Release Note Needed
    • Regression

    Description

      DERBY-2109 introduced optional parameters username and password to the shutdown command. But with this fix, the existing shutdown command which does not use username and password stopped working from client with DERBY-2109 changes against a network server without DERBY-2109 changes.

      This jira is to ensure that existing shutdown command without user name and password still works fine between different releases of client and network server(with or without DERBY-2109). The new shutdown command introduced by DERBY-2109 will work obviosuly only on client and server with DERBY-2109 changes. For client/server not with DERBY-2109 changes attempting to user use name and password will get an error.

      Attachments

        1. releaseNote.html
          4 kB
          Mamta A. Satoor
        2. releaseNote.html
          5 kB
          Richard N. Hillegas
        3. DERBY4786_testScript_patch3_diff.txt
          14 kB
          Mamta A. Satoor
        4. DERBY4786_patch2_diff.txt
          6 kB
          Mamta A. Satoor
        5. DERBY4786_patch1_diff.txt
          5 kB
          Mamta A. Satoor

        Issue Links

          Activity

            Attaching a patch to fix the jira. What the patch does is it checks if the optional username and password have specified for the shutdown command and if yes, then it uses protocol level 2 and then sends the username and password info to the server when sending the shutdown command. If user has not specified username and password then it uses protocol level 1 and sends just the shutdown command the way it used to work prior to DERBY-2109. In other words, protocol level 1 for shutdown with no username and password and protocol level 2 for shutdown with username and password.

            Server on its side checks if it is dealing with protocol level 1 for shutdown and if yes, then it does not need to look for username and password. But if the the protocol level is 2, then the server will expect username and password for the shutdown command,

            This way, a trunk client with this patch will be able to shutdown a 10.3 server with DERBY-2109 changes with no username and password. If it sends the username and password then there be following error on the server and client side
            10.3 server side error
            DRDA_UnknownProtocol.S, <2>
            Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM;CODPNT arg = 0; Error Code Value = 1. Plaintext connection attempt from an SSL enabled client?
            trunk client side error
            Tue Aug 31 11:48:20 PDT 2010 : Invalid reply header from network server: Invalid string. Plaintext connection attempt to an SSL enabled server?

            Please let me know if anyone has any feedback on this patch. I will plan on committing this in a day or two.

            mamtas Mamta A. Satoor added a comment - Attaching a patch to fix the jira. What the patch does is it checks if the optional username and password have specified for the shutdown command and if yes, then it uses protocol level 2 and then sends the username and password info to the server when sending the shutdown command. If user has not specified username and password then it uses protocol level 1 and sends just the shutdown command the way it used to work prior to DERBY-2109 . In other words, protocol level 1 for shutdown with no username and password and protocol level 2 for shutdown with username and password. Server on its side checks if it is dealing with protocol level 1 for shutdown and if yes, then it does not need to look for username and password. But if the the protocol level is 2, then the server will expect username and password for the shutdown command, This way, a trunk client with this patch will be able to shutdown a 10.3 server with DERBY-2109 changes with no username and password. If it sends the username and password then there be following error on the server and client side 10.3 server side error DRDA_UnknownProtocol.S, <2> Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM;CODPNT arg = 0; Error Code Value = 1. Plaintext connection attempt from an SSL enabled client? trunk client side error Tue Aug 31 11:48:20 PDT 2010 : Invalid reply header from network server: Invalid string. Plaintext connection attempt to an SSL enabled server? Please let me know if anyone has any feedback on this patch. I will plan on committing this in a day or two.

            Hi Mamta,

            With this patch, how does a changed trunk client specifying no user/password behave with an existing 10.5 server? I am concerned it might hang.

            Thanks

            Kathey

            kmarsden Katherine Marsden added a comment - Hi Mamta, With this patch, how does a changed trunk client specifying no user/password behave with an existing 10.5 server? I am concerned it might hang. Thanks Kathey

            You are right, Kathey. It sure hangs because the protocol level 1 from client is accepted by the server but for shutdown, existing 10.5 server expects username and password.

            We may have to revert to another approach to this problem which is to send shutdown command with protocol level 2 whether there is username and password or not. If this command fails because of protocol mismatch, then send shutdown command with protocol level 1. Also, if we do try this approach, what should we do if the user has provided user name and password for shutdown going against 10.3 server? Should we throw an exception that username and password can't be used for shutdown when going against a server that doesn't support protocol 2 or should we drop the user name and password and simply send the shutdown with protcol level 1 even though user name and password has been provided on the shutdown command?

            mamtas Mamta A. Satoor added a comment - You are right, Kathey. It sure hangs because the protocol level 1 from client is accepted by the server but for shutdown, existing 10.5 server expects username and password. We may have to revert to another approach to this problem which is to send shutdown command with protocol level 2 whether there is username and password or not. If this command fails because of protocol mismatch, then send shutdown command with protocol level 1. Also, if we do try this approach, what should we do if the user has provided user name and password for shutdown going against 10.3 server? Should we throw an exception that username and password can't be used for shutdown when going against a server that doesn't support protocol 2 or should we drop the user name and password and simply send the shutdown with protcol level 1 even though user name and password has been provided on the shutdown command?
            lilywei Lily Wei added a comment -

            +1 for send shutdown command with protocol level 2 whether there is username and password or not. If this command fails because of protocol mismatch, then send shutdown command with protocol level 1. If users want to shutdown the server, it should not failed because protocol mismatch. Does people concern about security for this solution?

            lilywei Lily Wei added a comment - +1 for send shutdown command with protocol level 2 whether there is username and password or not. If this command fails because of protocol mismatch, then send shutdown command with protocol level 1. If users want to shutdown the server, it should not failed because protocol mismatch. Does people concern about security for this solution?

            It appears that the sole pupose of protocol mismatch error thrown by the server is for logging purposed on it's end. That exception never makes it to the client. What client gets is the generic exception as follows
            Invalid reply header from network server: Invalid string Plaintext connection attempt to an SSL enabled server?
            Note that there is no error code associated with the exception that I could see in my debugging.

            So with the current approach for this jira, we were thinking of sending the shutdown with protocol level 2 and if there is protcol mismatch exception, then try it again with protocol level 1. Since there is no way to know that the exception received is for protocol mismatch and no error code either, I was thinking of doing a string search of "Plaintext connection attempt to an SSL enabled server" into exception's message. I do not like this string searching but I wonder what alternative way can we use to know that the protocol level 2 failed and hence tried 1. Another possible thing could be to try shutdown with level 2 and catch the exception and don't worry about what kind of exception it is, just go ahead and try protocol level 1. If there is exception with that too, we will just let the existing code take care of it the way it does today.

            Also, another outstanding issue was what if user has provided user name and password and protocol level 2 fails, then should we still try protocol level 1 with no user password and password?

            Would appreciate any feedback.

            mamtas Mamta A. Satoor added a comment - It appears that the sole pupose of protocol mismatch error thrown by the server is for logging purposed on it's end. That exception never makes it to the client. What client gets is the generic exception as follows Invalid reply header from network server: Invalid string Plaintext connection attempt to an SSL enabled server? Note that there is no error code associated with the exception that I could see in my debugging. So with the current approach for this jira, we were thinking of sending the shutdown with protocol level 2 and if there is protcol mismatch exception, then try it again with protocol level 1. Since there is no way to know that the exception received is for protocol mismatch and no error code either, I was thinking of doing a string search of "Plaintext connection attempt to an SSL enabled server" into exception's message. I do not like this string searching but I wonder what alternative way can we use to know that the protocol level 2 failed and hence tried 1. Another possible thing could be to try shutdown with level 2 and catch the exception and don't worry about what kind of exception it is, just go ahead and try protocol level 1. If there is exception with that too, we will just let the existing code take care of it the way it does today. Also, another outstanding issue was what if user has provided user name and password and protocol level 2 fails, then should we still try protocol level 1 with no user password and password? Would appreciate any feedback.

            Hi Mamta,

            If we have to check the error string I think DRDA_InvalidReplyHeader is a better string to search for as it won't change with localization. I think we should fail if user, password are specified and level 2 doesn't work as it is better not to give users the impression they are doing a credentialed shutdown if they are not. Once you get your new patch ready it would be good to do some testing wtih SSLTest and mixed versions to make sure we didn't make any wrong assumptions there.

            kmarsden Katherine Marsden added a comment - Hi Mamta, If we have to check the error string I think DRDA_InvalidReplyHeader is a better string to search for as it won't change with localization. I think we should fail if user, password are specified and level 2 doesn't work as it is better not to give users the impression they are doing a credentialed shutdown if they are not. Once you get your new patch ready it would be good to do some testing wtih SSLTest and mixed versions to make sure we didn't make any wrong assumptions there.

            Attaching a new patch, DERBY4786_patch2_diff.txt, which sends shutdown command with protocol level 2 whether there is username or password provided or not. If this command fails because of DRDA_InvalidReplyHead from server, then resend the shutdown command but this time with protocol level 1. The attempt with protocol level 1 will be made only if there was no username and password supplied with the shutdown command.

            One issue I noticed this with change is if a client with the changes proposed by this patch sends a shutdown command to a 10.3 server(which does not have DERBY-2109 changes) without the username and password, it will get 2 exceptions back from the server. 1st exception will be for sending the shutdown command at protocol level 2 and the 2nd will be for shutting down the server succesfully. Server will also have 2 messages, first indicating that an invalid protocol level command was received and 2nd message saying that the server is shutdown. Let me show that by example

            Client with the patch applied will show following when it is trying to shutdown a 10.3 server
            $ java org.apache.derby.drda.NetworkServerControl -noSecurityManager shutdown
            Tue Sep 07 21:57:10 PDT 2010 : Invalid reply header from network server: Invalid string ←. Plaintext connection attempt to an SSL enabled server?
            Tue Sep 07 21:57:11 PDT 2010 : Apache Derby Network Server - 10.7.0.0 alpha - (1) shutdown

            The 10.3 server would show following for a shutdown command from a trunk client(with the patch applied)
            java.lang.Throwable: DRDA_UnknownProtocol.S, <2>
            at org.apache.derby.impl.drda.NetworkServerControlImpl.processCommands(NetworkServerControlImpl.java:1509)
            at org.apache.derby.impl.drda.DRDAConnThread.sessionInitialState(DRDAConnThread.java:602)
            at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:266)
            Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM;CODPNT arg = 0; Error Code Value = 1. Plaintext connection attempt from an SSL enabled client?
            org.apache.derby.impl.drda.DRDAProtocolException: Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT arg = 0; Error Code Value = 1. Plaintext connection attempt from an SSL enabled client?
            at org.apache.derby.impl.drda.DRDAConnThread.throwSyntaxrm(DRDAConnThread.java:470)
            at org.apache.derby.impl.drda.DDMReader.readDssHeader(DDMReader.java:340)
            at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:673)
            at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:277)
            Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM;CODPNT arg = 0; Error Code Value = 1. Plaintext connection attempt from an SSL enabled client?
            org.apache.derby.impl.drda.DRDAProtocolException: Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT arg = 0; Error Code Value = 1. Plaintext connection attempt from an SSL enabled client?
            at org.apache.derby.impl.drda.DRDAConnThread.throwSyntaxrm(DRDAConnThread.java:470)
            at org.apache.derby.impl.drda.DDMReader.readDssHeader(DDMReader.java:340)
            at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:673)
            at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:277)
            Apache Derby Network Server - 10.3.3.1 - (1) shutdown at

            {2}

            I am not sure if we should try to mask this exception for the shutdown attempt with protocol level 2. Is it an ususal case any ways that a 10.3 server is being shutdown with a higher release client? Should we just document this behavior?

            mamtas Mamta A. Satoor added a comment - Attaching a new patch, DERBY4786_patch2_diff.txt, which sends shutdown command with protocol level 2 whether there is username or password provided or not. If this command fails because of DRDA_InvalidReplyHead from server, then resend the shutdown command but this time with protocol level 1. The attempt with protocol level 1 will be made only if there was no username and password supplied with the shutdown command. One issue I noticed this with change is if a client with the changes proposed by this patch sends a shutdown command to a 10.3 server(which does not have DERBY-2109 changes) without the username and password, it will get 2 exceptions back from the server. 1st exception will be for sending the shutdown command at protocol level 2 and the 2nd will be for shutting down the server succesfully. Server will also have 2 messages, first indicating that an invalid protocol level command was received and 2nd message saying that the server is shutdown. Let me show that by example Client with the patch applied will show following when it is trying to shutdown a 10.3 server $ java org.apache.derby.drda.NetworkServerControl -noSecurityManager shutdown Tue Sep 07 21:57:10 PDT 2010 : Invalid reply header from network server: Invalid string ←. Plaintext connection attempt to an SSL enabled server? Tue Sep 07 21:57:11 PDT 2010 : Apache Derby Network Server - 10.7.0.0 alpha - (1) shutdown The 10.3 server would show following for a shutdown command from a trunk client(with the patch applied) java.lang.Throwable: DRDA_UnknownProtocol.S, <2> at org.apache.derby.impl.drda.NetworkServerControlImpl.processCommands(NetworkServerControlImpl.java:1509) at org.apache.derby.impl.drda.DRDAConnThread.sessionInitialState(DRDAConnThread.java:602) at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:266) Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM;CODPNT arg = 0; Error Code Value = 1. Plaintext connection attempt from an SSL enabled client? org.apache.derby.impl.drda.DRDAProtocolException: Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT arg = 0; Error Code Value = 1. Plaintext connection attempt from an SSL enabled client? at org.apache.derby.impl.drda.DRDAConnThread.throwSyntaxrm(DRDAConnThread.java:470) at org.apache.derby.impl.drda.DDMReader.readDssHeader(DDMReader.java:340) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:673) at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:277) Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM;CODPNT arg = 0; Error Code Value = 1. Plaintext connection attempt from an SSL enabled client? org.apache.derby.impl.drda.DRDAProtocolException: Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT arg = 0; Error Code Value = 1. Plaintext connection attempt from an SSL enabled client? at org.apache.derby.impl.drda.DRDAConnThread.throwSyntaxrm(DRDAConnThread.java:470) at org.apache.derby.impl.drda.DDMReader.readDssHeader(DDMReader.java:340) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:673) at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:277) Apache Derby Network Server - 10.3.3.1 - (1) shutdown at {2} I am not sure if we should try to mask this exception for the shutdown attempt with protocol level 2. Is it an ususal case any ways that a 10.3 server is being shutdown with a higher release client? Should we just document this behavior?

            I have started looking at SSLTest. Can someone more aware of the test please describe it a little? Does it already do testing with different releases of the network server product? Specifically, is there existing framework to do junit testing with client and server at different releases? Thanks

            mamtas Mamta A. Satoor added a comment - I have started looking at SSLTest. Can someone more aware of the test please describe it a little? Does it already do testing with different releases of the network server product? Specifically, is there existing framework to do junit testing with client and server at different releases? Thanks

            Hi Mamta, I will look at the patch today but to answer your question, I think the behavior you have is fine with existing old versions but we should backport the recognition of level 2 protocol to the early branches so users running on the latest version on the branch, won't see the error. I think we should be careful to document that moving forward, instead of changing existing commands, new API's should create a new COMMAND_XXX command instead of bumping the protocol version. Maybe a big code comment around PROTOCOL_VERSION would be a good place to put this.

            It would be good to have some sort of automated test for this. The comments in DERBY-3644 seem to indicate that the compatibility tests exposed the problem. Are those still run anywhere?

            kmarsden Katherine Marsden added a comment - Hi Mamta, I will look at the patch today but to answer your question, I think the behavior you have is fine with existing old versions but we should backport the recognition of level 2 protocol to the early branches so users running on the latest version on the branch, won't see the error. I think we should be careful to document that moving forward, instead of changing existing commands, new API's should create a new COMMAND_XXX command instead of bumping the protocol version. Maybe a big code comment around PROTOCOL_VERSION would be a good place to put this. It would be good to have some sort of automated test for this. The comments in DERBY-3644 seem to indicate that the compatibility tests exposed the problem. Are those still run anywhere?
            knutanders Knut Anders Hatlen added a comment - The compatibility tests are run in the Ole's nightly tests: http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/Limited/compatibility_history.html

            Thanks Mamta.

            The patch looks good to me.

            kmarsden Katherine Marsden added a comment - Thanks Mamta. The patch looks good to me.

            Please review the attached release note, especially the wordings in the "Rationale for Change" section. Thanks

            mamtas Mamta A. Satoor added a comment - Please review the attached release note, especially the wordings in the "Rationale for Change" section. Thanks

            Attaching a patch which modifies the really outdated testScript.xml This gets used to run the compaibility tests. In addition to trunk, it only tested upto 10.2 and didn't include all releases of 10.2 and 10.1 I have modified it to test all available releases upto 10.6 This will definitely increase the runtime of the compatibility tests.

            mamtas Mamta A. Satoor added a comment - Attaching a patch which modifies the really outdated testScript.xml This gets used to run the compaibility tests. In addition to trunk, it only tested upto 10.2 and didn't include all releases of 10.2 and 10.1 I have modified it to test all available releases upto 10.6 This will definitely increase the runtime of the compatibility tests.

            I don't think the fix made it into the 10.6 branch until after the 10.6.2.1 release candidate was produced, so I've changed the fix-version to 10.6.2.2.

            knutanders Knut Anders Hatlen added a comment - I don't think the fix made it into the 10.6 branch until after the 10.6.2.1 release candidate was produced, so I've changed the fix-version to 10.6.2.2.

            Thanks for fixing the 10.6 version, Knut. I must not have synced my client when I did sysinfo on it.

            mamtas Mamta A. Satoor added a comment - Thanks for fixing the 10.6 version, Knut. I must not have synced my client when I did sysinfo on it.

            If there are no objections, then I will go ahead and commit the changes for briging up test script upto date (which are part of DERBY4786_testScript_patch3_diff.txt) on Friday.

            mamtas Mamta A. Satoor added a comment - If there are no objections, then I will go ahead and commit the changes for briging up test script upto date (which are part of DERBY4786_testScript_patch3_diff.txt) on Friday.

            Committed the test script changes with revision 1005193 into trunk

            mamtas Mamta A. Satoor added a comment - Committed the test script changes with revision 1005193 into trunk

            Attaching a new version of the release note, incorporating Dag's comments on the 10.7.1 release notes.

            rhillegas Richard N. Hillegas added a comment - Attaching a new version of the release note, incorporating Dag's comments on the 10.7.1 release notes.

            [bulk update] Close all resolved issues that haven't been updated for more than one year.

            knutanders Knut Anders Hatlen added a comment - [bulk update] Close all resolved issues that haven't been updated for more than one year.

            People

              mamtas Mamta A. Satoor
              mamtas Mamta A. Satoor
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: