Error: Cannot find SSL binaries under /usr

This happens with the configure script for apache cannot find the “openssl” (or “ssleay”) binaries in any of
/usr/bin/openssl
/usr/sbin/openssl
/usr/apps/openssl

The usual location for “openssl” is /usr/bin/openssl

On a debian system, run

apt-get install openssl

DirectAdmin : Apache stops responding but is running

A few things that could cause that are:

Possible Causes:
1) MaxClients set to a value too low
2) If you have over about 800 sites, the ErrorLog files open too many file descriptors and apache won’t be able to log the errors and may stop responding.

Solutions:
1) edit /etc/httpd/conf/httpd.conf and increase the MaxClients setting to something like 200 or 300.
2)

cd /usr/local/directadmin/data/templates
cp virtual_host*.conf custom
cd custom

# remove all the ErrorLog lines (or comment them out) from the 4 virtual_host*.conf files that are in the custom directory.

echo “action=rewrite&value=httpd” >> /usr/local/directadmin/data/task.queue

Apache should be restarted automatically after a few minutes later (rewrite might take a while with over 800 sites).

3) Other possible information:
Edit /usr/include/bits/typesizes.h and set
#define __FD_SETSIZE 32768 
and then recompile with customapache or custombuild.

On FreeBSD, it’s /usr/include/sys/select.h or /usr/include/sys/types.h
Change:
#define FD_SETSIZE 1024U
to
#define FD_SETSIZE 32768U

then recompile apache/php

4) edit /etc/sysctl.conf and add:
fs.file-max = 32768

and run:

/sbin/sysctl -w fs.file-max=32768

then recompile apache/php

Other possible entires for the sysctl.conf:
kern.maxfiles = 32768
kern.maxfilesperproc = 32768

5) Another way to free up FileDescriptors (FDs) is to disable ssl on any domain that does not require it.
A quck way to check is to type:

ls -la /home/*/domains/*/private_html/index.html

quickly scan the list for any index.html that isn’t betwen 200-300 bytes in size. Any that are not in that range will have been edited and the user is probably using ssl, so take note of those usernames and domains. Now, the quick way to do a mass SSL shutoff for domains is to type:

