PostgreSQL installation thoughts for discussion


(Gavan Schneider) #1

I am new so apologies if this has been done to death in a former life.

Currently I am in the process of installing and configuring Homebrew:PostgreSQL after many years of “doing it my way”, and it has all worked just the way the documents said… well done and thank you.

Two items on which I would like to hear some thoughts:

  1. While I am happy enough to accept “Sudo is bad” on basic principles, I find this hard to reconcile with the need to:
    (a) install the file:homebrew.mxcl.postgresql.plist as a superuser owned item in /Library/LaunchDaemons so the postgres process will launch properly; and,
    (b) have the whole PostgreSQL directory owned by the dedicated user, e.g., postgres, which is likely to not be the user doing the homebrew installation.

  2. I would like for the versions of the installation to have a “Current” symlink in each place where a specific version could be reference, e.g.,

/usr/local/Cellar/postgresql
9.6.1
Current -> 9.6.1
Which would facilitate moving between different versions since the switch only has to be made in a single place provided other references are in sympathy, viz.,
/usr/local/bin:
brew -> /usr/local/Homebrew/bin/brew
clusterdb -> …/Cellar/postgresql/Current/bin/clusterdb
createdb -> …/Cellar/postgresql/Current/bin/createdb
etc

My suggestion is for the installation script to determine if the user wants to install the PostgreSQL as a specific user (and do it) and ask further if the .plist is to be installed (and do it). The script would decline to act if the user is not an administrator with a suitable message. This approach would minimise the evil of sudo and still get a proper result. Is this being too controversial?

The “Current” symlink is a matter of taste but does fit with a long history of unix installed packages where versioning is supported and can be useful while still being “mostly harmless”. I hope others agree.


(Mike McQuaid) #2

Neither of these are necessary and we don’t recommend either. We recommend installing into ~/Library/LaunchDaemons and using your normal user.

/usr/local/opt/postgresql provides this symlink to the current version.

An interesting idea but I’m afraid not something Homebrew will support.


(Gavan Schneider) #3

Hmmm, then something’s not how it’s meant to be:
> Rosebud:~ gavan$ cd /usr/local/opt/postgresql
> Rosebud:postgresql gavan$ ls -las
> total 64
> 0 drwxr-xr-x 14 gavan admin 476 1 Jan 17:18 .
> 0 drwxr-xr-x 5 gavan admin 170 1 Jan 17:33 …
> 16 -rw-r–r--@ 1 gavan admin 6148 1 Jan 17:45 .DS_Store
> 0 drwxr-xr-x 3 gavan admin 102 25 Oct 07:26 .brew
> 8 -rw-r–r-- 1 gavan admin 1192 25 Oct 07:26 COPYRIGHT
> 8 lrwxr-xr-x 1 gavan admin 7 1 Jan 17:18 Current -> Current
> 8 -rw-r–r-- 1 gavan admin 283 25 Oct 07:26 HISTORY
> 8 -rw-r–r-- 1 gavan admin 1171 28 Dec 10:20 INSTALL_RECEIPT.json
> 8 -rw-r–r-- 1 gavan admin 1209 25 Oct 07:26 README
> 0 drwxr-xr-x 40 gavan admin 1360 28 Dec 10:20 bin
> 8 -rw-r–r-- 1 gavan admin 639 28 Dec 10:20 homebrew.mxcl.postgresql.plist
> 0 drwxr-xr-x 29 gavan admin 986 2 Jan 11:51 include
> 0 drwxr-xr-x 24 gavan admin 816 1 Jan 17:47 lib
> 0 drwxr-xr-x 6 gavan admin 204 1 Jan 13:17 share
> Rosebud:postgresql gavan$ cd Current
> -bash: cd: Current: Too many levels of symbolic links

Nothing I can’t work around but it didn’t look like a versioning symlink to me.

Also the include, bin, lib and share directories are a bit odd in that they would not normally be on a search path and do not symlink to anything in the Cellar. Can I suggest they be dropped (especially as their content would be easily locatable at the end of a valid Current symlink), or be changed to symlinks referencing the relevant parts of the Cellar (as is done with the rest of the installation).
And, if there is a “Current” symlink in place within the Cellar, all the other symlinks could use it, which seems nicer than all of them being updated to the new version when that happens.


(Gavan Schneider) #4

Ok, policy noted. For those of us with a networked system wide (and/or needs to run when user is not logged in) the /Library/LaunchDaemons will still have to be used. And all the usual cautions are noted.
Any who venture into this area will need to add:

(key)UserName(/key)
(string)postgres(/string)
Where the ‘(’ & ‘)’ should be angle brackets as per xml

to homebrew.mxcl.postgresql.plist since postgres will refuse to run if started as a superuser.

This leads to the suggestion for the installation process to do this. If the .plist is in the recommended place it’s redundant but otherwise harmless, and if it’s to be loaded by the system it’s necessary. My thinking is that .plist problems cause a lot of grief and anything an installer can do to fix little gotchas like this is a valuable service to humanity.


(Mike McQuaid) #5

You created the Current symlink, not Homebrew. The opt link points to the latest or currently brew linkd version. I’m afraid we’re unwilling (and unable) at this stage to change the filesystem format.

Again, I’m afraid this isn’t something we wish to support. We support running as root systemwide (and its up to the process to drop privileges) or running as your normal user. We also don’t support customising plists so you’re best to do that yourself manually and/or build tooling yourself on top of ours.


(Gavan Schneider) #6

Raising a minor factual point: I do not believe I created that Current symlink (i.e., the one in /usr/local/opt/postgresql, other than to run the installer. Since there’s no real chance of me going back and stripping everything out I can’t test a reinstallation. Maybe others could have a look especially if they’ve not done any previous PostgreSQL homebrew installations. But it’s not harmful so I’ll leave it there to see what happens with the next PostgreSQL version upgrade.

I note I am not the first (and likely not the last) to ask about cautious privilege upgrades. It’s a difficult area. The folk at PostgreSQL seem to want belt and braces. None of the tools will run as superuser, and they really don’t want the postgres user to be the same as the user with write permissions on the binaries. Basically it’s a tool which can have a public interface so should not be installed in a way that would allow it’s binaries to be compromised if the server code was compromised. The rest of the security measures are well outside the scope of the installation package.

So for anyone still following this there are three levels of ownership in my now modified installation:
root: owns the .plist (which has to be modified so postgres can drop to normal user status)
myself: owns the installation and all the binaries (and I have sudo privileges)
postgres: owns the folder with the data and log files (and does not have sudo privileges)
Still to be decided is whether postgres will have write privileges on it’s configuration files (answer is likely no).

Thank you Mike for taking time to engage with my questions and have a very good new year.


(Mike McQuaid) #7

The symlink named Current was not created by Homebrew.

Have a good new year too!