[jira] [Updated] (NIFI-2193) Command Line Keystore and Truststore utility

[Andy LoPresto (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy LoPresto updated NIFI-2193:

Resolution: Fixed
Status: Resolved  (was: Patch Available)

The initial PR for implementing this functionality is merged. I am closing this 
ticket, and follow-on work will occur against NIFI-2476. 

> Command Line Keystore and Truststore utility
> 
>
> Key: NIFI-2193
> URL: https://issues.apache.org/jira/browse/NIFI-2193
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
>  Labels: certificate, security, tls
> Fix For: 1.0.0
>
>
> In order to facilitate secure setup of NiFi, it would be useful to have a 
> command line utility capable of generating the required keystores, 
> truststore, and relevant configuration files.
> It should be able to generate keystores for each NiFi node, a truststore that 
> they all use, and relevant passwords and configuration files for using the 
> keystores and truststore.
> Additionally, in order to support distributed deployment, a web based 
> certificate authority with corresponding client will allow for each NiFi 
> instance to generate its own keypair and then request signing by the CA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2193) Command Line Keystore and Truststore utility

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407130#comment-15407130
 ] 

ASF subversion and git services commented on NIFI-2193:
---

Commit fa4c6ab03cae9dae98e41ac984901df90fdd1b2a in nifi's branch 
refs/heads/master from [~bryanrosan...@gmail.com]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=fa4c6ab ]

NIFI-2193 - Added functionality to automate certificate generation, keystore 
and truststore generation, and nifi.properties keystore and truststore password 
population. Follow-on changes will be made under NIFI-2476.

This closes #695.

Signed-off-by: Andy LoPresto 

Defaulting to same keyStore, key password (+18 squashed commits)
Squashed commits:
[9d01ba0] NIFI-2193 - Fixing typo
[55440bc] NIFI-2193 - Standalone can run as long as there are no conflicting 
files/folders
[0ca34ed] NIFI-2193 - Fixing some filename, absolute path issues
[9d4f65b] NIFI-2193 - Incorporating feedback
[f7550b4] NIFI-2193 - Cleaning up imports
[59a7637] NIFI-2193 - Updating umask to allow owner to execute
[cf824e7] NIFI-2193 - Moving DN arg to CA service specific parent class
[921ee13] NIFI-2193 - Making keystore getInstance more consistent
[a283c4b] NIFI-2193 - Updating sample config files in assembly to reflect new 
structure
[8d3a21d] NIFI-2193 - Making TlsHelper static, adding option to use same 
password for Key, KeyStore
[b13d247] NIFI-2193 - Addressing PR feedback
[46ef8ed] NIFI-2193 - Removing commons-logging, log4j from notice
[d4cf41a] NIFI-2193 - Adding option to specify output file for CA certificate 
when using cli client
[b74bf25] NIFI-2193 - Removing Bouncy Castle from notice
[6e34f9a] NIFI-2193 - Adding CLI client for easier generation of client 
certificates
[2924fca] NIFI-2193 - nifi-toolkit-ssl -> nifi-toolkit-tls, removing unused 
constants
[886167e] NIFI-2193 - Adding slf4j to avoid runtime issue
[082de46] NIFI-2193 - Command line SSL config utility as well as certificate 
authority client/server


> Command Line Keystore and Truststore utility
> 
>
> Key: NIFI-2193
> URL: https://issues.apache.org/jira/browse/NIFI-2193
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
>  Labels: certificate, security, tls
> Fix For: 1.0.0
>
>
> In order to facilitate secure setup of NiFi, it would be useful to have a 
> command line utility capable of generating the required keystores, 
> truststore, and relevant configuration files.
> It should be able to generate keystores for each NiFi node, a truststore that 
> they all use, and relevant passwords and configuration files for using the 
> keystores and truststore.
> Additionally, in order to support distributed deployment, a web based 
> certificate authority with corresponding client will allow for each NiFi 
> instance to generate its own keypair and then request signing by the CA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2193) Command Line Keystore and Truststore utility

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407132#comment-15407132
 ] 

ASF subversion and git services commented on NIFI-2193:
---

Commit fa4c6ab03cae9dae98e41ac984901df90fdd1b2a in nifi's branch 
refs/heads/master from [~bryanrosan...@gmail.com]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=fa4c6ab ]

NIFI-2193 - Added functionality to automate certificate generation, keystore 
and truststore generation, and nifi.properties keystore and truststore password 
population. Follow-on changes will be made under NIFI-2476.

This closes #695.

Signed-off-by: Andy LoPresto 

Defaulting to same keyStore, key password (+18 squashed commits)
Squashed commits:
[9d01ba0] NIFI-2193 - Fixing typo
[55440bc] NIFI-2193 - Standalone can run as long as there are no conflicting 
files/folders
[0ca34ed] NIFI-2193 - Fixing some filename, absolute path issues
[9d4f65b] NIFI-2193 - Incorporating feedback
[f7550b4] NIFI-2193 - Cleaning up imports
[59a7637] NIFI-2193 - Updating umask to allow owner to execute
[cf824e7] NIFI-2193 - Moving DN arg to CA service specific parent class
[921ee13] NIFI-2193 - Making keystore getInstance more consistent
[a283c4b] NIFI-2193 - Updating sample config files in assembly to reflect new 
structure
[8d3a21d] NIFI-2193 - Making TlsHelper static, adding option to use same 
password for Key, KeyStore
[b13d247] NIFI-2193 - Addressing PR feedback
[46ef8ed] NIFI-2193 - Removing commons-logging, log4j from notice
[d4cf41a] NIFI-2193 - Adding option to specify output file for CA certificate 
when using cli client
[b74bf25] NIFI-2193 - Removing Bouncy Castle from notice
[6e34f9a] NIFI-2193 - Adding CLI client for easier generation of client 
certificates
[2924fca] NIFI-2193 - nifi-toolkit-ssl -> nifi-toolkit-tls, removing unused 
constants
[886167e] NIFI-2193 - Adding slf4j to avoid runtime issue
[082de46] NIFI-2193 - Command line SSL config utility as well as certificate 
authority client/server


> Command Line Keystore and Truststore utility
> 
>
> Key: NIFI-2193
> URL: https://issues.apache.org/jira/browse/NIFI-2193
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
>  Labels: certificate, security, tls
> Fix For: 1.0.0
>
>
> In order to facilitate secure setup of NiFi, it would be useful to have a 
> command line utility capable of generating the required keystores, 
> truststore, and relevant configuration files.
> It should be able to generate keystores for each NiFi node, a truststore that 
> they all use, and relevant passwords and configuration files for using the 
> keystores and truststore.
> Additionally, in order to support distributed deployment, a web based 
> certificate authority with corresponding client will allow for each NiFi 
> instance to generate its own keypair and then request signing by the CA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2193) Command Line Keystore and Truststore utility

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407128#comment-15407128
 ] 

ASF subversion and git services commented on NIFI-2193:
---

Commit fa4c6ab03cae9dae98e41ac984901df90fdd1b2a in nifi's branch 
refs/heads/master from [~bryanrosan...@gmail.com]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=fa4c6ab ]

NIFI-2193 - Added functionality to automate certificate generation, keystore 
and truststore generation, and nifi.properties keystore and truststore password 
population. Follow-on changes will be made under NIFI-2476.

This closes #695.

Signed-off-by: Andy LoPresto 

Defaulting to same keyStore, key password (+18 squashed commits)
Squashed commits:
[9d01ba0] NIFI-2193 - Fixing typo
[55440bc] NIFI-2193 - Standalone can run as long as there are no conflicting 
files/folders
[0ca34ed] NIFI-2193 - Fixing some filename, absolute path issues
[9d4f65b] NIFI-2193 - Incorporating feedback
[f7550b4] NIFI-2193 - Cleaning up imports
[59a7637] NIFI-2193 - Updating umask to allow owner to execute
[cf824e7] NIFI-2193 - Moving DN arg to CA service specific parent class
[921ee13] NIFI-2193 - Making keystore getInstance more consistent
[a283c4b] NIFI-2193 - Updating sample config files in assembly to reflect new 
structure
[8d3a21d] NIFI-2193 - Making TlsHelper static, adding option to use same 
password for Key, KeyStore
[b13d247] NIFI-2193 - Addressing PR feedback
[46ef8ed] NIFI-2193 - Removing commons-logging, log4j from notice
[d4cf41a] NIFI-2193 - Adding option to specify output file for CA certificate 
when using cli client
[b74bf25] NIFI-2193 - Removing Bouncy Castle from notice
[6e34f9a] NIFI-2193 - Adding CLI client for easier generation of client 
certificates
[2924fca] NIFI-2193 - nifi-toolkit-ssl -> nifi-toolkit-tls, removing unused 
constants
[886167e] NIFI-2193 - Adding slf4j to avoid runtime issue
[082de46] NIFI-2193 - Command line SSL config utility as well as certificate 
authority client/server


> Command Line Keystore and Truststore utility
> 
>
> Key: NIFI-2193
> URL: https://issues.apache.org/jira/browse/NIFI-2193
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
>  Labels: certificate, security, tls
> Fix For: 1.0.0
>
>
> In order to facilitate secure setup of NiFi, it would be useful to have a 
> command line utility capable of generating the required keystores, 
> truststore, and relevant configuration files.
> It should be able to generate keystores for each NiFi node, a truststore that 
> they all use, and relevant passwords and configuration files for using the 
> keystores and truststore.
> Additionally, in order to support distributed deployment, a web based 
> certificate authority with corresponding client will allow for each NiFi 
> instance to generate its own keypair and then request signing by the CA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2193) Command Line Keystore and Truststore utility

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407139#comment-15407139
 ] 

ASF subversion and git services commented on NIFI-2193:
---

Commit fa4c6ab03cae9dae98e41ac984901df90fdd1b2a in nifi's branch 
refs/heads/master from [~bryanrosan...@gmail.com]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=fa4c6ab ]

NIFI-2193 - Added functionality to automate certificate generation, keystore 
and truststore generation, and nifi.properties keystore and truststore password 
population. Follow-on changes will be made under NIFI-2476.

This closes #695.

Signed-off-by: Andy LoPresto 

Defaulting to same keyStore, key password (+18 squashed commits)
Squashed commits:
[9d01ba0] NIFI-2193 - Fixing typo
[55440bc] NIFI-2193 - Standalone can run as long as there are no conflicting 
files/folders
[0ca34ed] NIFI-2193 - Fixing some filename, absolute path issues
[9d4f65b] NIFI-2193 - Incorporating feedback
[f7550b4] NIFI-2193 - Cleaning up imports
[59a7637] NIFI-2193 - Updating umask to allow owner to execute
[cf824e7] NIFI-2193 - Moving DN arg to CA service specific parent class
[921ee13] NIFI-2193 - Making keystore getInstance more consistent
[a283c4b] NIFI-2193 - Updating sample config files in assembly to reflect new 
structure
[8d3a21d] NIFI-2193 - Making TlsHelper static, adding option to use same 
password for Key, KeyStore
[b13d247] NIFI-2193 - Addressing PR feedback
[46ef8ed] NIFI-2193 - Removing commons-logging, log4j from notice
[d4cf41a] NIFI-2193 - Adding option to specify output file for CA certificate 
when using cli client
[b74bf25] NIFI-2193 - Removing Bouncy Castle from notice
[6e34f9a] NIFI-2193 - Adding CLI client for easier generation of client 
certificates
[2924fca] NIFI-2193 - nifi-toolkit-ssl -> nifi-toolkit-tls, removing unused 
constants
[886167e] NIFI-2193 - Adding slf4j to avoid runtime issue
[082de46] NIFI-2193 - Command line SSL config utility as well as certificate 
authority client/server


> Command Line Keystore and Truststore utility
> 
>
> Key: NIFI-2193
> URL: https://issues.apache.org/jira/browse/NIFI-2193
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
>  Labels: certificate, security, tls
> Fix For: 1.0.0
>
>
> In order to facilitate secure setup of NiFi, it would be useful to have a 
> command line utility capable of generating the required keystores, 
> truststore, and relevant configuration files.
> It should be able to generate keystores for each NiFi node, a truststore that 
> they all use, and relevant passwords and configuration files for using the 
> keystores and truststore.
> Additionally, in order to support distributed deployment, a web based 
> certificate authority with corresponding client will allow for each NiFi 
> instance to generate its own keypair and then request signing by the CA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2193) Command Line Keystore and Truststore utility

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407135#comment-15407135
 ] 

ASF subversion and git services commented on NIFI-2193:
---

Commit fa4c6ab03cae9dae98e41ac984901df90fdd1b2a in nifi's branch 
refs/heads/master from [~bryanrosan...@gmail.com]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=fa4c6ab ]

NIFI-2193 - Added functionality to automate certificate generation, keystore 
and truststore generation, and nifi.properties keystore and truststore password 
population. Follow-on changes will be made under NIFI-2476.

This closes #695.

Signed-off-by: Andy LoPresto 

Defaulting to same keyStore, key password (+18 squashed commits)
Squashed commits:
[9d01ba0] NIFI-2193 - Fixing typo
[55440bc] NIFI-2193 - Standalone can run as long as there are no conflicting 
files/folders
[0ca34ed] NIFI-2193 - Fixing some filename, absolute path issues
[9d4f65b] NIFI-2193 - Incorporating feedback
[f7550b4] NIFI-2193 - Cleaning up imports
[59a7637] NIFI-2193 - Updating umask to allow owner to execute
[cf824e7] NIFI-2193 - Moving DN arg to CA service specific parent class
[921ee13] NIFI-2193 - Making keystore getInstance more consistent
[a283c4b] NIFI-2193 - Updating sample config files in assembly to reflect new 
structure
[8d3a21d] NIFI-2193 - Making TlsHelper static, adding option to use same 
password for Key, KeyStore
[b13d247] NIFI-2193 - Addressing PR feedback
[46ef8ed] NIFI-2193 - Removing commons-logging, log4j from notice
[d4cf41a] NIFI-2193 - Adding option to specify output file for CA certificate 
when using cli client
[b74bf25] NIFI-2193 - Removing Bouncy Castle from notice
[6e34f9a] NIFI-2193 - Adding CLI client for easier generation of client 
certificates
[2924fca] NIFI-2193 - nifi-toolkit-ssl -> nifi-toolkit-tls, removing unused 
constants
[886167e] NIFI-2193 - Adding slf4j to avoid runtime issue
[082de46] NIFI-2193 - Command line SSL config utility as well as certificate 
authority client/server


> Command Line Keystore and Truststore utility
> 
>
> Key: NIFI-2193
> URL: https://issues.apache.org/jira/browse/NIFI-2193
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
>  Labels: certificate, security, tls
> Fix For: 1.0.0
>
>
> In order to facilitate secure setup of NiFi, it would be useful to have a 
> command line utility capable of generating the required keystores, 
> truststore, and relevant configuration files.
> It should be able to generate keystores for each NiFi node, a truststore that 
> they all use, and relevant passwords and configuration files for using the 
> keystores and truststore.
> Additionally, in order to support distributed deployment, a web based 
> certificate authority with corresponding client will allow for each NiFi 
> instance to generate its own keypair and then request signing by the CA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2476) Further refine tls-toolkit based on feedback gathered during beta

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407123#comment-15407123
 ] 

ASF subversion and git services commented on NIFI-2476:
---

Commit fa4c6ab03cae9dae98e41ac984901df90fdd1b2a in nifi's branch 
refs/heads/master from [~bryanrosan...@gmail.com]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=fa4c6ab ]

NIFI-2193 - Added functionality to automate certificate generation, keystore 
and truststore generation, and nifi.properties keystore and truststore password 
population. Follow-on changes will be made under NIFI-2476.

This closes #695.

Signed-off-by: Andy LoPresto 

Defaulting to same keyStore, key password (+18 squashed commits)
Squashed commits:
[9d01ba0] NIFI-2193 - Fixing typo
[55440bc] NIFI-2193 - Standalone can run as long as there are no conflicting 
files/folders
[0ca34ed] NIFI-2193 - Fixing some filename, absolute path issues
[9d4f65b] NIFI-2193 - Incorporating feedback
[f7550b4] NIFI-2193 - Cleaning up imports
[59a7637] NIFI-2193 - Updating umask to allow owner to execute
[cf824e7] NIFI-2193 - Moving DN arg to CA service specific parent class
[921ee13] NIFI-2193 - Making keystore getInstance more consistent
[a283c4b] NIFI-2193 - Updating sample config files in assembly to reflect new 
structure
[8d3a21d] NIFI-2193 - Making TlsHelper static, adding option to use same 
password for Key, KeyStore
[b13d247] NIFI-2193 - Addressing PR feedback
[46ef8ed] NIFI-2193 - Removing commons-logging, log4j from notice
[d4cf41a] NIFI-2193 - Adding option to specify output file for CA certificate 
when using cli client
[b74bf25] NIFI-2193 - Removing Bouncy Castle from notice
[6e34f9a] NIFI-2193 - Adding CLI client for easier generation of client 
certificates
[2924fca] NIFI-2193 - nifi-toolkit-ssl -> nifi-toolkit-tls, removing unused 
constants
[886167e] NIFI-2193 - Adding slf4j to avoid runtime issue
[082de46] NIFI-2193 - Command line SSL config utility as well as certificate 
authority client/server


> Further refine tls-toolkit based on feedback gathered during beta
> -
>
> Key: NIFI-2476
> URL: https://issues.apache.org/jira/browse/NIFI-2476
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Rosander
>
> The basic functionality of generating keystores, truststores, 
> nifi.properties, and a configuration json is implemented.
> As people start using this tool to ease the tls setup process in NiFi, 
> shortcomings in the initial implementation will need to be addressed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2193) Command Line Keystore and Truststore utility

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407137#comment-15407137
 ] 

