The CLI does not use nifi.properties, there are several ways of passing in
config...

https://nifi.apache.org/docs/nifi-docs/html/toolkit-guide.html#property-argument-handling

On Wed, Oct 14, 2020 at 10:01 AM Wyll Ingersoll <
wyllys.ingers...@keepertech.com> wrote:

> That makes sense.  It must be reading the keystore/truststore specified in
> the nifi.properties file then?
> ------------------------------
> *From:* Bryan Bende <bbe...@gmail.com>
> *Sent:* Wednesday, October 14, 2020 9:59 AM
> *To:* users@nifi.apache.org <users@nifi.apache.org>
> *Subject:* Re: Clustered nifi issues
>
> The get-nodes command calls the REST resource /controller/cluster which
> authorizes against READ on /controller [1], so there is no way you can call
> this in a secure environment without authenticating somehow, which from the
> CLI means specifying a keystore/truststore.
>
> [1]
> https://github.com/apache/nifi/blob/main/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/api/ControllerResource.java#L857
>
> On Wed, Oct 14, 2020 at 9:26 AM Wyll Ingersoll <
> wyllys.ingers...@keepertech.com> wrote:
>
> Yes, this is for a secured cluster deployed as a Kubernetes stateful set.
> The certificate parameters are apparently not needed to just get the status
> of the nodes using the command below.
>
>
>
> ------------------------------
> *From:* Sushil Kumar <skm....@gmail.com>
> *Sent:* Tuesday, October 13, 2020 4:01 PM
> *To:* users@nifi.apache.org <users@nifi.apache.org>
> *Subject:* Re: Clustered nifi issues
>
> Did you say that the same line of code works fine for secured clusters
> too.
> I asked because nifi-toolkit has a separate set of parameters asking for
> certificates and everything else related to secure clusters.
>
>
> On Tue, Oct 13, 2020 at 12:14 PM Wyll Ingersoll <
> wyllys.ingers...@keepertech.com> wrote:
>
>
> I found that instead of dealing with nifi client certificate hell, the
> nifi-toolkit cli.sh will work just fine for testing the readiness of the
> cluster.  Here is my readiness script which seems to work just fine with in
> kubernetes with the apache/nifi docker container version 1.12.1
>
>
> #!/bin/bash
>
>
> $NIFI_TOOLKIT_HOME/bin/cli.sh nifi get-nodes -ot json > /tmp/cluster.state
>
> if [ $? -ne 0 ]; then
>
>         cat /tmp/cluster.state
>
>         exit 1
>
> fi
>
> STATUS=$(jq -r ".cluster.nodes[] | select((.address==\"$(hostname -f)\")
> or .address==\"localhost\") | .status" /tmp/cluster.state)
>
> if [[ ! $STATUS = "CONNECTED" ]]; then
>
>         echo "Node not found with CONNECTED state. Full cluster state:"
>
>         jq . /tmp/cluster.state
>
>         exit 1
>
> fi
>
>
> ------------------------------
> *From:* Chris Sampson <chris.samp...@naimuri.com>
> *Sent:* Thursday, October 1, 2020 9:03 AM
> *To:* users@nifi.apache.org <users@nifi.apache.org>
> *Subject:* Re: Clustered nifi issues
>
> For info, the probes we currently use for our StatefulSet Pods are:
>
>    - livenessProbe - tcpSocket to ping the NiFi instance port (e.g. 8080)
>    - readinessProbe - exec command to curl the
>    nifi-api/controller/cluster endpoint to check the node's cluster connection
>    status, e.g.:
>
> readinessProbe:
> exec:
> command:
> - bash
> - -c
> - |
> if [ "${SECURE}" = "true" ]; then
> INITIAL_ADMIN_SLUG=$(echo "${INITIAL_ADMIN}" | tr '[:upper:]' '[:lower:]'
> | tr ' ' '-')
>
> curl -v \
> --cacert ${NIFI_HOME}/data/conf/certs/${INITIAL_ADMIN_SLUG}/nifi-cert.pem \
> --cert
> ${NIFI_HOME}/data/conf/certs/${INITIAL_ADMIN_SLUG}/${INITIAL_ADMIN_SLUG}-cert.pem
> \
> --key
> ${NIFI_HOME}/data/conf/certs/${INITIAL_ADMIN_SLUG}/${INITIAL_ADMIN_SLUG}-key.pem
> \
> https://$(hostname -f):8080/nifi-api/controller/cluster >
> /tmp/cluster.state
> else
> curl -kv http://$(hostname -f):8080/nifi-api/controller/cluster >
> /tmp/cluster.state
> fi
>
> STATUS=$(jq -r ".cluster.nodes[] | select((.address==\"$(hostname -f)\")
> or .address==\"localhost\") | .status" /tmp/cluster.state)
>
> if [[ ! $STATUS = "CONNECTED" ]]; then
> echo "Node not found with CONNECTED state. Full cluster state:"
> jq . /tmp/cluster.state
> exit 1
> fi
>
>
> Note that INITIAL_ADMIN is the CN of a user with appropriate permissions
> to call the endpoint and for whom our pod contains a set of certificate
> files in the indicated locations (generated from NiFi Toolkit in an
> init-container before the Pod starts); jq utility was added into our
> customised version of the apache/nifi Docker Image.
>
>
> ---
> *Chris Sampson*
> IT Consultant
> chris.samp...@naimuri.com
> <https://www.naimuri.com/>
>
>
>

Reply via email to