I hope whoever is maintaining the RPM build will eventually read this!
Solution has been found!
Van
Martin Simmons wrote:
On Wed, 08 Nov 2006 09:37:26 -0800, G Armour Van Horn said:
Martin Simmons wrote:
On Wed, 08 Nov 2006 00:16:09 -0800, G Armour Van Horn said:
Scott, I hope you don't mind but I'm taking this back to the list, I
really would like as many folks looking at this as possible, and if we
figure it out the solution should end up in the list archive.
Scott Simpson wrote:
On Tuesday 07 November 2006 11:58 am, you wrote:
All of that is working perfectly with only one exception. When I did the
"psql bacula" the first line in response was
could not change directory to "/root"
What is the home directory set to for postgres in /etc/passwd? Mine
is /var/lib/postgresql (on Ubuntu).
.
[EMAIL PROTECTED] ~]# cat /etc/passwd | grep postg
postgres:x:26:26:PostgreSQL Server:/var/lib/pgsql:/bin/bash
And, since I've seen "/root" pop up in several of the errors:
[EMAIL PROTECTED] ~]# cat /etc/passwd | grep root
root:x:0:0:root:/root:/bin/bash
operator:x:11:0:operator:/root:/sbin/nologin
If I try to start the director I get this:
[EMAIL PROTECTED] bacula]# ./bacula-ctl-dir start
Starting the Bacula Director daemon
07-Nov 23:52 bacula-dir: Fatal error: Could not open Catalog
"MyCatalog", database "bacula".
07-Nov 23:52 bacula-dir: Fatal error: postgresql.c:168 Unable to
connect to PostgreSQL server.
Database=bacula User=bacula
It is probably not running or your password is incorrect.
07-Nov 23:52 bacula-dir ERROR TERMINATION
Please correct configuration file: /etc/bacula/bacula-dir.conf
Note that it's trying to run as bacula. Earlier you suggested I do "psql
bacula" as user postgresql, but I see here that it's not trying to run
as user postgresql. So I tried to do that from that account, but "su
bacula" was disallowed as the user doesn't have shell access:
[EMAIL PROTECTED] bacula]# cat /etc/passwd | grep bacula
bacula:x:100:6:Bacula:/var/bacula:/sbin/nologin
However, switching the bacula shell from /sbin/nologin to /bin/bash (the
same as user postgresql) did not change the behavior, so I restored it
to how the RPMs created it. it did allow me to do the "psql bacula"
wtihout error, but the director still failed with exactly the same message.
In bacula-dir.conf is the declaration
dbname = bacula; user = bacula; password = ""
I used the PostgreSQL admin section of Webmin to set a password for the
user and entered it in bacula-dir.conf, but there was no change in behavior.
Any other suggestions?
Firstly, note that PostgreSQL user names are not the same as Linux login names
(both have to set up independently). Confusion arises because the psql
command uses the current Linux login name as the PostgreSQL user name by
default.
Do any of these commands works?
psql -U bacula -d bacula
psql -U bacula -d bacula --password
psql -U postgresql -d bacula
psql -U postgresql -d bacula --password
All of those fail like this:
[EMAIL PROTECTED] bacula]# psql -U bacula -d bacula
psql: FATAL: Ident authentication failed for user "bacula"
I did mess with the password for user bacula last night, the Webmin
console reports that "Requires password?" is set to No for user
postgres. There is no user postgresql, but the error was still the same.
However, if I "su postgres" and immediately do "psql bacula" it happily
drops to the terminal.
Ah, OK, so your main PostgreSQL user is called postgres. I think the
Director's problem is related to the problem you get with
psql -U bacula -d bacula
Check your pg_hba.conf file. It probably lists "ident sameuser" as the
"method" and you'll need to change this to something else. You can use
"trust" if you don't care about security.
You've nailed it. The working part of the pg_hba.conf starts with this:
# "local" is for Unix domain socket connections only
# local all all ident sameuser
local all all trust
Note that the commented line with "ident sameuser" was the original,
the copy that uses "trust" was active after the edit and a restart of
the PostgreSQL service, at which point bacula-dir started up instantly.
For whoever is creating the RPMs, note that other than some messing
around trying to work around this, everything in this mess was exactly
out of the box, I didn't change a thing before the problem started. It
seems to me that the users, databases, tables, and passwords that are
created by the RPM install should simply work to start with, although
perhaps with a security scheme that might need to be improved on.
I'm just going to run with "trust" at this point, as the server is, and
probably always will be, inside my NAT network.
Van
--
----------------------------------------------------------
Sign up now for Quotes of the Day, a handful of quotations
on a theme delivered every morning.
Enlightenment! Daily, for free!
mailto:[EMAIL PROTECTED]
For photography, web design, hosting, and maintenance,
visit Van's home page: http://www.domainvanhorn.com/van/
-----------------------------------------------------------
|
