Re: [VOTE] Release Apache NiFi 1.1.1 (RC1)

[Koji Kawamura]

+1 (non-binding)

- Built and tested on OSX with contrib-check.
- Ran followings with Standalone/Cluster/Secure/Plain NiFi environments
  - Test Consume/Publish with Kafka 0.10 using demarcator
  - Create, download, upload and instantiate template
  - Site-to-Site communication push/pull

On Wed, Dec 21, 2016 at 5:06 AM, Oleg Zhurakousky
 wrote:
> +1 (non-binding)
>
> Built and tested on OSX with contrib-check.
> Ran several basic flows
> Validated Import/Export templates (single node and 3 node cluster)
>
>> On Dec 20, 2016, at 1:49 PM, Joey Frazee  wrote:
>>
>> +1 (non-binding)
>>
>> - Verified commit hash, checksums and GPG signature
>> - Checked root LICENSE and NOTICE
>> - Checked version in pom files
>> - Ran `mvn -T 2.0C clean install -Pcontrib-check`
>> - Tested with PutElasticsearchHttp with/without connection failure 
>> (NIFI-3194)
>> - Tested with ValidateCsv (NIFI-3175)
>> - Tested CSV to Hive data flow with Avro, ORC conversions and PutHiveQL
>>
>>> On Dec 20, 2016, at 12:29 PM, James Wing  wrote:
>>>
>>> +1 (non-binding). I ran through the release helper -- verified hashes,
>>> license/notice/readme files, full build, and tested the resulting binary
>>> without issues on JDK 1.8.0_101, Amazon Linux.
>>>
>>> Thanks,
>>>
>>> James
>>>
>>> On Mon, Dec 19, 2016 at 2:35 PM, Joe Percivall <
>>> joeperciv...@yahoo.com.invalid> wrote:
>>>
 Hello Apache NiFi Community,

 I am pleased to be calling this vote for the source release of Apache
 NiFi, nifi-1.1.1.

 The source zip, including signatures, digests, etc. can be found at:
 https://repository.apache.org/content/repositories/orgapachenifi-1097

 The Git tag is nifi-1.1.1-RC1
 The Git commit hash is a92f2e36ed6be695e4dc6f624f6b3a96e6d1a57c
 * https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=
 a92f2e36ed6be695e4dc6f624f6b3a96e6d1a57c
 * https://github.com/apache/nifi/commit/a92f2e36ed6be695e4dc6f624f6b3a
 96e6d1a57c

 Checksums of nifi-1.1.1-source-release.zip:
 MD5: 74955060d8ee295d77a23607ac644a6e
 SHA1: 82efc0dc3141d0fad0205b33539e5928da87ad17
 SHA256: 25fab8d7abfecf4c0ccef1ed9cd5f0849c829c0741142ed4074bc8dd0781f7d0

 Release artifacts are signed with the following key:
 https://people.apache.org/keys/committer/jpercivall

 KEYS file available here:
 https://dist.apache.org/repos/dist/release/nifi/KEYS

 16 issues were closed/resolved for this release:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?
 projectId=12316020=12338797
 Release note highlights can be found here:
 https://cwiki.apache.org/confluence/display/NIFI/
 Release+Notes#ReleaseNotes-Version1.1.1

 The vote will be open for 72 hours.
 Please download the release candidate and evaluate the necessary items
 including checking hashes, signatures, build from source, and test. Then
 please vote:

 [ ] +1 Release this package as nifi-1.1.1
 [ ] +0 no opinion
 [ ] -1 Do not release this package because...

 Thanks!
>>
>>
>

Re: [ANNOUNCE] New Apache NiFi Committer Jeremy Dyer

[Andre]

Welcome aboard Jeremy and thank you for the contributions!

On Tue, Dec 20, 2016 at 12:23 PM, Aldrin Piri  wrote:

> On behalf of the Apache NiFI PMC, I am very pleased to announce that Jeremy
> Dyer has accepted the PMC's invitation to become a committer on the
> Apache NiFi project. We greatly appreciate all of Jeremy's hard work and
> generous contributions and look forward to continued involvement in the
> project.
>
> Jeremy’s contributions include creation a suite of the processors that
> aided in parsing HTML, build improvement and testing for MiNiFi, as well as
> many articles and presentations on using NiFi in new and novel ways.
>
> Welcome Jeremy!
>

Re: Legacy Authorized Users File approach not working?

[Russell Bateman]

Thanks, Bryan. I will try this again. Meanwhile, I've been studying our 
0.x LDAP twists and I am starting to feel sure I can replicate them in 
1.x. Both avenues will be useful to us. (But, I really liked 
nifi-toolkit and your tutorial.)


Best,
Russ

On 12/20/2016 03:41 PM, Bryan Bende wrote:

Russell,

To verify the conversion of the legacy authorized users file, I just did
the following...

1) Took a fresh build off master (1.2-SNAPSHOT)

2) Created an authorized-users.xml with the following content as a test:



 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 


3) Configured authorizers.xml as follows:


 file-provider
 org.apache.nifi.authorization.FileAuthorizer
 ./conf/authorizations.xml
 ./conf/users.xml
 
 
*/path/to/authorized-users.xml*
 

4) Set the necessary TLS/SSL properties in nifi.properties

5) Started up successfully

6) users.xml got created and had this:



 
 
 
 
 
 
 
 
 
 
 
 
 


7) authorizations.xml got created and had a bunch of policies for theses
users, not going to paste it because it was a bit long.

Now at this point I don't have a real certificate for any of these fakes
users 1-6, but in a real migration those users would be in your LDAP or you
would have a client certificate for one of them.

One thing to keep in mind is that the legacy migration only runs when there
are no other users or policies defined, it is meant to be a one time
initial start up task. So if you ever get into a weird state and want to
try it again, you will need to delete users.xml and authorizations.xml from
your conf directory to get back to a clean state.

Thanks,

Bryan


On Tue, Dec 20, 2016 at 5:10 PM, Russell Bateman 
wrote:


Bryan,

As I'm new to setting this up (why I'm tackling this at all), I initially
looked toJames Wing's tutorial . At the end of that, I had a file,
/authorized-users.xml/, which I wanted to provide via this "legacy"
interface to NiFi 1.1.0. The Administration Guide told me how to do that
and I did it, or so I thought. In the end, NiFi would not come up
complaining about a missing /users.xml/, when I provided an empty one (with
) that this was wrong too.

I am happy it works in this new way, after following your tutorial, but
what we've really got is complicated, it uses LDAP, and we might want to
take the "legacy" solution route to soften the impact on our /rpm/ and
Ansible work by falling back on what we've already got.

Sorting out that nightmare was going to be a subsequent step after getting
James Wing's tutorial working in NiFi 1.1.0 since it's written for NiFi
0.x, producing 0.x artifacts that I could use in 1.1.0, but without the
added LDAP complication that's present in our present, shipping 0.7.1
artifacts.

Does this make sense? I was trying to take a couple of paths in parallel
to get ready for switching from 0.x to 1.x.