ASF subversion and git services commented on NIFI-2193:
---

Commit fa4c6ab03cae9dae98e41ac984901df90fdd1b2a in nifi's branch 
refs/heads/master from [~bryanrosan...@gmail.com]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=fa4c6ab ]

NIFI-2193 - Added functionality to automate certificate generation, keystore 
and truststore generation, and nifi.properties keystore and truststore password 
population. Follow-on changes will be made under NIFI-2476.

This closes #695.

Signed-off-by: Andy LoPresto 

Defaulting to same keyStore, key password (+18 squashed commits)
Squashed commits:
[9d01ba0] NIFI-2193 - Fixing typo
[55440bc] NIFI-2193 - Standalone can run as long as there are no conflicting 
files/folders
[0ca34ed] NIFI-2193 - Fixing some filename, absolute path issues
[9d4f65b] NIFI-2193 - Incorporating feedback
[f7550b4] NIFI-2193 - Cleaning up imports
[59a7637] NIFI-2193 - Updating umask to allow owner to execute
[cf824e7] NIFI-2193 - Moving DN arg to CA service specific parent class
[921ee13] NIFI-2193 - Making keystore getInstance more consistent
[a283c4b] NIFI-2193 - Updating sample config files in assembly to reflect new 
structure
[8d3a21d] NIFI-2193 - Making TlsHelper static, adding option to use same 
password for Key, KeyStore
[b13d247] NIFI-2193 - Addressing PR feedback
[46ef8ed] NIFI-2193 - Removing commons-logging, log4j from notice
[d4cf41a] NIFI-2193 - Adding option to specify output file for CA certificate 
when using cli client
[b74bf25] NIFI-2193 - Removing Bouncy Castle from notice
[6e34f9a] NIFI-2193 - Adding CLI client for easier generation of client 
certificates
[2924fca] NIFI-2193 - nifi-toolkit-ssl -> nifi-toolkit-tls, removing unused 
constants
[886167e] NIFI-2193 - Adding slf4j to avoid runtime issue
[082de46] NIFI-2193 - Command line SSL config utility as well as certificate 
authority client/server


> Command Line Keystore and Truststore utility
> 
>
> Key: NIFI-2193
> URL: https://issues.apache.org/jira/browse/NIFI-2193
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
>  Labels: certificate, security, tls
> Fix For: 1.0.0
>
>
> In order to facilitate secure setup of NiFi, it would be useful to have a 
> command line utility capable of generating the required keystores, 
> truststore, and relevant configuration files.
> It should be able to generate keystores for each NiFi node, a truststore that 
> they all use, and relevant passwords and configuration files for using the 
> keystores and truststore.
> Additionally, in order to support distributed deployment, a web based 
> certificate authority with corresponding client will allow for each NiFi 
> instance to generate its own keypair and then request signing by the CA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2193) Command Line Keystore and Truststore utility

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407125#comment-15407125
 ] 

ASF subversion and git services commented on NIFI-2193:
---

Commit fa4c6ab03cae9dae98e41ac984901df90fdd1b2a in nifi's branch 
refs/heads/master from [~bryanrosan...@gmail.com]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=fa4c6ab ]

NIFI-2193 - Added functionality to automate certificate generation, keystore 
and truststore generation, and nifi.properties keystore and truststore password 
population. Follow-on changes will be made under NIFI-2476.

This closes #695.

Signed-off-by: Andy LoPresto 

Defaulting to same keyStore, key password (+18 squashed commits)
Squashed commits:
[9d01ba0] NIFI-2193 - Fixing typo
[55440bc] NIFI-2193 - Standalone can run as long as there are no conflicting 
files/folders
[0ca34ed] NIFI-2193 - Fixing some filename, absolute path issues
[9d4f65b] NIFI-2193 - Incorporating feedback
[f7550b4] NIFI-2193 - Cleaning up imports
[59a7637] NIFI-2193 - Updating umask to allow owner to execute
[cf824e7] NIFI-2193 - Moving DN arg to CA service specific parent class
[921ee13] NIFI-2193 - Making keystore getInstance more consistent
[a283c4b] NIFI-2193 - Updating sample config files in assembly to reflect new 
structure
[8d3a21d] NIFI-2193 - Making TlsHelper static, adding option to use same 
password for Key, KeyStore
[b13d247] NIFI-2193 - Addressing PR feedback
[46ef8ed] NIFI-2193 - Removing commons-logging, log4j from notice
[d4cf41a] NIFI-2193 - Adding option to specify output file for CA certificate 
when using cli client
[b74bf25] NIFI-2193 - Removing Bouncy Castle from notice
[6e34f9a] NIFI-2193 - Adding CLI client for easier generation of client 
certificates
[2924fca] NIFI-2193 - nifi-toolkit-ssl -> nifi-toolkit-tls, removing unused 
constants
[886167e] NIFI-2193 - Adding slf4j to avoid runtime issue
[082de46] NIFI-2193 - Command line SSL config utility as well as certificate 
authority client/server


> Command Line Keystore and Truststore utility
> 
>
> Key: NIFI-2193
> URL: https://issues.apache.org/jira/browse/NIFI-2193
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
>  Labels: certificate, security, tls
> Fix For: 1.0.0
>
>
> In order to facilitate secure setup of NiFi, it would be useful to have a 
> command line utility capable of generating the required keystores, 
> truststore, and relevant configuration files.
> It should be able to generate keystores for each NiFi node, a truststore that 
> they all use, and relevant passwords and configuration files for using the 
> keystores and truststore.
> Additionally, in order to support distributed deployment, a web based 
> certificate authority with corresponding client will allow for each NiFi 
> instance to generate its own keypair and then request signing by the CA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2193) Command Line Keystore and Truststore utility

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407129#comment-15407129
 ] 

ASF subversion and git services commented on NIFI-2193:
---

Commit fa4c6ab03cae9dae98e41ac984901df90fdd1b2a in nifi's branch 
refs/heads/master from [~bryanrosan...@gmail.com]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=fa4c6ab ]

NIFI-2193 - Added functionality to automate certificate generation, keystore 
and truststore generation, and nifi.properties keystore and truststore password 
population. Follow-on changes will be made under NIFI-2476.

This closes #695.

Signed-off-by: Andy LoPresto 

Defaulting to same keyStore, key password (+18 squashed commits)
Squashed commits:
[9d01ba0] NIFI-2193 - Fixing typo
[55440bc] NIFI-2193 - Standalone can run as long as there are no conflicting 
files/folders
[0ca34ed] NIFI-2193 - Fixing some filename, absolute path issues
[9d4f65b] NIFI-2193 - Incorporating feedback
[f7550b4] NIFI-2193 - Cleaning up imports
[59a7637] NIFI-2193 - Updating umask to allow owner to execute
[cf824e7] NIFI-2193 - Moving DN arg to CA service specific parent class
[921ee13] NIFI-2193 - Making keystore getInstance more consistent
[a283c4b] NIFI-2193 - Updating sample config files in assembly to reflect new 
structure
[8d3a21d] NIFI-2193 - Making TlsHelper static, adding option to use same 
password for Key, KeyStore
[b13d247] NIFI-2193 - Addressing PR feedback
[46ef8ed] NIFI-2193 - Removing commons-logging, log4j from notice
[d4cf41a] NIFI-2193 - Adding option to specify output file for CA certificate 
when using cli client
[b74bf25] NIFI-2193 - Removing Bouncy Castle from notice
[6e34f9a] NIFI-2193 - Adding CLI client for easier generation of client 
certificates
[2924fca] NIFI-2193 - nifi-toolkit-ssl -> nifi-toolkit-tls, removing unused 
constants
[886167e] NIFI-2193 - Adding slf4j to avoid runtime issue
[082de46] NIFI-2193 - Command line SSL config utility as well as certificate 
authority client/server


> Command Line Keystore and Truststore utility
> 
>
> Key: NIFI-2193
> URL: https://issues.apache.org/jira/browse/NIFI-2193
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
>  Labels: certificate, security, tls
> Fix For: 1.0.0
>
>
> In order to facilitate secure setup of NiFi, it would be useful to have a 
> command line utility capable of generating the required keystores, 
> truststore, and relevant configuration files.
> It should be able to generate keystores for each NiFi node, a truststore that 
> they all use, and relevant passwords and configuration files for using the 
> keystores and truststore.
> Additionally, in order to support distributed deployment, a web based 
> certificate authority with corresponding client will allow for each NiFi 
> instance to generate its own keypair and then request signing by the CA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2193) Command Line Keystore and Truststore utility

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407136#comment-15407136
 ] 

ASF subversion and git services commented on NIFI-2193:
---

Commit fa4c6ab03cae9dae98e41ac984901df90fdd1b2a in nifi's branch 
refs/heads/master from [~bryanrosan...@gmail.com]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=fa4c6ab ]

NIFI-2193 - Added functionality to automate certificate generation, keystore 
and truststore generation, and nifi.properties keystore and truststore password 
population. Follow-on changes will be made under NIFI-2476.

This closes #695.

Signed-off-by: Andy LoPresto 

Defaulting to same keyStore, key password (+18 squashed commits)
Squashed commits:
[9d01ba0] NIFI-2193 - Fixing typo
[55440bc] NIFI-2193 - Standalone can run as long as there are no conflicting 
files/folders
[0ca34ed] NIFI-2193 - Fixing some filename, absolute path issues
[9d4f65b] NIFI-2193 - Incorporating feedback
[f7550b4] NIFI-2193 - Cleaning up imports
[59a7637] NIFI-2193 - Updating umask to allow owner to execute
[cf824e7] NIFI-2193 - Moving DN arg to CA service specific parent class
[921ee13] NIFI-2193 - Making keystore getInstance more consistent
[a283c4b] NIFI-2193 - Updating sample config files in assembly to reflect new 
structure
[8d3a21d] NIFI-2193 - Making TlsHelper static, adding option to use same 
password for Key, KeyStore
[b13d247] NIFI-2193 - Addressing PR feedback
[46ef8ed] NIFI-2193 - Removing commons-logging, log4j from notice
[d4cf41a] NIFI-2193 - Adding option to specify output file for CA certificate 
when using cli client
[b74bf25] NIFI-2193 - Removing Bouncy Castle from notice
[6e34f9a] NIFI-2193 - Adding CLI client for easier generation of client 
certificates
[2924fca] NIFI-2193 - nifi-toolkit-ssl -> nifi-toolkit-tls, removing unused 
constants
[886167e] NIFI-2193 - Adding slf4j to avoid runtime issue
[082de46] NIFI-2193 - Command line SSL config utility as well as certificate 
authority client/server


> Command Line Keystore and Truststore utility
> 
>
> Key: NIFI-2193
> URL: https://issues.apache.org/jira/browse/NIFI-2193
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
>  Labels: certificate, security, tls
> Fix For: 1.0.0
>
>
> In order to facilitate secure setup of NiFi, it would be useful to have a 
> command line utility capable of generating the required keystores, 
> truststore, and relevant configuration files.
> It should be able to generate keystores for each NiFi node, a truststore that 
> they all use, and relevant passwords and configuration files for using the 
> keystores and truststore.
> Additionally, in order to support distributed deployment, a web based 
> certificate authority with corresponding client will allow for each NiFi 
> instance to generate its own keypair and then request signing by the CA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #695: NIFI-2193 - Command line SSL config utility as well ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/695


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2193) Command Line Keystore and Truststore utility

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407138#comment-15407138
 ] 

ASF GitHub Bot commented on NIFI-2193:
--

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/695


> Command Line Keystore and Truststore utility
> 
>
> Key: NIFI-2193
> URL: https://issues.apache.org/jira/browse/NIFI-2193
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
>  Labels: certificate, security, tls
> Fix For: 1.0.0
>
>
> In order to facilitate secure setup of NiFi, it would be useful to have a 
> command line utility capable of generating the required keystores, 
> truststore, and relevant configuration files.
> It should be able to generate keystores for each NiFi node, a truststore that 
> they all use, and relevant passwords and configuration files for using the 
> keystores and truststore.
> Additionally, in order to support distributed deployment, a web based 
> certificate authority with corresponding client will allow for each NiFi 
> instance to generate its own keypair and then request signing by the CA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2193) Command Line Keystore and Truststore utility

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407131#comment-15407131
 ] 

ASF subversion and git services commented on NIFI-2193:
---

Commit fa4c6ab03cae9dae98e41ac984901df90fdd1b2a in nifi's branch 
refs/heads/master from [~bryanrosan...@gmail.com]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=fa4c6ab ]

NIFI-2193 - Added functionality to automate certificate generation, keystore 
and truststore generation, and nifi.properties keystore and truststore password 
population. Follow-on changes will be made under NIFI-2476.

This closes #695.

Signed-off-by: Andy LoPresto 

Defaulting to same keyStore, key password (+18 squashed commits)
Squashed commits:
[9d01ba0] NIFI-2193 - Fixing typo
[55440bc] NIFI-2193 - Standalone can run as long as there are no conflicting 
files/folders
[0ca34ed] NIFI-2193 - Fixing some filename, absolute path issues
[9d4f65b] NIFI-2193 - Incorporating feedback
[f7550b4] NIFI-2193 - Cleaning up imports
[59a7637] NIFI-2193 - Updating umask to allow owner to execute
[cf824e7] NIFI-2193 - Moving DN arg to CA service specific parent class
[921ee13] NIFI-2193 - Making keystore getInstance more consistent
[a283c4b] NIFI-2193 - Updating sample config files in assembly to reflect new 
structure
[8d3a21d] NIFI-2193 - Making TlsHelper static, adding option to use same 
password for Key, KeyStore
[b13d247] NIFI-2193 - Addressing PR feedback
[46ef8ed] NIFI-2193 - Removing commons-logging, log4j from notice
[d4cf41a] NIFI-2193 - Adding option to specify output file for CA certificate 
when using cli client
[b74bf25] NIFI-2193 - Removing Bouncy Castle from notice
[6e34f9a] NIFI-2193 - Adding CLI client for easier generation of client 
certificates
[2924fca] NIFI-2193 - nifi-toolkit-ssl -> nifi-toolkit-tls, removing unused 
constants
[886167e] NIFI-2193 - Adding slf4j to avoid runtime issue
[082de46] NIFI-2193 - Command line SSL config utility as well as certificate 
authority client/server


> Command Line Keystore and Truststore utility
> 
>
> Key: NIFI-2193
> URL: https://issues.apache.org/jira/browse/NIFI-2193
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
>  Labels: certificate, security, tls
> Fix For: 1.0.0
>
>
> In order to facilitate secure setup of NiFi, it would be useful to have a 
> command line utility capable of generating the required keystores, 
> truststore, and relevant configuration files.
> It should be able to generate keystores for each NiFi node, a truststore that 
> they all use, and relevant passwords and configuration files for using the 
> keystores and truststore.
> Additionally, in order to support distributed deployment, a web based 
> certificate authority with corresponding client will allow for each NiFi 
> instance to generate its own keypair and then request signing by the CA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2193) Command Line Keystore and Truststore utility

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407133#comment-15407133
 ] 

ASF subversion and git services commented on NIFI-2193:
---

Commit fa4c6ab03cae9dae98e41ac984901df90fdd1b2a in nifi's branch 
refs/heads/master from [~bryanrosan...@gmail.com]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=fa4c6ab ]

NIFI-2193 - Added functionality to automate certificate generation, keystore 
and truststore generation, and nifi.properties keystore and truststore password 
population. Follow-on changes will be made under NIFI-2476.

This closes #695.

Signed-off-by: Andy LoPresto 

Defaulting to same keyStore, key password (+18 squashed commits)
Squashed commits:
[9d01ba0] NIFI-2193 - Fixing typo
[55440bc] NIFI-2193 - Standalone can run as long as there are no conflicting 
files/folders
[0ca34ed] NIFI-2193 - Fixing some filename, absolute path issues
[9d4f65b] NIFI-2193 - Incorporating feedback
[f7550b4] NIFI-2193 - Cleaning up imports
[59a7637] NIFI-2193 - Updating umask to allow owner to execute
[cf824e7] NIFI-2193 - Moving DN arg to CA service specific parent class
[921ee13] NIFI-2193 - Making keystore getInstance more consistent
[a283c4b] NIFI-2193 - Updating sample config files in assembly to reflect new 
structure
[8d3a21d] NIFI-2193 - Making TlsHelper static, adding option to use same 
password for Key, KeyStore
[b13d247] NIFI-2193 - Addressing PR feedback
[46ef8ed] NIFI-2193 - Removing commons-logging, log4j from notice
[d4cf41a] NIFI-2193 - Adding option to specify output file for CA certificate 
when using cli client
[b74bf25] NIFI-2193 - Removing Bouncy Castle from notice
[6e34f9a] NIFI-2193 - Adding CLI client for easier generation of client 
certificates
[2924fca] NIFI-2193 - nifi-toolkit-ssl -> nifi-toolkit-tls, removing unused 
constants
[886167e] NIFI-2193 - Adding slf4j to avoid runtime issue
[082de46] NIFI-2193 - Command line SSL config utility as well as certificate 
authority client/server


