MINOR: Remove multi-byte charactor in docs

There are multi-byte characters In quickstart.html and security.html.
This PR will fix it.

Author: Sasaki Toru <sasakitoa@nttdata.co.jp>

Reviewers: Grant Henke

Closes #897 from sasakitoa/remove_multi_byte_character
This commit is contained in:
Sasaki Toru 2016-02-10 12:50:57 -07:00 committed by Gwen Shapira
parent d5b43b19bb
commit 1faab034b1
2 changed files with 4 additions and 4 deletions

View File

@ -200,7 +200,7 @@ Kafka Connect is a tool included with Kafka that imports and exports data to Kaf
how to run Kafka Connect with simple connectors that import data from a file to a Kafka topic and export data from a how to run Kafka Connect with simple connectors that import data from a file to a Kafka topic and export data from a
Kafka topic to a file. Kafka topic to a file.
First, well start by creating some seed data to test with: First, we'll start by creating some seed data to test with:
<pre> <pre>
&gt; <b>echo -e "foo\nbar" > test.txt</b> &gt; <b>echo -e "foo\nbar" > test.txt</b>

View File

@ -34,7 +34,7 @@ Apache Kafka allows clients to connect over SSL. By default SSL is disabled but
<ol> <ol>
<li><h4><a id="security_ssl_key" href="#security_ssl_key">Generate SSL key and certificate for each Kafka broker</a></h4> <li><h4><a id="security_ssl_key" href="#security_ssl_key">Generate SSL key and certificate for each Kafka broker</a></h4>
The first step of deploying HTTPS is to generate the key and the certificate for each machine in the cluster. You can use Javas keytool utility to accomplish this task. The first step of deploying HTTPS is to generate the key and the certificate for each machine in the cluster. You can use Java's keytool utility to accomplish this task.
We will generate the key into a temporary keystore initially so that we can export and sign it later with CA. We will generate the key into a temporary keystore initially so that we can export and sign it later with CA.
<pre> <pre>
keytool -keystore server.keystore.jks -alias localhost -validity {validity} -genkey</pre> keytool -keystore server.keystore.jks -alias localhost -validity {validity} -genkey</pre>
@ -54,7 +54,7 @@ Apache Kafka allows clients to connect over SSL. By default SSL is disabled but
The generated CA is simply a public-private key pair and certificate, and it is intended to sign other certificates.<br> The generated CA is simply a public-private key pair and certificate, and it is intended to sign other certificates.<br>
The next step is to add the generated CA to the **clients truststore** so that the clients can trust this CA: The next step is to add the generated CA to the **clients' truststore** so that the clients can trust this CA:
<pre> <pre>
keytool -keystore server.truststore.jks -alias CARoot <b>-import</b> -file ca-cert</pre> keytool -keystore server.truststore.jks -alias CARoot <b>-import</b> -file ca-cert</pre>
@ -62,7 +62,7 @@ Apache Kafka allows clients to connect over SSL. By default SSL is disabled but
<pre> <pre>
keytool -keystore client.truststore.jks -alias CARoot -import -file ca-cert</pre> keytool -keystore client.truststore.jks -alias CARoot -import -file ca-cert</pre>
In contrast to the keystore in step 1 that stores each machines own identity, the truststore of a client stores all the certificates that the client should trust. Importing a certificate into ones truststore also means trusting all certificates that are signed by that certificate. As the analogy above, trusting the government (CA) also means trusting all passports (certificates) that it has issued. This attribute is called the chain of trust, and it is particularly useful when deploying SSL on a large Kafka cluster. You can sign all certificates in the cluster with a single CA, and have all machines share the same truststore that trusts the CA. That way all machines can authenticate all other machines.</li> In contrast to the keystore in step 1 that stores each machine's own identity, the truststore of a client stores all the certificates that the client should trust. Importing a certificate into one's truststore also means trusting all certificates that are signed by that certificate. As the analogy above, trusting the government (CA) also means trusting all passports (certificates) that it has issued. This attribute is called the chain of trust, and it is particularly useful when deploying SSL on a large Kafka cluster. You can sign all certificates in the cluster with a single CA, and have all machines share the same truststore that trusts the CA. That way all machines can authenticate all other machines.</li>
<li><h4><a id="security_ssl_signing" href="#security_ssl_signing">Signing the certificate</a></h4> <li><h4><a id="security_ssl_signing" href="#security_ssl_signing">Signing the certificate</a></h4>
The next step is to sign all certificates generated by step 1 with the CA generated in step 2. First, you need to export the certificate from the keystore: The next step is to sign all certificates generated by step 1 with the CA generated in step 2. First, you need to export the certificate from the keystore: