So, I am attempting to create an install script for my application (targeting Ubuntu 16). It has to create a postgresql user, grant permission to that user to authenticate via password, and grant permission to that user to authenticate locally. I only want to grant permission to do that on one database, the application database. So I need to insert the line local databasename username md5 above the lines that reject unknown connections, e.g., in the "Put your actual configuration here" section of pg_hba.conf. (pg_hba.conf uses position in the file to determine priority: first rule encountered that matches the connection gives the final result.)
To add this line, my script runs:
sudo awk '
/# Put your actual configuration here/ {
print "local databasename username md5"
}
{ print }
' /etc/postgresql/9.5/main/pg_hba.conf
# other setup
service postgresql restart
But that's less than optimal. First, the version number will change in the future, so hardcoding the directory is poor. Second, that's making a comment in someone else's project an actual structural part of the config file, which is a horrible idea from all possible points of view in all possible universes.
So my question is twopart. First, is there a good, correct, and accepted method to edit pg_hba.conf that I can use in an installation script instead of kitbashing about with text editors?
Second, if there is no good answer to the first part: is there a programmatic way to ask postgresql where it's pulling pg_hba from?
Is there a programmatic way to ask postgresql where it's pulling pg_hba from?
show hba_file;
-- or
select current_setting('hba_file');
Debian tool chain
So my question is twopart. First, is there a good, correct, and accepted method to edit pg_hba.conf that I can use in an installation script instead of kitbashing about with text editors?
Yes, however, you'll probably find it unsatisfactory.
Upstream, PostgreSQL doesn't support multiple versions and installs with their build tools. Debian does. So Debian has invented a concept of a cluster which is essentially a name and a version number.
Building a tool on Ubuntu or Debian, you should also probably use a name and version number.
Second, if there is no good answer to the first part: is there a programmatic way to ask postgresql where it's pulling pg_hba from?
Yes, there is a tool called pg_conftool. The default cluster's name is main. If you want the 9.5/main cluster. You can do this..
pg_conftool -s 9.5 main show hba_file
/etc/postgresql/9.5/main/pg_hba.conf
You can see conftool can make use of a version and name, but strictly it may not require one.
/usr/bin/pg_conftool [options] [<version> <cluster name>] [<configfile>] <command>
If you want to know more about a cluster in this context, check out check out all the binaries starting with pg_* but first and foremost pg_ctl and pg_ctlcluster (the debian wrapper)
Related
I'm following instructions here and it says that I will find a bitcoin.conf file Windows: %APPDATA%\Bitcoin\ and
To use bitcoind and bitcoin-cli, you will need to add a RPC password to your bitcoin.conf file. Both programs will read from the same file if both run on the same system as the same user, so any long random password will work: rpcpassword=change_this_to_a_long_random_password
However When I navigate to %APPDATA%\Bitcoin\ I don't see a bitcoin.conf file.
So What do I do? Do I add a bitcoin.conf file? There is a bitcoin-conf.md file in doc in my bitcoin install directory so maybe somthing todo with that? I really don't know. Thanks for pointing me in the right direction.
That guide does not take into account the fact that you do not have to add any RPC user or password to your configuration file for the past some years.
Bitcoind will generate a cookie that allows the CLI (command line interface) to communicate with the Bitcoin daemon using RPC without the user having had to give it a single thought.
That is a developers' guide, so developers may have more complex requirements that are solved if they specify their own RPC authentication settings, such as running multiple wallets, or possibly exchange software that communicates with the wallet or multiple wallets.
bitcoin.conf being optional, it is not by default created, and is not needed for ordinary usage, only becoming necessary when the user or developer has particular, non-default settings to set.
The possible settings can be found by the help command bitcoind -help and lists a number of command line parameters (beginning with a dash or hyphen) that can be typed or pasted after bitcoind on the command line, but can be put in a text file named bitcoin.conf without the minus sign before the command. For example: -connect=IPAddress becomes simply connect=IPAddress in the conf file.
For creating suitable rpcauth (username and hashed password), and rpcuser and rpcpassword values, I've found some resources such as https://github.com/jlopp/bitcoin-core-rpc-auth-generator
Rather than serving JLopp's RPC auth generator locally you can simply copy from, or use a Python script found in the Bitcoin repository under the folder named "share", you will see a folder called rpcauth which contains the rpcauth.py script and a small explanatory file called README.md.
You have to create this file and put a single line rpcpassword=<your_password> in it.
bitcoin-conf.md contains documentation for this btcoin.conf and particularily states:
The configuration file is not automatically created; you can create it using your favorite text editor.
Recommended reading this doc. It may help you to facilitate running your node.
i am really super frustrated/lost so I would appreciate any help I can get here. I have searched all over Google and SO and it seems nobody has had my problem yet.
Symptom: when i try to run psql in command line, or connect to any GUI postgresql client like Postgres or Postico, I get errors like FATAL: password authentication failed for user <myusername>. It asks me for my username where it shouldn't ask for one.
All the advice online goes along the lines of "find your pg_hba.conf file and add these magic lines to it", but here's the thing: I don't have a pg_hba.conf file! The normal location (on a Mac) seems to be in /etc/postgresql (like this) and this folder just plain doesnt exist on my mac even though I have installed all the other postgresql paraphernalia.
There's a remote possibility that my pg_hba.conf is in some other location but guess what! i need a running psql instance to find it! whoop-dee-heckin-do chicken and egg!
I notice these instructions are also like 3+ years out of date so there could be a change in the location or the filename and I have no idea what to find. Please help! I just want to connect to my sql database in localhost to learn web development.
thanks very much.
I am trying to set up a test environment on my mac (os 10.12) and it requires Fishbowl/Firebird DB. No matter what I do i bounce back and forth between these two errors:
isql localhost:/Users/me/Fishbowl/database/data/EXAMPLE.FDB
which gives me:
Your user name and password are not defined. Ask your database
administrator to set up a Firebird login.
And anything to do using gsec to create user or change password:
And:
Statement failed, SQLSTATE = HY000 operating system directive stat
failed
-Bad file descriptor
This is supremely frustrating. Fishbowl Client itself seems to hit this DB just fine. I have chmod 770 the /tmp/firebird directory and even tried to chown the example.fdb file itself.
Can anyone tell me how I might hit this DB from my java app or commandline? Both ways produce these errors.
1) Your connection line starts with "localhost:". That means you user TCP/IP connection to reach the database server. And the database server is running in a separate process. That means chmod and chown should not matter as long as there is firebird daemon server running and listening at TCP port ( default is 3050 AFAIR, you can read the value of your installation in the text file firebird.conf ).
Indeed, there is so-called "embedded server" or "embedded mode" where the server is loaded as DLL/SO library into the application. But then the connection string can not have network protocol prefix, so that should NOT be your case.
2) You can check documentation at http://firebirdsql.org/manual/isql-switches.html to specify your user and password in the isql command line. The Firebird has one built-in superuser, namely "SYSDBA". Regarding the password it might be a bit complicated.... It differs by Firebird version and platform
2.0) whatever SYSDBA password might be set by the server installation, if server comes in a bundle with some application the said application can override it later. Then you would either have to contact application developers or try to remove the bundled FB and install your own vanilla one, risking rendering the application no more functioning.
2.1) Windows installation of FB 2.x sets the "default" SYSDBA password as "masterkey" (only 8 first symbols actually matter)
2.2) Linux installation of FB 2.x generates a random SYSDBA password and saves it into a text file in Firebird folder.
2.3) MacOS ? Don't know. Perhaps it is closer to Linux than to Windows. So try to find such a text file and try "masterkey"
2.4) With FB 3 the authentication methods and configuration was greatly overhauled, so... So it is quite hard to tell something specific. At least for me.
3) I don't know what Fishbowl ever is, but Google suggests this: https://www.fishbowlinventory.com/wiki/Fishbowl_for_Mac
If that is so, then check the bottomline examples at that page. They stress that you should sudo all those commands. That also makes sense because
3.1) Firebird daemon might have "trusted authentication" enabled, mapping FB users to Operating System users. On UNIX that would at least map SYSDBA to root. On Windows - to Administrator (however it is localized). This does not have to be enabled, but if it is then sudo UNIX command is exactly what makes applications run with OS superuser grants and might explain lack of user and password in the command line examples.
3.2) Firebird embedded server/mode work as part of an application process, and especially with CS (Classic Server) package on UNIX the command line utilities tend to fall into this mode. Then again it needs to be run as root to read highly sensitive data from Firebird Security Database, thus the need to sudo the command. Granted, I do not think your isql command might ever run in embedded mode - because you do specify "localhost:' prefix. But the example at the wiki link above - backup and restore - they use local connection strings, so they probably do run as embedded. So that might give you yet another hint - to try remove "localhost:" prefix from the connection string and to sudo isql rather than running it from regular user. It would hardly be a normal mode, but for test purposes why not.
Hope this helps.
PS. you might also try this Firebird IDE - it is simplistic, but again, for testing purposes... http://www.flamerobin.org/dokuwiki/wiki/manual
Being fairly new to the Linux environment, and not having local resources to inquire on, I would like to ask what is the preferred method of starting a process at startup as a specific user on a Ubuntu 12.04 system. The reasoning for such a setup is that this machine(s) will be hosting an Input/Output Controller (IOC) in an industrial setting. If the machine fails or restarts, this process must boot automatically..... everytime.
My internet searches have provided two such area's to perform this task:
/etc/rc.local
/etc/init.d/
I ask for the specific advantages and disadvantages of each approach. I'll add that some of these machines are clients and some are servers, but all need to run an IOC, and preferably in the same manner.
Within what ever method above is deemed to be the most appropriate, a bash shell script must be run as my specified user. It is my understanding all start up process are owned by root. So I question if this is the best practice:
sudo -u <user> start_ioc.sh
If this is the case, then I believe it is required to create a file under:
/etc/sudoers.d/
Using:
sudo visudo -f <filename>
Where within this file you assign the appropriate rights and paths to the user. Most of my searches has shown this as the proper format:
<user or group> <host or IP>=(<user or group to run as>)NOPASSWD:<list of comma separated applications>
root ALL=(user)NOPASSWD:/usr/bin/start_ioc.sh
So for final additional information, the ultimate reason for this approach, which may also be flawed logic, is that the IOC process needs to have access to a network attached server (NAS). Allowing root access to the NAS is I believe a no-no, where the user can have the appropriate permissions assigned.
This may not be the best answer, but it is how I decided to complete this task:
Exactly as this post here:
how to run script as another user without password
I did use rc.local to initiate the process at startup. It seems to be working quite well.
I'm writing a Ruby script that uses the PG gem to set up a database connection and send files. I'm structuring it to take variables for the hostname, username, database name, and port. In a Shell script I've written to manage some companion tasks, I rely on the password stored in ~/.pgpass instead of having the user enter a password for psql because there are a lot of transactions and sometimes entering the password can fail for no apparent reason (and it sucks entering it in 20 times).
Will PG access the same source when a password isn't explicitly provided? By convention, I've included the password in the file, but since this is being pushed to an internally available repo, I'd prefer not to have that information in my file. I'm trying to test the functionality now, but was wondering if anyone in the SO community knows the answer to this question. If PG doesn't access the .pgpass file, is there a way to reference the variable and write it into the file without prompting the user to enter the password?
Thanks in advance for your help.
Yes, it will use ~/.pgpass just like any interface based on libpq, the C PostgreSQL client library.
However, a good alternative for not having the password in a file is to have it in the PGPASSWORD environment variable. If you set this in a script, it will be inherited by every program it calls.
PGPASSWORD when set will be used as the password for any libpq connection, which means the majority of programs that connect to PostgreSQL.