accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: ChangeSecret Utility
Date Wed, 13 Jul 2016 22:33:15 GMT
Oh wait, strike that. We don't have a shell command for this. I think I
misunderstood your use of the word "shell".
If I understand correctly, doing this works:
CLASSPATH=.... java org.apache.accumulo.server.util.ChangeSecret
but this doesn't:
bin/accumulo org.apache.accumulo.server.util.ChangeSecret

This would imply that the thing which is interfering is something coming in
from the classpath which is set up by bin/accumulo.

On Wed, Jul 13, 2016 at 6:27 PM Christopher <ctubbsii@apache.org> wrote:

> The shell does change the input charset (to latin1, I believe), so maybe
> that has an effect?
>
>
> On Wed, Jul 13, 2016 at 4:22 PM Josh Elser <josh.elser@gmail.com> wrote:
>
>> That's really weird. I have no suggestions without digging into the code
>> myself. Sorry :\
>>
>> Mike Miller wrote:
>> > After further debugging, I don't think the problem is with the
>> JCommander
>> > classes directly.  I have isolated the problem to be with something in
>> the
>> > accumulo shell. When I run the ChangeSecret utility as a standalone java
>> > program on the command line, it has no problem accepting input. Any idea
>> > what in the shell might be causing this issue? Is there something else
>> > accepting input that could be interfering?
>> >
>> > On Tue, Jul 12, 2016 at 12:02 PM, Mike Miller<michaelpmiller@gmail.com>
>> > wrote:
>> >
>> >> 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<josh.elser@gmail.com>
>> wrote:
>> >>
>> >>> Mike Miller wrote:
>> >>>
>> >>>> I was looking at the bug ACCUMULO-2971
>> >>>> <https://issues.apache.org/jira/browse/ACCUMULO-2971>   but
I am
>> unable
>> >>>> to
>> >>>> get the ChangeSecret utility to run. I also noticed the bug 2972
>> >>>> <https://issues.apache.org/jira/browse/ACCUMULO-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 accumulo-env.sh) to
>> trace
>> >>> through what it's doing?
>> >>>
>> >>
>> >
>>
>

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