I am trying very simply to download MS SQL Server to my Mac using Docker.
As I was following a video, I reached a road block because my password was too short and Docker exits the program. (I received the error below). Can you please advise on how to change my password using the terminal or elsewhere?
ERROR: Unable to set system administrator password: Password validation failed. The password does not meet SQL Server password policy requirements because it is too short.
The container only accepts SQL auth and you've locked yourself out by making SQL auth impossible for the only SQL auth account that exists. Kind of a catch-22 because you can't log in to make your password long enough so that you can log in. I wish docker recognized this when you first fire up the run command instead of when it is too late, but this is where we are.
While it may be possible to hack into mssql-conf or the mssql-server service to change the password, honestly, the easiest thing for you to do is to start over with a new container. The nice thing about containers is that this is exactly what they're designed for. Run this:
docker ps
This will list the containers you have created; the one in question might be named something like a5de64..., so then just do:
docker stop a5
docker rm a5
Then create a new container with a password that is both long enough and strong enough:
docker run ... -e SA_PASSWORD=d0_n0t_be_l#zy_h3r3 ... mcr.microsoft...
Related
Setup: Progress 11.5 databases sitting on Linux (CentOS) server, with proenv available.
I'm trying to connect to Progress database through proenv and sqlexp. I'm unable to, since I don't know the user and password. There's no way I can obtain it from someone else, as nobody knows these credentials. I have root access on this server.
How can I connect to this database so that I can later create another account to use through ODBC?
What I've tried already is:
Being on root account, opening up proenv by
/dlcloc/dlc-11.5/bin/proenv
which brings up proenv, and then when I try
sqlexp -db rep -H localhost -S 2502 {-user ?? -password ??}
given that there's a db within
/dbloc/prod/rep/
with files like rep.db, rep.lg, rep.b1, rep.d1 and some other files avilable on localhost under port 2502 (confirmed through ps aux | grep rep)
I get an error even without user and password
Error: [DataDirect][OpenEdge JDBC Driver][OpenEdge] Access denied(Authorisation failed). (8933)
Which is obvious from my side, but there's no way to get user and password. How can I go around this given my environment to be able to establish a successfull connection?
Additional note: There's a special user called progressuser under which database is created, but impersonating that user from root as su progressuser and going through the same process yields the same results.
You could try accessing the database using the native 4GL broker. And possibly try this solution:
https://knowledgebase.progress.com/articles/Article/P9483
First run that proenv-script, it will set paths and environment variables.
Then identify on which port the 4GL broker runs. If you dont know: check your database log file (rep.lg). Look for something like:
[YYYY/MM/DD#HH:MM:SS.sss+TZ] P-XXXX T-YYYY I BROKER 0: (4262) Servicename (-S): NNNN.
The Ns will be your port. It might possibly be a service name to check in /etc/services
Then access the Progress Editor with a connected database:
pro -db rep -H <IP-address/domain name> -S <port number/service name>
You should see a rudimentary editor. To run something you press Ctrl+X or F1. To access the menu F3. To exit something F4.
Access the Menu using F3 and arrow-key your way to Tools -> Datadictionary. Now you should be able to follow the steps in the link provided above.
Perhaps its a good idea to make sure you have a valid backup before you start messing around with the users...
I want to shutdown a remote DB with proshut
https://knowledgebase.progress.com/articles/Article/P20918
i get this error:
"Shutdown request denied because you are an invalid user, remote shutdown is not allowed, or the database is enabled for Failover Clusters. (12566)"
Where can i define the user for the shutdown request?
You're seeing the error because the database was started with the specific flag to disallow remote shutdown. Since you're probably not root, you will not be able to go around that.
More info on the normtshutdown db flag:
https://knowledgebase.progress.com/articles/Article/P94213
dbman -stop -H 192.168.1.123 -port 20931 -u j.verne -db pool_05_xyz
followed by my windows password stops the remote DB
(i dont know why this works...)
The problem seems to be that OpenEdge Explorer starts the DB with SYSTEM and not the user that is logged in.
When i try to stop it remotely my windows login name is used to send it as user to the server. At the moment i dont know how to solve it.
Maybe i can stop the db with DBMAN command, but this rejects my login.
Starting the service with a user account makes it possible to connect and stop it
AdminService for OpenEdge 11.4 Manages Progress OpenEdge servers Wird ausgeführt Automatisch j.verne#treasureIsland.de
But this is my local solution, i dont know if this is ok for the real remote server
I'm still learning how to work with a databases using python libraries
An operational error has occurred while executing the following code
screenshot
Code snippet:
import pymysql
db1=pymysql.connect(host="127.0.0.1",user="root",password='root',port=3306,db='world')
a=db1.cursor()
sql='SELECT * from CITY'
print(a.execute(sql))
Error:
(1045, "Access denied for user 'root'#'localhost' (using password: NO)")
what could be the reason for this?
An operational error has occurred while executing the following code screenshot. what could be the reason for this?
Error in question is:
(1045, "Access denied for user 'root'#'localhost' (using password: NO)")
It reveals that you are attempting to connect without password while you actually supplied one in connection arguments. This was at one point known bug with pymysql so answer can be version dependent. If you can normally connect to mysql with mysql -u root -proot world (database, password and user from your connect arguments) that means that your database is indeed with proper credentials and expects password while connect method is not sending one, most probably due to old version. On the other hand if you can't connect then most probably your root password is blank and you need to set it properly. Also there is option that you have issues with access to database 'world' for root user.
Why not asking on dba.stackexchange: the description says it is for professionals, which I am not and SO has its "for enthusiasts" part.
I have an error
"Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'"
This is a common error with several possible reasons and solutions. The problem is that I have no knowledge of the database and server administration and credentials authentication topics, thus I will need to spend some significant time understanding what is being said and proposed.
Before I do that I would like to ask if it might be possible for me not to be able to solve the problem due to technical limitations. I will describe the situation in more detail now.
There is an MS SQL Server A with database Adb and table dbo.At. I can read from it. There is also an MS SQL Server B. I can read and write here.
I have MS SQL Server Management Studio 2012 open on my computer. I have a connection with server A open with query "select * from Adb.dbo.At" which works just fine. The connection used Windows Authentication.
I have a connection with server B (Windows Authentication as well) with query "select * from A.Adb.dbo.At" which results in the aforementioned error.
At this point I do have read access to A, I have read and write access to B. I can export data from A and then import it to B using my computer, i.e. I can do a kind of a copy paste and I will end up having what I want. There is no insurmountable wall between these 2 servers with me being the middle man. I simply would like to make it easier. Before I dwell on SPNs, delegations, Kerberos, Active Directory and whatnot I would like to ask if, assuming that I have nothing more than read on A and read/write on B, I might not be able to solve the issue?
It seems I have a "double hop" problem.
https://blogs.technet.microsoft.com/askds/2008/06/13/understanding-kerberos-double-hop/
I have found a workaround. I can use Server Agent on server B. Using this I can use the server to perform some actions, for example query other servers. The Agent jobs are of a specific type (like T-SQL script). For specific job types the Agent can run the jobs in "run as" mode (requires a proxy). I created a proxy referring to my normal Windows login. Sadly T-SQL script type job cannot be executed in "run as" mode. But PowerShell type job can. PowerShell can also execute SQL statements. Thus I have created PowerShell job running with proxy with the command being:
SQLCMD -Q "select * into Bdb.dbo.Bt from A.dbA.dbo.At" -E
This solved my problem.
I'm getting this error when running an SSIS package through SQL Agent
Failed to acquire connection "ORACLE ADO.NET". Connection may not be configured correctly or you may not have the right permissions on this connection.
When I log on as the SQL Agent User and run the ssis package directly it is fine. When I then execute it through the SQL agent job, it fails.
I've read around extensively on this topic, and it seems a lot of the advise concerns how you are logged in, configuring of proxy accounts, etc, etc, etc, none of which has been helpful.
I am logging onto an Oracle database with an ADO.NET conncetion. The connection string is as follows (datasource, userid and password have been changed):
Data Source=DATASOURCE;User ID=userid;Password=password;Persist Security Info=True;Unicode=True;
I'm loading this from a registry setting using package configuration. To check that I am getting the correct string, I am writing it into a temporary log table. I am definately getting the string I need from the correct registry setting.
I've tested the oracle login credentials though PL/SQL developer, and it lets me login just fine.
As far as I can tell, as I'm using an explicit user name and password for the Oracle connection it just shouldn't matter who the SSIs pacakge is run as. The only point of failure that Ican see would be the reading of the information from the registry, but that seems fine.
I'm really quite baffled, I must confess, and would appreciate any help some of the splendid experts here can offer.
Many thanks,
James
Ok, tracked this one down after quite a lot of pain.
It was working fine on one environment, but not another, so I fired up Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) and ran a package through the SQL Agent job, comparing which system entities were hit on each enviroment.
On the failing environment, at the point of the bulk transfer operation, the package attempted to get the Oracle 11 client DLL, and then hung.
I knew that this was installed, and, moreoever, the DLL path was a system environment setting. After further investigation it was revealed that the server had not been rebooted since the Oracle Client install and the SQL Server Agent process had not bee recycled.
Yes, can you believe it, the old helpdesk fix "Can you reboot your computer?" worked.
Sigh!
We had issues at a client with running packages connecting to Oracle before stored on our sql server instance. The work around we found was to change the package property, protection level, to "Dont save Sensitive Data" and for security purposes, we encrypted the username and password in the package configuration that was decrypted by a udf in sql server. Of course, before you try the whole encryption part, I would recommend putting the username and password in the package configuration without encrypting the values to see if changing the protection level setting is the solution to your specific problem. I hope this helps.
I was getting this error when tnsnames.ora file did not have a valid entry for the environment