[GitHub] [hbase] bitterfox edited a comment on pull request #3591: HBASE-26204 Obtain credential for VerifyReplication with peerQuorumAddress

[GitBox <gi...@apache.org>]

bitterfox edited a comment on pull request #3591:
URL: https://github.com/apache/hbase/pull/3591#issuecomment-900194011


   Thank you for your comments.
   
   > Can we add explanation on how to use this in the printUsage method?
   
   I see. I'll check the current usage first.
   
   > What if the remote peer isn't kerberised? I guess initCredentialsForCluster call would throw an exception?
   
   I think there are several cases as you mentioned, but in general, initCredentialsForCluster shouldn't throw exceptions and do nothing for non-kerberos cluster configuration(connection).
   https://github.com/apache/hbase/blob/721cb96f8c543ed4f8cb2ba3a1196f98fa8bd26a/hbase-mapreduce/src/main/java/org/apache/hadoop/hbase/mapreduce/TableMapReduceUtil.java#L589
   
   I know initCredentialsForCluster is odd as another issue.
   https://issues.apache.org/jira/browse/HBASE-26205
   https://github.com/apache/hbase/pull/3592
   
   Current initCredentialsForCluster won't work for the following case and I'd like to fix it in HBASE-26205 (#3592) as indivisual change (because initCredentialsForCluster is common feature)
   - cluster A is non-secure(hbase.security.authentication=simple in job conf), cluster B is secure(hbase.security.authentication=kerberos in cluster conf)
   - cluster A is secure(hbase.security.authentication=kerberos in job conf), cluster B is non-secure(hbase.security.authentication=simple in cluster conf)
   
   > Since we are making VerifyReplication a general comparison tool (not replication specific anymore), shouldn't we cover all possible scenarios (unsecure/secure, secure/secure, secure/unsecure, unsecure/unsecure)?
   
   Yes, it could handle either combination with configuration for the VerifyReplication execution.
   
   For example, these is some examples of the execution for the combinations.
   (Please make sure, #3592 is necessary for mixed env)
   ```
   # non-secure vs secure (as well as for opposite)
   hbase VerifyReplication \
     -D hbase.security.authentication=simple \
     -D hbase.zookeeper.quorum=non-secure-hbase-a-1.example.com,non-secure-hbase-a-2.example.com,non-secure-hbase-a-3.example.com \
     -D hbase.zookeeper.property.clientPort=2181 \
     -D zookeeper.znode.parent=/hbase-a
     -D verifyrep.peer.hbase.security.authentication=kerberos \
     -D verifyrep.peer.hbase.regionserver.kerberos.principal=secure-hbase-b/_HOST@EXAMPLE.COM \
     -D verifyrep.peer.hbase.master.kerberos.principal=secure-hbase-b/_HOST@EXAMPLE.COM \
     ... \
     secure-hbase-b-1.example.com,secure-hbase-b-2.example.com,secure-hbase-b-3.example.com:2181:/hbase-b \
     table
   
   # secure vs secure (use different principal for cluster daemons)
   hbase VerifyReplication \
     -D hbase.security.authentication=kerberos \
     -D hbase.zookeeper.quorum=secure-hbase-a-1.example.com,secure-hbase-a-2.example.com,secure-hbase-a-3.example.com \
     -D hbase.zookeeper.property.clientPort=2181 \
     -D zookeeper.znode.parent=/hbase-a
     -D hbase.regionserver.kerberos.principal=secure-hbase-a/_HOST@EXAMPLE.COM \
     -D hbase.master.kerberos.principal=secure-hbase-a/_HOST@EXAMPLE.COM \
     -D verifyrep.peer.hbase.regionserver.kerberos.principal=secure-hbase-b/_HOST@EXAMPLE.COM \
     -D verifyrep.peer.hbase.master.kerberos.principal=secure-hbase-b/_HOST@EXAMPLE.COM \
     ... \
     secure-hbase-b-1.example.com,secure-hbase-b-2.example.com,secure-hbase-b-3.example.com:2181:/hbase-b \
     table
   ```
   
   > Any chance to add UTs?
   
   I'll try it.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@hbase.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org