Mayur's BLOG

I had an issue where I had to disable eAccelerator for a single domain on my VPS.

I've seen instructions that say to put following lines .htaccess file in the site's root directory,

php_flag eaccelerator.enable 0
php_flag eaccelerator.optimizer 0


but when I did that trying to access any pages on that site resulted in a 500 error.

I found that the only way to make this work is to locate the VirtualHost section for the domain in question in /etc/httpd/conf/httpd.conf. Within that VirtualHost section, there should be a section that looks similar to this:



php_admin_value open_basedir "/home/site-name/:/usr/lib/php:/usr/local/lib/php:/tmp"



Add the following lines to this section, before the ""


php_flag eaccelerator.enable 0
php_flag eaccelerator.optimizer 0

Any suggestions or questions are welcome.

This is very known issue between CSF and ftp and it hangs while we change directory through ftp so this is what I tried to get this fixed.

Server the follwoing line in /etc/pure-ftpd.conf

Port range for passive connections replies. - for firewalling.

and simply comment it.

Then restart FTP and CSF and FTP should be working fine now.

Traditionally, the dist upgrade path that many were familiar with from the RH8/9->Fedora or similarly Fedora dist upgrades, have applied more or less to RHEL/CentOS but with the release of 4.5 and early releases of 5.0 the actual dist upgrade path was messy or nearly impossible. The early versions of 5.0 (up to 5.2) had excessive dependency issues with versions later than 4.4 for straight dist upgrades that would often result in a box blowing up on you or forcing a messy downgrade attempt of 4.5+ to 4.4 to try get things to dist upgrade. With more recent release updates the gap has closed and now dist upgrades on are far more reasonable to complete with little in the way of problems.

If you are currently running a version of RHEL/CentOS earlier than 4.8 (cat /etc/redhat-release) then please do a proper ‘yum update’ and get yourself on 4.8. Although this is intended for CentOS it “should” (read: at own risk) work on RHEL systems as well, in the unfortunate situation that something does blow up please post a comment and I will try to assist.

The first thing we must do is make sure none of our core binaries, libraries or other content is set immutable as this will cause a package to fail on installation. If you are running an earlier version of LES or you use immutable bits on system paths (sbin/bin/share/include/libexec/etc) then you should run the following:

wget http://www.rfxn.com/downloads/disable.les.rpmpkg
sh disable.les.rpmpkg

Once that is done we should go ahead and have a quick run through of cleaning up yum cache, double check that any pending updates are installed and rebuild the rpmdb:

rpm --rebuilddb
yum clean all
yum update

If for some reason the rpm rebuild hangs for more than a few minutes then you may need to manually clear the rpmdb files:

rm -f /var/lib/rpm/__db.00*
rpm --rebuilddb

If you run into any minor dependency issues for packages that are not essential, such as syslinux and lftp then you can either exclude them or better yet remove them. If you are not sure what a package does, then you should query it for description details and make an educated choice (rpm -qi PACKAGE):

rpm -e lftp syslinux mkboot

OR (but not recommended)

yum update --exclude=syslinux --exclude=lftp --exclude=mkboot

At this point you should be able to run a ‘yum update’ command with optional exclude and receive no errors (again, I recommend you remove conflicts items instead of using exclusions).

# yum update –exclude=nagios-plugins
Setting up Update Process
Setting up repositories
Reading repository metadata in from local files
Excluding Packages in global exclude list
Finished
No Packages marked for Update/Obsoletion

Now we are ready to get going, I have put together a small package that contains the needed packages for this upgrade in addition to a few that you might require to resolve dependency conflicts:

wget http://www.rfxn.com/downloads/CentOS-5up.tar.gz
tar xvfz CentOS-5up.tar.gz
cd CentOS-5up

We need to go ahead and setup the centos-release package as follows:

rpm -Uhv centos-release-*

If you see that CentOS-Base.repo was created as /etc/yum.repos.d/CentOS-Base.repo.rpmnew then go ahead and move it into the proper place:

mv /etc/yum.repos.d/CentOS-Base.repo.rpmnew /etc/yum.repos.d/CentOS-Base.repo

