hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hadoop QA (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-12983) HBase book mentions hadoop.ssl.enabled when it should be hbase.ssl.enabled
Date Mon, 10 Aug 2015 00:50:46 GMT

    [ https://issues.apache.org/jira/browse/HBASE-12983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14679440#comment-14679440

Hadoop QA commented on HBASE-12983:

{color:red}-1 overall{color}.  Here are the results of testing the latest attachment 
  against master branch at commit 5bdb0eb91290e306213bca62cea82c5d1b24d317.
  ATTACHMENT ID: 12749495

    {color:green}+1 @author{color}.  The patch does not contain any @author tags.

    {color:green}+0 tests included{color}.  The patch appears to be a documentation patch
that doesn't require tests.

    {color:green}+1 hadoop versions{color}. The patch compiles with all supported hadoop versions
(2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.0 2.7.0)

    {color:green}+1 javac{color}.  The applied patch does not increase the total number of
javac compiler warnings.

    {color:green}+1 protoc{color}.  The applied patch does not increase the total number of
protoc compiler warnings.

    {color:green}+1 javadoc{color}.  The javadoc tool did not generate any warning messages.

    {color:green}+1 checkstyle{color}.  The applied patch does not increase the total number
of checkstyle errors

    {color:green}+1 findbugs{color}.  The patch does not introduce any  new Findbugs (version
2.0.3) warnings.

    {color:green}+1 release audit{color}.  The applied patch does not increase the total number
of release audit warnings.

    {color:red}-1 lineLengths{color}.  The patch introduces the following lines longer than
    +To enable secure HTTP (HTTPS) connections instead, set `hbase.ssl.enabled` to `true`
in _hbase-site.xml_.
+ZooKeeper has a pluggable authentication mechanism to enable access from clients using different
methods. ZooKeeper even allows authenticated and un-authenticated clients at the same time.
The access to znodes can be restricted by providing Access Control Lists (ACLs) per znode.
An ACL contains two components, the authentication method and the principal. ACLs are NOT
enforced hierarchically. See link:https://zookeeper.apache.org/doc/r3.3.6/zookeeperProgrammers.html#sc_ZooKeeperPluggableAuthentication[ZooKeeper
Programmers Guide] for details.
+HBase daemons authenticate to ZooKeeper via SASL and kerberos (See <<zk.sasl.auth>>).
HBase sets up the znode ACLs so that only the HBase user and the configured hbase superuser
(`hbase.superuser`) can access and modify the data. In cases where ZooKeeper is used for service
discovery or sharing state with the client, the znodes created by HBase will also allow anyone
(regardless of authentication) to read these znodes (clusterId, master address, meta location,
etc), but only the HBase user can modify them.
+All of the data under management is kept under the root directory in the file system (`hbase.rootdir`).
Access to the data and WAL files in the filesystem should be restricted so that users cannot
bypass the HBase layer, and peek at the underlying data files from the file system. HBase
assumes the filesystem used (HDFS or other) enforces permissions hierarchically. If sufficient
protection from the file system (both authorization and authentication) is not provided, HBase
level authorization control (ACLs, visibility labels, etc) is meaningless since the user can
always access the data from the file system.
+In secure mode, SecureBulkLoadEndpoint should be configured and used for properly handing
of users files created from MR jobs to the HBase daemons and HBase user. The staging directory
in the distributed file system used for bulk load (`hbase.bulkload.staging.dir`, defaults
to `/tmp/hbase-staging`) should have (mode 711, or `rwx--x--x`) so that users can access the
staging directory created under that parent directory, but cannot do any other operation.
See <<hbase.secure.bulkload>> for how to configure SecureBulkLoadEndPoint.

  {color:green}+1 site{color}.  The mvn post-site goal succeeds with this patch.

     {color:red}-1 core tests{color}.  The patch failed these unit tests:

     {color:red}-1 core zombie tests{color}.  There are 1 zombie test(s): 	at org.apache.hadoop.hbase.util.TestDrainBarrier.testStopIsBlockedByOps(TestDrainBarrier.java:98)

Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/15018//testReport/
Release Findbugs (version 2.0.3) 	warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/15018//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors: https://builds.apache.org/job/PreCommit-HBASE-Build/15018//artifact/patchprocess/checkstyle-aggregate.html

  Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/15018//console

This message is automatically generated.

> HBase book mentions hadoop.ssl.enabled when it should be hbase.ssl.enabled
> --------------------------------------------------------------------------
>                 Key: HBASE-12983
>                 URL: https://issues.apache.org/jira/browse/HBASE-12983
>             Project: HBase
>          Issue Type: Bug
>          Components: documentation
>            Reporter: Esteban Gutierrez
>            Assignee: Misty Stanley-Jones
>         Attachments: HBASE-12983.patch
> In the HBase book we say the following:
> {quote}
> A default HBase install uses insecure HTTP connections for web UIs for the master and
region servers. To enable secure HTTP (HTTPS) connections instead, set *hadoop.ssl.enabled*
to true in hbase-site.xml. This does not change the port used by the Web UI. To change the
port for the web UI for a given HBase component, configure that port’s setting in hbase-site.xml.
These settings are:
> {quote}
> The property should be *hbase.ssl.enabled* instead. 

This message was sent by Atlassian JIRA

View raw message