> Command Line Keystore and Truststore utility
> 
>
> Key: NIFI-2193
> URL: https://issues.apache.org/jira/browse/NIFI-2193
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
>  Labels: certificate, security, tls
> Fix For: 1.0.0
>
>
> In order to facilitate secure setup of NiFi, it would be useful to have a 
> command line utility capable of generating the required keystores, 
> truststore, and relevant configuration files.
> It should be able to generate keystores for each NiFi node, a truststore that 
> they all use, and relevant passwords and configuration files for using the 
> keystores and truststore.
> Additionally, in order to support distributed deployment, a web based 
> certificate authority with corresponding client will allow for each NiFi 
> instance to generate its own keypair and then request signing by the CA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2193) Command Line Keystore and Truststore utility

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407124#comment-15407124
 ] 

ASF subversion and git services commented on NIFI-2193:
---

Commit fa4c6ab03cae9dae98e41ac984901df90fdd1b2a in nifi's branch 
refs/heads/master from [~bryanrosan...@gmail.com]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=fa4c6ab ]

NIFI-2193 - Added functionality to automate certificate generation, keystore 
and truststore generation, and nifi.properties keystore and truststore password 
population. Follow-on changes will be made under NIFI-2476.

This closes #695.

Signed-off-by: Andy LoPresto 

Defaulting to same keyStore, key password (+18 squashed commits)
Squashed commits:
[9d01ba0] NIFI-2193 - Fixing typo
[55440bc] NIFI-2193 - Standalone can run as long as there are no conflicting 
files/folders
[0ca34ed] NIFI-2193 - Fixing some filename, absolute path issues
[9d4f65b] NIFI-2193 - Incorporating feedback
[f7550b4] NIFI-2193 - Cleaning up imports
[59a7637] NIFI-2193 - Updating umask to allow owner to execute
[cf824e7] NIFI-2193 - Moving DN arg to CA service specific parent class
[921ee13] NIFI-2193 - Making keystore getInstance more consistent
[a283c4b] NIFI-2193 - Updating sample config files in assembly to reflect new 
structure
[8d3a21d] NIFI-2193 - Making TlsHelper static, adding option to use same 
password for Key, KeyStore
[b13d247] NIFI-2193 - Addressing PR feedback
[46ef8ed] NIFI-2193 - Removing commons-logging, log4j from notice
[d4cf41a] NIFI-2193 - Adding option to specify output file for CA certificate 
when using cli client
[b74bf25] NIFI-2193 - Removing Bouncy Castle from notice
[6e34f9a] NIFI-2193 - Adding CLI client for easier generation of client 
certificates
[2924fca] NIFI-2193 - nifi-toolkit-ssl -> nifi-toolkit-tls, removing unused 
constants
[886167e] NIFI-2193 - Adding slf4j to avoid runtime issue
[082de46] NIFI-2193 - Command line SSL config utility as well as certificate 
authority client/server


> Command Line Keystore and Truststore utility
> 
>
> Key: NIFI-2193
> URL: https://issues.apache.org/jira/browse/NIFI-2193
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
>  Labels: certificate, security, tls
> Fix For: 1.0.0
>
>
> In order to facilitate secure setup of NiFi, it would be useful to have a 
> command line utility capable of generating the required keystores, 
> truststore, and relevant configuration files.
> It should be able to generate keystores for each NiFi node, a truststore that 
> they all use, and relevant passwords and configuration files for using the 
> keystores and truststore.
> Additionally, in order to support distributed deployment, a web based 
> certificate authority with corresponding client will allow for each NiFi 
> instance to generate its own keypair and then request signing by the CA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2193) Command Line Keystore and Truststore utility

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407142#comment-15407142
 ] 

ASF subversion and git services commented on NIFI-2193:
---

Commit fa4c6ab03cae9dae98e41ac984901df90fdd1b2a in nifi's branch 
refs/heads/master from [~bryanrosan...@gmail.com]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=fa4c6ab ]

NIFI-2193 - Added functionality to automate certificate generation, keystore 
and truststore generation, and nifi.properties keystore and truststore password 
population. Follow-on changes will be made under NIFI-2476.

This closes #695.

Signed-off-by: Andy LoPresto 

Defaulting to same keyStore, key password (+18 squashed commits)
Squashed commits:
[9d01ba0] NIFI-2193 - Fixing typo
[55440bc] NIFI-2193 - Standalone can run as long as there are no conflicting 
files/folders
[0ca34ed] NIFI-2193 - Fixing some filename, absolute path issues
[9d4f65b] NIFI-2193 - Incorporating feedback
[f7550b4] NIFI-2193 - Cleaning up imports
[59a7637] NIFI-2193 - Updating umask to allow owner to execute
[cf824e7] NIFI-2193 - Moving DN arg to CA service specific parent class
[921ee13] NIFI-2193 - Making keystore getInstance more consistent
[a283c4b] NIFI-2193 - Updating sample config files in assembly to reflect new 
structure
[8d3a21d] NIFI-2193 - Making TlsHelper static, adding option to use same 
password for Key, KeyStore
[b13d247] NIFI-2193 - Addressing PR feedback
[46ef8ed] NIFI-2193 - Removing commons-logging, log4j from notice
[d4cf41a] NIFI-2193 - Adding option to specify output file for CA certificate 
when using cli client
[b74bf25] NIFI-2193 - Removing Bouncy Castle from notice
[6e34f9a] NIFI-2193 - Adding CLI client for easier generation of client 
certificates
[2924fca] NIFI-2193 - nifi-toolkit-ssl -> nifi-toolkit-tls, removing unused 
constants
[886167e] NIFI-2193 - Adding slf4j to avoid runtime issue
[082de46] NIFI-2193 - Command line SSL config utility as well as certificate 
authority client/server


> Command Line Keystore and Truststore utility
> 
>
> Key: NIFI-2193
> URL: https://issues.apache.org/jira/browse/NIFI-2193
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
>  Labels: certificate, security, tls
> Fix For: 1.0.0
>
>
> In order to facilitate secure setup of NiFi, it would be useful to have a 
> command line utility capable of generating the required keystores, 
> truststore, and relevant configuration files.
> It should be able to generate keystores for each NiFi node, a truststore that 
> they all use, and relevant passwords and configuration files for using the 
> keystores and truststore.
> Additionally, in order to support distributed deployment, a web based 
> certificate authority with corresponding client will allow for each NiFi 
> instance to generate its own keypair and then request signing by the CA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2193) Command Line Keystore and Truststore utility

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407122#comment-15407122
 ] 

ASF subversion and git services commented on NIFI-2193:
---

Commit fa4c6ab03cae9dae98e41ac984901df90fdd1b2a in nifi's branch 
refs/heads/master from [~bryanrosan...@gmail.com]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=fa4c6ab ]

NIFI-2193 - Added functionality to automate certificate generation, keystore 
and truststore generation, and nifi.properties keystore and truststore password 
population. Follow-on changes will be made under NIFI-2476.

This closes #695.

Signed-off-by: Andy LoPresto 

Defaulting to same keyStore, key password (+18 squashed commits)
Squashed commits:
[9d01ba0] NIFI-2193 - Fixing typo
[55440bc] NIFI-2193 - Standalone can run as long as there are no conflicting 
files/folders
[0ca34ed] NIFI-2193 - Fixing some filename, absolute path issues
[9d4f65b] NIFI-2193 - Incorporating feedback
[f7550b4] NIFI-2193 - Cleaning up imports
[59a7637] NIFI-2193 - Updating umask to allow owner to execute
[cf824e7] NIFI-2193 - Moving DN arg to CA service specific parent class
[921ee13] NIFI-2193 - Making keystore getInstance more consistent
[a283c4b] NIFI-2193 - Updating sample config files in assembly to reflect new 
structure
[8d3a21d] NIFI-2193 - Making TlsHelper static, adding option to use same 
password for Key, KeyStore
[b13d247] NIFI-2193 - Addressing PR feedback
[46ef8ed] NIFI-2193 - Removing commons-logging, log4j from notice
[d4cf41a] NIFI-2193 - Adding option to specify output file for CA certificate 
when using cli client
[b74bf25] NIFI-2193 - Removing Bouncy Castle from notice
[6e34f9a] NIFI-2193 - Adding CLI client for easier generation of client 
certificates
[2924fca] NIFI-2193 - nifi-toolkit-ssl -> nifi-toolkit-tls, removing unused 
constants
[886167e] NIFI-2193 - Adding slf4j to avoid runtime issue
[082de46] NIFI-2193 - Command line SSL config utility as well as certificate 
authority client/server


> Command Line Keystore and Truststore utility
> 
>
> Key: NIFI-2193
> URL: https://issues.apache.org/jira/browse/NIFI-2193
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
>  Labels: certificate, security, tls
> Fix For: 1.0.0
>
>
> In order to facilitate secure setup of NiFi, it would be useful to have a 
> command line utility capable of generating the required keystores, 
> truststore, and relevant configuration files.
> It should be able to generate keystores for each NiFi node, a truststore that 
> they all use, and relevant passwords and configuration files for using the 
> keystores and truststore.
> Additionally, in order to support distributed deployment, a web based 
> certificate authority with corresponding client will allow for each NiFi 
> instance to generate its own keypair and then request signing by the CA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2193) Command Line Keystore and Truststore utility

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407127#comment-15407127
 ] 

ASF subversion and git services commented on NIFI-2193:
---

Commit fa4c6ab03cae9dae98e41ac984901df90fdd1b2a in nifi's branch 
refs/heads/master from [~bryanrosan...@gmail.com]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=fa4c6ab ]

NIFI-2193 - Added functionality to automate certificate generation, keystore 
and truststore generation, and nifi.properties keystore and truststore password 
population. Follow-on changes will be made under NIFI-2476.

This closes #695.

Signed-off-by: Andy LoPresto 

Defaulting to same keyStore, key password (+18 squashed commits)
Squashed commits:
[9d01ba0] NIFI-2193 - Fixing typo
[55440bc] NIFI-2193 - Standalone can run as long as there are no conflicting 
files/folders
[0ca34ed] NIFI-2193 - Fixing some filename, absolute path issues
[9d4f65b] NIFI-2193 - Incorporating feedback
[f7550b4] NIFI-2193 - Cleaning up imports
[59a7637] NIFI-2193 - Updating umask to allow owner to execute
[cf824e7] NIFI-2193 - Moving DN arg to CA service specific parent class
[921ee13] NIFI-2193 - Making keystore getInstance more consistent
[a283c4b] NIFI-2193 - Updating sample config files in assembly to reflect new 
structure
[8d3a21d] NIFI-2193 - Making TlsHelper static, adding option to use same 
password for Key, KeyStore
[b13d247] NIFI-2193 - Addressing PR feedback
[46ef8ed] NIFI-2193 - Removing commons-logging, log4j from notice
[d4cf41a] NIFI-2193 - Adding option to specify output file for CA certificate 
when using cli client
[b74bf25] NIFI-2193 - Removing Bouncy Castle from notice
[6e34f9a] NIFI-2193 - Adding CLI client for easier generation of client 
certificates
[2924fca] NIFI-2193 - nifi-toolkit-ssl -> nifi-toolkit-tls, removing unused 
constants
[886167e] NIFI-2193 - Adding slf4j to avoid runtime issue
[082de46] NIFI-2193 - Command line SSL config utility as well as certificate 
authority client/server


> Command Line Keystore and Truststore utility
> 
>
> Key: NIFI-2193
> URL: https://issues.apache.org/jira/browse/NIFI-2193
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
>  Labels: certificate, security, tls
> Fix For: 1.0.0
>
>
> In order to facilitate secure setup of NiFi, it would be useful to have a 
> command line utility capable of generating the required keystores, 
> truststore, and relevant configuration files.
> It should be able to generate keystores for each NiFi node, a truststore that 
> they all use, and relevant passwords and configuration files for using the 
> keystores and truststore.
> Additionally, in order to support distributed deployment, a web based 
> certificate authority with corresponding client will allow for each NiFi 
> instance to generate its own keypair and then request signing by the CA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2193) Command Line Keystore and Truststore utility

