Missing Dependency: perl(URI)

root@serverte [~]# yum install subversion
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* addons: centos.mirror.netriplex.com
* base: centos.mirror.netriplex.com
* extras: mirrors.igsobe.com
* updates: ftp.usf.edu
Excluding Packages in global exclude list
Finished
Setting up Install Process
Resolving Dependencies
–> Running transaction check
—> Package subversion.i386 0:1.6.11-7.el5_6.4 set to be updated
–> Processing Dependency: perl(URI) >= 1.17 for package: subversion
–> Finished Dependency Resolution
subversion-1.6.11-7.el5_6.4.i386 from updates has depsolving problems
–> Missing Dependency: perl(URI) >= 1.17 is needed by package subversion-1.6.11-7.el5_6.4.i386 (updates)

Packages skipped because of dependency problems:
subversion-1.6.11-7.el5_6.4.i386 from updates

Fix

wget http://mirror.centos.org/centos/5/os/i386/CentOS/perl-URI-1.35-3.noarch.rpm
rpm -Uvh perl-URI-1.35-3.noarch.rpm

Installing git on centos 6

I’m installing git on centos 6.

Install dependencies:

yum -y install zlib-devel openssl-devel cpio expat-devel

gettext-devel gcc perl-ExtUtils-MakeMaker

Install MakeMaker:

cd /usr/local/src
wget http://files.directadmin.com/services/9.0/ExtUtils-

MakeMaker-6.31.tar.gz
tar xvzf ExtUtils-MakeMaker-6.31.tar.gz
cd ExtUtils-MakeMaker-6.31
perl Makefile.PL
make
make install

Download and compile the latest git source:

cd /usr/local/src
wget http://git-core.googlecode.com/files/git-1.7.9.2.

tar.gz
tar xvzf git-1.7.9.tar.gz
cd git-1.7.9.2
./configure
make
make install

Test installation by initializing a new git repository:

cd ~/
mkdir test.git
cd test.git
git init

You should see “Initialized empty Git repository in /root/git-test/.git/” if the installation process was successful.

INSTALL GIT ON CENTOS CPANEL SERVER

I have a love/hate rela­tion­ship with cpanel. On one hand it makes low end host­ing a breeze, on the other its a huge pita if you want to do any­thing “out­side the box”. Per­haps it’s not such a pain if you work with cpanel fre­quently. But I find cpanel ben­e­fi­cial because it aids in tasks that I don’t do fre­quently, and can offload many of those tasks to less tech­ni­cal people.

I was recently set­ting up a cpanel instance for some­one and had the need to install git for ver­sion con­trol. I con­fig­ured the epel repos­i­tory for use as usual and went to yum install git only to be met with a nasty error.

git-1.5.5.6-2.el5.i386 from epel has depsolving problems
  --> Missing Dependency: perl(Error) is needed by package 
git-1.5.5.6-2.el5.i386 (epel)
git-1.5.5.6-2.el5.i386 from epel has depsolving problems
  --> Missing Dependency: perl-Git = 1.5.5.6-2.el5 is needed by package 
git-1.5.5.6-2.el5.i386 (epel)
git-1.5.5.6-2.el5.i386 from epel has depsolving problems
  --> Missing Dependency: perl(Git) is needed by package 
git-1.5.5.6-2.el5.i386 (epel)
Error: Missing Dependency: perl(Git) is needed by package 
git-1.5.5.6-2.el5.i386 (epel)
Error: Missing Dependency: perl(Error) is needed by package 
git-1.5.5.6-2.el5.i386 (epel)
Error: Missing Dependency: perl-Git = 1.5.5.6-2.el5 is needed by package 
git-1.5.5.6-2.el5.i386 (epel)

I was pretty sur­prised as I have installed git with­out issue before on Cen­tOS boxes before. A bit of dig­ging showed that installing cpanel actu­ally made some mod­i­fi­ca­tions to my /etc/yum.conf.

exclude=apache* bind-chroot courier* dove­cot* exim* httpd* mod_ssl* mysql* nsd* perl* php* proftpd* pure-ftpd* ruby* spa­mas­sas­sin* squirrelmail*

