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 = postmas...@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