[Andy LoPresto (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy LoPresto updated NIFI-2193:

   Labels: certificate security tls  (was: )
Fix Version/s: 1.0.0
   Status: Patch Available  (was: Open)

> Command Line Keystore and Truststore utility
> 
>
> Key: NIFI-2193
> URL: https://issues.apache.org/jira/browse/NIFI-2193
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
>  Labels: security, certificate, tls
> Fix For: 1.0.0
>
>
> In order to facilitate secure setup of NiFi, it would be useful to have a 
> command line utility capable of generating the required keystores, 
> truststore, and relevant configuration files.
> It should be able to generate keystores for each NiFi node, a truststore that 
> they all use, and relevant passwords and configuration files for using the 
> keystores and truststore.
> Additionally, in order to support distributed deployment, a web based 
> certificate authority with corresponding client will allow for each NiFi 
> instance to generate its own keypair and then request signing by the CA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2477) Document tls-toolkit

[Bryan Rosander (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407114#comment-15407114
 ] 

Bryan Rosander commented on NIFI-2477:
--

Rough draft:

Admin Guide:

The tls-toolkit has two primary modes of operation:
Standalone -- generates the certificate authority, keystores, truststores, and 
nifi.properties files in one command.
Client/Server mode -- uses a Certificate Authority Server that accepts 
Certificate Signing Requests from clients, signs them, and sends the resulting 
certificates back.  Both client and server validate the other’s identity 
through a shared secret.

Standalone:
Standalone mode can be invoked by running “tls-toolkit.sh standalone -h” which 
will print the usage information along with descriptions of options that can be 
specified.

The most common options to specify are:
-n (or --hostnames) a comma-separated list of hostnames that you’d like to 
generate certificates for
-f (or --nifiPropertiesFile) a base nifi.properties file that the tool will 
update for each host
-o (or --outputDirectory) the directory to use for the resulting Certificate 
Authority files and NiFi configurations.  A subdirectory will be made for each 
host.
-R (or --sameKeyAndKeyStorePassword) use the same value when generating 
KeyStore and TrustStore passwords which is currently needed
-p (or --httpsPort) the https port in nifi.properties and enable secure 
site-to-site.  This is optional and not necessary if you’ve provided a template 
nifi.properties.

Client/Server:

Server:
Client/Server mode relies on a long-running CA (Certificate Authority) (that 
can be stopped when you’re not bringing nodes online) to issue certificates.  
The CA server can be invoked by running “tls-toolkit server -h” which will 
print the usage information.

The most likely options to be specified are:
-f (or --configJson) the location of the json config (written after first run)
-F (or --useConfigJson) load all relevant configuration from the config json 
(if using, configJson is the only other argument necessary)
-t (or --token) the token used to prevent man in the middle attacks (this 
should be a long, random value and needs to be known when invoking the client)
-D (or --dn) the dn for the CA

Client:
The client can be used to request new Certificates from the CA.  The client 
utility will generate a keypair and CSR (Certificate Signing Request) and send 
the CSR to the certificate authority.  The client can be invoked by running 
“tls-toolkit.sh client -h” which will print usage information.

The most likely options to be specified are:
-f (or --configJson) the json config file
-c (or --certificateAuthorityHostname) the hostname of the CA
-D (or --DN) the dn for the CSR (and Certificate)
-t (or --token) the token used to prevent man in the middle attacks (this 
should be a long, random value and needs to be known when invoking the client)
-T (or --keyStoreType) the type of keystore to create (specify jks for NiFi 
nodes, leave default to create client cert)

After running the client you will have the CA’s certificate, a keystore, a 
truststore, and a config.json with information about them as well as their 
passwords.

If you leave -T (or --keyStoreType) as its default value, PKCS12 will be used 
in order to make it easy to import into a browser (for client certificates).


Developer Guide:

This is a developer-oriented document, for the tls-toolkit.  For the usage 
information, please consult the Admin Guide.

The Client/Server mode of operation came about from the desire to be able to 
autogenerate required TLS configuration artifacts without needing to perform 
that generation in a centralized place.  This simplifies configuration in a 
clustered environment.  Since we don’t necessarily have a central place to run 
the generation logic or a trusted Certificate Authority, a shared secret is 
used to authenticate the clients and server to each other.

The tls-toolkit prevents man in the middle attacks using HMAC verification of 
the public keys of the CA server and the CSR the client sends, using a shared 
secret (the token) as the HMAC key.

The basic process goes as follows:
The client generates a KeyPair.
The client generates a request json payload containing a CSR and an HMAC with 
the token as the key and the CSR’s public key fingerprint as the data.
The client connects to the CA Hostname at the https port specified and 
validates that the CN of the CA’s certificate matches the hostname (NOTE: 
because we don’t trust the CA at this point, this adds NO security, it is just 
a way to error out early if possible)
The server validates the HMAC from the client payload using the token as the 
key and the CSR’s public key fingerprint as the data.  This proves that the 
client knows the shared secret and that it wanted a CSR with that public key to 
be signed.  (A man in the middle could forward this on but wouldn’t be able 

[GitHub] nifi issue #695: NIFI-2193 - Command line SSL config utility as well as cert...

[alopresto]

Github user alopresto commented on the issue:

https://github.com/apache/nifi/pull/695
  
I am merging this for the beta release tomorrow. There are still some rough 
edges, and those are being captured in 
[NIFI-2476](https://issues.apache.org/jira/browse/NIFI-2476). The documentation 
for using the tools here is temporarily provided in the original Jira 
[NIFI-2193](https://issues.apache.org/jira/browse/NIFI-2193) until it can be 
properly reviewed and merged into the User Guide and Admin Guide 
[NIFI-2477](https://issues.apache.org/jira/browse/NIFI-2477). 

I will run contrib-check, rebase, squash, and merge. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2193) Command Line Keystore and Truststore utility

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407115#comment-15407115
 ] 

ASF GitHub Bot commented on NIFI-2193:
--

Github user alopresto commented on the issue:

https://github.com/apache/nifi/pull/695
  
I am merging this for the beta release tomorrow. There are still some rough 
edges, and those are being captured in 
[NIFI-2476](https://issues.apache.org/jira/browse/NIFI-2476). The documentation 
for using the tools here is temporarily provided in the original Jira 
[NIFI-2193](https://issues.apache.org/jira/browse/NIFI-2193) until it can be 
properly reviewed and merged into the User Guide and Admin Guide 
[NIFI-2477](https://issues.apache.org/jira/browse/NIFI-2477). 

I will run contrib-check, rebase, squash, and merge. 


> Command Line Keystore and Truststore utility
> 
>
> Key: NIFI-2193
> URL: https://issues.apache.org/jira/browse/NIFI-2193
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
>
> In order to facilitate secure setup of NiFi, it would be useful to have a 
> command line utility capable of generating the required keystores, 
> truststore, and relevant configuration files.
> It should be able to generate keystores for each NiFi node, a truststore that 
> they all use, and relevant passwords and configuration files for using the 
> keystores and truststore.
> Additionally, in order to support distributed deployment, a web based 
> certificate authority with corresponding client will allow for each NiFi 
> instance to generate its own keypair and then request signing by the CA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (NIFI-2477) Document tls-toolkit

[Bryan Rosander (JIRA)]

Bryan Rosander created NIFI-2477:


 Summary: Document tls-toolkit
 Key: NIFI-2477
 URL: https://issues.apache.org/jira/browse/NIFI-2477
 Project: Apache NiFi
  Issue Type: Task
Reporter: Bryan Rosander


tls-toolkit created as part of NIFI-2193 needs to be documented in order to be 
a useful utility to ease the burden of configuring tls for one or more NiFi 
instances.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (NIFI-2193) Command Line Keystore and Truststore utility

[Bryan Rosander (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407111#comment-15407111
 ] 

Bryan Rosander edited comment on NIFI-2193 at 8/4/16 4:18 AM:
--

Here is a rough draft of the documentation

Admin Guide:

The tls-toolkit has two primary modes of operation:
Standalone -- generates the certificate authority, keystores, truststores, and 
nifi.properties files in one command.
Client/Server mode -- uses a Certificate Authority Server that accepts 
Certificate Signing Requests from clients, signs them, and sends the resulting 
certificates back.  Both client and server validate the other’s identity 
through a shared secret.

Standalone:
Standalone mode can be invoked by running “tls-toolkit.sh standalone -h” which 
will print the usage information along with descriptions of options that can be 
specified.

The most common options to specify are:
-n (or --hostnames) a comma-separated list of hostnames that you’d like to 
generate certificates for
-f (or --nifiPropertiesFile) a base nifi.properties file that the tool will 
update for each host
-o (or --outputDirectory) the directory to use for the resulting Certificate 
Authority files and NiFi configurations.  A subdirectory will be made for each 
host.
-p (or --httpsPort) the https port in nifi.properties and enable secure 
site-to-site.  This is optional and not necessary if you’ve provided a template 
nifi.properties.

Client/Server:

Server:
Client/Server mode relies on a long-running CA (Certificate Authority) (that 
can be stopped when you’re not bringing nodes online) to issue certificates.  
The CA server can be invoked by running “tls-toolkit server -h” which will 
print the usage information.

The most likely options to be specified are:
-f (or --configJson) the location of the json config (written after first run)
-F (or --useConfigJson) load all relevant configuration from the config json 
(if using, configJson is the only other argument necessary)
-t (or --token) the token used to prevent man in the middle attacks (this 
should be a long, random value and needs to be known when invoking the client)
-D (or --dn) the dn for the CA

Client:
The client can be used to request new Certificates from the CA.  The client 
utility will generate a keypair and CSR (Certificate Signing Request) and send 
the CSR to the certificate authority.  The client can be invoked by running 
“tls-toolkit.sh client -h” which will print usage information.

The most likely options to be specified are:
-f (or --configJson) the json config file
-c (or --certificateAuthorityHostname) the hostname of the CA
-D (or --DN) the dn for the CSR (and Certificate)
-t (or --token) the token used to prevent man in the middle attacks (this 
should be a long, random value and needs to be known when invoking the client)
-T (or --keyStoreType) the type of keystore to create (specify jks for NiFi 
nodes, leave default to create client cert)

After running the client you will have the CA’s certificate, a keystore, a 
truststore, and a config.json with information about them as well as their 
passwords.

If you leave -T (or --keyStoreType) as its default value, PKCS12 will be used 
in order to make it easy to import into a browser (for client certificates).


Developer Guide:

This is a developer-oriented document, for the tls-toolkit.  For the usage 
information, please consult the Admin Guide.

The Client/Server mode of operation came about from the desire to be able to 
autogenerate required TLS configuration artifacts without needing to perform 
that generation in a centralized place.  This simplifies configuration in a 
clustered environment.  Since we don’t necessarily have a central place to run 
the generation logic or a trusted Certificate Authority, a shared secret is 
used to authenticate the clients and server to each other.

The tls-toolkit prevents man in the middle attacks using HMAC verification of 
the public keys of the CA server and the CSR the client sends, using a shared 
secret (the token) as the HMAC key.

The basic process goes as follows:
The client generates a KeyPair.
The client generates a request json payload containing a CSR and an HMAC with 
the token as the key and the CSR’s public key fingerprint as the data.
The client connects to the CA Hostname at the https port specified and 
validates that the CN of the CA’s certificate matches the hostname (NOTE: 
because we don’t trust the CA at this point, this adds NO security, it is just 
a way to error out early if possible)
The server validates the HMAC from the client payload using the token as the 
key and the CSR’s public key fingerprint as the data.  This proves that the 
client knows the shared secret and that it wanted a CSR with that public key to 
be signed.  (A man in the middle could forward this on but wouldn’t be able to 
change the CSR without invalidating the HMAC, 

[jira] [Commented] (NIFI-2193) Command Line Keystore and Truststore utility

[Bryan Rosander (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407111#comment-15407111
 ] 

Bryan Rosander commented on NIFI-2193:
--

Here is a rough draft of the documentation

Admin Guide:

The tls-toolkit has two primary modes of operation:
Standalone -- generates the certificate authority, keystores, truststores, and 
nifi.properties files in one command.
Client/Server mode -- uses a Certificate Authority Server that accepts 
Certificate Signing Requests from clients, signs them, and sends the resulting 
certificates back.  Both client and server validate the other’s identity 
through a shared secret.

Standalone:
Standalone mode can be invoked by running “tls-toolkit.sh standalone -h” which 
will print the usage information along with descriptions of options that can be 
specified.

The most common options to specify are:
-n (or --hostnames) a comma-separated list of hostnames that you’d like to 
generate certificates for
-f (or --nifiPropertiesFile) a base nifi.properties file that the tool will 
update for each host
-o (or --outputDirectory) the directory to use for the resulting Certificate 
Authority files and NiFi configurations.  A subdirectory will be made for each 
host.
-R (or --sameKeyAndKeyStorePassword) use the same value when generating 
KeyStore and TrustStore passwords which is currently needed
-p (or --httpsPort) the https port in nifi.properties and enable secure 
site-to-site.  This is optional and not necessary if you’ve provided a template 
nifi.properties.

Client/Server:

Server:
Client/Server mode relies on a long-running CA (Certificate Authority) (that 
can be stopped when you’re not bringing nodes online) to issue certificates.  
The CA server can be invoked by running “tls-toolkit server -h” which will 
print the usage information.

The most likely options to be specified are:
-f (or --configJson) the location of the json config (written after first run)
-F (or --useConfigJson) load all relevant configuration from the config json 
(if using, configJson is the only other argument necessary)
-t (or --token) the token used to prevent man in the middle attacks (this 
should be a long, random value and needs to be known when invoking the client)
-D (or --dn) the dn for the CA

Client:
The client can be used to request new Certificates from the CA.  The client 
utility will generate a keypair and CSR (Certificate Signing Request) and send 
the CSR to the certificate authority.  The client can be invoked by running 
“tls-toolkit.sh client -h” which will print usage information.

The most likely options to be specified are:
-f (or --configJson) the json config file
-c (or --certificateAuthorityHostname) the hostname of the CA
-D (or --DN) the dn for the CSR (and Certificate)
-t (or --token) the token used to prevent man in the middle attacks (this 
should be a long, random value and needs to be known when invoking the client)
-T (or --keyStoreType) the type of keystore to create (specify jks for NiFi 
nodes, leave default to create client cert)

After running the client you will have the CA’s certificate, a keystore, a 
truststore, and a config.json with information about them as well as their 
passwords.

If you leave -T (or --keyStoreType) as its default value, PKCS12 will be used 
in order to make it easy to import into a browser (for client certificates).


Developer Guide:

This is a developer-oriented document, for the tls-toolkit.  For the usage 
information, please consult the Admin Guide.

The Client/Server mode of operation came about from the desire to be able to 
autogenerate required TLS configuration artifacts without needing to perform 
that generation in a centralized place.  This simplifies configuration in a 
clustered environment.  Since we don’t necessarily have a central place to run 
the generation logic or a trusted Certificate Authority, a shared secret is 
used to authenticate the clients and server to each other.

The tls-toolkit prevents man in the middle attacks using HMAC verification of 
the public keys of the CA server and the CSR the client sends, using a shared 
secret (the token) as the HMAC key.

The basic process goes as follows:
The client generates a KeyPair.
The client generates a request json payload containing a CSR and an HMAC with 
the token as the key and the CSR’s public key fingerprint as the data.
The client connects to the CA Hostname at the https port specified and 
validates that the CN of the CA’s certificate matches the hostname (NOTE: 
because we don’t trust the CA at this point, this adds NO security, it is just 
a way to error out early if possible)
The server validates the HMAC from the client payload using the token as the 
key and the CSR’s public key fingerprint as the data.  This proves that the 
client knows the shared secret and that it wanted a CSR with that public key to 
be signed.  (A man in the middle could forward 

[jira] [Commented] (NIFI-2476) Further refine tls-toolkit based on feedback gathered during beta

[Andy LoPresto (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407105#comment-15407105
 ] 

Andy LoPresto commented on NIFI-2476:
-

The tool should allow for multiple, non-unique hostnames. For example, running 
multiple instances on one physical/virtual machine, both would default to the 
hostname {{localhost}}, but the tool would only generate one keystore and then 
fail. Instead, the output folders should use a format like {{hostname-n}} where 
{{n}} is a sequential counter, {{hostname-}}, or 
{{hostname-}}. 

> Further refine tls-toolkit based on feedback gathered during beta
> -
>
> Key: NIFI-2476
> URL: https://issues.apache.org/jira/browse/NIFI-2476
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Rosander
>
> The basic functionality of generating keystores, truststores, 
> nifi.properties, and a configuration json is implemented.
> As people start using this tool to ease the tls setup process in NiFi, 
> shortcomings in the initial implementation will need to be addressed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (NIFI-2476) Further refine tls-toolkit based on feedback gathered during beta

[Andy LoPresto (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407094#comment-15407094
 ] 

Andy LoPresto edited comment on NIFI-2476 at 8/4/16 3:49 AM:
-

The standalone tool should combine {{nifi-cert.pem}} and {{nifi-key.key}} into 
{{client.p12}} so a user can provide a client certificate to connect to the 
newly secured NiFi instance. 

{{ossl pkcs12 -export -out client.p12 -inkey nifi-key.key -in nifi-cert.pem}}


was (Author: alopresto):
The standalone tool should combine {{nifi-cert.pem}} and {{nifi-key.key}} into 
{{client.p12}} so a user can provide a client certificate to connect to the 
newly secured NiFi instance. 

{{ossl pkcs12 -export -out nifi-cert.p12 -inkey nifi-key.key -in nifi-cert.pem}}

> Further refine tls-toolkit based on feedback gathered during beta
> -
>
> Key: NIFI-2476
> URL: https://issues.apache.org/jira/browse/NIFI-2476
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Rosander
>
> The basic functionality of generating keystores, truststores, 
> nifi.properties, and a configuration json is implemented.
> As people start using this tool to ease the tls setup process in NiFi, 
> shortcomings in the initial implementation will need to be addressed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2476) Further refine tls-toolkit based on feedback gathered during beta

[Andy LoPresto (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407094#comment-15407094
 ] 

Andy LoPresto commented on NIFI-2476:
-

The standalone tool should combine {{nifi-cert.pem}} and {{nifi-key.key}} into 
{{client.p12}} so a user can provide a client certificate to connect to the 
newly secured NiFi instance. 

{{ossl pkcs12 -export -out nifi-cert.p12 -inkey nifi-key.key -in nifi-cert.pem}}

> Further refine tls-toolkit based on feedback gathered during beta
> -
>
> Key: NIFI-2476
> URL: https://issues.apache.org/jira/browse/NIFI-2476
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Rosander
>
> The basic functionality of generating keystores, truststores, 
> nifi.properties, and a configuration json is implemented.
> As people start using this tool to ease the tls setup process in NiFi, 
> shortcomings in the initial implementation will need to be addressed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2419) Node could be elected Cluster Coordinator when disconnected from cluster

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407093#comment-15407093
 ] 

ASF GitHub Bot commented on NIFI-2419:
--

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/739


> Node could be elected Cluster Coordinator when disconnected from cluster
> 
>
> Key: NIFI-2419
> URL: https://issues.apache.org/jira/browse/NIFI-2419
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Blocker
> Fix For: 1.0.0
>
>
> In my cluster, I see the following Node events for a particular node:
> 07/28/2016 06:17:29 UTC: Acquired role [Cluster Coordinator]
> 07/28/2016 04:53:30 UTC: Node Status changed from CONNECTING to DISCONNECTED 
> due to org.apache.nifi.controller.UninheritableFlowException: Failed to 
> connect node to cluster because local flow is different than cluster flow.
> So the Cluster Coordinator role was obtained even though the node is 
> disconnected. This shouldn't happen.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2419) Node could be elected Cluster Coordinator when disconnected from cluster

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407091#comment-15407091
 ] 

ASF subversion and git services commented on NIFI-2419:
---

Commit f0401e47747e8bfc0b96ff824f23f6f0f91017f1 in nifi's branch 
refs/heads/master from [~markap14]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=f0401e4 ]

NIFI-2419: Ensure that if a node is disconnected that we unregister for 
'cluster coordinator' and 'primary node' roles by updating FlowController to 
know that it is disconnected. Also removed dead code that was needed in the 
master-worker clustering paradigm but not for zero-master-clustering

Signed-off-by: Yolanda M. Davis 

This closes #739


> Node could be elected Cluster Coordinator when disconnected from cluster
> 
>
> Key: NIFI-2419
> URL: https://issues.apache.org/jira/browse/NIFI-2419
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Blocker
> Fix For: 1.0.0
>
>
> In my cluster, I see the following Node events for a particular node:
> 07/28/2016 06:17:29 UTC: Acquired role [Cluster Coordinator]
> 07/28/2016 04:53:30 UTC: Node Status changed from CONNECTING to DISCONNECTED 
> due to org.apache.nifi.controller.UninheritableFlowException: Failed to 
> connect node to cluster because local flow is different than cluster flow.
> So the Cluster Coordinator role was obtained even though the node is 
> disconnected. This shouldn't happen.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #739: NIFI-2419: Ensure that if a node is disconnected tha...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/739


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2035) Connection creation needs to verify that source and destination both exist during 1st phase of 2 phase commit

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407069#comment-15407069
 ] 

ASF GitHub Bot commented on NIFI-2035:
--

Github user YolandaMDavis commented on the issue:

https://github.com/apache/nifi/pull/690
  
@markap14 thanks for the update! will retest and confirm.


> Connection creation needs to verify that source and destination both exist 
> during 1st phase of 2 phase commit
> -
>
> Key: NIFI-2035
> URL: https://issues.apache.org/jira/browse/NIFI-2035
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Mark Payne
>Assignee: Mark Payne
> Fix For: 1.0.0
>
>
> When a connection is created, we don't verify in the first step that both the 
> source and destination exist. In the case of a Remote Process Group, where 
> the ports change in the background, this can become problematic, we one node 
> in the cluster may not have the same ports as another and the connection 
> creation could end up failing on that node, resulting in the node getting 
> kicked out of the cluster. We should also verify that the new destination 
> exists when updating a connection if its destination changes, as this could 
> happen there as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #690: NIFI-2035: Verify existence of source and destination when ...

[YolandaMDavis]

Github user YolandaMDavis commented on the issue:

https://github.com/apache/nifi/pull/690
  
@markap14 thanks for the update! will retest and confirm.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2419) Node could be elected Cluster Coordinator when disconnected from cluster

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407039#comment-15407039
 ] 

ASF GitHub Bot commented on NIFI-2419:
--

Github user YolandaMDavis commented on the issue:

https://github.com/apache/nifi/pull/739
  
@markap14 was able to test with 2 node cluster removing one node from 
cluster, changing it's flow by adding a new processor, and attempting to add it 
back to the cluster.  Did confirm through debug and log review that upon the 
UninheritableFlowException node's clustered state was set to false and node was 
unregistered from both Primary Node and Cluster Coordinator roles in leader 
election.  Updating flow to match original flow did allow the node to rejoin 
the cluster without issue.

+1


> Node could be elected Cluster Coordinator when disconnected from cluster
> 
>
> Key: NIFI-2419
> URL: https://issues.apache.org/jira/browse/NIFI-2419
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Blocker
> Fix For: 1.0.0
>
>
> In my cluster, I see the following Node events for a particular node:
> 07/28/2016 06:17:29 UTC: Acquired role [Cluster Coordinator]
> 07/28/2016 04:53:30 UTC: Node Status changed from CONNECTING to DISCONNECTED 
> due to org.apache.nifi.controller.UninheritableFlowException: Failed to 
> connect node to cluster because local flow is different than cluster flow.
> So the Cluster Coordinator role was obtained even though the node is 
> disconnected. This shouldn't happen.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #739: NIFI-2419: Ensure that if a node is disconnected that we un...

[YolandaMDavis]

Github user YolandaMDavis commented on the issue:

https://github.com/apache/nifi/pull/739
  
@markap14 was able to test with 2 node cluster removing one node from 
cluster, changing it's flow by adding a new processor, and attempting to add it 
back to the cluster.  Did confirm through debug and log review that upon the 
UninheritableFlowException node's clustered state was set to false and node was 
unregistered from both Primary Node and Cluster Coordinator roles in leader 
election.  Updating flow to match original flow did allow the node to rejoin 
the cluster without issue.

+1


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request #774: Nifi 2440 - Add Last Modified Time attribute to List...

[kirkalicious]

GitHub user kirkalicious reopened a pull request:

https://github.com/apache/nifi/pull/774

Nifi 2440 - Add Last Modified Time attribute to ListSFTP

Add last modified time  attribute to flow files generated by ListSFTP 
processor.
The attribute format is consistent with what is expected by downstream 
processors like PutFile

attribute - file.lastModifiedTime
attribute format - -MM-dd'T'HH:mm:ssZ

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/kirkalicious/nifi NIFI-2440

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/774.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #774


commit 85b196f07337110a4931bf80702604393df12afe
Author: Kirk Tarou 
Date:   2016-07-31T04:22:59Z

NIFI-2440

Add last modified time & timestamp attribute to flow files
generated by ListSFTP processor

commit 4136bf15fe7fac725cda3e252a2287807fcdead3
Author: Kirk Tarou 
Date:   2016-08-02T05:30:27Z

Changed format of file.lastModifiedTime attribute to match the format
required by PutFile processor

commit 13e1145a5a14755cfbbf637dc18ba0308801eb13
Author: Kirk Tarou 
Date:   2016-08-02T23:45:35Z

Changed imports to match required style

commit 4f56b4f9f4dfeda557ea926ec60cb78e4a5a3b8f
Author: Kirk Tarou 
Date:   2016-08-02T23:55:13Z

Remove WritesAttribute annotation for file.timestamp

commit 610a7b0b3b5324571dec9f7d145162ceaf5c4796
Author: Kirk Tarou 
Date:   2016-08-03T22:14:24Z

ListFileTransfer - now uses attribute constants from ListFile
TestListFile - trying to fix AppVeyor issue reading name of process
owner to match with file owner




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request #774: Nifi 2440 - Add Last Modified Time attribute to List...

[kirkalicious]

Github user kirkalicious closed the pull request at:

https://github.com/apache/nifi/pull/774


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2474) TestRunner should not expose a VariableRegistry construct

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406907#comment-15406907
 ] 

ASF GitHub Bot commented on NIFI-2474:
--

GitHub user markap14 opened a pull request:

https://github.com/apache/nifi/pull/782

NIFI-2474: Remove VariableRegistry from outward facing API so that th…

…e it is more flexible to evolve

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/markap14/nifi NIFI-2474

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/782.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #782


commit 2004ed2fdeaf1190cc8ac8ccb137909b17f07ba2
Author: Mark Payne 
Date:   2016-08-04T00:44:04Z

NIFI-2474: Remove VariableRegistry from outward facing API so that the it 
is more flexible to evolve




> TestRunner should not expose a VariableRegistry construct
> -
>
> Key: NIFI-2474
> URL: https://issues.apache.org/jira/browse/NIFI-2474
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Tools and Build
>Reporter: Mark Payne
> Fix For: 1.0.0
>
>
> Currently, the TestRunners class provides a mechanism for creating a 
> TestRunner that takes in a Variable Registry. The concept of providing 
> variables to the Test Runner is very valuable. However, the notion of the 
> VariableRegistry is an internal implementation detail that is getting 
> exposed, creating a leaky abstraction.
> We should remove the override of the createTestRunner() method that takes the 
> Variable Registry and instead expose a set of methods of TestRunner:
> void setVariable(String name, String value)
> String getVariable(String name)
> void setVariables(Map variables)
> Map getVariables()
> Additionally, as-is, if no VariableRegistry is provided, the default is to 
> use a Variable Registry that provides System and Environment variables. This 
> should be avoided, as it encourages unit tests to depend on 
> environment-specific settings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2476) Further refine tls-toolkit based on feedback gathered during beta

[Andy LoPresto (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406908#comment-15406908
 ] 

Andy LoPresto commented on NIFI-2476:
-

The standalone tool should accept a flag indicating that when multiple 
hostnames are provided, sequential (or at least unique) port numbers should be 
used for the respective {{nifi.properties}} files. This allows the tool to 
configure multiple instances of the application which will reside on the same 
server. 

> Further refine tls-toolkit based on feedback gathered during beta
> -
>
> Key: NIFI-2476
> URL: https://issues.apache.org/jira/browse/NIFI-2476
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Rosander
>
> The basic functionality of generating keystores, truststores, 
> nifi.properties, and a configuration json is implemented.
> As people start using this tool to ease the tls setup process in NiFi, 
> shortcomings in the initial implementation will need to be addressed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2474) TestRunner should not expose a VariableRegistry construct

[Mark Payne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Payne updated NIFI-2474:
-
Assignee: Mark Payne
  Status: Patch Available  (was: Open)

> TestRunner should not expose a VariableRegistry construct
> -
>
> Key: NIFI-2474
> URL: https://issues.apache.org/jira/browse/NIFI-2474
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Tools and Build
>Reporter: Mark Payne
>Assignee: Mark Payne
> Fix For: 1.0.0
>
>
> Currently, the TestRunners class provides a mechanism for creating a 
> TestRunner that takes in a Variable Registry. The concept of providing 
> variables to the Test Runner is very valuable. However, the notion of the 
> VariableRegistry is an internal implementation detail that is getting 
> exposed, creating a leaky abstraction.
> We should remove the override of the createTestRunner() method that takes the 
> Variable Registry and instead expose a set of methods of TestRunner:
> void setVariable(String name, String value)
> String getVariable(String name)
> void setVariables(Map variables)
> Map getVariables()
> Additionally, as-is, if no VariableRegistry is provided, the default is to 
> use a Variable Registry that provides System and Environment variables. This 
> should be avoided, as it encourages unit tests to depend on 
> environment-specific settings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #782: NIFI-2474: Remove VariableRegistry from outward faci...

[markap14]

GitHub user markap14 opened a pull request:

https://github.com/apache/nifi/pull/782

NIFI-2474: Remove VariableRegistry from outward facing API so that th…

…e it is more flexible to evolve

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/markap14/nifi NIFI-2474

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/782.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #782


commit 2004ed2fdeaf1190cc8ac8ccb137909b17f07ba2
Author: Mark Payne 
Date:   2016-08-04T00:44:04Z

NIFI-2474: Remove VariableRegistry from outward facing API so that the it 
is more flexible to evolve




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2476) Further refine tls-toolkit based on feedback gathered during beta

[Andy LoPresto (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406904#comment-15406904
 ] 

Andy LoPresto commented on NIFI-2476:
-

By default, the tool generates different values for the {{key}} and 
{{keystore}} password. It successfully populates these values into the 
respective {{nifi.properties}}, but the {{SSLContextService}} which is used by 
NiFi does not allow for disparate keys, so a key tamper/incorrect exception is 
thrown during NiFi startup. The default behavior of the tool should be to 
enforce the same key and keystore password {{-R}} until such time that the 
blocking issues [NIFI-1478] and [NIFI-2466] are resolved. 

Example:
{code}
2016-08-03 17:29:33,526 INFO [main] /nifi-api Initializing Spring root 
WebApplicationContext
2016-08-03 17:29:38,018 WARN [main] org.eclipse.jetty.webapp.WebAppContext 
Failed startup of context 
o.e.j.w.WebAppContext@5440a3a{/nifi-api,file:///Users/alopresto/Workspace/scratch/NIFI-2193/host1/work/jetty/nifi-web-api-1.0.0-SNAPSHOT.war/webapp/,UNAVAILABLE}{./work/nar/framework/nifi-framework-nar-1.0.0-SNAPSHOT.nar-unpacked/META-INF/bundled-dependencies/nifi-web-api-1.0.0-SNAPSHOT.war}
org.apache.nifi.web.NiFiCoreException: Unable to start Flow Controller.
at 
org.apache.nifi.web.contextlistener.ApplicationStartupContextListener.contextInitialized(ApplicationStartupContextListener.java:93)
 ~[na:na]
at 
org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:837)
 ~[jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:533)
 ~[jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:810)
 ~[jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:345)
 ~[jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1404) 
~[jetty-webapp-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1366) 
~[jetty-webapp-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:772)
 ~[jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:262)
 ~[jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:520) 
~[jetty-webapp-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
 [jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at org.eclipse.jetty.server.Server.start(Server.java:411) 
[jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:106)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
 [jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at org.eclipse.jetty.server.Server.doStart(Server.java:378) 
[jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:651) 
[nifi-jetty-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
at org.apache.nifi.NiFi.(NiFi.java:137) 
[nifi-runtime-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
at org.apache.nifi.NiFi.main(NiFi.java:227) 
[nifi-runtime-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
Caused by: org.springframework.beans.factory.BeanCreationException: Error 
creating bean with name 'flowService': FactoryBean threw exception on object 
creation; nested exception is 
org.springframework.beans.factory.BeanCreationException: Error creating bean 
with 

[jira] [Commented] (NIFI-2466) SSLContextService should support specifying Key Password

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406878#comment-15406878
 ] 

ASF GitHub Bot commented on NIFI-2466:
--

Github user markap14 commented on the issue:

https://github.com/apache/nifi/pull/776
  
@alopresto yes i was able to test with ListenHTTP / PostHTTP so that the 
SSL Context was used on both the receiving & sending ends, using both keystore 
and truststore. Thanks!


> SSLContextService should support specifying Key Password
> 
>
> Key: NIFI-2466
> URL: https://issues.apache.org/jira/browse/NIFI-2466
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Mark Payne
>Assignee: Mark Payne
> Fix For: 1.0.0
>
>
> Currently, the SSLContextService supports only a keystore password and 
> assumes that the key password is the same. We should support setting a 
> separate password for the key itself.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #776: NIFI-2466: Add option to specify key password when differen...

[markap14]

Github user markap14 commented on the issue:

https://github.com/apache/nifi/pull/776
  
@alopresto yes i was able to test with ListenHTTP / PostHTTP so that the 
SSL Context was used on both the receiving & sending ends, using both keystore 
and truststore. Thanks!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2476) Further refine tls-toolkit based on feedback gathered during beta

[Andy LoPresto (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406874#comment-15406874
 ] 

Andy LoPresto commented on NIFI-2476:
-

The default path populated into {{nifi.properties}} should probably be 
{{conf/keystore.jks}} and {{conf/truststore.jks}} so that the entire tool 
output directory for each host can be copied directly into the {{conf/}} 
directory on the respective server. The keystore and truststore paths are 
searched from {{$NIFI_HOME}}, so the keystore/truststore must either be one 
directory above {{nifi.properties}}, or the paths should change. 

> Further refine tls-toolkit based on feedback gathered during beta
> -
>
> Key: NIFI-2476
> URL: https://issues.apache.org/jira/browse/NIFI-2476
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Rosander
>
> The basic functionality of generating keystores, truststores, 
> nifi.properties, and a configuration json is implemented.
> As people start using this tool to ease the tls setup process in NiFi, 
> shortcomings in the initial implementation will need to be addressed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (NIFI-2476) Further refine tls-toolkit based on feedback gathered during beta

[Andy LoPresto (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406838#comment-15406838
 ] 

Andy LoPresto edited comment on NIFI-2476 at 8/3/16 11:48 PM:
--

Standalone tool does not configure NiFi to run with HTTPS enabled by default. 

{code}
hw12203:...assembly/target/nifi-toolkit-1.0.0-SNAPSHOT-bin/nifi-toolkit-1.0.0-SNAPSHOT
 (pr695) alopresto
 9s @ 16:41:08 $ ./bin/tls-toolkit.sh standalone -n host1,host2
16/08/03 16:43:39 INFO standalone.TlsToolkitStandalone: Running standalone 
certificate generation with output directory . and hostnames [host1, host2]
16/08/03 16:43:39 INFO standalone.TlsToolkitStandalone: Successfully generated 
TLS configuration
hw12203:...assembly/target/nifi-toolkit-1.0.0-SNAPSHOT-bin/nifi-toolkit-1.0.0-SNAPSHOT
 (pr695) alopresto
 151s @ 16:43:40 $ tl
.
...
├── [ 170]  host1
│   ├── [3.0K]  keystore.jks
│   ├── [8.2K]  nifi.properties
│   └── [ 907]  truststore.jks
├── [ 170]  host2
│   ├── [3.0K]  keystore.jks
│   ├── [8.2K]  nifi.properties
│   └── [ 907]  truststore.jks
...

6 directories, 38 files
hw12203:...assembly/target/nifi-toolkit-1.0.0-SNAPSHOT-bin/nifi-toolkit-1.0.0-SNAPSHOT
 (pr695) alopresto
 7s @ 16:43:48 $ more host1/nifi.properties
...
# Site to Site properties
nifi.remote.input.host=
nifi.remote.input.secure=false
nifi.remote.input.socket.port=
nifi.remote.input.http.enabled=true
nifi.remote.input.http.transaction.ttl=30 sec

# web properties #
nifi.web.war.directory=./lib
nifi.web.http.host=
nifi.web.http.port=8080
nifi.web.https.host=
nifi.web.https.port=
nifi.web.jetty.working.directory=./work/jetty
nifi.web.jetty.threads=200

# security properties #
nifi.sensitive.props.key=
nifi.sensitive.props.algorithm=PBEWITHMD5AND256BITAES-CBC-OPENSSL
nifi.sensitive.props.provider=BC

nifi.security.keystore=keystore.jks
nifi.security.keystoreType=jks
nifi.security.keystorePasswd=AKDDN7R+dOawssR9VhwI/BcTpDyUIF/90cE2GygxyC6f
nifi.security.keyPasswd=FSid1nbtYvSYcsSn6QWod4lvhEM1ffOEapPJz2FEdhk
nifi.security.truststore=truststore.jks
nifi.security.truststoreType=jks
nifi.security.truststorePasswd=AK5o4UzDW8bV2b+IU3bUBW1rGz4Ka0L1B2IsIY8pj+fk
nifi.security.needClientAuth=
...
{code}

*Update*: I think this is because the HTTPS port is empty by default. With a 
port provided, the HTTPS configuration is populated. 


was (Author: alopresto):
Standalone tool does not configure NiFi to run with HTTPS enabled by default. 

{code}
hw12203:...assembly/target/nifi-toolkit-1.0.0-SNAPSHOT-bin/nifi-toolkit-1.0.0-SNAPSHOT
 (pr695) alopresto
 9s @ 16:41:08 $ ./bin/tls-toolkit.sh standalone -n host1,host2
16/08/03 16:43:39 INFO standalone.TlsToolkitStandalone: Running standalone 
certificate generation with output directory . and hostnames [host1, host2]
16/08/03 16:43:39 INFO standalone.TlsToolkitStandalone: Successfully generated 
TLS configuration
hw12203:...assembly/target/nifi-toolkit-1.0.0-SNAPSHOT-bin/nifi-toolkit-1.0.0-SNAPSHOT
 (pr695) alopresto
 151s @ 16:43:40 $ tl
.
...
├── [ 170]  host1
│   ├── [3.0K]  keystore.jks
│   ├── [8.2K]  nifi.properties
│   └── [ 907]  truststore.jks
├── [ 170]  host2
│   ├── [3.0K]  keystore.jks
│   ├── [8.2K]  nifi.properties
│   └── [ 907]  truststore.jks
...

6 directories, 38 files
hw12203:...assembly/target/nifi-toolkit-1.0.0-SNAPSHOT-bin/nifi-toolkit-1.0.0-SNAPSHOT
 (pr695) alopresto
 7s @ 16:43:48 $ more host1/nifi.properties
...
# Site to Site properties
nifi.remote.input.host=
nifi.remote.input.secure=false
nifi.remote.input.socket.port=
nifi.remote.input.http.enabled=true
nifi.remote.input.http.transaction.ttl=30 sec

# web properties #
nifi.web.war.directory=./lib
nifi.web.http.host=
nifi.web.http.port=8080
nifi.web.https.host=
nifi.web.https.port=
nifi.web.jetty.working.directory=./work/jetty
nifi.web.jetty.threads=200

# security properties #
nifi.sensitive.props.key=
nifi.sensitive.props.algorithm=PBEWITHMD5AND256BITAES-CBC-OPENSSL
nifi.sensitive.props.provider=BC

nifi.security.keystore=keystore.jks
nifi.security.keystoreType=jks
nifi.security.keystorePasswd=AKDDN7R+dOawssR9VhwI/BcTpDyUIF/90cE2GygxyC6f
nifi.security.keyPasswd=FSid1nbtYvSYcsSn6QWod4lvhEM1ffOEapPJz2FEdhk
nifi.security.truststore=truststore.jks
nifi.security.truststoreType=jks
nifi.security.truststorePasswd=AK5o4UzDW8bV2b+IU3bUBW1rGz4Ka0L1B2IsIY8pj+fk
nifi.security.needClientAuth=
...
{code}

> Further refine tls-toolkit based on feedback gathered during beta
> -
>
> Key: NIFI-2476
> URL: https://issues.apache.org/jira/browse/NIFI-2476
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Rosander
>
> The basic functionality of generating keystores, truststores, 
> nifi.properties, and a configuration json is implemented.
> As people start using this tool to ease the tls setup process in NiFi, 
> 

[jira] [Commented] (NIFI-2476) Further refine tls-toolkit based on feedback gathered during beta

[Andy LoPresto (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406838#comment-15406838
 ] 

Andy LoPresto commented on NIFI-2476:
-

Standalone tool does not configure NiFi to run with HTTPS enabled by default. 

{code}
hw12203:...assembly/target/nifi-toolkit-1.0.0-SNAPSHOT-bin/nifi-toolkit-1.0.0-SNAPSHOT
 (pr695) alopresto
 9s @ 16:41:08 $ ./bin/tls-toolkit.sh standalone -n host1,host2
16/08/03 16:43:39 INFO standalone.TlsToolkitStandalone: Running standalone 
certificate generation with output directory . and hostnames [host1, host2]
16/08/03 16:43:39 INFO standalone.TlsToolkitStandalone: Successfully generated 
TLS configuration
hw12203:...assembly/target/nifi-toolkit-1.0.0-SNAPSHOT-bin/nifi-toolkit-1.0.0-SNAPSHOT
 (pr695) alopresto
 151s @ 16:43:40 $ tl
.
...
├── [ 170]  host1
│   ├── [3.0K]  keystore.jks
│   ├── [8.2K]  nifi.properties
│   └── [ 907]  truststore.jks
├── [ 170]  host2
│   ├── [3.0K]  keystore.jks
│   ├── [8.2K]  nifi.properties
│   └── [ 907]  truststore.jks
...

6 directories, 38 files
hw12203:...assembly/target/nifi-toolkit-1.0.0-SNAPSHOT-bin/nifi-toolkit-1.0.0-SNAPSHOT
 (pr695) alopresto
 7s @ 16:43:48 $ more host1/nifi.properties
...
# Site to Site properties
nifi.remote.input.host=
nifi.remote.input.secure=false
nifi.remote.input.socket.port=
nifi.remote.input.http.enabled=true
nifi.remote.input.http.transaction.ttl=30 sec

# web properties #
nifi.web.war.directory=./lib
nifi.web.http.host=
nifi.web.http.port=8080
nifi.web.https.host=
nifi.web.https.port=
nifi.web.jetty.working.directory=./work/jetty
nifi.web.jetty.threads=200

# security properties #
nifi.sensitive.props.key=
nifi.sensitive.props.algorithm=PBEWITHMD5AND256BITAES-CBC-OPENSSL
nifi.sensitive.props.provider=BC

nifi.security.keystore=keystore.jks
nifi.security.keystoreType=jks
nifi.security.keystorePasswd=AKDDN7R+dOawssR9VhwI/BcTpDyUIF/90cE2GygxyC6f
nifi.security.keyPasswd=FSid1nbtYvSYcsSn6QWod4lvhEM1ffOEapPJz2FEdhk
nifi.security.truststore=truststore.jks
nifi.security.truststoreType=jks
nifi.security.truststorePasswd=AK5o4UzDW8bV2b+IU3bUBW1rGz4Ka0L1B2IsIY8pj+fk
nifi.security.needClientAuth=
...
{code}

> Further refine tls-toolkit based on feedback gathered during beta
> -
>
> Key: NIFI-2476
> URL: https://issues.apache.org/jira/browse/NIFI-2476
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Rosander
>
> The basic functionality of generating keystores, truststores, 
> nifi.properties, and a configuration json is implemented.
> As people start using this tool to ease the tls setup process in NiFi, 
> shortcomings in the initial implementation will need to be addressed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2476) Further refine tls-toolkit based on feedback gathered during beta

[Andy LoPresto (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406831#comment-15406831
 ] 

Andy LoPresto commented on NIFI-2476:
-

* Standalone tool has no default for:
** {{-f, --nifiPropertiesFile}}
** {{-p, --httpsPort}}
* Standalone tool default is unclear for:
** {{-o, --outputDirectory}} "." can display "current directory" or 
"../"

> Further refine tls-toolkit based on feedback gathered during beta
> -
>
> Key: NIFI-2476
> URL: https://issues.apache.org/jira/browse/NIFI-2476
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Rosander
>
> The basic functionality of generating keystores, truststores, 
> nifi.properties, and a configuration json is implemented.
> As people start using this tool to ease the tls setup process in NiFi, 
> shortcomings in the initial implementation will need to be addressed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2402) UI - Update logic to verify if components are eligible for moving

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406815#comment-15406815
 ] 

ASF subversion and git services commented on NIFI-2402:
---

Commit c26398eabae7f1c1ee5b489057b7924259c2d5e1 in nifi's branch 
refs/heads/master from [~mcgilman]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=c26398e ]

NIFI-2402: - Removing client side check component move eligibility and instead 
relaying on verification server side. Cannot check client side as the current 
user may not have permissions to inspect required fields.

This closes #750

Signed-off-by: jpercivall 


> UI - Update logic to verify if components are eligible for moving
> -
>
> Key: NIFI-2402
> URL: https://issues.apache.org/jira/browse/NIFI-2402
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.0.0
>
>
> The logic to check if components are eligible for moving is still outdated. 
> Need to update to invoke the refactored endpoints or remove the client side 
> check entirely and perform the strictly server side.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2402) UI - Update logic to verify if components are eligible for moving

[Joseph Percivall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joseph Percivall updated NIFI-2402:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> UI - Update logic to verify if components are eligible for moving
> -
>
> Key: NIFI-2402
> URL: https://issues.apache.org/jira/browse/NIFI-2402
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.0.0
>
>
> The logic to check if components are eligible for moving is still outdated. 
> Need to update to invoke the refactored endpoints or remove the client side 
> check entirely and perform the strictly server side.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #750: Removing client side check for component move eligib...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/750


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2402) UI - Update logic to verify if components are eligible for moving

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406816#comment-15406816
 ] 

ASF GitHub Bot commented on NIFI-2402:
--

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/750


> UI - Update logic to verify if components are eligible for moving
> -
>
> Key: NIFI-2402
> URL: https://issues.apache.org/jira/browse/NIFI-2402
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.0.0
>
>
> The logic to check if components are eligible for moving is still outdated. 
> Need to update to invoke the refactored endpoints or remove the client side 
> check entirely and perform the strictly server side.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2476) Further refine tls-toolkit based on feedback gathered during beta

[Andy LoPresto (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406813#comment-15406813
 ] 

Andy LoPresto commented on NIFI-2476:
-

Some of the issues to be addressed:
* Evaluate current structure of class hierarchy
* Add Javadoc to public methods
* Populate cluster properties if multiple nodes are configured in standalone 
mode
* Improve error messaging/input validation
* Improve logging


> Further refine tls-toolkit based on feedback gathered during beta
> -
>
> Key: NIFI-2476
> URL: https://issues.apache.org/jira/browse/NIFI-2476
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Rosander
>
> The basic functionality of generating keystores, truststores, 
> nifi.properties, and a configuration json is implemented.
> As people start using this tool to ease the tls setup process in NiFi, 
> shortcomings in the initial implementation will need to be addressed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2466) SSLContextService should support specifying Key Password

[Andy LoPresto (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy LoPresto updated NIFI-2466:

Resolution: Fixed
Status: Resolved  (was: Patch Available)

Resolved by commit 13ad765 [1]. 

[1] 
https://github.com/apache/nifi/commit/83a23f90d46201d63593f13ea4be4d88013ad765 

> SSLContextService should support specifying Key Password
> 
>
> Key: NIFI-2466
> URL: https://issues.apache.org/jira/browse/NIFI-2466
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Mark Payne
>Assignee: Mark Payne
> Fix For: 1.0.0
>
>
> Currently, the SSLContextService supports only a keystore password and 
> assumes that the key password is the same. We should support setting a 
> separate password for the key itself.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2466) SSLContextService should support specifying Key Password

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406768#comment-15406768
 ] 

ASF subversion and git services commented on NIFI-2466:
---

Commit 83a23f90d46201d63593f13ea4be4d88013ad765 in nifi's branch 
refs/heads/master from [~markap14]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=83a23f9 ]

NIFI-2466: Added option to provide separate key password to 
StandardSSLContextService.

Fixed NPE (+2 squashed commits)
Squashed commits:
[c5d521a] NIFI-2466: Added unit test to verify changes; fixed validation
[aa4d418] NIFI-2446: Add option to specify key password when different than 
keystore password

This closes #776.

Signed-off-by: Andy LoPresto 


> SSLContextService should support specifying Key Password
> 
>
> Key: NIFI-2466
> URL: https://issues.apache.org/jira/browse/NIFI-2466
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Mark Payne
>Assignee: Mark Payne
> Fix For: 1.0.0
>
>
> Currently, the SSLContextService supports only a keystore password and 
> assumes that the key password is the same. We should support setting a 
> separate password for the key itself.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2466) SSLContextService should support specifying Key Password

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406771#comment-15406771
 ] 

ASF GitHub Bot commented on NIFI-2466:
--

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/776


> SSLContextService should support specifying Key Password
> 
>
> Key: NIFI-2466
> URL: https://issues.apache.org/jira/browse/NIFI-2466
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Mark Payne
>Assignee: Mark Payne
> Fix For: 1.0.0
>
>
> Currently, the SSLContextService supports only a keystore password and 
> assumes that the key password is the same. We should support setting a 
> separate password for the key itself.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2446) Component Summary - Cluster breakdown

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406770#comment-15406770
 ] 

