I started to test my container locally and saw the speed was drastically
faster.
So I limited my docker cpu on my laptop to half a core instead of the 4 or 8
my mac has.. and the script went from running in 13 seconds to 1+ minute.
On the cluster i changed half core to be using 1 whole core,
Guessing - if it's a new container on the first invocation, maybe the JVM
is generating the binary class cache? This operation is performed only once
ever, but with a clean environment every time I can see it being invoked
again and again.
Other than that, you'd need to connect a profiler and see
Hi Andrew - yes its a container environment. Everything I work with is in
effect 'dockerized'. I created the container environment with 128min memory
and 256 max memory and 500m cpu which is half a core (2.40GHz per core). I
think that should be fine for the CLI but you tell me otherwise.
Hi Andy
If you’re running in a containerized environment and this is the first task run
that requires cryptographic operations (i.e. performing TLS handshake
negotiations), there is a chance that the issue is that the OS doesn’t feel it
has sufficient entropy to provide cryptographically-secure random
Are you running in some container environment? It should never take 15 secs
and there's no caching performed by cli. I would review the container
environment and see why it's taking forever to start.
Andrew
On Sun, Oct 28, 2018, 10:11 AM ara m. wrote:
> The Keystore user had "view processor"
The Keystore user had "view processor" and "modify processor" permissions.
Still did not work. Its odd since NiFi UI can make imports, so the CLI
should be able to.
Speed wise.. JVM takes a few seconds to start. The command to list buckets
takes ~13 seconds. Its kind of rough. I noticed however
Glad you were able to get it working.
Regarding the super user comment... I don't think it has to be a super
user, but it has to be a user that has permissions to perform the
action. For your example of "nifi pg-import" it would have to be a
user that has write permission to the parent process
Also one more note, if you want to add that same debugging on the NiFi
or NiFi Registry side then it would go in the bootstrap.conf as a
java.arg like:
java.arg.17=-Djavax.net.debug=ssl:handshake
Then restart the application and the SSL handshake debug should go to
nifi-boostrap.log, or
Can you try editing cli.sh and near the end where it actually executes
the CLIMain, edit the line to add the -D for SSL handshake debugging
so it looks like this:
exec "${JAVA}" -cp "${CLASSPATH}" ${JAVA_OPTS:--Xms128m -Xmx256m}
-Djavax.net.debug=ssl:handshake org.apache.nifi.toolkit.cli.CLIMain
I tried the ssldump tool, didnt have much luck with it no matter which
parameters i passed in. Not sure if its because my cluster everything is
dockerized and hides the communication so it cannot parse the communication
then.
Still stuck without being able to use CLI from inside NiFi container
Everything is 1.7.1.
--
Sent from: http://apache-nifi-users-list.2361937.n4.nabble.com/
Hi Ara,
I can see that the Toolkit version is 1.7.1 but what versions of NiFi and
NiFi Registry are you using?
Can you perform an ssldump [1] on the Toolkit or the Registry side to see
the TLS handshake error (supposing that is the issue) more closely?
[1]
With the CLI using the keystore/truststore from NiFi you shouldn't get
an SSL handshake error at all, regardless of whether it was a command
against NiFi or NIFi Registry.
After the SSL handshake the command could still fail based on whether
the identity of the CLI has permissions to execute the
Thats right they are identical, and registry-dev.properties has 2 more
fields, one that is baseUrl https:// registry:port, and the other
proxiedEntity is left blank..
/baseUrl=https://nifi-registry.xx.local:18443
proxiedEntity=/
So using those NiFi properties the CLI can only talk to the
So you're saying the CLI properties for the keystore and truststore
match exactly what is in your nifi.properties for the nifi.security
properties?
Basically these should be identical...
nifi.properties
nifi.security.keystore=
nifi.security.keystoreType=
nifi.security.keystorePasswd=
Since NiFi is already talking to the Registry, the CLI inside the NiFi
container should be able to connect right?
What else can I try?
--
Sent from: http://apache-nifi-users-list.2361937.n4.nabble.com/
I tried this >>> You could also just use the keystore from NiFi since NiFi is
already
successfully talking to registry.
I used the CLI from inside NiFi and provided the truststore as well as the
keystore that NiFi uses, still same error message.
/ERROR: Error executing command 'list-buckets'
In order to perform any action against a secure registry or NiFi you
will need to authenticate, just like if you went to one of the UI's in
your browser and you provided a client cert in your browser, or logged
in with LDAP/Kerberos/etc.
By specifying a truststore you are only verifying the
Hi I've setup NiFi and NiFi registry to talk securely with 2-way SSL auth
(tls), and so have 2 separate keystores and truststores. The truststores of
each service include the cert from the other service. I am able to go to
https:// NiFI url and https:// Registry url, and see both UI's, and I am
19 matches
Mail list logo
