Script to send email alert when disk space usage is more than 70%

Hi,

This is a script for the linux administrators who wish to have the alerts of disk usage to be sent via email, then please run this script on your Linux box..

#!/bin/bash
usage=`df -h | awk '{print $5}' | sed -e N -e 's/\n/ /' | awk '{print $2}' | tr -d % -s "\n"`
devnm=`df -h | awk '{print $1}' | sed -e N -e 's/\n/ /' | awk '{print $2}' | tr -s "\n"`
str="============================="

if [ $usage -ge 70 ]; then
info="Disk usage for $devnm is more than 70% , Current Disk usage is $usage % "
echo -e "$str\n$info\n$str" |mail -s "Alert: Disk Usage for `hostname` on `date`" abc@yourdom.com

else
info="Disk Usage is $usage% for $devnm"
# echo -e "$str\n$info\n$str" | mail -s "Alert: Disk Usage for `hostname` on `date`" abc@yourdom.com
fi

How to check PHP version of your server ?

You can check Php Version using phpinfo file. You can create phpinfo.php from your Cpanel >> Filemanager Or You can crete it through shell also(if you have the access).

1) Create a phpinfo.php file under your public_html folder for respective host.

2) Edit phpinfo.php file using any editor like vi. add below code in the phpinfo.php file

Code:
< ?phpinfo();?>
Close and save the file
3) Permissions should be 644 for phpinfo.php. You could change the permission using the code given below.

Code:

chmod 644 phpinfo.php

4) Ownerships should be user:user. You could change the permission using the code given below.

Code:

chown username:username phpinfo.php

5) If you are using cPanel >> Go to Filemanager and create phpinfo.php file. Insert the phpinfo script as updated above, save the file then change the permission easily from the "permission" tab provided by cPanel.

6) Now check the php version of your host using link

http://domainname/phpinfo.php

Note : If server already has PHP5 installed.

5) If "http://domainname/phpinfo.php" which displays the version PHP 4 and you want to upgrade it php5

6) Then Create .htacess file under your public_html folder for respective domain.

7) Edit with your favorite editor and add following code in the .htaccess file.

Code:

AddHandler application/x-httpd-php5 .php

8) Permissions should be 644 for .htaccess. You could change the permission using the code given below.

Code:

chmod 644 .htaccess

9) Now visit "http://domainname/phpinfo.php" It should display the PHP 5 version.

linux VPS Commands

Utility vzctl runs on host server (HS) and performs direct manipulations with Container (CT).

Containers can be referred to by numeric ctid (or name which can be assigned with --name option).

Note

that CT ID <= 100 are reserved for Virtuozzo internal purposes.

Following commands turn the quota on or off for the particular Container; the vzctl quotainit command forces the quota to be initialized for the Container, i.e. its disk space and inodes recalculated. The Container ID must be specified after these commands with no additional options:

vzctl quotaon

vzctl quotaoff

vzctl quotainit

When the quota is turned on or initialized for the specified Container, the quota settings are taken from the Container configuration file. If you wish to change these settings, you should use the vzctl set command.

============================================

vzctl

vzctl is the primary tool for Container management. To use it, you have to log in to the Hardware Node as the root user. The syntax of vzctl is:

CT_ID>>>>is Container ID set

vzctl [--quiet | --verbose] command CT_ID

vzctl --version

vzctl --help

Where command can be one of the following:

convert : Used to convert legacy Containers to the new Virtuozzo Containers 4.0 directory layout.

create : Used to create Containers.

delete : Used to remove a Container.

Like vzctl delete, this command is also used to remove a Container from the Hardware Node.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mounting and Unmounting

vzctl mount CT_ID : Allows mounting the Container private area and executing the Container mount script.

vzctl umount CT_ID : Allows dismounting the Container private area and executing the unmount script.

start : Starts a Container.

stop : Stops a Container.

restart : Restarts a Container.

status : Displays the Container status.

vzctl set ctid :

This command sets various CT parameters. If flag --save is given, parameters are saved in CT configu

ration file ve.conf(5). If CT is currently running, vzctl applies these parameters to CT, in case

--setmode option specified apply logic for parameters that canât be applied or tunning CT will be

changed, if restart -restart CT, if ignore - ignore error. Parameters that can not be applied run-