ASF subversion and git services commented on NIFI-2446:
---

Commit 83a23f90d46201d63593f13ea4be4d88013ad765 in nifi's branch 
refs/heads/master from [~markap14]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=83a23f9 ]

NIFI-2466: Added option to provide separate key password to 
StandardSSLContextService.

Fixed NPE (+2 squashed commits)
Squashed commits:
[c5d521a] NIFI-2466: Added unit test to verify changes; fixed validation
[aa4d418] NIFI-2446: Add option to specify key password when different than 
keystore password

This closes #776.

Signed-off-by: Andy LoPresto 


> Component Summary - Cluster breakdown
> -
>
> Key: NIFI-2446
> URL: https://issues.apache.org/jira/browse/NIFI-2446
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Matt Gilman
>Priority: Minor
> Fix For: 1.1.0
>
>
> The component specific cluster summary breakdown needs minor refreshing.
> - Remove old icons and replace with current versions
> - Address style issues where there is too much spacing between the header and 
> the table



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #776: NIFI-2466: Add option to specify key password when d...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/776


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-1876) Clustering - Merge all responses based on authorization

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406748#comment-15406748
 ] 

ASF GitHub Bot commented on NIFI-1876:
--

Github user jtstorck commented on the issue:

https://github.com/apache/nifi/pull/694
  