So cpanel has blocked all perl pack­ages from being installed or updated because they don’t want updates to break or con­flict with their pack­ages. Thank­fully yum pro­vides a nice one time workaround for this kind of situation.

–disableexcludes=[repo]
dis­able exclude from main, for a repo or for
everything

So one com­mand later and I now have git installed.

 yum --disableexcludes=main install git

How to Install ffmpeg, ffmpeg-php and codecs automagically

A client recently requested ffmpeg to be installed on the server. I have done this in the past on a client's box but he had a different OS setup.

Everyone loves automagic installations! After the first failure I bumped into a forum that let's you download a tarball and install ffmpeg without any hitches and within 20 minutes. This attempt did work!

Pros and Cons of Auto Installer

Con: The downside to the ffmpeg auto install script, you end up downloading and installing many ffmpeg related libraries you might not need.
Pros: No errors and installtions works as expected (at least for my setup).

There are a few things you should know before you get started:
Must be a Linux/Unix/POSIX server
Must need root shell(bash) access
Must need 200 MB of free space in your server
The author of this gpl ffmpeg auto install script will know your server ip (see below how to remove this) upon installation.
Check if yum is installed or not in the server. If there is no yum, please make sure automake,autoconf and libtools are installed. It is reccommend to configure the distribution specific yum.

Setup Installation

First, open up SSH (I like using putty) and login as "root". Once there, run the below commands:
mkdir ~/ffmpeg-packages
cd ~/ffmpeg-packages
wget http://trulymanaged.com/ffmpeg/ffmpeginstaller.tar.gz
tar -xvzf ffmpeginstall.tar.gz
cd ffmpeginstall

Now let's begin the installation process
./install.sh

Once the installation starts you will see the verbose messages, letting you know the status of the installation.

rkhunter software - Install Linux Rkhunter in RHEL, CentOS and Fedora

rkhunter (Rootkit Hunter) is a open source Unix/Linux based tool released under GPL  that scans for rootkits, backdoors and possible local exploits. rkhunter is a shell script which carries out various checks on the local system to try and detect known rootkits and malware. It also performs checks to see if commands have been modified, if the system startup files have been modified, and various checks on the network interfaces, including checks for listening applications. It scans haddressden files, wrong permissions set on binaries, suspicious strings in kernel etc. To know more about Rkhunter and its features visit http://www.rootkit.nl/.

Installing Rkhunter (Rootkit Hunter) in RHEL, CentOS and Fedora

Step 1: Downloading Rkhunter

Login to your server if you enter via SSH as root and download the latest stable version of Rkhunter tool by going to http://www.rootkit.nl/projects/rootkit_hunter.html or use below Wget command to download it on your systems.

# cd /tmp
# wget http://ncu.dl.sourceforge.net/project/rkhunter/rkhunter/1.4.0/rkhunter-1.4.0.tar.gz

Step 2: Installing Rkhunter

Once you have downloaded the latest version, run the following commands as a root user to install it.

# tar -xvf rkhunter-1.4.0.tar.gz
# cd rkhunter-1.4.0
# ./installer.sh --layout default --install

Step 3: Updating Rkhunter

Run the RKH updater to fill the database properties by running the following command.

# /usr/local/bin/rkhunter --update
# /usr/local/bin/rkhunter --propupd

Step 4: Setting Cronjob and Email Alerts

Create a file called rkhunter.sh under /etc/cron.daily/, which then scans your file system every day and sends email notifications to your email address. Create following file with the help of your favourite editor.

# vi /etc/cron.daily/rkhunter.sh

Add the following lines of code to it and replace “YourServerNameHere” with your “Server Name” and “you@yourdomain.com” with your “Email address“.

#!/bin/sh
(
/usr/local/bin/rkhunter --versioncheck
/usr/local/bin/rkhunter --update
/usr/local/bin/rkhunter --cronjob --report-warnings-only
) | /bin/mail -s 'rkhunter Daily Run (PutYourServerNameHere)' you@yourdomain.com

Set execute permission on the file.

# chmod 755 /etc/cron.daily/rkhunter.sh

Step 5: Manual Scan and Usage

