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 <[email protected]>: > > 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>>: >> >> 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>>: >>> >>> 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 <[email protected] >>> <mailto:[email protected]>> 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 >>> >> >> > >
