SHELL command and Java Admin Client

[duncdrum]

So while doing the readme updates i played some more with the SHELL directive for docker files. The good news first:

FROM existdb/existdb

SHELL ["java"]

RUN -version

This works, and produces:

Step 1/4 : FROM existdb/existdb
 ---> 85d5983d5020
Step 2/4 : SHELL ["java"]
 ---> Running in c14c825171eb
Removing intermediate container c14c825171eb
 ---> 8c3ef1e84064
Step 3/4 : RUN -version
 ---> Running in e7ad6accb70e
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8   -Djava.awt.headless=true   -Dorg.exist.db-connection.cacheSize
=256M   -Dorg.exist.db-connection.pool.max=20   -XX:+UnlockExperimentalVMOptions   -XX:+UseCGroupMemoryLimitForHea
p   -XX:+UseG1GC   -XX:+UseStringDeduplication   -XX:MaxRAMFraction=1
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2~deb9u1-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

all good. By the same token this works as expected as well:

FROM existdb/existdb

SHELL ["java", "-jar","start.jar", "client", "--no-gui"]

RUN -l 

So, i would expect the following to also work:

FROM existdb/existdb

SHELL ["java", "-jar","start.jar", "client", "--no-gui"]

RUN -l -u admin -P "" -x sm:passwd("admin","123")

Yet, it produces (shortened for readability):

Sending build context to Docker daemon  2.048kB
Step 1/4 : FROM existdb/existdb
 ---> 85d5983d5020

Step 2/4 : SHELL ["java", "-jar","start.jar", "client", "--no-gui"]
 ---> Running in 6e12f0d98548
Removing intermediate container 6e12f0d98548
 ---> be4e190e4800
Step 3/4 : RUN -l -u admin -P "" -x "sm:passwd('admin','123')"
 ---> Running in 29e6d9451921
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8   -Djava.awt.headless=true   -Dorg.exist.db-connection.cacheSize
=256M   -Dorg.exist.db-connection.pool.max=20   -XX:+UnlockExperimentalVMOptions   -XX:+UseCGroupMemoryLimitForHea
p   -XX:+UseG1GC   -XX:+UseStringDeduplication   -XX:MaxRAMFraction=1
…

so far so good, however:

…
Unexpected argument: -l -u admin -P "" -x "sm:passwd('admin','123')", previous argument: --no-gui
Usage: Main [Arguments]

Arguments:
-c, --collection <string>                  set target collection.
                                           <string>: any string
                                           Default:
-C, --config <path>                        specify alternate configuration
                                           file. Implies -l.
                                           <path>: a file path
                                           Default: /exist/.
-d, --recurse-dirs                         recurse into subdirectories during
                                           index?
                                           Default: disabled
[…]
The command 'java -jar start.jar client --no-gui -l -u admin -P "" -x sm:passwd("admin","123")' returned a non-zero code: 3

So the client is responding just not how I expect it to. I have tried different iterations of json escaping the RUN command and reshuffle the split between SHELL and RUN, e.g. only go up to -jar in SHELL and execute the rest from RUN but no joy.

I guess one could address exist.jar directly and use the -Dorg.exist.db… syntax here as well, but imv the above example should work, or am i missing something. Given that the JAC "dumb shell" is coming up and executing -l there should be away to, e.g. also do mkcol hamlet or what not.

It possible that this is a string escaping problem with docker, but its also possible that our JAC shell is still not 100% any input welcome, i m kind of stuck why the last example doesn't work but the others do.

The workaround is to simply not use SHELL and stick to long json escaped RUN commands, ie.:

FROM existdb/existdb

RUN ["java", "-jar", "start.jar", "client", "--no-gui", "-l", "-u", "admin", "-P", "", "-x", "sm:passwd('admin','123')"]

[adamretter]

The problem is how the args are being passed to the command line. I am 99% sure this is a Docker issue.

[duncdrum]

very likely i just don't see whats wrong with the commands, reported in the final line, they seem correct to me. If you e.g. JSON escape the RUN you get:

OCI runtime create failed: container_linux.go:344: starting container process caused "exec: \"-l\": executable file not found in $PATH": unknown

[duncdrum]

ok after some more digging around i think this is on distroless and not on docker

[eduarddrenth]

@duncdrum tried you workaround like this:

FROM existdb/existdb:4.6.1

ARG ADMINPW
RUN ["java", "-jar", "start.jar", "client", "--no-gui", "-l", "-u", "admin", "-P", "", "-x", "sm:passwd('admin','$ADMINPW')"]

building succeeds, but exist will not start any more, but instead continuously reboots, no errors, no logging. Any ideas?

[eduarddrenth]

docker run works, docker-compose up works, stack deploy doesn't.

[grantmacken]

@duncan Paterson <[email protected]> A couple of things. This is my understanding ... 1. The client communicates with a running existdb instance using RPC so the container instance must be running. 2. You can't use the -l flag as that tries to use localhost. *Instead use the IP address or container name of the running container.* *You can use the container name as docker knows how to do dns resolution.* *If you check, the travis tests, the above criteria are met*

…

On Sun, 20 Jan 2019 at 01:17, Duncan Paterson ***@***.***> wrote: very likely i just don't see whats wrong with the commands, reported in the final line, they seem correct to me. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#52 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABrSYJntY3OuwBu5itlIYOy3DyB1fZTuks5vEwzHgaJpZM4aJG2w> .

-- Take Care Grant Mackenzie

[duncdrum]

@grantmacken

• 1. Yes but thats what happens during build, see the first two working examples
• 2. container name is set by passing an argument to the build command, or using a randomly generated one if no argument is passed. I m not aware of any arguments that can reference the container name from inside the image instructions of a dockerfile, is there one?

the problem is related to different syntax variants of the RUN command, the -l flag by itself is working as expected. I just don't see the method behind why some commands (with or without flags) work, and others don't. If it is A DNS issue i would expect none of the commands to work.

All work in the full JSON form, which is good enough, i d just like to understand why not all commands work in both syntax variants. JAC provides a shell that SHELL recognises.

[grantmacken]

My understanding is the client is just an RPC client. It connects to local or remote existdb instances using the RPC protocol. If you are trying to use the client at the build phase and using the l flag what is the client connecting to.

[eduarddrenth]

RUN ["java", "-jar", "start.jar", "client",..... will start exist, run the client command to it and shutdown exist.

[duncdrum]

@grantmacken the intermediate image created for the layer corresponding to the RUN command calling it?