> >> This isn't happening for a number of reasons, the most
> obvious being
> >> that we cannot require initdb to be run interactively.
> (That stern
> >> warning will not impress /dev/null.)
>
> > This is the very reason --pwfile was added.
>
> No, that does not address the objection in the least. That
> simply allows a level of indirection. There still has to be
> user interaction going on somewhere to supply the password.
Right. I realised that after posting.
I still think it would be a good move to add a switch you have to
explicitly put in there to make it use "trust" auth by default. This can
spit out some warnings, which will of course be ignored by RPM and such
packagers. But for those installs the package creator made the
decisions, and we will still get most of the
install-from-source-but-don't-know-about-the-switches people.
It would, of course, be better if the RPMs could do this as well. Don'tk
now how they work, though, but I assume this is the part that has been
discussed before by people who do.
Or we could initdb with requiring password, and just refuse logins with
blank passwords. That way you get a system that can be installed, but
you cannot actually connect to it until you have set a password. We'd
need to supply a tool that could change the password without connecting
(since you can't connect with no password, catch-22) but that should be
fairly straightforward with a standalone backend, right?
For reference, does anybody know how other databases do it? Like MySQL
or Oracle (which both run on RedHat, which should mean RPMs, right?) I
know MSSQL refuses to install with blank passwords these days (didn't
use to be that way, no, which is why there are still a lot of
installations out there with blank sa passwords).
//Magnus