accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Miller <>
Subject Re: ChangeSecret Utility
Date Tue, 12 Jul 2016 16:02:46 GMT
It looks the problem is with the parsing of the arguments in the JCommander
classes. When I run ChangeSecret through the Eclipse debugger it uses the
DefaultConsole.readPassword method to read in the password and it seems to
take my input correctly. When I ran the utility through the accumulo script
and attached jdb, it looks like its using an internal class called
JDK6Console to read the password. The simple fact that it has a JDK version
in the name (I am running Java 1.8) gives me the feeling this might be the
problem.  I will keep investigating.

On Tue, Jul 12, 2016 at 10:43 AM, Josh Elser <> wrote:

> Mike Miller wrote:
>> I was looking at the bug ACCUMULO-2971
>> <>  but I am unable to
>> get the ChangeSecret utility to run. I also noticed the bug 2972
>> <>  which states the
>> documentation should instruct the user to run the utility as so:
>> accumulo org.apache.accumuloserver.util.ChangeSecret
>> I have a standalone instance of 1.7.2 setup on my machine. I am running
>> the
>> utility as myself, which is also the user that is running Hadoop and who
>> has control over the files in HDFS, but when the utility prompts for the
>> passwords, it is only letting me enter a single keystroke for each
>> password. Then I get an
>> org.apache.zookeeper.KeeperException$NoAuthException because I am unable
>> to
>> enter the passwords correctly.
> That's weird.
> Christopher suggested that it might be an issue with the latest JLine jar
>> (2.11) so I pulled down the older jar (2.10) and replaced the newer jar in
>> my lib. This didn't seem to have any effect. Could this be an issue with
>> my
>> local install?
> It might just be broken. It's not something that is commonly used, and has
> probably atrophied.
> Have you tried to attach a remote debugger to the process (you can put the
> JVM properties into ACCUMULO_GENERAL_OPTS via to trace
> through what it's doing?

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