To scan the entire file system, run the Rkhunter as a root user.

# rkhunter --check

The above command generates log file under /var/log/rkhunter.log with the checks results made by Rkhunter. For more help or information please run the following command.

# rkhunter --help

Differnt PHP Configurations

When it comes to php configuration, there are many options available. Users and administrators easily gets confused with this. Here is a small reference on some php configurations.
DSO – Provide this version of PHP via libphp4.so or libphp5.so (AKA mod_php). This is normally the fastest possible way to serve PHP requests, but PHP will execute as the user “nobody”. If both versions of PHP are available, it is impossible to configure both to be served as DSO unless the concurrent DSO patch was applied at build time.

SuPHP – Provide this version of PHP through mod_suphp. This is the most flexible way of serving PHP requests and tends to be very secure. PHP scripts are executed by the user who owns the VirtualHost serving the request.


FCGI – Provide this version of PHP through mod_fcgid. This is a very fast way of serving PHP requests, but php.conf will most likely require additional tuning to perform well. If Suexec is enabled, each user will create their own PHP FastCGI server automatically and PHP scripts will be executed by the user who owns the VirtualHost serving the request. If Suexec is disabled, the “nobody” user will own all of the PHP FastCGI server processes and PHP scripts will be executed by the “nobody” user. FCGI mode is recommended only for advanced administrators who understand how to tune the performance of mod_fcgid. Userdir requests will not function correctly with the basic mod_fcgid setup provided by cPanel.

CGI – Provide this version of PHP through mod_cgi or mod_cgid. If Suexec is enabled, PHP scripts will be executed by the user who owns the VirtualHost serving the request. If Suexec is disabled, the “nobody” user will execute all PHP scripts. Userdir requrests will not function correctly with the basic CGI setup provided by cPanel. It is intended as a fallback when the other preferred methods (DSO or SuPHP) are not available. Serving PHP as CGI is not particularly secure or fast regardless of whether Suexec is enabled.

Default PHP Version

This setting controls which version of PHP will be configured to handle the .php file extension. When both versions of PHP are enabled, .php4 will always be PHP4, .php5 will always be PHP5 and .php will be whichever is configured as the default. Overriding this setting in for individual VirtualHosts will be detailed below.

DSO Considerations

Apache directives like php_value and php_admin_value are features provided by libphp. This is the only setup where those are valid directives in .htaccess files or httpd.conf. When compiled with the concurrent DSO patch, php4_value, php5_value, etc should be used instead.

For PHP scripts to execute, permissions of 0644 are sufficient. The user “nobody” must have sufficient permissions to traverse to the PHP script and read it though. Any files created by PHP scripts will be created by the user “nobody”, so files and directories that will receive such output must be writable by that user.

SuPHP Considerations

EasyApache 3 compiles mod_suphp in paranoid mode with several patches to improve Apache userdir support. If you encounter problems with mod_suphp, please be aware that mod_suphp as shipped by cPanel behaves in very different ways than the pristine upstream version.

Apache directives like php_value are not valid for mod_suphp. It is possible to place a php.ini file in the directory containing the PHP script and specify these types of values in it.

NOTE: PHP does not merge the php.ini files together, so when a custom php.ini is used it must contain all of the required directives from the main php.ini file (for example, if Zend Optimizer is required, the new php.ini must load the extension.)

For PHP scripts to execute, permissions of 0400 are sufficient. Scripts are run as the user who owns the VirtualHost, and as long as this user has permissions sufficient to write to a file/directory, PHP scripts will also have the ability to do so. Mod_SuPHP performs various security checks before executing PHP scripts. Most can be disabled in Mod_SuPHP configuration file located at /opt/suphp/etc/suphp.conf
docroot – PHP scripts must reside under this directory. Default is /, change to /home/ to improve security.
allow_file_group_writable – prevents execution of PHP scripts with the group write bit set. Default is false. Changing to true will allow these scripts to execute but reduce security.
allow_file_others_writable – Same as above, others write bit.

allow_directory_group_writable – If you previously run PHP as DSO, you may have PHP scripts residing in a directory that is writable by group members. This security check prevents those scripts from executing. Default is false. Changing to true will allow these scripts to execute but reduce security.


