Error updating Exim from 4.96.1-7-g79877b70e to 4.97

[quags]

In the middle of a compile now, 'task=action=rewrite&value=httpd' after each php run plus cagefs really ads up. I'd recommend, since there appears to be no alternative

* run task=action=rewrite&value=httpd only after all php rebuilds complete
* dovecot is offline immediately, and potentially php will shows errors on sites running a non cloudlinux php version. It is important to get php, then dovecot, then exim compiled as fast as possible. Getting custombuild to be able to run a two compiles at once would help if we can background php, dovecot, then do the rest of build all normally.

 

[zEitEr]

//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_read_alloc@KEYUTILS_0.3'
//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_set_timeout@KEYUTILS_1.0'
//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_unlink@KEYUTILS_0.3'
//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_get_keyring_ID@KEYUTILS_0.3'
//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_get_persistent@KEYUTILS_1.5'
//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_link@KEYUTILS_0.3'
//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_describe_alloc@KEYUTILS_0.3'
//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_search@KEYUTILS_0.3'
//usr/lib64/libkrb5.so.3: undefined reference to `add_key@KEYUTILS_0.3'
//usr/lib64/libkrb5.so.3: undefined reference to `keyctl_clear@KEYUTILS_0.3'
collect2: error: ld returned 1 exit status

Have this issue on AlmaLinux 8 when building Dovecot and PHP 8.2. The craziest thing is the "./configure" part of the installation fails when using "da build" command, but it succeeds when I trigger the "./configure" from CLI.

Already checked: no custom libraries are installed under "/usr/local/", AlmaLinux upgraded to the latest available, even tried to reinstall all "rpm" packages. Nothing helps yet.

How can it be that the same "./configure" fails to complete when executed from directadmin and succeeds when running manually?

For now can I see these differences:

- CLI:

checking for cURL support... yes
checking for libcurl >= 7.29.0... yes
checking for SSL support in libcurl... yes
checking for libcurl linked against old openssl... no
checking for curl_easy_perform in -lcurl... yes
checking for QDBM support... no

- DirectAdmin:

checking for libcurl >= 7.29.0... yes
checking for SSL support in libcurl... yes
checking for libcurl linked against old openssl... no
checking for curl_easy_perform in -lcurl... no
configure: error: There is something wrong. Please check config.log for more information.
Compiling PHP 8.2 ...
make: *** No targets specified and no makefile found.  Stop.

 

[Richard G]

Have this issue on AlmaLinux 8 when building Dovecot and PHP 8.2.

Oh this is odd. The day before yesterday I ran an update on an Almalinux 8.9 server, also Exim and Dovecot and php 8.1 were updated and no problem at all.
After that I did the update from Alma 8.9 to 8.10. Maybe the issue is somewhere in Alma 8.10 then?

 

[zEitEr]

Maybe the issue is somewhere in Alma 8.10 then?

This is the only AlmaLinux 8.x server having the issue. No other AlmaLinux 8.x servers are affected.

 

[romans]

Have this issue on AlmaLinux 8 when building Dovecot and PHP 8.2. The craziest thing is the "./configure" part of the installation fails when using "da build" command, but it succeeds when I trigger the "./configure" from CLI.

Already checked: no custom libraries are installed under "/usr/local/", AlmaLinux upgraded to the latest available, even tried to reinstall all "rpm" packages. Nothing helps yet.

How can it be that the same "./configure" fails to complete when executed from directadmin and succeeds when running manually?

For now can I see these differences:

- CLI:

checking for cURL support... yes
checking for libcurl >= 7.29.0... yes
checking for SSL support in libcurl... yes
checking for libcurl linked against old openssl... no
checking for curl_easy_perform in -lcurl... yes
checking for QDBM support... no

- DirectAdmin:

checking for libcurl >= 7.29.0... yes
checking for SSL support in libcurl... yes
checking for libcurl linked against old openssl... no
checking for curl_easy_perform in -lcurl... no
configure: error: There is something wrong. Please check config.log for more information.
Compiling PHP 8.2 ...
make: *** No targets specified and no makefile found.  Stop.

Do you have exactly the same output if you run these 2 commands ?

ls -la /usr/lib64/libkeyutils.so*

and

strace -o /dev/null ls -la /usr/lib64/libkeyutils.so*

 

[zEitEr]

Do you have exact the same output if you run these 2 commands ?

Good catch. It differs:

[root@server ~]# strace -o /dev/null ls -la /usr/lib64/libkeyutils.so*
lrwxrwxrwx 1 root root    27 Oct  8  2021 /usr/lib64/libkeyutils.so -> /usr/lib64/libkeyutils.so.1
lrwxrwxrwx 1 root root    20 Nov  6 15:49 /usr/lib64/libkeyutils.so.1 -> libkeyutils.so.1.6.2
-rwxr-xr-x 1 root root 16160 Oct  8  2021 /usr/lib64/libkeyutils.so.1.6
[root@server ~]#

[root@server ~]# ls -la /usr/lib64/libkeyutils.so*
lrwxrwxrwx 1 root root    27 Oct  8  2021 /usr/lib64/libkeyutils.so -> /usr/lib64/libkeyutils.so.1
lrwxrwxrwx 1 root root    20 Nov  6 15:49 /usr/lib64/libkeyutils.so.1 -> libkeyutils.so.1.6
-rwxr-xr-x 1 root root 16160 Oct  8  2021 /usr/lib64/libkeyutils.so.1.6
[root@server ~]#

Don't get how is it possible yet.

 

[romans]

It seems it is some malicious file "libkeyutils.so.1.6.2". We saw several servers with such file. But how it appeared there ... it is the question. We were not able to identify it and also were not able to find anything more suspicious.
To remove it you can use such commands:

strace -o /dev/null rm -fv /usr/lib64/libkeyutils.so.1.6.2
cd /usr/lib64/
rm -fv libkeyutils.so.1
ln -s libkeyutils.so.1.6 libkeyutils.so.1

But be careful not to removing the real /usr/lib64/libkeyutils.so.1.6 file (once I did it and needed to find the way how to copy that file from other server with the same OS )
After that you should be able to build PHP or Dovecot without the errors you mentioned above.

 

[zEitEr]

To remove it you can use such commands:

Thank you, it solved the issue

According to the following article it was possibly a SSHD rootkit:

- https://www.hkcert.org/blog/beware-...ials-in-server-updated-with-ebury-information