Now we are ready to go with kernel changes, this is an important part so pay attention. The key to successful upgrade is that you remove ALL OLD KERNELS as many packages will fail to install during the upgrade if they detect a release 4.x kernel due to minimum kernel version dependency checks. We will start with first installing the new kernel so it preserves grub templating:

rpm -ivh kernel-2.6.18-164.el5.i686.rpm kernel-devel-2.6.18-164.el5.i686.rpm --nodeps

NOTE: release 5.x has smp support integrated into the standard kernel, so no -smp version is required for mp systems

If you are running an older system the chances are you got allot of older kernel packages installed so make sure you get them all out of the way:

rpm -e $(rpm -qa | grep kernel | grep -v 2.6.18 | tr '\n' ' ')

You may end up with a few dependencies coming up such as lm_sensors and net-snmp if the list is fairly small and packages you do not recognize as critical (if unsure always query the package for info ‘rpm -qi PACKAGE’, remember you can reinstall them later):

# rpm -e $(rpm -qa | grep kernel | grep -v 2.6.18)
error: Failed dependencies:
kernel-utils is needed by (installed) lm_sensors-2.8.7-2.40.5.i386

The command the ended up being required on most of my servers to get the kernel packages and related dependencies came out to the following:

rpm -e $(rpm -qa | grep kernel | grep -v 2.6.18 | tr '\n' ' ') lm_sensors net-snmp net-snmp-devel net-snmp-utils

That said and done you should now only have 2 kernel packages installed which are the 2.6.18 release 5.x kernels, DO NOT under any circumstance continue if you still got 2.6.9 release 4.x kernels packages still installed, remove them!

# rpm -qa | grep -i kernel
kernel-2.6.18-164.el5
kernel-devel-2.6.18-164.el5

A cleanup of /etc/grub.conf may be required, though if all went as planned then the rpm command should have done this up for us but review it anyways for good measure. You should find that 2.6.18-164.el5 is the only kernel in the file, if it is not go ahead and clean it by removing all older entries for 2.6.9 kernels.

There is a known bug with python-elementtree package versions which cause yum/rpm to think the release 4.x version is newer than the 5.x version, to get around this without blowing up the entire python installation we need to remove the package from just the rpmdb as follows:

rpm -e --justdb python-elementtree --nodeps

We can now go ahead and use yum to start the upgrade process, this is a dry run and will take a few minutes to compile list of available packages and associated dependency checks. You should carry the exclude options, if any, that you used during the ‘yum update’ process as so to avoid unresolvable dependencies:

yum clean all
yum upgrade --exclude=nagios-plugins

You will end up with a small list of dependency errors, these should be resolved by again evaluating a packages need as a critical system component and either removing it with ‘rpm -e’ or excluding it with ‘–exclude’ (remember to query description with ‘rpm -qi PACKAGE’ if you are unsure what something does). In my case the packages that threw up red flags were stuff I had manually installed over time such as iftop and mrtg in addition to default installed samba, these can all safely be removed or excluded as you prefer (removal always safest to prevent dependency chain issues).

Error: Missing Dependency: libpcap.so.0.8.3 is needed by package iftop
Error: Missing Dependency: perl(Convert::ASN1) is needed by package samba
Error: Missing Dependency: libevent-1.1a.so.1 is needed bypackage nfs-utils
Error: Missing Dependency: perl-Socket6 is needed by package mrtg
Error: Missing Dependency: perl-IO-Socket-INET6 is needed by package mrtg


rpm -e iftop samba nfs-utils mrtg system-config-samba

At this point we should be ready to do a final dry run of with yum and see where we stand on dependencies, rerun the earlier ‘yum upgrade’ while making sure to carry over any exclude options you are using.

yum upgrade --exclude=nagios-plugins

You should now end up with a summary of actions that yum needs to perform, go ahead and kick it off… this will take a bit to complete so go grab some coffee/jolt/redbull and maybe a small snack cause it could be a long night if this blows up on you.

Transaction Summary
=============================================================================
Install 183 Package(s)
Update 327 Package(s)
Remove 0 Package(s)
Total download size: 299 M
Is this ok [y/N]:

Once yum has completed (hopefully without major errors) we need to fix a few things, the first is the rpmdb needs a rebuild due to version changes that will cause any rpm commands to fail:

