Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: DBMail: users

FATAL: database "dbmail" does not exist? - and no dbmail logs

 

 

DBMail users RSS feed   Index | Next | Previous | View Threaded


loupicciano at comcast

May 16, 2010, 4:41 AM

Post #1 of 4 (700 views)
Permalink
FATAL: database "dbmail" does not exist? - and no dbmail logs

Hello dbmailers!


Am attempting setup of a new installation of dbmail - using Postfix/PostgreSQL.


We do have a backend database set up, called 'dbmail' and Postfix is apparently trying to connect, but is saying 'connect to pgsql server localhost: FATAL: database "dbmail" does not exist?'


Note: we can connect correctly using same login details using psql, so don't think this is the problem.
Also, both queries in the sql interface files return 0 results, as they should, right?


Last, I cannot get dbmail to write to either of its logs.


Clearly, we're getting close - can someone suggest something? Thanks, Lou


paul at nfg

May 16, 2010, 6:14 AM

Post #2 of 4 (675 views)
Permalink
Re: FATAL: database "dbmail" does not exist? - and no dbmail logs [In reply to]

Lou Picciano wrote:
> Hello dbmailers!
>
> Am attempting setup of a new installation of dbmail - using
> Postfix/PostgreSQL.
>
> We do have a backend database set up, called 'dbmail' and Postfix is
> apparently trying to connect, but is saying 'connect to pgsql server
> localhost: FATAL: database "dbmail" does not exist?'
>
> Note: we can connect correctly using same login details using psql, so
> don't think this is the problem.

How sure are you? Please share some details like the relevant parts of
your dbmail.conf and the command-line test you use.

> Also, both queries in the sql interface files return 0 results, as they
> should, right?

Both queries? What queries are those?

> Last, I cannot get dbmail to write to either of its logs.

Not even syslog??? Makes me wonder if you are 1) running the binaries
you think you are running, 2) using the dbmail.conf file you think
dbmail is using.... You wouldn't be the first :-)

> Clearly, we're getting close - can someone suggest something? Thanks, Lou

Yes, send us your trace_syslog=5 logs. Oh wait, no logs you say.

Try 'dbmail-imapd -n -f /etc/dbmail/dbmail.conf' with dbmail.conf
containing trace_stderr=5

That should make dbmail spill it's guts on stderr.





>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> DBmail mailing list
> DBmail [at] dbmail
> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail


--
________________________________________________________________
Paul Stevens paul at nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands________________________________http://www.nfg.nl
_______________________________________________
DBmail mailing list
DBmail [at] dbmail
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail


loupicciano at comcast

May 16, 2010, 9:14 AM

Post #3 of 4 (678 views)
Permalink
Re: FATAL: database "dbmail" does not exist? - and no dbmail logs [In reply to]

Paul, Thanks for you help on this...

----- Original Message -----
From: "Paul J Stevens" <paul [at] nfg>
To: "DBMail mailinglist" <dbmail [at] dbmail>
Sent: Sunday, May 16, 2010 9:14:20 AM GMT -05:00 US/Canada Eastern
Subject: Re: [Dbmail] FATAL: database "dbmail" does not exist? - and no dbmail logs

Lou Picciano wrote:
> Hello dbmailers!
>
> Am attempting setup of a new installation of dbmail - using
> Postfix/PostgreSQL.
>
> We do have a backend database set up, called 'dbmail' and Postfix is
> apparently trying to connect, but is saying 'connect to pgsql server
> localhost: FATAL: database "dbmail" does not exist?'


SOLVED: This was my late-night testing-while-exhausted error: my mistake! I had been testing incorrect syntax
for passing a non-standard database port to the dbmail connection. I was, however, ultimately able to connect to the database with a syntax of hostname:port




> Note: we can connect correctly using same login details using psql, so
> don't think this is the problem.


How sure are you? Please share some details like the relevant parts of
your dbmail.conf and the command-line test you use.


> Also, both queries in the sql interface files return 0 results, as they
> should, right?

Both queries? What queries are those?


The two queries, of course, put into files as suggested by the Wiki's documentation on postgresql setup_postfix:
sql-virtual_mailbox_domains.cf sql-virtual_mailbox_maps.cf


> Last, I cannot get dbmail to write to either of its logs.




Not even syslog??? Makes me wonder if you are 1) running the binaries
you think you are running, 2) using the dbmail.conf file you think
dbmail is using.... You wouldn't be the first :-)