perl -pi -e ‘s/ssl=ON/ssl=OFF/’ /usr/local/directadmin/data/users/*/domains/*.conf

Then turn ssl=ON back on for any users who need it. Note that this is an end user level setting, so they have the ability to turn it back on themselves via Domain Setup. Then type the action=rewrite&value=httpd command as mentioned in step 2 above.
What this does is reduced the number of FD’s by 50%. Since many people rarely use SSL, disabling it reduceds half of all virtualhosts, since all domains, subdomains, etc.. have 2 virtualhosts each with ssl, and only 1 each without ssl.

6) Openssl bug. Either update openssl and recompile apache, or patch apache 2:
http://issues.apache.org/bugzilla/show_bug.cgi?id=43717


Related error messages:
[error] System: Too many open files in system (errno: 23)

host: isc_socket_create: not enough free resources socket.c:2117: REQUIRE(maxfd <= (int)1024) failed.
host: isc_socket_create: not enough free resources

 

DirectAdmin FAQ

DirectAdmin : Updating Apache to the latest version

Updating Apache to the latest version

You can check the current version of apache by running

httpd -v

If you wish to update your 1.3 version of apache to the most recent, run the following:

cd /usr/local/directadmin/customapache
./build clean
./build update
./build apache_mod_ssl

If you’re using apache 2.x, use “./build apache_2” isntead of apache_mod_ssl.
This should update both the configure options and the version of apache to the most recent version. Once the update has completed, you’ll need to restart apache:

RedHat:

/sbin/service httpd restart

FreeBSD:

/usr/local/etc/rc.d/httpd restart

Crontab basics

cron is a unix, solaris utility that allows tasks to be automatically run in the background at regular intervals by the cron daemon. These tasks are often termed as cron jobs in unix , solaris.
Crontab (CRON TABle) is a file which contains the schedule of cron entries to be run and at specified times.


Crontab syntax


A crontab file has five fields for specifying day , date and time  followed by the command to be run at that interval.

*     *   *   *    *  command to be executed
–     –    –    –    –
|     |     |     |     |
|     |     |     |     +—– day of week (0 – 6) (Sunday=0)
|     |     |     +——- month (1 – 12)
|     |     +——— day of month (1 – 31)
|     +———– hour (0 – 23)
+————- min (0 – 59)

* in the value field above means all legal values as in braces for that column.
The value column can have a * or a list of elements separated by commas. An element is either a number in the ranges shown above or two numbers in the range separated by a hyphen (meaning an inclusive range).

Crontab Example

min      hour      day/month      month      day/week       Execution time
30     0     1     1,6,12     *     — 00:30 Hrs  on 1st of Jan, June & Dec.

0     20     *     10     1-5     –8.00 PM every weekday (Mon-Fri) only in Oct.

0     0     1,10,15     *     *     — midnight on 1st ,10th & 15th of month

5,10     0     10     *     1     — At 12.05,12.10 every Monday & on 10th of every month


By default cron jobs sends a email to the user account executing the cronjob. If this is not needed put the following command At the end of the cron job line .

>/dev/null 2>&1


To collect the cron execution execution log in a file :

30 18  *    *   *    rm /home/someuser/tmp/* > /home/someuser/cronlogs/clean_tmp_dir.log

DirectAdmin : Downgrade from apache 2 back to apache 1.3

How to downgrade from apache 2 back to apache 1.3
If you need to go back to apache 1.3 after installing apache 2, you’ll need to do the following:

1) Restore the old httpd.conf file:

cp -f /etc/httpd/conf/httpd.conf.1.3.backup /etc/httpd/conf/httpd.conf

2) Get DirectAdmin to use the old httpd.conf files for the users. Edit the /usr/local/directadmin/conf/directadmin.conf file and change apache_ver=2.0 to apache_ver=1.3. Also, if you were using custombuild, and are going back to customapache, the apache_conf value needs to be reset to:

apacheconf=/etc/httpd/conf/httpd.conf

Then type

echo “action=rewrite&value=ips” >> /usr/local/directadmin/data/task.queue
echo “action=rewrite&value=httpd” >> /usr/local/directadmin/data/task.queue
echo “action=directadmin&value=restart” >> /usr/local/directadmin/data/task.queue

3) Now you can recompile apache 1.3

rm -f /usr/lib/apache/*
cd /usr/local/directadmin/customapache
./build clean
./build all

4) Fix the modules link:

cd /etc/httpd
rm -f modules
ln -s /usr/lib/apache modules

5) Restore the old boot script:
FreeBSD:

cp -f /usr/local/directadmin/customapache/httpd_freebsd /usr/local/etc/rc.d/httpd
chmod 755 /usr/local/etc/rc.d/httpd
/usr/local/etc/rc.d/httpd restart

RedHat:

cp -f /usr/local/directadmin/customapache/httpd /etc/init.d/httpd
chmod 755 /etc/init.d/httpd
/etc/init.d/httpd restart

How do I upgrade Apache on my Cpanel box?

There are two ways to update your Apache version on cpanel.

The first is from within WHM. Underneath the “Software” section in the menubar is “Apache Update.” Click this link and then follow the on screen directions.

The second option is from the command line. Run “/scripts/easyapache”, which will provide an update interface including a few more options than WHM.

It is highly recommended that you create a backup of your Apache configuration before preforming an update to a newer version.

How to block ip addresses with iptables

I have an ip address attacking my server or taking up all my httpd connections so none of my sites work.

In order to correct this you will want to use the netstat -n command to see the ip addresses connected to your server. Once you have the ip address you want to block you can use the following command to block them from accessing your server using iptables

iptables -I INPUT 1 -s IP.ADD.RES.SS -j DROP

-I INPUT 1 means to insert the rule at the top of the INPUT table (which means it will get looked at first)

-s IP.ADD.RES.SS is the source address of the packets we want to deal with

-j DROP means dump the packets into the void, and forget they ever happened.

cgi files generate Internal Server Error

This means that the cgi script did not execute properly. There are several causes that can generate this error so a few things would need to be checked.

1) check the /var/log/httpd/suexec_log. It contains any errors that would be as a result of not having correct permissions on the file. The file needs to be in a cgi-bin and must have the owner/group as the username who owns the site. If it’s owned by anyone else, it will not run. Also, the script must have execute permission. The most common chmod permission is 755. Go through all directories from the public_html down to the directory the script is in, and make sure they’re all set to 755 (public_html can be 750 *only* if it has a group of apache).

If the suexec_log only shows the script being run, then the cause may be with the script code itself. The easiest way to figure out script coding problems is to first run the script manually from an ssh prompt.

cd /home/username/domains/domain.com/public_html/cgi-bin
./script.cgi

One common error is to use an incorrect interpreter. The 2 most common interpreters are:

#!/usr/bin/perl

and

#!/usr/local/bin/php

This code must appear on the first line of the script. Somtimes a file is uploaded in windows format so the trailing newline (return) character is formed incorrectly and the file would need to be reuploaded in a different format.

Other errors that would be generated when running the script manually from ssh would be missing perl modules, in which case you’ll need to install them yourself. Cpan is the easiest method to install new perl modules, eg:

perl -e shell -MCPAN
install Bundle::DBD::mysql