time are capability, quotaugidlimit, bindmount, and iptables.

The following options can be used with set command.

Miscellaneous parameters

--setmode restart|ignore

Change default mode for apply parameters that can not be applied on running CT. restart - restart CT,

ignore - ignore error.

--onboot yes|no

Sets whether this CT will be started during system boot up. CT will not be auto-started during system

boot up unless this parameter is set to yes.

--root path

Sets path to root directory for this CT. This is essentially a mount point for CT root. Value must

contain string $VEID, which will be substituted with numeric CT ID. Changing this parameter is not

recommended, better edit vz(5) global configuration file.

--userpasswd user:password

Sets password for given user in CT, creating the user if it does not exists. Note that this option is

not saved in configuration file at all (so --save flag is useless), it is applied to CT (by modifying

its /etc/passwd and /etc/shadow files).

In case CT root is not mounted, it is automatically mounted, then all appropriate file changes are

applied, then it is unmounted.

Note that CT area should be created before using this option.

--disabled yes|no :

Disable CT start. For force start disabled CT option --force can be used.

--name name :

Bind CT with name, it allows to use name unstead of CT ID. The valid symbols for name are [0-9][aA-

Zz][ -_.] and all international sybmols.

--description desc :

Assing description for CT. It can be viewed by vzlist utility.

--ipadd addr :

Network related parameters

vzctl start : Start the container

vzctl create {--pkgset [--pkgver ] | --ostemplate }

[--config ] [--private ] [--root ]

[--ipadd ] | [--hostname ] [--skip_app_templates] : Create Container with the package , configuration, allocating ipaddress, signing hostname , etc..

vzctl convert CT_ID :

In Virtuozzo 4.0 Container is created in new (4.0) layout. All private data (config,

scripts, quota) resides under CT private. Convert action convert Container from old to

4.0 layout.

vzctl set [--save] [--ipadd ] [--ipdel |all]

Used to set Container parameters, including resource control settings, the location of the Container private area, hostname, IP addresses, and Container root user password.

vzctl unset

: Used to remove Container parameters (resource control settings, IP addresses, etc.) from the configuration file.

vzctl enter

: Provides a way for the Hardware Node administrator to "enter" a Container without knowing the Container root password. Use this command with caution and never run it on un-trusted Containers.

exec, exec2 : These two commands allow running arbitrary commands inside a Container without logging in to the corresponding Container. The difference between two is the returned status.

vzctl recover : Recovers the original state of the Container system and application files in case something has been broken. The user files are left intact.

vzctl quotaon

: Turns the disk quota on for the given Container.

quotaoff

: Turns the disk quota off for the given Container.

quotainit

: Initializes the disk quota for the given Container with the parameters taken from the Container configuration file.

How to increase ip conntrack max value

First, find out the value of ip_conntrack_max using the command.

cat /proc/sys/net/ipv4/ip_conntrack_max

By default, the value is 34576.

Sometimes you can see the error "ip_conntrack Table full. Dropping packet" in the log file (/var/log/messages).

This error can be eliminated by increasing the value of this parameter.

Method # 1:

i) Execute the following line in the command prompt

echo 65536 > /proc/sys/net/ipv4/ip_conntrack_max

ii) Execute the command sysctl -p to flush the values

Note: This value will be restored once the server rebooted.

Method # 2:

i) Add the following line in '/etc/sysctl.conf' file

net.ipv4.netfilter.ip_conntrack_max = "65536"

ii) Execute the command sysctl -p to flush the values

Note: When we modify the value using this method, the value won't be restored even though we reboot the server.

Issue:

Sometimes we reset the value of ip_conntrack_max to 65536. But, it will restore to 34576 once we restart APF in the server.

Steps to fix this issue:

1. Open APF configuration file - /etc/apf/conf.apf

2. Find the line "SYSCTL_CONNTRACK"

3. The value sholuld be "34576". Change it to "65536".

4. Now refresh the firewall using the command "apf -r"

5. Check the value "cat /proc/sys/net/ipv4/ip_conntrack_max"

Error Cause:

Iptables under Linux maintains a list of connections passing through the router. Each connection tracking entry contains defined characteristics of the packet, including the source and destination IP address and port number. The connection tracking entries are ultimately stored in a hash table with a fixed size. If the router reaches the maximum number of connection tracking entries, it will log an error:

"ip_conntrack: table full, dropping packet"

The maximum size of the connection tracking table can be increased. The maximum size value is stored in the router's proc filesystem in the file /proc/sys/net/ipv4/ip_conntrack_max. Increasing the maximum size of the connection tracking table to a value larger than the total number of connections will eliminate the error message and prevent the router from dropping connections due to a lack of space in the connection tracking table.

SYN Attack OR DDOS Attack

SYN Attack

Command to check number of connection for port 25:

#netstat -plan|grep :25|awk {'print $5'}|cut -d: -f 1|sort|uniq -c|sort -nk 1

#iptables -I INPUT -s xxx.xxx.xxx.xxx -j DROP

DDOS Attack

Quick check for a ddos via number of connections
A quick and usefull command for checking if a server is under ddos is:

#netstat -anp |grep 'tcp\|udp' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

That will list the IPs taking the most amount of connections to a server. It is important to remember that the ddos is becoming more sophistcated and they are using fewer connections with more attacking ips. If this is the case you will still get low number of connections even while you are under a DDOS.


A quick and useful command for checking if a server is under ddos:

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

That will list the IPs taking the most amounts of connections to a server. It is important to remember that ddos is becoming more sophisticated and they are using fewer connections with more attacking ips. If this is the case you will still get low number of connections even while you are under a DDOS.

Another very important thing to look at is how many active connections your server is currently processing.

#netstat -n | grep :80 |wc -l

#netstat -n | grep :80 | grep SYN |wc -l

The first command will show the number of active connections that are open to your server. Many of the attacks typically seen work by starting a connection to the server and then not sending any reply making the server wait for it to time out. The number of active connections from the first command is going to vary widely but if you are much above 500 you are probably having problems. If the second command is over 100 you are having trouble with a syn attack.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To Block a certain IP address that on server .Please use following commands
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

#route add ipaddress reject

for example route add 192.168.0.168 reject

You can check whether given IP is blocked on server by using following command

#route -n |grep IPaddress

~~~~~~~~~~~~~~~~~~~

OR

Use following command to block an ip with iptables on server

#iptables -A INPUT 1 -s IPADRESS -j DROP/REJECT

#service iptables restart

#service iptables save



Then KILL all httpd connection and restart httpd service by using following command:

#killall -KILL httpd

#service httpd startssl

Linux VPS Start Issue

Note: VE is virtual environment, refer as a VPS

Any operation on a VE gives "Cannot lock VE". How do I solve it?

>>

VE is locked when some operation (backup, migration, start / stop, etc.) with this VE is in progress. You can determine which process is holding VE #101 using the following command on the hardware node:

# cat /vz/lock/101.lck

You can kill that process if needed. Make sure that the process is really killed. If there is no process with that PID on the node, just remove the lock file or rename is using mv /vz/lock/101.lck /vz/lock/101.lck.bk

~~~~~~~~~~~~~~~~~~~~~~~

VE starts but then just shuts down in a few minutes

>>

You probably do not have a valid Virtuozzo license installed - it can be expired or number of VEs is exceeded. Please, check the output of 'vzlicview' command. The status of the license should be ACTIVE and 'used VE' should be not more than 've_total'.

Another possible reason - VE was created with so called class 1 (Light VE) and exceeds defined in license limits for a number of resources such as privvmpages, numproc, shmpages and other. You will find error messages like this in /var/log/messages file on a node:

VE 101 violates UB_PRIVVMPAGES

In this case it is recommended to change VE class to 2 (Unlimited VE) using

'vzctl set VE_ID --class 2 --save'.

~~~~~~~~~~~~~~~~~~~~~~~

VE starts but displays error "/bin/bash: no such file" or the like.

>>

The owner of the VE could have removed some important package such as bash or glibc.

In this case you may recover VE private area using 'vzctl recover VEID'.

You may also have OS template the VE is abused on missed on hardware node, you may check it using 'vzpkgls VE_ID' and install missed OS template if it is needed.

The VE can also be compromised.

~~~~~~~~~~~~~~~~~~~~~~~

The VE starts but Segmentation fault occurs very soon after starting.

>>

The VE can be compromised

