mssql-docker
mssql-docker copied to clipboard
microsoft
What ist the root password in the latest official image for Microsoft SQL Server on Linux for Docker Engine.
In order to administer the installation I need root access for the 2019-CU4-ubuntu-16.04 Docker image, but I cannot find it. Trying did not work ...
The main problem is that there is no sudo which is need by mssql-conf. Message: : ./mssql-conf: line 28: sudo: command not found
But why in the first place did you want to modify the container on a runtime? Container should be disposable, portable and not immutable, if you want a specific setting other than provided by released image then you might want to take a look at building your own container image with dockerfile customized to your needs.
I did want to use the Microsoft maintained SQL Server on Linux for Docker 2019-CU4-ubuntu-16.04 image. Obviously in this Image the SQL Srver Agent (needed for scheduled backups) is disabled and I wanted to switch it on. This did not work (at least) due to the lack of sudo (i.e. used in scripts like mssql-conf) and root password. One benefit of docker is also the ease of use and so I did not want to invest the time in learning how to build own docker images. May be I have to try a SQL Server installation into a docker Ubuntu container.
First off all maybe SQL Server Agent was turned off by default for pre-built Docker image for the sake of minimalism. Have you tried MSSQL_AGENT_ENABLED on your Docker environment?
https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-configure-environment-variables?view=sql-server-ver15
And yes you can do SQL Server installation on vanilla Ubuntu container, but keep in mind that container should designed to be disposable, portable and not immutable, prepare everything for it including persistent volume or storage. If you think of deploying the container once and for all, that could be less fit the case, instead install it on Linux machine itself.
But if what you need is a scheduled backup, you could do that also by using sqlcmd from anywhere outside the running container and put it on cron.
The main problem is that there is no sudo which is need by mssql-conf. Message: : ./mssql-conf: line 28: sudo: command not found
Fortunately, you don't need the root user to make a change in the mssql-conf file. There was another thread very similar to your issue, however, the solution will depend on what you want to do.
Are you looking to modify the mssql-conf file while the container is running (already started) or during a custom build process? I can guide you to make both changes but it will be easy to nail down the process to the specific requirement.
In case what you want is simply to have the SQL Agent started. This can be easily accompplish during the container creation using the MSSQL_AGENT_ENABLED environment variable. Here you have an example:
docker container run \
--env 'ACCEPT_EULA=Y' \
--env 'MSSQL_SA_PASSWORD=_SqLr0ck$_' \
--env 'MSSQL_AGENT_ENABLED=1' \
--detach mcr.microsoft.com/mssql/server:2019-CU4-ubuntu-18.04
Cheers,
Yes, I have set MSSQL_AGENT_ENABLED=true and according to the 2019 doc, it is preinstalled in the image. I also have enabled it via script, but the the context menu entry of the SQL Server Agent is still greyed out. The Maintenance Plan Wizard menu entry is also not existing. I am wondering that this Microsoft maintained image is that poor. I do not want to deploy anything, I just want to setup one installation for test and delelopment in an existing system without (more or less) touching that system. @rudysp: Thx for your help.
@dbsmaster: the environment variables are correctly set. After looking into the log mssql files, it seems, that the agent canont connect to the server (no reason given). This would fit the observation, that in SSMS the context menu item to start the agent is greyed out. FYI the container is running under qnap (current version).
@dbsmaster: the environment variables are correctly set. After looking into the log mssql files, it seems, that the agent canont connect to the server (no reason given). This would fit the observation, that in SSMS the context menu item to start the agent is greyed out.
FYI the container is running under qnap (current version).
Will try to replicate it from my side, I have not experienced a problem with the agent on any version but SQL 2019 CU2.
What’s the length of the hostname for the container? There’s an issue with SQL Agent on Linux cannot support hostnames linger than 15 characters.
Anthony
On May 3, 2020, at 11:41 AM, Carlos Robles [email protected] wrote:
@dbsmaster: the environment variables are correctly set. After looking into the log mssql files, it seems, that the agent canont connect to the server (no reason given). This would fit the observation, that in SSMS the context menu item to start the agent is greyed out.
FYI the container is running under qnap (current version).
Will try to replicate it from my side, I have not experienced a problem with the agent on any version but SQL 2019 CU2.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/microsoft/mssql-docker/issues/599#issuecomment-623139833, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AE4X5FNY57KRWH7KQAXMBKLRPWNCLANCNFSM4MWY25MA.
Even with a hostname of 5 letters still the same problem. Extract of sqlagent.out:
2020-05-03 19:01:32 - ! [150] SQL Server does not accept the connection (error: 11001). Waiting for Sql Server to allow connections. Operation attempted was: Verify Connection On Start.
2020-05-03 19:01:32 - ! [000] Unable to connect to server '(local),1433'; SQLServerAgent cannot start
2020-05-03 19:01:32 - ! [103] SQLServerAgent could not be started (reason: Unable to connect to server '(local),1433'; SQLServerAgent cannot start)
2020-05-03 19:01:37 - ! [298] SQLServer Error: 11001, TCP Provider: No such host is known. [SQLSTATE 08001]
2020-05-03 19:01:37 - ! [165] ODBC Error: 0, Login timeout expired [SQLSTATE HYT00]
2020-05-03 19:01:37 - ! [298] SQLServer Error: 11001, A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online. [SQLSTATE 08001]
2020-05-03 19:01:37 - ! [382] Logon to server '(local),1433' failed (DisableAgentXPs)
2020-05-03 19:01:37 - ? [102] SQLServerAgent service successfully stopped
2020-05-03 19:01:39 - ? [098] SQLServerAgent terminated (normally)
Even with a hostname of 5 letters still the same problem. Extract of sqlagent.out:
2020-05-03 19:01:32 - ! [150] SQL Server does not accept the connection (error: 11001). Waiting for Sql Server to allow connections. Operation attempted was: Verify Connection On Start. 2020-05-03 19:01:32 - ! [000] Unable to connect to server '(local),1433'; SQLServerAgent cannot start 2020-05-03 19:01:32 - ! [103] SQLServerAgent could not be started (reason: Unable to connect to server '(local),1433'; SQLServerAgent cannot start) 2020-05-03 19:01:37 - ! [298] SQLServer Error: 11001, TCP Provider: No such host is known. [SQLSTATE 08001] 2020-05-03 19:01:37 - ! [165] ODBC Error: 0, Login timeout expired [SQLSTATE HYT00] 2020-05-03 19:01:37 - ! [298] SQLServer Error: 11001, A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online. [SQLSTATE 08001] 2020-05-03 19:01:37 - ! [382] Logon to server '(local),1433' failed (DisableAgentXPs) 2020-05-03 19:01:37 - ? [102] SQLServerAgent service successfully stopped 2020-05-03 19:01:39 - ? [098] SQLServerAgent terminated (normally)
Can you share your Dockerfile / docker container run command? So, I can reproduce this error from my side?
I have been experimenting with the latest CU, so far I have not had any issues at all.
Cheers,
I am also looking for the root password, I want to install iputil to diagnose a connection failure, I can't do it without creating a docker file and hook it into docker-compose. it means for a simple diagnostic I need to change docker-compose and rehook it to the rest of the system while I could do it easily on the fly. when you are sharing the whole docker file, what is the point of setting a password for the root?
This allowed me to log in as root:
docker exec -u 0 -it mycontainer /bin/bash
Is it really that big of a deal to just share out the root password? I need to do some diagnostics on why the box isn't connecting the inability to do literally anything in the shell is ridiculous.
FTR, there is no root password in containers, generally speaking. In the case of the mssql, and many other containers, a run as user is created and used. If you want to connect/run in the container as root, you should specify the user to run as from the command line. docker exec --user root ... to connect to an existing container as root... you can also use --privleged for additional escallation. docker exec
That is however not really necessary... you should be able to configure at creation with the appropriate environment variable set. It isn't that people don't want to tell you, it's that it's not the correct/proper way to work.
NOTE: you can also base a new image from the existing image, if you need additional resources... I've done this to pre-initialize schema/data in container before, which again isn't the best way to work either.
edit: noticed fketchakeu already answered this after I posted my comment. -u 0
