Mailing List Archive

[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: 23-Dec-15 20:41 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@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@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?

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
======================================================================

_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
[DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other [ In reply to ]
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: 24-Dec-15 15:13 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@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@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?

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
======================================================================

_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
[DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other [ In reply to ]
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: 24-Dec-15 15:38 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@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@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

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
======================================================================

_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
[DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other [ In reply to ]
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: 28-Dec-15 21:04 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@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@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?

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
======================================================================

_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
[DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other [ In reply to ]
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: 28-Dec-15 21:13 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@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@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

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
======================================================================

_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
[DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other [ In reply to ]
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: 28-Dec-15 21:30 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@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@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.

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
======================================================================

_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
[DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other [ In reply to ]
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: 28-Dec-15 23:00 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@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@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@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.

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
======================================================================

_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
[DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other [ In reply to ]
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: 29-Dec-15 23:10 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@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@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@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?

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
======================================================================

_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
[DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other [ In reply to ]
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: 29-Dec-15 23: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@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@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@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@mail:~]$ rpm -q dbmail
dbmail-3.1.17-3.fc22.20151012.rh.3.1.17.x86_64

[root@mail:~]$ cat dbmail.conf
[DBMAIL]
dburi =
mysql://dbmail:************@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@thelounge.net
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

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
======================================================================

_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
[DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other [ In reply to ]
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: 05-Jan-16 22:20 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@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@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@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@mail:~]$ rpm -q dbmail
dbmail-3.1.17-3.fc22.20151012.rh.3.1.17.x86_64

[root@mail:~]$ cat dbmail.conf
[DBMAIL]
dburi =
mysql://dbmail:************@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@thelounge.net
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.

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
======================================================================

_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
[DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other [ In reply to ]
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: 11-Jan-16 17:49 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@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@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@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@mail:~]$ rpm -q dbmail
dbmail-3.1.17-3.fc22.20151012.rh.3.1.17.x86_64

[root@mail:~]$ cat dbmail.conf
[DBMAIL]
dburi =
mysql://dbmail:************@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@thelounge.net
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?

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
======================================================================

_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
[DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other [ In reply to ]
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: 11-Jan-16 17:51 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@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@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@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@mail:~]$ rpm -q dbmail
dbmail-3.1.17-3.fc22.20151012.rh.3.1.17.x86_64

[root@mail:~]$ cat dbmail.conf
[DBMAIL]
dburi =
mysql://dbmail:************@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@thelounge.net
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?

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
======================================================================

_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
[DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other [ In reply to ]
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: 11-Jan-16 19:35 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@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@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@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@mail:~]$ rpm -q dbmail
dbmail-3.1.17-3.fc22.20151012.rh.3.1.17.x86_64

[root@mail:~]$ cat dbmail.conf
[DBMAIL]
dburi =
mysql://dbmail:************@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@thelounge.net
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?

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
======================================================================

_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
[DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other [ In reply to ]
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: 11-Jan-16 19:47 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@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@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@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@mail:~]$ rpm -q dbmail
dbmail-3.1.17-3.fc22.20151012.rh.3.1.17.x86_64

[root@mail:~]$ cat dbmail.conf
[DBMAIL]
dburi =
mysql://dbmail:************@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@thelounge.net
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

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
======================================================================

_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
[DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other [ In reply to ]
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: 13-Jan-16 23:21 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@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@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@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@mail:~]$ rpm -q dbmail
dbmail-3.1.17-3.fc22.20151012.rh.3.1.17.x86_64

[root@mail:~]$ cat dbmail.conf
[DBMAIL]
dburi =
mysql://dbmail:************@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@thelounge.net
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.

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
======================================================================

_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
[DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other [ In reply to ]
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@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@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@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@mail:~]$ rpm -q dbmail
dbmail-3.1.17-3.fc22.20151012.rh.3.1.17.x86_64

[root@mail:~]$ cat dbmail.conf
[DBMAIL]
dburi =
mysql://dbmail:************@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@thelounge.net
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:|||||@mysqldb:5038/dbmail
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Database:[db]
db_connect(+244): db at dburi: [mysql://db:|||||@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
======================================================================

_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
[DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other [ In reply to ]
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@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@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@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@mail:~]$ rpm -q dbmail
dbmail-3.1.17-3.fc22.20151012.rh.3.1.17.x86_64

[root@mail:~]$ cat dbmail.conf
[DBMAIL]
dburi =
mysql://dbmail:************@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@thelounge.net
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:|||||@mysqldb:5038/dbmail
Jan 15 03:21:01 oexdev1 dbmail-util[1749]: [0x7f725db33e00] Database:[db]
db_connect(+244): db at dburi: [mysql://db:|||||@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
======================================================================

_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev