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 <cma...@mapr.com> 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
> cma...@mapr.com
> 215-701-3146
>
> On Thu, Feb 4, 2016 at 9:31 AM, John Omernik <j...@omernik.com> 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 <ted.dunn...@gmail.com>
> 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 <cma...@mapr.com>
> > 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
> > > > cma...@mapr.com
> > > > 215-701-3146
> > > >
> > > > On Wed, Feb 3, 2016 at 5:29 PM, John Omernik <j...@omernik.com>
> 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 <kbot...@maprtech.com>
> > > > 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
> > > > > > kbot...@maprtech.com <mailto:kbot...@maprtech.com>
> > > > > > 443-718-0098
> > > > > > MapR Technologies
> > > > > > http://www.mapr.com <http://www.mapr.com/>
> > > > > > > On Feb 3, 2016, at 5:20 PM, John Omernik <j...@omernik.com>
> > 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 <
> > kbot...@maprtech.com
> > > > > > <mailto:kbot...@maprtech.com>> 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
> > > > > > >> kbot...@maprtech.com <mailto:kbot...@maprtech.com> <mailto:
> > > > > > kbot...@maprtech.com <mailto:kbot...@maprtech.com>>
> > > > > > >> 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 <j...@omernik.com>
> > > 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 <
> > > cma...@mapr.com
> > > > >
> > > > > > >> 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
> > > > > > >>>> cma...@mapr.com
> > > > > > >>>> 215-701-3146
> > > > > > >>>>
> > > > > > >>>> On Wed, Feb 3, 2016 at 4:53 PM, John Omernik <
> > j...@omernik.com>
> > > > > > 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!
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