Fair enough, but am using the location of /etc/dbmail.conf, as suggested by docs. (Is there a way to direct
No, our logs for various services have been segregated - syslog is empty.


Also, we are not running the dbmail-impad binary at all yet...





> Clearly, we're getting close - can someone suggest something? Thanks, Lou




Yes, send us your trace_syslog=5 logs. Oh wait, no logs you say.




Try 'dbmail-imapd -n -f /etc/dbmail/dbmail.conf' with dbmail.conf

containing trace_stderr=5



Ah, hah! Your note suggests the resolution here. Is it that only specific daemons which write to the log? We haven't yet even used dbmail-imapd yet, for example, but I would have assumed we are engaging dbmail-lmtp, no? For the moment, we are testing only the 'inbound' trunk Postfix->PostgreSQL(dbmail) - trying to test one thing at a time. So, I'm guessing: we are not yet engaging any dbmail-log-writing daemons yet. Correct?


Also, we've been referencing documentation which states that configuration belongs in /etc/dbmail.conf. Is this incorrect?
Is /etc/dbmail/dbmail.conf the correct location? Is there an option to have a dbmail binary regurgitate its expected configuration location (as long as we're having it spill its guts??!!) I've since checked; apparently not.





That should make dbmail spill it's guts on stderr.



That command was very helpful, indicating a successful startup: dbmail imap (protocol version 4r1) server 2.2.15 ready to run. We used both 'dbmail-imapd -n -f /etc/dbmail.conf' and ; the two commands seem equivalent. But log output suggests some other things to fix - again, though, impad is not our immediate priority:



no value for SOCKET in config file
socket []
....
no value for BACKLOG in config file. Using default value [16]

...Still nothing being written to dbmail.err or dbmail.log.




>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> DBmail mailing list
> DBmail [at] dbmail
> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail


--
________________________________________________________________
Paul Stevens paul at nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands________________________________http://www.nfg.nl
_______________________________________________
DBmail mailing list
DBmail [at] dbmail
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail


paul at nfg

May 17, 2010, 12:36 AM

Post #4 of 4 (666 views)
Permalink
Re: FATAL: database "dbmail" does not exist? - and no dbmail logs [In reply to]

Lou Picciano wrote:
> SOLVED: This was my late-night testing-while-exhausted error: my
> mistake! I had been testing incorrect syntax
> for passing a non-standard database port to the dbmail connection. I
> was, however, ultimately able to connect to the database with a syntax
> of _hostname:port_

That is not standard.

> > Note: we can connect correctly using same login details using psql, so
> > don't think this is the problem.
>
> How sure are you? Please share some details like the relevant parts of
> your dbmail.conf and the command-line test you use.
>
> > Also, both queries in the sql interface files return 0 results, as they
> > should, right?
>
>
> Both queries? What queries are those?
>
> The two queries, of course, put into files as suggested by the Wiki's
> documentation on postgresql setup_postfix:

Again, those are not standard. You should make sure all dbmail tools can
run and connect to the database before you plug-in stuff like postfix.
That's what I would do, anyway.

>
> sql-virtual_mailbox_domains.cf
>
> sql-virtual_mailbox_maps.cf
>
> > Last, I cannot get dbmail to write to either of its logs.
>
>
> Not even syslog??? Makes me wonder if you are 1) running the binaries
> you think you are running, 2) using the dbmail.conf file you think
> dbmail is using.... You wouldn't be the first :-)
>
>
> Fair enough, but am using the location of /etc/dbmail.conf, as suggested
> by docs. (Is there a way to direct

You can configure the location of files by using the correct configure
options. For debian packages (and LSB compliance) I use:

configure --prefix=/usr --mandir=${prefix}/share/man
--sysconfdir=/etc/dbmail
--localstatedir=/var/run/dbmail
--with-logdir=/var/log/dbmail
--infodir=${prefix}/share/info

in addition to the usual options for database support etc.

> No, our logs for various services have been segregated - syslog is empty.

I meant: whatever file syslogd writes MAIL.* messages to.

>
> Also, we are not running the dbmail-impad binary at all yet...

Ok, that was just an example. All tools and daemons need to talk to the
database and will bail out if they fail to do so.

I normally run 'dbmail-users -l' whenever I want to test database
connectivity.


>
> > Clearly, we're getting close - can someone suggest something?
> Thanks, Lou
>
> Yes, send us your trace_syslog=5 logs. Oh wait, no logs you say.
>
> Try 'dbmail-imapd -n -f /etc/dbmail/dbmail.conf' with dbmail.conf
> containing trace_stderr=5
>
>
> Ah, hah! Your note suggests the resolution here. Is it that only
> specific daemons which write to the log?

No, all tools and daemons share the same logs.

> We haven't yet even used
> dbmail-imapd yet, for example, but I would have assumed we are engaging
> dbmail-lmtp, no? For the moment, we are testing only the 'inbound'
> trunk Postfix->PostgreSQL(dbmail) - trying to test one thing at a time.
> So, I'm guessing: we are not yet engaging any dbmail-log-writing
> daemons yet. Correct?

Incorrect. dbmail-lmtp will write to the same log files and/or syslog
interfaces.

>
> Also, we've been referencing documentation which states that
> configuration belongs in /etc/dbmail.conf. Is this incorrect?

Depends on your configuration like I mentioned. /etc/dbmail.conf is
fine, but is a bit old-school imo.

> Is /etc/dbmail/dbmail.conf the correct location? Is there an option to
> have a dbmail binary regurgitate its expected configuration location (as
> long as we're having it spill its guts??!!) I've since checked;
> apparently not.

Use strace(1) for that.

>
> That should make dbmail spill it's guts on stderr.
>
>
> That command was very helpful, indicating a successful startup: dbmail
> imap (protocol version 4r1) server 2.2.15 ready to run. We used
> both 'dbmail-imapd -n -f /etc/dbmail.conf' and ; the two commands seem
> equivalent. But log output suggests some other things to fix - again,
> though, impad is not our immediate priority:
>
> no value for SOCKET in config file
> socket []
> ...
> no value for BACKLOG in config file. Using default value [16]
>
> ..Still nothing being written to dbmail.err or dbmail.log.

If you run dbmail-imapd or dbmail-lmtpd with the -n switch the stderr
logging will end up on stderr, not in a file.

If you get a ready to run message from dbmail-imapd your database
connection has been successfully established.

You can try the same with lmtpd:

dbmail-lmtpd -n -f /etc/dbmail.conf

should give you a '220 hostname DBMail LMTP service ready to rock' message.



--
________________________________________________________________
Paul Stevens paul at nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands________________________________http://www.nfg.nl
_______________________________________________
DBmail mailing list
DBmail [at] dbmail
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

DBMail users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.