allow_directory_others_writable – Same as above, others write bit.


check_vhost_docroot – This directive causes suphp to check that the target script resides in the document root of the VirtualHost serving a request. For a userdir request, SuPHP considers the domain part of the URL to be the VirtualHost serving the request. Setting this to true will cause userdir requests, and some types of PHP aliases to fail, though security will be significantly improved. Default it false.


userdir_overrides_usergroup – this is a configuration option allowed by cPanel specific patches. Setting this to true allows SuPHP to determine which user should execute a script from the userdir portion of the URL. Setting it to false will provide the normal mod_suphp behavior of executing scripts as the user specified by the domain portion of a URL.


paranoid_uid_check – Mod_SuPHP can be compiled with different security modes. EasyApache 3 uses the “paranoid” mode, though some scenarios are better served by the “force” mode. The paranoid UID check performed by mod_suphp verifies that the user ID that owns a script is the same one that is executing it. Setting this to false disables the UID check as in force mode.


paranoid_gid_check – Same as above, but with the group ID that owns the script. On some BSD systems it may be necessary to disable this check because files inherit the GID that owns the directory. Disabling this check should not significantly reduce security so long as the allow_file_group_writable and allow_directory_group_writable checks are left at their default values.


umask – The mod_suphp developers set this to a default of 0777 meaning that all permissions on files must be explicitly specified. This is a very secure setting, but causes many problems. The cPanel default is 0022. Use 0033, 0077, or 0777 for improved security.


min_uid – The lowest user ID that can own scripts being executed. Default value is 1. Set this value to 100 or 500 to greatly improve security. If you provide shared PHP scripts owned by root for your users, this value will need to be lowered to 0.

min_gid – The lowest group ID that can own scripts being executed. Default value is 1. Set this value to 100 or 500 to greatly improve security. If you provide shared PHP scripts owned by root for your users, this value will need to be lowered to 0.

full_php_process_display – When set to “true” mod_suphp will execute PHP scripts in a way that displays both the PHP interpreter and the SCRIPT_FILENAME in ps output. Setting this to “false” will improve security by hiding the SCRIPT_FILENAME.

The suphp.conf file includes a section called [phprc_paths] that can be used to override the standard handling of php.ini. To lock a particular PHP handler to its default php.ini file, simply uncomment the appropriate line under [phprc_paths]. There is also a configuration directive supported by mod_suphp in httpd.conf and .htaccess files called suPHP_ConfigPath that sets the path to the php.ini file. To prevent the use of this directive in .htaccess files, remove “Options” from the Apache AllowOverride setting. Note that the [phprc_paths] set in suphp.conf take precedence over any suPHP_ConfigPath settings.

FCGI Considerations

This is not a recommended configuration for PHP. It requires fine tuning of mod_fcgid to ensure that the server does not become overloaded with idle PHP processes.

Permissions of 0400 are sufficient to execute PHP scripts when running under Suexec. Permissions of 0444 are sufficient to execute PHP scripts when running with Suexec disabled.

With the standard cPanel FCGI configurations, the PHP binary is available as a URL in the VirtualHost. This should not be considered a very secure setup.

Userdir requests do not function with the FCGI setup provided by cPanel.

Apache directives like php_value are not valid for mod_fcgid. A custom php.ini file should be used instead as detailed in the SuPHP section above.

CGI Considerations

Like FCGI, this is not a recommended configuration for PHP. The PHP binary is available as a URL in the VirtualHost, and the setup is not very secure.

Permissions of 0400 are sufficient to execute PHP scripts when running under Suexec. Permissions of 0444 are sufficient to execute PHP scripts when running with Suexec disabled.

Several PHP options may prevent the CGI setup from functioning correctly, particularly DiscardPath and ForceCGIRedirect. If you are having trouble with this configuration, please verify these options are disabled.

Userdir requests do not function with the CGI setup provided by cPanel.

Apache directives like php_value are not valid for mod_cgi. A custom php.ini file should be used instead as detailed in the SuPHP section above.

Apache configuration #2 - CentOS

