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]>: > > 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 >> > >
