[
https://issues.apache.org/jira/browse/NIFI-5247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494869#comment-16494869
]
ASF GitHub Bot commented on NIFI-5247:
--------------------------------------
Github user pepov commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2746#discussion_r191681207
--- Diff: nifi-toolkit/nifi-toolkit-assembly/src/main/resources/bin/cli.sh
---
@@ -111,8 +111,7 @@ run() {
export NIFI_TOOLKIT_HOME="$NIFI_TOOLKIT_HOME"
umask 0077
- "${JAVA}" -cp "${CLASSPATH}" ${JAVA_OPTS:--Xms128m -Xmx256m}
org.apache.nifi.toolkit.cli.CLIMain "$@"
- return $?
+ exec "${JAVA}" -cp "${CLASSPATH}" ${JAVA_OPTS:--Xms128m -Xmx256m}
org.apache.nifi.toolkit.cli.CLIMain "$@"
--- End diff --
I've also ran `mvn package -P docker` in the
nifi-toolkit/nifi-toolkit-assembly folder and ran the following return code
tests using the newly built dockerfile:
Command not specified:
```
docker run --rm apache/nifi-toolkit:1.7.0-SNAPSHOT tls-toolkit; echo $?
Expected at least a service argument.
Usage: tls-toolkit service [-h] [args]
Services:
standalone: Creates certificates and config files for nifi cluster.
server: Acts as a Certificate Authority that can be used by clients to
get Certificates
client: Generates a private key and gets it signed by the certificate
authority.
status: Checks the status of an HTTPS endpoint by making a GET request
using a supplied keystore and truststore.
2
```
Argument error:
```
docker run --rm apache/nifi-toolkit:1.7.0-SNAPSHOT tls-toolkit client; echo
$?
token argument must not be empty unless useConfigJson or configJsonIn set
usage: org.apache.nifi.toolkit.tls.TlsToolkitMain [-a <arg>] [-c <arg>] [-C
<arg>] [--configJsonIn <arg>] [-D <arg>] [-f <arg>] [-F] [-g] [-h] [-k <arg>]
[-p
<arg>] [--subjectAlternativeNames <arg>] [-T <arg>] [-t <arg>]
Generates a private key and gets it signed by the certificate authority.
-a,--keyAlgorithm <arg> Algorithm to use for generated
keys. (default: RSA)
-c,--certificateAuthorityHostname <arg> Hostname of NiFi Certificate
Authority (default: localhost)
-C,--certificateDirectory <arg> The file to write the CA
certificate to (default: .)
--configJsonIn <arg> The place to read configuration
info from (defaults to the value of configJson), implies useConfigJson if set.
(default: configJson value)
-D,--dn <arg> The dn to use for the client
certificate (default: CN=0d2f3cfed775,OU=NIFI)
-f,--configJson <arg> The place to write configuration
info (default: config.json)
-F,--useConfigJson Flag specifying that all
configuration is read from configJson to facilitate automated use (otherwise
configJson will
only be written to.
-g,--differentKeyAndKeystorePasswords Use different generated password
for the key and the keyStore.
-h,--help Print help and exit.
-k,--keySize <arg> Number of bits for generated
keys. (default: 2048)
-p,--PORT <arg> The port to use to communicate
with the Certificate Authority (default: 8443)
--subjectAlternativeNames <arg> Comma-separated list of domains
to use as Subject Alternative Names in the certificate
-T,--keyStoreType <arg> The type of keyStores to
generate. (default: jks)
-t,--token <arg> The token to use to prevent MITM
(required and must be same as one used by CA)
Java home: /usr/lib/jvm/java-1.8-openjdk/jre
NiFi Toolkit home: /opt/nifi-toolkit/nifi-toolkit-1.7.0-SNAPSHOT
8
```
Service error:
```
docker run --rm apache/nifi-toolkit:1.7.0-SNAPSHOT tls-toolkit client -t
$(uuidgen); echo $?
2018/05/30 08:23:44 INFO [main]
org.apache.nifi.toolkit.tls.service.client.TlsCertificateAuthorityClient:
Requesting new certificate from localhost:8443
2018/05/30 08:23:45 INFO [main]
org.apache.nifi.toolkit.tls.service.client.TlsCertificateSigningRequestPerformer:
Requesting certificate with dn CN=24e8d8c4c0da,OU=NIFI from localhost:8443
Service client error: Connect to localhost:8443 [localhost/127.0.0.1]
failed: Connection refused (Connection refused)
Usage: tls-toolkit service [-h] [args]
Services:
standalone: Creates certificates and config files for nifi cluster.
server: Acts as a Certificate Authority that can be used by clients to
get Certificates
client: Generates a private key and gets it signed by the certificate
authority.
status: Checks the status of an HTTPS endpoint by making a GET request
using a supplied keystore and truststore.
3
```
> NiFi toolkit signal handling changes, Dockerfile enhancements
> -------------------------------------------------------------
>
> Key: NIFI-5247
> URL: https://issues.apache.org/jira/browse/NIFI-5247
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Docker, Tools and Build
> Affects Versions: 1.6.0, 1.7.0
> Reporter: Peter Wilcsinszky
> Priority: Minor
>
> 1. Signal handling issues
> In order for processes to handle signals properly in Docker we have to
> implement explicit signal handling for the first process in the container. In
> the case of the NiFi toolkit the easiest solution is to replace the bash
> shell with the Java process and let it handle the signal using the exec
> system call. More detailed explanation of the issue:
> [http://veithen.github.io/2014/11/16/sigterm-propagation.html]
> Relevant issues: NIFI-3505 and NIFI-2689 that already added exec to the run
> invocation of the nifi.sh start script.
> This changes makes stopping containers fast and graceful.
> 2. TLS toolkit commands and basic tooling in the container
> In order to be able to request certificates from a running CA server instance
> some tooling is needed inside the container. These tools are openssl for
> checking ssl certificates and endpoints, and jq for config.json processing. A
> complete use case is available in the following NiFi helm chart:
> [https://github.com/pepov/apache-nifi-helm/blob/master/templates/statefulset.yaml#L75]
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
