Noted, I've updated the gist. Thanks John. Chris Matta [email protected] 215-701-3146
On Thu, Feb 4, 2016 at 10:12 AM, John Omernik <[email protected]> wrote: > Like I said, I don't believe read -s is posix compliant, hence why I went > with the stty -echo based on > > http://stackoverflow.com/questions/3980668/how-to-get-a-password-from-a-shell-script-without-echoing > > Thus, I went that route for more portability. > > On Thu, Feb 4, 2016 at 8:54 AM, Christopher Matta <[email protected]> wrote: > > > Looks good. You can streamline the no echo of the password by passing > read > > an -s flag. I’ve also updated it to allow for a -u or —user flag: > > > > #!/bin/bash > > USERNAME= > > PASSWORD= > > > > DRILL_VER=drill-1.4.0 > > DRILL_LOC=/opt/mapr/drill > > URL=jdbc:drill:zk=10.10.15.10:5181,10.10.15.11:5181, > > 10.10.15.12:5181/drill/se1-drillbits > > > > DPROP=~/prop$$ > > > > touch $DPROP > > chmod 600 $DPROP > > usage () { > > echo "$0 [ -u|--user username ]" > > } > > ask_user () { > > read -p "Enter username: " USERNAME > > } > > ask_pass () { > > read -s -p "Enter password for ${USERNAME}: " PASSWORD > > echo "" > > } > > while :; do > > case $1 in > > -h|-\?|--help) > > usage > > exit > > ;; > > -u|--user) > > if [ -n "$2" ]; then > > USERNAME=$2 > > shift > > else > > printf 'ERROR: "--user" requires a non-empty option > > argument.\n' >&2 > > exit 1 > > fi > > ;; > > --user=?*) > > USERNAME=${1#*=} # Delete everything up to "=" and assign > > the remainder. > > ;; > > --file=) # Handle the case of an empty --file= > > printf 'ERROR: "--user" requires a non-empty option > > argument.\n' >&2 > > exit 1 > > ;; > > --) # End of all options. > > shift > > break > > ;; > > -?*) > > printf 'WARN: Unknown option (ignored): %s\n' "$1" >&2 > > ;; > > *) # Default case: If no more options then break > > out of the loop. > > break > > esac > > > > shiftdone > > if [[ -z $USERNAME ]];then > > ask_userfi > > if [[ -z $PASSWORD ]];then > > ask_passfi > > # Write properties file for Drill > > cat >> $DPROP <<! > > user=$USERNAME > > password=$PASSWORD > > url=$URL > > ! > > # Exectue Drill connect with properties file. After 5 seconds, the > > command# will delete the prop file. Note this may result in race > > condition.# 5 seconds SHOULD be enough. > > (sleep 5; rm $DPROP) & $DRILL_LOC/$DRILL_VER/bin/sqlline $DPROP > > > > I stuck this up on a public gist if anyone else wants to fiddle with it: > > https://gist.github.com/cjmatta/93993f9283c3508c18d6 > > > > > > Chris Matta > > [email protected] > > 215-701-3146 > > > > On Thu, Feb 4, 2016 at 9:31 AM, John Omernik <[email protected]> wrote: > > > > > That works, here is the script I came up with (mostly based on Ted's > > script > > > with a few terminal reads). Feel free to include this script in Drill > > for > > > people to use, Security wise, this is fairly sound, 5 seconds of a file > > > existing with the user's credentials, that is only readable by the user > > > seems a fair compromise here. Ideally sqlline would handle, but this > > works. > > > > > > John > > > > > > #Will need to be privieged to make system wide script > > > touch /usr/sbin/zetadrill > > > chmod +x /usr/sbin/zetadrill > > > > > > contents of zetadrill # Note I used printf and stty -echo to stay posix > > > compliant as read -s and echo -n apparently are not the same across > > > different *nixes. > > > > > > #!/bin/bash > > > > > > # Setup Drill Locations Versions > > > DRILL_LOC="/mapr/zetapoc/mesos/prod/drill/" > > > DRILL_VER="drill-1.4.0" > > > DRILL_BIN="/bin/sqlline" > > > > > > #This is your Drill url > > > URL="jdbc:drill:zk:zknode1:5181,zknode2:5181,zknode3:5181" > > > > > > #Location for the prop file. (Should by user's home directoy, the word > > > prop, and the PID of this script via $$) > > > DPROP=~/prop$$ > > > > > > # Create and Secure the File > > > touch "$DPROP" > > > chmod 600 "$DPROP" > > > > > > # Get username from user > > > printf "Please enter Username: " > > > read USER > > > > > > # Turn of Terminal Echo > > > stty -echo > > > # Get Password from User > > > printf "Please enter Password: " > > > read PASS > > > # Turn Echo back on > > > stty echo > > > printf "\n" > > > > > > # Write properties file for Drill > > > cat >> "$DPROP" <<! > > > user=$USER > > > password=$PASS > > > url=$URL > > > ! > > > > > > # Exectue Drill connect with properties file. After 5 seconds, the > > command > > > will delete the prop file. Note this may result in race condition. > > > # 5 seconds SHOULD be enough. > > > (sleep 5; rm "$DPROP") & ${DRILL_LOC}${DRILL_VER}${DRILL_BIN} ${DPROP} > > > > > > On Wed, Feb 3, 2016 at 5:24 PM, Ted Dunning <[email protected]> > > wrote: > > > > > > > If you specify a file name on the sqlline command line, that file > will > > be > > > > treated as a properties file which can specify user and password. > > > > > > > > An attacker could see the file name on the [ps ax] output, but they > > > > wouldn't be able to read the props file. If that file is deleted > > shortly > > > > after starting sqlline, even better. > > > > > > > > So you can write the user and password to such a file: > > > > > > > > touch props$$ > > > > chmod 600 props$$ > > > > cat >> props$$ <<! > > > > user=$user > > > > password=$mypassword > > > > url=$url > > > > ! > > > > (sleep 5 ; rm props$$) & > > > > sqlline props$$ > > > > > > > > > > > > The deletion of the properties file is a bit racy, but it should work > > > fine > > > > unless sqlline decides to take forever to start. > > > > > > > > > > > > On Wed, Feb 3, 2016 at 2:44 PM, Christopher Matta <[email protected]> > > > wrote: > > > > > > > > > Good point about the ps, I can imagine a workaround using expect > for > > > > now… I > > > > > attempted to use heredoc but it didn’t really work: > > > > > > > > > > sqlline <<< '!connect jdbc:drill:' > > > > > could not load a native library: netty-transport-native-epoll > > > > > apache drill 1.4.0 > > > > > "a drill is a terrible thing to waste" > > > > > 0: jdbc:drill:> !connect jdbc:drill: > > > > > Enter username for jdbc:drill:: Enter password for jdbc:drill:: > > > > > java.lang.NullPointerException > > > > > at java.util.Hashtable.put(Hashtable.java:514) > > > > > at > > > > sqlline.DatabaseConnection.connect(DatabaseConnection.java:165) > > > > > at > > > > > > sqlline.DatabaseConnection.getConnection(DatabaseConnection.java:213) > > > > > at sqlline.Commands.connect(Commands.java:1083) > > > > > at sqlline.Commands.connect(Commands.java:1015) > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > > Method) > > > > > at > > > > > > > > > > > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > > > > at > > > > > > > > > > > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > > > at java.lang.reflect.Method.invoke(Method.java:606) > > > > > at > > > > > > > > > > > > > > > sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:36) > > > > > at sqlline.SqlLine.dispatch(SqlLine.java:742) > > > > > at sqlline.SqlLine.begin(SqlLine.java:621) > > > > > at sqlline.SqlLine.start(SqlLine.java:375) > > > > > at sqlline.SqlLine.main(SqlLine.java:268) > > > > > 1: jdbc:drill:> java.lang.NullPointerException > > > > > at java.util.Hashtable.put(Hashtable.java:514) > > > > > at > > > > sqlline.DatabaseConnection.connect(DatabaseConnection.java:165) > > > > > at > > > > > > sqlline.DatabaseConnection.getConnection(DatabaseConnection.java:213) > > > > > at sqlline.Commands.close(Commands.java:925) > > > > > at sqlline.Commands.closeall(Commands.java:899) > > > > > at sqlline.SqlLine.begin(SqlLine.java:649) > > > > > at sqlline.SqlLine.start(SqlLine.java:375) > > > > > at sqlline.SqlLine.main(SqlLine.java:268) > > > > > > > > > > > > > > > > > > > > Chris Matta > > > > > [email protected] > > > > > 215-701-3146 > > > > > > > > > > On Wed, Feb 3, 2016 at 5:29 PM, John Omernik <[email protected]> > > wrote: > > > > > > > > > > > I updated the JIRA with the secondary Use Case and I don't think > > > things > > > > > > have been addressed yet. > > > > > > > > > > > > Chris: The issue I see with that approach is it effectively puts > > > your > > > > > > credentials on display in the ps ax on the system. (You typed > your > > > > > > password at a command line) It also puts your credentials in the > > > > > > .bash_history. We need a way that sqlline can get the > credentials > > > that > > > > > > don't show them to all users, or the root user in the case of > > > > > > .bash_history. (See the Jira that Keys mentioned) > > > > > > > > > > > > https://issues.apache.org/jira/browse/DRILL-3880 > > > > > > > > > > > > On Wed, Feb 3, 2016 at 4:24 PM, Keys Botzum < > [email protected]> > > > > > wrote: > > > > > > > > > > > > > They are different although interestingly I think some of this > > has > > > > been > > > > > > > fixed per what others here have posted. If it were me I'd > > > > > clarify/enhance > > > > > > > the JIRA based on what you've just learned but others may feel > > > > > > differently. > > > > > > > > > > > > > > Keys > > > > > > > _______________________________ > > > > > > > Keys Botzum > > > > > > > Senior Principal Technologist > > > > > > > [email protected] <mailto:[email protected]> > > > > > > > 443-718-0098 > > > > > > > MapR Technologies > > > > > > > http://www.mapr.com <http://www.mapr.com/> > > > > > > > > On Feb 3, 2016, at 5:20 PM, John Omernik <[email protected]> > > > wrote: > > > > > > > > > > > > > > > > LOL So I did. > > > > > > > > > > > > > > > > I saw them as two things. "Not putting the password at the > > > command > > > > > > line" > > > > > > > > vs. Specifying the Connect string URL without user or pass > and > > > then > > > > > > > getting > > > > > > > > prompted... but in reality they really are the same thing > > aren't > > > > > they? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Feb 3, 2016 at 4:18 PM, Keys Botzum < > > > [email protected] > > > > > > > <mailto:[email protected]>> wrote: > > > > > > > > > > > > > > > >> Did you already open a JIRA on this? > > > > > > > >> > > > > > > > >> https://issues.apache.org/jira/browse/DRILL-3880 < > > > > > > > https://issues.apache.org/jira/browse/DRILL-3880> > > > > > > > >> > > > > > > > >> > > > > > > > >> Keys > > > > > > > >> _______________________________ > > > > > > > >> Keys Botzum > > > > > > > >> Senior Principal Technologist > > > > > > > >> [email protected] <mailto:[email protected]> <mailto: > > > > > > > [email protected] <mailto:[email protected]>> > > > > > > > >> 443-718-0098 > > > > > > > >> MapR Technologies > > > > > > > >> http://www.mapr.com <http://www.mapr.com/> < > > > http://www.mapr.com/ > > > > < > > > > > > > http://www.mapr.com/>> > > > > > > > >>> On Feb 3, 2016, at 5:14 PM, John Omernik <[email protected] > > > > > > wrote: > > > > > > > >>> > > > > > > > >>> Ya, Andries, that's effectively what I did with my script, > I > > > > passed > > > > > > the > > > > > > > >> url > > > > > > > >>> with -u, but without the username and password provided on > > the > > > > > > command > > > > > > > >>> line, I get an auth error. If there truly is no way to ask > > for > > > > > > > >>> username/password when providing auth string, I may open a > > JIRA > > > > on > > > > > > > that, > > > > > > > >> I > > > > > > > >>> think it would be a helpful feature. Right now my work > around > > > is > > > > to > > > > > > use > > > > > > > >> the > > > > > > > >>> bash script to echo out what they need to type to get into > > > drill > > > > :) > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> On Wed, Feb 3, 2016 at 4:03 PM, Christopher Matta < > > > > [email protected] > > > > > > > > > > > > > >> wrote: > > > > > > > >>> > > > > > > > >>>> The only way I know of getting sqlline to ask for a > password > > > is > > > > to > > > > > > run > > > > > > > >> the > > > > > > > >>>> !connect command after starting the shell: > > > > > > > >>>> > > > > > > > >>>> $ /opt/mapr/drill/drill-1.4.0/bin/sqlline > > > > > > > >>>> apache drill 1.4.0 > > > > > > > >>>> "a drill in the hand is better than two in the bush" > > > > > > > >>>> sqlline> !connect jdbc:drill: > > > > > > > >>>> scan complete in 427ms > > > > > > > >>>> Enter username for jdbc:drill:: cmatta > > > > > > > >>>> Enter password for jdbc:drill:: ************** > > > > > > > >>>> > > > > > > > >>>> I’m not sure how to send that string to the sqlline shell > > once > > > > > it’s > > > > > > > >> opened > > > > > > > >>>> though.. > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>> Chris Matta > > > > > > > >>>> [email protected] > > > > > > > >>>> 215-701-3146 > > > > > > > >>>> > > > > > > > >>>> On Wed, Feb 3, 2016 at 4:53 PM, John Omernik < > > > [email protected]> > > > > > > > wrote: > > > > > > > >>>> > > > > > > > >>>>> Hey all, I am trying to "Ease" my users into using drill. > > > > > > > >>>>> > > > > > > > >>>>> One thing that I'd like to automate for them is the > initial > > > > > > > connection, > > > > > > > >>>>> basically, my zk string > > > > > > > >>>>> > > > > > > > >>>>> jdbc:drill:zk:zknode1:5181,zknode2:5181,zknode3:5181 > > > > > > > >>>>> > > > > > > > >>>>> Is a bit of pain, in addition, my users have to find > > sqlline, > > > > so > > > > > > what > > > > > > > >> if > > > > > > > >>>> I > > > > > > > >>>>> change versions etc... my idea was to put an executable > > > script > > > > in > > > > > > > >>>> /usr/sbin > > > > > > > >>>>> named zetadrill (zeta is a nod To Mr. Scott!) > > > > > > > >>>>> > > > > > > > >>>>> Basically, that has the path and I hoped the connect > string > > > so > > > > > > users > > > > > > > >>>> would > > > > > > > >>>>> not have to find my sqlline, nor would they have to > > > > know/remember > > > > > > > >>>> zookeeper > > > > > > > >>>>> information. Ideal world: They'd type zetadrill and it > > would > > > > say > > > > > > > >> "Please > > > > > > > >>>>> enter Username" "Please enter password" and they'd be > good > > to > > > > go. > > > > > > > >>>>> > > > > > > > >>>>> So I tried using -u flag. > > > > > > > >>>>> > > > > > > > >>>>> When I do that (without a username and password) it fails > > out > > > > on > > > > > > me, > > > > > > > >>>>> basically telling me that auth failed (invalid user > > > > credentials). > > > > > > > >>>>> > > > > > > > >>>>> I obviously can't put a username and password in the > > script, > > > > > > running > > > > > > > >> the > > > > > > > >>>>> connect with -u and -n (no password) results in the same > > > > failure. > > > > > > > >>>>> > > > > > > > >>>>> I guess I am asking: Is there any way to provide a > > connection > > > > > > string, > > > > > > > >> and > > > > > > > >>>>> then have sqlline prompt for credentials? This would make > > the > > > > > user > > > > > > > exp > > > > > > > >> so > > > > > > > >>>>> much better. > > > > > > > >>>>> > > > > > > > >>>>> Thanks in advanced! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