Continuing from the first CentOS Apache configuration article, we now look at some of the other settings in the main httpd.conf file and what they can do.

Concentrating on efficiency and security, this will end our httpd.conf journey (for now).

ServerName

Default: Not Set

The ServerName is usually a hostname or a FQDN (Fully Qualified Domain Name).

If you set followed the CentOS installing Apache and PHP5 article, you will have already set the ServerName configuration.

If you fail to set the ServerName then on an Apache restart you will see the following warning:

Starting httpd: httpd: Could not reliably determine the server's fully qualified domain name,
using 127.0.0.1 for ServerName

HostnameLookups

Default:

HostnameLookups Off

If you want happy users and to save traffic, keep this at Off.

Setting this to 'On' will enable DNS lookups so host names can be logged (it performs a reverse DNS check), setting it to 'Double' will not only perform the reverse DNS check it will then check the resulting hostname.

All a bit much and if you desperately need hostname information from your visitors it is advised to use logresolve (located in /usr/bin/logresolve) for this purpose. A small explanation can be found here.

ServerTokens

Default:

ServerTokens OS

The ServerTokens setting will dictate how much information is sent in the Headers with regard to Apache version and modules in use.

The default (Set as 'OS") would send something like this:

Apache/2.2.3 (CentOS)

Does this make a difference? Well, yes. If we can suppress that information it will make it harder for someone to find an exploit.

It does not make the actual install any more secure but all someone has to do right now is look for an exploit in CentOS Apache 2.2.3 and so on. Why make it easy for them?

The options are (with example outputs):

Full

Apache/2.2.3 (CentOS) DAV/2 PHP/5.1.6 mod_ssl/2.2.3 OpenSSL/0.9.8b

OS

Apache/2.2.3 (CentOS)

Minimal

Apache/2.2.3

Minor

Apache/2.2

Major

Apache/2

Prod

Apache

It's up to you what level of info you want to give out. I prefer setting ServerTokens to Prod.

ServerSignature

Default:

ServerSignature On

Server generated pages, such as 404 pages or directory listings, can contain a footer line which includes server information and can include the ServerAdmin email address.

If you navigate to your Slice IP address and a non-existent page:

http://123.45.67.890/blahblah

You will see a 404 Page not found page with the footer information:

 

Note the image shown has ServerTokens set to 'Prod' so little information is shown in the footer.

The options are:

Off: Produces no footer

On: Produces footer information (at a level defined by the ServerTokens setting)

Email: Adds an email link to the information (level defined by the ServerTokens setting)

Reload

After each change to the httpd.conf file, you will need to reload Apache for the settings to take effect:

sudo /etc/init.d/httpd reload

Summary

Some simple steps in this article but ones which I believe are very useful and aid in increasing the efficiency of your Slice and assist in the overall security effort on your Slice.

Apache configuration #1 - CentOS

Let's take a look at the main httpd.conf for our CentOS Apache install.

We're not actually going to change a lot at this point, just look at the main settings and see what they mean and what a change will actually do

Defaults

Why no specific changes to the default? Well, it's difficult to give a definitive configuration as there are so many variables to consider such as expected site traffic, Slice size, site type, etc.

However, we'll discuss the main settings and you can make any decisions as to what settings you feel are best for your site.

My advice is very simple: experiment. Find what works best on your setup.

apache2.conf

Open up the main CentOS Apache config file:

sudo nano /etc/httpd/conf/httpd.conf

I won't list the whole contents here but, if you are not familiar with the settings, have a read of the comments. I find them very informative and straight to the point.

Let's look at some of the main settings and what they mean (you may notice that we skip some settings but don't worry, many of them will be discussed in the 2nd Apache configuration article):

Timeout

Default:

Timeout 120

This sets (in simple terms) the maximum time, in seconds, to wait for a request, action it and the response to the request.

The default is deliberately set high to allow for varied situations. You can reduce this to something more sane, such as 45 or even lower. A decrease may also help in reducing the effects of a DOS attack.

KeepAlive

Default:

KeepAlive Off

Setting this to 'On' allows for persistent connections to a client so each file, image, etc is not requested with a new connection. This allows for more efficiency. Define the KeepAlive settings as shown below:

