You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@nifi.apache.org by Gard Skauge <ga...@cloudexplorers.com> on 2016/09/13 13:37:56 UTC
Untrusted proxy message
Hello,
I am setting up a secure NiFi cluster with 3 nodes, using keystone and truststores generated with the tls-toolkit:
tls-toolkit.sh standalone -n '<hostname>' -C 'CN=<hostname>’
All three nodes start and inter-node communication is working fine fromwhat I can see in the logs. However, after logging in, I get the message
Access denied - Untrusted proxy CN=<hostname>, OU=NIFI
If I start only one node, I do not get this error, it´s only after the next node joins the cluster that this happens. Any ideas?
Thanks,
Gard
Re: Untrusted proxy message
Posted by Gard Skauge <ga...@cloudexplorers.com>.
Matt,
That was exactly the issue. The users.xml was different on the node that failed to start. I copied it from another node and everything works.
Thanks a lot!
Gard
> 13. sep. 2016 kl. 22.15 skrev Matt Gilman <ma...@gmail.com>:
>
> Gard,
>
> Is it possible the users.xml contains some users which the other nodes do not? To be sure you could remove/empty the users.xml file as well to be re-generated based on the authorizers.xml configuration.
>
> Alternatively, you could copy the files in question from one node into the conf directory of the others.
>
> Matt
>
> On Tue, Sep 13, 2016 at 3:53 PM, Gard Skauge <gard@cloudexplorers.com <ma...@cloudexplorers.com>> wrote:
> I did the changes on all nodes now, and removed the contents of the authorizations.xml files. When I start up the nodes now, I am in a situation where two of the nodes work fine and join the cluster (and can be accessed in the web interface), but the last one is never able to join (or even start up) because of the same error:
>
>> Proposed Authorizer is not inheritable by the flow controller because of Authorizer differences: Proposed Authorizations do not match current Authorizations
>
> Even when it starts with no authorizations.xml file present, the file is populated at startup and then this exception shows up.
>
> Is there a way to reset things so this node can start and be aligned to the other two?
>
> Thanks,
> Gard
>
>
>> 13. sep. 2016 kl. 16.19 skrev Matt Gilman <matt.c.gilman@gmail.com <ma...@gmail.com>>:
>>
>> Gard,
>>
>> Sounds like those changes were just made on one node. Those changes I outlined will need to be made on all nodes of the cluster in order to keep the policies consistent across the cluster.
>>
>> Matt
>>
>> On Tue, Sep 13, 2016 at 10:16 AM, Gard Skauge <gard@cloudexplorers.com <ma...@cloudexplorers.com>> wrote:
>> Thanks a lot Matt, I had left out that step.
>>
>> Having put those entries in the authorizers.xml file and deleted the authorizations.xml file , I now get the following exception on the
>>
>>
>> Proposed Authorizer is not inheritable by the flow controller because of Authorizer differences: Proposed Authorizations do not match current Authorizations
>>
>>
>> Is something out of sync here?
>>
>>
>> Gard
>>
>>
>>
>>
>>> 13. sep. 2016 kl. 15.45 skrev Matt Gilman <matt.c.gilman@gmail.com <ma...@gmail.com>>:
>>>
>>> Gard,
>>>
>>> In your conf/authorizers.xml configuration file you'll see entries which need to be populated with the nodes in your cluster. With zero master clustering, the nodes in the cluster may be replicating requests to the other nodes in the cluster. In order for the node to trust the end user, each machine along the way needs to be authorized for proxying. Configuring that part of the authorizers.xml will establish these policies.
>>>
>>> Note, the policies are only created when the authorizations.xml is not present or empty (containing just the empty root element) so you may need to modify/removing this file prior to restarting.
>>>
>>> Thanks.
>>>
>>> Matt
>>>
>>> On Tue, Sep 13, 2016 at 9:37 AM, Gard Skauge <gard@cloudexplorers.com <ma...@cloudexplorers.com>> wrote:
>>> Hello,
>>>
>>>
>>> I am setting up a secure NiFi cluster with 3 nodes, using keystone and truststores generated with the tls-toolkit:
>>>
>>> tls-toolkit.sh standalone -n '<hostname>' -C 'CN=<hostname>’
>>>
>>> All three nodes start and inter-node communication is working fine fromwhat I can see in the logs. However, after logging in, I get the message
>>>
>>>
>>> Access denied - Untrusted proxy CN=<hostname>, OU=NIFI
>>>
>>>
>>> If I start only one node, I do not get this error, it´s only after the next node joins the cluster that this happens. Any ideas?
>>>
>>>
>>> Thanks,
>>> Gard
>>>
>>
>>
>
>
Re: Untrusted proxy message
Posted by Matt Gilman <ma...@gmail.com>.
Gard,
Is it possible the users.xml contains some users which the other nodes do
not? To be sure you could remove/empty the users.xml file as well to be
re-generated based on the authorizers.xml configuration.
Alternatively, you could copy the files in question from one node into the
conf directory of the others.
Matt
On Tue, Sep 13, 2016 at 3:53 PM, Gard Skauge <ga...@cloudexplorers.com>
wrote:
> I did the changes on all nodes now, and removed the contents of the
> authorizations.xml files. When I start up the nodes now, I am in a
> situation where two of the nodes work fine and join the cluster (and can be
> accessed in the web interface), but the last one is never able to join (or
> even start up) because of the same error:
>
> Proposed Authorizer is not inheritable by the flow controller because of
>> Authorizer differences: Proposed Authorizations do not match current
>> Authorizations
>>
>
> Even when it starts with no authorizations.xml file present, the file is
> populated at startup and then this exception shows up.
>
> Is there a way to reset things so this node can start and be aligned to
> the other two?
>
> Thanks,
> Gard
>
>
> 13. sep. 2016 kl. 16.19 skrev Matt Gilman <ma...@gmail.com>:
>
> Gard,
>
> Sounds like those changes were just made on one node. Those changes I
> outlined will need to be made on all nodes of the cluster in order to keep
> the policies consistent across the cluster.
>
> Matt
>
> On Tue, Sep 13, 2016 at 10:16 AM, Gard Skauge <ga...@cloudexplorers.com>
> wrote:
>
>> Thanks a lot Matt, I had left out that step.
>>
>> Having put those entries in the authorizers.xml file and deleted the
>> authorizations.xml file , I now get the following exception on the
>>
>>
>> Proposed Authorizer is not inheritable by the flow controller because
>> of Authorizer differences: Proposed Authorizations do not match current
>> Authorizations
>>
>>
>> Is something out of sync here?
>>
>>
>> Gard
>>
>>
>>
>>
>> 13. sep. 2016 kl. 15.45 skrev Matt Gilman <ma...@gmail.com>:
>>
>> Gard,
>>
>> In your conf/authorizers.xml configuration file you'll see entries which
>> need to be populated with the nodes in your cluster. With zero master
>> clustering, the nodes in the cluster may be replicating requests to the
>> other nodes in the cluster. In order for the node to trust the end user,
>> each machine along the way needs to be authorized for proxying. Configuring
>> that part of the authorizers.xml will establish these policies.
>>
>> Note, the policies are only created when the authorizations.xml is not
>> present or empty (containing just the empty root element) so you may need
>> to modify/removing this file prior to restarting.
>>
>> Thanks.
>>
>> Matt
>>
>> On Tue, Sep 13, 2016 at 9:37 AM, Gard Skauge <ga...@cloudexplorers.com>
>> wrote:
>>
>>> Hello,
>>>
>>>
>>> I am setting up a secure NiFi cluster with 3 nodes, using keystone and
>>> truststores generated with the tls-toolkit:
>>>
>>> tls-toolkit.sh standalone -n '<hostname>' -C 'CN=<hostname>’
>>>
>>> All three nodes start and inter-node communication is working fine
>>> fromwhat I can see in the logs. However, after logging in, I get the message
>>>
>>>
>>> Access denied - Untrusted proxy CN=<hostname>, OU=NIFI
>>>
>>>
>>> If I start only one node, I do not get this error, it´s only after the
>>> next node joins the cluster that this happens. Any ideas?
>>>
>>>
>>> Thanks,
>>> Gard
>>
>>
>>
>>
>
>
Re: Untrusted proxy message
Posted by Gard Skauge <ga...@cloudexplorers.com>.
I did the changes on all nodes now, and removed the contents of the authorizations.xml files. When I start up the nodes now, I am in a situation where two of the nodes work fine and join the cluster (and can be accessed in the web interface), but the last one is never able to join (or even start up) because of the same error:
> Proposed Authorizer is not inheritable by the flow controller because of Authorizer differences: Proposed Authorizations do not match current Authorizations
Even when it starts with no authorizations.xml file present, the file is populated at startup and then this exception shows up.
Is there a way to reset things so this node can start and be aligned to the other two?
Thanks,
Gard
> 13. sep. 2016 kl. 16.19 skrev Matt Gilman <ma...@gmail.com>:
>
> Gard,
>
> Sounds like those changes were just made on one node. Those changes I outlined will need to be made on all nodes of the cluster in order to keep the policies consistent across the cluster.
>
> Matt
>
> On Tue, Sep 13, 2016 at 10:16 AM, Gard Skauge <gard@cloudexplorers.com <ma...@cloudexplorers.com>> wrote:
> Thanks a lot Matt, I had left out that step.
>
> Having put those entries in the authorizers.xml file and deleted the authorizations.xml file , I now get the following exception on the
>
>
> Proposed Authorizer is not inheritable by the flow controller because of Authorizer differences: Proposed Authorizations do not match current Authorizations
>
>
> Is something out of sync here?
>
>
> Gard
>
>
>
>
>> 13. sep. 2016 kl. 15.45 skrev Matt Gilman <matt.c.gilman@gmail.com <ma...@gmail.com>>:
>>
>> Gard,
>>
>> In your conf/authorizers.xml configuration file you'll see entries which need to be populated with the nodes in your cluster. With zero master clustering, the nodes in the cluster may be replicating requests to the other nodes in the cluster. In order for the node to trust the end user, each machine along the way needs to be authorized for proxying. Configuring that part of the authorizers.xml will establish these policies.
>>
>> Note, the policies are only created when the authorizations.xml is not present or empty (containing just the empty root element) so you may need to modify/removing this file prior to restarting.
>>
>> Thanks.
>>
>> Matt
>>
>> On Tue, Sep 13, 2016 at 9:37 AM, Gard Skauge <gard@cloudexplorers.com <ma...@cloudexplorers.com>> wrote:
>> Hello,
>>
>>
>> I am setting up a secure NiFi cluster with 3 nodes, using keystone and truststores generated with the tls-toolkit:
>>
>> tls-toolkit.sh standalone -n '<hostname>' -C 'CN=<hostname>’
>>
>> All three nodes start and inter-node communication is working fine fromwhat I can see in the logs. However, after logging in, I get the message
>>
>>
>> Access denied - Untrusted proxy CN=<hostname>, OU=NIFI
>>
>>
>> If I start only one node, I do not get this error, it´s only after the next node joins the cluster that this happens. Any ideas?
>>
>>
>> Thanks,
>> Gard
>>
>
>
Re: Untrusted proxy message
Posted by Matt Gilman <ma...@gmail.com>.
Gard,
Sounds like those changes were just made on one node. Those changes I
outlined will need to be made on all nodes of the cluster in order to keep
the policies consistent across the cluster.
Matt
On Tue, Sep 13, 2016 at 10:16 AM, Gard Skauge <ga...@cloudexplorers.com>
wrote:
> Thanks a lot Matt, I had left out that step.
>
> Having put those entries in the authorizers.xml file and deleted the
> authorizations.xml file , I now get the following exception on the
>
>
> Proposed Authorizer is not inheritable by the flow controller because
> of Authorizer differences: Proposed Authorizations do not match current
> Authorizations
>
>
> Is something out of sync here?
>
>
> Gard
>
>
>
>
> 13. sep. 2016 kl. 15.45 skrev Matt Gilman <ma...@gmail.com>:
>
> Gard,
>
> In your conf/authorizers.xml configuration file you'll see entries which
> need to be populated with the nodes in your cluster. With zero master
> clustering, the nodes in the cluster may be replicating requests to the
> other nodes in the cluster. In order for the node to trust the end user,
> each machine along the way needs to be authorized for proxying. Configuring
> that part of the authorizers.xml will establish these policies.
>
> Note, the policies are only created when the authorizations.xml is not
> present or empty (containing just the empty root element) so you may need
> to modify/removing this file prior to restarting.
>
> Thanks.
>
> Matt
>
> On Tue, Sep 13, 2016 at 9:37 AM, Gard Skauge <ga...@cloudexplorers.com>
> wrote:
>
>> Hello,
>>
>>
>> I am setting up a secure NiFi cluster with 3 nodes, using keystone and
>> truststores generated with the tls-toolkit:
>>
>> tls-toolkit.sh standalone -n '<hostname>' -C 'CN=<hostname>’
>>
>> All three nodes start and inter-node communication is working fine
>> fromwhat I can see in the logs. However, after logging in, I get the message
>>
>>
>> Access denied - Untrusted proxy CN=<hostname>, OU=NIFI
>>
>>
>> If I start only one node, I do not get this error, it´s only after the
>> next node joins the cluster that this happens. Any ideas?
>>
>>
>> Thanks,
>> Gard
>
>
>
>
Re: Untrusted proxy message
Posted by Gard Skauge <ga...@cloudexplorers.com>.
Thanks a lot Matt, I had left out that step.
Having put those entries in the authorizers.xml file and deleted the authorizations.xml file , I now get the following exception on the
Proposed Authorizer is not inheritable by the flow controller because of Authorizer differences: Proposed Authorizations do not match current Authorizations
Is something out of sync here?
Gard
> 13. sep. 2016 kl. 15.45 skrev Matt Gilman <ma...@gmail.com>:
>
> Gard,
>
> In your conf/authorizers.xml configuration file you'll see entries which need to be populated with the nodes in your cluster. With zero master clustering, the nodes in the cluster may be replicating requests to the other nodes in the cluster. In order for the node to trust the end user, each machine along the way needs to be authorized for proxying. Configuring that part of the authorizers.xml will establish these policies.
>
> Note, the policies are only created when the authorizations.xml is not present or empty (containing just the empty root element) so you may need to modify/removing this file prior to restarting.
>
> Thanks.
>
> Matt
>
> On Tue, Sep 13, 2016 at 9:37 AM, Gard Skauge <gard@cloudexplorers.com <ma...@cloudexplorers.com>> wrote:
> Hello,
>
>
> I am setting up a secure NiFi cluster with 3 nodes, using keystone and truststores generated with the tls-toolkit:
>
> tls-toolkit.sh standalone -n '<hostname>' -C 'CN=<hostname>’
>
> All three nodes start and inter-node communication is working fine fromwhat I can see in the logs. However, after logging in, I get the message
>
>
> Access denied - Untrusted proxy CN=<hostname>, OU=NIFI
>
>
> If I start only one node, I do not get this error, it´s only after the next node joins the cluster that this happens. Any ideas?
>
>
> Thanks,
> Gard
>
Re: Untrusted proxy message
Posted by Matt Gilman <ma...@gmail.com>.
Gard,
In your conf/authorizers.xml configuration file you'll see entries which
need to be populated with the nodes in your cluster. With zero master
clustering, the nodes in the cluster may be replicating requests to the
other nodes in the cluster. In order for the node to trust the end user,
each machine along the way needs to be authorized for proxying. Configuring
that part of the authorizers.xml will establish these policies.
Note, the policies are only created when the authorizations.xml is not
present or empty (containing just the empty root element) so you may need
to modify/removing this file prior to restarting.
Thanks.
Matt
On Tue, Sep 13, 2016 at 9:37 AM, Gard Skauge <ga...@cloudexplorers.com>
wrote:
> Hello,
>
>
> I am setting up a secure NiFi cluster with 3 nodes, using keystone and
> truststores generated with the tls-toolkit:
>
> tls-toolkit.sh standalone -n '<hostname>' -C 'CN=<hostname>’
>
> All three nodes start and inter-node communication is working fine
> fromwhat I can see in the logs. However, after logging in, I get the message
>
>
> Access denied - Untrusted proxy CN=<hostname>, OU=NIFI
>
>
> If I start only one node, I do not get this error, it´s only after the
> next node joins the cluster that this happens. Any ideas?
>
>
> Thanks,
> Gard