Need Pre-Build Configuration File for Exim on DA

louie55

Verified User
Joined
May 4, 2004
Messages
113
Location
Nebraska
I need to build Exim from the source because my current Exim installation is not working. It is a long story why it isn't working, but it has something to do with a PHP exploit and viruses and IRC chat software being installed on the server. Somehow, all this malicious activity broke perl. Which in turn broke other programs such as vi and also Exim. We are currently in the process of getting ready to completely reinstall the OS and DA because of this exploit, however, we need to get this one running for at least a few more weeks while we get things ready for a new server.

I have compiled and reinstalled perl from source and compiled and reinstalled vi from source and both work now. However, when trying to start Exim, I get this error:

Starting exim: /usr/sbin/exim: error while loading shared libraries: libperl.so: cannot open shared object file: No such file or directory

This is exactly the same type of error that the vi editor was giving me before I recompiled it. Now it works, so I figure if I recompile Exim, it will work also. I tried the DA RPM's, but they don't make it better. I get the same error after installing them. Anyway, to compile Exim, it says:

Before building Exim, a local configuration file that specifies options independent of any operating system has to be created with the name Local/Makefile. A template for this file is supplied as the file src/EDITME, and it contains full descriptions of all the option settings therein. These descriptions are therefore not repeated here. If you are building Exim for the first time, the simplest thing to do is to copy src/EDITME to Local/Makefile, then read it and edit it appropriately.

There are three settings that you must supply, because Exim will not build without them. They are the location of the run time configuration file (CONFIGURE_FILE), the directory in which Exim binaries will be installed (BIN_DIRECTORY), and the identity of the Exim user (EXIM_USER and maybe EXIM_GROUP as well). The value of CONFIGURE_FILE can in fact be a colon-separated list of file names; Exim uses the first of them that exists.

My question is, does anybody have a copy of this file (or know where I can get one) that will work for RedHat 9 and DirectAdmin so that I don't miss anything in configuring this file.

Either that or let me know what to change in here before compiling. I think the binary directory should be /usr/sbin, but I'm not sure what the user/group id's should be, or the other stuff.

Thanks.

Louie
 
Have you written the DA support address and asked them if they have it?

Jeff
 
Ok, I'm getting build errors :mad: :(

Here is what is coming up:

In file included from exim.h:23,
from macros.h:12,
from exim.h:424,
from exim_dbmbuild.c:33:
os.h:14: redefinition of `flock_t'
os.h:14: `flock_t' previously declared here
In file included from exim.h:423,
from macros.h:12,
from exim.h:424,
from exim_dbmbuild.c:33:
local_scan.h:31: conflicting types for `LOCAL_SCAN_ACCEPT'
local_scan.h:31: previous declaration of `LOCAL_SCAN_ACCEPT'
local_scan.h:32: conflicting types for `LOCAL_SCAN_ACCEPT_FREEZE'
local_scan.h:32: previous declaration of `LOCAL_SCAN_ACCEPT_FREEZE'
local_scan.h:33: conflicting types for `LOCAL_SCAN_ACCEPT_QUEUE'
local_scan.h:33: previous declaration of `LOCAL_SCAN_ACCEPT_QUEUE'
local_scan.h:34: conflicting types for `LOCAL_SCAN_REJECT'
local_scan.h:34: previous declaration of `LOCAL_SCAN_REJECT'
local_scan.h:35: conflicting types for `LOCAL_SCAN_REJECT_NOLOGHDR'
local_scan.h:35: previous declaration of `LOCAL_SCAN_REJECT_NOLOGHDR'
local_scan.h:36: conflicting types for `LOCAL_SCAN_TEMPREJECT'
local_scan.h:36: previous declaration of `LOCAL_SCAN_TEMPREJECT'
local_scan.h:38: conflicting types for `LOCAL_SCAN_TEMPREJECT_NOLOGHDR'
local_scan.h:38: previous declaration of `LOCAL_SCAN_TEMPREJECT_NOLOGHDR'
local_scan.h:38: confused by earlier errors, bailing out

Any Ideas??

Louie
 
Instead of recompiling everything, why not figure out why libperl.so can't be found. By default, the DA exim uses an RPATH to find libperl.so, and on my system (CentOS 4.2) it is looking for it in /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE your system might be different, but in either case you can see where it wants to look for in with the command:
Code:
readelf -d /usr/sbin/exim | grep rpath
If it doesn't exist there, you could do a couple of things. One, add the path to libperl.so to /etc/ld.so.conf and run ldconfig, or update the exim startup script to add that path to the LD_LIBRARY_PATH. Either one should get you going until you can do an OS reload.
 
Wow, thanks! Adding the path and doing /sbin/ldconfig seemed to do the trick for the libperl.so problem. I think that exim started up now, but still not without error. During startup, it said there was a Segmentation Fault when starting spamd, but, I still think Exim itself is up and running. Going to test it now.

Louie
 
Well, it worked for 4 days, but, now is giving this error:

Starting exim: /usr/sbin/exim: error while loading shared libraries: /root/perlbak/i386-linux-thread-multi/CORE/libperl.so: unexpected reloc type 0x11

(the reason it is in /root/perlbak is because that is where I moved my old perl files after recompiling and installing the newer perl version. However, the new perl installation didn't have libperl.so, so I had to refer to the old files for that file)

Nothing was changed. The server seems to just keep corrupting itself as the days go by. I think the exploits did something to cause all this, but I don't know what! Chkrootkit and rkhunter didn't find much.

Also, DirectAdmin is also down this time. When starting, it says "OK", but it never really starts. Also, when I call the directadmin binary manually "directadmin d", it gives no errors, yet it doesn't start.

I think the server is dying fast.

Louie
 
Since you are on RedHat 9, why all the recompiling? You should be able to uninstall the perl and other packages and reinstall them. Of course the best thing to do, would be to reinsall/upgrade the OS to something more current, like CentOS or WBEL or even RedHat EL 4. At least there will be updates for any known exploits, unlike the RH9.
 
Back
Top