MaxKeepAliveRequests

Default:

MaxKeepAliveRequests 100

Now we have our persistent connection, set the maximum number of requests per connection. Keep this high more maximum efficiency. If you have a site with images, javascripts, etc, try increasing this to 200.

KeepAliveTimeout

Default:

KeepAliveTimeout 15

So how long does the persistent connection wait for the next request? The default setting is very high and can easily be reduced to 2 or 3 seconds. If no new requests are received during this time the connection is killed.

What does this mean? Well, once a connection has been established and the client has requested the files needed for the web page, this setting says "sit there and ignore everyone else until the time limit is reached or you get a new request from the client".

Why would you want a higher time? In cases where there will be a lot of interactivity on the site. However, in most cases, people will go to a page, read it for a while and then click for the next page. You don't want the connection sat there doing nothing and ignoring other users.

prefork MPM

During the Apache install we installed Apache using prefork and not Apache using worker. If you want to know more about the differences between the two I will point you towards the official Apache docs (which are actually very good).

Default:

<IfModule mpm_prefork_module>  StartServers 8 MinSpareServers 5 MaxSpareServers 20 ServerLimit 256 MaxClients 256 MaxRequestsPerChild 4000 </IfModule>

Again, it's difficult to give a suggestion here as to what is best for your site but, most the time, they can be left at the defaults.

StartServers: number of child server processes created at startup

MinSpareServers: minimum number of child server processes not doing anything (idle).

MaxSpareServers: maximum number of child server processes not doing anything (idle) - any more than the maximum will be killed.

Don't set Max lower than Min but Apache will ignore silly numbers here and set the Max at Min+1.

ServerLimit: sets the server limit

MaxClients: sets the maximum simultaneous requests that Apache will handle. Anything over this number will be queued until a process is free to action the request.

MaxClients is not the same as the maximum number of visitors you can have. It is the maximum requests.

Remember the KeepAliveTimeout? This was set low so the next request can be actioned but the original (now 'idle') client will still be sat there reading your webpage - the new (active) request will be actioned or, if the MaxClients limit has been reached, will be queued ready for the next available process.

In most cases, the client is not 'active'. Take this page. You requested it (using an active process) and then spent a while reading it which uses no processes - you are 'idle' (as far as the server is concerned!).

MaxRequestsPerChild: sets how many requests a child process will handle before terminating. The default is 4000. If you set it to 0, it will never die.

Summary

Quite a lot here but as you go through the different settings you will see that the theory is quite simple. Naturally, there is a lot more to it than this article (or set of articles) can go into.

In the second httpd.conf article we will look at other settings that will add some more efficiency and help in increasing the security of our Slice.

Script to monitor exim mail queue

==> Features
* This particular script alerts the admin if the mail queue is larger than the specified limit
* Script for EXIM Mail Servers

==> Usage
* Copy the below code to a file and give it execute permission
Code:
$ chmod 755 [file_name]

* Set the code to run every 30 minutes by configuring it as a cron job
Code:
*/30 * * * * /bin/sh [/path/to/file] > /dev/null 2>&1

* Edit the variables under the section: "Edit here" to suit your requirements

==> Script
Code:
#!/bin/bash
# Script from www.r6host.com to alert admin about larger mail queue
# Save the file as eximqueue.sh

######### Edit here ##########

_mail_user=info@r6host.com # Set this to your email id to receive alerts on mail queue
_limit=200 # Set the limit here

##############################

clear;
_result="/tmp/eximqueue.txt"
_queue="`exim-bpc`"

if [ "$_queue" -ge "$_limit" ]; then
echo "Current queue is: $_queue" > $_result
echo "Summary of Mail queue" >> $_result
echo "`exim -bp | exiqsumm`" >> $_result
mail -s "Number of mails on `hostname` : $_queue" $_mail_user < $_result
cat $_result
fi

rm -f $_result

Counting Ips in an access log

So,  If you need to look through an apache access log and count how many IP addresses there are this is how:

root@sertechs [~]# cd /usr/local/apache/logs/

root@sertechs [~]#  cat access_log | awk '{print$1}' | sort | uniq -c | sort -nr | less

