Matt, Thank you for advice here and other pointers. I will pass this on and see how I can get these suggestions addressed on this other system.
Regards, -- Jeremy H. Taylor Software Developer ACES, Incorporated http://acesinc.net<http://acesinc.net/> From: Matt Gilman <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Wednesday, November 22, 2017 at 2:21 PM To: "[email protected]" <[email protected]> Subject: Re: observing strange behavior nifi UI flow on a system from a recent nifi 0.6.x to nifi 1.3.x upgrade Jeremy, The behavior your describing happens when you do not have permissions to the root group. This is the behavior when the policies for the initial admin (configured either through the property or through a legacy authorized-users.xml file) are created but there is no existing flow.xml.gz in the conf directory. In this case, the admin can log in and grant themselves the necessary permissions to the root group. From the admin guide... For a brand new secure flow, providing the "Initial Admin Identity" gives that user access to get into the UI and to manage users, groups and policies. But if that user wants to start modifying the flow, they need to grant themselves policies for the root process group. The system is unable to do this automatically because in a new flow the UUID of the root process group is not permanent until the flow.xml.gz is generated. If the NiFi instance is an upgrade from an existing flow.xml.gz or a 1.x instance going from unsecure to secure, then the "Initial Admin Identity" user is automatically given the privileges to modify the flow. Hope this helps. Matt On Wed, Nov 22, 2017 at 2:13 PM, Jeremy Taylor <[email protected]<mailto:[email protected]>> wrote: Greetings, I’d like to describe some observations we are witnessing and to see if anyone has seen this before or has any thoughts on the matter. Any helpful advice would be appreciated. I am remotely trying to help some folks on a system that has just been upgraded from nifi 0.6.x to 1.3.x. They are simply running nifi via the “nifi.sh start” technique now and not as a service and have nuked their nifi repos to help avoid issues when upgrading. On our development baseline we’ve done the upgrade smoothly to nifi 1.3.0 months ago and have never seen what is being described. Thus, a nifi flow is being used that has already been updated months ago for nifi 1.3.0 and thus is already complaint. I’ve also ensured our custom nars are in the nifi-lib dir, etc. And, those custom nars were also upgraded months ago to use 1.3.0 compliant nifi processor related classes. The observations occurring in NiFi UI: 1) the nifi processors are coming up unlabeled and their outlines are skeleton-dotted-lines. 2) all connections to each processor are each red dotted lines 3) in the top left menu of the nifi where all the icons are for adding processors, input ports, etc., when a mouseover occurs, instead of seeing a hand, we see a the equivalent of a “do NOT symbol”. (i.e. the symbol in the do not smoking sign) I’ve had someone lightly look at the logs for anything special, especially the word “validation” in case there were any bizarre XML validation errors on the nifi flow file. Again, any thoughts or advice would be appreciated. Thanks. Regards, -- Jeremy H. Taylor Software Developer ACES, Incorporated http://acesinc.net<http://acesinc.net/>
