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/> > > >