@Rohitravi    If you only want to list files from directory DIR5, simply provide the complete path to DIR5 in the "Input Directory" ListFile processor configuration property and set Recurse Subdirectories as false.   If above is not an option, you may want to try using the following "Path Filter": .*?/DIR5   Hope this helps, Matt ... View more

@DivyaKaki  It is complaining because the hostname is "ip-10-175-124-250.xxx.com" but that hostname does not exist as SAN in your certificate.   I would also be concerned that in the nifi.properties files on each of you nodes you are using localhost as your hostnames.  That will not work since that would already resolve to the server itself, so nodes would not be successful at heart beating to one another. As i mentioned much earlier, the keystore has requirements: 1. keystore can only contain ONE PrivateKeyEntry 2. PrivateKeyEntry must support clientAuth and serverAuth EKU 3. PrivateKeyEntry must contain at least one Subject Alternative Name (SAN) that matches the hostname of the server on which the certificate is being used.  In your case you have "localhost" as a SAN entry, but no SAN entry for "ip-10-175-124-250.xxx.com"   This kinda loops back around to the original command i provided that produced keystores not using localhost. On a side note, looks like after removing the users.xml, you got an expected users.xml created. Now you may be able to cheat here, but I strongly recommend against it for security reasons (but using localhost is already a bad security idea).  In the nifi.properties file, you could add each of your servers hostnames to the "nifi.web.proxy.host" property (comma separated list with no spaces). Matt ... View more

@Manus    I have never seen this.  Anytime a relationship is defined in more than one connection, the originating FlowFile will be routed to one connection and clone routed to the other(s). Perhaps you can share a some screenshots of your dataflow showing the behavior you are seeing? Screenshot of flow feeding the output port inside PG1. Screenshot of tope level interconnected Process group PG1, PG2, and PG3.   Is the input port inside PG2 connected to anything?   What version of NiFi are you using?   Thank you, Matt ... View more

@DivyaKaki    Lets take a step back for a moment here.... What is the full version of NiFi you are running currently? What is set value for following properties in your nifi.properties configuration file: nifi.security.user.authorizer=file-provider   Can you share the contents of your authorizers.xml file? Looking at what you shared earlier indicates your file-provider is commented out: <!-- <authorizer> <identifier>file-provider</identifier> <class>org.apache.nifi.authorization.FileAuthorizer</class> <property name="Authorizations File">./conf/authorizations.xml</property> <property name="Users File">./conf/users.xml</property> <property name="Initial Admin Identity">CN=NifiAdmin, OU=ApacheNIfi</property> <property name="Legacy Authorized Users File"></property> <property name="Node Identity 1">CN=localhost, OU=NIFI</property> </authorizer> Note that "<!--" indicates the start of a comment block.  The comment vlock continues until "-->" is found in the XML. The file-provider should look like this: <authorizers> <authorizer> <identifier>file-provider</identifier> <class>org.apache.nifi.authorization.FileAuthorizer</class> <property name="Authorizations File">./conf/authorizations.xml</property> <property name="Users File">./conf/users.xml</property> <property name="Initial Admin Identity">CN=NifiAdmin, OU=ApacheNIfi</property> <property name="Legacy Authorized Users File"></property> <property name="Node Identity 1">CN=localhost, OU=NIFI</property> </authorizer> </authorizers> If your provider is in fact still commented out, that will explain why your users.xml and authorizations.xml files are not being correctly built on startup.   Thank you, Matt     ... View more

@DivyaKaki    Not really sure what to tell you about the command not working for you (maybe a copy paste issue with the single quotes?).   I ran the command locally just fine. Never the less, you would not need to merge your truststore.jks files because every of your truststores already contains the same CA (localhost).   The response you are seeing in the UI indicates that your user authentication was successful; however, your authenticated user is not authorized to the requested resource (specifically /flow is needed to even see the NiFi UI canvas). You will want to be looking at the output written to the nifi-user.log when you attempt to access the NiFi UI for details about user authentication and authorization. Your users.xml and authorizations.xml files should not be empty. NiFi's file-provider from the authorizers.xml file will only generate the users.xml and authorizations.xml files if they do NOT already exist at time of NiFi startup.  Try stopping your NiFi, removing these files from all three nodes, and then starting NiFi again.  Then inspect the new files to see if they are populated. Hope this helps, Matt ... View more

@DivyaKaki  Sorry my responses were more genaralized requirements instead of the actual tls-toolkit command needed to accomplish this with the provided TLS toolkit.   When using "standalone" with NiFi TLS toolkit, all that means is that you are not using an already running  NiFi CA server. To create certificates for all three of your nodes, your tsl-toolkit.sh standalone command would look something like the following:   ./tls-toolkit.sh standalone -B <client cert password> -C 'CN=nifiadmin, OU=NIFI' -n 'node1.xyz.com,node2.xyz.com,node3.xyz.com' --nifiDnPrefix 'CN=' --nifiDnSuffix ', OU=NIFI' -o /tmp/certs/ -K <key password> -P <truststore password> -S <keystore password>   Above will create output in /tmp/certs directory (make sure directory exists before running above command).   What you end up with is the following: 1. A user certificate for nifiadmin which you can use in your browser by importing the p12 file to access your NiFi as the nifi-admin user (provided "CN=nifiadmin, OU=NIFI" was configured as your initial admin user).  2. Three folders (one for each of your nodes) containing the keystore and truststore you need to use on each of those nodes. Note: each node directory will contain a default nifi.properties file.  You should simply update your existing nifi.properties file on each node instead with the keystore and truststore required property values. You Initial Admin Identity  gets configured with the authorizers.xml file. Hope this helps, Matt ... View more

@DivyaKaki    The hostname must exist as a SAN entry in your certificate.  You may also choose to add your servers IP as a SAN entry, FQDN, internal hostname (multi-homed network), etc as SAN entries.  Each SAN entry would correspond with a unique way of addressing the server.  Localhost should not be used anywhere in a certificate (good security practice).  When you access your NiFi via a web browser you should be using one of those SAN entries in the URL. As far as the Distinguished Name (DN) goes for your certificate, NiFi does not support wildcards.  The CN within your DN can be whatever you like.  For example: CN=NiFiNode1, OU=Specialists, O=MyCompany, L=Baltimore, ST=Maryland, C=US   My cert would require following EKUs: #5: ObjectId: 2.5.29.37 Criticality=false ExtendedKeyUsages [ serverAuth clientAuth  I then would have SAN entries like following for example: #8: ObjectId: 2.5.29.17 Criticality=false SubjectAlternativeName [ DNSName: nifi-node-01.com DNSName: nifi-node-01 DNSName: nifi-node-internal-01   Hope this helps, Matt ... View more

@Cl0ck    There will be a HDF 3.5 release coming that is based off Apache NiFi 1.11. The next CFM release will be CFM 2.0, will be based off Apache NiFi 1.11 and will be targeted for CDP.   Thanks, Matt ... View more