I'm trying to connect to Postgres in a C program using libpq. When I'm running under my own username (which is the same as the username I've created for my Postgres database) everything is fine. When I try to run the program under root it fails with:
FATAL: Peer authentication failed for user "jqpublic"
In both cases the conninfo string I'm passing to PQconnectdb is something like:
dbname=somedb user=jqpublic password=somepassword
If I add a host option to the conninfo, the connection succeeds, but then I'll be connecting over TCP/IP which my tests show is measurably slower than the default UNIX sockets. Is there a way to use the UNIX socket while running under root (or another user with a name not the same as the DB user)?
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 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...
While connecting to sybase, i'm trying to start my server using
startserver
but, i have encountered the above error.
The usual way to start a Sybase instance is:
startserver -f RUN_SERVER_FILENAME
e.g RUN_MY_INSTANCE or similar depending on what your Sybase instance is called. Once its started correctly then you should be able to connect. This is usually in the $SYBASE/$SYBASE_ASE/install directory on a default installation for Unix.
More info here:http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc30191.1570100/doc/html/san1367605056632.html
Are you getting any other messages? You should look at the instance errorlog to check for problems on startup.
I am in the process of setting up a remote PostgreSQL database. The server is running CentOS 7 and PostgreSQL-9.5. Currently, I am testing whether users can query the database. To this end, I have the following:
import psycopg2
host = 'server1'
dbname = 'test_db'
user = 'test-user'
sslcert = 'test-db.crt'
sslmode = 'verify-full'
sslkey = 'test-db.key'
dsn = 'host={0} dbname={1} user={2} sslcert={3} sslmode={4} sslkey={5}'.format(host, dbname, user, sslcert, sslmode, sslkey)
conn = psycopg2.connect(dsn)
The connection times out with the following error:
psycopg2.OperationalError: could not connect to server: Connection timed out (0x0000274C/10060)
Is the server running on host "server1" (xx.xx.xx.xx) and accepting
TCP/IP connections on port 5432?
I have tried several things (given below). I'm trying to pin down on which side the problem exists: the Python end or the database configuration:
Is the Python syntax correct?
Where can I find documentation concerning the DSN arguments, such as sslmode, sslcert, and sslkey?
Is there a different package better suited for this kind of connection?
What other questions should I be asking?
I have checked the following:
'server1' was entered correctly and the IP address returned by Python corresponds
All other arguments are spelled correctly and refer to the correct object
Postgres is currently running (service postgres-9.5 status shows "active")
Postgres is listening on port 5432 (netstat -na | grep tcp shows "LISTEN" on port 5432)
SSL is running for my table (psql -U username -W -d test-db -h host returns SSL connection (protocol: TLSAv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
user=test-user has been added to postgres as a Superuser
My understanding is that psycopg2 is the appropriate package to use nowadays. I have scoured the documentation and don't find much information regarding SSL connections. I found this SO post which talks about SSL connections using psycog2, but I can't match some of the syntax to the documentation.
In the Python script, I have tried the following in all 4 combinations:
Use sslmode='require'
Use absolute paths to test-db.crt and test-db.key
It appears that you have presented yourself with a False Dilemma. The problem does not lie solely between Python and the database configuration. There exist other entities in between which may cause a disconnect.
Is the Python syntax correct?
Yes. The syntax is described in the psycopg2.connect() documentation. It has the form:
psycopg2.connect(dsn=None, connection_factory=None, cursor_factory=None, async=False, **kwargs)
where the DSN (Data Source Name) can be given as a single string or as separate arguments:
conn = psycopg2.connect(dsn="dbname=test user=postgres password=secret")
conn = psycopg2.connect(dbname="test", user="postgres", password="secret")
Where can I find documentation concerning the DSN arguments, such as sslmode, sslcert, and sslkey?
Note that as DSN arguments, they are not part of the psycopg2 module. They are defined by the database, in this case Postgres. They can be found in the chapter on Database Connection Control Functions, under the Parameter Key Words section.
What other questions should I be asking?
Perhaps,
Is there anything between the host (the PostgresSQL server) and the client (the local Python instance) which could prevent communication?
One answer to this would be "the firewall." This turned out to be the problem. Postgres was listening and Python was reaching out. But the door was closed.
Please don't move this question to askubuntu as I think this question is not OS-specific.
When I invoke the createuser postgres command (for now it doesn't matter if I provide any parameters or not), I'm getting this error:
createuser: could not connect to database postgres: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
Normally it means that the postgres server is down but not this time:
pg_lsclusters
Ver Cluster Port Status Owner Data directory Log file
9.4 main 5432 online postgres /var/lib/postgresql/9.4/main /var/log/postgresql/postgresql-9.4-main.log
sudo service postgresql status
9.4/main (port 5432): online
But it's true that there is no /tmp/.s.PGSQL.5432 file because my configuration file (/etc/postgresql/9.4/main/postgresql.conf) has this line:
unix_socket_directories = '/var/run/postgresql'
So I don't really understand why createuser whants to access /tmp/.s.PGSQL.5432? Can this path can be hardcoded into the createuser binary? I don't see any command line argument to specify the settings file location for createuser...
Have you started the service?
service postgresql start
The postgresql.conf file is read by the database server, but not by client applications (such as createuser, psql, ...). (In fact, the server configuration file cannot be read by client applications because the client would have to connect to the server, which could be halfway across the world, before it could possibly know where that configuration file lives).
Instead, you have to tell your client application where to find the socket directory.
If your client application (createuser) is connecting to the local host (which is must be because you are not specifying a different host), you use the host parameter to specify the name of the socket directory.
For example:
createuser -h /var/run/postgresql newusername
See http://www.postgresql.org/docs/devel/static/libpq-connect.html#LIBPQ-CONNECT-HOST
Hope that helps.