colin | 19 May 01:19 2016
Picon
Gravatar

***SPAM*** some interesting info

Hi,

Some of my friends think that's really interesting, check it out http://buthophyshy.livebigbear.com/nearby.php

 

Best, colin-i6+wjS9+XQAQL/OqXoauh4dd74u8MsAO@public.gmane.org

_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@...
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
Mantis Bug Tracker | 16 May 13:08 2016

[DBMail 0001078]: DBMail stopped working after upgrading to mysql 5.7


A NOTE has been added to this issue. 
====================================================================== 
http://www.dbmail.org/mantis/view.php?id=1078 
====================================================================== 
Reported By:                px3
Assigned To:                
====================================================================== 
Project:                    DBMail
Issue ID:                   1078
Category:                   Database layer
Reproducibility:            have not tried
Severity:                   minor
Priority:                   normal
Status:                     new
target:                      
====================================================================== 
Date Submitted:             16-May-16 12:39 CEST
Last Modified:              16-May-16 13:08 CEST
====================================================================== 
Summary:                    DBMail stopped working after upgrading to mysql 5.7
Description: 
After upgrading mysql to 5.7.12 dbmail stopped working.
Inserts into the database are no longer possible.

Using mysql and executing the same statements from the mysql-client,
everything works fine.

All other applications on the machine are runnning fine, expect dbmail.

dbmail-util -a shows no errors.

Even trying to create a new user with dbmail-users ends up in:
 May 16 12:42:51 rdsroot dbmail/user[29631]: Debug:[user] do_add(+65):
Adding user px3 with password type crypt,0 bytes mailbox limit and clientid
0...
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db] db_con_get(+263):
[0xe05ca0] connection from pool
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db]
db_stmt_prepare(+419): [0xe05ca0] [SELECT user_idnr FROM dbmail_users WHERE
lower(userid) = lower(?)]
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db]
db_stmt_set_str(+427): [0xdf5810] 1:[px3]
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db]
db_con_close(+291): [0xe05ca0] connection to pool
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db] db_con_get(+263):
[0xe05ca0] connection from pool
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db]
db_stmt_prepare(+419): [0xe05ca0] [SELECT user_idnr FROM dbmail_users WHERE
lower(userid) = lower(?)]
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db]
db_stmt_set_str(+427): [0xdf5aa0] 1:[px3]
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db]
db_con_close(+291): [0xe05ca0] connection to pool
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db] db_con_get(+263):
[0xe05ca0] connection from pool
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db]
db_begin_transaction(+542): BEGIN
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db]
db_stmt_prepare(+419): [0xe05ca0] [INSERT INTO dbmail_users
(userid,passwd,client_idnr,maxmail_size,encryption_type) VALUES (?,?,?,?,?)
]
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db]
db_stmt_set_str(+427): [0xdf5d10] 1:[px3]
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db]
db_stmt_set_str(+427): [0xdf5d10] 2:[fE3UF87llocO6]
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db]
db_stmt_set_u64(+439): [0xdf5d10] 3:[0]
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db]
db_stmt_set_u64(+439): [0xdf5d10] 4:[0]
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db]
db_stmt_set_str(+427): [0xdf5d10] 5:[crypt]

And then nothing more happens.

Mysql shows no errors in the logfiles.

====================================================================== 

---------------------------------------------------------------------- 
 (0003734) px3 (reporter) - 16-May-16 13:08
 http://www.dbmail.org/mantis/view.php?id=1078#c3734 
---------------------------------------------------------------------- 
The severity is "block", but i can't change it :( 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
16-May-16 12:39  px3            New Issue                                    
16-May-16 13:06  px3            Issue Monitored: px3                         
16-May-16 13:08  px3            Note Added: 0003734                          
======================================================================
Mantis Bug Tracker | 16 May 12:39 2016

[DBMail 0001078]: DBMail stopped working after upgrading to mysql 5.7


The following issue has been SUBMITTED. 
====================================================================== 
http://www.dbmail.org/mantis/view.php?id=1078 
====================================================================== 
Reported By:                px3
Assigned To:                
====================================================================== 
Project:                    DBMail
Issue ID:                   1078
Category:                   Database layer
Reproducibility:            have not tried
Severity:                   minor
Priority:                   normal
Status:                     new
target:                      
====================================================================== 
Date Submitted:             16-May-16 12:39 CEST
Last Modified:              16-May-16 12:39 CEST
====================================================================== 
Summary:                    DBMail stopped working after upgrading to mysql 5.7
Description: 
After upgrading mysql to 5.7.12 dbmail stopped working.
Inserts into the database are no longer possible.

Using mysql and executing the same statements from the mysql-client,
everything works fine.

All other applications on the machine are runnning fine, expect dbmail.

dbmail-util -a shows no errors.

Even trying to create a new user with dbmail-users ends up in:
 May 16 12:42:51 rdsroot dbmail/user[29631]: Debug:[user] do_add(+65):
Adding user px3 with password type crypt,0 bytes mailbox limit and clientid
0...
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db] db_con_get(+263):
[0xe05ca0] connection from pool
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db]
db_stmt_prepare(+419): [0xe05ca0] [SELECT user_idnr FROM dbmail_users WHERE
lower(userid) = lower(?)]
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db]
db_stmt_set_str(+427): [0xdf5810] 1:[px3]
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db]
db_con_close(+291): [0xe05ca0] connection to pool
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db] db_con_get(+263):
[0xe05ca0] connection from pool
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db]
db_stmt_prepare(+419): [0xe05ca0] [SELECT user_idnr FROM dbmail_users WHERE
lower(userid) = lower(?)]
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db]
db_stmt_set_str(+427): [0xdf5aa0] 1:[px3]
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db]
db_con_close(+291): [0xe05ca0] connection to pool
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db] db_con_get(+263):
[0xe05ca0] connection from pool
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db]
db_begin_transaction(+542): BEGIN
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db]
db_stmt_prepare(+419): [0xe05ca0] [INSERT INTO dbmail_users
(userid,passwd,client_idnr,maxmail_size,encryption_type) VALUES (?,?,?,?,?)
]
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db]
db_stmt_set_str(+427): [0xdf5d10] 1:[px3]
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db]
db_stmt_set_str(+427): [0xdf5d10] 2:[fE3UF87llocO6]
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db]
db_stmt_set_u64(+439): [0xdf5d10] 3:[0]
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db]
db_stmt_set_u64(+439): [0xdf5d10] 4:[0]
May 16 12:42:51 rdsroot dbmail/user[29631]: Database:[db]
db_stmt_set_str(+427): [0xdf5d10] 5:[crypt]

And then nothing more happens.

Mysql shows no errors in the logfiles.

====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
16-May-16 12:39  px3            New Issue                                    
======================================================================
Jordon Bedwell | 25 Mar 01:11 2016
Picon

Fw: new message

Hey!

 

Open message http://mikethomascd.com/take.php

 

Jordon Bedwell

_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@...
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
mysql.jorge | 9 Mar 20:29 2016
Picon

Fw: new message

Hey!

 

Open message http://sudarena.intelmedia.ro/ask.php

 

mysql.jorge <at> decimal.pt

_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@...
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
Paul J Stevens | 5 Mar 18:43 2016
Picon
Gravatar

[SCM]Paul's DBMail tree branch, master, updated. f5b73b342b4a6cae1bb15340e5da7330e29319c1

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Paul's DBMail tree".

The branch, master has been updated
       via  f5b73b342b4a6cae1bb15340e5da7330e29319c1 (commit)
      from  b4b82aca1dd1c8aece722b8370da02b715e4bb53 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit f5b73b342b4a6cae1bb15340e5da7330e29319c1
Author: Paul J Stevens <p.stevens@...>
Date:   Sat Mar 5 18:43:12 2016 +0100

    simplify log_query_time duration logic

-----------------------------------------------------------------------

Summary of changes:
 src/dm_db.c            |   16 ++++++++--------
 src/dm_misc.c          |   12 ++++++++++++
 src/dm_misc.h          |    2 ++
 test/check_dbmail_db.c |   27 +++++++++++++++++++++++++++
 4 files changed, 49 insertions(+), 8 deletions(-)

hooks/post-receive
--
Paul's DBMail tree
Paul J Stevens | 10 Feb 09:15 2016
Picon
Gravatar

[SCM]Paul's DBMail tree branch, master, updated. b4b82aca1dd1c8aece722b8370da02b715e4bb53

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Paul's DBMail tree".

The branch, master has been updated
       via  b4b82aca1dd1c8aece722b8370da02b715e4bb53 (commit)
      from  b6f28ffa54e6533fd0d8676248d0c9bc6d4bd859 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit b4b82aca1dd1c8aece722b8370da02b715e4bb53
Author: Paul J Stevens <p.stevens@...>
Date:   Wed Feb 10 09:14:41 2016 +0100

    improve crypt authentication

    also don't segfault when spasswd is empty

-----------------------------------------------------------------------

Summary of changes:
 src/dm_db.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

hooks/post-receive
--
Paul's DBMail tree
Paul J Stevens | 10 Feb 09:15 2016
Picon
Gravatar

[SCM]Paul's DBMail tree branch, dbmail_3_2, updated. 77fa6cbb77a0637bea84bd2bfa108e4497aca06d

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Paul's DBMail tree".

