@Zack Riesland The Cron you have there should run 18 minutes and 1 second into every hour. What you really are looking for as a cron here for 6:01pm is ( 0 1 18 * * ? * or 0 1 18 * * ? ) CRON driven: When using the CRON driven scheduling mode, the Processor is scheduled to run periodically, similar to the Timer driven scheduling mode. However, the CRON driven mode provides significantly more flexibility at the expense of increasing the complexity of the configuration. This value is made up of seven fields (where the seventh field is optional), each separated by a space. These fields include: Seconds Minutes Hours Day of Month Month Day of Week Year The value for each of these fields should be a number, range, or increment. Range here refers to a syntax of <number>-<number>. For example,the Seconds field could be set to 0-30, meaning that the Processor should only be scheduled if the time is 0 to 30 seconds after the minute. Additionally, a value of * indicates that all values are valid for this field. Multiple values can also be entered using a , as a separator: 0,5,10,15,30 . An increment is written as <start value>/<increment>. For example, settings a value of 0/10 for the seconds fields means that valid values are 0, 10, 20, 30, 40, and 50. However, if we change this to 5/10 , valid values become 5, 15, 25, 35, 45, and 55. For the Month field, valid values are 1 (January) through 12 (December). For the Day of Week field, valid values are 1 (Sunday) through 7 (Saturday). Additionally, a value of L may be appended to one of these values to indicate the last occurrence of this day in the month. For example, 1L can be used to indicate the last Monday of the month. Thanks, Matt ... View more

@mayki wogno In order to list a queue you need the "view the data" policy. in order to empty a queue you need the "modify the data" policy. If you are working with a NiFi cluster, all your nodes in the cluster will also need to be granted these policies as well. Click on the key in the "operate" window to the left of the Canvas: Then select the two policies listed above (Click override if you want to create a new policy and not edit the parent policy that is inherited). Add the Cluster node users and any other users you want to have those abilities. Thanks, Matt ... View more

@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