Resolved conflicts to StandardNifiServiceFacade.java.  Ready for review.


> Clustering - Merge all responses based on authorization
> ---
>
> Key: NIFI-1876
> URL: https://issues.apache.org/jira/browse/NIFI-1876
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Jeff Storck
> Fix For: 1.0.0
>
>
> Each node in a cluster may have a different view of the authorization access 
> policies simply to in the timing of updates. Because of this, all requests 
> need to be merged accordingly.
> Requests are directed at a specific resource. These would result in some 403 
> responses.
> Some requests are contain a filtered view of a number of resources. These 
> would need to be updated to return the most restrictive set of responses.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2476) Further refine tls-toolkit based on feedback gathered during beta

[Bryan Rosander (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Rosander updated NIFI-2476:
-
Summary: Further refine tls-toolkit based on feedback gathered during beta  
(was: Further refine NiFi tls-toolkit based on feedback gathered during beta)

> Further refine tls-toolkit based on feedback gathered during beta
> -
>
> Key: NIFI-2476
> URL: https://issues.apache.org/jira/browse/NIFI-2476
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Rosander
>
> The basic functionality of generating keystores, truststores, 
> nifi.properties, and a configuration json is implemented.
> As people start using this tool to ease the tls setup process in NiFi, 
> shortcomings in the initial implementation will need to be addressed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (NIFI-2476) Further refine NiFi tls-toolkit based on feedback gathered during beta

[Bryan Rosander (JIRA)]

Bryan Rosander created NIFI-2476:


 Summary: Further refine NiFi tls-toolkit based on feedback 
gathered during beta
 Key: NIFI-2476
 URL: https://issues.apache.org/jira/browse/NIFI-2476
 Project: Apache NiFi
  Issue Type: Improvement
Reporter: Bryan Rosander


The basic functionality of generating keystores, truststores, nifi.properties, 
and a configuration json is implemented.

As people start using this tool to ease the tls setup process in NiFi, 
shortcomings in the initial implementation will need to be addressed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #694: NIFI-1876 Implements merging of responses to successful req...

[jtstorck]

Github user jtstorck commented on the issue:

https://github.com/apache/nifi/pull/694
  
After doing some investigation, I saw that the FlowMerger wasn't merging 
labels or funnels, it was just picking the first instance of the component from 
each node.  I added the use of the mergers for labels and funnels to the 
FlowMerger and tested on a three-node cluster, and the merging looks good now.  
With one node denying the read permissions on labels and funnels, the UI is 
correctly disabling them.  Ready for review.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2301) Remove policy when component is deleted

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406718#comment-15406718
 ] 

ASF GitHub Bot commented on NIFI-2301:
--

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/757


> Remove policy when component is deleted
> ---
>
> Key: NIFI-2301
> URL: https://issues.apache.org/jira/browse/NIFI-2301
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.0.0
>
>
> When a component is removed, we need to also remove any associated policies. 
> Otherwise, the policies will continue to grow unboundedly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #757: Ensuring all component specific policies are removed...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/757


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi issue #757: Ensuring all component specific policies are removed when t...

[JPercivall]

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/757
  
+1

Visually verified code and did a contrib check build. In a 3 node secure 
cluster tried adding and modifying policies for every component and then 
deleting each. Saw policies removed as components were deleted as expected. 
Thanks @mcgilman, I will merge it in.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (NIFI-2475) UI - Update Policy page for adminstrators

[Matt Gilman (JIRA)]

Matt Gilman created NIFI-2475:
-

 Summary: UI - Update Policy page for adminstrators
 Key: NIFI-2475
 URL: https://issues.apache.org/jira/browse/NIFI-2475
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Core UI
Reporter: Matt Gilman
Assignee: Matt Gilman
Priority: Blocker
 Fix For: 1.0.0


We need to update the Policy page to make it more clear that when updating the 
list of users who can view or modify the policies of a component, we are 
appending to the list of administrators not overriding it.

This needs to be made obvious as it is different behavior then updating the 
list of users who can view or modify a component as these policies override the 
otherwise inherited policies.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2468) Address inconsistent placement of action buttons above tables; minor style edits

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406635#comment-15406635
 ] 

ASF GitHub Bot commented on NIFI-2468:
--

GitHub user scottyaslan opened a pull request:

https://github.com/apache/nifi/pull/781

[NIFI-2468] addressing some inconsistencies



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/scottyaslan/nifi devBranch

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/781.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #781






