accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Miller <michaelpmil...@gmail.com>
Subject Re: ChangeSecret Utility
Date Thu, 14 Jul 2016 19:18:24 GMT
I think I have isolated the problem and think this may be a bug. The
interference is happening when jline.console.ConsoleReader gets
instantiated in the constructor of org.apache.accumulo.shell.Shell. Even
though I am not starting the shell with bin/accumulo, it is still being
instantiated by the ServiceLoader in o.a.a.start.Main.  See the evidence of
my manually thrown exception and stacktrace below.
Shell() called from...
java.lang.Exception
    at org.apache.accumulo.shell.Shell.<init>(Shell.java:247)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at java.lang.Class.newInstance(Class.java:442)
    at
java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
    at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
    at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
    at org.apache.accumulo.start.Main.checkDuplicates(Main.java:223)
    at org.apache.accumulo.start.Main.getExecutables(Main.java:215)
    at org.apache.accumulo.start.Main.main(Main.java:78)

I tested ChangeSecret again with an empty constructor in o.a.a.shell.Shell
and it has no problem reading in the passwords. This seems like a bug
between the two classes but I am just not sure which one is the guilty
party.


On Thu, Jul 14, 2016 at 7:36 AM, Mike Miller <michaelpmiller@gmail.com>
wrote:

> Sorry for the confusion, I was thinking that
> org.apache.accumulo.shell.Shell gets instantiated when calling bin/accumulo
> org.apache.accumulo.server.util.ChangeSecret. I think you are right about
> the problem being with the classpath setup by the bin/accumulo script.
>
> On Wed, Jul 13, 2016 at 6:33 PM, Christopher <ctubbsii@apache.org> wrote:
>
>> 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