[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765960#comment-17765960 ] 袁枫 commented on HDFS-14509: --- [~John Smith] hi yuxuan, can your patch apply on branch-2.7.3? > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Assignee: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Fix For: 2.10.0, 3.3.0, 3.1.4, 3.2.2 > > Attachments: HDFS-14509-001.patch, HDFS-14509-002.patch, > HDFS-14509-003.patch, HDFS-14509-branch-2.001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616351#comment-17616351 ] yuyanlei commented on HDFS-14509: - However, this patch cannot be merged on 2.7.2. The BlockTokenIdentifier class in the hadoop-2.7.2 code does not have the handshakeMsg attribute > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Assignee: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Fix For: 2.10.0, 3.3.0, 3.1.4, 3.2.2 > > Attachments: HDFS-14509-001.patch, HDFS-14509-002.patch, > HDFS-14509-003.patch, HDFS-14509-branch-2.001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611945#comment-17611945 ] Brahma Reddy Battula commented on HDFS-14509: - Hope I remeber correctly,Yes, you need to have this patch before you go upgrade. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Assignee: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Fix For: 2.10.0, 3.3.0, 3.1.4, 3.2.2 > > Attachments: HDFS-14509-001.patch, HDFS-14509-002.patch, > HDFS-14509-003.patch, HDFS-14509-branch-2.001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17610768#comment-17610768 ] yuyanlei commented on HDFS-14509: - When Kerberos is enabled and Hadoop is upgraded from 2.7.2 to 3.3.4, when Acitve Namenode version is 3.3.4 and Datanode version is 2.7.2, The BlockToken authentication between Namenode and Datanode fails. As a result, the client cannot read and write. The datanode error: org.apache.hadoop.security.token.SecretManager$InvalidToken: Block token with block_token_identifier (expiryDate=1664452892587, keyId=2032735264, userId=work, blockPoolId=BP-874546658-10.48.20.234-1660635316009, blockId=1152681184, access modes=[READ]) doesn't have the correct token password at org.apache.hadoop.hdfs.security.token.block.BlockTokenSecretManager.checkAccess(BlockTokenSecretManager.java:303) at org.apache.hadoop.hdfs.security.token.block.BlockPoolTokenSecretManager.checkAccess(BlockPoolTokenSecretManager.java:97) at org.apache.hadoop.hdfs.server.datanode.DataXceiver.checkAccess(DataXceiver.java:1296) at org.apache.hadoop.hdfs.server.datanode.DataXceiver.readBlock(DataXceiver.java:521) at org.apache.hadoop.hdfs.protocol.datatransfer.Receiver.opReadBlock(Receiver.java:116) at org.apache.hadoop.hdfs.protocol.datatransfer.Receiver.processOp(Receiver.java:71) at org.apache.hadoop.hdfs.server.datanode.DataXceiver.run(DataXceiver.java:253) at java.lang.Thread.run(Thread.java:745) This phenomenon like https://issues.apache.org/jira/browse/HDFS-14509, but can't merge the issues on the version 2.7.2 patch, so now can't in the case of open kerberos, Perform a rolling upgrade of Hadoop (2.7.2 upgrading 3.3.4) I think it's a problem. What do you think > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Assignee: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Fix For: 2.10.0, 3.3.0, 3.1.4, 3.2.2 > > Attachments: HDFS-14509-001.patch, HDFS-14509-002.patch, > HDFS-14509-003.patch, HDFS-14509-branch-2.001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948927#comment-16948927 ] Chen Liang commented on HDFS-14509: --- Thanks for the update [~John Smith]! The change makes sense to me. I think we should be able to remove {{instanceof}} as it seems for block access token it is always {{DataInputStream}}. But I also don't like doing a casting without a check. I also verified the two failed tests, both passed in my local run. Committed to branch-2. Thanks for the contribution Yuxuan! > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Attachments: HDFS-14509-001.patch, HDFS-14509-002.patch, > HDFS-14509-003.patch, HDFS-14509-branch-2.001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948370#comment-16948370 ] Yuxuan Wang commented on HDFS-14509: I uploaded branch-2 patch. But I can't build it locally. Pls check the UT failed if related, thanks [~vagarychen]. In my practice, the *instanceof* is always true. But I can't confirm it is true overall, so I add if-condition here. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Attachments: HDFS-14509-001.patch, HDFS-14509-002.patch, > HDFS-14509-003.patch, HDFS-14509-branch-2.001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948338#comment-16948338 ] Hadoop QA commented on HDFS-14509: -- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 1m 30s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 0s{color} | {color:green} The patch appears to include 1 new or modified test files. {color} | || || || || {color:brown} branch-2 Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 52s{color} | {color:blue} Maven dependency ordering for branch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 11m 50s{color} | {color:green} branch-2 passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 23s{color} | {color:green} branch-2 passed with JDK v1.7.0_95 {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 4s{color} | {color:green} branch-2 passed with JDK v1.8.0_222 {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 45s{color} | {color:green} branch-2 passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m 52s{color} | {color:green} branch-2 passed {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m 36s{color} | {color:green} branch-2 passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 7s{color} | {color:green} branch-2 passed with JDK v1.7.0_95 {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 34s{color} | {color:green} branch-2 passed with JDK v1.8.0_222 {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 11s{color} | {color:blue} Maven dependency ordering for patch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m 42s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 14s{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m 14s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 3s{color} | {color:green} the patch passed with JDK v1.8.0_222 {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m 3s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 40s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m 53s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m 28s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 45s{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 12s{color} | {color:green} the patch passed with JDK v1.8.0_222 {color} | || || || || {color:brown} Other Tests {color} || | {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 34s{color} | {color:green} hadoop-hdfs-client in the patch passed. {color} | | {color:red}-1{color} | {color:red} unit {color} | {color:red} 79m 1s{color} | {color:red} hadoop-hdfs in the patch failed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 27s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black}129m 59s{color} | {color:black} {color} | \\ \\ || Reason || Tests || | Failed junit tests | hadoop.hdfs.qjournal.server.TestJournalNodeRespectsBindHostKeys | | | hadoop.hdfs.server.namenode.ha.TestDelegationTokensWithHA | \\ \\ || Subsystem || Report/Notes || | Docker | Client=19.03.3 Server=19.03.3 Image:yetus/hadoop:da675796017 | | JIRA Issue | HDFS-14509 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12982639/HDFS-14509-branch-2.001.patch | | Optional Tests
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16947906#comment-16947906 ] Chen Liang commented on HDFS-14509: --- Hey [~John Smith], after reading through the previous comments again, I'm under impression that you have a 2.x patch? If this is correct, would you mind sharing a branch-2 patch? If it is just casting to {{DataInputStream}}, I guess I can put a patch as well I think. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Attachments: HDFS-14509-001.patch, HDFS-14509-002.patch, > HDFS-14509-003.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16947154#comment-16947154 ] Chen Liang commented on HDFS-14509: --- Committed to trunk, branch-3.2 and branch-3.1. For branch-2 though, seems we need to take another look, because HDFS-11026 is not in branch-2. Seems the key difference for the purpose of this Jira here is that, HDFS-11026 casts {{DataInput}} to {{DataInputStream}} so that we can leverage {{mark(..)}} and {{reset() }}to initialize the cache. I wonder if we can do the same cast in branch-2, if yes, we should be able to set the cache in the similar way. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Attachments: HDFS-14509-001.patch, HDFS-14509-002.patch, > HDFS-14509-003.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16947133#comment-16947133 ] Hudson commented on HDFS-14509: --- SUCCESS: Integrated in Jenkins build Hadoop-trunk-Commit #17505 (See [https://builds.apache.org/job/Hadoop-trunk-Commit/17505/]) HDFS-14509. DN throws InvalidToken due to inequality of password when (cliang: rev 72ae371e7a6695f45f0d9cea5ae9aae83941d360) * (edit) hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/security/token/block/TestBlockToken.java * (edit) hadoop-hdfs-project/hadoop-hdfs-client/src/main/java/org/apache/hadoop/hdfs/security/token/block/BlockTokenIdentifier.java > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Attachments: HDFS-14509-001.patch, HDFS-14509-002.patch, > HDFS-14509-003.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16947127#comment-16947127 ] Chen Liang commented on HDFS-14509: --- Thanks for the patch [~John Smith]. v003 patch LGTM, +1. I also verified locally, TestDFSZKFailoverController passed in my local run, TestRenameWithSnapshots fails both with and without the patch. I will commit v003 patch shortly. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Attachments: HDFS-14509-001.patch, HDFS-14509-002.patch, > HDFS-14509-003.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16946540#comment-16946540 ] Hadoop QA commented on HDFS-14509: -- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 1m 27s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 0s{color} | {color:green} The patch appears to include 1 new or modified test files. {color} | || || || || {color:brown} trunk Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 23s{color} | {color:blue} Maven dependency ordering for branch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 22m 44s{color} | {color:green} trunk passed {color} | | {color:red}-1{color} | {color:red} compile {color} | {color:red} 2m 15s{color} | {color:red} hadoop-hdfs-project in trunk failed. {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 2s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 2m 11s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 16m 51s{color} | {color:green} branch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m 3s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 1s{color} | {color:green} trunk passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 19s{color} | {color:blue} Maven dependency ordering for patch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m 2s{color} | {color:green} the patch passed {color} | | {color:red}-1{color} | {color:red} compile {color} | {color:red} 2m 3s{color} | {color:red} hadoop-hdfs-project in the patch failed. {color} | | {color:red}-1{color} | {color:red} javac {color} | {color:red} 2m 3s{color} | {color:red} hadoop-hdfs-project in the patch failed. {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 57s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 2m 7s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 14m 49s{color} | {color:green} patch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m 11s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 41s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 53s{color} | {color:green} hadoop-hdfs-client in the patch passed. {color} | | {color:red}-1{color} | {color:red} unit {color} | {color:red}110m 46s{color} | {color:red} hadoop-hdfs in the patch failed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 40s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black}195m 26s{color} | {color:black} {color} | \\ \\ || Reason || Tests || | Failed junit tests | hadoop.hdfs.tools.TestDFSZKFailoverController | | | hadoop.hdfs.server.namenode.snapshot.TestRenameWithSnapshots | \\ \\ || Subsystem || Report/Notes || | Docker | Client=19.03.2 Server=19.03.2 Image:yetus/hadoop:1dde3efb91e | | JIRA Issue | HDFS-14509 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12982453/HDFS-14509-003.patch | | Optional Tests | dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle | | uname | Linux cea13ba5d394 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | trunk / 4fdf016 | | maven | version: Apache Maven 3.3.9 | | Default Java |
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16946443#comment-16946443 ] Yuxuan Wang commented on HDFS-14509: Sorry for delay it. I upload 003 patch. Feel free to take over this jira. [~shv] Thanks for your patch. [~vagarychen] Thanks for your review. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Attachments: HDFS-14509-001.patch, HDFS-14509-002.patch, > HDFS-14509-003.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16946135#comment-16946135 ] Chen Liang commented on HDFS-14509: --- I tested the v002 patch locally. {{TestMultipleNNPortQOP}} is related (others all passed). This is because HDFS-13699 added making changes to Block Access Token field at run-time, but if the value is cached at the initial {{readFields(...)}} call, it is always the unchanged old, cached value gets returned. I tried the fix by invalidating the cache on handshake message change, which is already something we do for {{setKeyId}} and {{setExpiryDate}}. Specifically, I changed {{BlockTokenIdentifier#setHandshakeMsg}} to be {code} public void setHandshakeMsg(byte[] bytes) { cache = null; // invalidate the cache handshakeMsg = bytes; } {code} With this change, the test passes. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Attachments: HDFS-14509-001.patch, HDFS-14509-002.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16946134#comment-16946134 ] Jonathan Hung commented on HDFS-14509: -- FYI the javac/compile issues should be fixed by HADOOP-16636. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Attachments: HDFS-14509-001.patch, HDFS-14509-002.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16944966#comment-16944966 ] Hadoop QA commented on HDFS-14509: -- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 58s{color} | {color:blue} Docker mode activated. {color} | || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 0s{color} | {color:green} The patch appears to include 1 new or modified test files. {color} | || || || || {color:brown} trunk Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 28s{color} | {color:blue} Maven dependency ordering for branch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 19m 4s{color} | {color:green} trunk passed {color} | | {color:red}-1{color} | {color:red} compile {color} | {color:red} 1m 48s{color} | {color:red} hadoop-hdfs-project in trunk failed. {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 54s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m 51s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 15m 39s{color} | {color:green} branch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m 15s{color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 46s{color} | {color:green} trunk passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 11s{color} | {color:blue} Maven dependency ordering for patch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m 41s{color} | {color:green} the patch passed {color} | | {color:red}-1{color} | {color:red} compile {color} | {color:red} 1m 37s{color} | {color:red} hadoop-hdfs-project in the patch failed. {color} | | {color:red}-1{color} | {color:red} javac {color} | {color:red} 1m 37s{color} | {color:red} hadoop-hdfs-project in the patch failed. {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 48s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m 41s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} shadedclient {color} | {color:green} 13m 35s{color} | {color:green} patch has no errors when building and testing our client artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m 47s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 40s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 52s{color} | {color:green} hadoop-hdfs-client in the patch passed. {color} | | {color:red}-1{color} | {color:red} unit {color} | {color:red}112m 46s{color} | {color:red} hadoop-hdfs in the patch failed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 42s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black}187m 19s{color} | {color:black} {color} | \\ \\ || Reason || Tests || | Failed junit tests | hadoop.hdfs.tools.TestDFSZKFailoverController | | | hadoop.hdfs.TestMultipleNNPortQOP | | | hadoop.hdfs.server.namenode.snapshot.TestRenameWithSnapshots | \\ \\ || Subsystem || Report/Notes || | Docker | Client=18.09.7 Server=18.09.7 Image:yetus/hadoop:1dde3efb91e | | JIRA Issue | HDFS-14509 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12982260/HDFS-14509-002.patch | | Optional Tests | dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle | | uname | Linux 944be578c543 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | trunk / f209722 | | maven | version:
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16944914#comment-16944914 ] Konstantin Shvachko commented on HDFS-14509: Updated [~John Smith]'s patch. Fixed some warnings, and added the second test. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Attachments: HDFS-14509-001.patch, HDFS-14509-002.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942284#comment-16942284 ] Jonathan Hung commented on HDFS-14509: -- Hey [~John Smith], since this is a blocker for 2.10.0 release, do you have an ETA for when we can get this in by? Thanks :) > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16940521#comment-16940521 ] Konstantin Shvachko commented on HDFS-14509: Hey [~John Smith]. Agreed we should apply to trunk and backport to 3.2, 3.1, and 2.10. With 2.10 we are trying to make it a bridge release, it should allow upgrading to 3.x. Let me clarify about the tests. Suppose that your fix is applied to 3.2 and 2.10, but not to 2.9. # One test should make sure that when we upgrade from 2.10 to 3.2 the passwords are verified correctly on DNs running 2.10. # Another test should verify that when upgrading from 2.9 (which does not have the fix) to 2.10 (which does) the passwords are verified correctly on DNs running 2.9. Hope it makes sense. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16940329#comment-16940329 ] Fei Hui commented on HDFS-14509: [~John Smith] Part of approach 1 will be good. We only consider the NN changes of approach 1, and with your fix we could upgrade to 3.x directly. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16940327#comment-16940327 ] Yuxuan Wang commented on HDFS-14509: [~ferhui] Oh, It's other approach can do, not my PR. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16940326#comment-16940326 ] Yuxuan Wang commented on HDFS-14509: {quote} As for unit tests I think we need two that verifies the upgrade from 2.x to 3.x is possible. that verifies the upgrade from 2.x-1 to 2.x is still possible. {quote} I don't understand the comment's meaning. What's 2.x-1 ? Patched with this patch ? And upgrade from 2.x to 3.x is impossible not possible? I'll improve UT and fix checkstyle together after I realize how to. I don't know your github ID, feel free to comment at PR. Thanks for your review [~shv]. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16940325#comment-16940325 ] Fei Hui commented on HDFS-14509: [~John Smith] {quote} NN 3.x does not include storage types into block token until the upgrade is finalized. {quote} During upgrading, NN does not use fields from HDFS-6708 and HDFS-9807.After finalizing NN could use it, with this we could upgrade to 3.x directly. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16940277#comment-16940277 ] Yuxuan Wang commented on HDFS-14509: [~John Smith] If we add some fields in the future, we still need this patch. Trunk is better. According to hadoop's doc, we should update NN first. At that time, the block token will have new fields attached which DN not upgraded yet can't recognize. So we have to backport it to 2.x branch and upgrade DN before upgrade to 3.x . Or I miss [~shv]'s some comment. Can you quote it ? [~ferhui] > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16940272#comment-16940272 ] Fei Hui commented on HDFS-14509: [~John Smith] If it's a general solution, I think target version is 3.x better. Is it? If combined with # 1 [~shv] said, we could upgrade to 3.x directly, do not have to upgrade an intermediate version > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16940266#comment-16940266 ] Yuxuan Wang commented on HDFS-14509: [~ferhui] If it's just for resolving upgrading from 2.x to 3.x, we need patch it before HDFS-6708 and HDFS-9807. But I think it's a general solution, I suggest to target to trunk and backport to 2.x branch. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16940264#comment-16940264 ] Fei Hui commented on HDFS-14509: Have one question Is target version is 2.x or both 2.x and 3.x? > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16940253#comment-16940253 ] Yuxuan Wang commented on HDFS-14509: [~brahmareddy] Yes, existing cluster might need to update this patch before upgrade. I have reopened PR, pending yetus and we can go ahead. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939658#comment-16939658 ] Brahma Reddy Battula commented on HDFS-14509: - [~shv] thanks for explanation. {quote}NN 3.x does not include storage types into block token until the upgrade is finalized. This will require changes on branch-3.x only. {quote} Yes,I was targeting existing 2.7 ( 2.8 or 2.6) versions where it can smooth upgrade(they can't port any issue before they plan for upgrade.). {quote}As I said #2 seems more general, so let's just go with it. If nobody objects. {quote} Should be fine with this approrach also, Existing cluster might need to update this patch before upgrade. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939016#comment-16939016 ] Jonathan Hung commented on HDFS-14509: -- Marking as 2.10.0 blocker as per discussion with [~shv] > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Labels: release-blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16938192#comment-16938192 ] Yuxuan Wang commented on HDFS-14509: OK, I'll update my PR later. Thanks for [~shv], [~vagarychen]'s comments. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16938114#comment-16938114 ] Chen Liang commented on HDFS-14509: --- I prefer the fix from [~John Smith], it's a pretty clever fix I would say. A nit: the current line of {{this.cache = null;}} at the beginning of {{readFields(DataInput in)}} seems no longer needed. I was a bit concerned with the fact that there is code where cache gets reset to null (i.e. {{setExpiryDate}} and {{setKeyId}}) and if {{getBytes}} gets called after cache got reset to null, {{cache = super.getBytes();}} will be called and we run into this same issue. But after more checking, it looks like {{setExpiryDate}} and {{setKeyId}} are only called at NN side when creating the token, so on DN side, once the cache is set, it stays at those bytes. So this should not be an issue. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16938086#comment-16938086 ] Konstantin Shvachko commented on HDFS-14509: So [~John Smith], do you want to update your PR or submit a patch here? With your current PR it seems that some tests are failing including the one that you added to {{TestBlockToken}}. Also worth looking at javac and checkstyle warning. As for unit tests I think we need two # that verifies the upgrade from 2.x to 3.x is possible. # that verifies the upgrade from 2.x-1 to 2.x is still possible. You should be able to cover both using your mocking approach in {{testRetrievePasswordWithUnknownFields()}}. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937309#comment-16937309 ] Konstantin Shvachko commented on HDFS-14509: As I said #2 seems more general, so let's just go with it. If nobody objects. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937300#comment-16937300 ] Yuxuan Wang commented on HDFS-14509: [~shv] Thanks for your explanation! That's what I mean! If someone determines which approach we choose, we can go follow. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937288#comment-16937288 ] Konstantin Shvachko commented on HDFS-14509: We should assume that protobuf for {{BlockTokenIdentifier}} is disabled, since DN 2.x cannot read proto. Then I see two ways to fix this # NN 3.x does not include storage types into block token until the upgrade is finalized. This will require changes on branch-3.x only. # DN 2.x uses all raw bytes received from NN (including storages) for calculating the password. Desalinization of these bytes will still omit storage fields. This should be uniformly changed on all branches up to 2.x. Looks like [~brahmareddy]'s patch goes in the direction of approach #1. While [~John Smith]'s PR assumes approach #2. Both should work, but it seems that #2 is more general. Since it will work if we ever decide to add more fields into the token. While with #1 we will have to explicitly exclude any new fields during upgrade. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936605#comment-16936605 ] Chengwei Wang commented on HDFS-14509: -- In my test cases, the issue exists when I try to upgrade our cluster from 2.6.0 to 3.2.0 (with HDFS-13596 ), and it can be fixed with the given patch. But I doubt whether it's better to exclude these fields by a specific configuration rather than check version every time in datanode even though the cluster has been upgraded to 3.x. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935174#comment-16935174 ] Wei-Chiu Chuang commented on HDFS-14509: If this patch has to be applied to 3.x, it would be prudent to add 3.1.3 and 3.2.1 to target versions, and stop the current 3.1.3/3.2.1 release vote. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932372#comment-16932372 ] Fei Hui commented on HDFS-14509: [~jojochuang] The issue exists after HDFS-13596 Password is different from 2.x and 3.x. [~brahmareddy] There is a problem the patch. One moment in time 1. Client get the password from NN( NN 2.x, DN 3.x, During upgrading) 2. After finalize upgrading done(NN 3.x, DN 3.x) 3. Client access DN. The password of client is different from password of DN(3.x) generate. Maybe it should compute password again if password mismatch > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16930209#comment-16930209 ] Yuxuan Wang commented on HDFS-14509: [~ferhui] Client's version is unimportant, since client just "forward" the block token without reading its fields. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926217#comment-16926217 ] Fei Hui commented on HDFS-14509: [~John Smith] During Rolling upgrade, NN is 3.x, and DN is 2.x , What is your client version? > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926109#comment-16926109 ] Wei-Chiu Chuang commented on HDFS-14509: [~ferhui] can you tell if this fix is still required after HDFS-13596? > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917352#comment-16917352 ] Yuxuan Wang commented on HDFS-14509: [~shv], we don't have a conclusion here. But my solution need both 3.x and 2.x apply a patch. I' ll attach a my later. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917060#comment-16917060 ] Konstantin Shvachko commented on HDFS-14509: Hi [~John Smith] , do I understand correctly the target version for this is 3.x, not 2.10? > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Blocker > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16891108#comment-16891108 ] Erik Krogen commented on HDFS-14509: Great, I will mark them all as blockers for a 2.10 release. Thanks for confirming [~John Smith]. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Major > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890619#comment-16890619 ] Yuxuan Wang commented on HDFS-14509: [~xkrogen], I've tested upgrading/downgrading between 2.x and 3.x in my company. It's ok if we patch HDFS-13596, HDFS-14551 and this jira. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Major > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888943#comment-16888943 ] Erik Krogen commented on HDFS-14509: [~John Smith] and [~brahmareddy], thanks for looking into this. Is this targeted as a fix for the 2.x line which will make it possible to rolling upgrade to 3.x? If so, I would like to mark it as a blocker for a 2.10 release, as one of the goals of that release is to ensure a proper rolling upgrade path from 2.x to 3.x. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Major > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888533#comment-16888533 ] Yuxuan Wang commented on HDFS-14509: I've created an PR about my thoughts. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Major > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857500#comment-16857500 ] Yuxuan Wang commented on HDFS-14509: Hi, [~brahmareddy]. If I add codes to {{BlockTokenIdentifier#readFields()}} like: {code:title=BlockTokenIdentifier.java|borderStyle=solid} public void readFields(DataInput in) throws IOException { { this.cache = IOUtils.readFullyToByteArray(dis); dis.reset(); } {code} And then it works for me. In my opinion, it doesn't break token's security. How about you? Is there any misunderstanding? > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Major > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855852#comment-16855852 ] Brahma Reddy Battula commented on HDFS-14509: - Uploaded the draft patch. Kindly review. i) Storagetypes will be considered only if the version is greater than 3.0.0. ( while creating the token) ii) Balancer isn't considered. [~kihwal] could you please take look. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Major > Attachments: HDFS-14509-001.patch > > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16847190#comment-16847190 ] Yuxuan Wang commented on HDFS-14509: Hi~, [~kihwal] [~brahmareddy], thanks for comment. It's the same issue as HDFS-6708 after I take a look. I wonder if we can use {{token.getIdentifier()}} instead of following when compute password. {code} public byte[] retrievePassword(BlockTokenIdentifier identifier) { ... return createPassword(identifier.getBytes(), key.getKey()); } {code} > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Major > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846858#comment-16846858 ] Brahma Reddy Battula commented on HDFS-14509: - {quote}Anyone can take a look? It's a bug or just I miss something? {quote} thanks for reporting,Yes,it's an issue, Even it was discussed here. BlockTokenIdentifier needs to be changes to support for old and new fields. > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Major > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846709#comment-16846709 ] Kihwal Lee commented on HDFS-14509: --- It is caused by HDFS-6708. Are you seeing failures? > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Major > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Commented] (HDFS-14509) DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x
[ https://issues.apache.org/jira/browse/HDFS-14509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846697#comment-16846697 ] Yuxuan Wang commented on HDFS-14509: Anyone can take a look? It's a bug or just I miss something? > DN throws InvalidToken due to inequality of password when upgrade NN 2.x to > 3.x > --- > > Key: HDFS-14509 > URL: https://issues.apache.org/jira/browse/HDFS-14509 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Yuxuan Wang >Priority: Major > > According to the doc, if we want to upgrade cluster from 2.x to 3.x, we need > upgrade NN first. And there will be a intermediate state that NN is 3.x and > DN is 2.x. At that moment, if a client reads (or writes) a block, it will get > a block token from NN and then deliver the token to DN who can verify the > token. But the verification in the code now is : > {code:title=BlockTokenSecretManager.java|borderStyle=solid} > public void checkAccess(...) > { > ... > id.readFields(new DataInputStream(new > ByteArrayInputStream(token.getIdentifier(; > ... > if (!Arrays.equals(retrievePassword(id), token.getPassword())) { > throw new InvalidToken("Block token with " + id.toString() > + " doesn't have the correct token password"); > } > } > {code} > And {{retrievePassword(id)}} is: > {code} > public byte[] retrievePassword(BlockTokenIdentifier identifier) > { > ... > return createPassword(identifier.getBytes(), key.getKey()); > } > {code} > So, if NN's identifier add new fields, DN will lose the fields and compute > wrong password. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org