> Address inconsistent placement of action buttons above tables; minor style 
> edits
> 
>
> Key: NIFI-2468
> URL: https://issues.apache.org/jira/browse/NIFI-2468
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Rob Moran
>Assignee: Scott Aslan
>
> Use the current Data Provenance table as a model:
> * The inputs (Filter, filter type combo) sit directly on top of the table 
> header (no space between them and the table)
> * The search button sits 4px above the table
> If there are multiple buttons (e.g., in Flow History shell), separate by 2px 
> like buttons in the Navigate and Operate palettes
> OTHER RELATED NOTES
> Configure Processor > Properties tab – Add button icon sits higher (within 
> the button); it is not vertically centered like others
> Controller Service, Reporting Task Add buttons are above the tabs. They 
> should sit above the corresponding table like all others.
> MISC STYLE EDITS
> .combo-text {
> ADD font-weight: normal;
> #general-process-group-configuration input, 
> #general-process-group-configuration textarea {
> REMOVE font-size: 11px!important;
> REMOVE font-family: Verdana;
> #general-settings input {
> REMOVE font-size: 11px!important;
> REMOVE font-family: Verdana;
> All input 'placeholder's should consistently use color:#728E9B
> #settings-last-refreshed {
> CHANGE font-weight: 500;
> .setting-field {
> ADD font-weight: 500;
> .setting-name
> ADD text-transform: capitalize;
> Still seeing some instances where values (color:#775351) are either normal or 
> bold in weight
> * All values should be font-weight:500;



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (NIFI-2474) TestRunner should not expose a VariableRegistry construct

[Mark Payne (JIRA)]

Mark Payne created NIFI-2474:


 Summary: TestRunner should not expose a VariableRegistry construct
 Key: NIFI-2474
 URL: https://issues.apache.org/jira/browse/NIFI-2474
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Tools and Build
Reporter: Mark Payne
 Fix For: 1.0.0


Currently, the TestRunners class provides a mechanism for creating a TestRunner 
that takes in a Variable Registry. The concept of providing variables to the 
Test Runner is very valuable. However, the notion of the VariableRegistry is an 
internal implementation detail that is getting exposed, creating a leaky 
abstraction.

We should remove the override of the createTestRunner() method that takes the 
Variable Registry and instead expose a set of methods of TestRunner:

void setVariable(String name, String value)
String getVariable(String name)
void setVariables(Map variables)
Map getVariables()

Additionally, as-is, if no VariableRegistry is provided, the default is to use 
a Variable Registry that provides System and Environment variables. This should 
be avoided, as it encourages unit tests to depend on environment-specific 
settings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (NIFI-2473) UX regarding deleting components and connections regressed unintentionally

[Joseph Percivall (JIRA)]

Joseph Percivall created NIFI-2473:
--

 Summary: UX regarding deleting components and connections 
regressed unintentionally
 Key: NIFI-2473
 URL: https://issues.apache.org/jira/browse/NIFI-2473
 Project: Apache NiFi
  Issue Type: Bug
Reporter: Joseph Percivall
 Fix For: 1.0.0


Currently in master each of these fail but succeed in 0.x (connection is coming 
from the destination and is connected to the source):

destination and connection selected, attempt to delete
source and connection selected, attempt to delete
source and destination selected, attempt to delete

I believe this is due to the connection being "connected" to a component 
outside of the snippet and in the third case, the components being "connected" 
to the connection (which is outside the snippet).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #778: NIFI-2407 Implements EL support on some properties o...

[markap14]

Github user markap14 commented on a diff in the pull request:

https://github.com/apache/nifi/pull/778#discussion_r73416186
  
--- Diff: 
nifi-nar-bundles/nifi-standard-services/nifi-dbcp-service-bundle/nifi-dbcp-service/src/test/java/org/apache/nifi/dbcp/DBCPServiceTest.java
 ---
@@ -258,6 +264,28 @@ public void testURLClassLoaderGetConnection() throws 
ClassNotFoundException, Mal
 DriverManager.deregisterDriver(shim);
 }
 
+@Test
+public void testPropertiesUseVariableRegistry() throws 
InitializationException, SQLException {
+final VariableRegistry variableRegistry = 
mock(VariableRegistry.class);
+
given(variableRegistry.getVariableValue("databaseurl")).willReturn("jdbc:derby:"
 + DB_LOCATION + ";create=true");
+
given(variableRegistry.getVariableValue("drivername")).willReturn("org.apache.derby.jdbc.EmbeddedDriver");
+
given(variableRegistry.getVariableValue("username")).willReturn("tester");
+
given(variableRegistry.getVariableValue("password")).willReturn("testerp");
+
+final TestRunner runner = 
TestRunners.newTestRunner(mock(org.apache.nifi.processor.Processor.class), 
variableRegistry);
+final DBCPConnectionPool service = new DBCPConnectionPool();
+runner.addControllerService("dbcpService", service);
+
+runner.setProperty(service, DBCPConnectionPool.DATABASE_URL, 
"${databaseurl}");
+runner.setProperty(service, DBCPConnectionPool.DB_DRIVERNAME, 
"${drivername}");
+runner.setProperty(service, DBCPConnectionPool.DB_USER, 
"${username}");
+runner.setProperty(service, DBCPConnectionPool.DB_PASSWORD, 
"${password}");
+
+runner.enableControllerService(service);
+
+
then(variableRegistry).should(times(4)).getVariableValue(anyString());
--- End diff --

This feels brittle. The controller service being tested does not call into 
the variable registry - it simply calls evaluateAttributeExpressions(). So 
verifying that the mock framework calls into the variable registry 4 times is 
really testing the mock framework moreso than the Controller Service. The 
Controller Service (or mock framework) could certainly be changed so that they 
call getVariableValue() many more times without any change in functionality, as 
well.

I think a better test would be to ensure that each time that the property's 
value is obtained, the EL is first evaluated. This is already done by the mock 
framework - if the PropertyDescriptor indicates that it supports expression 
language but getValue() is called on the PropertyValue without first calling 
evaluateAttributeExpressions(), the mock framework calls Assert.fail()


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request #780: NIFI-2435 - Wrapping reader call in doAs if necessar...

[brosander]

GitHub user brosander opened a pull request:

https://github.com/apache/nifi/pull/780

NIFI-2435 - Wrapping reader call in doAs if necessary



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/brosander/nifi NIFI-2435-master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/780.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #780


commit 43a26698f9941f0732315f3e36d1fd2d3393f0d1
Author: Bryan Rosander 
Date:   2016-08-03T18:02:52Z

NIFI-2435 - Wrapping reader call in doAs if necessary




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2237) REST API Documentation Updates

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406552#comment-15406552
 ] 

ASF subversion and git services commented on NIFI-2237:
---

Commit 9338f102cbfa681525cbf806ae71481944ac3516 in nifi's branch 
refs/heads/master from [~mcgilman]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=9338f10 ]

NIFI-2237:
- Updating Rest Endpoint documentation specifically regarding access policies.
- Ensuring the resource listing is accurate.
- Removing unnecessary code.


> REST API Documentation Updates
> --
>
> Key: NIFI-2237
> URL: https://issues.apache.org/jira/browse/NIFI-2237
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>Priority: Critical
> Fix For: 1.0.0
>
>
> - Ensure REST APi documentation is up to date.
> - Remove mention of deprecated user roles
> - Mark applicable endpoints with Yetus like descriptions according to 
> intent/stability/openness.
> - Ensure all fields are correctly marked as optional or not.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #757: Ensuring all component specific policies are removed when t...

[JPercivall]

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/757
  
@mcgilman I don't think the UI button to delete the CS/RT works properly. 
When I tried to use it when I had "write" but not "view" I saw a 405.

![screen shot 2016-08-03 at 4 17 16 
pm](https://cloud.githubusercontent.com/assets/11302527/17380576/c5e9329c-5995-11e6-818e-6956e28c7cee.png)



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2407) Add EL support to processors/controller services

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406546#comment-15406546
 ] 

ASF GitHub Bot commented on NIFI-2407:
--

Github user markap14 commented on a diff in the pull request:

https://github.com/apache/nifi/pull/778#discussion_r73411049
  
--- Diff: 
nifi-nar-bundles/nifi-hadoop-bundle/nifi-hdfs-processors/src/test/java/org/apache/nifi/processors/hadoop/PutHDFSTest.java
 ---
@@ -199,7 +202,39 @@ public void testPutFile() throws IOException {
 TestRunner runner = TestRunners.newTestRunner(proc);
 runner.setProperty(PutHDFS.DIRECTORY, "target/test-classes");
 runner.setProperty(PutHDFS.CONFLICT_RESOLUTION, "replace");
-runner.setValidateExpressionUsage(false);
+try (FileInputStream fis = new 
FileInputStream("src/test/resources/testdata/randombytes-1");) {
+Map attributes = new HashMap();
+attributes.put(CoreAttributes.FILENAME.key(), "randombytes-1");
+runner.enqueue(fis, attributes);
+runner.run();
+}
+
+Configuration config = new Configuration();
+FileSystem fs = FileSystem.get(config);
+
+List failedFlowFiles = runner
+.getFlowFilesForRelationship(new 
Relationship.Builder().name("failure").build());
+assertTrue(failedFlowFiles.isEmpty());
+
+List flowFiles = 
runner.getFlowFilesForRelationship(PutHDFS.REL_SUCCESS);
+assertEquals(1, flowFiles.size());
--- End diff --

The above assertion that failed flowfiles is empty and that this has size 1 
can be simplified to simply using:

runner.assertAllFlowFilesTransferred(PutHDFS.REL_SUCCESS, 1);


> Add EL support to processors/controller services
> 
>
> Key: NIFI-2407
> URL: https://issues.apache.org/jira/browse/NIFI-2407
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Jeff Storck
>Assignee: Jeff Storck
> Fix For: 1.0.0
>
>
> Add support for EL:
> * "Directory" property for GetHDFS and ListHDFS processors
> * "Destination Name" property for ConsumeJMS and PublishJMS processors
> * "MQ ConnectionFactory Implementation", "MQ client library path", "Broker 
> URI" properties for the JMS Connection Factory Provider
> * "Database Connection URL", "Database Driver Class Name", "DB Driver jar 
> url", "DB username", and "DB password" properties for the DBCP Connection Pool



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #778: NIFI-2407 Implements EL support on some properties o...

[markap14]

Github user markap14 commented on a diff in the pull request:

https://github.com/apache/nifi/pull/778#discussion_r73411049
  
--- Diff: 
nifi-nar-bundles/nifi-hadoop-bundle/nifi-hdfs-processors/src/test/java/org/apache/nifi/processors/hadoop/PutHDFSTest.java
 ---
@@ -199,7 +202,39 @@ public void testPutFile() throws IOException {
 TestRunner runner = TestRunners.newTestRunner(proc);
 runner.setProperty(PutHDFS.DIRECTORY, "target/test-classes");
 runner.setProperty(PutHDFS.CONFLICT_RESOLUTION, "replace");
-runner.setValidateExpressionUsage(false);
+try (FileInputStream fis = new 
FileInputStream("src/test/resources/testdata/randombytes-1");) {
+Map attributes = new HashMap();
+attributes.put(CoreAttributes.FILENAME.key(), "randombytes-1");
+runner.enqueue(fis, attributes);
+runner.run();
+}
+
+Configuration config = new Configuration();
+FileSystem fs = FileSystem.get(config);
+
+List failedFlowFiles = runner
+.getFlowFilesForRelationship(new 
Relationship.Builder().name("failure").build());
+assertTrue(failedFlowFiles.isEmpty());
+
+List flowFiles = 
runner.getFlowFilesForRelationship(PutHDFS.REL_SUCCESS);
+assertEquals(1, flowFiles.size());
--- End diff --

The above assertion that failed flowfiles is empty and that this has size 1 
can be simplified to simply using:

runner.assertAllFlowFilesTransferred(PutHDFS.REL_SUCCESS, 1);


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (NIFI-2471) Multiple Hadoop processors cannot point to different Hadoop clusters

[Michael Moser (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Moser updated NIFI-2471:

Status: Patch Available  (was: Open)

> Multiple Hadoop processors cannot point to different Hadoop clusters
> 
>
> Key: NIFI-2471
> URL: https://issues.apache.org/jira/browse/NIFI-2471
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 0.7.0
>Reporter: Michael Moser
>Assignee: Michael Moser
>Priority: Minor
> Fix For: 1.0.0, 0.8.0
>
>
> Two GetHDFS processors, each with different Hadoop Configuration Resources, 
> will only operate with one Hadoop cluster.  In this specific case, both 
> Hadoop clusters had the same HDFS system name.  The AbstractHadoopProcessor 
> disables caching of Configuration and FileSystem objects but it doesn't 
> appear to be working.
> Also, if I configure a GetHDFS processor to point to one Hadoop cluster, but 
> the processor is invalid because the Directory doesn't exist, the processor 
> doesn't start (that's good).  But if I change the Hadoop Configuration 
> Resources to point to a different Hadoop cluster where the Directory does 
> exist, then GetHDFS continues to talk to the first Hadoop cluster.  It seems 
> like the Configuration and FileSystem objects don't reset when I change the 
> Hadoop Configuration Resources property.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2466) SSLContextService should support specifying Key Password

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406534#comment-15406534
 ] 

ASF GitHub Bot commented on NIFI-2466:
--

Github user markap14 commented on the issue:

https://github.com/apache/nifi/pull/776
  
@alopresto sorry about that NPE - i had a typo where i referenced the 
configContext instead of validation context. The config context isn't 
guaranteed to be set when customValidate is called. Pushed a new commit for 
that.


> SSLContextService should support specifying Key Password
> 
>
> Key: NIFI-2466
> URL: https://issues.apache.org/jira/browse/NIFI-2466
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Mark Payne
>Assignee: Mark Payne
> Fix For: 1.0.0
>
>
> Currently, the SSLContextService supports only a keystore password and 
> assumes that the key password is the same. We should support setting a 
> separate password for the key itself.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2471) Multiple Hadoop processors cannot point to different Hadoop clusters

