> >> 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 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