So this command will write out your access file to screen, use awk to print the first column, sort it, get the unique values, then sort it with a count, and print to "less".

Very useful to see if your being scraped!

FIND Command

Some examples:

Find all files with 777 permissions:
find . -type f -perm 777 -print

Find all files that are older than 14 days and ls:
find . -type f -mtime +14 -exec ls -l {} ;

Find all your writable files and list them:
find . -perm -0777 -type f -ls

Find files and change their permission to writeable:
find . -name "NAME*" -exec chmod 666 {} ;

Find files created in the past 7 days:
find . -mtime -7 -type f

Find files modified in the past 7 days:
find . -mtime -7 -type f

Find files owned by a particular user:
find . -user esofthub

Find files that were modified more than 7 days ago and tar them into an archive (with a date in the name):
find . -type f -mtime +7 | xargs tar -cvf `date '+%d%m%Y'_archive.tar`

Find files that were modified less than 7 days ago and tar them into an archive (with a date in the name):
find . -type f -mtime -7 | xargs tar -cvf `date '+%d%m%Y'_archive.tar`

Find how many files are in a path:
find . -type f -exec basename {} ; | wc -l

Find the top 50 Biggest Files:
find / -type f -not -path "/proc/*" -not -path "/dev/*" -not -path "/sys/*" -not -path "/home/rack/*" -printf "%s %h/%fn" | sort -rn -k1 | head -n 50 | awk '{print $1/1048576 "MB" " " $2}'

Install zend optimiser on direct admin server

cd /usr/local/directadmin/custombuild

./build update

vi /usr/local/directadmin/custombuild/options.conf

Change no to yes in options.conf

./build zend

How to enable open_basedir for particular domain in plesk

SSH into your Plesk machine as “root” and cd to the conf directory for the domain.

Create a “vhost.conf” file in “/var/www/vhosts/<domain name>/conf/”

<Directory /var/www/vhosts/<domain name>/httpdocs>
php_admin_value safe_mode on
php_admin_value open_basedir none
</Directory>

Rebuild the domain configs for the particular host via::–

