How to Change default MySQL Data Directory in Linux

As a System Administrator I don’t prefer to use / directory to store MySQL data files. Each time when I install MySQL for a production server, I tried to use secondary disk for storing application and database file. In that way I always change the default data directory of MySQL to secondary disk mounted on system.
Mostly MySQL uses /var/lib/mysql directory as default data directory for Linux based systems. Which are going to change to another location in this article.

Instruction’s to Change Default MySQL Data Directory:

Follow the below steps to make all the changes. In some cases service name, default data directory or MySQL configuration file path change. So use all the command as per you system settings.

1. Stop MySQL

Before making any changes, first make sure to stop mysql service

# service mysqld stop

2. Change Data Directory

Now copy default MySQL data directory (/var/lib/mysql) to other location as per your requirement. Also set the required MySQL ownership on new directory location. As per below command, we are relocating data directory to /data/mysql.

# cp -rap /var/lib/mysql /data/mysql
# chown mysql.mysql /data/mysql

Now edit MySQL default configuration file /etc/my.cnf and update values of datadir and socket variable.

Change From:
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock

Change To: 
datadir=/data/mysql
socket=/data/mysql/mysql.sock

3. Start MySQL

After making all above changes. finally start MySQL service. Now it will use new data directory path

# service mysqld start

This article has been tested with CentOS 6.5 with MySQL 5.5.37. If you face any issue during MySQL startup check mysql log file /var/log/mysqld.log for any errors.

Continue reading How to Change default MySQL Data Directory in Linux

IP ROTATION VIA IP TABLES

First we need creating Interface aliases for your public IPs.


Let's say you have 5 ips

#ifup eth0:1
#ifup eth0:2
#ifup eth0:3
#ifup eth0:4

Now the iptables part.make sure your iptables support for statistic match module.

# iptables -m statistic -h
......
......
......
statistic match options:
--mode mode Match mode (random, nth)
random mode:
--probability p Probability
nth mode:
--every n Match every nth packet
--packet p Initial counter value (0 <= p <= n-1, default 0)
Next continue with iptables rule for rotating source IP addresses.

# iptables -t nat -I POSTROUTING -m state --state NEW -p tcp --dport 25 -o eth0 -m statistic --mode nth --every 5 -j SNAT --to-source 202.XXX.XX.2
# iptables -t nat -I POSTROUTING -m state --state NEW -p tcp --dport 25 -o eth0 -m statistic --mode nth --every 5 -j SNAT --to-source 202.XXX.XX.3
# iptables -t nat -I POSTROUTING -m state --state NEW -p tcp --dport 25 -o eth0 -m statistic --mode nth --every 5 -j SNAT --to-source 202.XXX.XX.4
# iptables -t nat -I POSTROUTING -m state --state NEW -p tcp --dport 25 -o eth0 -m statistic --mode nth --every 5 -j SNAT --to-source 202.XXX.XX.5
# iptables -t nat -I POSTROUTING -m state --state NEW -p tcp --dport 25 -o eth0 -m statistic --mode nth --every 5 -j SNAT --to-source 202.XXX.XX.6

done

Continue reading IP ROTATION VIA IP TABLES

Solved: Error compiling httpd-2.2.23: byterange_filter.c:(.text+0x12c1): undefined reference to `apr_array_clear’

modules/http/.libs/libmod_http.a(byterange_filter.o): In function `ap_set_byterange':
byterange_filter.c:(.text+0x12c1): undefined reference to `apr_array_clear’
collect2: ld returned 1 exit status
Solution: Add this to the configure command:
--with-included-apr
with compliments and kind regards to Stefan for providing this solution

Continue reading Solved: Error compiling httpd-2.2.23: byterange_filter.c:(.text+0x12c1): undefined reference to `apr_array_clear’

How to check if your Linux server is under DDOS Attack?