Let's not waste your time. If there's value in my taking the output from
James Wing's tutorial and trying to make it work in NiFi 1.x, and reporting
what's not working to you guys, I'll do it. Otherwise, I was just going to
move on. Ultimately though, we will have to tackle getting our LDAP
solution rewritten for NiFi 1.x. If the legacy way of using 0.x artifacts
had worked right off, we'd probably have resorted to that. We (my
colleague, who originally injected our LDAP solution and I) will probably
at least try that way again in a few weeks before starting over from
scratch to shoehorn our LDAP stuff into NiFi 1.x.

(I've probably repeated myself here, sorry.)

Thanks for your help.

Russ



On 12/20/2016 01:32 PM, Bryan Bende wrote:


For the 0.x instance, can you elaborate on "it was not working"?

You should be able to point set "Legacy Authorized Users File" in
authorizers.xml to point to your old file, and leave the Initial Admin
blank.

On Tue, Dec 20, 2016 at 2:17 PM, Russell Bateman 
wrote:

Just getting time to return to this...

Bryan

First, I was trying to follow the admin guide for converting an existing
0.x instance. It was not working.

Second, however, I walked your tutorial successfully and created a secure
instance of NiFi (I'm not, at this moment, interested in creating a
cluster). I'm at least as interested in doing a native 1.x instance as
converting an old 0.x instance.

Thanks,

Russ


On 12/16/2016 04:05 PM, Bryan Bende wrote:

Russell,

If you are starting with an existing 1.x installation then this post
has a
tutorial that should cover all the steps to secure the installation:

http://bryanbende.com/development/2016/08/17/apache-nifi-1-
0-0-authorization-and-multi-tenancy

The short version is you should not have to create users.xml or
authorizations.xml, NiFi will do that for you the 

Re: Legacy Authorized Users File approach not working?

[Russell Bateman]

Bryan,

As I'm new to setting this up (why I'm tackling this at all), I 
initially looked toJames Wing's tutorial 
. At the end of 
that, I had a file, /authorized-users.xml/, which I wanted to provide 
via this "legacy" interface to NiFi 1.1.0. The Administration Guide told 
me how to do that and I did it, or so I thought. In the end, NiFi would 
not come up complaining about a missing /users.xml/, when I provided an 
empty one (with ) that this was wrong too.


I am happy it works in this new way, after following your tutorial, but 
what we've really got is complicated, it uses LDAP, and we might want to 
take the "legacy" solution route to soften the impact on our /rpm/ and 
Ansible work by falling back on what we've already got.


Sorting out that nightmare was going to be a subsequent step after 
getting James Wing's tutorial working in NiFi 1.1.0 since it's written 
for NiFi 0.x, producing 0.x artifacts that I could use in 1.1.0, but 
without the added LDAP complication that's present in our present, 
shipping 0.7.1 artifacts.


Does this make sense? I was trying to take a couple of paths in parallel 
to get ready for switching from 0.x to 1.x.


Let's not waste your time. If there's value in my taking the output from 
James Wing's tutorial and trying to make it work in NiFi 1.x, and 
reporting what's not working to you guys, I'll do it. Otherwise, I was 
just going to move on. Ultimately though, we will have to tackle getting 
our LDAP solution rewritten for NiFi 1.x. If the legacy way of using 0.x 
artifacts had worked right off, we'd probably have resorted to that. We 
(my colleague, who originally injected our LDAP solution and I) will 
probably at least try that way again in a few weeks before starting over 
from scratch to shoehorn our LDAP stuff into NiFi 1.x.


