OK, @MattWho, thanks for your help. ... View more

@justloseit  NiFi Process groups are just logical containers for processors.  A Process group does not run/execute.  Selecting "Start" on a process group triggers starting of all the components within that process group.  In your case it sounds like you have have setup cron scheduling on your ingest/starting processor(s) within the process group.  All downstream processors to that source should be set run all the time and not cron based scheduling.  So what you are really looking for is how long it took the processors within that process group to process all produced FlowFiles to point of termination? Besides looking at the lineage data for each FlowFile that traverses all the processor in a process group, I can't think of how else you would get that data.   Take a look at the SiteToSiteProvenanceReportingTask available in Apache NiFi.  It allows you send the provenance data (produces a lot of data depending on size of yoru dataflows and amount of FlowFiles being processed) via NiFi's Site-To-Site protocol to another NiFi instance (would recommend a separate dedicated NiFi to receive this data).  You can then build a  dataflow to process that data how you want to retain what information you need, or send it to an external storage/processing system. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@Siva227 Has the reply helped resolve your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future. Thanks. ... View more

Thank you, @MattWho. It's a bit clear for me now. ... View more

@jfs912  NiFi 2.x is secured in the same way as NiFi 1.x was secured.  The Apache NIFi community made a decision to move away from providing a toolkit for generating TLS certificates since it did not make sense to have its own tool to manage certificate creation when there is nothing special the toolkit does (NIFI-12200) .  You can create your own self signed certificates (simple web search will show many resources on how to do this), you can use a certificate service to create yoru certificates and sign them for you, you can setup your own certificate authority for signing your certificates, etc.    It really made no sense for Apache NiFi to maintain this code.  The important parts to remember when creating your NiFi certificates are: Keystore for NiFi: Must contain 1 and only 1 PrivateKey entry PrivateKey entry DN must NOT contain wildcards.  The DN is used as the client identity and use of wildcards in client identities is not a proper security practice. PrivateKey entry must have ExtendedKeyUsage with both ClientAuth and ServerAuth.  NiFi uses this certificate for both client and server authorizations PrivateKey entry must include at least one SAN entry that matches the hostname of the NiFi server on which the certificate will be used. During a TLS exchange hostname verification is performed to make sure the hostname accessed via the URL used matches a SAN entry in the Server certificate the target server responds with.  It is not uncommon for a certificate to contain more then one SAN entry. Recommend that PrivateKey password and Keystore password are the same. Truststore for NiFi: The NiFi truststore contains one too many trusted cert entries.  Some choose to use the Java default cacerts (truststore) file and just add the NiFi additional trusted certs entries to it.  This same truststore is then used on every node in a NiFi cluster. Must contain the complete trusts chain for the NiFi certificates.  A NiFi certificate may be self signed meaning the issuer and signer are the same DistinquishedName (DN).  I this case the public cert for each of yoru NiFi node's certificates needs to be added to the truststore.  A NiFi certificate might be signed by an Intermediate Certificate Authority (CA).  An intermediate CA would be the signer DN for the NIFi certificate. An Intermediate CA will have a different Issuer and Signer DN.  The truststore must contain the public cert for this Intermediate CA.  There may be multiple levels of intermediate CAs before reaching the signer that is the root CA. The root CA public certificate can be identified  because it will have the same DN for issuer and signer.  The truststore must contain the public certificate for the root CA.  Having all the public certificates for every signer for the NiFi certificate to the Root CA makes up the complete trust chain required for trust of the signed NiFi certificate. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

The error ERR_BAD_SSL_CLIENT_AUTH_CERT is a security-related bug that appears in web browsers, especially Google Chrome, due to a failure to interact with the SSL/TLS client authentication process.  This issue arises when SSL/TLS certificates are required on both client and server sides, but the client fails to present a valid certificate or the server can't verify it. Common causes include certificate misconfiguration, incorrect device date/time, software issues, or interference from browser extensions and antivirus programs. There are many different ways to fix the error which you need to understand properly in detail. Furthermore I found the helpful resource at:-  https://cheapsslweb.com/resources/how-to-fix-the-err_bad_ssl_client_auth_cert-error. I hope it helps!     ... View more

Preferred to have new question for unique questions, but.... Keep in mind these things when it comes to user identities and authorizations: 1. user identities are case sensitive in NiFi.  So the user identity from oidc must match exactly the initial admin user identity you passed to the file-user-group-provider and the file-access-policy-provider. 2. The file-user-group-provider will only generate the users.xml file if it does NOT already exist.  So if you edit the configuration of the file-user-group-provide after the users.xml already exists, those change will not be made to that existing users.xml file.  (remove it and restart so it gets created again) 3.  The file-access-policy-provider will only generate the authorizations.xml file if it does not exist.  It also will not modify an already existing authorizations.xml file if you make modifications to the provider. 4. Additional user identities and authorization post accessing your NiFi with your initial admin are done directly with the NiFi UI.  Those additions made from the UI will be persisted in the users.xml and authorizations.xml files If above does not help, please start a new community question with the details of your issue. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

Hello @MattWho thank you for your guidance, I just posted a topic I would be very appreciative with your help ... View more

Possibly related to https://issues.apache.org/jira/browse/NIFI-14462 I suggest reviewing discussion in this Apache Jira and reviewing your "nifi.web.request.timeout" setting in the nifi.properties file. Making adjustments to this setting may help here. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more