@mayki wogno SSL Certificates are generally issued per server. It would be extremely unusual to have multiple certificates issued for the same server or to issue certificates per piece of software. I am not saying you can't, but unnecessary. Having said that, when you installed NiFi via Ambari, The NIfI CA that was installed likely generated the certificates needed for all your servers where NiFi is running its nodes. A quick look in the nifi.properties file for these jks files will reveal where to find them and the passwords for them as well (Default nifi.properties location on each node --> /etc/nifi/2.0.0.0-579/0/nifi.properties) Now here is the hitch.... When the NiFi CA generates these keystores for your NiFi nodes, the keystore and truststore on every node end up with its own unique password. This will not work for the ssl context service you need to configure to make your ListenHTTP processor operate using SSL. This is because the same identical ssl context service will be used by the listenHTTP processor on each node. There is a little work that needs to be done on each node to get you setup here, I suggest you make a copy of the keystore.jks and truststore.jks files on every node in to some new directory. Then capture the following lines from the nifi.properties file on each node: nifi.security.keyPasswd=<keypass> nifi.security.keystore=/<path>/keystore.jks nifi.security.keystorePasswd=<keystore-password> nifi.security.keystoreType=jks nifi.security.truststore=/<path>/truststore.jks nifi.security.truststorePasswd=<truststore-password> nifi.security.truststoreType=jks Lets assume you create a /opt/nifi-certs/ directory n every node and placed them there. Next you will want to use the keytool command to change the password on the copies so that nifi.security.keyPasswd= uses the same password on every node, nifi.security.keystorePasswd= uses the same password on every node, and nifi.security.truststorePasswd= uses the same password on every node. While the contents of each certificate is unique to the server, the passwords used to access that key and keystore will then all be the same. This will allow you to configure your ssl-context service to use common passwords to access these server keystores on each node. Below are the command you can use to change the keystore/trustore passwords and the key passwords within the keystore files. For each keystore do the following: keytool -storepasswd -new <new_storepass> -keystore keystore.jks (Make sure you use the same <new_storepass> on every node in your nifi cluster. keytool -keypasswd -alias [Alias name for private key] -keystore [path to key store] (If you don't know your private key <alias>, you can get it by running the following command against your keystore.jks file. You will be prompted for yoru <new_storepassword> and the original <key-password>, and then allowed to set a >new-key-password>) keytool -v --list -keystore keystore.jks For each Truststore do the following: keytool -storepasswd -new <new_trustpass> -keystore truststore.jks (Make sure you use the same <new_trustpass> on every node in your nifi cluster. After you have completed the above on every node you are ready to configure and start using the ssl-context service. Thanks, Matt ... View more

@mayki wogno Every Processor has a well defined job to do. When that job is executed, there are 1 to many possible outcomes. Those outcomes are represented in the form of relationships. As a FlowFile traverses through your dataflow it will be routed to these various relationships. Eventually you will reach the end of you dataflow and the auto-terminate relationship capability gives the user the ability to tell NiFi I am not done with the FlowFile you may get rid of it. A processor is never coded to ever delete FlowFiles by default. For example, lets assume the last processor in my dataflow is a putSFTP. What this processor actually does when it receives a FlowFile is send a copy of that FlowFiles content to the SFTP destination. Upon confirmed delivery it routes the FlowFile to the "success" relationship. You may choose to send that FlowFile via that "success" relationship on for further processing in additional processors or "auto-terminate" it within the putSFTP thus ending its life as FlowFile. In NiFi it is the dataflow designers job to determine when a FlowFile has reached the end of the dataflow and that is exactly what "auto-terminate relationships" is used for. Thanks, Matt ... View more

@Sanaz Janbakhsh Re-installing from scratch is not necessary. Shutdown your NiFi instance, create the user on your system that you want to run NiFi as and change ownership of all the files and directories used by NiFi to that user. This includes all 4 NiFi repositories (Database, Provenance, Content, and FlowFile). The "NiFi user" must be able to read and write to the repos, nifi logs, and state directories. If you are unsure where to find these directories your user needs access to, look in the various config files found in NiFi's conf directory. NiFi will be able to continue working on FlowFiles that were still active in the flow as long as ownership of those files was successfully changed. After that you can either start NiFi while logged in as that new user or set the "run.as=" property in the NiFI bootstrap.conf file. After starting NiFi as the user, tail the nifi-app.log and watch for any permission denied errors. If you encounter any, adjusted permissions on the reported file/dir and you should be good to go. There is no such thing as NiFi version 2.4.2.0? Are you running an Apache Nifi release (0.x or 1.x) or a HDF release (1.x or 2.0)? You can see your NiFi version by clicking on "about" in the upper right corner of the NiFi UI. Thanks, Matt ... View more

@milind pandit Is this a flow.xml.gz you copied from another instance of NiFi? All the sensitive properties inside the flow.xml.gz file are encrypted using the sensitive property defined in the nifi.properties file (If blank NiFi uses and internal default). If you move your flow.xml.gz file to another NiFi, the sensitive property value used must be the same or NiFi will fail to start because it cannot decrypt the sensitive properties in the file. Matt ... View more