(I've probably repeated myself here, sorry.)

Thanks for your help.

Russ


On 12/20/2016 01:32 PM, Bryan Bende wrote:

For the 0.x instance, can you elaborate on "it was not working"?

You should be able to point set "Legacy Authorized Users File" in
authorizers.xml to point to your old file, and leave the Initial Admin
blank.

On Tue, Dec 20, 2016 at 2:17 PM, Russell Bateman 
wrote:


Just getting time to return to this...

Bryan

First, I was trying to follow the admin guide for converting an existing
0.x instance. It was not working.

Second, however, I walked your tutorial successfully and created a secure
instance of NiFi (I'm not, at this moment, interested in creating a
cluster). I'm at least as interested in doing a native 1.x instance as
converting an old 0.x instance.

Thanks,

Russ


On 12/16/2016 04:05 PM, Bryan Bende wrote:


Russell,

If you are starting with an existing 1.x installation then this post has a
tutorial that should cover all the steps to secure the installation:

http://bryanbende.com/development/2016/08/17/apache-nifi-1-
0-0-authorization-and-multi-tenancy

The short version is you should not have to create users.xml or
authorizations.xml, NiFi will do that for you the first time it starts
secured based on your authorizers.xml.

If you are converting an existing 0.x instance there is a way to auto
convert that through a property in authorizers.xml,  and it should be
explained in the admin guide as well.

Hope that helps.

-Bryan

On Fri, Dec 16, 2016 at 5:21 PM Russell Bateman 
wrote:

I'm working on securing NiFi 1.1.0 with SSL. As I'm following a tutorial

[1] written for 0.x, I'm attempting to use the legacy option in

/conf/authorizers.//xml/:



  

 file-provider

  org.apache.nifi.authorization.FileAuthorizer

 ./conf/authorizations.xml

 ./conf/users.xml

 

  *  ./conf/authorized-users.xml*



 

  





I fixed complaints of missing /users.xml/ already by supplying

/conf/users.xml/, no default for which exists:



  

  





It would appear that this is insufficient (/logs/nifi-app.log/):



org.springframework.beans.factory.BeanCreationException: Error creating

bean with name 'niFiWebApiSecurityConfiguration': Injection of autowired

dependencies failed; nested exception is

org.springframework.beans.factory.BeanCreationException: Could not

autowire method: public void


org.apache.nifi.web.NiFiWebApiSecurityConfiguration.setX509A
uthenticationProvider(org.apache.nifi.web.security.x509.
X509AuthenticationProvider);

nested exception is

org.springframework.beans.factory.BeanCreationException: Error creating

bean with name 'x509AuthenticationProvider' defined in class path

resource [nifi-web-security-context.xml]: Cannot resolve reference to

bean 'authorizer' while setting constructor argument; nested exception

is org.springframework.beans.factory.BeanCreationException: Error

creating bean with name 'authorizer': FactoryBean threw exception on

object creation; nested exception is

Re: Legacy Authorized Users File approach not working?

[Bryan Bende]

For the 0.x instance, can you elaborate on "it was not working"?

You should be able to point set "Legacy Authorized Users File" in
authorizers.xml to point to your old file, and leave the Initial Admin
blank.

On Tue, Dec 20, 2016 at 2:17 PM, Russell Bateman 
wrote:

> Just getting time to return to this...
>
> Bryan
>
> First, I was trying to follow the admin guide for converting an existing
> 0.x instance. It was not working.
>
> Second, however, I walked your tutorial successfully and created a secure
> instance of NiFi (I'm not, at this moment, interested in creating a
> cluster). I'm at least as interested in doing a native 1.x instance as
> converting an old 0.x instance.
>
> Thanks,
>
> Russ
>
>
> On 12/16/2016 04:05 PM, Bryan Bende wrote:
>
>> Russell,
>>
>> If you are starting with an existing 1.x installation then this post has a
>> tutorial that should cover all the steps to secure the installation:
>>
>> http://bryanbende.com/development/2016/08/17/apache-nifi-1-
>> 0-0-authorization-and-multi-tenancy
>>
>> The short version is you should not have to create users.xml or
>> authorizations.xml, NiFi will do that for you the first time it starts
>> secured based on your authorizers.xml.
>>
>> If you are converting an existing 0.x instance there is a way to auto
>> convert that through a property in authorizers.xml,  and it should be
>> explained in the admin guide as well.
>>
>> Hope that helps.
>>
>> -Bryan
>>
>> On Fri, Dec 16, 2016 at 5:21 PM Russell Bateman 
>> wrote:
>>
>> I'm working on securing NiFi 1.1.0 with SSL. As I'm following a tutorial
>>>
>>> [1] written for 0.x, I'm attempting to use the legacy option in
>>>
>>> /conf/authorizers.//xml/:
>>>
>>>
>>>
>>>  
>>>
>>> file-provider
>>>
>>>  org.apache.nifi.authorization.FileAuthorizer
>>>
>>> ./conf/authorizations.xml
>>>
>>> ./conf/users.xml
>>>
>>> 
>>>
>>>  *  ./conf/authorized-users.xml*
>>>
>>>
>>>
>>> 
>>>
>>>  
>>>
>>>
>>>
>>>
>>>
>>> I fixed complaints of missing /users.xml/ already by supplying
>>>
>>> /conf/users.xml/, no default for which exists:
>>>
>>>
>>>
>>>  
>>>
>>>  
>>>
>>>
>>>
>>>
>>>
>>> It would appear that this is insufficient (/logs/nifi-app.log/):
>>>
>>>
>>>
>>> org.springframework.beans.factory.BeanCreationException: Error creating
>>>
>>> bean with name 'niFiWebApiSecurityConfiguration': Injection of autowired
>>>
>>> dependencies failed; nested exception is
>>>
>>> org.springframework.beans.factory.BeanCreationException: Could not
>>>
>>> autowire method: public void
>>>
>>>
>>> org.apache.nifi.web.NiFiWebApiSecurityConfiguration.setX509A
>>> uthenticationProvider(org.apache.nifi.web.security.x509.
>>> X509AuthenticationProvider);
>>>
>>> nested exception is
>>>
>>> org.springframework.beans.factory.BeanCreationException: Error creating
>>>
>>> bean with name 'x509AuthenticationProvider' defined in class path
>>>
>>> resource [nifi-web-security-context.xml]: Cannot resolve reference to
>>>
>>> bean 'authorizer' while setting constructor argument; nested exception
>>>
>>> is org.springframework.beans.factory.BeanCreationException: Error
>>>
>>> creating bean with name 'authorizer': FactoryBean threw exception on
>>>
>>> object creation; nested exception is
>>>
>>> org.apache.nifi.authorization.exception.AuthorizerCreationException:
>>>
>>> javax.xml.bind.UnmarshalException
>>>
>>>- with linked exception:
>>>
>>> *[org.xml.sax.SAXParseException; systemId:
>>>
>>> file:/home/russ/dev/nifi/secure-nifi/nifi-1.1.0/./conf/users.xml;
>>>
>>> lineNumber: 2; columnNumber: 9; cvc-elt.1: Cannot find the declaration
>>>
>>> of element 'users'.]*
>>>
>>>
>>>
>>> I'm defining users by means of a 0.x /authorized-users.xml/ file, not
>>>
>>> the /users.xml/ file. There are no examples I can find of /users.xml/
>>>
>>> and /authorizations.xml/, empty or otherwise, to compare with existing,
>>>
>>> functioning NiFi 0.x installations, so I can't tell if the whole legacy
>>>
>>> option just doesn't work anyway or if it's just that I've got stuff
>>>
>>> wrong still.
>>>
>>>
>>>
>>> Grateful for comments or samples of working /users.xml/ and
>>>
>>> /authoriz//ations.xml/.
>>>
>>>
>>>
>>> [1] http://www.batchiq.com/nifi-configuring-ssl-auth.html
>>>
>>> --
>>>
>> Sent from Gmail Mobile
>>
>>
>

Re: [VOTE] Release Apache NiFi 1.1.1 (RC1)

[Oleg Zhurakousky]

+1 (non-binding) 

Built and tested on OSX with contrib-check.
Ran several basic flows
Validated Import/Export templates (single node and 3 node cluster)

> On Dec 20, 2016, at 1:49 PM, Joey Frazee  wrote:
> 
> +1 (non-binding)
> 
> - Verified commit hash, checksums and GPG signature
> - Checked root LICENSE and NOTICE
> - Checked version in pom files
> - Ran `mvn -T 2.0C clean install -Pcontrib-check`
> - Tested with PutElasticsearchHttp with/without connection failure (NIFI-3194)
> - Tested with ValidateCsv (NIFI-3175)
> - Tested CSV to Hive data flow with Avro, ORC conversions and PutHiveQL
> 
>> On Dec 20, 2016, at 12:29 PM, James Wing  wrote:
>> 
>> +1 (non-binding). I ran through the release helper -- verified hashes,
>> license/notice/readme files, full build, and tested the resulting binary
>> without issues on JDK 1.8.0_101, Amazon Linux.
>> 
>> Thanks,
>> 
>> James
>> 
>> On Mon, Dec 19, 2016 at 2:35 PM, Joe Percivall <
>> joeperciv...@yahoo.com.invalid> wrote:
>> 
>>> Hello Apache NiFi Community,
>>> 
>>> I am pleased to be calling this vote for the source release of Apache
>>> NiFi, nifi-1.1.1.
>>> 
>>> The source zip, including signatures, digests, etc. can be found at:
>>> https://repository.apache.org/content/repositories/orgapachenifi-1097
>>> 
>>> The Git tag is nifi-1.1.1-RC1
>>> The Git commit hash is a92f2e36ed6be695e4dc6f624f6b3a96e6d1a57c
>>> * https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=
>>> a92f2e36ed6be695e4dc6f624f6b3a96e6d1a57c
>>> * https://github.com/apache/nifi/commit/a92f2e36ed6be695e4dc6f624f6b3a
>>> 96e6d1a57c
>>> 
>>> Checksums of nifi-1.1.1-source-release.zip:
>>> MD5: 74955060d8ee295d77a23607ac644a6e
>>> SHA1: 82efc0dc3141d0fad0205b33539e5928da87ad17
>>> SHA256: 25fab8d7abfecf4c0ccef1ed9cd5f0849c829c0741142ed4074bc8dd0781f7d0
>>> 
>>> Release artifacts are signed with the following key:
>>> https://people.apache.org/keys/committer/jpercivall
>>> 
>>> KEYS file available here:
>>> https://dist.apache.org/repos/dist/release/nifi/KEYS
>>> 
>>> 16 issues were closed/resolved for this release:
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>>> projectId=12316020=12338797
>>> Release note highlights can be found here:
>>> https://cwiki.apache.org/confluence/display/NIFI/
>>> Release+Notes#ReleaseNotes-Version1.1.1
>>> 
>>> The vote will be open for 72 hours.
>>> Please download the release candidate and evaluate the necessary items
>>> including checking hashes, signatures, build from source, and test. Then
>>> please vote:
>>> 
>>> [ ] +1 Release this package as nifi-1.1.1
>>> [ ] +0 no opinion
>>> [ ] -1 Do not release this package because...
>>> 
>>> Thanks!
> 
> 

Re: Legacy Authorized Users File approach not working?

[Russell Bateman]

Just getting time to return to this...

Bryan

First, I was trying to follow the admin guide for converting an existing 
0.x instance. It was not working.


Second, however, I walked your tutorial successfully and created a 
secure instance of NiFi (I'm not, at this moment, interested in creating 
a cluster). I'm at least as interested in doing a native 1.x instance as 
converting an old 0.x instance.


Thanks,

Russ

On 12/16/2016 04:05 PM, Bryan Bende wrote:

Russell,

If you are starting with an existing 1.x installation then this post has a
tutorial that should cover all the steps to secure the installation:

http://bryanbende.com/development/2016/08/17/apache-nifi-1-0-0-authorization-and-multi-tenancy

The short version is you should not have to create users.xml or
authorizations.xml, NiFi will do that for you the first time it starts
secured based on your authorizers.xml.

If you are converting an existing 0.x instance there is a way to auto
convert that through a property in authorizers.xml,  and it should be
explained in the admin guide as well.

Hope that helps.

-Bryan

On Fri, Dec 16, 2016 at 5:21 PM Russell Bateman 
wrote:


I'm working on securing NiFi 1.1.0 with SSL. As I'm following a tutorial

[1] written for 0.x, I'm attempting to use the legacy option in

/conf/authorizers.//xml/:



 

file-provider

 org.apache.nifi.authorization.FileAuthorizer

./conf/authorizations.xml

./conf/users.xml



 *  ./conf/authorized-users.xml*





 





I fixed complaints of missing /users.xml/ already by supplying

/conf/users.xml/, no default for which exists:



 

 





It would appear that this is insufficient (/logs/nifi-app.log/):



org.springframework.beans.factory.BeanCreationException: Error creating

bean with name 'niFiWebApiSecurityConfiguration': Injection of autowired

dependencies failed; nested exception is

org.springframework.beans.factory.BeanCreationException: Could not

autowire method: public void


org.apache.nifi.web.NiFiWebApiSecurityConfiguration.setX509AuthenticationProvider(org.apache.nifi.web.security.x509.X509AuthenticationProvider);

nested exception is

org.springframework.beans.factory.BeanCreationException: Error creating

bean with name 'x509AuthenticationProvider' defined in class path

resource [nifi-web-security-context.xml]: Cannot resolve reference to

bean 'authorizer' while setting constructor argument; nested exception

is org.springframework.beans.factory.BeanCreationException: Error

creating bean with name 'authorizer': FactoryBean threw exception on

object creation; nested exception is

org.apache.nifi.authorization.exception.AuthorizerCreationException:

javax.xml.bind.UnmarshalException

   - with linked exception:

*[org.xml.sax.SAXParseException; systemId:

file:/home/russ/dev/nifi/secure-nifi/nifi-1.1.0/./conf/users.xml;

lineNumber: 2; columnNumber: 9; cvc-elt.1: Cannot find the declaration

of element 'users'.]*



I'm defining users by means of a 0.x /authorized-users.xml/ file, not

the /users.xml/ file. There are no examples I can find of /users.xml/

and /authorizations.xml/, empty or otherwise, to compare with existing,

functioning NiFi 0.x installations, so I can't tell if the whole legacy

option just doesn't work anyway or if it's just that I've got stuff

wrong still.



Grateful for comments or samples of working /users.xml/ and

/authoriz//ations.xml/.



[1] http://www.batchiq.com/nifi-configuring-ssl-auth.html

--

Sent from Gmail Mobile

Re: [VOTE] Release Apache NiFi 1.1.1 (RC1)

[Joey Frazee]

+1 (non-binding)

- Verified commit hash, checksums and GPG signature
- Checked root LICENSE and NOTICE
- Checked version in pom files
- Ran `mvn -T 2.0C clean install -Pcontrib-check`
- Tested with PutElasticsearchHttp with/without connection failure (NIFI-3194)
- Tested with ValidateCsv (NIFI-3175)
- Tested CSV to Hive data flow with Avro, ORC conversions and PutHiveQL

> On Dec 20, 2016, at 12:29 PM, James Wing  wrote:
> 
> +1 (non-binding). I ran through the release helper -- verified hashes,
> license/notice/readme files, full build, and tested the resulting binary
> without issues on JDK 1.8.0_101, Amazon Linux.
> 
> Thanks,
> 
> James
> 
> On Mon, Dec 19, 2016 at 2:35 PM, Joe Percivall <
> joeperciv...@yahoo.com.invalid> wrote:
> 
>> Hello Apache NiFi Community,
>> 
>> I am pleased to be calling this vote for the source release of Apache
>> NiFi, nifi-1.1.1.
>> 
>> The source zip, including signatures, digests, etc. can be found at:
>> https://repository.apache.org/content/repositories/orgapachenifi-1097
>> 
>> The Git tag is nifi-1.1.1-RC1
>> The Git commit hash is a92f2e36ed6be695e4dc6f624f6b3a96e6d1a57c
>> * https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=
>> a92f2e36ed6be695e4dc6f624f6b3a96e6d1a57c
>> * https://github.com/apache/nifi/commit/a92f2e36ed6be695e4dc6f624f6b3a
>> 96e6d1a57c
>> 
>> Checksums of nifi-1.1.1-source-release.zip:
>> MD5: 74955060d8ee295d77a23607ac644a6e
>> SHA1: 82efc0dc3141d0fad0205b33539e5928da87ad17
>> SHA256: 25fab8d7abfecf4c0ccef1ed9cd5f0849c829c0741142ed4074bc8dd0781f7d0
>> 
>> Release artifacts are signed with the following key:
>> https://people.apache.org/keys/committer/jpercivall
>> 
>> KEYS file available here:
>> https://dist.apache.org/repos/dist/release/nifi/KEYS
>> 
>> 16 issues were closed/resolved for this release:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>> projectId=12316020=12338797
>> Release note highlights can be found here:
>> https://cwiki.apache.org/confluence/display/NIFI/
>> Release+Notes#ReleaseNotes-Version1.1.1
>> 
>> The vote will be open for 72 hours.
>> Please download the release candidate and evaluate the necessary items
>> including checking hashes, signatures, build from source, and test. Then
>> please vote:
>> 
>> [ ] +1 Release this package as nifi-1.1.1
>> [ ] +0 no opinion
>> [ ] -1 Do not release this package because...
>> 
>> Thanks!

Re: [VOTE] Release Apache NiFi 1.1.1 (RC1)

[James Wing]

+1 (non-binding). I ran through the release helper -- verified hashes,
license/notice/readme files, full build, and tested the resulting binary
without issues on JDK 1.8.0_101, Amazon Linux.

Thanks,

James

On Mon, Dec 19, 2016 at 2:35 PM, Joe Percivall <
joeperciv...@yahoo.com.invalid> wrote:

> Hello Apache NiFi Community,
>
> I am pleased to be calling this vote for the source release of Apache
> NiFi, nifi-1.1.1.
>
> The source zip, including signatures, digests, etc. can be found at:
> https://repository.apache.org/content/repositories/orgapachenifi-1097
>
> The Git tag is nifi-1.1.1-RC1
> The Git commit hash is a92f2e36ed6be695e4dc6f624f6b3a96e6d1a57c
> * https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=
> a92f2e36ed6be695e4dc6f624f6b3a96e6d1a57c
> * https://github.com/apache/nifi/commit/a92f2e36ed6be695e4dc6f624f6b3a
> 96e6d1a57c
>
> Checksums of nifi-1.1.1-source-release.zip:
> MD5: 74955060d8ee295d77a23607ac644a6e
> SHA1: 82efc0dc3141d0fad0205b33539e5928da87ad17
> SHA256: 25fab8d7abfecf4c0ccef1ed9cd5f0849c829c0741142ed4074bc8dd0781f7d0
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/jpercivall
>
> KEYS file available here:
> https://dist.apache.org/repos/dist/release/nifi/KEYS
>
> 16 issues were closed/resolved for this release:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12316020=12338797
> Release note highlights can be found here:
> https://cwiki.apache.org/confluence/display/NIFI/
> Release+Notes#ReleaseNotes-Version1.1.1
>
> The vote will be open for 72 hours.
> Please download the release candidate and evaluate the necessary items
> including checking hashes, signatures, build from source, and test. Then
> please vote:
>
> [ ] +1 Release this package as nifi-1.1.1
> [ ] +0 no opinion
> [ ] -1 Do not release this package because...
>
> Thanks!

Re: [ANNOUNCE] New Apache NiFi Committer Jeremy Dyer

[Jeff]

Congrats Jeremy!

On Tue, Dec 20, 2016 at 9:16 AM Bryan Rosander  wrote:

> Congrats Jeremy!
>
> On Tue, Dec 20, 2016 at 9:03 AM, Oleg Zhurakousky <
> ozhurakou...@hortonworks.com> wrote:
>
> > Congrats Jeremy! Well deserved!
> > > On Dec 20, 2016, at 8:46 AM, Yolanda Davis 
> > wrote:
> > >
> > > Congratulations Jeremy!
> > >
> > > On Mon, Dec 19, 2016 at 8:23 PM, Aldrin Piri 
> wrote:
> > >
> > >> On behalf of the Apache NiFI PMC, I am very pleased to announce that
> > Jeremy
> > >> Dyer has accepted the PMC's invitation to become a committer on the
> > >> Apache NiFi project. We greatly appreciate all of Jeremy's hard work
> and
> > >> generous contributions and look forward to continued involvement in
> the
> > >> project.
> > >>
> > >> Jeremy’s contributions include creation a suite of the processors that
> > >> aided in parsing HTML, build improvement and testing for MiNiFi, as
> > well as
> > >> many articles and presentations on using NiFi in new and novel ways.
> > >>
> > >> Welcome Jeremy!
> > >>
> > >
> > >
> > >
> > > --
> > > --
> > > yolanda.m.da...@gmail.com
> > > @YolandaMDavis
> >
> >
>

Re: OCSP validation not happening for cluster servers

[Matt Gilman]

Joe,

I believe the JIRA is questioning whether we need to be manually verifying.
It probably makes sense to answer that first. Once we know that answer we
can establish the best path to appropriately resolve NIFI-1364 and ensure
that we are verifying the certificates in all places. I'm going to do some
testing locally to see if I can answer that question. Please do the same
and then let's sync up again here.

Also, a lot of good details here [1].

Matt

[1]
http://blogs.nologin.es/rickyepoderi/index.php?/archives/77-BUG-in-Java-OCSP-Implementation-PKIX.html

On Tue, Dec 20, 2016 at 8:33 AM, Joe Skora  wrote:

> Matt,
>
> We found the "ocsp.enable" Java Security setting in
> $JRE/lib/security/java.security, but setting that did NOT change the
> behavior and the node with the revoked certificate could still join the
> cluster.
>
> Looking at the posts referenced by NIFI-1364 [1], they all seem to discuss
> needed code changes.  For example, the first link [2], includes this
> example.
>
> PKIXParameters params = new PKIXParameters(anchors);
>
> // Activate certificate revocation checking
> params.setRevocationEnabled(true);
>
> // Activate OCSP
> Security.setProperty("ocsp.enable", "true");
>
>
> It looks like "ocsp.enable" may only matter if revocation is enabled in the
> first place and that appears to be what the
> PKIXParameters.setRevocationEnabled(true) call accomplishes.  I don't know
> the clustering code well enough to dive in, but if you can point out where
> to look I can try digging into it myself.  For now, it still appears that
> cluster nodes are not rejected due to OCSP revocation.
>
> Thanks,
> Joe
>
> [1] https://issues.apache.org/jira/browse/NIFI-1364
> [2] https://blogs.oracle.com/xuelei/entry/enable_ocsp_checking
>
> On Mon, Dec 19, 2016 at 5:57 PM, Joe Skora  wrote:
>
> > Thanks, I'll check on the configuration used for the tests and reply back
> > here once that's clear.
> >
> > On Mon, Dec 19, 2016 at 12:48 PM, Matt Gilman 
> > wrote:
> >
> >> The existing OCSP logic is part of the REST API filter chain. The
> >> communications you're referring to are happening outside of that. Have
> you
> >> tried enabling OCSP as part of the SSL/TLS handshake as was mentioned in
> >> the JIRA [1]. Using the built-in features should allow us to use it
> >> throughout the application regardless of the communications in question
> >> (cluster protocol, site to site, REST API, etc).
> >>
> >> Matt
> >>
> >> [1] https://issues.apache.org/jira/browse/NIFI-1364
> >>
> >> On Mon, Dec 19, 2016 at 12:18 PM, Joe Skora  wrote:
> >>
> >> > Matt,
> >> >
> >> > It's not clients we are concerned with, but cluster servers.
> >> >
> >> > The test process used Java 1.8.0_65 and NiFi 0.7.1 to do the
> following.
> >> >
> >> >1. Configure a cluster with valid certificates for each node,
> >> >2. revoke one node's certificate,
> >> >3. restart the cluster,
> >> >4. confirm with keytool that the node is invalid, and
> >> >5. test whether the node can still join the cluster.
> >> >
> >> > The expectation was that in #5 the node would not be able to join to
> the
> >> > cluster, but it could.
> >> >
> >> > Whether the OCSP check should be handled by NiFi or Java, it doesn't
> >> appear
> >> > to be happening.
> >> >
> >> > Thanks,
> >> > Joe
> >> >
> >> > On Mon, Dec 19, 2016 at 11:22 AM, Matt Gilman <
> matt.c.gil...@gmail.com>
> >> > wrote:
> >> >
> >> > > Joe,
> >> > >
> >> > > If a server connects through the REST API it should be subject to
> the
> >> > same
> >> > > checks as a regular user. Can you provide more details regarding the
> >> > > requests that aren't being checked correctly?
> >> > >
> >> > > Additionally, there was some discussion whether we need the
> additional
> >> > > checks in the first place as we may be able to leverage checks built
> >> into
> >> > > Java [1].
> >> > >
> >> > > Matt
> >> > >
> >> > > [1] https://issues.apache.org/jira/browse/NIFI-1364
> >> > >
> >> > > On Mon, Dec 19, 2016 at 10:57 AM, Joe Skora 
> wrote:
> >> > >
> >> > > > This could very soon be a show stopper for us.
> >> > > >
> >> > > > Does anyone have any thoughts that might help us get this
> straight?
> >> > > >
> >> > > > On Wed, Dec 14, 2016 at 2:23 PM, Joe Skora 
> >> wrote:
> >> > > >
> >> > > > > Running Apache NiFi 0.7.1, we see clients rejected due to OCSP
> >> > > revocation
> >> > > > > of their certificates but we think we are seeing instances where
> >> > > servers
> >> > > > > using OCSP revoked certificates are still able to connect to a
> >> > cluster.
> >> > > > >
> >> > > > > Should OCSP revocation cause these servers to be rejected by the
> >> > > cluster?
> >> > > > >
> >> > > > > Could this be a configuration problem even though the revoked
> >> clients
> >> > > > > certificates are rejected?
> >> > > > >
> >> > > > > Thanks,
> >> > > > > Joe
> >> > > > >
> >> > > >

Re: [ANNOUNCE] New Apache NiFi Committer Jeremy Dyer

[Bryan Rosander]

Congrats Jeremy!

On Tue, Dec 20, 2016 at 9:03 AM, Oleg Zhurakousky <
ozhurakou...@hortonworks.com> wrote:

> Congrats Jeremy! Well deserved!
> > On Dec 20, 2016, at 8:46 AM, Yolanda Davis 
> wrote:
> >
> > Congratulations Jeremy!
> >
> > On Mon, Dec 19, 2016 at 8:23 PM, Aldrin Piri  wrote:
> >
> >> On behalf of the Apache NiFI PMC, I am very pleased to announce that
> Jeremy
> >> Dyer has accepted the PMC's invitation to become a committer on the
> >> Apache NiFi project. We greatly appreciate all of Jeremy's hard work and
> >> generous contributions and look forward to continued involvement in the
> >> project.
> >>
> >> Jeremy’s contributions include creation a suite of the processors that
> >> aided in parsing HTML, build improvement and testing for MiNiFi, as
> well as
> >> many articles and presentations on using NiFi in new and novel ways.
> >>
> >> Welcome Jeremy!
> >>
> >
> >
> >
> > --
> > --
> > yolanda.m.da...@gmail.com
> > @YolandaMDavis
>
>

Re: [ANNOUNCE] New Apache NiFi Committer Jeremy Dyer

[Oleg Zhurakousky]

Congrats Jeremy! Well deserved!
> On Dec 20, 2016, at 8:46 AM, Yolanda Davis  wrote:
> 
> Congratulations Jeremy!
> 
> On Mon, Dec 19, 2016 at 8:23 PM, Aldrin Piri  wrote:
> 
>> On behalf of the Apache NiFI PMC, I am very pleased to announce that Jeremy
>> Dyer has accepted the PMC's invitation to become a committer on the
>> Apache NiFi project. We greatly appreciate all of Jeremy's hard work and
>> generous contributions and look forward to continued involvement in the
>> project.
>> 
>> Jeremy’s contributions include creation a suite of the processors that
>> aided in parsing HTML, build improvement and testing for MiNiFi, as well as
>> many articles and presentations on using NiFi in new and novel ways.
>> 
>> Welcome Jeremy!
>> 
> 
> 
> 
> -- 
> --
> yolanda.m.da...@gmail.com
> @YolandaMDavis

Re: [ANNOUNCE] New Apache NiFi Committer Jeremy Dyer

[Jeremy Dyer]

Thank you everyone. I'm really pumped to be part of such a thriving community! 
I look forward to working more closely with you all and helping continue your 
existing legacy of building awesome stuff. 

- Jeremy Dyer

Sent from my iPhone
> On Dec 20, 2016, at 8:01 AM, Koji Kawamura  wrote:
> 
> Congratulations Jeremy!!
> 
> Koji
> 
> On Dec 20, 2016 9:26 PM, "Rob Moran"  wrote:
> 
> Thank you and congratulations Jeremy!
> 
> Rob
> 
>> On Tue, Dec 20, 2016 at 7:14 AM, Joe Skora  wrote:
>> 
>> Congrats Jeremy, welcome!
>> 
>> On Tue, Dec 20, 2016 at 8:47 AM, Pierre Villard <
>> pierre.villard...@gmail.com
>>> wrote:
>> 
>>> Congrats Jeremy, great to have you!
>>> 
>>> 2016-12-20 6:18 GMT+01:00 Andrew Psaltis :
>>> 
 Congrats Jeremy!!
 
> On Mon, Dec 19, 2016 at 9:45 PM, Joe Witt  wrote:
> 
> Well done Jeremy and thanks for all your contributions!
> 
> On Mon, Dec 19, 2016 at 9:24 PM, Joe Percivall
>  wrote:
>> Congrats Jeremy! Very well deserved.
>> 
>> 
>> - - - - - - Joseph Percivalllinkedin.com/in/Percivalle:
> joeperciv...@yahoo.com
>> 
>> 
>> On Monday, December 19, 2016, 9:13:22 PM EST, Bryan Bende <
> bbe...@gmail.com> wrote:Congrats and welcome!
>> 
>> On Mon, Dec 19, 2016 at 8:52 PM Matt Burgess >> 
> wrote:
>> 
>> Congratulations Jeremy and welcome! Very well deserved.
>> 
>> 
>> 
>> Regards,
>> 
>> Matt
>> 
>> 
>> 
>> On Mon, Dec 19, 2016 at 8:23 PM, Aldrin Piri 
 wrote:
>> 
>>> On behalf of the Apache NiFI PMC, I am very pleased to announce
>> that
>> Jeremy
>> 
>>> Dyer has accepted the PMC's invitation to become a committer on
>> the
> Apache
>> 
>>> NiFi project. We greatly appreciate all of Jeremy's hard work and
> generous
>> 
>>> contributions and look forward to continued involvement in the
 project.
>> 
>>> 
>> 
>>> Jeremy’s contributions include creation a suite of the processors
>>> that
>> aided
>> 
>>> in parsing HTML, build improvement and testing for MiNiFi, as
> well
>>> as
> many
>> 
>>> articles and presentations on using NiFi in new and novel ways.
>> 
>>> 
>> 
>>> Welcome Jeremy!
>> 
>> --
>> Sent from Gmail Mobile
> 
 
 
 
 --
 Thanks,
 Andrew
 
 Subscribe to my book: Streaming Data 
 
 twiiter: @itmdata 
 
>>> 
>> 

Re: [ANNOUNCE] New Apache NiFi Committer Jeremy Dyer

[Yolanda Davis]

Congratulations Jeremy!

On Mon, Dec 19, 2016 at 8:23 PM, Aldrin Piri  wrote:

> On behalf of the Apache NiFI PMC, I am very pleased to announce that Jeremy
> Dyer has accepted the PMC's invitation to become a committer on the
> Apache NiFi project. We greatly appreciate all of Jeremy's hard work and
> generous contributions and look forward to continued involvement in the
> project.
>
> Jeremy’s contributions include creation a suite of the processors that
> aided in parsing HTML, build improvement and testing for MiNiFi, as well as
> many articles and presentations on using NiFi in new and novel ways.
>
> Welcome Jeremy!
>



-- 
--
yolanda.m.da...@gmail.com
@YolandaMDavis

Re: OCSP validation not happening for cluster servers

[Joe Skora]

Matt,

We found the "ocsp.enable" Java Security setting in
$JRE/lib/security/java.security, but setting that did NOT change the
behavior and the node with the revoked certificate could still join the
cluster.

Looking at the posts referenced by NIFI-1364 [1], they all seem to discuss
needed code changes.  For example, the first link [2], includes this
example.

PKIXParameters params = new PKIXParameters(anchors);

// Activate certificate revocation checking
params.setRevocationEnabled(true);

// Activate OCSP
Security.setProperty("ocsp.enable", "true");


It looks like "ocsp.enable" may only matter if revocation is enabled in the
first place and that appears to be what the
PKIXParameters.setRevocationEnabled(true) call accomplishes.  I don't know
the clustering code well enough to dive in, but if you can point out where
to look I can try digging into it myself.  For now, it still appears that
cluster nodes are not rejected due to OCSP revocation.

Thanks,
Joe

[1] https://issues.apache.org/jira/browse/NIFI-1364
[2] https://blogs.oracle.com/xuelei/entry/enable_ocsp_checking

On Mon, Dec 19, 2016 at 5:57 PM, Joe Skora  wrote:

> Thanks, I'll check on the configuration used for the tests and reply back
> here once that's clear.
>
> On Mon, Dec 19, 2016 at 12:48 PM, Matt Gilman 
> wrote:
>
>> The existing OCSP logic is part of the REST API filter chain. The
>> communications you're referring to are happening outside of that. Have you
>> tried enabling OCSP as part of the SSL/TLS handshake as was mentioned in
>> the JIRA [1]. Using the built-in features should allow us to use it
>> throughout the application regardless of the communications in question
>> (cluster protocol, site to site, REST API, etc).
>>
>> Matt
>>
>> [1] https://issues.apache.org/jira/browse/NIFI-1364
>>
>> On Mon, Dec 19, 2016 at 12:18 PM, Joe Skora  wrote:
>>
>> > Matt,
>> >
>> > It's not clients we are concerned with, but cluster servers.
>> >
>> > The test process used Java 1.8.0_65 and NiFi 0.7.1 to do the following.
>> >
>> >1. Configure a cluster with valid certificates for each node,
>> >2. revoke one node's certificate,
>> >3. restart the cluster,
>> >4. confirm with keytool that the node is invalid, and
>> >5. test whether the node can still join the cluster.
>> >
>> > The expectation was that in #5 the node would not be able to join to the
>> > cluster, but it could.
>> >
>> > Whether the OCSP check should be handled by NiFi or Java, it doesn't
>> appear
>> > to be happening.
>> >
>> > Thanks,
>> > Joe
>> >
>> > On Mon, Dec 19, 2016 at 11:22 AM, Matt Gilman 
>> > wrote:
>> >
>> > > Joe,
>> > >
>> > > If a server connects through the REST API it should be subject to the
>> > same
>> > > checks as a regular user. Can you provide more details regarding the
>> > > requests that aren't being checked correctly?
>> > >
>> > > Additionally, there was some discussion whether we need the additional
>> > > checks in the first place as we may be able to leverage checks built
>> into
>> > > Java [1].
>> > >
>> > > Matt
>> > >
>> > > [1] https://issues.apache.org/jira/browse/NIFI-1364
>> > >
>> > > On Mon, Dec 19, 2016 at 10:57 AM, Joe Skora  wrote:
>> > >
>> > > > This could very soon be a show stopper for us.
>> > > >
>> > > > Does anyone have any thoughts that might help us get this straight?
>> > > >
>> > > > On Wed, Dec 14, 2016 at 2:23 PM, Joe Skora 
>> wrote:
>> > > >
>> > > > > Running Apache NiFi 0.7.1, we see clients rejected due to OCSP
>> > > revocation
>> > > > > of their certificates but we think we are seeing instances where
>> > > servers
>> > > > > using OCSP revoked certificates are still able to connect to a
>> > cluster.
>> > > > >
>> > > > > Should OCSP revocation cause these servers to be rejected by the
>> > > cluster?
>> > > > >
>> > > > > Could this be a configuration problem even though the revoked
>> clients
>> > > > > certificates are rejected?
>> > > > >
>> > > > > Thanks,
>> > > > > Joe
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

Re: [ANNOUNCE] New Apache NiFi Committer Jeremy Dyer

[Koji Kawamura]

Congratulations Jeremy!!

Koji

On Dec 20, 2016 9:26 PM, "Rob Moran"  wrote:

Thank you and congratulations Jeremy!

Rob

On Tue, Dec 20, 2016 at 7:14 AM, Joe Skora  wrote:

> Congrats Jeremy, welcome!
>
> On Tue, Dec 20, 2016 at 8:47 AM, Pierre Villard <
> pierre.villard...@gmail.com
> > wrote:
>
> > Congrats Jeremy, great to have you!
> >
> > 2016-12-20 6:18 GMT+01:00 Andrew Psaltis :
> >
> > > Congrats Jeremy!!
> > >
> > > On Mon, Dec 19, 2016 at 9:45 PM, Joe Witt  wrote:
> > >
> > > > Well done Jeremy and thanks for all your contributions!
> > > >
> > > > On Mon, Dec 19, 2016 at 9:24 PM, Joe Percivall
> > > >  wrote:
> > > > > Congrats Jeremy! Very well deserved.
> > > > >
> > > > >
> > > > > - - - - - - Joseph Percivalllinkedin.com/in/Percivalle:
> > > > joeperciv...@yahoo.com
> > > > >
> > > > >
> > > > > On Monday, December 19, 2016, 9:13:22 PM EST, Bryan Bende <
> > > > bbe...@gmail.com> wrote:Congrats and welcome!
> > > > >
> > > > > On Mon, Dec 19, 2016 at 8:52 PM Matt Burgess  >
> > > > wrote:
> > > > >
> > > > > Congratulations Jeremy and welcome! Very well deserved.
> > > > >
> > > > >
> > > > >
> > > > > Regards,
> > > > >
> > > > > Matt
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Dec 19, 2016 at 8:23 PM, Aldrin Piri 
> > > wrote:
> > > > >
> > > > >> On behalf of the Apache NiFI PMC, I am very pleased to announce
> that
> > > > > Jeremy
> > > > >
> > > > >> Dyer has accepted the PMC's invitation to become a committer on
> the
> > > > Apache
> > > > >
> > > > >> NiFi project. We greatly appreciate all of Jeremy's hard work and
> > > > generous
> > > > >
> > > > >> contributions and look forward to continued involvement in the
> > > project.
> > > > >
> > > > >>
> > > > >
> > > > >> Jeremy’s contributions include creation a suite of the processors
> > that
> > > > > aided
> > > > >
> > > > >> in parsing HTML, build improvement and testing for MiNiFi, as
well
> > as
> > > > many
> > > > >
> > > > >> articles and presentations on using NiFi in new and novel ways.
> > > > >
> > > > >>
> > > > >
> > > > >> Welcome Jeremy!
> > > > >
> > > > > --
> > > > > Sent from Gmail Mobile
> > > >
> > >
> > >
> > >
> > > --
> > > Thanks,
> > > Andrew
> > >
> > > Subscribe to my book: Streaming Data 
> > > 
> > > twiiter: @itmdata 
> > >
> >
>

Re: [ANNOUNCE] New Apache NiFi Committer Jeremy Dyer

[Rob Moran]

Thank you and congratulations Jeremy!

Rob

On Tue, Dec 20, 2016 at 7:14 AM, Joe Skora  wrote:

> Congrats Jeremy, welcome!
>
> On Tue, Dec 20, 2016 at 8:47 AM, Pierre Villard <
> pierre.villard...@gmail.com
> > wrote:
>
> > Congrats Jeremy, great to have you!
> >
> > 2016-12-20 6:18 GMT+01:00 Andrew Psaltis :
> >
> > > Congrats Jeremy!!
> > >
> > > On Mon, Dec 19, 2016 at 9:45 PM, Joe Witt  wrote:
> > >
> > > > Well done Jeremy and thanks for all your contributions!
> > > >
> > > > On Mon, Dec 19, 2016 at 9:24 PM, Joe Percivall
> > > >  wrote:
> > > > > Congrats Jeremy! Very well deserved.
> > > > >
> > > > >
> > > > > - - - - - - Joseph Percivalllinkedin.com/in/Percivalle:
> > > > joeperciv...@yahoo.com
> > > > >
> > > > >
> > > > > On Monday, December 19, 2016, 9:13:22 PM EST, Bryan Bende <
> > > > bbe...@gmail.com> wrote:Congrats and welcome!
> > > > >
> > > > > On Mon, Dec 19, 2016 at 8:52 PM Matt Burgess  >
> > > > wrote:
> > > > >
> > > > > Congratulations Jeremy and welcome! Very well deserved.
> > > > >
> > > > >
> > > > >
> > > > > Regards,
> > > > >
> > > > > Matt
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Dec 19, 2016 at 8:23 PM, Aldrin Piri 
> > > wrote:
> > > > >
> > > > >> On behalf of the Apache NiFI PMC, I am very pleased to announce
> that
> > > > > Jeremy
> > > > >
> > > > >> Dyer has accepted the PMC's invitation to become a committer on
> the
> > > > Apache
> > > > >
> > > > >> NiFi project. We greatly appreciate all of Jeremy's hard work and
> > > > generous
> > > > >
> > > > >> contributions and look forward to continued involvement in the
> > > project.
> > > > >
> > > > >>
> > > > >
> > > > >> Jeremy’s contributions include creation a suite of the processors
> > that
> > > > > aided
> > > > >
> > > > >> in parsing HTML, build improvement and testing for MiNiFi, as well
> > as
> > > > many
> > > > >
> > > > >> articles and presentations on using NiFi in new and novel ways.
> > > > >
> > > > >>
> > > > >
> > > > >> Welcome Jeremy!
> > > > >
> > > > > --
> > > > > Sent from Gmail Mobile
> > > >
> > >
> > >
> > >
> > > --
> > > Thanks,
> > > Andrew
> > >
> > > Subscribe to my book: Streaming Data 
> > > 
> > > twiiter: @itmdata 
> > >
> >
>

Re: [ANNOUNCE] New Apache NiFi Committer Jeremy Dyer

[Pierre Villard]

Congrats Jeremy, great to have you!

2016-12-20 6:18 GMT+01:00 Andrew Psaltis :

> Congrats Jeremy!!
>
> On Mon, Dec 19, 2016 at 9:45 PM, Joe Witt  wrote:
>
> > Well done Jeremy and thanks for all your contributions!
> >
> > On Mon, Dec 19, 2016 at 9:24 PM, Joe Percivall
> >  wrote:
> > > Congrats Jeremy! Very well deserved.
> > >
> > >
> > > - - - - - - Joseph Percivalllinkedin.com/in/Percivalle:
> > joeperciv...@yahoo.com
> > >
> > >
> > > On Monday, December 19, 2016, 9:13:22 PM EST, Bryan Bende <
> > bbe...@gmail.com> wrote:Congrats and welcome!
> > >
> > > On Mon, Dec 19, 2016 at 8:52 PM Matt Burgess 
> > wrote:
> > >
> > > Congratulations Jeremy and welcome! Very well deserved.
> > >
> > >
> > >
> > > Regards,
> > >
> > > Matt
> > >
> > >
> > >
> > > On Mon, Dec 19, 2016 at 8:23 PM, Aldrin Piri 
> wrote:
> > >
> > >> On behalf of the Apache NiFI PMC, I am very pleased to announce that
> > > Jeremy
> > >
> > >> Dyer has accepted the PMC's invitation to become a committer on the
> > Apache
> > >
> > >> NiFi project. We greatly appreciate all of Jeremy's hard work and
> > generous
> > >
> > >> contributions and look forward to continued involvement in the
> project.
> > >
> > >>
> > >
> > >> Jeremy’s contributions include creation a suite of the processors that
> > > aided
> > >
> > >> in parsing HTML, build improvement and testing for MiNiFi, as well as
> > many
> > >
> > >> articles and presentations on using NiFi in new and novel ways.
> > >
> > >>
> > >
> > >> Welcome Jeremy!
> > >
> > > --
> > > Sent from Gmail Mobile
> >
>
>
>
> --
> Thanks,
> Andrew
>
> Subscribe to my book: Streaming Data 
> 
> twiiter: @itmdata 
>