@Jette    There is no need for the updateAttribute processor here, unless there are some missing details to this issue. The extractText processor already permanently adds any created attribute to the FlowFile it outputs.  The dynamic property name used becomes the FlowFile attribute name.   Matt ... View more

@Sergiete    The nifi-app.log should tell you why the second node failed to start if NiFi got beyond the bootstrap process.  If not, the nifi bootstrap.log will tell you why it failed to start.   Matt ... View more

@Sergiete    The sensitive.key file is created during NiFi startup and is removed once startup completes successfully.  The fact that it still exists when you are trying to start NiFi, tells me that some previous startup attempt failed after sensitive.key was created, but before startup completed.   You can safely remove this sensitive.key file from your NiFi nodes and start your NiFi service again.  If NiFi fails to start and you see the sensitive.key was created and not removed again, look through your NiFi logs to see why it failed.  It will be for a different reason since you had manually removed the sensitive.key before that startup.   I have not seen this condition occur on any of my CFM installs yet, but have heard of this happening before.  What I do not have is logs to determine what is happening in those cases.   Matt ... View more

@big-f    The work to support bundles is part of NiFi-Registry 0.4.0 https://nifi.apache.org/docs/nifi-registry-docs/html/administration-guide.html#bundle-persistence-providers https://nifi.apache.org/docs/nifi-registry-docs/html/user-guide.html#manage-bundles https://issues.apache.org/jira/browse/NIFIREG-211     ... View more

@Dale1979    It would appear you have a multi-node NiFi cluster that is using the NiFi CA to issue the certificate for each NiFi node.   Within a NiFi cluster, one node will be elected cluster coordinator. While you can access your NiFi cluster from any node in the cluster, any user requests (including displaying the UI) need to be replicated to the cluster coordinator.  This replication request is performed by the node which you are authenticated in to on behalf of you as the user.  Thus requiring that the node itself has been authorized to act as a proxy for your user.   Within your authorizers.xml file you should find a file-user-group-provider which should have been configured a separate "Initial User Identity <num>" property for each of your NiFi nodes. The file-user-group-provider is used add the initial users in the users.xml file. The value would match the DN of the certificate found in each node's keystore.jks file.  Using you output as an example, you should see a line like this:   <property name="Initial User Identity 2">CN=server.domain:port, OU=NIFI</property>   Above would be followed by additional similar lines with new number for each of your other NiFi nodes.   Note: Having a port number in your CN name is unexpected.   IMPORTANT:  NiFi will only generate the users.xml and authorizations.xml files from the configuration in the authorizers.xml file the very first time.  If you make edits to either the file-user-group-provider (build users.xml) or File-access-provider (builds authorizations.xml), those changes will not be reflected in the already existing users.xml and authorizations.xml files.  You must delete these files so they are recreated.  The expectation is that following successful securing of NiFi, all additional users and authorizers are added directly via the NiFi UI.   Hope this helps, Matt ... View more