nifi-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Gilman <matt.c.gil...@gmail.com>
Subject Re: Untrusted proxy message
Date Tue, 13 Sep 2016 20:15:30 GMT
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>
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>:
>
> 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>
> 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>:
>>
>> 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>
>> 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
>>
>>
>>
>>
>
>

Mime
View raw message