[Postgres/ISP] - checksetup (or Bugzilla) using template1 database

RESOLVED INVALID

Status

()

RESOLVED INVALID
12 years ago
11 years ago

People

(Reporter: raczkowk, Unassigned)

Tracking

Details

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6

Hi,

ISP providers very often disable access to template1 database and disable ability to create databases. 

Error from checksetup.pl:

checksetup.pl: Can't connect to the database.
checksetup.pl: Error: FATAL:  no pg_hba.conf entry for host "xxxx", user "xxx", database "template1", SSL off

It is any workaround for this problem?

Reproducible: Always

Steps to Reproduce:
1. Disable access to template1
2. Try to install bugzilla



Expected Results:  
1) Option for disble database create process 
2) Remove usage template1 database
3) dumped postgress schema for manual database installation

Comment 1

12 years ago
This is a support question, ask it on the bugzilla-support list. (This is not a bug in Bugzilla.) You can see information about the support list at:

  http://www.bugzilla.org/support/
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → INVALID

Comment 2

11 years ago
I have to wholeheartedly disagree with your assessment of "this is a feature, not a bug." This is a totally valid concern and the checkconfig.pl script is broken by making these assumptions.

template1 is a maintenance database that we do *not* grant remote access to. The checksetup.pl script should *not* under any condition assume that it has access to this database.

We printed the following stack trace to determine where template1 was hardcoded into the bugzilla postgres libraries:

| Bugzilla::DB::Pg::new line 178
| Bugzilla::DB::_connect line 160
| Bugzilla::DB::connect_main line 1526

checksetup.pl (line 1526) has the offending call. There should be two cases in this check. First, you should try to connect to the *configured* database. A good sysadmin isn't going to let a 3rd party app connect to any database of its fancy. If you can't connect to the configured database (perhaps because it's not configured), then, and only then, should you fall back to the maitenance database.

The check itself should only it can't connect to the database, but only after attempting the configuration given by the SysAdmin in the configuration file.

We changed checksetup.pl line 1526 to read:
    my $dbh = Bugzilla::DB::connect_main(0);

as a workaround to this problem.

Comment 3

11 years ago
It's a support question. Trust me.

All you had to do was disable $db_check in localconfig. You should have just asked on the support list, like I said.
You need to log in before you can comment on or make changes to this bug.