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
[email protected]
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