[Michael Moser (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Moser updated NIFI-2471:

Fix Version/s: 0.8.0
   1.0.0

> Multiple Hadoop processors cannot point to different Hadoop clusters
> 
>
> Key: NIFI-2471
> URL: https://issues.apache.org/jira/browse/NIFI-2471
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 0.7.0
>Reporter: Michael Moser
>Assignee: Michael Moser
>Priority: Minor
> Fix For: 1.0.0, 0.8.0
>
>
> Two GetHDFS processors, each with different Hadoop Configuration Resources, 
> will only operate with one Hadoop cluster.  In this specific case, both 
> Hadoop clusters had the same HDFS system name.  The AbstractHadoopProcessor 
> disables caching of Configuration and FileSystem objects but it doesn't 
> appear to be working.
> Also, if I configure a GetHDFS processor to point to one Hadoop cluster, but 
> the processor is invalid because the Directory doesn't exist, the processor 
> doesn't start (that's good).  But if I change the Hadoop Configuration 
> Resources to point to a different Hadoop cluster where the Directory does 
> exist, then GetHDFS continues to talk to the first Hadoop cluster.  It seems 
> like the Configuration and FileSystem objects don't reset when I change the 
> Hadoop Configuration Resources property.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #779: NIFI-2471 fix Hadoop configuration resources when ta...

[mosermw]

GitHub user mosermw opened a pull request:

https://github.com/apache/nifi/pull/779

NIFI-2471 fix Hadoop configuration resources when talking to ...

…multiple Hadoop clusters

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mosermw/nifi NIFI-2471

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/779.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #779


commit 873a7a747070284dbd72eaba49b5bc388c1c7a77
Author: Mike Moser 
Date:   2016-08-03T19:58:57Z

NIFIDEV-2471 fix Hadoop configuration resources when talking to multiple 
Hadoop clusters




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi issue #776: NIFI-2466: Add option to specify key password when differen...

[markap14]

Github user markap14 commented on the issue:

https://github.com/apache/nifi/pull/776
  
@alopresto sorry about that NPE - i had a typo where i referenced the 
configContext instead of validation context. The config context isn't 
guaranteed to be set when customValidate is called. Pushed a new commit for 
that.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request #755: Update REST endpoint documentation

[mcgilman]

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/755#discussion_r73408766
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/api/ProvenanceResource.java
 ---
@@ -181,15 +179,15 @@ public Response getSearchOptions() {
 + "should be deleted by the client who originally 
submitted it.",
 response = ProvenanceEntity.class,
 authorizations = {
-@Authorization(value = "Provenance", type = 
"ROLE_PROVENANCE")
+@Authorization(value = "Read - /provenance", type = "")
--- End diff --

Yes it should. Thanks.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi issue #755: Update REST endpoint documentation

[bbende]

Github user bbende commented on the issue:

https://github.com/apache/nifi/pull/755
  
I'm a +1 once the comments above are addressed, let me know if you want me 
to merge it in after you make any updates


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (NIFI-2472) Copy and Pasting groups of components repositions them erratically

[Joseph Percivall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joseph Percivall updated NIFI-2472:
---
Attachment: Screen Shot 2016-08-03 at 3.49.01 PM.png

Before and after screenshots attached

> Copy and Pasting groups of components repositions them erratically
> --
>
> Key: NIFI-2472
> URL: https://issues.apache.org/jira/browse/NIFI-2472
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Joseph Percivall
> Fix For: 1.0.0
>
> Attachments: Screen Shot 2016-08-03 at 3.48.42 PM.png, Screen Shot 
> 2016-08-03 at 3.49.01 PM.png
>
>
> Currently when you copy and paste a group of components the components don't 
> paste where you would expect. One thought is that some components in the 
> copy/paste are having the 0.x template scaling logic applied.
> I will attach screenshots to demonstrate.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2472) Copy and Pasting groups of components repositions them erratically

[Joseph Percivall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joseph Percivall updated NIFI-2472:
---
Attachment: Screen Shot 2016-08-03 at 3.48.42 PM.png

> Copy and Pasting groups of components repositions them erratically
> --
>
> Key: NIFI-2472
> URL: https://issues.apache.org/jira/browse/NIFI-2472
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Joseph Percivall
> Fix For: 1.0.0
>
> Attachments: Screen Shot 2016-08-03 at 3.48.42 PM.png
>
>
> Currently when you copy and paste a group of components the components don't 
> paste where you would expect. One thought is that some components in the 
> copy/paste are having the 0.x template scaling logic applied.
> I will attach screenshots to demonstrate.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2407) Add EL support to processors/controller services

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406493#comment-15406493
 ] 

ASF GitHub Bot commented on NIFI-2407:
--

Github user markap14 commented on a diff in the pull request:

https://github.com/apache/nifi/pull/778#discussion_r73406263
  
--- Diff: 
nifi-nar-bundles/nifi-hadoop-bundle/nifi-hdfs-processors/src/main/java/org/apache/nifi/processors/hadoop/AbstractHadoopProcessor.java
 ---
@@ -191,9 +191,19 @@ public final void abstractOnScheduled(ProcessContext 
context) throws IOException
 HdfsResources resources = hdfsResources.get();
 if (resources.getConfiguration() == null) {
 String configResources = 
context.getProperty(HADOOP_CONFIGURATION_RESOURCES).getValue();
-String dir = 
context.getProperty(DIRECTORY_PROP_NAME).getValue();
-dir = dir == null ? "/" : dir;
-resources = resetHDFSResources(configResources, dir, 
context);
+final String dir;
+final PropertyDescriptor directoryPropDescriptor = 
context.getProperties().keySet().stream()
--- End diff --

@jtstorck I think this can be made a lot simpler by simply calling 
getPropertyDescriptor(DIRECTORY_PROP_NAME) of the AbstractProcessor super 
class, no?


> Add EL support to processors/controller services
> 
>
> Key: NIFI-2407
> URL: https://issues.apache.org/jira/browse/NIFI-2407
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Jeff Storck
>Assignee: Jeff Storck
> Fix For: 1.0.0
>
>
> Add support for EL:
> * "Directory" property for GetHDFS and ListHDFS processors
> * "Destination Name" property for ConsumeJMS and PublishJMS processors
> * "MQ ConnectionFactory Implementation", "MQ client library path", "Broker 
> URI" properties for the JMS Connection Factory Provider
> * "Database Connection URL", "Database Driver Class Name", "DB Driver jar 
> url", "DB username", and "DB password" properties for the DBCP Connection Pool



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #778: NIFI-2407 Implements EL support on some properties o...

[markap14]

Github user markap14 commented on a diff in the pull request:

https://github.com/apache/nifi/pull/778#discussion_r73406263
  
--- Diff: 
nifi-nar-bundles/nifi-hadoop-bundle/nifi-hdfs-processors/src/main/java/org/apache/nifi/processors/hadoop/AbstractHadoopProcessor.java
 ---
@@ -191,9 +191,19 @@ public final void abstractOnScheduled(ProcessContext 
context) throws IOException
 HdfsResources resources = hdfsResources.get();
 if (resources.getConfiguration() == null) {
 String configResources = 
context.getProperty(HADOOP_CONFIGURATION_RESOURCES).getValue();
-String dir = 
context.getProperty(DIRECTORY_PROP_NAME).getValue();
-dir = dir == null ? "/" : dir;
-resources = resetHDFSResources(configResources, dir, 
context);
+final String dir;
+final PropertyDescriptor directoryPropDescriptor = 
context.getProperties().keySet().stream()
--- End diff --

@jtstorck I think this can be made a lot simpler by simply calling 
getPropertyDescriptor(DIRECTORY_PROP_NAME) of the AbstractProcessor super 
class, no?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2407) Add EL support to processors/controller services

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406491#comment-15406491
 ] 

ASF GitHub Bot commented on NIFI-2407:
--

Github user brosander commented on a diff in the pull request:

https://github.com/apache/nifi/pull/778#discussion_r73405976
  
--- Diff: 
nifi-nar-bundles/nifi-hadoop-bundle/nifi-hdfs-processors/src/main/java/org/apache/nifi/processors/hadoop/AbstractHadoopProcessor.java
 ---
@@ -191,9 +191,19 @@ public final void abstractOnScheduled(ProcessContext 
context) throws IOException
 HdfsResources resources = hdfsResources.get();
 if (resources.getConfiguration() == null) {
 String configResources = 
context.getProperty(HADOOP_CONFIGURATION_RESOURCES).getValue();
-String dir = 
context.getProperty(DIRECTORY_PROP_NAME).getValue();
-dir = dir == null ? "/" : dir;
-resources = resetHDFSResources(configResources, dir, 
context);
+final String dir;
+final PropertyDescriptor directoryPropDescriptor = 
context.getProperties().keySet().stream()
--- End diff --

Why replace a (fast) map lookup with an iteration over all keys?


> Add EL support to processors/controller services
> 
>
> Key: NIFI-2407
> URL: https://issues.apache.org/jira/browse/NIFI-2407
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Jeff Storck
>Assignee: Jeff Storck
> Fix For: 1.0.0
>
>
> Add support for EL:
> * "Directory" property for GetHDFS and ListHDFS processors
> * "Destination Name" property for ConsumeJMS and PublishJMS processors
> * "MQ ConnectionFactory Implementation", "MQ client library path", "Broker 
> URI" properties for the JMS Connection Factory Provider
> * "Database Connection URL", "Database Driver Class Name", "DB Driver jar 
> url", "DB username", and "DB password" properties for the DBCP Connection Pool



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #778: NIFI-2407 Implements EL support on some properties o...

[brosander]

Github user brosander commented on a diff in the pull request:

https://github.com/apache/nifi/pull/778#discussion_r73405976
  
--- Diff: 
nifi-nar-bundles/nifi-hadoop-bundle/nifi-hdfs-processors/src/main/java/org/apache/nifi/processors/hadoop/AbstractHadoopProcessor.java
 ---
@@ -191,9 +191,19 @@ public final void abstractOnScheduled(ProcessContext 
context) throws IOException
 HdfsResources resources = hdfsResources.get();
 if (resources.getConfiguration() == null) {
 String configResources = 
context.getProperty(HADOOP_CONFIGURATION_RESOURCES).getValue();
-String dir = 
context.getProperty(DIRECTORY_PROP_NAME).getValue();
-dir = dir == null ? "/" : dir;
-resources = resetHDFSResources(configResources, dir, 
context);
+final String dir;
+final PropertyDescriptor directoryPropDescriptor = 
context.getProperties().keySet().stream()
--- End diff --

Why replace a (fast) map lookup with an iteration over all keys?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request #755: Update REST endpoint documentation

[bbende]

Github user bbende commented on a diff in the pull request:

https://github.com/apache/nifi/pull/755#discussion_r73405602
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/api/ProvenanceResource.java
 ---
@@ -181,15 +179,15 @@ public Response getSearchOptions() {
 + "should be deleted by the client who originally 
submitted it.",
 response = ProvenanceEntity.class,
 authorizations = {
-@Authorization(value = "Provenance", type = 
"ROLE_PROVENANCE")
+@Authorization(value = "Read - /provenance", type = "")
--- End diff --

Should this also document that it needs READ for each data event?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (NIFI-2471) Multiple Hadoop processors cannot point to different Hadoop clusters

[Michael Moser (JIRA)]

Michael Moser created NIFI-2471:
---

 Summary: Multiple Hadoop processors cannot point to different 
Hadoop clusters
 Key: NIFI-2471
 URL: https://issues.apache.org/jira/browse/NIFI-2471
 Project: Apache NiFi
  Issue Type: Bug
  Components: Extensions
Affects Versions: 0.7.0
Reporter: Michael Moser
Assignee: Michael Moser
Priority: Minor


Two GetHDFS processors, each with different Hadoop Configuration Resources, 
will only operate with one Hadoop cluster.  In this specific case, both Hadoop 
clusters had the same HDFS system name.  The AbstractHadoopProcessor disables 
caching of Configuration and FileSystem objects but it doesn't appear to be 
working.

Also, if I configure a GetHDFS processor to point to one Hadoop cluster, but 
the processor is invalid because the Directory doesn't exist, the processor 
doesn't start (that's good).  But if I change the Hadoop Configuration 
Resources to point to a different Hadoop cluster where the Directory does 
exist, then GetHDFS continues to talk to the first Hadoop cluster.  It seems 
like the Configuration and FileSystem objects don't reset when I change the 
Hadoop Configuration Resources property.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-1868) Add support for Hive Streaming

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406469#comment-15406469
 ] 

ASF GitHub Bot commented on NIFI-1868:
--

Github user mattyb149 commented on the issue:

https://github.com/apache/nifi/pull/706
  
Yeah I think that's a bug in this version of Hive: 
https://issues.apache.org/jira/browse/HIVE-13725

For now I'd like to make the processor TriggerSerially (unless there are 
any objections), then when we upgrade the version of Hive we can revisit and 
hopefully remove this limitation.


> Add support for Hive Streaming
> --
>
> Key: NIFI-1868
> URL: https://issues.apache.org/jira/browse/NIFI-1868
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Matt Burgess
>Assignee: Matt Burgess
> Fix For: 1.0.0
>
>
> Traditionally adding new data into Hive requires gathering a large amount of 
> data onto HDFS and then periodically adding a new partition. This is 
> essentially a “batch insertion”. Insertion of new data into an existing 
> partition is not permitted. Hive Streaming API allows data to be pumped 
> continuously into Hive. The incoming data can be continuously committed in 
> small batches of records into an existing Hive partition or table. Once data 
> is committed it becomes immediately visible to all Hive queries initiated 
> subsequently.
> This case is to add a PutHiveStreaming processor to NiFi, to leverage the 
> Hive Streaming API to allow continuous streaming of data into a Hive 
> partition/table.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #706: NIFI-1868: Add PutHiveStreaming processor

[mattyb149]

Github user mattyb149 commented on the issue:

https://github.com/apache/nifi/pull/706
  
Yeah I think that's a bug in this version of Hive: 
https://issues.apache.org/jira/browse/HIVE-13725

For now I'd like to make the processor TriggerSerially (unless there are 
any objections), then when we upgrade the version of Hive we can revisit and 
hopefully remove this limitation.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2458) After canceling provenance query, cannot submit a new one

[Mark Payne (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406453#comment-15406453
 ] 

Mark Payne commented on NIFI-2458:
--

So the interesting bit here is that we have optimized the query so that it 
already just holds the last 1000 events or so in memory and it just immediately 
returns those. Typically what I see is that the majority of the time spent on 
that initial query is the network traffic of pulling those events back. There 
is a JIRA (https://issues.apache.org/jira/browse/NIFI-1135) that addresses this 
by pulling back 'summaries' of the events (only those things shown in the 
table) instead of the entire events, which include all attributes, etc. of each 
event. That is slated for 1.1.0 and I think will make this significantly better.


> After canceling provenance query, cannot submit a new one
> -
>
> Key: NIFI-2458
> URL: https://issues.apache.org/jira/browse/NIFI-2458
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Mark Payne
>Assignee: Joseph Witt
> Fix For: 1.0.0
>
>
> I right-clicked on a Processor and choose to view provenance events. I then 
> clicked Cancel on the progress bar dialog. I then clicked 'search' and added 
> a new parameter to the search (added a value for 'Relationship'). When I 
> click Search, I get an error message: Message body is malformed. Unable to 
> map into expected format.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #755: Update REST endpoint documentation

[mcgilman]

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/755#discussion_r73401344
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/api/ProcessGroupResource.java
 ---
@@ -1470,42 +1437,41 @@ public Response getRemoteProcessGroups(
  * Creates a new connection.
  *
  * @param httpServletRequest request
- * @param groupId The group id
- * @param connectionEntity A connectionEntity.
+ * @param groupIdThe group id
+ * @param connectionEntity   A connectionEntity.
  * @return A connectionEntity.
  */
 @POST
 @Consumes(MediaType.APPLICATION_JSON)
 @Produces(MediaType.APPLICATION_JSON)
 @Path("{id}/connections")
-// TODO - @PreAuthorize("hasRole('ROLE_DFM')")
 @ApiOperation(
-value = "Creates a connection",
-response = ConnectionEntity.class,
-authorizations = {
-@Authorization(value = "Data Flow Manager", type = "ROLE_DFM")
-}
+value = "Creates a connection",
+response = ConnectionEntity.class,
+authorizations = {
+@Authorization(value = "Write - 
/process-groups/{uuid}", type = "")
--- End diff --

Yep, good call.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (NIFI-2391) Add toString() implementation to ComponentDTO

[Mark Payne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Payne updated NIFI-2391:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Add toString() implementation to ComponentDTO
> -
>
> Key: NIFI-2391
> URL: https://issues.apache.org/jira/browse/NIFI-2391
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core Framework
>Reporter: Oleg Zhurakousky
>Assignee: Oleg Zhurakousky
> Fix For: 1.0.0
>
>
> While working on deterministic templates and some of the follow up issues 
> after it makes it increasingly difficult to debug without more informative 
> toString implementation. 
> For now I'll go with "[Simple Class Name]:[Component ID] scheme. For example:
> {code}
> ProcessorDTO:59595eb1-7296-4db1-bb06-012705f5a698
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #755: Update REST endpoint documentation

[mcgilman]

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/755#discussion_r73401076
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/api/AccessResource.java
 ---
@@ -111,7 +111,7 @@
  * Authorizes access to the flow.
  */
 private boolean hasFlowAccess(final NiFiUser user) {
-final Map userContext;
+final Map userContext;
--- End diff --

Yep, removing...


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request #755: Update REST endpoint documentation

[mcgilman]

Github user mcgilman commented on a diff in the pull request:

https://github.com/apache/nifi/pull/755#discussion_r73401024
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/api/AccessPolicyResource.java
 ---
@@ -102,14 +102,18 @@ public AccessPolicyEntity 
populateRemainingAccessPolicyEntityContent(AccessPolic
 @Consumes(MediaType.WILDCARD)
 @Produces(MediaType.APPLICATION_JSON)
 @Path("{action}/{resource: .+}")
-// TODO - @PreAuthorize("hasAnyRole('ROLE_MONITOR', 'ROLE_DFM', 
'ROLE_ADMIN')")
 @ApiOperation(
-value = "Gets an access policy",
+value = "Gets an access policy for the specified action and 
resource",
+notes = "Will return the effective policy if no component 
specific policy exists for the specified action and resource. "
++ "Must have Read permissions to the policy with the 
desired action and resource. Permissions for the policy that is "
++ "returned will be indicated in the response. This 
means the client could be authorized to get the policy for a "
++ "given component but the effective policy may be 
inherited from an ancestor Process Group. If the client does not "
++ "have permissions to that policy, the response will 
not include the policy and the permissions in the response "
++ "will be marked accordingly. If the client does not 
have permissions to the policy of the desired action and resource "
++ "a 403 response will be returned.",
 response = AccessPolicyEntity.class,
 authorizations = {
-@Authorization(value = "Read Only", type = 
"ROLE_MONITOR"),
-@Authorization(value = "Data Flow Manager", type = 
"ROLE_DFM"),
-@Authorization(value = "Administrator", type = 
"ROLE_ADMIN")
+@Authorization(value = "Read - 
/policies/{action}/{resource}", type = "")
--- End diff --

Yep, good call.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2291) Site-to-Site Provenance Reporting Task showing wrong content URI

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406434#comment-15406434
 ] 

ASF GitHub Bot commented on NIFI-2291:
--

Github user markap14 commented on the issue:

https://github.com/apache/nifi/pull/752
  
Excellent, thanks, @YolandaMDavis ! Congratulations of your first merge :)


> Site-to-Site Provenance Reporting Task showing wrong content URI
> 
>
> Key: NIFI-2291
> URL: https://issues.apache.org/jira/browse/NIFI-2291
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Mark Payne
>Assignee: Mark Payne
> Fix For: 1.0.0
>
>
> I'm seeing the following JSON provided by the reporting task:
> {"eventId":"056aaf5c-476b-48fb-a252-55f9c6f42287",
> "eventOrdinal":113158283,
> "eventType":"ATTRIBUTES_MODIFIED",
> "timestampMillis":1468719367054,
> "timestamp":"2016-07-17T01:36:07.054Z",
> "durationMillis":-1,
> "lineageStart":146871866,
> "componentId":"f1550b29-5823-31c0-801d-d95770828ca9",
> "componentType":"UpdateAttribute",
> "componentName":"UpdateAttribute",
> "entityId":"14d23482-e2e6-4740-af6a-31059134feef",
> "entityType":"org.apache.nifi.flowfile.FlowFile",
> "entitySize":1431,
> "previousEntitySize":1431,
> "updatedAttributes":{},
> "previousAttributes":{"path":"./","execution.command":"python","filename":"5285482415879175","execution.command.args":"-m
>  
> json.tool","execution.status":"0","reporting.task.transaction.id":"a3528aa7-674b-4de1-a65c-61ff0b094eac","execution.error":"","uuid":"14d23482-e2e6-4740-af6a-31059134feef"},
> "actorHostname":"nifi-02",
> "contentURI":"http:/-02:8080/nifi-api/controller/provenance/events/113158283/content/output",
> "previousContentURI":"http:/-02:8080/nifi-api/controller/provenance/events/113158283/content/input",
> "parentIds":[],
> "childIds":[],
> "platform":"nifi",
> "application":"NiFi Flow"}
> It appears that the "/nifi" is getting removed from the content URI - I think 
> this has to do with the following block of code in the reporting task:
> `final String urlPrefix = nifiUrl.toString().replace(nifiUrl.getPath(), "");`



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2291) Site-to-Site Provenance Reporting Task showing wrong content URI

[Mark Payne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Payne updated NIFI-2291:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Site-to-Site Provenance Reporting Task showing wrong content URI
> 
>
> Key: NIFI-2291
> URL: https://issues.apache.org/jira/browse/NIFI-2291
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Mark Payne
>Assignee: Mark Payne
> Fix For: 1.0.0
>
>
> I'm seeing the following JSON provided by the reporting task:
> {"eventId":"056aaf5c-476b-48fb-a252-55f9c6f42287",
> "eventOrdinal":113158283,
> "eventType":"ATTRIBUTES_MODIFIED",
> "timestampMillis":1468719367054,
> "timestamp":"2016-07-17T01:36:07.054Z",
> "durationMillis":-1,
> "lineageStart":146871866,
> "componentId":"f1550b29-5823-31c0-801d-d95770828ca9",
> "componentType":"UpdateAttribute",
> "componentName":"UpdateAttribute",
> "entityId":"14d23482-e2e6-4740-af6a-31059134feef",
> "entityType":"org.apache.nifi.flowfile.FlowFile",
> "entitySize":1431,
> "previousEntitySize":1431,
> "updatedAttributes":{},
> "previousAttributes":{"path":"./","execution.command":"python","filename":"5285482415879175","execution.command.args":"-m
>  
> json.tool","execution.status":"0","reporting.task.transaction.id":"a3528aa7-674b-4de1-a65c-61ff0b094eac","execution.error":"","uuid":"14d23482-e2e6-4740-af6a-31059134feef"},
> "actorHostname":"nifi-02",
> "contentURI":"http:/-02:8080/nifi-api/controller/provenance/events/113158283/content/output",
> "previousContentURI":"http:/-02:8080/nifi-api/controller/provenance/events/113158283/content/input",
> "parentIds":[],
> "childIds":[],
> "platform":"nifi",
> "application":"NiFi Flow"}
> It appears that the "/nifi" is getting removed from the content URI - I think 
> this has to do with the following block of code in the reporting task:
> `final String urlPrefix = nifiUrl.toString().replace(nifiUrl.getPath(), "");`



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)