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 11:36:38 GMT
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