Bug 961425

Requesting blocker flag for 6.2. 
Unfortunately this issue had neither the blocker flag requested nor Regression keyword filled, so it didn't take part in 6.1 triage.

@Josef: that was intentional. We realized full well we could not stop the 6.1 release. The plan is to get a one-off ready in the next couple of days. Ståle has already fixed it upstream but is still tweaking the code a little.

1. Issue status should not be 'NEW'
2. if this has been fixed in upstream, where is ISSUE_#/PR ?

resolved upstream and in

the eap6.1 branch for æsh can be found here:
https://github.com/aeshell/aesh/tree/eap6.1
i've also created a tag for the latest version called 0.33.5 
   spederse

ready for inclusion in 6.1.1 and later 6.2.0
It got fixed by Ståle faster then we could get the BZ updated :)

@Ståle

Can you please check and close the BZ ?

Kind regards
Tom

Stale is on PTO for two weeks. If it's urgent, please, let me know, I'll check it out.

As already touched upon in email, there are further issues with carriage returns and/or line feeds.

if for example the management realm is setup to always require a user/password, then scripting like this:

$JBOSS_HOME/bin/jboss-cli.sh <<EOFDEL
myuser
mypassword
batch
somecommand

results in:

You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] connect
Username: myuserPassword: mypassword[domain.redhat.com:9999 /] batchsomacommand

Similarly after "run-batch":

 #] run-batchThe batch executed successfully

ive managed to reproduce this locally. working on a fix..

ive pushed aesh 0.33.6 to nexus. the only other thing that needs to change is the version in the pom.
i can probably do that, but im not sure in which branch i should do this (and how its accepted etc)...

I've reproduced issues from customer cases 00904577, 00889193 and 00910827, but example with working required user/password still not working for me.

reproducer.sh:
------------------
#!/bin/bash
./jboss-cli.sh -c <<EOF
bob
admin123$
batch
:shutdown
run-batch
EOF
------------------

steps to reproduce:
(1) unzip a fresh EAP 6.x and remove the following two lines in standalone.xml: <local default-user="$local"/> <local default-user="$local" allowed-users="*"/> 
(2) add a management user ( ./bin/add-user.sh bob admin123$ )
(3) start the server in standalone mode (./bin/standalone.sh)
(4) run reproducer.sh (./bin/reproducer.sh)

result with EAP 6.0.1 -> server is successfully stopped

result with EAP 6.1.1 ER4 -> 
Authenticating against security realm: ManagementRealm
Username: bob
Password: 
[standalone@localhost:9999 /] batch:shutdown
'batch:shutdown' is not a valid operation name.
[standalone@localhost:9999 /] run-batch
// cli hangs here, must use Ctrl+C to rescue

Or is there another open BZ for this remaining issue?

My own results with 6.1.1er4

#!/bin/bash
./jboss-cli.sh -c <<EOF
bob
admin123$
batch
/system-property=bar:add(value=foo)
run-batch

exit

EOF

The empty lines are needed as is the exit