Login to your server as root and fire the following command, using  which you can check if your server is under DDOS attack or not:
netstat -anp |grep ‘tcp\|udp’ | awk ‘{print $5}’ | cut -d: -f1 | sort | uniq -c | sort –n
This command will show you the list of IP’s which have logged in is maximum number of connections to your server.
ddos becomes more complex as attackers  use fewer connections with more number of attacking IP’s.In such cases, you should get less number of connections even when your server is under ddos.One important thing that you should check is the number of active connections that your server currently has.For that execute the following command:
netstat -n | grep :80 |wc –l
The above command will show the active connections that are open to your server.
You can also fire the following command :
netstat -n | grep :80 | grep SYN |wc –l
Result of active connections from the first command will vary but if it shows connections more than 500, then you will be definitely having problems. If the result after you fire second command is 100 or above then you are having problems with sync attack.
Once you get an idea of the ip attacking your server, you can easily block it.
Fire the following command to block that ip or any other specific ip:
route add ipaddress reject
Once you block a paricular IP on the server, you can even crosscheck if the IP is blocked or not
by using the following command:
route -n |grep IPaddress
You can also block a IP with iptables on the server by using the following command.
iptables -A INPUT 1 -s IPADRESS -j DROP/REJECT
service iptables restart
service iptables save
After firing the above command, KILL all httpd connection and than restart httpd service by
using following command:
killall -KILL httpd
service httpd startssl

Continue reading How to check if your Linux server is under DDOS Attack?

How To Implement SPF In Postfix

