Make mysql command work out of box

[sclorg]

Make mysql command work out of box

[mfojtik]

@mnagy I thought we already have socket enabled and that is the way you connect to mysql when docker exec. If not, then it is a bug.

[hhorak]

+1 for making the command line arguments voluntary (if that was what enabling unix socket means in eventually)

About the "mysql" wrapper -- I don't see any other solution to enable this, so +1 as well. It's not nice though that this wrapper may conflict with the system binary (provided by non-SCL mariadb package).

[mfojtik]

@hhorak it is possible to make mysql consume parameters as env variables? so you don't have to set them?

[mfojtik]

It seems like it should be possible: https://dev.mysql.com/doc/refman/5.5/en/environment-variables.html

[mfojtik]

@mnagy before going to create bash script, please explore if we can do it 'clean' way without wrappers.

[mnagy]

@mfojtik enabling the socket seems a better solution than working with env vars (and very easy one at that) wrt to wrapper script, we already determined that this can't be done in any other way, remember @hhorak's matrix?

@hhorak I'll try to figure out a path that won't collide, but this should not be a concern since we'll be pretty sure MariaDB packages won't be installed.

[hhorak]

@mfojtik there are no environment variables for user and dbname afaict (didn't find any at least), but to avoid passing parameters there is $HOME/.my.cnf that should have correct permissions.

[mfojtik]

OK, I misunderstood this... I thought this is a bug where when you enter the container namespace and execute 'mysql' you will not be connected to mysql as admin user.... now I understand what @mnagy is trying to solve here... docker exec 123456 mysql where the mysql is a wrapper bash script... I don't like that solution... we should stop providing wrappers for stuff like this. This should be fixed in SCL collection and provided by the SCL mysql package, not by this hacky workaround.

[mfojtik]

@hhorak @mnagy also the solution here is to execute this command:

docker exec 123456 /bin/sh -c mysql

@hhorak also you should talk to Docker folks about providing some hook mechanism to inject your SCL vars/scl enable before we enter the running container.

[mnagy]

@mfojtik SCL packages can't provide such a wrapper. If they could, they could just install the binary directly into $PATH. I don't know about patching docker, it's questionable if they'd want to provide a hook mechanism, although that would help things.

And yes, running /bin/bash -c mysql (/bin/sh won't) might do the trick, but it seems to me too verbose if you can simplify it and only need mysql. Reason why I think we should do it is that for other images (those not using SCL), running mysql will work out of box. I'm afraid that users will be confused when it won't work for our images.

@danmcp @bparees thoughts?

[mfojtik]

@mnagy I think /bin/bash -c mysql is reasonable and we can document that. Having to ship extra wrapper with the same name as the RPM binary is too hackish to me.

[mnagy]

@mfojtik well, tested it and /bin/bash -c mysql does not work. You need to execute bash and then execute mysql. Adding -l to bash won't make it work as well.

[hhorak]

@mfojtik as @mnagy said, shipping the wrapper in the RPM is no go, it is actually against SCL concept to not influence the base system. The wrappers were consulted already before and they were explicitly denied by PM. Although you're right about the request to the Docker folks, I will at least try to do something about it.

[mfojtik]

@mnagy that command should work, if not we should fix it. It seems like the .bashrc file is not picked up and the collection is not enabled properly.

[mfojtik]

@hhorak @mnagy if SCL don't want wrappers, why should we go against that?

[praiskup]

Could the discussed 'docker exec cont-entry mysql' help here?

[praiskup]

Ouch, sorry, it was changed to container-entrypoint example:
https://github.com/sclorg/rhscl-dockerfiles/blob/master/rhel6.postgresql92/usr/share/cont-docs/70-general.txt

[mfojtik]

@praiskup @hhorak I thought we all agree that this should work out-of-box without having middle-man script (looking at the matrix from May/11).

[hhorak]

@mfojtik There is one case that doesn't work (#6 in the matrix from May/11) -- non-bash binary run as docker exec, which is exactly the case with docker exec -ti mysql. That's why @mnagy suggested the wrapper.

[mfojtik]

@hhorak but docker exec $CID /bin/bash -c "mysql" should work according to matrix, or I'm wrong?

[mnagy]

@mfojtik not implemented in our images.

[mfojtik]

@mnagy what you mean 'not implemented' in our images? i thought that is the reason why we have $HOME/.bashrc and bash reads it when it starts.

[mnagy]

@mfojtik it only works for bash. For bash -l you need something in /etc/profile and for other uses (bash -c, executing a bash script) you need to set BASH_ENV.

[mfojtik]

@mnagy can you make a PR to set BASH_ENV for our images? and test it.

[mnagy]

@mfojtik just BASH_ENV? What about /etc/profile.d/?

[bparees]

@mnagy @mfojtik I also don't like the wrapper script approach, it was a problem in v2 because no one understood that we'd supplanted the normal binary with an alias(we used an alias in v2 for a similar use case) and there were subtle differences in behavior that confused people who thought they were running the normal binary but were actually getting the wrapper alias.

[mfojtik]

@bparees +100 I thought we can do much better in Docker than in v2

[mnagy]

@bparees bash wrapper script is not the same as binary. And the /opt/rh/.. path set by scl enable precedes ordinary $PATH. This means that if you're in a (scl enabled) bash session, running mysql will execute the correct binary. The wrapper would only be executed in a non-enabled bash session (bash -l unless we chose to add .bashrc also to /etc/profile/) or during docker/oc exec.

[mnagy]

I meant, not the same as an alias.

[mfojtik]

@mnagy I don't see docker exec CID /bin/bash -c mysql as a big problem. At least we are not hiding that we actually execute a bash to enable SCL and we make it explicit for users. Having two executables named "mysql" will be confusing for users and it cripple the PATH when executing it the way you propose.

[bparees]

@mnagy it's the same in that it's magic a user is unware of that has unpredictable behavior if you think you're running the binary.