[tom@orac 611er4]$ ./r.sh 
Username: tom
Password: 
[standalone@localhost:9999 /] batch
[standalone@localhost:9999 / #] /system-property=bar:add(value=foo)
#1 /system-property=bla:add(value=foo)
[standalone@localhost:9999 / #] run-batch
The batch executed successfully
[standalone@localhost:9999 /] exit


So I cannot reproduce the concatenation of the "batch" and the first actual command
The need of "exit" is legitimate, as you want to exit the cli before going back to bash mode.

The fact that you need empty lines both before and after exit seems to be a valid issue
@Stale ?

hi, the empty line after exit is needed since the input stream is identical to when you just paste text into the terminal. so if there isnt any new line found after exit it wont run that command (its waiting for more input).

regarding a new line after run-batch seems a bit "strange", ill look into it when im back from pto on monday if thats ok (might have some time tonight, but cant promise anything).

Created attachment 781070 [details]
pkremens_reproducer

Hmm that is really strange, I have same problem (concatenation of the "batch" and the first command) even with you example. Can you please try to run rep.sh (attachment 781070 [details])?

I am getting:
$ ./rep.sh 
Authenticating against security realm: ManagementRealm
Username: bob
Password: 
[standalone@localhost:9999 /] batch/system-property=bar:add(value=foo)
'batch/system-property=bar:add(value=foo)' is not a valid operation name.
[standalone@localhost:9999 /] run-batch
Without arguments the command can be executed only in the batch mode.
[standalone@localhost:9999 /] 
[standalone@localhost:9999 /] exit

I must put empty line also between 'batch' and first command to make things work.

Created attachment 781074 [details]
pkremens_reproducer2

I uploaded working example by mistake, please try attachment 781074 [details]

tested 781074 and works for me, I changed user/pass, nothing else:

[tom@orac 611er4]$ ./rep.sh 
Username: tom
Password: 
[standalone@localhost:9999 /] batch
[standalone@localhost:9999 / #] /system-property=bar:add(value=foo)
#1 /system-property=bar:add(value=foo)
[standalone@localhost:9999 / #] run-batch
The batch executed successfully
[standalone@localhost:9999 /] exit

Just to confirm, this is were I downloaded ER4:

http://porkchop.redhat.com/devel/candidates/JBEAP/JBEAP-6.1.1.ER4/jboss-eap-6.1.1.ER4.zip

and my install is on Fedora 18 (latest patches as of last month)

reproduce both ways now, once working and once not working.
I have the habit of using LDAP authentication for everything, so my own tests were done with the management realm pointing to LDAP.

With LDAP, it works:

[tom@orac bin]$ ./rep.sh 
Username: tom
Password: 
[standalone@localhost:9999 /] batch
[standalone@localhost:9999 / #] /system-property=bar:add(value=foo)
#1 /system-property=bar:add(value=foo)
[standalone@localhost:9999 / #] run-batch
The batch executed successfully
[standalone@localhost:9999 /] exit

Now, with management realm using property files:

[tom@orac bin]$ ./rep.sh 
Authenticating against security realm: ManagementRealm
Username: bob
Password: 
[standalone@localhost:9999 /] batch/system-property=bar:add(value=foo)
'batch/system-property=bar:add(value=foo)' is not a valid operation name.
[standalone@localhost:9999 /] run-batch
Without arguments the command can be executed only in the batch mode.
[standalone@localhost:9999 /] 
[standalone@localhost:9999 /] exit


note the extra line of output:
==>  Authenticating against security realm: ManagementRealm

which is the one that is eating the linefeed !

hi, im back from pto today and look at it now

it seems that its the $ sign in the password that causes this since its parsed by the shell as a variable afaik ( havent googled it yet).
so try to escape the $ sign or use a password that doesnt contain $.
let my know how that works.

the $ sign was only the problem for that example, but ive find out what happens and will have a fix and a new release of aesh out in 1-2 hours.

ive pushed out a new version of aesh (0.33.7) that should fix this. it should also be no need for an extra new line after the exit statement.

Hi Ståle,

Is it possible to get some idea of what was breaking the scripts and how it was fixed for the Release Note?

hi scott, the jira i created for this is here: https://issues.jboss.org/browse/AESH-105
its a fairly short description (albeit correct) description on what was wrong.

in more detail æsh have a separate thread that reads from the stream so it gets data in chunks. when it received a chunk of data that contained several new-lines and the last byte also was a new-line the last byte was swallowed and not parsed correctly... :/

Thanks Ståle

I added a draft Release Note. Please comment on technical it's accuracy.

assigning back to stalep

as found by pkremers:

There is still problem with blocked CLI after passing the command via stdin.

echo 'ls' > /tmp/commands

jboss-eap-6.0/bin]$ ./jboss-cli.sh -c < /tmp/commands
=> Runs ls, and returns (exit correcly)

jboss-eap-6.1/bin]$ ./jboss-cli.sh -c < /tmp/commands
=> Runs ls, input is locked, only CTRL-C return to shell

to 'fix' this,

/tmp/commands

needs to contain:

ls
exit

e.g. the "exit" *must* be present

which if you think about it makes sense..... stdin is handled by the redirect and the CLI is correctly waiting for more input but you cannot type as stdin in not yours

So theoretically we could document this and done (though I'm not in favour to do this as this worked without 'exit' in EAP 6.0 obviously)

i have found out why this happens and ill do a new release now.
however this would also require a small change to jboss-cli as well.
- a null check to prevent a nullpointer exception.

ive pushed out 0.33.8 of aesh now.
as stated above it also needs a change to jboss-cli. ill attach the diff here and contact alexey.
just to be clear that this issue is very different than the original description. imo it could/should be another issue.

Created attachment 785671 [details]
jboss-cli patch

Opened up https://bugzilla.redhat.com/show_bug.cgi?id=996164

About the patch Stale attached, sure. Feel free to submit a PR or I'll include it in the issues I am working on this week.

Verified on EAP 6.1.1. ER5

Setting for inclusion in the 6.1.1 Release notes using the above doc text.