Member since
09-29-2015
871
Posts
723
Kudos Received
255
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 4181 | 12-03-2018 02:26 PM | |
| 3147 | 10-16-2018 01:37 PM | |
| 4263 | 10-03-2018 06:34 PM | |
| 3100 | 09-05-2018 07:44 PM | |
| 2359 | 09-05-2018 07:31 PM |
09-07-2016
03:43 PM
1 Kudo
There isn't a specific place for config files in a NAR, a NAR is only bundle of JARs, so you would have to put all the config files in your processors project in src/main/resources which would bundle them into the processors JAR so they are on the classpath.
... View more
09-07-2016
03:11 PM
1 Kudo
Ok thanks for providing that... When the NAR module gets built it uses a Maven plugin for packaging a NAR, this based on the packaging element in the pom.xml saying "nar". That plugin takes all of the dependencies of the NAR module, and all of their transitive dependencies, and packages them into a single archive (the NAR). After running a build, if you take the NAR file from the target directory and unzip it, you should see a directory like "META-INF/bundled-dependencies/" and that will show you all the JARs that are included in the NAR. In your example when the NAR module is built it will first see the dependency on nifi-demo-processors, so it will include that JAR, then it will go to through the dependencies of nifi-demo-processors and include all those JARs, and also their transitive dependencies. So in your screenshot, if you want everything in common-lib and lib to be accessible to your processor, then all of those JARs need to be listed as a dependency in the processors pom, or need to be transitive dependencies of something listed in the processors pom.
... View more
09-06-2016
03:21 PM
Can you share your NAR and processors project, or at least the pom.xml from each project? It is going to be hard to help without that. You should have something like: custom-nar pom.xml with dependency on custom-processor jar custom-processor pom.xml with dependency on module1 jar At that point, whatever module1 is dependent on would also get brought in.
... View more
09-05-2016
06:40 PM
I don't think you want that value set so high, the description of nifi.bored.yield.duration is: When a processor has no work to do (i.e., is "bored"), this is the amount of time it will wait before checking to see if it has data to work on. This way, it does not use up CPU resources by checking for new work too often. When setting this property, be aware that it could add extra latency for processors that constantly have work to do, as they will always wait this amount of time before checking for more work. The default value is 10 millis. Setting that to 30 minutes impacts all processors on your flow. You could change the scheduling of GetFile from 0 sec to 1 or 2 seconds and that would save a lot of executions/CPU.
... View more
09-05-2016
06:26 PM
1 Kudo
I don't know about Flume, but just wanted to mention that Apache NiFi has a ListenSyslog processor that supports TLS.
... View more
09-01-2016
01:37 AM
8 Kudos
Apache NiFi supports several authentication mechanisms and provides a pluggable authentication model, allowing
anyone to implement a custom identity provider. By default, NiFi always supports two-way SSL as an authentication
mechanism, but also provides the ability to use LDAP or Kerberos. This post will demonstrate how to use Kerberos
for authentication. Setting up a KDC In order to do anything with Kerberos, the first thing we need to do is setup a KDC. For this post we are going to use the *docker-kdc* project which makes it really easy to run a KDC on any environment. I'm working on OSX and had previously installed docker-machine. The *docker-kdc* project was originally created
to work with boot2docker, so to work around that we can do the following: Create a boot2docker machine: docker-machine create --driver virtualbox boot2docker
eval "$(docker-machine env boot2docker)" Create /usr/local/bin/boot2docker with the contents provided here https://gist.github.com/sttts/b9c03604be3da01b8d60 We also need to install a library called jq, which I did using homebrew: brew install jq After that we can clone the *docker-kdc* git repo and cd into the directory: git clone https://github.com/tillt/docker-kdc.git
cd docker-kdc At the root of this directory create a file named *kdc.json* which will be the config file used when setting up the KDC: { "principals": [
{
"id": "bbende@NIFI.APACHE.ORG",
"password": "bbende"
},
{
"id": "HTTP/nifi.apache.org@NIFI.APACHE.ORG",
"password": "http"
}
],
"domain": "nifi.apache.org",
"realm": "NIFI.APACHE.ORG",
"ip": "127.0.0.1",
"port": 48088
} This tells *docker-kdc* to create two principals, the first represents the end-user that will authenticate to NiFi,
and the second is the principal that NiFi will use to talk to the KDC.
We can now build and start the KDC: ./kdc build
./kdc start We can test the KDC by running *./kdc* test and should output similar to the following: Checking boot2docker active... ok
Trying to connect to KDC... at 192.168.99.101:48088... ok As part of starting the KDC, a *krb5.conf* and *krb5.keytab* were generated in the *docker-kdc* directory. The krb5.conf is the configuration file that clients would use to talk to the KDC running in the docker container,
and krb5.keytab contains the keytabs for the principals that were specified in kdc.json. In order to setup the current shell to leverage the krb5.conf generated by *docker-kdc*, and not the one in /etc, run
the following command: $(./kdc shellinit)
We should now be able to perform a kinit against the KDC using one of the principals that we specified: kinit bbende@NIFI.APACHE.ORG Performing a klist should show something like the following: klist
Credentials cache: API:5D669ADD-9028-441F-A6E0-C2C78DA04CC5
Principal: bbende@NIFI.APACHE.ORG
Issued Expires Principal
Aug 31 10:12:29 2016 Aug 31 20:12:27 2016 krbtgt/NIFI.APACHE.ORG@NIFI.APACHE.ORG One last bit of setup is that we will have to access NiFi using nifi.apache.org as the hostname in order to
line up with the domain in our KDC. Edit */etc/hosts* and map nifi.apache.org to localhost: 127.0.0.1localhost nifi.apache.org Configuring NiFi In order to perform any type of authentication, NiFi has to be configured to use https. One way to generate a certificate and truststore is using the NiFi Toolkit, you can read how to use the toolkit in the Apache NiFi Admin Guide. The nifi.properties related to https would look something like the following: nifi.remote.input.secure=true
nifi.web.https.host=localhost
nifi.web.https.port=9445
nifi.security.keystore=./conf/keystore.jks
nifi.security.keystoreType=jks
nifi.security.keystorePasswd=<your password>
nifi.security.keyPasswd=<your password>
nifi.security.truststore=./conf/truststore.jks
nifi.security.truststoreType=jks
nifi.security.truststorePasswd=<your password> We also need to set some additional properties related to Kerberos: nifi.security.user.login.identity.provider=kerberos-provider
nifi.kerberos.krb5.file=/path/to/docker-kdc/krb5.conf
nifi.kerberos.spnego.principal=HTTP/nifi.apache.org@NIFI.APACHE.ORG
nifi.kerberos.spnego.keytab.location=/path/to/docker-kdc/krb5.keytab
nifi.kerberos.spnego.authentication.expiration=12 hours The login identity provider is the identifier of a provider defined in login-identity-providers.xml. We need to edit
*login-identity-providers.xml* and uncomment the kerberos-provider: <provider>
<identifier>kerberos-provider</identifier>
<class>org.apache.nifi.kerberos.KerberosProvider</class>
<property name="Default Realm">NIFI.APACHE.ORG</property>
<property name="Authentication Expiration">12 hours</property>
</provider> The last thing we need to do is configure the Intial Admin Identity in *authorizers.xml*: <property name="Initial Admin Identity">bbende@NIFI.APACHE.ORG</property> If we were using certificates to authenticate to NiFi, we would put the DN from a certificate here, but since we are going to authenticate
with Kerberos, the admin needs to be the principal for our end user. At this point we can start NiFi: ./bin/nifi.sh start Kerberos Login There are two ways we can authenticate to NiFi using Kerberos: Kerberos Login - NiFi presents a login screen and authenticates the user against the KDC. SPNEGO - A ticket that was established outside of NiFi is forwarded to NiFi through the browser. If we navigate to NiFi in our browser at https://nifi.apache.org:9445/nifi, assuming
we didn't already configure our browser for SPNEGO, then we should get prompted with a login screen: NOTE: If you have a client certificate in your browser that corresponds to this NiFi instance, you may get prompted to
use that certificate, but we want to decline in this case so that we end up at the login page. At this login screen we can enter the principal name and password (in this example bbende and bbende) and we should get
authenticated and see the NiFi UI: SPNEGO Using SPNEGO requires some extra configuration in your browser. I am using Firefox which requires going to the about:config
page and setting the following properties: NOTE: The trusted URIs are the host and port being used to access NiFi in the browser, which in this case is https://nifi.apache.org:9445. This works because of the mapping we setup earlier to map nifi.apache.org to localhost.
If you followed the steps earlier, you probably already have a ticket, but you can check by issuing klist. If you don't
see a ticket for your user principal then you need to perform a kinit: kinit bbende@NIFI.APACHE.ORG You should then be able to go to the NiFi UI in your browser without requiring a login.
... View more
Labels:
08-31-2016
08:33 PM
There is only one canvas that can have many logical dataflows. Typically you can organize each logical dataflow into a process group, and then start and stop the whole process group.
... View more
08-31-2016
12:44 PM
2 Kudos
The NiFi UI has a Summary page from the top-right menu, as well as stats on each processor by right-clicking and selecting Status History. Both of those views show things like bytes read/written, flow files in/out, etc. If you want to track this information somewhere else, you can implement a custom ReportingTask to send this information somewhere. This is how Ambari is able to display the stats/graphs, there is an AmbariReportingTask: https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-ambari-bundle/nifi-ambari-reporting-task/src/main/java/org/apache/nifi/reporting/ambari/AmbariReportingTask.java
... View more
08-31-2016
12:00 PM
3 Kudos
In NiFi 1.0 the configuration was separated into a principal/keytab that NiFi uses to talk to other services vs. a principal/keytab used for authenticating users. For authenticating users you would need to populate these two properties: nifi.kerberos.spnego.principal* The name of the NiFi Kerberos service principal, if used. It is blank by default. Note that this property is used to authenticate NiFi users. Example: HTTP/nifi.example.com or HTTP/nifi.example.com@EXAMPLE.COM nifi.kerberos.spnego.keytab.location* The file path of the NiFi Kerberos keytab, if used. It is blank by default. Note that this property is used to authenticate NiFi users. Example: /etc/http-nifi.keytab In step 5 of that article, there is no more authorized-users.xml... you should put the identity of the initial admin user into conf/authorizers.xml. The identity would be kerberos principal you are going to login as. When NiFi starts and sees the initial admin, it will generate permissions for that user giving access to the UI.
... View more
08-31-2016
11:47 AM
3 Kudos
Yes you can use the QueryDatabaseTable processor for incrementally retrieving data from a relational database table, see this article: https://community.hortonworks.com/articles/51902/incremental-fetch-in-nifi-with-querydatabasetable.html Then you can use PutHDFS to store the data in HDFS.
... View more