This tutorial shows how to implement SPF (Sender Policy Framework) in a Postfix 2.x installation. The Sender Policy Framework is an open standard specifying a technical method to prevent sender address forgery (see http://www.openspf.org/Introduction). There are lots of SPF extensions and patches available for Postfix, but most require that you recompile Postfix. Therefore we will install the postfix-policyd-spf-perl package from openspf.org which is a Perl package and can be implemented in existing Postfix installations (no Postfix compilation required).

1 Preliminary Note

I assume that you have already set up a working Postfix mail server.
The following procedure is distribution-independent, i.e., it should work on any Linux distribution (however, I tested this on Debian Etch).

2 Install Required Perl Modules

The postfix-policyd-spf-perl package depends on the Mail::SPF and the NetAddr::IP Perl modules. Therefore we are going to install them now using the Perl shell. Start the Perl shell like this:

perl -MCPAN -e shell

If you run the Perl shell for the first time, you will be asked a few questions. You can accept all default values. You will also be asked about the CPAN repositories to use. Select repositories that are close to you.
After the initial Perl shell configuration, we can start to install the needed modules. To install Mail::SPF, simply run

install Mail::SPF

In my case, it tried to install Module::Build (which is a dependency), but then it failed. If this happens to you, simply quit the Perl shell by typing

q

Then start the Perl shell again:

perl -MCPAN -e shell

and try to install Mail::SPF again:

install Mail::SPF

This time it should succeed, and you should see that it also installs the modules Net::DNS::Resolver::Programmable and NetAddr::IP on which Mail::SPF depends.
A successful installation of Mail:SPF should end like this:

Installing /usr/local/bin/spfquery
Writing /usr/local/lib/perl/5.8.8/auto/Mail/SPF/.packlist
  /usr/bin/make install  -- OK

Because NetAddr::IP has already been installed, we can now leave the Perl shell:

q

3 Install postfix-policyd-spf-perl

Next we download postfix-policyd-spf-perl from http://www.openspf.org/Software to the /usr/src/ directory and install it to the /usr/lib/postfix/ directory like this:

cd /usr/src
wget http://www.openspf.org/blobs/postfix-policyd-spf-perl-2.001.tar.gz
tar xvfz postfix-policyd-spf-perl-2.001.tar.gz
cd postfix-policyd-spf-perl-2.001
cp postfix-policyd-spf-perl /usr/lib/postfix/policyd-spf-perl

Then we edit /etc/postfix/master.cf and add the following stanza at the end:

vi /etc/postfix/master.cf

[...] policy unix - n n - - spawn user=nobody argv=/usr/bin/perl /usr/lib/postfix/policyd-spf-perl

(The leading spaces before user=nobody are important so that Postfix knows that this line belongs to the previous one!)
Then open /etc/postfix/main.cf and search for the smtpd_recipient_restrictions directive. You should have reject_unauth_destination in that directive, and right after reject_unauth_destination you add check_policy_service unix:private/policy like this:

vi /etc/postfix/main.cf

[...] smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination,check_policy_service unix:private/policy [...]

or like this:

[...] smtpd_recipient_restrictions = [...] reject_unauth_destination check_policy_service unix:private/policy [...] [...]

It is important that you specify check_policy_service AFTER reject_unauth_destination or else your system can become an open relay!
Then restart Postfix:

/etc/init.d/postfix restart

That's it already. You should check the README file that comes with the postfix-policyd-spf-perl package, it contains some important details about how postfix-policyd-spf-perl processes emails, e.g. like this part from the postfix-policyd-spf-perl-2.0001 README:
This version of the policy server always checks HELO before Mail From (older
versions just checked HELO if Mail From was null). It will reject mail that
fails either Mail From or HELO SPF checks. It will defer mail if there is a
temporary SPF error and the message would othersise be permitted
(DEFER_IF_PERMIT). If the HELO check produces a REJECT/DEFER result, Mail From
will not be checked.
If the message is not rejected or deferred, the policy server will PREPEND the
appropriate SPF Received header. In the case of multi-recipient mail, multiple
headers will get appended. If Mail From is anything other than completely empty
(i.e. ) then the Mail From result will be used for SPF Received (e.g. Mail
From None even if HELO is Pass).
The policy server skips SPF checks for connections from the localhost (127.) and
instead prepends and logs 'SPF skipped - localhost is always allowed.'

4 Test policyd-spf-perl

We can test policyd-spf-perl by running

perl /usr/lib/postfix/policyd-spf-perl

The cursor will then wait on the policyd-spf-perl shell. We can now act as if we tried to send an email from a certain domain and a certain server to another email address. policyd-spf-perl will then check if that certain server is allowed to send emails for the sender domain and show us the result.
So let's see what happens if we try to send a mail from info@h****forge.com from the server h****.server*********.net (IP address 81.169.1**.**). The h****forge.com has an SPF record that allows 81.169.1**.** to send emails from h****forge.com.

 

So on the policyd-spf-perl shell we type:

request=smtpd_access_policy
protocol_state=RCPT
protocol_name=SMTP
helo_name=h****forge.com
queue_id=8045F2AB23
sender=info@h****forge.com
recipient=falko.timme@*******.de
client_address=81.169.1**.**
client_name=h****.server*********.net
[empty line]

The output should look like this:

action=PREPEND Received-SPF: pass (h****forge.com: 81.169.1**.** is authorized to use 'info@h****forge.com' in 'mfrom' identity (mechanism 'ip4:81.169.1**.**' matched)) receiver=server1.example.com; identity=mfrom; envelope-from="info@h****forge.com"; helo=h****forge.com; client-ip=81.169.1**.**

which means we passed the test.
Let's run another test, this time we will send from the client 1.2.3.4 (www.example.com) which is not allowed to send emails from h****forge.com:

request=smtpd_access_policy
protocol_state=RCPT
protocol_name=SMTP
helo_name=h****forge.com
queue_id=8045F2AB23
sender=info@h****forge.com
recipient=falko.timme@*******.de
client_address=1.2.3.4
client_name=www.example.com
[empty line]

This is the output, the test failed as expected:

action=PREPEND Received-SPF: softfail (h****forge.com: Sender is not authorized by default to use 'info@h****forge.com' in 'mfrom' identity, however domain is not currently prepared for false failures (mechanism '~all' matched)) receiver=server1.example.com; identity=mfrom; envelope-from="info@h****forge.com"; helo=h****forge.com; client-ip=1.2.3.4

We can now even try to leave the sender field empty, as many spammers do. Still, policyd-spf-perl should be able to complete its tests:

request=smtpd_access_policy
protocol_state=RCPT
protocol_name=SMTP
helo_name=h****forge.com
queue_id=8045F2AB23
sender=
recipient=falko.timme@*******.de
client_address=81.169.1**.**
client_name=h****.server*********.net
[empty line]

This is the output, we are still allowed to send from h****forge.com:

action=PREPEND Received-SPF: pass (h****forge.com: 81.169.1**.** is authorized to use 'h****forge.com' in 'helo' identity (mechanism 'ip4:81.169.1**.**' matched)) receiver=server1.example.com; identity=helo; helo=h****forge.com; client-ip=81.169.1**.**

Let's try the same test with an invalid client:

request=smtpd_access_policy
protocol_state=RCPT
protocol_name=SMTP
helo_name=h****forge.com
queue_id=8045F2AB23
sender=
recipient=falko.timme@*******.de
client_address=1.2.3.4
client_name=www.example.com
[empty line]

As expected, this is the output:

action=PREPEND Received-SPF: softfail (h****forge.com: Sender is not authorized by default to use 'h****forge.com' in 'helo' identity, however domain is not currently prepared for false failures (mechanism '~all' matched)) receiver=server1.example.com; identity=helo; helo=h****forge.com; client-ip=1.2.3.4 

To leave the policyd-spf-perl shell, type

[CTRL+C]

Continue reading How To Implement SPF In Postfix

Configuring Reverse DNS in BIND 9

Reverse DNS is the process of using DNS to translate IP addresses to hostnames. Reverse DNS is the opposite of Forward DNS, which is used to translate hostnames to IP addresses.

One way to see reverse DNS at work is to use nslookup a tool on most OS’s.
Let’s use `nslookup` to do a forward and reverse DNS lookup on redhat.com:
##FORWARD LOOKUP

[phil@ns1 ~]$ nslookup redhat.com Server: 206.71.175.XX Address: 206.71.175.XX#53   Non-authoritative answer: Name: redhat.com Address: 209.132.177.50

##REVERSE LOOKUP

[phil@ns1 ~]$ nslookup 209.132.177.50 Server: 206.71.175.XX Address: 206.71.175.XX#53   Non-authoritative answer: 50.177.132.209.in-addr.arpa name = www.redhat.com.   Authoritative answers can be found from: 177.132.209.in-addr.arpa nameserver = ns3.redhat.com. 177.132.209.in-addr.arpa nameserver = ns2.redhat.com. 177.132.209.in-addr.arpa nameserver = ns1.redhat.com.

Reverse DNS is setup by configuring PTR records (Pointer Records) on your DNS server.
This is in different to Forward DNS, which are configured with A records (Address Records).
Typically you or a DNS provider is in charge of Forward DNS. In the case of Reverse DNS most likely your ISP supplying your IP information will have responsibility. You would simply send them what Hostname resolves to what IP, and they would setup the PTR records. You can setup Reverse DNS on your own name servers if you choose which we will cover in this article.
Your ISP or hosting provider may delegate your own range of IP addresses, or you may have NAT setup for Private IP space you control, in this case you must configure Reverse DNS thru PTR records on your DNS server.
A lot of Systems Administrators configure Forward DNS but not Reverse DNS. In most cases when you do this things will work fine, however some applications require doing Reverse DNS lookups in which case you could run into latency issues and a whole slew of other issues.
Common applications and protocols such as IRC, SMTP, Backup utilities, and Databases sometimes use Reverse DNS.
It is best practice to configure Reverse DNS from the get go, to avoid troubleshooting headaches.
Below is a quick example how-to.
Say you NAT Private IP’s in your network 192.168.0.1-192.168.0.255
STEP 1 create a zone file and place it where you store your zone files named

0.168.192.in-addr.arpa

(Notate your address space backwards missing last octect with .in-addr.arpa appended)
Your zone file will look like this: (between ##)

#######   @ IN SOA ns1.yournameserver.com. root.domain.com. ( 2007040301 ;serial 14400 ;refresh 3600 ;retry 604800 ;expire 10800 ;minimum )   0.168.192.in-addr.arpa. IN NS ns1.yournameserver.com. 0.168.192.in-addr.arpa. IN NS ns2.yournameserver.com.   2 IN PTR blah1.domain.com. 3 IN PTR blah2.domain.com. 4 IN PTR blah3.domain.com. 5 IN PTR blah4.domain.com. 6 IN PTR blah5.domain.com.   ########

The example zone file above stipulates the below:

192.168.0.2 blah1.domain.com 192.168.0.3 blah2.domain.com 192.168.0.4 blah3.domain.com 192.168.0.5 blah4.domain.com 192.168.0.6 blah5.domain.com

The number 2-6 are the last octect of 192.168.0. and PTR is the pointer.
STEP 2 Enter the zone into your named.conf or named.boot as you would a regular zone.
This would go into your Master DNS server or Primary DNS server

zone "0.168.192.in-addr.arpa" IN { type master; file "0.168.192.in-addr.arpa"; allow-update { none; }; };

This would go into your Slave DNS server or Secondary DNS server

zone "0.168.192.in-addr.arpa" IN { type slave; file "0.168.192.in-addr.arpa"; masters { whateveryourmasteripis; }; };

STEP 3
Wholla if configured right you should be up and running. Make sure to tail your log file when you restart DNS for any errors in syntax

Continue reading Configuring Reverse DNS in BIND 9