## WE HAVE A PRODUCTION MELTDOWN ## REVERT THE PACKAGE Version IN THE REPO ## I'm sorry, i wanted to warn you bevor this happend, but exim 4.99 has some bugs that need to get wiped out before it wents into production. This is a bnew topic we will discuss on the Exim Dev ML. Description of problem: Queries like this: ${lookup mysql{ SELECT '${quote_mysql:${domain}}' FROM mail_config WHERE ... }} end in while checking a list: unknown lookup type "mysql" Version-Release number of selected component (if applicable): 4.99 How reproducible: always Steps to Reproduce: you need a sql based config for this Actual results: exim no longer serves a purpose. Expected results: getting the mysql module back to work Additional info: I will contact Jeremy & the Exim team, he may know what happend. You will check for compile related issues. The runtime config says: # exim -bV Exim version 4.99 #2 built 04-Nov-2025 00:00:00 Copyright (c) University of Cambridge, 1995 - 2018 (c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2025 Hints DB: Berkeley DB: Berkeley DB 5.3.28: (September 9, 2013) Support for: Content_Scanning Exim_filter Sieve_filter crypteq Expand_dlfunc iconv() IPv6 PAM Perl OpenSSL TLS_resume DANE DKIM DMARC DNSSEC ESMTP_Limits ESMTP_Wellknown Event OCSP PIPECONNECT PRDR PROXY Queue_Ramp SOCKS SPF SRS TCP_Fast_Open Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz dbmnz dnsdb dsearch ldap ldapdn ldapm nis nis0 passwd spf sqlite Lookups (dynamic): mysql pgsql Authenticators (built-in): cram_md5 cyrus_sasl dovecot gsasl plaintext spa tls Routers (built-in): accept dnslookup ipliteral manualroute redirect queryprogram Transports (built-in): appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp Malware: f-protd f-prot6d drweb fsecure sophie clamd avast sock cmdline Fixed never_users: 0 Configure owner: 0:0 Size of off_t: 8 Configuration file is /etc/exim/exim.conf so the module is included, but not working.
found it: openat(AT_FDCWD, "/usr/lib64/exim/4.99-1.fc42/lookups/mysql_lookup.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) # rpm -ql exim-mysql-4.99-1.fc42.x86_64 ... /usr/lib64/exim/4.99-1.fc42/lookups/mysql.so The binary referes to the wrong libname. AND i found out, it searches for the wrong mysql conf ... which is not in etc/mysql/my.cnf, it is in /etc/my.cnf : access("/etc/mysql/my.cnf", R_OK) = -1 ENOENT (No such file or directory) But that not important now. QUICK WORKAROUND until the new rpm version is out: cd /usr/lib64/exim/4.99-1.fc42/lookups ln -s mysql.so mysql_lookup.so @Maintainers: Do a new build with a fix and send it out as a CRITPATH update. The current rpm destoryed any production system that uses mysql configs.
This is broken on the EPEL packages for EL9 as well. The same workaround applies.
Can also confirm it's broken in EPEL for EL8 in the same way.
(In reply to customercare from comment #1) > found it: > > openat(AT_FDCWD, "/usr/lib64/exim/4.99-1.fc42/lookups/mysql_lookup.so", > O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) > > # rpm -ql exim-mysql-4.99-1.fc42.x86_64 > ... > /usr/lib64/exim/4.99-1.fc42/lookups/mysql.so > > The binary referes to the wrong libname. > IMHO there was no related exim downstream change. > AND i found out, it searches for the wrong mysql conf ... which is not in > etc/mysql/my.cnf, it is in /etc/my.cnf : > > access("/etc/mysql/my.cnf", R_OK) = -1 ENOENT (No such file or > directory) > Isn't it handled by the mysql library and not the exim itself?
The lookup libs are without the _lookup suffix, e.g.: /usr/lib64/exim/4.99-1.fc44/lookups/pgsql.so /usr/lib64/exim/4.99-1.fc44/lookups/mysql.so No change here in comparison with the exim 4.98: /usr/lib64/exim/4.98.2-4.fc43/lookups/pgsql.so /usr/lib64/exim/4.98.2-4.fc43/lookups/mysql.so Maybe some upstream change?
I'd say this is due to upstream commit cccb2c06bbb96fa98edf6867f0eba4059aa757a0 https://github.com/Exim/exim/commit/cccb2c06bbb96fa98edf6867f0eba4059aa757a0 This makes the "load dynamic module" code path append `_lookup` to the name of the module to be loaded. I don't immediately see changes to make the loadable modules generated by the build process have that appended, though.
Yep: Yep, it seems like upstream bug: sprintf(CS big_buffer, "%s/%s", LOOKUP_MODULE_DIR, name); if (!(dl = dlopen(CS big_buffer, RTLD_NOW))) vs const uschar * path = string_sprintf( LOOKUP_MODULE_DIR "/%s_%s." DYNLIB_FN_EXT, name, class);
src/drtables.c But they forgot to change the lookup Makefile that still has: mysql.o mysql.so: $(HDRS) mysql.c palmface that they relesed it as a security bug fix release.
I will create upstream bug to be sure what's the upstream intention how to fix it, i.e. by dropping the _lookup suffix in the loader or by renaming the lookup libs.
I took care of informing the exim staff.
if you make the effort to change the sourcecode, you do it on purpose. So, mostlikely, the lib name will change.
Well, not to only blame the upstream, somebody could write fedora CI sanity test for checking the lookups, so it will not repeat in the future :)
(In reply to customercare from comment #10) > I took care of informing the exim staff. Thanks, could you link the upstream ticket? I would incorporate the upstream fix instead of home brewing my own solution :).
(In reply to Jaroslav Škarvada from comment #13) > (In reply to customercare from comment #10) > > I took care of informing the exim staff. > > Thanks, could you link the upstream ticket? I would incorporate the upstream > fix instead of home brewing my own solution :). hehe.. i have them on short call, but we already had a thread on the exim ML running, so i just added your findings and cced them. be ensured, it get fixed. you can fix it now temporary with a downstream fix: change the lib name or add a symlink to 4.99-2 build . That will go faster and servers, who already have that 4.99-1 package, are not working right now. The userbase is a need now.
Jeremy responded: >Nope. The project build sequence results in "<modname>_lookup.so" in a different directory >(along with .so files for any routers, transports, authenticators and other misc components >which the build config has been set to build as loadbable modules. >The file <modname>.so is a precursor, and they should not have been trying to use it. >I think this is a mistake in the Fedora package build. However, it is a step not well >detailed in Exim's documentation so I've added a bit of descriptions in EDITME file (which >becomes a makefile).
Here is your testcase, no idea how to set that up in the Fedora CI ;) You need a working database, but you don't need a sql setup in that db except a valid login. You DO NOT need a running exim to have that testcase working. exim.conf: # # Absolut minimum test config for db access # primary_hostname = testfarm.fedoraproject.org keep_environment = PATH smtp_max_synprot_errors = 0 smtp_accept_max = 100 smtp_accept_max_per_host = 20 message_logs = false hide mysql_servers = localhost/<DBNANE>/<DBUSER>/<DBPASSWORD> /exim.conf a working example: # exim -be '${lookup mysql {SELECT 1}}' 1 a none working example: # exim -be '${lookup mysql {SELECT * from mail_config LIMIT 1}}' Failed: unknown lookup type "mysql"
(In reply to customercare from comment #15) > Jeremy responded: > > > >Nope. The project build sequence results in "<modname>_lookup.so" in a different directory > >(along with .so files for any routers, transports, authenticators and other misc components > >which the build config has been set to build as loadbable modules. > > >The file <modname>.so is a precursor, and they should not have been trying to use it. > > >I think this is a mistake in the Fedora package build. However, it is a step not well > >detailed in Exim's documentation so I've added a bit of descriptions in EDITME file (which > >becomes a makefile). Now we are installing the files the following way (and we are doing it for at least a decade): mkdir -p $RPM_BUILD_ROOT%{_libdir}/exim/%{version}-%{release}/lookups for i in mysql.so pgsql.so do. install -m755 lookups/$i \ $RPM_BUILD_ROOT%{_libdir}/exim/%{version}-%{release}/lookups done So we could rename it during install, but I will wait for the upstream instructions how to correctly install it.
Jeremy said he changed the editme example file, but it's not yet in the official git.
(In reply to customercare from comment #16) > Here is your testcase, no idea how to set that up in the Fedora CI ;) > > You need a working database, but you don't need a sql setup in that db > except a valid login. > You DO NOT need a running exim to have that testcase working. > > exim.conf: > > # > # Absolut minimum test config for db access > # > > primary_hostname = testfarm.fedoraproject.org > > keep_environment = PATH > > smtp_max_synprot_errors = 0 > smtp_accept_max = 100 > smtp_accept_max_per_host = 20 > message_logs = false > > hide mysql_servers = localhost/<DBNANE>/<DBUSER>/<DBPASSWORD> > > /exim.conf > > a working example: > > # exim -be '${lookup mysql {SELECT 1}}' > 1 > > a none working example: > > # exim -be '${lookup mysql {SELECT * from mail_config LIMIT 1}}' > Failed: unknown lookup type "mysql" Thanks, could you provide the sql setup? I could write the test (unfortunately, I cannot spend much time on it now). The tests use beakerlib, which is simple bash wrapper, here e.g. is sanity test we have for postfix: https://src.fedoraproject.org/tests/postfix/blob/main/f/Sanity/simple-sanity-test
(In reply to customercare from comment #18) > Jeremy said he changed the editme example file, but it's not yet in the > official git. OK, as a temporal fix, I will change the install script now and will use the EDITME instructions later.
Created attachment 2114796 [details] INCOMPLETE a breakershell exim-mysql package test This still needs the database to be setuped.
From OS/Makefile-Base in exim 4.99: ... for d in lookup router transport auth miscmod; do \ for f in $${d}s/*.so; do \ [ -e $$f ] && ln $$f dynmodules/`basename $$f .so`_$$d.so; \ done; \ done; \ ...
that looks like something that works along with the src changes.
FEDORA-2025-1384b70f90 (exim-4.99-2.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2025-1384b70f90
FEDORA-2025-1384b70f90 (exim-4.99-2.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
Try this temporal fix: https://koji.fedoraproject.org/koji/taskinfo?taskID=139007634 If it works I will push it to other branches.
(In reply to customercare from comment #21) > Created attachment 2114796 [details] > INCOMPLETE a breakershell exim-mysql package test > > This still needs the database to be setuped. Thanks, it is a good start.
(In reply to Jaroslav Škarvada from comment #26) > Try this temporal fix: > https://koji.fedoraproject.org/koji/taskinfo?taskID=139007634 Works for me on F44.
FEDORA-2025-05363027e5 (exim-4.99-2.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-05363027e5
FEDORA-2025-5b000bcc3d (exim-4.99-3.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-5b000bcc3d
FEDORA-EPEL-2025-5baf2f08a1 (exim-4.99-2.el10_2) has been submitted as an update to Fedora EPEL 10.2. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-5baf2f08a1
FEDORA-EPEL-2025-a8f8abd969 (exim-4.99-2.el9) has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-a8f8abd969
FEDORA-EPEL-2025-316343e185 (exim-4.99-2.el8) has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-316343e185
FEDORA-EPEL-2025-5baf2f08a1 has been pushed to the Fedora EPEL 10.2 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-5baf2f08a1 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2025-a8f8abd969 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-a8f8abd969 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-5b000bcc3d has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-5b000bcc3d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-5b000bcc3d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2025-316343e185 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-316343e185 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-05363027e5 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-05363027e5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-05363027e5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Added the test: https://src.fedoraproject.org/tests/exim/blob/main/f/Sanity/sql-lookup
I also moved existing tests to https://src.fedoraproject.org/tests/exim and enabled gating. So far only in rawhide. The test was checked, it works, regarding the gating, we will see :).
FEDORA-EPEL-2025-5baf2f08a1 (exim-4.99-2.el10_2) has been pushed to the Fedora EPEL 10.2 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2025-a8f8abd969 (exim-4.99-2.el9) has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-05363027e5 (exim-4.99-2.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2025-316343e185 (exim-4.99-2.el8) has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-5b000bcc3d (exim-4.99-3.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
*** Bug 2415247 has been marked as a duplicate of this bug. ***