The Ambari/NiFi install fails from the http/Gui with this message:
resource_management.core.exceptions.Fail: Execution of 'unzip /tmp/nifi-0.5.1.1.1.2.0-32.zip -d /opt >> /var/log/nifi/nifi-setup.log' returned 9. End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive. unzip: cannot find zipfile directory in one of /tmp/nifi-0.5.1.1.1.2.0-32.zip or /tmp/nifi-0.5.1.1.1.2.0-32.zip.zip, and cannot find /tmp/nifi-0.5.1.1.1.2.0-32.zip.ZIP, period.
The bottom line is that wget never finds the tarball from the sandbox's configured location to bring it over. I realize this version of NiFi is an ancient one--which may be why its missing in action, but this HDF/HDP 2.4 sandbox is the only one I can get to run on my thin resources at the moment. 2.6 takes my host's resources over the tipping point.
I was able to manually install the 0.5.1x version by executing these steps after downloading an archive copy from Apache NiFi into the VMWare fileshare drive:
cd /opt
tar -xzvf /mnt/hgfs/myfileshare/nifi-0.5.1.tar.gz
nifi-0.5.1/bin/nifi.sh install
service nifi start
I can see the canvas from sandbox.hortonworks.com:9090/nifi, so I know the install on the sandbox was successful.
Now I am stuck in an endless Ambari loop where the ambari agent thinks the product isn't installed, so I won't be able to stop/start NiFi from Ambari. This would mean a manual start on each VM power cycle. Other than freezing the VM, is there a work around for the constant attempt at an unnecessary install and the inability to invoke the service from Ambari?