不多說，直接上干貨！
問題詳情
查看/var/log/cloudera-scm-server.log的啟動日志
問題來源
我在用cloudermanager安裝好之后，然后，在對如下。
配置kerberos后，在web界面重啟服務ok。
但有一個警告：Cloudera recommends at least Level 1 TLS when Kerberos is enabled for CDH clusters.
設置好上面之后，我再
vim /etc/cloudera-scm-agent/config.ini配置文件
然后，就再重啟service cloudera-scm-server restart 服務，但一直起不來，報錯如下：
2016-05-24 15:31:54,843 INFO MainThread:org.mortbay.log: jetty-6.1.26.cloudera.4 2016-05-24 15:31:54,888 WARN MainThread:org.mortbay.log: failed SslSelectChannelConnector@0.0.0.0:7182: java.io.FileNotFoundException: /var/lib/cloudera-scm-server/.keystore (沒有那個文件或目錄) 2016-05-24 15:31:54,888 WARN MainThread:org.mortbay.log: failed Server@17a7ad7b: java.io.FileNotFoundException: /var/lib/cloudera-scm-server/.keystore (沒有那個文件或目錄) 2016-05-24 15:31:54,889 ERROR MainThread:com.cloudera.server.cmf.Main: Failed to start Agent listener. 2016-05-24 15:31:54,889 ERROR MainThread:com.cloudera.server.cmf.Main: Server failed. org.apache.avro.AvroRuntimeException: java.io.FileNotFoundException: /var/lib/cloudera-scm-server/.keystore (No such file or directory) at com.cloudera.server.common.HttpConnectorServer.start(HttpConnectorServer.java:89) at com.cloudera.server.cmf.Main.startAgentServer(Main.java:571) at com.cloudera.server.cmf.Main.startAvro(Main.java:483) at com.cloudera.server.cmf.Main.run(Main.java:620) at com.cloudera.server.cmf.Main.main(Main.java:217) Caused by: java.io.FileNotFoundException: /var/lib/cloudera-scm-server/.keystore (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.<init>(FileInputStream.java:146) at org.mortbay.resource.FileResource.getInputStream(FileResource.java:275) at org.mortbay.jetty.security.SslSelectChannelConnector.createSSLContext(SslSelectChannelConnector.java:639) at org.mortbay.jetty.security.SslSelectChannelConnector.doStart(SslSelectChannelConnector.java:613) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.Server.doStart(Server.java:235) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at com.cloudera.server.common.HttpConnectorServer.start(HttpConnectorServer.java:87) ... 4 more
但是，我的確，進入/var/lib/cloudera-scm-server目錄里去看了。沒有 /var/lib/cloudera-scm-server/.keystore 這個文件的確不存在的，要如何解決這個問題呢？
原理
了解Hadoop Kerberos安全機制
http://www.aboutyun.com/forum.php?mod=viewthread&tid=9943
如何產生，大家可以參考官網：
http://www.cloudera.com/documentation/enterprise/5-2-x/topics/cm_sg_create_key_trust.html
下面的解決辦法，官網給的太正式了，網上參考資料甚少。
倒是， 我總結了如下的一個解決辦法，大家可以先去嘗試下。（我是按照這個方法解決了的）
方法1
tls安全協議是用的壓縮算法 它會記錄 所以可能需要把元數據庫全清了 重新裝了！！！
注意：是只刪除數據庫（比如我這里用的是mysql）的元數據庫（即ambari），而不是刪除數據庫（mysql）啊！！！一定要注意了。
方法2（推薦）
All Cloudera Manager Server Configuration Properties are inside a embed postgreSQL database. You need change the value true to false in "agent_tls" column -> "configs" table -> "scm" database. Restart Cluster.
http://www.cloudera.com/documentation/enterprise/5-5-x/topics/cm_ig_embed_pstgrs.html
參考來源於
https://community.cloudera.com/t5/Cloudera-Manager-Installation/Cannot-log-in-to-Cloudera-Manager-no-TLS-keystore/td-p/42312
國內有人翻譯做過來
How to change the Cloudera Manager Properties in postgres
bigdata@nssa-sensor1:~$ sudo mysql -uroot -proot Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 329 Server version: 5.5.35-1ubuntu1 (Ubuntu) Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | ambari | | amon | | hive | | hue | | mysql | | oozie | | performance_schema | | scm | +--------------------+ 9 rows in set (0.00 sec) mysql> use scm; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> show tables; +--------------------------------+ | Tables_in_scm | +--------------------------------+ | AUDITS | | CLIENT_CONFIGS | | CLIENT_CONFIGS_TO_HOSTS | | CLUSTERS | | CLUSTERS_AUD | | CLUSTER_ACTIVATED_RELEASES | | CLUSTER_ACTIVATED_RELEASES_AUD | | CLUSTER_MANAGED_RELEASES | | CLUSTER_UNDISTRIBUTED_RELEASES | | CM_PEERS | | CM_VERSION | | COMMANDS | | COMMAND_SCHEDULES | | CONFIGS | | CONFIGS_AUD | | CONFIG_CONTAINERS | | CREDENTIALS | | DIAGNOSTICS_EVENTS | | EXTERNAL_ACCOUNTS | | EXTERNAL_ACCOUNTS_AUD | | GLOBAL_SETTINGS | | HOSTS | | HOSTS_AUD | | HOST_TEMPLATES | | HOST_TEMPLATE_TO_ROLE_CONF_GRP | | METRICS | | PARCELS | | PARCEL_COMPONENTS | | PROCESSES | | PROCESS_ACTIVE_RELEASES | | RELEASES | | RELEASES_AUD | | REVISIONS | | ROLES | | ROLES_AUD | | ROLE_CONFIG_GROUPS | | ROLE_CONFIG_GROUPS_AUD | | ROLE_STALENESS_STATUS | | SCHEMA_VERSION | | SERVICES | | SERVICES_AUD | | SNAPSHOT_POLICIES | | USERS | | USER_ROLES | | USER_SETTINGS | +--------------------------------+ 45 rows in set (0.00 sec) mysql>
官網（太復雜）
方法一：解決辦法
Creating Java Keystores and Truststores（創建Java密鑰庫和信任庫）
- The keystore contains private keys and certificates used by SSL servers to authenticate themselves to SSL clients. By convention, such files are referred to as keystores.
- When used as a truststore, the file contains certificates of trusted SSL servers, or of Certificate Authorities trusted to identify servers. There are no private keys in the truststore.
翻譯就是：
密鑰庫包含SSL服務器使用的私鑰和證書，以便向SSL客戶端進行身份驗證。 按照慣例，這樣的文件被稱為密鑰庫。
當用作信任庫時，該文件包含可信SSL服務器或可信任標識服務器的證書頒發機構的證書。 信托商店中沒有私鑰。
Note: The foregoing assumes that certificate-based authentication is being used in one direction only—that is, SSL servers are using certificates to authenticate themselves to clients. It is also possible for clients to authenticate themselves to servers using certificates. (This is known as mutual authentication.) Throughout this document, we assume that client certificates are not in use.
翻譯就是：
注意：前面假設僅在一個方向上使用基於證書的身份驗證，即SSL服務器正在使用證書向客戶端進行身份驗證。 客戶端也可以使用證書對服務器進行身份驗證。 （這被稱為相互認證。）在本文檔中，我們假設客戶端證書不被使用。
While all SSL clients must have access to a truststore, it is not always necessary to create and deploy truststores across a cluster. The standard JDK distribution includes a default truststore which is pre-provisioned with the root certificates of a number of well-known Certificate Authorities. If you do not provide a custom truststore, the Hadoop daemons load this default truststore. Therefore, if you are using certificates issued by a CA in the default truststore, you do not need to provide custom truststores. However, you must consider the following before you decide to use the default truststore:
翻譯就是：
雖然所有SSL客戶端都必須具有對信任庫的訪問權限，但並不總是需要在群集中創建和部署信托庫。 標准JDK分發包括一個默認的信任商店，該默認信任商店預先配置了許多知名證書頒發機構的根證書。 如果您不提供自定義信任庫，Hadoop守護進程將加載該默認信任庫。 因此，如果您使用默認信任庫中的CA頒發的證書，則不需要提供自定義的信任庫。 但是，在決定使用默認信任庫之前，您必須考慮以下事項：
- If you choose to use the default truststore, it is your responsibility to maintain it. You may need to remove the certificates of CAs you do not deem trustworthy, or add or update the certificates of CAs you trust. Use the keytool utility to perform these actions.
翻譯就是：
如果您選擇使用默認信任庫，則有責任維護它。 您可能需要刪除不認為可靠的CA證書，或者添加或更新您信任的CA證書。 使用keytool實用程序來執行這些操作。
Continue reading:
然后，我們繼續閱讀下去。
Security Considerations for Keystores and Truststores
（密鑰庫和信任域的安全注意事項）
注意：雖然您選擇的證書部署策略最終將取決於您希望實施的安全策略，但以下准則可能有用。
Because keystores contain private keys, while truststores do not, the security requirements for keystores are more stringent. In particular:
- Hadoop SSL requires that truststores and the truststore password be stored, in plaintext, in a configuration file that is readable by all.
- Keystore and key passwords are stored, in plaintext, in a file that is readable only by members of the appropriate group.
These considerations should inform your choice of which keys and certificates to store in the keystores and truststores you will deploy across your cluster.
- Keystores should contain a minimal set of keys and certificates. A reasonable strategy would be to create a unique keystore for each host, which would contain only the keys and certificates needed by the Hadoop SSL services running on the host. In most cases, the keystore would contain a single key/certificate entry.
- On the other hand, because truststores do not contain sensitive information, it is reasonable to create a single truststore for an entire cluster. On a production cluster, such a truststore would often contain a single CA certificate (or certificate chain), since you would typically choose to have all certificates issued by a single CA.
- Important: Do not use the same password for truststores and keystores/keys.Since truststore passwords are stored in the clear in files readable by all, doing so would compromise the security of the private keys in the keystore.
翻譯就是：
由於密鑰庫包含私鑰，而信任庫不存在，密鑰庫的安全性要求更為嚴格。尤其是：
Hadoop SSL要求信任庫和信任密碼以明文方式存儲在所有可讀的配置文件中。
密鑰庫和密鑰密碼以明文形式存儲在只能由適當組的成員讀取的文件中。
這些注意事項應該通知您選擇要在集群中部署的密鑰庫和信任庫中存儲哪些密鑰和證書。
密鑰庫應包含一組最小的密鑰和證書。合理的策略是為每個主機創建唯一的密鑰庫，其中只包含主機上運行的Hadoop SSL服務所需的密鑰和證書。在大多數情況下，密鑰庫將包含單個密鑰/證書條目。
另一方面，由於信任庫不包含敏感信息，因此為整個集群創建單個信任庫是合理的。在生產集群上，這樣的信任商店通常會包含單個CA證書（或證書鏈），因為您通常會選擇由單個CA頒發所有證書。
重要信息：請勿對信任庫和密鑰庫/密鑰使用相同的密碼。
由於信任密碼存儲在所有可讀的文件中，這樣做會危及密鑰庫中私鑰的安全性。
Creating Keystores（床架密鑰庫）
Once you have settled on a storage plan for your keys and certificates, you can use keytool to create or update the necessary keystores and truststores. To create a new keystore with a certificate see Creating Certificates.
In many cases, you will already have created the set of keystores that you need. If you have followed the approach of creating a separate keystore for each private key and certificate, and wish to maintain this arrangement when deploying the keystores, no additional steps are required to prepare the keystores for deployment. If you wish to reorganize your keys and certificates into a different set of keystores, you can use keytool -importkeystore to transfer entries from one keystore to another.
翻譯就是：
創建密鑰庫
一旦確定了密鑰和證書的存儲計划，您可以使用keytool來創建或更新必要的密鑰庫和信任庫。 要使用證書創建新密鑰庫，請參閱 Creating Certificates。
在許多情況下，您將已經創建了所需的一組密鑰庫。 如果您遵循為每個私鑰和證書創建單獨密鑰庫的方法，並希望在部署密鑰庫時保持此安排，則無需准備其他部署步驟即可部署密鑰庫。 如果您希望將密鑰和證書重組為不同的密鑰庫，則可以使用keytool -importkeystore將條目從一個密鑰庫傳輸到另一個密鑰庫。
然后，接着閱讀
Creating Certificates（創建證書）
一、Creating Certificates（創建證書）
The following sections will walk you through obtaining certificates from commercial Certificate Authorities and creating self-signed test certificates.
- Using Keytool
- Using OpenSSL
- Obtaining a Production Certificate from a Commercial CA
- Creating Self-Signed Test Certificates
翻譯就是：
以下部分將引導您從商業證書頒發機構獲取證書並創建自簽名測試證書。
（1）使用Keytool
（2）使用OpenSSL
（3）從商業CA獲得生產證書
（4）創建自簽名測試證書
Using Keytool（使用keytool）
Keytool is a utility for creating and managing certificates and cryptographic keys, and is part of the standard JDK distribution. The keytool executable usually resides in $JAVA_HOME/bin.
Keytool stores certificates and keys in a file known as a keystore . While several different keystore types are supported, by default keytool uses the Java KeyStore (JKS) format.
Java-based services such as HDFS, MapReduce, and YARN use the JKS format by default. For this reason it is particularly convenient to use keytool for managing keys and certificates for these services. In the following topics, we assume you are using keytool.
For additional information on keytool, refer the keytool documentation.
翻譯就是：
Keytool是用於創建和管理證書和加密密鑰的實用程序，是標准JDK發行版的一部分。 keytool可執行文件通常駐留在$ JAVA_HOME / bin中。
Keytool將證書和密鑰存儲在稱為密鑰庫的文件中。 雖然支持幾種不同的密鑰庫類型，但默認情況下，keytool使用Java KeyStore（JKS）格式。
默認情況下，基於Java的服務（如HDFS，MapReduce和YARN）使用JKS格式。 因此，使用keytool來管理這些服務的密鑰和證書是特別方便的。 在以下主題中，我們假設您正在使用keytool。
有關keytool的其他信息，請參閱keytool文檔。
Using OpenSSL（使用OpenSSL）
Python-based services such as Hue expect certificates and keys to be stored in PEM format. When managing certificates and keys for such services, you may find it convenient to use the openssl tool.
Refer the openssl documentation for more information.
翻譯就是：
基於Python的服務，如Hue，期望證書和密鑰以PEM格式存儲。 在管理這些服務的證書和密鑰時，您可能會發現使用openssl工具很方便。
有關更多信息，請參閱openssl文檔。
Obtaining a Production Certificate from a Commercial CA（從商業CA獲得生產證書）
Once you have decided on a certificate-provisioning strategy, and have determined which hosts require certificates, you will typically purchase the necessary certificates from a commercial Certificate Authority (CA). The procedure for applying for a certificate varies from one CA to another, but typically involves providing some form of proof that you are the legitimate owner of the domain name for which you are requesting a certificate, generating a key pair, and submitting a Certificate Signing Request (CSR) to the CA.
翻譯就是：
一旦您決定了證書配置策略，並確定哪些主機需要證書，您通常將從商業認證機構（CA）購買必要的證書。 申請證書的過程從一個CA到另一個CA不同，但通常涉及提供某種形式的證明，證明您是要求證書的域名的合法所有者，生成密鑰對並提交證書簽名 請求（CSR）到CA。
As noted above, you may find it convenient to use the Java keytool utility to generate your key pair and CSR, and to manage your certificates. The CA you choose will provide instructions for obtaining and installing a certificate; typically, there will be separate sets of instructions for different web and application servers. The instructions for Java-based servers (Tomcat, for example), will usually describe the following process comprising three keytool commands to obtain a certificate:
翻譯就是：
如上所述，您可能會發現使用Java keytool實用程序可以方便地生成密鑰對和CSR，並管理證書。 您選擇的CA將提供獲取和安裝證書的說明; 通常，對於不同的web和應用服務器將存在單獨的指令集。 基於Java的服務器（例如，Tomcat）的說明通常將描述以下過程，包括三個keytool命令來獲取證書：
- keytool -genkeypair to generate a public/private key pair and create the keystore.
- keytool -certreq to create the CSR.
- keytool -importcert to import the signed certificate into the keystore.
翻譯就是：
keytool -genkeypair生成公鑰/私鑰對並創建密鑰庫。
keytool -certreq來創建CSR。
keytool -importcert將簽名的證書導入密鑰庫。
For example, to generate a public/private key pair for the domain name node1.example.com, you would use a command similar to the one shown below:
翻譯就是：
例如，要為域名node1.example.com生成公鑰/私鑰對，您將使用類似於以下所示的命令：
$ keytool -genkeypair -keystore node1.keystore -alias node1 \ -dname "CN=node1.example.com,O=Hadoop" -keyalg RSA \ -keysize 2048 -storepass changeme -keypass changeme
This command generates a pair of 2048-bit keys using the RSA key algorithm, one of several available. The keys are stored in a keystore file called node1.keystore, in a keystore entry identified by by the alias node1. The keystore password (which protects the keystore as a whole) and the key password (which protects the private key stored in the node1 entry) are set using the -storepass and -keypass options (respectively). -keypassmust be set to the same password value as -storepass for Cloudera Manager to access the keystore.
翻譯就是：
該命令使用RSA密鑰算法生成一對2048位密鑰，其中有幾種可用。 密鑰存儲在名為node1.keystore的密鑰庫文件中，位於由別名node1標識的密鑰庫條目中。 分別使用-storepass和-keypass選項設置密鑰庫密碼（保護密鑰庫作為整體）和密鑰密碼（保護存儲在node1條目中的私鑰）。 必須將-keypass設置為與Cloudera Manager的-storepass相同的密碼值才能訪問密鑰庫。
To create a CSR, you would use a command similar to the following:
翻譯就是:
要創建CSR，您將使用類似於以下命令：
$ keytool -certreq -keystore node1.keystore -alias node1 \
-storepass changeme -keypass changeme -file node1.csr
This command generates the CSR, and stores it in a file called node1.csr. Once you've submitted your CSR to the CA, and received the CA's reply (containing the signed certificate), you will use the following keytool -importcert command to import the reply into your keystore:
翻譯就是：
此命令生成CSR，並將其存儲在名為node1.csr的文件中。 一旦您將CSR提交給CA，並收到CA的回復（包含簽名的證書），您將使用以下keytool -importcert命令將回復導入您的密鑰庫：
$ keytool -importcert -keystore node1.keystore -alias node1 \
-storepass changeme -keypass changeme -trustcacerts -file node1.crt
Here we assume that the CA's reply is stored in the file node1.crt.
翻譯就是：
這里我們假設CA的回復存儲在文件node1.crt中。
要點：本節介紹使用keytool從商業證書頒發機構獲取證書的一般過程。 此過程將因CA與另一CA不同而有所不同，Cloudera建議您參考CA的文檔以了解更多詳細信息。
Creating Self-Signed Test Certificates
It is also possible to create your own test certificates. These certificates are typically self-signed; that is, they are signed by your own private key, rather than that of an external CA. Such test certificates are useful during testing and bringup of a cluster.
也可以創建自己的測試證書。 這些證書通常是自簽名的; 也就是說，它們由您自己的私鑰簽名，而不是外部CA的密鑰。 這樣的測試證書在測試和啟動集群期間很有用。
要生成自簽名證書，請使用keytool -genkeypair。 （除了創建公鑰/私鑰對之外，此命令將公鑰包裝到自簽名證書中。）例如，以下命令為主機 node1.example.com創建一個自簽名測試證書，並存儲 它在密鑰庫中）
$ keytool -genkeypair -keystore node1.keystore -keyalg RSA \ -alias node1 -dname "CN=node1.example.com O=Hadoop" \ -storepass changeme -keypass changeme
Set -keypass to the same value as -storepass. Cloudera Manager assumes that the same password is used to access both the key and the keystore, and therefore, does not support separate values for -keypass and -storepass.
翻譯就是：
將-keypass設置為與-storepass相同的值。 Cloudera Manager假定使用相同的密碼訪問密鑰庫和密鑰庫，因此不支持-keypass和-storepass的單獨值。
然后接着
二、Creating Truststores（創建信任域）
- If you are using the default truststore, you may need to add CA certificates (or certificate chains) to the truststore, or delete them from the truststore.
- If you are creating custom truststores, you will need to build the truststores by importing trusted certificates into new truststores. The trusted certificates can be CA certificates (typically downloaded from the CA's website), or self-signed certificates that you have created.
As shown in the examples below, when creating a truststore you must select a password. All truststore passwords for a given service must be the same. In practice, this restriction rarely comes into play, since it is only relevant when you wish to create distinct custom truststores for each host.
The following sections provide examples of the steps required for several common scenarios:
翻譯就是：
准備在部署中使用的信任庫所涉及的步驟取決於您是否決定使用默認Java信任庫，還是創建自定義信任庫：
如果您使用默認的信任庫，則可能需要將CA證書（或證書鏈）添加到信任庫中，或者從信任庫中刪除它們。
如果要創建自定義信任庫，則需要通過將受信任的證書導入新的信任庫來構建信任庫。受信任的證書可以是CA證書（通常從CA的網站下載）或您創建的自簽名證書。
如下面的示例所示，創建信任庫時，您必須選擇一個密碼。給定服務的所有信任密碼必須相同。實際上，這種限制很少發揮作用，因為只有當您希望為每個主機創建不同的自定義信任庫時，這種限制才是有用的。
以下部分提供了幾個常見場景所需步驟的示例：
Example 1: Adding a CA Certificate to the alternative Default Truststore（將CA證書添加到備用的默認信任域）
In this example, we assume that you have chosen to use the default Java truststore, but have obtained a certificate from a CA not included in the truststore. (This situation can also arise if the CA that issued your certificate has an entry in the default truststore, but the particular certificate product you purchased requires an alternate CA certificate chain.)
- Locate the default truststore on your system. The default truststore is located in the $JAVA_HOME/jre/lib/security/cacerts file. This contains the default CA information shipped with the JDK. Create an alternate default file called jssecacerts in the same location as the cacerts file. You can now safely append CA certificates for any private or public CAs not present in the default cacerts file, while keeping the original file intact.
The alternate file will always be read unless the javax.net.ssl.trustStore flag is set in the arguments for the startup of the java process.
For our example, we will be following this recommendation by copying the default cacerts file into the new jssecacerts file.
翻譯就是：
在此示例中，我們假設您已選擇使用默認的Java信任庫，但已從不包含在信任庫中的CA獲取證書。 （如果發出證書的CA在默認信任庫中有一個條目，但是您購買的特定證書產品需要備用CA證書鏈，則也可能會出現這種情況。）
找到系統上的默認信任庫。默認的truststore位於$ JAVA_HOME / jre / lib / security / cacerts文件中。這包含JDK附帶的默認CA信息。在與cacerts文件相同的位置創建一個名為jssecacerts的備用默認文件。您現在可以安全地為默認cacerts文件中不存在的任何私有或公共CA安全地附加CA證書，同時保持原始文件不變。
除非在java進程啟動的參數中設置javax.net.ssl.trustStore標志，否則備用文件將始終被讀取。
對於我們的示例，我們將通過將默認cacerts文件復制到新的jssecacerts文件中來執行此建議。
$ cp $JAVA_HOME/jre/lib/security/cacerts \ $JAVA_HOME/jre/lib/security/jssecacerts
If you use a copy of the cacerts file, remember the default keystore password is changeit.
翻譯就是：
如果您使用cacerts文件的副本，請記住默認密鑰庫密碼為changeit。
2、Import the CA certificate into the default truststore. Assuming that the file myCA-root.cer contains the CA’s certificate, which you have previously downloaded from the CA’s web site, the following command imports this certificate into the alternative default truststore。
Note: Test the trust relationship before you import any intermediary CA certificates. Trust should be derived from the root CA only. Import intermediary CA certificates only if necessary.
翻譯就是：
將CA證書導入默認的信任庫。 假設文件myCA-root.cer包含先前從CA的網站下載的CA的證書，則以下命令會將此證書導入備用的默認信任庫。
注意：在導入任何中間CA證書之前，請先測試信任關系。 信任應僅從根CA派生。 僅在必要時才導入中間CA證書。
$ keytool -importcert -file myCA-root.cer -alias myCA \ -keystore /usr/java/default/jre/lib/security/jssecacerts \ -storepass changeit
When you give this command, you will be prompted to confirm that you trust the certificate. Be sure to verify that the certificate is genuine before importing it.
Important: Any updates you make to the default truststore must be made on all hosts in the cluster.
翻譯就是：
當您給出此命令時，系統將提示您確認您信任該證書。 在導入證書之前，請確保證書是真實的。
重要提示：必須對集群中的所有主機進行對默認信任庫的任何更新。
Example 2: Creating a Custom Truststore Containing a Single CA Certificate Chain（創建包含單個CA證書鏈的自定義信任域）
In this example, we demonstrate how to use keytool to create a custom truststore. We assume all certificates were issued by a single CA, so a truststore containing the certificate chain for that CA will serve for all hosts in the cluster.
Our example certificate chain consists of a root certificate and a single intermediate certificate. We assume that you have downloaded these and saved them in the files myCA-root.cer and myCA-intermediate.cer(respectively). The steps below show the commands needed to build a custom truststore containing the root and intermediate certificates.
示例2：
在這個例子中，我們演示了如何使用keytool來創建自定義的信任庫。 我們假設所有證書都由單個CA頒發，因此包含該CA的證書鏈的信任庫將為集群中的所有主機提供服務。
我們的示例證書鏈由根證書和單個中間證書組成。 我們假設您已經下載這些文件並將它們保存在文件myCA-root.cer和myCA-intermediate.cer（分別）中。 以下步驟顯示構建包含根證書和中間證書的自定義信任庫所需的命令。
- Import the root certificate and create the truststore:
$ keytool -importcert -keystore my.truststore -alias myCA-root \ -storepass trustchangeme -file myCA-root.cer
You will be prompted to confirm that the root certificate is trustworthy. Be sure to verify that the certificate is genuine before you import it.
翻譯就是：
導入根證書並創建信任庫：
系統將提示您確認根證書是否值得信賴。 在導入證書之前，請確保證書是真實的。
2、 Import the intermediate certificate into the truststore created in Step 1:
$ keytool -importcert -keystore my.truststore \ -alias myCA-intermediate -storepass trustchangeme \ -file myCA-intermediate.cer
翻譯就是：將中間證書導入到步驟1中創建的信任庫：
Example 3: Creating a Custom Truststore Containing Self-Signed Test Certificates（創建包含自簽名測試證書的自定義信任商店）
This example is particularly relevant when setting up a test cluster. We assume that you have generated a set of self-signed test certificates for the hosts in the cluster, and wish to create a single truststore that can be deployed on all hosts. Because the certificates are self-signed, we cannot simply construct a truststore containing a single certificate chain, as in the previous example. When a client receives a self-signed certificate from a server during the SSL handshake, it must be able to find the server’s certificate in the truststore, since no other signing certificate exists to establish trust. Therefore, the truststore must contain all the test certificates.
We assume that the test certificates reside in keystores named node1.keystore … node100.keystore, which were created following the steps described in Creating Self-Signed Test Certificates.
翻譯就是：
重要提示：Cloudera強烈建議不要在生產群集中使用自簽名證書。
此示例在設置測試集群時特別有用。我們假設您為集群中的主機生成了一組自簽名測試證書，並希望創建一個可以在所有主機上部署的信任庫。因為證書是自簽名的，所以我們不能簡單地構建一個包含單個證書鏈的信任庫，如前面的例子所示。當客戶端在SSL握手期間從服務器接收到自簽名證書時，它必須能夠在信任庫中找到服務器的證書，因為不存在建立信任的其他簽名證書。因此，信任庫必須包含所有測試證書。
我們假定測試證書位於名為node1.keystore ... node100.keystore的密鑰庫中，它們是按照創建自簽名測試證書中描述的步驟創建的。
- Export the test certificate for node1.example.com:
$ keytool -exportcert -keystore node1.keystore -alias node1 \ -storepass changeme -file node1.cer
- Import the test certificate into the truststore:
keytool -importcert -keystore my.truststore -alias node1 \ -storepass trustchangeme -file node1.cer -noprompt
Here we specify the -noprompt option to suppress the prompt asking you to confirm that the certificate is trustworthy. Since you created the certificate yourself, this confirmation is unnecessary. - Repeat Steps 1 and 2 for node2.keystore … node100.keystore.
翻譯就是：
1、導出node1.example.com的測試證書：
2、將測試證書導入到信任庫中：
這里我們指定-noprompt選項來禁止提示，要求您確認證書是值得信賴的。 由於你自己創建了證書，所以這個確認是不必要的。
3、對node2.keystore ... node100.keystore重復步驟1和2。
方法二：解決辦法
參考 ：
https://www.pythian.com/blog/using-ansible-to-secure-cloudera-manager-installation-on-a-hadoop-cluster/
Building a secure Hadoop cluster requires protecting a number of services that comprise the Hadoop infrastructure. If you are using CDH distribution, then Cloudera Manager (CM) is one of the components that needs to be secured. CM consists of Server and Agents running on all cluster machines and web UI. CM provides you with 3 levels of security for its communication (good/better/best):
翻譯就是：
構建安全的Hadoop集群需要保護構成Hadoop基礎架構的許多服務。 如果您正在使用CDH分發，那么Cloudera Manager（CM）是需要保護的組件之一。 CM由在所有集群機器和Web UI上運行的服務器和代理組成。 CM為您提供3種安全級別的通信（好/更好/最好）：
- Transport Layer Security (TLS) Encryption for Cloudera Manager
- TLS Authentication of Server to Agent and Users
- TLS Authentication of Agents to Server
Cloudera Manager的傳輸層安全（TLS）加密
服務器到代理和用戶的TLS認證
代理服務器的TLS認證
There is a good step-by-step guide in CM’s documentation, and it’s easy to follow for one server. But what about when you have hundreds of them? There are different approaches to the problem of managing a server’s configuration to scale, but I’d like to focus on Ansible, which is a neat framework for parallel command execution and complex rollouts. And it’s written in Python! Ansible is easy to install and requires only a couple of Python libraries on a “master” node and nothing other than python2.6 on “slaves”. You don’t have to setup ssh-keys and configure passwordless access across all machines, which is important when talking about security. To give you and idea of how Ansible command looks like, here is how you can restart CM Agents on all Hadoop data nodes:
翻譯就是：
CM的文檔中有一個很好的分步指南，一個服務器很容易遵循。 但是，當你有數百人的時候呢？ 管理服務器配置以擴展的問題有不同的方法，但我想關注Ansible，這是並行命令執行和復雜推出的整潔框架。 它是用Python編寫的！ 可安裝易於安裝，只需要“主”節點上的幾個Python庫，而在“從站”上只需要python2.6。 您不必在所有機器上設置ssh-key並配置無密碼訪問，這在談論安全性時非常重要。 為了讓您了解Ansible命令的樣子，以下是如何在所有Hadoop數據節點上重新啟動CM Agent：
ansible hadoop_data_nodes -m service\ -a "name=cloudera-scm-agent state=restarted" -k --sudo
This command will read a list of hosts from your /etc/ansible/hosts file or any other file specified by ANSIBLE_HOSTS environment variable. It will find a section [hadoop_data_nodes] in the hosts file (which has ini-like structure) and will execute any given command for all servers in this section. Ansible will ask you for both ssh and sudo passwords only once and will use them to execute commands on target servers. Ansible relies on modules (specified by -m option) to perform specific tasks, like restarting services, executing shell commands, or manipulating text files. A full list of modules can be found here. You can write your own, of course, if you need.
翻譯就是：
此命令將從/ etc / ansible / hosts文件或由ANSIBLE_HOSTS環境變量指定的任何其他文件讀取主機列表。 它將在hosts文件中找到一個[hadoop_data_nodes]部分（具有類似於ini的結構），並且將在本節中為所有服務器執行任何給定的命令。 Ansible會詢問你們ssh和sudo密碼只有一次，並使用它們在目標服務器上執行命令。 可靠依賴於模塊（由-m選項指定）來執行特定任務，例如重新啟動服務，執行shell命令或操作文本文件。 可以在這里找到完整的模塊列表。 當然，如果你需要，你可以自己寫。
Below is the step-by-step guide on configuring all 3 levels of TLS for CM. In some aspects, it repeats steps from CM’s documentation guide, but there are some important nuances that I have discovered. This guide is also scalable: You can apply it with very little modifications to clusters of any size.
翻譯就是：以下是為CM配置所有3級TLS的分步指南。 在某些方面，它重復CM的文檔指南中的步驟，但我發現了一些重要的細微差別。 本指南也是可擴展的：您可以對任何大小的群集進行很少的修改來應用它。
Level I、 TLS Encryption for Cloudera Manager（翻譯就是Cloudera Manager的TLS加密）
The following steps assume that you have installed Ansible on the same server as your CM Server and properly configured it to access all nodes in your cluster.
翻譯就是：以下步驟假定您已在與CM服務器相同的服務器上安裝了Ansible，並將其正確配置為訪問集群中的所有節點。
1、Create a directory for CM keystore:
翻譯就是：為CM密鑰庫創建一個目錄
mkdir /etc/cloudera-scm-server/keystore
2、Generate a certificate for CM. You will be prompted for a new Keystore password. Also make sure that the CN field you will be asked to specify matches the CM Server hostname. It’s not *your* name!
翻譯就是：為CM生成證書。 系統將提示您輸入新的密碼庫密碼。 還要確保要求您指定的CN字段與CM Server主機名匹配。 這不是你*的名字！
keytool -validity 1095 -keystore\ /etc/cloudera-scm-server/keystore/scm-keystore -alias jetty\ -genkeypair -keyalg RSA
note -validity option, new certificate will be valid for 3 years in this case
翻譯就是：note -validity選項，新證書在這種情況下將有效3年
3、Restrict permissions to the Keystore:
翻譯就是：限制對Keystore的權限：
chown -R cloudera-scm:cloudera-scm /etc/cloudera-scm-server/keystore/ chmod o-r /etc/cloudera-scm-server/keystore/scm-keystore
4 、Enable TLS Encryptions for Agents and provide path and password to the Keystore in CM web UI. You can refer to CM’s documentation on how to do this.、|\
翻譯就是：啟用代理的TLS加密，並在CM Web UI中為密鑰庫提供路徑和密碼。 您可以參考CM關於如何執行此操作的文檔。
5、Next, we need to update CM Agent configuration files to set use_tls=1 option. For this, Ansible lineinfile module can be used:
翻譯就是：接下來，我們需要更新CM Agent配置文件以設置use_tls = 1選項。 為此，可以使用Ansible lineinfile模塊：
ansible hadoop -m lineinfile -a\
"dest=/etc/cloudera-scm-agent/config.ini state=present regexp='use_tls.*'\
line='use_tls=1'" -k -K
There are several assumptions made here. First of all, your Ansible host list has a [hadoop] section in it, which covers all Hadoop cluster nodes or has sections like [hadoop_namenodes], [hadoop_datanodes], etc. Ansible can recognize patterns. Second, your template for CM Agnet config.ini files has all security related options in it, but they are commented out. Maintaining a template for all configuration files is a good idea, and Ansible can help you here as well, but it’s beyond the scope of this guide.
翻譯就是：這里有幾個假設。 首先，您的可選主機列表中有一個[hadoop]部分，其中包含所有Hadoop集群節點，或包含[hadoop_namenodes]，[hadoop_datanodes]等部分。可以使用可識別的模式。 其次，您的CM Agnet config.ini文件的模板中包含所有與安全性相關的選項，但它們被注釋掉。 維護所有配置文件的模板是一個好主意，Ansible也可以幫助您，但這超出了本指南的范圍。
6、Restart CM Server (again, I assume that you run Ansible commands from the same machine):
翻譯就是：重新啟動CM服務器（再次，我假設您從同一台機器運行可執行的命令）：
sudo /etc/init.d/cloudera-scm-agent restart
7、Restart CM Agents and check their health:
翻譯就是：重新啟動CM代理並檢查其身體狀況：
ansible hadoop -m service -a\ 'name=cloudera-scm-agent state=restarted' -k -K;
ansible hadoop -m shell -a\ "tail /var/log/cloudera-scm-agent/cloudera-scm-agent.log" -k -K
You have already seen an example with service Ansible module. The new module used here is shell. It allows you to run arbitrary shell commands. It’s a good idea to verify that all agents started fine, so you can check the log files on all servers.
翻譯就是：
您已經看到了一個服務Ansible模塊的例子。 這里使用的新模塊是shell。 它允許您運行任意shell命令。 驗證所有代理程序是否正常啟動是一個好主意，因此您可以檢查所有服務器上的日志文件。
If all is fine, at this point you have encrypted communication between CM Server and CM Agents.
翻譯就是：如果一切正常，此時您將在CM Server和CM Agent之間進行加密通信。
Level II、 TLS Authentication of Server to Agent and Users（服務器到代理和用戶的TLS認證）
At this level, you will force CM Agents to check a certificate for CM Server to make sure they are talking to the right machine.
翻譯就是： 在這個級別上，您將強制CM Agent檢查CM Server的證書，以確保它們與正確的機器通話。
- Export CM Server Certificate from Keystore and convert it to .der format: （翻譯就是從密鑰庫導出CM服務器證書並將其轉換為.der格式：）
keytool -exportcert -keystore\ /etc/cloudera-scm-server/keystore/scm-keystore -alias jetty\ -file scm-server.der openssl x509 -out scm-server.pem -in scm-server.der -inform der
- Create new cert dirs on all agent servers: （翻譯就是在所有代理服務器上創建新的證書）
ansible hadoop -m shell -a "mkdir /etc/cloudera-scm-agent/cert" -k -K
- Copy server cert to agents: （將服務器證書復制到代理）
ansible hadoop -m copy -a "src=/tmp/scm-server.pem dest=/etc/cloudera-scm-agent/cert/ owner=root group=root" -k -K - Change very_cert_file option in agent’s config.ini: （在代理的config.ini中更改very_cert_file選項）
ansible hadoop -m lineinfile -a "dest=/etc/cloudera-scm-agent/config.ini state=present regexp='verify_cert_file' line='verify_cert_file=/etc/cloudera-scm-agent/cert/scm-server.pem'" -k -K
- Enabled Use TLS Encryption for Admin Console in CM Web UI （啟用對CM Web UI中的管理控制台使用TLS加密）
- Restart CM server and Agents. See Steps 6-7 in Level I. （重新啟動CM服務器和代理。 見第一級步驟6-7。）
Level III、 TLS Authentication of Agents to Server
This is similar to the previous level, but requires certificates to be generated for all agents so they can authenticate to the CM Server. Here I describe an approach with self-signed certificates, which is fine for development or POC clusters. For production clusters, you may need to comply with your organisation’s standards and obtain properly signed certificates.
翻譯就是：
這與上一級相似，但需要為所有代理生成證書，以便他們可以向CM Server進行身份驗證。 我在這里描述一種具有自簽名證書的方法，這對於開發或POC集群是很好的。 對於生產集群，您可能需要遵守組織的標准並獲得正確簽名的證書。
Generate password for Agent keys and copy it to all agents machines:
ansible hadoop -m shell -a\ 'echo PASSWORD > /etc/cloudera-scm-agent/cert/agent_cert.pwd' -k -K ansible hadoop -m shell -a\ 'chmod o-rx /etc/cloudera-scm-agent/cert/agent_cert.pwd' -k -K
- The next step is to generate a private key and certificate for each CM Agent. To automate this task I wrote a quick script — https://github.com/dazbur/morecerts. It takes a list of hosts in a plain text file and produces a private key and certificate for each host. Resulting files will have agent_HOSTNAME.key and agent_HOSTNAME.pem format. It also takes care of providing Distinguished Name options for keys-generating commands:
- Create a text file with list of Agent’s IP adress. You can just copy it from Ansible hosts lists.
- Create agent key password and put it into a text file.
- Generate keys:
./morecerts.py -f agentiplist.file -p agent.pass.file gencerts
- Add keys to CM Server keystore:
sudo ./morecerts.py -f agentiplist.file -p agent.pass.file -k\ /etc/cloudera-scm-server/keystore/scm-keystore\ -w KEYSTORE_PASSOWORD addtokeystore
- Copy keys and certs to agent machines (assuming you have generated keys in your home directory):
ansible hadoop -m copy -a "src=~/agent_$inventory_hostname.key dest=/etc/cloudera-scm-agent/cert/agent.key owner=root group=root" -k -K ansible hadoop -m copy -a "src=~/agent_$inventory_hostname.pem dest=/etc/cloudera-scm-agent/cert/agent.pem owner=root group=root" -k -K
Here you can see another nice trick Ansible can do: $inventory_hostname variable corresponds to the server on which command will be executed. This allows you to copy specific files to specific servers.
- Update agent config.ini files to set client_key_file, client_keypw_file, and client_cert_fileoptions:
ansible hadoop -m lineinfile -a "dest=/etc/cloudera-scm-agent/config.ini state=present regexp='client_key_file.*' line='client_key_file=/etc/cloudera-scm-agent/cert/agent.key'" -k -K ansible hadoop -m lineinfile -a "dest=/etc/cloudera-scm-agent/config.ini state=present regexp='client_keypw_file.*' line='client_keypw_file=/etc/cloudera-scm-agent/cert/agent_cert.pwd'" -k -K ansible hadoop -m lineinfile -a "dest=/etc/cloudera-scm-agent/config.ini state=present regexp='client_cert_file.*' line='client_cert_file=/etc/cloudera-scm-agent/cert/agent.pem'" -k -K
- Update CM’s configuration via Web UI to set Use TLS Authentication of Agents to Server, Path to Truststore, and Truststore Password. Truststore is the same as Keystore in our case.
- Restart CM Server and Agents.
You are done now! Ansible can also wrap individual playbooks, so you can execute them on demand later. In general, I found Ansible to be a great tool to manage and execute commands on many servers, and it is definitely worth exploring.
解決方式三
參考
http://www.jianshu.com/p/ccfff00bc37d
同時，大家可以關注我的個人博客：
http://www.cnblogs.com/zlslch/ 和 http://www.cnblogs.com/lchzls/ http://www.cnblogs.com/sunnyDream/
詳情請見：http://www.cnblogs.com/zlslch/p/7473861.html
人生苦短，我願分享。本公眾號將秉持活到老學到老學習無休止的交流分享開源精神，匯聚於互聯網和個人學習工作的精華干貨知識，一切來於互聯網，反饋回互聯網。
目前研究領域：大數據、機器學習、深度學習、人工智能、數據挖掘、數據分析。 語言涉及：Java、Scala、Python、Shell、Linux等 。同時還涉及平常所使用的手機、電腦和互聯網上的使用技巧、問題和實用軟件。 只要你一直關注和呆在群里，每天必須有收獲
對應本平台的討論和答疑QQ群：大數據和人工智能躺過的坑（總群）（161156071）