# rpm -qa
rpmdb: Program version 4.3 doesn’t match environment version
error: db4 error(-30974) from dbenv->open: DB_VERSION_MISMATCH: Database environment version mismatch
error: cannot open Packages index using db3 – (-30974)
error: cannot open Packages database in /var/lib/rpm

This can be fixed by running the following to manually rebuild the rpmdb:

rm -f /var/lib/rpm/__db.00*
rpm --rebuilddb
yum clean all

The next issue on the list is python-elementtree and python-sqlite, one or both of these may have ended up in a broken state that will cause all yum commands to break, so we will go ahead and reinstall both of these for good measure:

rpm -e --justdb python-elementtree --nodeps
rpm -ivh python-elementtree-1.2.6-5.el5.i386.rpm
rpm -ivh python-sqlite-1.1.7-1.2.1.i386.rpm --nodeps --force

The yum command should now work, go ahead and run it with no options, if you do not get any errors you are all sorted.

Hopefully the install went well for you, the only thing left to do is go ahead and reboot the system; this is the last point at which you have to make backups (but we all maintain backups right?). For the sake of avoiding a heart attack if the system goes into an fsck, we will reboot with the -f option to skip fsck:

shutdown -rf now

That’s a wrap, I hope you found this HowTo useful, if you did run into any issues then go ahead and post them into the comments field and I will try to assist but when in doubt typically google is the fastest alternative.

About LimitIPConn
This is the distribution page for the Apache module mod_limitipconn.c, which allows web server administrators to limit the number of simultaneous downloads permitted from a single IP address

Official site: http://dominia.org/djao/limitipconn.html

well does this thing work with Cpanel ?
Answer :: Yes, it does.

Installing mod_limitipconn.c

Installing this was quick and easy. Login to your server through shell as the root user.

# wget http://dominia.org/djao/limit/mod_limitipconn-0.22.tar.gz
# tar -xzvf mod_limitipconn-0.22.tar.gz
# cd mod_limitipconn-0.22
# nano Makefile
Find
APXS = apxs
CHANGE TO:
APXS = /usr/local/apache/bin/apxs
Save

#make
#make install

This adds the module to httpd.conf and backs up the old configuration from httpd.conf.new

# vi /usr/local/apache/conf/httpd.conf
It should have added the following:

LoadModule limitipconn_module libexec/mod_limitipconn.so
and
AddModule mod_limitipconn.c

Now we need to setup the configuration for the site you want to add the limits to. Search the domain you want and go to the configuration for it in httpd.conf

You should be at the part like this:


ServerAlias www.domain.com domain.com

Add the following configuration that you want, this restricts 2 directories I have on my site to prevent users from downloading more than 1 video at a time, I have 2 separate rules.



MaxConnPerIP 1
# In this case, all MIME types other than audio/mpeg and video*
# are exempt from the limit check
OnlyIPLimit audio/mpeg video



MaxConnPerIP 1
# In this case, all MIME types other than audio/mpeg and video*
# are exempt from the limit check
OnlyIPLimit audio/mpeg video





So my whole entry for the domain looks like this:


ServerAlias www.domain.com domain.com
ServerAdmin webmaster@domain.com
DocumentRoot /home/domain/public_html
BytesLog domlogs/domain.com-bytes_log
ServerName www.domain.com

php_admin_value open_basedir "/home/domain:/usr/lib/php:/usr/local/lib/php:/tmp"



MaxConnPerIP 1
# In this case, all MIME types other than audio/mpeg and video*
# are exempt from the limit check
OnlyIPLimit audio/mpeg video



MaxConnPerIP 1
# In this case, all MIME types other than audio/mpeg and video*
# are exempt from the limit check
OnlyIPLimit audio/mpeg video



User domain
Group domain
CustomLog domlogs/domain.com combined
ScriptAlias /cgi-bin/ /home/domain/public_html/cgi-bin/



Save httpd.conf


Test Apache Configuration
# apachectl configtest start
Make sure it comes back ok without errors

# /scripts/restartsrv_httpd

Apache will restart. Try it out. Go to your limited directory and try to download 2 things (2 depends on your IP limit you set). You should get forwarded to a 503 Temporary Service page. We can customize that as well.

Any suggestions or questions are welcome.