[    #/usr/local/psa/admin/sbin/websrvmng -u --vhost-name=<domain name>   ]

or rebuild all via :

#/usr/local/psa/admin/sbin/websrvmng -a

#service httpd reload

View SSL cert from backend

openssl x509 -in /etc/ssl/certs/DOMAIN.crt -text -noout

phpmyadmin upload limitation

To increase the phpmyadmin upload limitation in cpanel servers you can edit the php.ini file mentioned below :

vi /usr/local/cpanel/3rdparty/etc/phpmyadmin/php.ini.

upload_max_filesize = 100M

post_max_size = 100M

Even if you edit the main php.ini file it wont work in this case.

Cpanel >> phpmyadmin may not reflect the change, if so go to

WHM >> tweak settings >> cPanel PHP max POST size >> and increase the limit.

or

Increase WHM >> Tweak Settings >> cPanel PHP max upload size

How to disable CSF IP address block alert email

vi /etc/csf/csf.conf

# Send an email alert if an IP address is blocked by one of the [*] triggers

LF_EMAIL_ALERT = “1?

# Send an email alert if an IP address is blocked by one of the [*] triggersLF_EMAIL_ALERT = “1?

How to detect domain being Attacked or Attacking Out in cPanel

What we can do to find out which domain being attacked or attacking out from/to the server. Its no matter how this could happen, we need to stop that from happenning and turn our server stable. Its better to do this process in real-time within the  time frame of server being attacked or the server  others to make sure we can gather enough information, prove and logs. Its also recommended to document  your process of troubleshooting for your reference. Believe me you will need it in future.

As for me, I will do basic checking as below:

1. Check overall server load summary using top command:

# top –c

2. Using the same command, we can monitor which process has taken high resource usage by sorting memory (Shift+M) or sorting CPU usage (Shift+P)

3. Check the network and analyse which connection flooding your server. Following command might be useful:

3.1 Check and sort number of network statistics connected to the server:

# netstat –anp |grep ‘tcp|udp’ | awk ‘{print $5}’ | cut –d: –f1 | sort | uniq –c | sort –n

3.2 If you have APFinstalled and using kernel older than 2.6.20, you can check the connection tracking table:

# cat /proc/net/ip_conntrack | cut –d ’ ’ –f 10 | cut –d ‘=’ –f 2 | sort | uniq –c | sort –nr | head –n 10

3.3 Do tcpdump to analyse packet that transmitted from/to your server. Following command might help to analyse any connection to eth0interface port 53 (DNS):

# tcpdump –vvxXlnni eth0 port 53 | grep A? | awk –F? ‘{print $2}’

4. Analyse Apache status page at WHM –> Server Status –> Apache Status. To do this via com­mand line, you can run following command:

# service httpd fullstatus

5. Analyse Daily process logs at WHM –> Server Status –> Daily Process Logs. Find any top 5 users which consume most CPU percentage, memory and SQL process

After that, we should see some suspected account/process/user which occupied much resources either on CPU, memory or network connections.
Up until this part, we should shorlist any suspected account.

Then from the suspected account, we should do any step advised as below:

6. Scan the public_html directory of suspected user with anti virus. We can use clamav, but make sure the virus definition is updated before we do this:

6.1 Update clamavvirus definition:

# freshclam

6.2 Scan the public_html directory of the suspected user recursively with scan result logged to scanlog.txt:

# cd /home/user/public_html

# clamscan –i –r –l scanlog.txt &

6.3 Analyse any suspected files found by clamav and quarantine them. Make sure the file can­not be executed by chmod it to 600

7. Find any PHP files which contain suspicious characteristic like base64 encoded and store it into text file called scan_base64.txt.
Following command might help:

# cd /home/user/public_html

# grep –lir “eval(base64” *.php >  scan_base64.txt

8. Scan the Apacheaccess log from raw log for any suspicious activities. Following command might help to find any scripting
activities happened in all domains via Apache:

# find /usr/local/apache/domlogs –exec egrep –iH ‘(wget|curl|lynx|gcc|perl|sh|cd|mkdir|touch)%20? {} ;

9. Analysing AWstats and bandwidth usage also get more clues. Go to cPanel > suspected domain > Logs > Awstats.
In the AWstats page, check the Hosts, Pages-URL or any related section. Example as below:

There are various way to help you in executing this task. As for me, above said steps should be enough to detect any domain/account
which attacking out or being attacked. Different administrator might using different approach in order to produce same result.

cPanel not showing FTP user accounts

This issue was due to the missing entries in the /etc/proftpd/username file.

For fixing this just issue the following command:-

# /scripts/ftpupdate.

This will sync the passwords of all the accounts in the servers

Php module installation steps :iconv

Overview : 
Installing a single php extension without recompiling PHP is never been a difficult job but most of the people doesn’t know it which leads to re-compile whole php.. In this article i will explain how can you add new php extension without recompiling whole php.

In our example, i will tell you how can you add iconv php extension without recompiling PHP.

root@sysadmin [~]# php -m

To list all the php modules installed in the server

root@sysadmin[~]# php -m|grep iconv

To search for the php module iconv in the module list installed in the server

=============
root@sysadmin [~]# cd /home/cpeasyapache/src/php-5.2.9/ext/
root@sysadmin [/home/cpeasyapache/src/php-5.2.9/ext]# cd iconv/
root@sysadmin [/home/cpeasyapache/src/php-5.2.9/ext/iconv]# phpize
Configuring for:
PHP Api Version:         20041225
Zend Module Api No:      20060613
Zend Extension Api No:   220060519
===============

Phpize-- with an example
------
The phpize command is used to prepare the build environment for a PHP extension. In the following sample, the sources for an extension are in a directory named extname:

$ cd extname
$ phpize
$ ./configure
$ make
# make install
----------------------

You can can see iconv php extension is installed under php extensions directory:
ls /usr/local/lib/php/extensions/no-debug-non-zts-20060613/iconv.so

Enable iconv PHP extension in php.ini 
echo "extension=iconv.so" >> /usr/local/lib/php.ini

Verify iconv :
php -i | grep -i "iconv support"

Output:
iconv support => enabled