I am aware of the fact that we can run a Q process with the -p parameter which enables other instances to connect to it and enables also a web interface on that port.
Is there a way how to secure the connection so there will be some kind of authorization? In the moment I don't like the fact that anyone can view and even execute queries on my database when it is running with the -p parameter.
You can add authentication by using -U:
-U /path/to/password.txt
This file contains user:password where password is result of in q md5"password" and strip off 0x in front.
there's also the .z.pw and .z.ac hooks, which can be used for more complex auth logic
Related
I'm trying to push artifacts to Artifactory (on Linux) and struggle with the whacky syntax. As I understand it there are multiple different ways to achieve this. I've kind of settled on this:
curl -uMyUser:MyPassord {...}
All stated without quotes. I've managed to make it push once, however since then I've fiddled around with it and keep getting a bad credentials error.
Is there a more robust way of doing this, preferably so that control sequences within the password don't cause me additional trouble, since I post the password unquoted.
We can deploy using the below curl command to Artifactory,
curl -u myUser:myPassword -X PUT "http://localhost:8081/artifactory/my-repository/file.txt" -T myNewFile.txt
If it fails with bad credentials, are you using any special character in the password?
Otherwise, the best approach is to generate the API Key and use it as below in the curl,
curl -H "X-JFrog-Art-Api:<API_Key_here>" -X PUT "http://localhost:8081/artifactory/my-repository/file.txt" -T myNewFile.txt
In this way the password issue should be resolved plus API Key ensures proper coating of your password and username.
Suppose we have enabled the "disable blank userid access" option in database options, then is there any way without using -U or -P parameter to login to openedge or progress application?
Thanks
You can avoid both the interactive login and the use of -U and -P by implementing the CLIENT-PRINCIPLE object and using that to assert an identity prior to attempting to access data.
A good place to start: http://knowledgebase.progress.com/articles/Article/P147947
It completely depends on your version of Progress from my reading. I believe though that if you're on a reasonably modern version of Progress (10.2B or later) then there is no way to access the data without a -U or -P parameter. It should be used in conjunction with the 'use runtime permissions checking' option. I hope this helps.
I have two databases set up as part of the same Postgresql 9.4 database cluster, and I'm trying to access a table in one of them from the other using a postgres_fdw. I have it all set up and working as a superuser, however when I try to access the foreign table as a normal user, I get the following error:
ERROR: password is required
DETAIL: Non-superuser cannot connect if the server does not request a password.
HINT: Target server's authentication method must be changed.
Now I understand that this is because I have the server set up with trust authentication for certain subnets, including Its own. However, in the 1 USER MAPPING I created, I did specify a password, with the hope that doing so would force it to use password authentication. No such luck apparently.
As such, my question is if there is any way around this somewhat onerous requirement? Is there a way to force this connection, or a specific user, or the like to use password authentication? Or some way to disable the requirement? Or is my only option to change the configuration to require passwords, and deal with whatever that breaks?
As Nick Barnes pointed out in a comment, pg_hba allows different authentication rules for specific users. As such, the solution to this issue was to simply create a user specifically for these FDW connections, and set that user in the pg_hba.conf to require a password. That way my trusted web apps on the trusted network can continue connecting as usual, but the FDW can get the password request it requires.
You can't force FDW to use a password: the server on the other end must request the password. the usual default for local socket connections is no password.
Try connecting via TCP instead of using local sockets: add host=localhost to the connection parameters, that will usually fix it.
Can someone point me to a piece of documentation that specifies the matching rules psql applies to the .pgpass file? I always spend a few extra keystrokes trying to find the right combination of host, port, database, username to get it to connect.
Some things are obvious (i.e. if my linux username is not the same as my postgres username than I need to specify it) but based on what I've seen there is some non-obvious behavior.
Here is the documentation you are probably looking for. It explains the rules pretty well.
Just so this isn't a link-only answer, here are the rules:
Each .pgpass entry is on its own line and has the following format:
hostname:port:database:username:password
You can use a wildcard (*) for each field except password
If you use wildcards, put more specific entries first
You can use for instance localhost:*:*:foo:password to specify password for user foo on your local machine regardless of the database you are connecting to or the port the Postgres is actually running on.
I did not find any reference to user related commands for the jenkins-cli tool.
I need this to automate deployment.
Any comeback?
To use jenkins internal database simply use the following command.
echo 'jenkins.model.Jenkins.instance.securityRealm.createAccount("user1", "password123")' | \
java -jar jenkins-cli.jar -s http://localhost:8080/ groovy =
This will create user=user1 with password=password123
If you have any existing user and have restricted anonymous access to your jenkins, you can specify the username and password with
--username "user_name" and --password "password"
Maybe you don't want to use Jenkins' internal user database at all. There are a host of "Authentication and User Management" plugins.
If you like MySQL, there is a MySQL authenticator (it reads a table of users and passwords), and your "adduser" command could do an insert on that table.
If you like flat files, there is a "Script Security Realm", where you can authenticate with an arbitrary script. Write a file with user and password combos in your favorite format, write an "adduser" script that writes to it, and write an auth script that reads the file and determines whether to authenticate the user.
You can also hook up to an LDAP server, Active Directory, Atlassian Crowd, Unix user accounts (pw_auth), or whatever authentication your application server uses (if it's running off of a Tomcat server, for instance, you can tell Jenkins to let Tomcat authenticate users, and set up Tomcat to do it however you want.
If you specify in more detail what you are trying to do people here may help you better. That said, here are some pointers:
All CLI commands are available via http://[jenkins-server]/cli. What's not found there is not available via CLI. You can specify user name / password via --username and --password (or --password-file) options in CLI commands.
Another option for Jenkins automation is to use Python JenkinsAPI.
You can also use tools like wget and curl to perform certain actions (such as starting a build). There you may use user-specific tokens instead of username/password.
Here's another link that can be helpful.