Whoa there.... can you turn on debug logging in conf/logback.xml by adding <logger name="org.apache.nifi.remote.SocketRemoteSiteListener " level="DEBUG"/>
Can you submit a JIRA for the log output with the stacktrace for those NPEs please. Thanks Joe On Fri, Oct 21, 2016 at 10:21 AM, Conrad Crampton <[email protected]> wrote: > Hi, > > I realise this may be getting boring for most but… > > I didn’t find any resolution to the upgrade so I have cleanly installed > v1.0.0 and oddly experienced the same issue with RPGs in that although the > RPGs didn’t show any errors (in so much as they had no warning on them and > reported that S2S was secure) the errors reported were about not being able > to determine other nodes in cluster. > > This is a section of log that showed an error that I don’t think I saw > before but only including here in case one of you fine folks need it for any > reason… > > > > ERROR [Site-to-Site Worker Thread-194] > o.a.nifi.remote.SocketRemoteSiteListener Unable to communicate with remote > instance Peer[url=nifi://nifinode3-cm1.mis.local:57289] > (SocketFlowFileServerProtocol[CommsID=04674c10-7351-443f-99c8-bffc59d650a7]) > due to java.lang.NullPointerException; closing connection > > 2016-10-21 12:19:11,401 ERROR [Site-to-Site Worker Thread-195] > o.a.nifi.remote.SocketRemoteSiteListener Unable to communicate with remote > instance Peer[url=nifi://nifinode1-cm1.mis.local:35831] > (SocketFlowFileServerProtocol[CommsID=97eb2f1c-f3dd-4924-89c9-d294bb4037f5]) > due to java.lang.NullPointerException; closing connection > > 2016-10-21 12:19:11,455 ERROR [Site-to-Site Worker Thread-196] > o.a.nifi.remote.SocketRemoteSiteListener Unable to communicate with remote > instance Peer[url=nifi://nifinode5-cm1.mis.local:59093] > (SocketFlowFileServerProtocol[CommsID=61e129ca-2e21-477a-8201-16b905e5beb6]) > due to java.lang.NullPointerException; closing connection > > 2016-10-21 12:19:11,462 ERROR [Site-to-Site Worker Thread-197] > o.a.nifi.remote.SocketRemoteSiteListener Unable to communicate with remote > instance Peer[url=nifi://nifinode6-cm1.mis.local:37275] > (SocketFlowFileServerProtocol[CommsID=48ec62f4-a9ba-45a7-a149-4892d0193819]) > due to java.lang.NullPointerException; closing connection > > 2016-10-21 12:19:11,470 ERROR [Site-to-Site Worker Thread-198] > o.a.nifi.remote.SocketRemoteSiteListener Unable to communicate with remote > instance Peer[url=nifi://nifinode4-cm1.mis.local:57745] > (SocketFlowFileServerProtocol[CommsID=266459a8-7a9b-44bd-8047-b5ba4d9b67ec]) > due to java.lang.NullPointerException; closing connection > > > > in my naivety this suggests a problem with the socket (RAW) connection > protocol. The relevant section for S2S connection in my nifi.properties is > > nifi.remote.input.socket.host=nifinode6-cm1.mis.local // the number > different for each node obviously > > nifi.remote.input.socket.port=10443 > > nifi.remote.input.secure=true > > nifi.remote.input.http.enabled=false > > nifi.remote.input.http.transaction.ttl=30 sec > > > > the errors suggest that the port specified here aren’t being used, but some > random ports are being used instead. Of course this is complete supposition > and probably a red herring. > > > > Anyway, I updated my nifi.properties to > > nifi.remote.input.socket.host=nifinode6-cm1.mis.local > > nifi.remote.input.http.host=nifinode6-cm1.mis.local > > nifi.remote.input.socket.port=10443 > > nifi.remote.input.http.port=11443 > > nifi.remote.input.secure=true > > nifi.remote.input.http.enabled=true > > nifi.remote.input.http.transaction.ttl=30 sec > > > > and used HTTP for my RPG and is now working ok. > > > > The test harness for this is > > > > GenerateFlowFile->RGP(test input port) > > InputPort(test input)->LogAttribute > > > > Regards, > > Conrad > > > > > > > > From: Conrad Crampton <[email protected]> > Date: Friday, 21 October 2016 at 08:18 > > > To: "[email protected]" <[email protected]> > Subject: Re: Upgrade 0.6.1 to 1.0.0 problems with Remote Process Groups > > > > Hi, > > Yes, the access policy for the input port at the root level of my workspace > has S2S access policy (receive data via site to site) for all server nodes > (I have all my nodes in one group). > > For the next level down in my workspace (I have other process groups from my > main ‘root’ page in the UI space to organise the flows), I have input ports > on the next level down of flows which when I check the access policies on > that for S2S, the receive and send data via site-to-site options are greyed > out and if I try to override the policy, they still are. I don’t know if > this is important, but from reading the post below, the issue that the > access policies looks to address is different from my issue. The RPG has a > locked padlock and says site to site is secure. I don’t have any warning > triangles on the RPG itself, but I have the aforementioned warnings in my > logs. > > > > I’m going to abandon this now as I can’t get it to work. > > > > I’m going to try a fresh install and go with that – and have to recreate all > my flows where necessary. I’m moving to a new model of data ingestion anyway > so isn’t as catastrophic as it might be. > > > > Thanks for the help. > > Conrad > > > > From: Andy LoPresto <[email protected]> > Reply-To: "[email protected]" <[email protected]> > Date: Thursday, 20 October 2016 at 17:31 > To: "[email protected]" <[email protected]> > Subject: Re: Upgrade 0.6.1 to 1.0.0 problems with Remote Process Groups > > > > * PGP Signed by an unknown key > > Conrad, > > > > For the site-to-site did you follow the instructions here [1]? Each node > needs to be added as a user in order to make the connections. > > > > [1] > http://bryanbende.com/development/2016/08/30/apache-nifi-1.0.0-secure-site-to-site > > > > Andy LoPresto > > [email protected] > > [email protected] > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > > > On Oct 20, 2016, at 7:36 AM, Conrad Crampton <[email protected]> > wrote: > > > > Ok, > > So I tried everything suggested so far to no avail unfortunately. > > > > So what I have done is to create all new certs etc. using the tookit. > Updated my existing authoriszed-users.xml to have to match the full cert > distinguished names CN=server.name, OU=NIFI etc. > > > > Recreated all my remote process groups to not reference the original NCM as > that still wouldn’t work – after a complete new install (upgrade). > > > > So now what I have is a six node cluster using original data/worker nodes > and they are part of the cluster – all appears to be working ie. I can log > into the UI (nice by the way ;-) on each server. There are no SSL handshake > errors etc. BUT the RPG (newly created) still don’t appear to be working. I > am getting > > > > 11:34:24 GMTWARNINGe19ccf8e-0157-1000-0000-000063bfd9c0 > > nifi6-cm1.local:9443org.apache.nifi.remote.client.PeerSelector@782af623 > Unable to refresh Remote Group's peers due to Unable to communicate with > remote NiFi cluster in order to determine which nodes exist in the remote > cluster > > 11:34:25 GMTWARNINGe19ccf8e-0157-1000-0000-000063bfd9c0 > > nifi1-cm1.local:9443org.apache.nifi.remote.client.PeerSelector@3a547274 > Unable to refresh Remote Group's peers due to Unable to communicate with > remote NiFi cluster in order to determine which nodes exist in the remote > cluster > > 11:34:25 GMTWARNINGe1990203-0157-1000-ffff-ffff9ff40dc0 > > nifi2-cm1.local:9443org.apache.nifi.remote.client.PeerSelector@54c2df1 > Unable to refresh Remote Group's peers due to Unable to communicate with > remote NiFi cluster in order to determine which nodes exist in the remote > cluster > > 11:34:25 GMTWARNINGe1990203-0157-1000-ffff-ffff9ff40dc0 > > nifi5-cm1.local:9443org.apache.nifi.remote.client.PeerSelector@50d59f3c > Unable to refresh Remote Group's peers due to Unable to communicate with > remote NiFi cluster in order to determine which nodes exist in the remote > cluster > > 11:34:26 GMTWARNINGe19ccf8e-0157-1000-0000-000063bfd9c0 > > nifi2-cm1.local:9443org.apache.nifi.remote.client.PeerSelector@97c92ef > Unable to refresh Remote Group's peers due to Unable to communicate with > remote NiFi cluster in order to determine which nodes exist in the remote > cluster > > 11:34:26 GMTWARNINGe1990203-0157-1000-ffff-ffff9ff40dc0 > > nifi6-cm1.local:9443org.apache.nifi.remote.client.PeerSelector@70663037 > Unable to refresh Remote Group's peers due to Unable to communicate with > remote NiFi cluster in order to determine which nodes exist in the remote > cluster > > 11:34:27 GMTWARNINGe1990203-0157-1000-ffff-ffff9ff40dc0 > > nifi4-cm1.local:9443org.apache.nifi.remote.client.PeerSelector@3c040426 > Unable to refresh Remote Group's peers due to Unable to communicate with > remote NiFi cluster in order to determine which nodes exist in the remote > cluster > > > > I can telnet from server to server on both https (UI) port and S2S port. > > I am really at a loss as to what to do now. > > > > Data is queuing up in my input processors with nowhere to go. > > Do I have to do something radical here to get this working like stopping > everything, clearing out all the queues then starting up again??? I really > don’t want to do this obviously but I am getting nowhere on this – two days > of frustration with nothing to show for it. > > > > Any more suggestions please?? > > Thanks for your patience. > > Conrad > > > > > > From: Andy LoPresto <[email protected]> > Reply-To: "[email protected]" <[email protected]> > Date: Wednesday, 19 October 2016 at 18:24 > To: "[email protected]" <[email protected]> > Subject: Re: Upgrade 0.6.1 to 1.0.0 problems with Remote Process Groups > > > >> Old Signed by an unknown key > > Hi Conrad, > > > > Bryan is correct that changing the certificates (and the encapsulating > keystores and truststores) will not affect any data held in the nodes. > > > > Regenerating everything using the TLS toolkit should hopefully not be too > challenging, but I am also curious as to why you are getting these handshake > exceptions now. As Bryan pointed out, adding the following line to > bootstrap.conf will provide substantial additional log output which should > help trace the issue. > > > > java.arg.15=-Djavax.net.debug=ssl,handshake > > > > You can also imitate the node connecting to the (previous) NCM via this > command: > > > > $ openssl s_client -connect <host:port> -debug -state -cert > <path_to_your_cert.pem> -key <path_to_your_key.pem> -CAfile > <path_to_your_CA_cert.pem> > > > > Where: > > > > <host:port> = the hostname and port of the “NCM” > <path_to_your_cert.pem> = the public key used to identify the “node” (can be > exported from the node keystore [1]) > <path_to_your_key.pem> = the private key used to identify the “node” (can be > exported from the node keystore via 2 step process) > <path_to_your_CA_cert.pem> = the public key used to sign the “NCM” > certificate (could be a 3rd party like Verisign or DigiCert, or an internal > organization CA if you have one) > > > > If you’ve already regenerated everything and it works, that’s fine. But if > you have the time to try and investigate the old certs, we are interested > and prepared to help. Thanks. > > > > [1] https://security.stackexchange.com/a/66865/16485 > > > > Andy LoPresto > > [email protected] > > [email protected] > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > > > On Oct 19, 2016, at 1:03 PM, Bryan Bende <[email protected]> wrote: > > > > That is definitely weird that it is only an issue on the node that used to > be the NCM. > > Might be worth double checking the keystore and truststore of that one node > and make sure it has what you would expect, and also double check > nifi.properties compared to the others to see if anything seems different. > > > > Changing all of the keystores, truststores, etc should be fine from a data > perspective... > > > > If you decide to go that route it would probably be easiest to start back > over from a security perspective, meaning: > > - Stop all the nodes and delete the users.xml and authorizations.xml from > all nodes > > - Configure authorizers.xml with the appropriate initial admin (or legacy > file) and node identities based on the new certs > > - Ensure authorizers.xml is the same on all nodes > > - Then restart everything > > > > Alternatively, you might be able to manually add users for all of the new > certs before shutting everything down and give them the appropriate > policies, then restart everything, but requires more manual work to get > everything lined up. > > > > > > On Wed, Oct 19, 2016 at 11:52 AM, Conrad Crampton > <[email protected]> wrote: > > Hi, > > As a plan for tomorrow – I have generated new keystores, truststores, client > certts etc. for all nodes in my cluster using the > > > > From: Bryan Bende <[email protected]> > Reply-To: "[email protected]" <[email protected]> > Date: Wednesday, 19 October 2016 at 15:33 > > > To: "[email protected]" <[email protected]> > Subject: Re: Upgrade 0.6.1 to 1.0.0 problems with Remote Process Groups > > > > > > Trying to think of things to check here... > > > > Does every node have nifi.remote.input.secure=true in nifi.properties and > the URL in the RPG is an https URL? > > > > On Wed, Oct 19, 2016 at 10:25 AM, Conrad Crampton > <[email protected]> wrote: > > One other thing… > > The RPGs have an unlocked padlock on them saying S2S is not secure. > > Conrad > > > > From: Bryan Bende <[email protected]> > Reply-To: "[email protected]" <[email protected]> > Date: Wednesday, 19 October 2016 at 15:20 > To: "[email protected]" <[email protected]> > Subject: Re: Upgrade 0.6.1 to 1.0.0 problems with Remote Process Groups > > > > Ok that does seem like a TLS/SSL issue... > > > > Is this a single cluster doing site-to-site to itself? > > > > On Wed, Oct 19, 2016 at 10:06 AM, Joe Witt <[email protected]> wrote: > > thanks conrad - did get it. Bryan is being more helpful that I so I > went silent :-) > > On Wed, Oct 19, 2016 at 10:02 AM, Conrad Crampton > > <[email protected]> wrote: >> Hi Joe, >> Yep, >> Tried removing the RPG that referenced the NCM and adding new one with >> one of the nifis as url. >> That sort of worked, but kept getting errors about the NCM not being >> available for the ports and therefore couldn’t actually enable the port I >> needed to for that RPG. >> Thanks >> Conrad >> >> (sending again as don’t know if the stupid header ‘spoofed’ is stopping >> getting though – apologies if already sent) >> >> On 19/10/2016, 14:12, "Joe Witt" <[email protected]> wrote: >> >> Conrad, >> >> For s2s now you can just point at any of the nodes in the cluster. >> Have you tried changing the URL or removing and adding new RPG >> entries? >> >> Thanks >> Joe >> >> On Wed, Oct 19, 2016 at 8:38 AM, Conrad Crampton >> <[email protected]> wrote: >> > Hi, >> > >> > I have finally taken the plunge to upgrade my cluster from 0.6.1 >> to 1.0.0. >> > >> > 6 nodes with a NCM. >> > >> > With the removal of NCM in 1.0.0 I believe I now have an issue >> where none of >> > my Remote Process Groups work as they previously did because >> they were >> > configured to connect to the NCM (as the RPG url) which now >> doesn’t exist. >> > >> > I have tried converting my NCM to a node but whilst I can get it >> running >> > (sort of) when I try and connect to the cluster I get something >> like this in >> > my logs… >> > >> > >> > >> > 2016-10-19 13:14:44,109 ERROR [main] >> o.a.nifi.controller.StandardFlowService >> > Failed to load flow from cluster due to: >> > org.apache.nifi.controller.UninheritableFlowException: Failed to >> connect >> > node to cluster because local flow is different than cluster >> flow. >> > >> > org.apache.nifi.controller.UninheritableFlowException: Failed to >> connect >> > node to cluster because local flow is different than cluster >> flow. >> > >> > at >> > >> org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:879) >> > ~[nifi-framework-core-1.0.0.jar:1.0.0] >> > >> > at >> > >> org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:493) >> > ~[nifi-framework-core-1.0.0.jar:1.0.0] >> > >> > at >> > >> org.apache.nifi.web.server.JettyServer.start(JettyServer.java:746) >> > [nifi-jetty-1.0.0.jar:1.0.0] >> > >> > at org.apache.nifi.NiFi.<init>(NiFi.java:152) >> > [nifi-runtime-1.0.0.jar:1.0.0] >> > >> > at org.apache.nifi.NiFi.main(NiFi.java:243) >> > [nifi-runtime-1.0.0.jar:1.0.0] >> > >> > Caused by: >> org.apache.nifi.controller.UninheritableFlowException: Proposed >> > Authorizer is not inheritable by the flow controller because of >> Authorizer >> > differences: Proposed Authorizations do not match current >> Authorizations >> > >> > at >> > >> org.apache.nifi.controller.StandardFlowSynchronizer.sync(StandardFlowSynchronizer.java:252) >> > ~[nifi-framework-core-1.0.0.jar:1.0.0] >> > >> > at >> > >> org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1435) >> > ~[nifi-framework-core-1.0.0.jar:1.0.0] >> > >> > at >> > >> org.apache.nifi.persistence.StandardXMLFlowConfigurationDAO.load(StandardXMLFlowConfigurationDAO.java:83) >> > ~[nifi-framework-core-1.0.0.jar:1.0.0] >> > >> > at >> > >> org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:671) >> > ~[nifi-framework-core-1.0.0.jar:1.0.0] >> > >> > at >> > >> org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:857) >> > ~[nifi-framework-core-1.0.0.jar:1.0.0] >> > >> > ... 4 common frames omitted >> > >> > 2016-10-19 13:14:44,414 ERROR [main] >> o.a.n.c.c.node.NodeClusterCoordinator >> > Event Reported for ncm-cm1.local:9090 -- Node disconnected from >> > cluster due to >> org.apache.nifi.controller.UninheritableFlowException: Failed >> > to connect node to cluster because local flow is different than >> cluster >> > flow. >> > >> > 2016-10-19 13:14:44,420 ERROR [Shutdown Cluster Coordinator] >> > org.apache.nifi.NiFi An Unknown Error Occurred in Thread >> Thread[Shutdown >> > Cluster Coordinator,5,main]: java.lang.NullPointerException >> > >> > 2016-10-19 13:14:44,423 ERROR [Shutdown Cluster Coordinator] >> > org.apache.nifi.NiFi >> > >> > java.lang.NullPointerException: null >> > >> > at >> > >> java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011) >> > ~[na:1.8.0_51] >> > >> > at >> > >> java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006) >> > ~[na:1.8.0_51] >> > >> > at >> > >> org.apache.nifi.cluster.coordination.node.NodeClusterCoordinator.updateNodeStatus(NodeClusterCoordinator.java:570) >> > ~[nifi-framework-cluster-1.0.0.jar:1.0.0] >> > >> > at >> > >> org.apache.nifi.cluster.coordination.node.NodeClusterCoordinator.shutdown(NodeClusterCoordinator.java:119) >> > ~[nifi-framework-cluster-1.0.0.jar:1.0.0] >> > >> > at >> > >> org.apache.nifi.controller.StandardFlowService$1.run(StandardFlowService.java:330) >> > ~[nifi-framework-core-1.0.0.jar:1.0.0] >> > >> > at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_51] >> > >> > 2016-10-19 13:14:44,448 WARN [main] >> o.a.n.c.l.e.CuratorLeaderElectionManager >> > Failed to close Leader Selector for Cluster Coordinator >> > >> > java.lang.IllegalStateException: Already closed or has not been >> started >> > >> > at >> > >> com.google.common.base.Preconditions.checkState(Preconditions.java:173) >> > ~[guava-18.0.jar:na] >> > >> > at >> > >> org.apache.curator.framework.recipes.leader.LeaderSelector.close(LeaderSelector.java:270) >> > ~[curator-recipes-2.11.0.jar:na] >> > >> > at >> > >> org.apache.nifi.controller.leader.election.CuratorLeaderElectionManager.stop(CuratorLeaderElectionManager.java:159) >> > ~[nifi-framework-core-1.0.0.jar:1.0.0] >> > >> > at >> > >> org.apache.nifi.controller.FlowController.shutdown(FlowController.java:1303) >> > [nifi-framework-core-1.0.0.jar:1.0.0] >> > >> > at >> > >> org.apache.nifi.controller.StandardFlowService.stop(StandardFlowService.java:339) >> > [nifi-framework-core-1.0.0.jar:1.0.0] >> > >> > at >> > >> org.apache.nifi.web.server.JettyServer.start(JettyServer.java:753) >> > [nifi-jetty-1.0.0.jar:1.0.0] >> > >> > at org.apache.nifi.NiFi.<init>(NiFi.java:152) >> > [nifi-runtime-1.0.0.jar:1.0.0] >> > >> > at org.apache.nifi.NiFi.main(NiFi.java:243) >> > [nifi-runtime-1.0.0.jar:1.0.0] >> > >> > 2016-10-19 13:14:45,062 WARN [Cluster Socket Listener] >> > org.apache.nifi.io.socket.SocketListener Failed to communicate >> with Unknown >> > Host due to java.net.SocketException: Socket closed >> > >> > java.net.SocketException: Socket closed >> > >> > at java.net.PlainSocketImpl.socketAccept(Native Method) >> > ~[na:1.8.0_51] >> > >> > at >> > >> java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:404) >> > ~[na:1.8.0_51] >> > >> > at >> java.net.ServerSocket.implAccept(ServerSocket.java:545) >> > ~[na:1.8.0_51] >> > >> > at >> > >> sun.security.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:348) >> > ~[na:1.8.0_51] >> > >> > at >> > >> org.apache.nifi.io.socket.SocketListener$2.run(SocketListener.java:112) >> > ~[nifi-socket-utils-1.0.0.jar:1.0.0] >> > >> > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51] >> > >> > 2016-10-19 13:14:45,064 WARN [main] >> org.apache.nifi.web.server.JettyServer >> > Failed to start web server... shutting down. >> > >> > java.lang.Exception: Unable to load flow due to: >> java.io.IOException: >> > org.apache.nifi.controller.UninheritableFlowException: Failed to >> connect >> > node to cluster because local flow is different than cluster >> flow. >> > >> > at >> > >> org.apache.nifi.web.server.JettyServer.start(JettyServer.java:755) >> > ~[nifi-jetty-1.0.0.jar:1.0.0] >> > >> > at org.apache.nifi.NiFi.<init>(NiFi.java:152) >> > [nifi-runtime-1.0.0.jar:1.0.0] >> > >> > at org.apache.nifi.NiFi.main(NiFi.java:243) >> > [nifi-runtime-1.0.0.jar:1.0.0] >> > >> > Caused by: java.io.IOException: >> > org.apache.nifi.controller.UninheritableFlowException: Failed to >> connect >> > node to cluster because local flow is different than cluster >> flow. >> > >> > at >> > >> org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:497) >> > ~[nifi-framework-core-1.0.0.jar:1.0.0] >> > >> > at >> > >> org.apache.nifi.web.server.JettyServer.start(JettyServer.java:746) >> > ~[nifi-jetty-1.0.0.jar:1.0.0] >> > >> > ... 2 common frames omitted >> > >> > Caused by: >> org.apache.nifi.controller.UninheritableFlowException: Failed to >> > connect node to cluster because local flow is different than >> cluster flow. >> > >> > at >> > >> org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:879) >> > ~[nifi-framework-core-1.0.0.jar:1.0.0] >> > >> > at >> > >> org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:493) >> > ~[nifi-framework-core-1.0.0.jar:1.0.0] >> > >> > ... 3 common frames omitted >> > >> > Caused by: >> org.apache.nifi.controller.UninheritableFlowException: Proposed >> > Authorizer is not inheritable by the flow controller because of >> Authorizer >> > differences: Proposed Authorizations do not match current >> Authorizations >> > >> > at >> > >> org.apache.nifi.controller.StandardFlowSynchronizer.sync(StandardFlowSynchronizer.java:252) >> > ~[nifi-framework-core-1.0.0.jar:1.0.0] >> > >> > at >> > >> org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1435) >> > ~[nifi-framework-core-1.0.0.jar:1.0.0] >> > >> > at >> > >> org.apache.nifi.persistence.StandardXMLFlowConfigurationDAO.load(StandardXMLFlowConfigurationDAO.java:83) >> > ~[nifi-framework-core-1.0.0.jar:1.0.0] >> > >> > at >> > >> org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:671) >> > ~[nifi-framework-core-1.0.0.jar:1.0.0] >> > >> > at >> > >> org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:857) >> > ~[nifi-framework-core-1.0.0.jar:1.0.0] >> > >> > ... 4 common frames omitted >> > >> > [root@ncm-cm1 logs]# >> > >> > >> > >> > I don’t know if the ‘Proposed Authorizer is not inheritable…’ >> exception is >> > part of the problem too. >> > >> > The docs weren’t very clear on whether (when upgrading and using >> the legacy >> > support of the authorized-user.xml path required the nodes to be >> also added >> > to the authorizers.xml. >> > >> > I did add them in the end as various attempts to get the cluster >> up and >> > running without them failed (as each server didn’t seem to have >> rights to do >> > anything. >> > >> > >> > >> > I have a lot of RPG in my work flows as I am ingesting many >> syslog data >> > sources and this was the recommended pattern to distribute the >> data >> > (listensyslog…run on primary, output to port (RPG), pick up in >> rest of data >> > flow), >> > >> > >> > >> > Any suggestions on where to start trying to get this working? >> > >> > I’ve tried creating a new RPG on one on the nifis and connecting >> the >> > syslog to that which sort of worked but then I have a bunch of >> other errors >> > when trying to enable the ports to do with not being able to >> connect to >> > (what was) the NCM. >> > >> > >> > >> > Thanks >> > >> > Conrad >> > >> > >> > >> > SecureData, combating cyber threats >> > >> > ________________________________ >> > >> > The information contained in this message or any of its >> attachments may be >> > privileged and confidential and intended for the exclusive use >> of the >> > intended recipient. If you are not the intended recipient any >> disclosure, >> > reproduction, distribution or other dissemination or use of this >> > communications is strictly prohibited. The views expressed in >> this email are >> > those of the individual and not necessarily of SecureData Europe >> Ltd. Any >> > prices quoted are only valid if followed up by a formal written >> quote. >> > >> > SecureData Europe Limited. Registered in England & Wales >> 04365896. >> > Registered Address: SecureData House, Hermitage Court, Hermitage >> Lane, >> > Maidstone, Kent, ME16 9NT >> >> >> ***This email originated outside SecureData*** >> >> Click >> https://www.mailcontrol.com/sr/tAj77!!uP0XGX2PQPOmvUu5zZAYN1Mos55ZMH65vS49VoLnJlQAkvDtaSciXa9lO25LWvxYjTGeVGm43FW9a3A== >> to report this email as spam. >> >> >> >> > > > > > > > > > > * Unknown Key > * 0x2F7DEF69 > > > > > > * Unknown Key > * 0x2F7DEF69 > >