VE can be compromised if its owner uses insecure or out-of-date software. To detect if VE #101 has any rootkits installed one can use the chkrootkit utility either inside the VE or (better) on the hardware node using -r /vz/root/101 parameter. There is also a way to determine which packages were modified on the VE:

- mount VE private area (it may be needed in case VE can not be started):

# vzctl mount 101

- check packages integrity:

# /usr/share/vzpkgtools/vzrpm/bin/rpm --root=/vz/root/101 --veid 101 -Va | egrep '^..5|missing'

This command shows the files that were modified or removed.

Path to the needed package manger (/usr/share/vzpkgtools/vzrpm/bin/rpm in the example above) may be different for different VEs (it depends on OS template of VE). You may check which package manager (PKGMAN) shoud be used in OS template in the file "/vz/template/$OSRELEASE/conf/$OSRELEASE.conf.$OSVERSION" for standard OS template or in the file "/vz/template/$OS/$RELEASE/$ARCH/config/os/default/package_manager" for EZ template, and use appropriate rpm in the command above.

For example, CentOS 4 uses 'PKGMAN=rpm43x86' so the path will be '/usr/share/vzpkgtools/vzrpm43/bin/rpm'

~~~~~~~~~~~~~~~~~~~~~~~

Follow the instructions from the corresponding article to repair a hacked VE.

>>

There are two ways of restoring a VE which is hacked or cannot be started for some other reasons. Please make sure that you have created a full backup of the VE before applying any of the following solutions.

Solution #1:

# vzctl recover 101

This command will reinstall OS template and all application templates, which were previously installed on the VE. This action will make it possible to start the broken VE but it does not give any guarantee that all rootkits are removed, if any.

Solution #2:

# vzctl reinstall 101

This command will create a brand new VE on the same OS template as the broken one, install the same application templates into it and restore users' credentials. The contents of the old VE will be copied into /old directory.

~~~~~~~~~~~~~~~~~~~~~~~

The VE failed to start with the message like this:

ERROR: Can't write to file /etc/sysconfig/network-scripts/ifcfg-venet0

vzquota : (warning) block_hard_limit [50100] <>

vzquota : (warning) block_hard_limit [50100] <>

>>

This error message means that VE exceeded its disk space quota and cannot be started because it is impossible to change system files during VE startup. Solution - increase diskspace (and probably inodes) alloted to VE using 'vzctl' utility:

# vzctl set VE_ID --diskspace BARRIER:LIMIT --save

#vzctl set VE_ID --diskinodes BARRIER:LIMIT --save

If increasing blocks and inodes limits does not help, try to re-init quota for this VE with:

# vzctl quotainit VE_ID

Then start VE

Exim : Message retry time not reached

What does the message retry time not reached [for any host] on the log mean? Why won't Exim try to deliver the message?

>>> That is not an error. It means exactly what it says. A previous attempt to deliver to that address failed with a temporary error, and Exim computed the earliest time at which to try again. This can apply to local as well as to remote deliveries.

For remote deliveries, each host (if there are several) has its own retry time.

If you are running on a dial-up host, the rest of this answer probably does not apply to you. If your host is permanently online.

Some MTAs have a retrying schedule for each message. Exim does not work like this.

Retry timing is normally host-based for remote deliveries and address-based for local deliveries. (There are some exceptions for certain kinds of remote failure - see Errors in outgoing SMTP in the manual.)

If a new message arrives for a failing address and the retry time has not yet arrived, Exim will log retry time not reached and leave the message on the queue, without attempting delivery.

Similarly, if a queue runner notices the message before the time to retry has arrived, it writes the same log entry. When the retry time has past, Exim attempts delivery at the next queue run. If you want to know when that will be, run the exinext utility on the address, for example:

exinext user@some.domain

You can suppress these messages on the log by including -retry_defer in the setting of log_selector.

You can force a delivery attempt on a specific message (overriding the retry time) by means of the -M option:

exim -M 10hCET-0000Bf-00

If you want to do this for the entire queue, use the -qf option.

Or Login to the server as root and try the following

/scripts/eximup --force

mv /etc/named.conf /etc/named.old

/scripts/rebuildnamedconf > /etc/named.conf

/scripts/fixndc

/etc/init.d/named restart

mail -vv nitinmartand@yahoo.co.in