#!/usr/bin/expect -f
#
# This Expect script was generated by autoexpect on Wed Dec 18 17:37:57 2019
# Expect and autoexpect were both written by Don Libes, NIST.
#
# Note that autoexpect does not guarantee a working script.  It
# necessarily has to guess about certain things.  Two reasons a script
# might fail are:
#
# 1) timing - A surprising number of programs (rn, ksh, zsh, telnet,
# etc.) and devices discard or ignore keystrokes that arrive "too
# quickly" after prompts.  If you find your new script hanging up at
# one spot, try adding a short sleep just before the previous send.
# Setting "force_conservative" to 1 (see below) makes Expect do this
# automatically - pausing briefly before sending each character.  This
# pacifies every program I know of.  The -c flag makes the script do
# this in the first place.  The -C flag allows you to define a
# character to toggle this mode off and on.

set force_conservative 0  ;# set to 1 to force conservative mode even if
			  ;# script wasn't run conservatively originally
if {$force_conservative} {
	set send_slow {1 .1}
	proc send {ignore arg} {
		sleep .1
		exp_send -s -- $arg
	}
}

#
# 2) differing output - Some programs produce different output each time
# they run.  The "date" command is an obvious example.  Another is
# ftp, if it produces throughput statistics at the end of a file
# transfer.  If this causes a problem, delete these patterns or replace
# them with wildcards.  An alternative is to use the -p flag (for
# "prompt") which makes Expect only look for the last line of output
# (i.e., the prompt).  The -P flag allows you to define a character to
# toggle this mode off and on.
#
# Read the man page for more info.
#
# -Don


set timeout -1
spawn ./add-user.sh
match_max 100000
expect -exact "\r
What type of user do you wish to add? \r
 a) Management User (mgmt-users.properties) \r
 b) Application User (application-users.properties)\r
(a): "
send -- "A\r"
expect -exact "A\r
\r
Enter the details of the new user to add.\r
Using realm 'ManagementRealm' as discovered from the existing property files.\r
Username : "
send -- "USER\r"
expect -exact "USER\r
Password recommendations are listed below. To modify these restrictions edit the add-user.properties configuration file.\r
 - The password should be different from the username\r
 - The password should not be one of the following restricted values {root, admin, administrator}\r
 - The password should contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s)\r
Password : "
send -- "PASSWORD\r"
expect -exact "\r
WFLYDM0101: Password should have at least 1 digit.\r
Are you sure you want to use the password entered yes/no? "
send -- "Y\r"
expect -exact "Y\r
Re-enter Password : "
send -- "PASSWORD\r"
expect -exact "\r
What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)\[  \]: "
send -- " User,Trainer,Administrator"
expect -exact " User,Trainer,Administrator"
send -- "\r"
expect -exact "\r
About to add user 'USER' for realm 'ManagementRealm'\r
Is this correct yes/no? "
send -- "Y\r"
expect -exact "Y\r
Added user 'USER' to file '/opt/jboss/wildfly/standalone/configuration/mgmt-users.properties'\r
Added user 'USER' to file '/opt/jboss/wildfly/domain/configuration/mgmt-users.properties'\r
Added user 'USER' with groups  User,Trainer,Administrator to file '/opt/jboss/wildfly/standalone/configuration/mgmt-groups.properties'\r
Added user 'USER' with groups  User,Trainer,Administrator to file '/opt/jboss/wildfly/domain/configuration/mgmt-groups.properties'\r
Is this new user going to be used for one AS process to connect to another AS process? \r
e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.\r
yes/no? "
send -- "Y\r"
expect eof