Many of us use online services to monitor web server status, if it goes down, if all services are up and running fine, which send back notification by sms, email or others... Such tools help making server administrator's life easier, but what about taking an action even before that your service goes down ? To be able to take such actions you will need to be informed in-time about your services status, actual server load, ... etc. A solution is System Integrity Monitor (SIM), a system and services monitor for 'SysVinit' systems.

SIM is designed to be intuitive and modular in nature, and to provide a clean and informative status system. It does this by consistently verifying that services are online, load averages are in check, and log files are at reasonable sizes. Many other SIM modules sport different and in-depth features to bring a well rounded tool to your disposal to stop otherwise common issues daunting internet hosts.
SIM Features include :

* Service monitoring of HTTP, FTP, DNS, SSH, MYSQL & more
* Event tracking and alert system
* Auto restart ability for downed services
* Checks against network sockets & process list to ensure services are online
* Advanced HTTP service monitoring, to prevent commonly encountered issues
* System load monitor with customizable warnings & actions
* Ability to auto restart system with definable critical load level
* Priority change configurable for services, at warning or critical load level
* Informative command line status display
* Easily customizable configuration file
* Auto configuration script
* Auto cronjob setup feature
* Simple & Informative installation script
* Integrated auto-update feature

Install SIM :

$wget http://www.rfxn.com/downloads/sim-current.tar.gz
$tar xvfz sim-current.tar.gz
$cd sim*
$sudo ./setup -i

Configuration :

After installation, setup will run a configuration script which will guide through features that you would like to enable or disable. The configuration script should be located in /usr/local/sim/autoconf

Most interesting to configure is http, mysql, and server load. You can configure more monitor according to your needs such as FTP, ENSIM, SMTP ... etc.

SIM 2.5-4 Auto-Config Script

All questions default to value in brackets if no answer is given. If you
make a typo during the autoconf process, hit CTRL+C (^C) to abort and
rerun the autoconf script (/usr/local/sim/autoconf).

The below are general configuration options for SIM:
press return to continue...

Where is SIM installed ?
[/usr/local/sim]:

Where should the sim.log file be created ?
[/usr/local/sim/sim.log]:

Max size of sim.log before rotated ? (value in KB)
[128]:

What is the location of your kernel log ?
Found kernel log at /var/log/messages

Where should alerts be emailed to ? (e.g: root, user@domain)
[root]:

Disable alert emails after how many events, to avoid email flood ?
(Note: events stats are cleared daily)
[8]:

The below are configuration options for Service modules:
press return to continue...

Auto-restart services found to be offline ? (true=enable, false=disable)
[true]:

Enforce laxed service checking ? (true=enable, false=disable)
[true]:

Disable auto-restart after how many downed service events ?
(Note: events stats are cleared daily)
[10]:

Enable FTP service monitoring ? (true=enable, false=disable)
[false]:

Enable HTTP service monitoring ? (true=enable, false=disable)
[false]:true

Name of the HTTP service as appears in 'ps' ?
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.3/FAQ
Found service name as httpd

TCP/IP port that HTTP operates on ?
Found service port as 80

Path to HTTP service init script ?
Found service init script at /etc/init.d/httpd

Enable DNS service monitoring ? (true=enable, false=disable)
[false]:

Enable SSH service monitoring ? (true=enable, false=disable)
[false]:

Enable MYSQL service monitoring ? (true=enable, false=disable)
[false]:true

Name of the MYSQL service as appears in 'ps' ?
[mysqld]:

TCP/IP port that MYSQL operates on ?
[3306]:

Path to MYSQL service init script ?
Found service init script at /etc/init.d/mysql

Enable SMTP service monitoring ? (true=enable, false=disable)
[false]:

Enable XINET service monitoring ? (true=enable, false=disable)
[false]:

Enable ENSIM service monitoring ? (true=enable, false=disable)
[false]:

Enable NETWORK monitoring ? (true=enable, false=disable)
[false]:true

interface to monitor ?
[eth0]:

Path to NETWORK init script ?
[/etc/init.d/network]:

Enable LOAD monitor ? (true=enable, false=disable)
[false]:true

Load level before status condition 'warning' ?
[25]:

Load level before status condition 'critical' ?
[45]:

Enable a global (wall) message at status condition 'warning' & 'critical' ?
[false]:

Renice services at status condition 'warning' or 'critical' ?
(3 values - warn, crit, false - false=disabled)
[false]:

Stop nonessential services at status condition 'warning' or 'critical' ?
(3 values - warn, crit, false - false=disabled)
[false]:

Reboot system on status condition 'warning' or 'critical' ?
(3 values - warn, crit, false - false=disabled)
[false]:

Configuration completed, saving conf.sim...
Done, conf.sim saved to /usr/local/sim.

And you are done ! You can already have a look at /usr/local/sim/sim.log to see how your services are actually acting.

Suggestions and questions are welcome.

Is your /tmp directory simply getting overrun with SESS files? If so, try this:

make a file in scripts called cleantmp, put the following in it:

************
# This script cleans out /tmp of empty, root, cpanel
# and nobody session files in /tmp
# rev 2.0b by Darren - 8.19.07

# if --test is passed, we just show the results
if [ "$1" == "--test" ]
then
CMD="-exec ls -la"
echo "$0: test mode"
else
CMD="-exec rm -rf"
fi

if [ "$1" == "--help" ]
then
echo ""
echo "cleantmp will clean out your tmp directory for you"
echo ""
echo "Parameters:"
echo "--test to run in test mode"
echo "--help display this file"
echo "-a accountname to remove all files owned by account name"
echo "-e cleans out all empty (zero length) files"
echo ""
exit 0
fi

if [ "$1" == "-a" ]
then
echo ""
echo "Removing session file for account $2"
find /tmp -name "sess*" -user $2 -maxdepth 1 $CMD {} \;
echo "completed"
echo ""
exit 0
fi

if [ "$1" == "-e" ]
then
echo ""
echo "Cleaning out empty files from /tmp"
find /tmp -name "sess*" -empty -maxdepth 1 $CMD {} \;
echo "completed"
echo ""
exit 0
fi


# remove empty session files that are over 2 hours old
find /tmp -name "sess*" -empty -mmin +120 -maxdepth 1 $CMD {} \;

# remove root owned session files
find /tmp -name "sess*" -user root -maxdepth 1 $CMD {} \;

# remove nobody session files
find /tmp -name "*sess*" -user nobody -maxdepth 1 $CMD {} \;

# remove cpanel owned session files
find /tmp -name "sess*" -user cpanel -maxdepth 1 $CMD {} \;

# remove any session file over 5 hours old
find /tmp -name "sess*" -mmin +300 -maxdepth 1 $CMD {} \;

# remove any spamassassin file over 4 hours old
find /tmp -name ".spamassassin*" -mmin +240 -maxdepth 1 $CMD {} \;
************

Now save, and chmod it so it can be run (use your discretion for perm level):
chmod 755 /scripts/cleantmp

Run it as /scripts/cleantmp --test to view which files will be removed or /scripts/cleantmp -a accountname to remove all files owned by account name. And running it with "-e" will remove all empty session files.

What we do on most boxes is have it run in cron.hourly so that it purges session files. It cleans empties that are over 2 hours old, and normal ones that are over 5 hours old. Keep in mind, this may break software that uses "Keep Me Logged In Indefinitely" option for users. But the script could be easily modified to skip some session files if needed.

So, go to /etc/cron.hourly and create a file called cleantmp. Put this into it:

****************
#!/bin/bash

/scripts/cleantmp -e >/dev/null 2>&1
/scripts/cleantmp >/dev/null 2>&1
****************

and save it, then do the same permissions procedure as above. Now every hour, the script wil clean out empty and older SESS files and keep your sites up. Modify this and the other script as needed.

Hope this helps! Suggestions, questions are welcome.

To avoid the situation and automatically transfer the files so that the FTP session can process unattended, use the prompt command before using the mput or mget commands. The prompt command toggles between prompting on, where ftp will prompt you to choose yes or no before each file is transfered, and prompting off, which will copy all files without prompting. By default, prompting is on. So to continue to FTP transfer all files without asking, remember to issue prompt command before starting the transfer process. Ask it do not prompt before putting or getting the files, make sure that your existing files do have have the same file name as FTP will overwrite the existing files that exists on the destination directory automatically too. The command is simple, just a single word “prompt”:

ftp> prompt

Interactive mode off.

FTP command line utility should return Interactive mode off.

Thanks.