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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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< > [email protected]> > >> > 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<[email protected]> > >> 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? > >> >>> > >> >> > >> > > >> > > >
