You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@nifi.apache.org by Jeremy Taylor <je...@acesinc.net> on 2017/11/22 19:13:47 UTC
observing strange behavior nifi UI flow on a system from a recent
nifi 0.6.x to nifi 1.3.x upgrade
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/>
Re: observing strange behavior nifi UI flow on a system from a recent
nifi 0.6.x to nifi 1.3.x upgrade
Posted by Jeremy Taylor <je...@acesinc.net>.
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 <ma...@gmail.com>
Reply-To: "users@nifi.apache.org" <us...@nifi.apache.org>
Date: Wednesday, November 22, 2017 at 2:21 PM
To: "users@nifi.apache.org" <us...@nifi.apache.org>
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 <je...@acesinc.net>> 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/>
Re: observing strange behavior nifi UI flow on a system from a recent
nifi 0.6.x to nifi 1.3.x upgrade
Posted by Matt Gilman <ma...@gmail.com>.
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 <je...@acesinc.net>
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
>