The branch, dbmail_3_2 has been updated
       via  77fa6cbb77a0637bea84bd2bfa108e4497aca06d (commit)
      from  9b4bf84d0f5a76880885e507fdeb82b639ccde3c (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 77fa6cbb77a0637bea84bd2bfa108e4497aca06d
Author: Paul J Stevens <p.stevens@...>
Date:   Wed Feb 10 09:14:41 2016 +0100

    improve crypt authentication

    also don't segfault when spasswd is empty

-----------------------------------------------------------------------

Summary of changes:
 src/dm_db.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

hooks/post-receive
--
Paul's DBMail tree
Mantis Bug Tracker | 15 Jan 18:24 2016

[DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other


A NOTE has been added to this issue. 
====================================================================== 
http://www.dbmail.org/mantis/view.php?id=1076 
====================================================================== 
Reported By:                Gorbash
Assigned To:                
====================================================================== 
Project:                    DBMail
Issue ID:                   1076
Category:                   POP3 daemon
Reproducibility:            have not tried
Severity:                   block
Priority:                   normal
Status:                     new
target:                      
====================================================================== 
Date Submitted:             12-Nov-15 15:48 CET
Last Modified:              15-Jan-16 18:24 CET
====================================================================== 
Summary:                    DBMail services dbmail-pop3d OR dbmail-lmtpd remain
inactive after start and enable, erratic start on one or the other
Description: 
As part of testing an updated version of DBMail (a year or so newer than
the one we have in production), we set up a test RHEL server and pulled
version 3.1.16 from an existing channel. Unfortunately, after making sure
that the channel installed all the required libraries and files, and
updating the configuration URI to our test database, we've hit a snag.

The two DBMail services we use are dbmail-lmtpd and dbmail-pop3d. Every
time we try to start both services, one of the following things will
happen:
1. Both services stick at loaded/enabled but inactive, no PID files show
up, and logging in dbmail.err for each service stops at "effective group
shall be [nobody]"
2. One service will become active, but the other will stick at
loaded/enabled but inactive; the active service will have a PID file, but
not the inactive one, and logging in dbmail.err for the inactive service
stops at "effective group shall be [nobody]" while the other passes that
step and completes normally. When this happens, its usually (but not
always) the first service tried that becomes active.

Normally, the default config would produce "effective group shall be
[nogroup]", but RHEL 7 uses nobody/nobody instead of nobody/nogroup.
Nevertheless, I tried changing it back to nobody/nogroup in dbmail.conf,
and got a result matching http://www.dbmail.org/mantis/view.php?id=2, above.
We've also tried using a specific
account, and setting the referenced files to match that account, but in
that case, neither process will become active and no PID file is
generated.

The only other error message I've seen is a "can't drop permissions"
message from the active service in /var/log/dbmail, before the messages
from the inactive service start.

We haven't had this problem on our previous test or production servers, so
I think it might have something to do with RHEL 7. I'm hoping that's not
the case, however, as RHEL 7 dramatically improved the installation of
other services we've added onto this server. Any ideas on what this might
be stemming from?
====================================================================== 

---------------------------------------------------------------------- 
 (0003707) thelounge (reporter) - 12-Nov-15 15:57
 http://www.dbmail.org/mantis/view.php?id=1076#c3707 
---------------------------------------------------------------------- 
besides that 3.1.16 is missing a important bugfix from 3.1.17 that sounds
more like wrong systemd-units
effective group shall be [nogroup]", but RHEL 7 uses nobody/nobody instead
of nobody/nogroup.

i wonder really why because normally you have a user "dbmail" and a group
"dbmail" instead abuse "Nobody"
effective_user        = dbmail
effective_group       = dbmail

the units below are working here from Fedora 15 to Fedora 23
___________________________________________________________________

[root <at> srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-pop3d.service
[Unit]
Description=DBMail POP3 Server
After=network.service systemd-networkd.service network-online.target
mysqld.service
Before=dovecot.service

[Service]
Type=simple
ExecStart=/usr/sbin/dbmail-pop3d -D
Environment="LANG=en_GB.UTF-8"
Restart=always
RestartSec=1
TimeoutStopSec=5
LimitNOFILE=50000

PrivateTmp=yes
PrivateDevices=yes
CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE
CAP_SETGID CAP_SETUID

ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr

[Install] 
WantedBy=multi-user.target
___________________________________________________________________

[root <at> srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-lmtpd.service
[Unit]
Description=DBMail LMTP Server
After=network.service systemd-networkd.service network-online.target
mysqld.service 

[Service]
Type=simple
ExecStart=/usr/sbin/dbmail-lmtpd -D
Environment="LANG=en_GB.UTF-8"
Restart=always
RestartSec=1
TimeoutStopSec=5
LimitNOFILE=50000
PrivateTmp=yes
PrivateDevices=yes
CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE
CAP_SETGID CAP_SETUID
ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr

[Install]
WantedBy=multi-user.target 

---------------------------------------------------------------------- 
 (0003708) Gorbash (reporter) - 12-Nov-15 16:29
 http://www.dbmail.org/mantis/view.php?id=1076#c3708 
---------------------------------------------------------------------- 
--i wonder really why because normally you have a user "dbmail" and a group
"dbmail" instead abuse "Nobody"

Default on the configs is nobody/nogroup, and that's what our prod servers
(which are *not* RHEL 7) use. We also gave an alternate user (user exim /
group exim) a shot earlier, but I can give user / group dbmail a shot if
you think it'll work.

Meantime, since this install of DBmail was provided by a RedHat channel,
we've been using the systemd files that came with the RPM (listed below).
I'm a little hesitant about messing with them too much since they did come
from the channel, so they should have worked as-is.

# cat dbmail-pop3d.service 
[Unit]
Description=DBMail pop3 Server
After=syslog.target network.target mysqld.service postgresql.service

[Service]
Type=forking
EnvironmentFile=-/etc/sysconfig/dbmail-pop3d
ExecStart=/usr/sbin/dbmail-pop3d

[Install]
WantedBy=multi-user.target

# cat dbmail-lmtpd.service 
[Unit]
Description=DBMail LMTP Server
After=syslog.target network.target mysqld.service postgresql.service

[Service]
Type=forking
EnvironmentFile=-/etc/sysconfig/dbmail-lmtpd
ExecStart=/usr/sbin/dbmail-lmtpd

[Install]
WantedBy=multi-user.target 

---------------------------------------------------------------------- 
 (0003709) thelounge (reporter) - 12-Nov-15 16:45
 http://www.dbmail.org/mantis/view.php?id=1076#c3709 
---------------------------------------------------------------------- 
i doubt that dbmail 3.1.16 is from the default channel
since it are systemd-units it RHEL7
there is no dbmail at all except EPEL repo

epel repo has 3.2.3 and there was never 3.1.16
https://koji.fedoraproject.org/koji/packageinfo?packageID=1572

the epel-package clearly creates a dbmail user
____________________________________

%pre
getent group %{name} >/dev/null || groupadd -r %{name}
getent passwd %{name} >/dev/null || \
  useradd -r -M -g %{name} -d / -s /sbin/nologin \
  -c "DBMail Daemon" %{name}
exit 0
____________________________________

that part of the shipped "dbmail.conf" from the package is simply a bug
when due instal there is a user dbmail created

effective_user        = nobody
effective_group       = nogroup
____________________________________

that sed-snippet from the rpm-spec just don't work as intended because it's
uppercase and in the meantime the values in the sample config from the
tarball are lowercase, that said about the quality of the package, there is
a reason why i build my own rpm for the last 6 years

# make a couple of changes to the default dbmail.conf file:
# 1. default driver/authdriver sqlite/sql
# 2. effective uid/gid to dbmail/dbmail
sed -i 's/\(^driver\W*=\)\(\W*$\)/\1 sqlite/' dbmail.conf
sed -i -e 's,\(^db\W*=\)\(.*$\),\1 %{_localstatedir}/lib/dbmail/dbmail.db,'
  \
       -e 's/\(^authdriver\W*=\)\(\W*$\)/\1 sql/'                          
  \
       -e 's/\(^EFFECTIVE_USER\W*=\)\(.*$\)/\1 dbmail/'                    
  \
       -e 's/\(^EFFECTIVE_GROUP\W*=\)\(.*$\)/\1 dbmail/' dbmail.conf 

---------------------------------------------------------------------- 
 (0003710) Gorbash (reporter) - 13-Nov-15 16:28
 http://www.dbmail.org/mantis/view.php?id=1076#c3710 
---------------------------------------------------------------------- 
You're correct, we're on 3.2.3. I didn't see it as an option on dropdown,
so I picked the closest version in the dropdown (which would have been
3.1.17; apparently, I missed and hit 3.1.16 instead).

We're running off of a separate MySQL server as a database instead of
SQLite. Do I still need to change the default driver in that case?

I'm not really seeing any difference after changing the effective user and
group in dbmail.config to dbmail/dbmail. Do the associated files also have
to be assigned to dbmail/dbmail? 

---------------------------------------------------------------------- 
 (0003711) Gorbash (reporter) - 27-Nov-15 22:14
 http://www.dbmail.org/mantis/view.php?id=1076#c3711 
---------------------------------------------------------------------- 
We've switched to dbmail/dbmail, but neither dbmail-pop3d nor dbmail-lmtpd
are starting after the change.

Are you sure we should be changing the default driver? We're using a MySQL
server. 

---------------------------------------------------------------------- 
 (0003712) Gorbash (reporter) - 03-Dec-15 22:34
 http://www.dbmail.org/mantis/view.php?id=1076#c3712 
---------------------------------------------------------------------- 
Issue persists, even with the listed changes to our dbmail.conf file, and
all files owned by dbmail / dbmail. 

---------------------------------------------------------------------- 
 (0003713) Gorbash (reporter) - 08-Dec-15 16:30
 http://www.dbmail.org/mantis/view.php?id=1076#c3713 
---------------------------------------------------------------------- 
New dbmail.err logs are as follows:

Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000] Info:[debug]
configure_debug(+79): [POP] syslog [31 -> 31] stderr [31 -> 511]
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[server] server_config_load(+1015): max_db_connections [10]
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[config] config_get_timeout(+445): timeout [300] seconds
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[config] config_get_timeout(+456): login_timeout [60] seconds
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[server] server_config_load(+1024): no value for SOCKET in config
file
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[server] server_config_load(+1026): socket []
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[server] server_config_load(+1047): binding to PORT [110]
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[server] server_config_load(+1076): binding to IP [0.0.0.0]
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[server] server_config_load(+1082): no value for BACKLOG in config
file. Using default value [128]
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[server] server_config_load(+1086): POP backlog [128]
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[server] server_config_load(+1093): not resolving client IP
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[server] server_config_load(+1102): Disabling POP-before-SMTP
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[server] server_config_load(+1109): Disabling POP Authentication
logging
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[server] server_config_load(+1119): effective user shall be [dbmail]
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[server] server_config_load(+1128): effective group shall be
[dbmail]
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000] Info:[debug]
configure_debug(+79): [LMTP] syslog [31 -> 31] stderr [31 -> 511]
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[server] server_config_load(+1015): max_db_connections [10]
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[config] config_get_timeout(+445): timeout [300] seconds
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[config] config_get_timeout(+456): login_timeout [60] seconds
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[server] server_config_load(+1024): no value for SOCKET in config
file
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[server] server_config_load(+1026): socket []
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[server] server_config_load(+1047): binding to PORT [24]
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[server] server_config_load(+1076): binding to IP [0.0.0.0]
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[server] server_config_load(+1082): no value for BACKLOG in config
file. Using default value [128]
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[server] server_config_load(+1086): LMTP backlog [128]
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[server] server_config_load(+1093): not resolving client IP
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[server] server_config_load(+1100): no value for LMTP_BEFORE_SMTP  in
config file
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[server] server_config_load(+1102): Disabling LMTP-before-SMTP
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[server] server_config_load(+1109): Disabling LMTP Authentication
logging
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[server] server_config_load(+1119): effective user shall be [dbmail]
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[server] server_config_load(+1128): effective group shall be
[dbmail]

It looks like it cuts off at the same spot as with nobody/nobody. Could it
be a problem with the dbmail account that should have been generated with
it? 

---------------------------------------------------------------------- 
 (0003716) Gorbash (reporter) - 23-Dec-15 20:41
 http://www.dbmail.org/mantis/view.php?id=1076#c3716 
---------------------------------------------------------------------- 
We have now tried reinstalling this DBMail setup and setting effective
group / user to dbmail, and we're still running into the exact same issue,
with the logs cutting off at that point.

You mentioned earlier setting our authdriver to SQL and our driver to
sqlite. According to the config we have, the driver field is deprecated. I
can confirm our authdriver field is set to SQL; should I reactivate the
driver field and change it to sqlite?

Otherwise, I'm running out of ideas on what else we can try with this.
Should I just try building a new RPM based on the example you listed at the
beginning? 

---------------------------------------------------------------------- 
 (0003717) Gorbash (reporter) - 24-Dec-15 15:13
 http://www.dbmail.org/mantis/view.php?id=1076#c3717 
---------------------------------------------------------------------- 
I think I've spotted part of the problem.

You mention a dbmail.db in the line here:
"sed -i -e 's,\(^db\W*=\)\(.*$\),\1
%{_localstatedir}/lib/dbmail/dbmail.db,' \"

Not only do we not have a directory named dbmail in lib (though we have one
in lib64), we can't find a dbmail.db file anywhere within our structure.
The install should have created that file, correct? Could that be why we
can't start? 

---------------------------------------------------------------------- 
 (0003718) thelounge (reporter) - 24-Dec-15 15:38
 http://www.dbmail.org/mantis/view.php?id=1076#c3718 
---------------------------------------------------------------------- 
there is no "dbmail.db" when you are using mysql/postgreqsl as storage and
{_localstatedir} has nothing to do with lib64 - {_localstatedir} translates
to /var and so it would be /var/lib/dbmail/ the tyical runtime-data
directory like /var/lib/samba, /var/lib/hdcp, /var/lib/mysql and son on
which is by definition arch-agnostic 

---------------------------------------------------------------------- 
 (0003719) Gorbash (reporter) - 28-Dec-15 21:04
 http://www.dbmail.org/mantis/view.php?id=1076#c3719 
---------------------------------------------------------------------- 
If there's no dbmail.db, what is that line referencing? I would assume its
referring to the mysql db, but I wouldn't think the user the DB is running
would affect whether or not DBMail activates over here.

If that's the case, then changing to effective user DBMail and effective
group DBMail should have started this. Do you have any other ideas about
what might be preventing either process from starting? 

---------------------------------------------------------------------- 
 (0003720) thelounge (reporter) - 28-Dec-15 21:13
 http://www.dbmail.org/mantis/view.php?id=1076#c3720 
---------------------------------------------------------------------- 
it's likely referencing setups with no real db-server using sqlite

no, i have no idea what's preventing it to start, dbmail has a lot of bugs
but it's basically working here from Fedora 9 to Fedora 23 which covers
CentOS6/CentOS 7 over the last 7 years

what makes me sorrow is that the maintainer is silent for nearly a year now
but that's another story 

---------------------------------------------------------------------- 
 (0003721) Gorbash (reporter) - 28-Dec-15 21:30
 http://www.dbmail.org/mantis/view.php?id=1076#c3721 
---------------------------------------------------------------------- 
Well, thanks for the help regardless -- at least we've got one potential
problem tracked down. 

---------------------------------------------------------------------- 
 (0003722) Gorbash (reporter) - 28-Dec-15 23:00
 http://www.dbmail.org/mantis/view.php?id=1076#c3722 
---------------------------------------------------------------------- 
Hmm.... apparently, if I leave these "on" (loaded but inactive), I
occasionally get the following error messages 3-4 hours after I attempted
to start these processes.

Dec 27 03:15:01 oexdev1 dbmail-util[29998]: [0x7f24e9ddce00] Debug:[db]
db_connect(+201): dburi: mysql://dbmail:kL5cPdr2 <at> mysqldbqa:5038/dbmail
Failed. An error occured. Please check log.
Dec 28 03:13:01 oexdev1 dbmail-util[35221]: [0x7f41594b7e00] Debug:[config]
GetDBParams(+365): error getting config! [sortdriver]
Dec 28 03:13:01 oexdev1 dbmail-util[35221]: [0x7f41594b7e00] Debug:[config]
GetDBParams(+367): error getting config! [serverid]
Dec 28 03:13:01 oexdev1 dbmail-util[35221]: [0x7f41594b7e00] Debug:[config]
GetDBParams(+373): error getting config! [max_db_connections]

Is it possible that the processes are simply having trouble reading the
config?

We've tried setting the ownership of dbmail.conf to root, the dbmail user,
and nobody, in turn, without seeing any difference. Right now, dbmail.conf
is in /etc/. Is there any chance these processes might be looking in the
wrong folder for dbmail.conf? They're obviously finding it to determine
which user to use [as the errors will change to "effective user = dbmail"
when told to use user dbmail], but maybe there's another step its failing
to complete. 

---------------------------------------------------------------------- 
 (0003723) Gorbash (reporter) - 29-Dec-15 23:10
 http://www.dbmail.org/mantis/view.php?id=1076#c3723 
---------------------------------------------------------------------- 
I went back and compared the dbmail.err file results on here to on our much
older, existing, manually installed servers, and it looks like the process
is stopping in between when the effective user and group is assigned and
when DBMail checks the configs for a CA file and Certificate.

Now, neither of these should be running with an active Certificate (both
configs have blank certificate designations). Its possible the older one
has a certificate on it, but I don't think it does.

Is it possible that dbmail is failing while looking for a certificate that
doesn't exist? 

---------------------------------------------------------------------- 
 (0003724) thelounge (reporter) - 29-Dec-15 23:14
 http://www.dbmail.org/mantis/view.php?id=1076#c3724 
---------------------------------------------------------------------- 
unlikely, the TLS stuff is commented out here because TLS offloading is
done by dovecot running as IMAP proxy on the same machine for several
reasons (ath mechs, sharing auth for postfix SASL, stability)

[root <at> mail:~]$ rpm -q dbmail
dbmail-3.1.17-3.fc22.20151012.rh.3.1.17.x86_64

[root <at> mail:~]$ cat dbmail.conf 
[DBMAIL]
dburi                 =
mysql://dbmail:************ <at> localhost/dbmail?unix-socket=/var/lib/mysql/mysql.sock&charset=utf8
authdriver            = sql
table_prefix          = dbmail_
max_db_connections    = 25

encoding              = utf8
default_msg_encoding  = utf8
postmaster            = postmaster@...
sendmail              = /usr/sbin/sendmail

syslog_logging_levels = 31
query_time_info       = 10
query_time_notice     = 15
query_time_warning    = 30
query_timeout         = 300

effective_user        = dbmail
effective_group       = dbmail

# tls_cafile          = /etc/pki/tls/certs/ca-bundle.crt
# tls_cert            = /etc/postfix/certs/mail.thelounge.net.pem
# tls_key             = /etc/postfix/certs/mail.thelounge.net.pem
# tls_ciphers         =
ALL:!aNULL:!eNULL:!ADH!LOW:!MEDIUM:!EXP:!SSLv2:HIGH
# file_logging_levels = 511

backlog               = 256
timeout               = 300
login_timeout         = 60
resolve_ip            = no
authlog               = no
logfile               = /var/log/dbmail.log
errorlog              = /var/log/dbmail.err
pid_directory         = /run/dbmail
header_cache_readonly = yes

[LMTP]
bindip                = 127.0.0.1
port                  = 24
banner                = LMTP
timeout               = 1800
max_db_connections    = 1

[POP]
bindip                = 127.0.0.1
port                  = 110
pop_before_smtp       = no
banner                = POP3
timeout               = 1800

[IMAP]
bindip                = 127.0.0.1
port                  = 143
idle_timeout          = 35
imap_before_smtp      = no
capability            = IMAP4 IMAP4rev1 AUTH=LOGIN ACL RIGHTS=texk
NAMESPACE CHILDREN SORT QUOTA THREAD=ORDEREDSUBJECT UNSELECT IDLE
banner                = IMAP
timeout               = 3600
max_message_size      = 26214400

[SIEVE]
bindip                = *
port                  = 2000
banner                = SIEVE

[DELIVERY]
auto_reply            = yes
suppress_duplicates   = yes
sieve                 = yes
subaddress            = yes
sieve_vacation        = no
sieve_notify          = no
sieve_debug           = no
auto_notify           = no
quota_failure         = hard 

---------------------------------------------------------------------- 
 (0003726) Gorbash (reporter) - 05-Jan-16 22:20
 http://www.dbmail.org/mantis/view.php?id=1076#c3726 
---------------------------------------------------------------------- 
I'm not really seeing a lot of differences that should lead to this. 

I dug into server.c, which is the file that sends the "server_config_load"
messages that debug is catching, and I found where in the stream the
"effective user shall be" and "effective group shall be" messages are set
off. Right afterwards is the section of code where the script checks for
certificate information. I noticed a difference in that section between the
code on our working 3.1.7 server and this server:

-----------------------------------
3.1.7 version:
	/* read items: TLS_CAFILE */
	config_get_value("TLS_CAFILE", service, val);
	if(strlen(val) == 0)
		TRACE(TRACE_WARNING, "no value for TLS_CAFILE in config file");
	strncpy(config->tls_cafile, val, FIELDSIZE);
        config->tls_cafile[FIELDSIZE - 1] = '\0';

        TRACE(TRACE_DEBUG, "CA file is set to [%s]", config->tls_cafile);

	/* read items: TLS_CERT */
	config_get_value("TLS_CERT", service, val);
	if(strlen(val) == 0)
		TRACE(TRACE_WARNING, "no value for TLS_CERT in config file");
	strncpy(config->tls_cert, val, FIELDSIZE);
        config->tls_cert[FIELDSIZE - 1] = '\0';

        TRACE(TRACE_DEBUG, "Certificate file is set to [%s]",
config->tls_cert);

	/* read items: TLS_KEY */
	config_get_value("TLS_KEY", service, val);
	if(strlen(val) == 0)
		TRACE(TRACE_WARNING, "no value for TLS_KEY in config file");
	strncpy(config->tls_key, val, FIELDSIZE);
        config->tls_key[FIELDSIZE - 1] = '\0';

        TRACE(TRACE_DEBUG, "Key file is set to [%s]", config->tls_key);

	/* read items: TLS_CIPHERS */
	config_get_value("TLS_CIPHERS", service, val);
	if(strlen(val) == 0)
		TRACE(TRACE_INFO, "no value for TLS_CIPHERS in config file");
	strncpy(config->tls_ciphers, val, FIELDSIZE);
        config->tls_ciphers[FIELDSIZE - 1] = '\0';

        TRACE(TRACE_DEBUG, "Cipher string is set to [%s]",
config->tls_ciphers);

	strncpy(config->service_name, service, FIELDSIZE);

3.2.3's version:
	/* read items: TLS_CAFILE */
	config_get_value("TLS_CAFILE", service, val);
	if(strlen(val)) {
		strncpy(config->tls_cafile, val, FIELDSIZE-1);
		TRACE(TRACE_DEBUG, "CA file is set to [%s]", config->tls_cafile);
	}

	/* read items: TLS_CERT */
	config_get_value("TLS_CERT", service, val);
	if(strlen(val)) {
		strncpy(config->tls_cert, val, FIELDSIZE-1);
		TRACE(TRACE_DEBUG, "Certificate file is set to [%s]", config->tls_cert);
	}

	/* read items: TLS_KEY */
	config_get_value("TLS_KEY", service, val);
	if(strlen(val)) {
		strncpy(config->tls_key, val, FIELDSIZE-1);
		TRACE(TRACE_DEBUG, "Key file is set to [%s]", config->tls_key);
	}

	/* read items: TLS_CIPHERS */
	config_get_value("TLS_CIPHERS", service, val);
	if(strlen(val)) {
		strncpy(config->tls_ciphers, val, FIELDSIZE-1);
		TRACE(TRACE_DEBUG, "Cipher string is set to [%s]", config->tls_ciphers);
	}

	strncpy(config->service_name, service, FIELDSIZE);

----------------------------

Our TLS information is currently blank, because as far as I knew, we were
not required to have certs in order to pass a message through. Our old
server 3.1.7 server doesn't have certs set up on it either.

What I think might be happening is that the script is hitting "
if(strlen(val)) " and dying on a null value, where the old cert would
acknowledge that " null != 0 " and keep going.

I tried commenting out the cert lines in the config, and it ran into the
same problem as previously (stopping after "effective group). However, when
I added in a fake cert name, it went a little bit further -- dbmail
remained inactive, but the logs progressed further. 

These lines are at the end of the server.c script, meaning that the problem
could also be occurring as part of calling the next script, or during the
next script (if there aren't any debug lines in that script). I'm not
certain what the next script is.

The problem could also be occurring at the " strncpy(config->service_name,
service, FIELDSIZE); " line; I'm not really certain what that one is
calling.

I'm going to try setting up cert information for this as a first step. With
any luck, this might resolve the issue. 

---------------------------------------------------------------------- 
 (0003727) Gorbash (reporter) - 11-Jan-16 17:49
 http://www.dbmail.org/mantis/view.php?id=1076#c3727 
---------------------------------------------------------------------- 
Okay, so putting in fake cert information (i.e. just a cert name and
location, without installing an actual cert file) pushed DBMail past where
it was getting stuck previously, but it still didn't become an active
process, and I think that's because it was looking for a cert that wasn't
actually there.

Putting in a fully-signed cert is a process I can handle, but I'd rather
avoid it until I'm certain that's what's needed to resolve the issue.

I can correct the line of code itself, but server.c is source code that is
compiled into a "server" file on install. And unfortunately, it looks like
that server file is encrypted, or at least can't be edited the way
everything else can be.

Editing the source code sounds kind of extreme, but its generally better
than paying for a signed cert that possibly won't fix the problem, right? 

---------------------------------------------------------------------- 
 (0003728) thelounge (reporter) - 11-Jan-16 17:51
 http://www.dbmail.org/mantis/view.php?id=1076#c3728 
---------------------------------------------------------------------- 
"but its generally better than paying for a signed cert that possibly won't
fix the problem" - why can't you just create a self signed certificate to
verify your assumptions? 

---------------------------------------------------------------------- 
 (0003729) Gorbash (reporter) - 11-Jan-16 19:35
 http://www.dbmail.org/mantis/view.php?id=1076#c3729 
---------------------------------------------------------------------- 
Will tls_cafile and tls_ciphers work with a self-signed cert? 

---------------------------------------------------------------------- 
 (0003730) thelounge (reporter) - 11-Jan-16 19:47
 http://www.dbmail.org/mantis/view.php?id=1076#c3730 
---------------------------------------------------------------------- 
"tls_ciphers" has NOTHING to do with the certificates or CA

i already postet my configuration and guess what "localhost.pem" was
a pem-file which is nothing else than "cat crtfule keyfile >
localhost.pem"

ca_file don't matter - to be honest - in the time you are asking that you
could have entered "create selfsigned certificate" in Google and try it

# tls_cafile          = /etc/pki/tls/certs/ca-bundle.crt                   

                                                           
# tls_cert            = /etc/postfix/certs/localhost.pem                   

                                                           
# tls_key             = /etc/postfix/certs/localhost.pem                   

                                                           
# tls_ciphers         = ALL:!aNULL:!eNULL:!ADH!LOW:!MEDIUM:!EXP:!SSLv2:HIGH 

---------------------------------------------------------------------- 
 (0003731) Gorbash (reporter) - 13-Jan-16 23:21
 http://www.dbmail.org/mantis/view.php?id=1076#c3731 
---------------------------------------------------------------------- 
No good. It took the self-signed cert, and the debug file stops right after
that. The service still sits at enabled/inactive. 

---------------------------------------------------------------------- 
 (0003732) Gorbash (reporter) - 15-Jan-16 18:14
 http://www.dbmail.org/mantis/view.php?id=1076#c3732 
---------------------------------------------------------------------- 
Okay, no, I take that back. Now its on inactive and disabled. Curious.

I'm also not seeing a connection from this server on the database -- I was
when the processes got to inactive/enabled status, but not now.

In addition, we got a few new errors sometime early this morning. From
this... I'm think we're close, and its possible that DBMail is now just
having connection issues with the database. I can nc the database just
fine, and the credentials should be correct, so I'm not sure why we're
still stuck, but I think this is at least a step forward.

Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Debug:[config]
GetDBParams(+365): error getting config! [sortdriver]
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Debug:[config]
GetDBParams(+367): error getting config! [serverid]
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Debug:[config]
GetDBParams(+373): error getting config! [max_db_connections]
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Debug:[db]
db_connect(+201): dburi: mysql://db:||||| <at> mysqldb:5038/dbmail
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Database:[db]
db_connect(+244): db at dburi: [mysql://db:||||| <at> mysqldb:5038/dbmail]
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Info:[db]
db_connect(+254): database connection pool created with maximum connections
of [10]
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Database:[db]
db_connect(+258): run a database connection reaper thread every [60]
seconds
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Database:[db]
db_connect(+263): database connection pool started with [5] connections,
max [10]
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Database:[db]
db_con_close(+342): [0x7f725db33370] connection to pool
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Database:[db]
db_con_get(+314): [0x7f725db33370] connection from pool
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Database:[db]
db_query(+414): [0x7f725db33370] [SELECT 1=1 FROM dbmail_users LIMIT 1
OFFSET 0]
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Database:[db]
log_query_time(+358): last query took [0.002] seconds 

---------------------------------------------------------------------- 
 (0003733) Gorbash (reporter) - 15-Jan-16 18:24
 http://www.dbmail.org/mantis/view.php?id=1076#c3733 
---------------------------------------------------------------------- 
Additional messages:

Debug:[auth] auth_load_driver(+47): no value for library_directory, using
default [/usr/lib64/dbmail]
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Debug:[auth]
auth_load_driver(+72): looking for auth_sql as
/builddir/build/BUILD/dbmail-3.2.3/src/modules/.libs/libauth_sql.so
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Info:[auth]
auth_load_driver(+76): cannot load
/builddir/build/BUILD/dbmail-3.2.3/src/modules/.libs/libauth_sql.so: cannot
open shared object file: No such file or directory
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Debug:[auth]
auth_load_driver(+72): looking for auth_sql as
/usr/lib64/dbmail/libauth_sql.so
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Database:[db]
db_con_get(+314): [0x7f725db33370] connection from pool 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
12-Nov-15 15:48  Gorbash        New Issue                                    
12-Nov-15 15:52  Gorbash        Issue Monitored: Gorbash                     
12-Nov-15 15:57  thelounge      Note Added: 0003707                          
12-Nov-15 16:29  Gorbash        Note Added: 0003708                          
12-Nov-15 16:45  thelounge      Note Added: 0003709                          
13-Nov-15 16:28  Gorbash        Note Added: 0003710                          
27-Nov-15 22:14  Gorbash        Note Added: 0003711                          
03-Dec-15 22:34  Gorbash        Note Added: 0003712                          
08-Dec-15 16:30  Gorbash        Note Added: 0003713                          
23-Dec-15 20:41  Gorbash        Note Added: 0003716                          
24-Dec-15 15:13  Gorbash        Note Added: 0003717                          
24-Dec-15 15:38  thelounge      Note Added: 0003718                          
28-Dec-15 21:04  Gorbash        Note Added: 0003719                          
28-Dec-15 21:13  thelounge      Note Added: 0003720                          
28-Dec-15 21:30  Gorbash        Note Added: 0003721                          
28-Dec-15 23:00  Gorbash        Note Added: 0003722                          
29-Dec-15 23:10  Gorbash        Note Added: 0003723                          
29-Dec-15 23:14  thelounge      Note Added: 0003724                          
05-Jan-16 22:20  Gorbash        Note Added: 0003726                          
11-Jan-16 17:49  Gorbash        Note Added: 0003727                          
11-Jan-16 17:51  thelounge      Note Added: 0003728                          
11-Jan-16 19:35  Gorbash        Note Added: 0003729                          
11-Jan-16 19:47  thelounge      Note Added: 0003730                          
13-Jan-16 23:21  Gorbash        Note Added: 0003731                          
15-Jan-16 18:14  Gorbash        Note Added: 0003732                          
15-Jan-16 18:24  Gorbash        Note Added: 0003733                          
======================================================================
Mantis Bug Tracker | 15 Jan 18:14 2016

[DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other


A NOTE has been added to this issue. 
====================================================================== 
http://www.dbmail.org/mantis/view.php?id=1076 
====================================================================== 
Reported By:                Gorbash
Assigned To:                
====================================================================== 
Project:                    DBMail
Issue ID:                   1076
Category:                   POP3 daemon
Reproducibility:            have not tried
Severity:                   block
Priority:                   normal
Status:                     new
target:                      
====================================================================== 
Date Submitted:             12-Nov-15 15:48 CET
Last Modified:              15-Jan-16 18:14 CET
====================================================================== 
Summary:                    DBMail services dbmail-pop3d OR dbmail-lmtpd remain
inactive after start and enable, erratic start on one or the other
Description: 
As part of testing an updated version of DBMail (a year or so newer than
the one we have in production), we set up a test RHEL server and pulled
version 3.1.16 from an existing channel. Unfortunately, after making sure
that the channel installed all the required libraries and files, and
updating the configuration URI to our test database, we've hit a snag.

The two DBMail services we use are dbmail-lmtpd and dbmail-pop3d. Every
time we try to start both services, one of the following things will
happen:
1. Both services stick at loaded/enabled but inactive, no PID files show
up, and logging in dbmail.err for each service stops at "effective group
shall be [nobody]"
2. One service will become active, but the other will stick at
loaded/enabled but inactive; the active service will have a PID file, but
not the inactive one, and logging in dbmail.err for the inactive service
stops at "effective group shall be [nobody]" while the other passes that
step and completes normally. When this happens, its usually (but not
always) the first service tried that becomes active.

Normally, the default config would produce "effective group shall be
[nogroup]", but RHEL 7 uses nobody/nobody instead of nobody/nogroup.
Nevertheless, I tried changing it back to nobody/nogroup in dbmail.conf,
and got a result matching http://www.dbmail.org/mantis/view.php?id=2, above.
We've also tried using a specific
account, and setting the referenced files to match that account, but in
that case, neither process will become active and no PID file is
generated.

The only other error message I've seen is a "can't drop permissions"
message from the active service in /var/log/dbmail, before the messages
from the inactive service start.

We haven't had this problem on our previous test or production servers, so
I think it might have something to do with RHEL 7. I'm hoping that's not
the case, however, as RHEL 7 dramatically improved the installation of
other services we've added onto this server. Any ideas on what this might
be stemming from?
====================================================================== 

---------------------------------------------------------------------- 
 (0003707) thelounge (reporter) - 12-Nov-15 15:57
 http://www.dbmail.org/mantis/view.php?id=1076#c3707 
---------------------------------------------------------------------- 
besides that 3.1.16 is missing a important bugfix from 3.1.17 that sounds
more like wrong systemd-units
effective group shall be [nogroup]", but RHEL 7 uses nobody/nobody instead
of nobody/nogroup.

i wonder really why because normally you have a user "dbmail" and a group
"dbmail" instead abuse "Nobody"
effective_user        = dbmail
effective_group       = dbmail

the units below are working here from Fedora 15 to Fedora 23
___________________________________________________________________

[root <at> srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-pop3d.service
[Unit]
Description=DBMail POP3 Server
After=network.service systemd-networkd.service network-online.target
mysqld.service
Before=dovecot.service

[Service]
Type=simple
ExecStart=/usr/sbin/dbmail-pop3d -D
Environment="LANG=en_GB.UTF-8"
Restart=always
RestartSec=1
TimeoutStopSec=5
LimitNOFILE=50000

PrivateTmp=yes
PrivateDevices=yes
CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE
CAP_SETGID CAP_SETUID

ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr

[Install] 
WantedBy=multi-user.target
___________________________________________________________________

[root <at> srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-lmtpd.service
[Unit]
Description=DBMail LMTP Server
After=network.service systemd-networkd.service network-online.target
mysqld.service 

[Service]
Type=simple
ExecStart=/usr/sbin/dbmail-lmtpd -D
Environment="LANG=en_GB.UTF-8"
Restart=always
RestartSec=1
TimeoutStopSec=5
LimitNOFILE=50000
PrivateTmp=yes
PrivateDevices=yes
CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE
CAP_SETGID CAP_SETUID
ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr

[Install]
WantedBy=multi-user.target 

---------------------------------------------------------------------- 
 (0003708) Gorbash (reporter) - 12-Nov-15 16:29
 http://www.dbmail.org/mantis/view.php?id=1076#c3708 
---------------------------------------------------------------------- 
--i wonder really why because normally you have a user "dbmail" and a group
"dbmail" instead abuse "Nobody"

Default on the configs is nobody/nogroup, and that's what our prod servers
(which are *not* RHEL 7) use. We also gave an alternate user (user exim /
group exim) a shot earlier, but I can give user / group dbmail a shot if
you think it'll work.

Meantime, since this install of DBmail was provided by a RedHat channel,
we've been using the systemd files that came with the RPM (listed below).
I'm a little hesitant about messing with them too much since they did come
from the channel, so they should have worked as-is.

# cat dbmail-pop3d.service 
[Unit]
Description=DBMail pop3 Server
After=syslog.target network.target mysqld.service postgresql.service

[Service]
Type=forking
EnvironmentFile=-/etc/sysconfig/dbmail-pop3d
ExecStart=/usr/sbin/dbmail-pop3d

[Install]
WantedBy=multi-user.target

# cat dbmail-lmtpd.service 
[Unit]
Description=DBMail LMTP Server
After=syslog.target network.target mysqld.service postgresql.service

[Service]
Type=forking
EnvironmentFile=-/etc/sysconfig/dbmail-lmtpd
ExecStart=/usr/sbin/dbmail-lmtpd

[Install]
WantedBy=multi-user.target 

---------------------------------------------------------------------- 
 (0003709) thelounge (reporter) - 12-Nov-15 16:45
 http://www.dbmail.org/mantis/view.php?id=1076#c3709 
---------------------------------------------------------------------- 
i doubt that dbmail 3.1.16 is from the default channel
since it are systemd-units it RHEL7
there is no dbmail at all except EPEL repo

epel repo has 3.2.3 and there was never 3.1.16
https://koji.fedoraproject.org/koji/packageinfo?packageID=1572

the epel-package clearly creates a dbmail user
____________________________________

%pre
getent group %{name} >/dev/null || groupadd -r %{name}
getent passwd %{name} >/dev/null || \
  useradd -r -M -g %{name} -d / -s /sbin/nologin \
  -c "DBMail Daemon" %{name}
exit 0
____________________________________

that part of the shipped "dbmail.conf" from the package is simply a bug
when due instal there is a user dbmail created

effective_user        = nobody
effective_group       = nogroup
____________________________________

that sed-snippet from the rpm-spec just don't work as intended because it's
uppercase and in the meantime the values in the sample config from the
tarball are lowercase, that said about the quality of the package, there is
a reason why i build my own rpm for the last 6 years

# make a couple of changes to the default dbmail.conf file:
# 1. default driver/authdriver sqlite/sql
# 2. effective uid/gid to dbmail/dbmail
sed -i 's/\(^driver\W*=\)\(\W*$\)/\1 sqlite/' dbmail.conf
sed -i -e 's,\(^db\W*=\)\(.*$\),\1 %{_localstatedir}/lib/dbmail/dbmail.db,'
  \
       -e 's/\(^authdriver\W*=\)\(\W*$\)/\1 sql/'                          
  \
       -e 's/\(^EFFECTIVE_USER\W*=\)\(.*$\)/\1 dbmail/'                    
  \
       -e 's/\(^EFFECTIVE_GROUP\W*=\)\(.*$\)/\1 dbmail/' dbmail.conf 

---------------------------------------------------------------------- 
 (0003710) Gorbash (reporter) - 13-Nov-15 16:28
 http://www.dbmail.org/mantis/view.php?id=1076#c3710 
---------------------------------------------------------------------- 
You're correct, we're on 3.2.3. I didn't see it as an option on dropdown,
so I picked the closest version in the dropdown (which would have been
3.1.17; apparently, I missed and hit 3.1.16 instead).

We're running off of a separate MySQL server as a database instead of
SQLite. Do I still need to change the default driver in that case?

I'm not really seeing any difference after changing the effective user and
group in dbmail.config to dbmail/dbmail. Do the associated files also have
to be assigned to dbmail/dbmail? 

---------------------------------------------------------------------- 
 (0003711) Gorbash (reporter) - 27-Nov-15 22:14
 http://www.dbmail.org/mantis/view.php?id=1076#c3711 
---------------------------------------------------------------------- 
We've switched to dbmail/dbmail, but neither dbmail-pop3d nor dbmail-lmtpd
are starting after the change.

Are you sure we should be changing the default driver? We're using a MySQL
server. 

---------------------------------------------------------------------- 
 (0003712) Gorbash (reporter) - 03-Dec-15 22:34
 http://www.dbmail.org/mantis/view.php?id=1076#c3712 
---------------------------------------------------------------------- 
Issue persists, even with the listed changes to our dbmail.conf file, and
all files owned by dbmail / dbmail. 

---------------------------------------------------------------------- 
 (0003713) Gorbash (reporter) - 08-Dec-15 16:30
 http://www.dbmail.org/mantis/view.php?id=1076#c3713 
---------------------------------------------------------------------- 
New dbmail.err logs are as follows:

Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000] Info:[debug]
configure_debug(+79): [POP] syslog [31 -> 31] stderr [31 -> 511]
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[server] server_config_load(+1015): max_db_connections [10]
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[config] config_get_timeout(+445): timeout [300] seconds
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[config] config_get_timeout(+456): login_timeout [60] seconds
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[server] server_config_load(+1024): no value for SOCKET in config
file
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[server] server_config_load(+1026): socket []
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[server] server_config_load(+1047): binding to PORT [110]
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[server] server_config_load(+1076): binding to IP [0.0.0.0]
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[server] server_config_load(+1082): no value for BACKLOG in config
file. Using default value [128]
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[server] server_config_load(+1086): POP backlog [128]
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[server] server_config_load(+1093): not resolving client IP
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[server] server_config_load(+1102): Disabling POP-before-SMTP
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[server] server_config_load(+1109): Disabling POP Authentication
logging
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[server] server_config_load(+1119): effective user shall be [dbmail]
Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000]
Debug:[server] server_config_load(+1128): effective group shall be
[dbmail]
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000] Info:[debug]
configure_debug(+79): [LMTP] syslog [31 -> 31] stderr [31 -> 511]
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[server] server_config_load(+1015): max_db_connections [10]
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[config] config_get_timeout(+445): timeout [300] seconds
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[config] config_get_timeout(+456): login_timeout [60] seconds
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[server] server_config_load(+1024): no value for SOCKET in config
file
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[server] server_config_load(+1026): socket []
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[server] server_config_load(+1047): binding to PORT [24]
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[server] server_config_load(+1076): binding to IP [0.0.0.0]
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[server] server_config_load(+1082): no value for BACKLOG in config
file. Using default value [128]
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[server] server_config_load(+1086): LMTP backlog [128]
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[server] server_config_load(+1093): not resolving client IP
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[server] server_config_load(+1100): no value for LMTP_BEFORE_SMTP  in
config file
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[server] server_config_load(+1102): Disabling LMTP-before-SMTP
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[server] server_config_load(+1109): Disabling LMTP Authentication
logging
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[server] server_config_load(+1119): effective user shall be [dbmail]
Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000]
Debug:[server] server_config_load(+1128): effective group shall be
[dbmail]

It looks like it cuts off at the same spot as with nobody/nobody. Could it
be a problem with the dbmail account that should have been generated with
it? 

---------------------------------------------------------------------- 
 (0003716) Gorbash (reporter) - 23-Dec-15 20:41
 http://www.dbmail.org/mantis/view.php?id=1076#c3716 
---------------------------------------------------------------------- 
We have now tried reinstalling this DBMail setup and setting effective
group / user to dbmail, and we're still running into the exact same issue,
with the logs cutting off at that point.

You mentioned earlier setting our authdriver to SQL and our driver to
sqlite. According to the config we have, the driver field is deprecated. I
can confirm our authdriver field is set to SQL; should I reactivate the
driver field and change it to sqlite?

Otherwise, I'm running out of ideas on what else we can try with this.
Should I just try building a new RPM based on the example you listed at the
beginning? 

---------------------------------------------------------------------- 
 (0003717) Gorbash (reporter) - 24-Dec-15 15:13
 http://www.dbmail.org/mantis/view.php?id=1076#c3717 
---------------------------------------------------------------------- 
I think I've spotted part of the problem.

You mention a dbmail.db in the line here:
"sed -i -e 's,\(^db\W*=\)\(.*$\),\1
%{_localstatedir}/lib/dbmail/dbmail.db,' \"

Not only do we not have a directory named dbmail in lib (though we have one
in lib64), we can't find a dbmail.db file anywhere within our structure.
The install should have created that file, correct? Could that be why we
can't start? 

---------------------------------------------------------------------- 
 (0003718) thelounge (reporter) - 24-Dec-15 15:38
 http://www.dbmail.org/mantis/view.php?id=1076#c3718 
---------------------------------------------------------------------- 
there is no "dbmail.db" when you are using mysql/postgreqsl as storage and
{_localstatedir} has nothing to do with lib64 - {_localstatedir} translates
to /var and so it would be /var/lib/dbmail/ the tyical runtime-data
directory like /var/lib/samba, /var/lib/hdcp, /var/lib/mysql and son on
which is by definition arch-agnostic 

---------------------------------------------------------------------- 
 (0003719) Gorbash (reporter) - 28-Dec-15 21:04
 http://www.dbmail.org/mantis/view.php?id=1076#c3719 
---------------------------------------------------------------------- 
If there's no dbmail.db, what is that line referencing? I would assume its
referring to the mysql db, but I wouldn't think the user the DB is running
would affect whether or not DBMail activates over here.

If that's the case, then changing to effective user DBMail and effective
group DBMail should have started this. Do you have any other ideas about
what might be preventing either process from starting? 

---------------------------------------------------------------------- 
 (0003720) thelounge (reporter) - 28-Dec-15 21:13
 http://www.dbmail.org/mantis/view.php?id=1076#c3720 
---------------------------------------------------------------------- 
it's likely referencing setups with no real db-server using sqlite

no, i have no idea what's preventing it to start, dbmail has a lot of bugs
but it's basically working here from Fedora 9 to Fedora 23 which covers
CentOS6/CentOS 7 over the last 7 years

what makes me sorrow is that the maintainer is silent for nearly a year now
but that's another story 

---------------------------------------------------------------------- 
 (0003721) Gorbash (reporter) - 28-Dec-15 21:30
 http://www.dbmail.org/mantis/view.php?id=1076#c3721 
---------------------------------------------------------------------- 
Well, thanks for the help regardless -- at least we've got one potential
problem tracked down. 

---------------------------------------------------------------------- 
 (0003722) Gorbash (reporter) - 28-Dec-15 23:00
 http://www.dbmail.org/mantis/view.php?id=1076#c3722 
---------------------------------------------------------------------- 
Hmm.... apparently, if I leave these "on" (loaded but inactive), I
occasionally get the following error messages 3-4 hours after I attempted
to start these processes.

Dec 27 03:15:01 oexdev1 dbmail-util[29998]: [0x7f24e9ddce00] Debug:[db]
db_connect(+201): dburi: mysql://dbmail:kL5cPdr2 <at> mysqldbqa:5038/dbmail
Failed. An error occured. Please check log.
Dec 28 03:13:01 oexdev1 dbmail-util[35221]: [0x7f41594b7e00] Debug:[config]
GetDBParams(+365): error getting config! [sortdriver]
Dec 28 03:13:01 oexdev1 dbmail-util[35221]: [0x7f41594b7e00] Debug:[config]
GetDBParams(+367): error getting config! [serverid]
Dec 28 03:13:01 oexdev1 dbmail-util[35221]: [0x7f41594b7e00] Debug:[config]
GetDBParams(+373): error getting config! [max_db_connections]

Is it possible that the processes are simply having trouble reading the
config?

We've tried setting the ownership of dbmail.conf to root, the dbmail user,
and nobody, in turn, without seeing any difference. Right now, dbmail.conf
is in /etc/. Is there any chance these processes might be looking in the
wrong folder for dbmail.conf? They're obviously finding it to determine
which user to use [as the errors will change to "effective user = dbmail"
when told to use user dbmail], but maybe there's another step its failing
to complete. 

---------------------------------------------------------------------- 
 (0003723) Gorbash (reporter) - 29-Dec-15 23:10
 http://www.dbmail.org/mantis/view.php?id=1076#c3723 
---------------------------------------------------------------------- 
I went back and compared the dbmail.err file results on here to on our much
older, existing, manually installed servers, and it looks like the process
is stopping in between when the effective user and group is assigned and
when DBMail checks the configs for a CA file and Certificate.

Now, neither of these should be running with an active Certificate (both
configs have blank certificate designations). Its possible the older one
has a certificate on it, but I don't think it does.

Is it possible that dbmail is failing while looking for a certificate that
doesn't exist? 

---------------------------------------------------------------------- 
 (0003724) thelounge (reporter) - 29-Dec-15 23:14
 http://www.dbmail.org/mantis/view.php?id=1076#c3724 
---------------------------------------------------------------------- 
unlikely, the TLS stuff is commented out here because TLS offloading is
done by dovecot running as IMAP proxy on the same machine for several
reasons (ath mechs, sharing auth for postfix SASL, stability)

[root <at> mail:~]$ rpm -q dbmail
dbmail-3.1.17-3.fc22.20151012.rh.3.1.17.x86_64

[root <at> mail:~]$ cat dbmail.conf 
[DBMAIL]
dburi                 =
mysql://dbmail:************ <at> localhost/dbmail?unix-socket=/var/lib/mysql/mysql.sock&charset=utf8
authdriver            = sql
table_prefix          = dbmail_
max_db_connections    = 25

encoding              = utf8
default_msg_encoding  = utf8
postmaster            = postmaster@...
sendmail              = /usr/sbin/sendmail

syslog_logging_levels = 31
query_time_info       = 10
query_time_notice     = 15
query_time_warning    = 30
query_timeout         = 300

effective_user        = dbmail
effective_group       = dbmail

# tls_cafile          = /etc/pki/tls/certs/ca-bundle.crt
# tls_cert            = /etc/postfix/certs/mail.thelounge.net.pem
# tls_key             = /etc/postfix/certs/mail.thelounge.net.pem
# tls_ciphers         =
ALL:!aNULL:!eNULL:!ADH!LOW:!MEDIUM:!EXP:!SSLv2:HIGH
# file_logging_levels = 511

backlog               = 256
timeout               = 300
login_timeout         = 60
resolve_ip            = no
authlog               = no
logfile               = /var/log/dbmail.log
errorlog              = /var/log/dbmail.err
pid_directory         = /run/dbmail
header_cache_readonly = yes

[LMTP]
bindip                = 127.0.0.1
port                  = 24
banner                = LMTP
timeout               = 1800
max_db_connections    = 1

[POP]
bindip                = 127.0.0.1
port                  = 110
pop_before_smtp       = no
banner                = POP3
timeout               = 1800

[IMAP]
bindip                = 127.0.0.1
port                  = 143
idle_timeout          = 35
imap_before_smtp      = no
capability            = IMAP4 IMAP4rev1 AUTH=LOGIN ACL RIGHTS=texk
NAMESPACE CHILDREN SORT QUOTA THREAD=ORDEREDSUBJECT UNSELECT IDLE
banner                = IMAP
timeout               = 3600
max_message_size      = 26214400

[SIEVE]
bindip                = *
port                  = 2000
banner                = SIEVE

[DELIVERY]
auto_reply            = yes
suppress_duplicates   = yes
sieve                 = yes
subaddress            = yes
sieve_vacation        = no
sieve_notify          = no
sieve_debug           = no
auto_notify           = no
quota_failure         = hard 

---------------------------------------------------------------------- 
 (0003726) Gorbash (reporter) - 05-Jan-16 22:20
 http://www.dbmail.org/mantis/view.php?id=1076#c3726 
---------------------------------------------------------------------- 
I'm not really seeing a lot of differences that should lead to this. 

I dug into server.c, which is the file that sends the "server_config_load"
messages that debug is catching, and I found where in the stream the
"effective user shall be" and "effective group shall be" messages are set
off. Right afterwards is the section of code where the script checks for
certificate information. I noticed a difference in that section between the
code on our working 3.1.7 server and this server:

-----------------------------------
3.1.7 version:
	/* read items: TLS_CAFILE */
	config_get_value("TLS_CAFILE", service, val);
	if(strlen(val) == 0)
		TRACE(TRACE_WARNING, "no value for TLS_CAFILE in config file");
	strncpy(config->tls_cafile, val, FIELDSIZE);
        config->tls_cafile[FIELDSIZE - 1] = '\0';

        TRACE(TRACE_DEBUG, "CA file is set to [%s]", config->tls_cafile);

	/* read items: TLS_CERT */
	config_get_value("TLS_CERT", service, val);
	if(strlen(val) == 0)
		TRACE(TRACE_WARNING, "no value for TLS_CERT in config file");
	strncpy(config->tls_cert, val, FIELDSIZE);
        config->tls_cert[FIELDSIZE - 1] = '\0';

        TRACE(TRACE_DEBUG, "Certificate file is set to [%s]",
config->tls_cert);

	/* read items: TLS_KEY */
	config_get_value("TLS_KEY", service, val);
	if(strlen(val) == 0)
		TRACE(TRACE_WARNING, "no value for TLS_KEY in config file");
	strncpy(config->tls_key, val, FIELDSIZE);
        config->tls_key[FIELDSIZE - 1] = '\0';

        TRACE(TRACE_DEBUG, "Key file is set to [%s]", config->tls_key);

	/* read items: TLS_CIPHERS */
	config_get_value("TLS_CIPHERS", service, val);
	if(strlen(val) == 0)
		TRACE(TRACE_INFO, "no value for TLS_CIPHERS in config file");
	strncpy(config->tls_ciphers, val, FIELDSIZE);
        config->tls_ciphers[FIELDSIZE - 1] = '\0';

        TRACE(TRACE_DEBUG, "Cipher string is set to [%s]",
config->tls_ciphers);

	strncpy(config->service_name, service, FIELDSIZE);

3.2.3's version:
	/* read items: TLS_CAFILE */
	config_get_value("TLS_CAFILE", service, val);
	if(strlen(val)) {
		strncpy(config->tls_cafile, val, FIELDSIZE-1);
		TRACE(TRACE_DEBUG, "CA file is set to [%s]", config->tls_cafile);
	}

	/* read items: TLS_CERT */
	config_get_value("TLS_CERT", service, val);
	if(strlen(val)) {
		strncpy(config->tls_cert, val, FIELDSIZE-1);
		TRACE(TRACE_DEBUG, "Certificate file is set to [%s]", config->tls_cert);
	}

	/* read items: TLS_KEY */
	config_get_value("TLS_KEY", service, val);
	if(strlen(val)) {
		strncpy(config->tls_key, val, FIELDSIZE-1);
		TRACE(TRACE_DEBUG, "Key file is set to [%s]", config->tls_key);
	}

	/* read items: TLS_CIPHERS */
	config_get_value("TLS_CIPHERS", service, val);
	if(strlen(val)) {
		strncpy(config->tls_ciphers, val, FIELDSIZE-1);
		TRACE(TRACE_DEBUG, "Cipher string is set to [%s]", config->tls_ciphers);
	}

	strncpy(config->service_name, service, FIELDSIZE);

----------------------------

Our TLS information is currently blank, because as far as I knew, we were
not required to have certs in order to pass a message through. Our old
server 3.1.7 server doesn't have certs set up on it either.

What I think might be happening is that the script is hitting "
if(strlen(val)) " and dying on a null value, where the old cert would
acknowledge that " null != 0 " and keep going.

I tried commenting out the cert lines in the config, and it ran into the
same problem as previously (stopping after "effective group). However, when
I added in a fake cert name, it went a little bit further -- dbmail
remained inactive, but the logs progressed further. 

These lines are at the end of the server.c script, meaning that the problem
could also be occurring as part of calling the next script, or during the
next script (if there aren't any debug lines in that script). I'm not
certain what the next script is.

The problem could also be occurring at the " strncpy(config->service_name,
service, FIELDSIZE); " line; I'm not really certain what that one is
calling.

I'm going to try setting up cert information for this as a first step. With
any luck, this might resolve the issue. 

---------------------------------------------------------------------- 
 (0003727) Gorbash (reporter) - 11-Jan-16 17:49
 http://www.dbmail.org/mantis/view.php?id=1076#c3727 
---------------------------------------------------------------------- 
Okay, so putting in fake cert information (i.e. just a cert name and
location, without installing an actual cert file) pushed DBMail past where
it was getting stuck previously, but it still didn't become an active
process, and I think that's because it was looking for a cert that wasn't
actually there.

Putting in a fully-signed cert is a process I can handle, but I'd rather
avoid it until I'm certain that's what's needed to resolve the issue.

I can correct the line of code itself, but server.c is source code that is
compiled into a "server" file on install. And unfortunately, it looks like
that server file is encrypted, or at least can't be edited the way
everything else can be.

Editing the source code sounds kind of extreme, but its generally better
than paying for a signed cert that possibly won't fix the problem, right? 

---------------------------------------------------------------------- 
 (0003728) thelounge (reporter) - 11-Jan-16 17:51
 http://www.dbmail.org/mantis/view.php?id=1076#c3728 
---------------------------------------------------------------------- 
"but its generally better than paying for a signed cert that possibly won't
fix the problem" - why can't you just create a self signed certificate to
verify your assumptions? 

---------------------------------------------------------------------- 
 (0003729) Gorbash (reporter) - 11-Jan-16 19:35
 http://www.dbmail.org/mantis/view.php?id=1076#c3729 
---------------------------------------------------------------------- 
Will tls_cafile and tls_ciphers work with a self-signed cert? 

---------------------------------------------------------------------- 
 (0003730) thelounge (reporter) - 11-Jan-16 19:47
 http://www.dbmail.org/mantis/view.php?id=1076#c3730 
---------------------------------------------------------------------- 
"tls_ciphers" has NOTHING to do with the certificates or CA

i already postet my configuration and guess what "localhost.pem" was
a pem-file which is nothing else than "cat crtfule keyfile >
localhost.pem"

ca_file don't matter - to be honest - in the time you are asking that you
could have entered "create selfsigned certificate" in Google and try it

# tls_cafile          = /etc/pki/tls/certs/ca-bundle.crt                   

                                                           
# tls_cert            = /etc/postfix/certs/localhost.pem                   

                                                           
# tls_key             = /etc/postfix/certs/localhost.pem                   

                                                           
# tls_ciphers         = ALL:!aNULL:!eNULL:!ADH!LOW:!MEDIUM:!EXP:!SSLv2:HIGH 

---------------------------------------------------------------------- 
 (0003731) Gorbash (reporter) - 13-Jan-16 23:21
 http://www.dbmail.org/mantis/view.php?id=1076#c3731 
---------------------------------------------------------------------- 
No good. It took the self-signed cert, and the debug file stops right after
that. The service still sits at enabled/inactive. 

---------------------------------------------------------------------- 
 (0003732) Gorbash (reporter) - 15-Jan-16 18:14
 http://www.dbmail.org/mantis/view.php?id=1076#c3732 
---------------------------------------------------------------------- 
Okay, no, I take that back. Now its on inactive and disabled. Curious.

I'm also not seeing a connection from this server on the database -- I was
when the processes got to inactive/enabled status, but not now.

In addition, we got a few new errors sometime early this morning. From
this... I'm think we're close, and its possible that DBMail is now just
having connection issues with the database. I can nc the database just
fine, and the credentials should be correct, so I'm not sure why we're
still stuck, but I think this is at least a step forward.

Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Debug:[config]
GetDBParams(+365): error getting config! [sortdriver]
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Debug:[config]
GetDBParams(+367): error getting config! [serverid]
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Debug:[config]
GetDBParams(+373): error getting config! [max_db_connections]
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Debug:[db]
db_connect(+201): dburi: mysql://db:||||| <at> mysqldb:5038/dbmail
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Database:[db]
db_connect(+244): db at dburi: [mysql://db:||||| <at> mysqldb:5038/dbmail]
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Info:[db]
db_connect(+254): database connection pool created with maximum connections
of [10]
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Database:[db]
db_connect(+258): run a database connection reaper thread every [60]
seconds
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Database:[db]
db_connect(+263): database connection pool started with [5] connections,
max [10]
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Database:[db]
db_con_close(+342): [0x7f725db33370] connection to pool
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Database:[db]
db_con_get(+314): [0x7f725db33370] connection from pool
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Database:[db]
db_query(+414): [0x7f725db33370] [SELECT 1=1 FROM dbmail_users LIMIT 1
OFFSET 0]
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Database:[db]
log_query_time(+358): last query took [0.002] seconds 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
12-Nov-15 15:48  Gorbash        New Issue                                    
12-Nov-15 15:52  Gorbash        Issue Monitored: Gorbash                     
12-Nov-15 15:57  thelounge      Note Added: 0003707                          
12-Nov-15 16:29  Gorbash        Note Added: 0003708                          
12-Nov-15 16:45  thelounge      Note Added: 0003709                          
13-Nov-15 16:28  Gorbash        Note Added: 0003710                          
27-Nov-15 22:14  Gorbash        Note Added: 0003711                          
03-Dec-15 22:34  Gorbash        Note Added: 0003712                          
08-Dec-15 16:30  Gorbash        Note Added: 0003713                          
23-Dec-15 20:41  Gorbash        Note Added: 0003716                          
24-Dec-15 15:13  Gorbash        Note Added: 0003717                          
24-Dec-15 15:38  thelounge      Note Added: 0003718                          
28-Dec-15 21:04  Gorbash        Note Added: 0003719                          
28-Dec-15 21:13  thelounge      Note Added: 0003720                          
28-Dec-15 21:30  Gorbash        Note Added: 0003721                          
28-Dec-15 23:00  Gorbash        Note Added: 0003722                          
29-Dec-15 23:10  Gorbash        Note Added: 0003723                          
29-Dec-15 23:14  thelounge      Note Added: 0003724                          
05-Jan-16 22:20  Gorbash        Note Added: 0003726                          
11-Jan-16 17:49  Gorbash        Note Added: 0003727                          
11-Jan-16 17:51  thelounge      Note Added: 0003728                          
11-Jan-16 19:35  Gorbash        Note Added: 0003729                          
11-Jan-16 19:47  thelounge      Note Added: 0003730                          
13-Jan-16 23:21  Gorbash        Note Added: 0003731                          
15-Jan-16 18:14  Gorbash        Note Added: 0003732                          
======================================================================
Chedomir Nikolikj | 14 Jan 15:12 2016

Migrating an account to another dbmail instance...

hello folks,

I've been looking around for a solution/tool that will help me migrate 
an account from one dbmail instance to another. What I want to achieve 
is to migrate an account from one dbmail instance to another completely, 
including ACLs, filters, auto-replies etc...

That being said, tools like imapsync doesn't help here. Also, both 
dbmail instances have users already in-place, so using something like:

# create table export_users as select * from dbmail_users where 
user_idnr = <IDNR>
# pg_dump --table=export_users --data-only --column-inserts dbmail > 
export_users.sql

for all relevant tables would not work because of db key/id conflicts.

could someone point me to the right direction or shed some light on 
this? I believe writing a custom tool would do the job, but really is 
that the only option I have in this situation?

thanks

Gmane