nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre <andre-li...@fucs.org>
Subject Closing on solving NIFI-1500 - NiFi requires too much write permissions to bootstrap
Date Tue, 27 Sep 2016 15:13:09 GMT
devs,

A while ago (0.4.0 IIRC) we had a brief exchange of messages around the
permissions NiFi requires to run (NIFI-1500).

The debate revolved mostly around 4 things:

1 - write access to $NIFI_HOME/bin

2. write access to $NIFI_HOME/lib - NIFI-2818  / #1059 (review is welcome)

3. write access to $NIFI_HOME/conf (i.e. by default the flow is saved under
"conf/")

4. write access to $NIFI_HOME/. (i.e. creates the missing repo and working
folders upon boot).

Good news is that inspection of the code suggests #1 has been solved when
we re-wrote the nifi.sh script and that #3 and #4 may be solved just by
small changes to default configuration and documentation.


Would anyone have thoughts on what would be the preferred approach to deal
with issues #3 and #4?


IMNSHO, the least impacting way of addressing #3 is to modify the default
behaviour, and ship NiFi with the following settings:

nifi.flow.configuration.file=./conf/flows/flow.xml.gz
nifi.flow.configuration.archive.dir=./conf/flows/archive/

instead of the currently used:

nifi.flow.configuration.file=./conf/flow.xml.gz
nifi.flow.configuration.archive.dir=./conf/archive/

This way, ./conf and all files could be owned by root.root and have fs
permissions set to 755 (drwxr-xr-x)

while conf/flows could be set to runsasuser.runasgroup and fs permissions
set to 700 (drwx------).


#4 Can be solved by modifying the pom files to add the adequate directory
structure to the  tar and gzip archives (i.e. pre-populating the directory
structure) or by adjusting rpm and deb files


We would also update the documentation to ensure people installing NiFi are
informed of the ideal filesystem permissions.


Would everyone be in agreement with this approach?


On a related note:

I would truly appreciate if we could get some eyes over PR-1059 as early as
possible . Whilst a minor change to the code, I suspect it needs to be well
thought off and tested before we commit.


Cheers

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message