Thứ Ba, 27 tháng 10, 2015

Speed up OpenVPN and get faster speed over its channel

Speed up OpenVPN and get faster speed over its channel

OpenVPN is a well-known VPN client for secure remote access or virtual private networking. If you use OpenVPN and experience a slow speed over its channel, you might be getting annoyed. This issue is very common for all OpenVPN users. While the general advice you can find on the Internet is to tweak the MTU (Maximum transmission unit) value and/or MSSFIX parameters, here is another trick you should try. It can help you significantly improve the bandwith. Here's what you should try.

Open your server.conf file (see the OpenVPN installation directory in Windows and /etc/openvpn in linux) and just add these two lines:
sndbuf 0
rcvbuf 0
This will prevent OpenVPN from tweaking the buffer size between the server and the client. It will be determined by the OS. Windows users who connect to a Linux server will experience faster speeds.
Now, add the same lines to your client configuration file (*.ovpn or *.conf). If for some reason this is not possible, e.g. your client computer is not accessible, put the following additional lines in your server.conf file:
sndbuf 0
rcvbuf 0
push "sndbuf 393216"
push "rcvbuf 393216"

OpenVPN over UDP

If you are running OpenVPN over UDP, you might get a better experience by setting fixed buffer values. Try these lines:
sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"

The causes of the slowdown

You might be wondering why and how these tweaks work? Let's refer to the history of OpenVPN. In the year 2004, OpenVPN had a problem with different buffer sizes on different platforms. To unify the data transfer channel, developers set the fixed buffers to 64Kb. However, this caused completely strange issues with the MTU for all adapters in Windows. To fix it, developers hardcoded these lines, which work for non-Windows based servers and clients:
#ifndef WIN32
    o->rcvbuf = 65536;
    o->sndbuf = 65536;
#endif
These lines are still presented in the OpenVPN source code, so that is why we are getting the slowdown! Additionally, you can try experimenting with MTU and MSSFIX parameters, if you know what you are doing.
Try with these lines in your config:
tun-mtu 1400 
mssfix 1360
In the most common case, MTU on the physical interface is 1500, so it is better to set OpenVPN TUN MTU to a value lower than the real MTU, and MSSFIX to MTU-40, as in the example above.
I hope this article was helpful for you. Share your speed results if you saw a significant improvement

Thứ Sáu, 23 tháng 10, 2015

Installing Python 2.7.10 - Django on CentOS 6.5



Installing Python 2.7.10 - Django on CentOS 6

CentOS 6 still come with Python 2.6 and I need 2.7, below a simple tutorial how to achieve this with no pain and not messing with installed Python.

Update CentOS and install development tools

yum -y update
yum groupinstall -y 'development tools'
Also you need the packages below to enable SSL, bz2, zlib for Python and some utils:
1
yum install -y zlib-devel bzip2-devel openssl-devel xz-libs wget

Installing Python 2.7.8 from source
Download Python and extract it

# tar -xvf Python-2.7.8.tar


Installation process

Since we already installed all the dependencies we are ready to go:

# Enter the directory:
cd Python-2.7.10

# Run the configure:
./configure --prefix=/usr/local

# compile and install it:
make
make altinstall

# Checking Python version:
[root@nicetry ~]# python2.7 -V
Python 2.7.10
If you need set PATH variable check the line below:

export PATH="/usr/local/bin:$PATH"

Installing pip and virtualenv
Now we have Python installed, but something is missing isn’t? Yes! We need pip and virtualenv.

Install setuptools








wget --no-check-certificate https://pypi.python.org/packages/source/s/setuptools/setuptools-1.4.2.tar.gz

# Extract the files:
tar -xvf setuptools-1.4.2.tar.gz
cd setuptools-1.4.2

# Install setuptools using the Python 2.7.8:
python2.7 setup.py install

Installing pip



curl https://raw.githubusercontent.com/pypa/pip/master/contrib/get-pip.py | python2.7 -

And finally virtualenv


pip2.7 install virtualenv
And that’s all, we have Python 2.7.8 installed on CentOS.

And for Django


pip2.7 install django

Thứ Hai, 12 tháng 10, 2015

10 Minutes Install the BIND DNS Server on CentOS 6

10 Minutes Install the BIND DNS Server on CentOS 6
Huy Ha

This article will show you how to setup and configure the BIND DNS Server on 2 server Primary(master) and Secondary(slave).

As with any new server, it's always important to ensure your system is up to date. You can verify this by checking for updates using yum as follows:

yum update -y

Initial BIND Installation

To begin, we will need to install the BIND and BIND Utilities packages using yum.

yum install bind bind-utils -y

Next, we'll open the BIND (named) configuration file and make several modifications.

vi /etc/named.conf

Your "options" section should appear as follows, replacing 2.2.2.2 with the IP of your second droplet.

options {
        #listen-on port 53 { 127.0.0.1; };
        listen-on-v6 port 53 { ::1; };
        directory    "/var/named";
        dump-file    "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        allow-query { any; };
        allow-transfer     { localhost; 2.2.2.2; };
        recursion no;

        dnssec-enable yes;
        dnssec-validation yes;
        dnssec-lookaside auto;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";

        managed-keys-directory "/var/named/dynamic";
};

Above, listen-on must be commented to listen on all available interfaces. Recursion should be turned off to prevent your server from being abused in "reflection" DDoS attacks. The allow-transfer directive whitelists transfers to your secondary droplet's IP. Furthermore, we have changed the allow-query directive to "any" in order to allow users proper access to hosted zones.

Next, we'll want to add a new zone for our first domain, you should add the following to your named.conf below the existing zones.

        zone "mydomain.com" IN {
                type master;
                file "mydomain.com.zone";
                allow-update { none; };
        };

After saving named.conf with the changes above, we're ready to create our first zone file.
Configure BIND Zones

Firstly, we'll need to open the zone file, using the name you specified in the configuration above. (Ex: mydomain.com.zone)

vi /var/named/mydomain.com.zone

We'll add the following contents to our newly created file. You should replace the applicable information with your own, where 1.1.1.1 is the IP of your first droplet, 2.2.2.2 is the IP of your second droplet and 3.3.3.3 is the IP you wish to point the domain itself to, such as a droplet running a webserver. You are free to add additional entries in the same format.

$TTL 86400
@   IN  SOA     ns1.mydomain.com. root.mydomain.com. (
        2013042201  ;Serial
        3600        ;Refresh
        1800        ;Retry
        604800      ;Expire
        86400       ;Minimum TTL
)
; Specify our two nameservers
        IN    NS        ns1.mydomain.com.
        IN    NS        ns2.mydomain.com.
; Resolve nameserver hostnames to IP, replace with your two droplet IP addresses.
ns1        IN    A        1.1.1.1
ns2        IN    A        2.2.2.2

; Define hostname -> IP pairs which you wish to resolve
@        IN    A        3.3.3.3
www        IN    A        3.3.3.3

We can now start named for the first time. This may take several minutes while named generates the rndc.key file, which only occurs on first execution.

service named restart

Once named has started successfully, we'll want to ensure that it is enabled as a startup service, by running the following:

chkconfig named on

By now, we should have a fully operational primary nameserver. You can verify that BIND is working correctly by running the following command, replacing 1.1.1.1 with the IP of your first droplet.

dig @1.1.1.1 mydomain.com

If you recieve a response which includes an answer and authority section, your nameserver has been configured correctly.
Slave Nameserver Configuration

With our primary nameserver configured, we'll now setup a slave nameserver.

As always, please assure your system is up to date by checking for updates with yum as follows:

yum update -y

We can start by installing BIND (and related utilities) on the second droplet, in the same manner as the first:

yum install bind bind-utils -y

We'll proceed by opening named.conf and making the same changes we made previously, ommitting the "allow transfer" line. This directive is unnecessary as we will only be transfering records from our primary name server.

nano -w /etc/named.conf

options {
        #listen-on port 53 { 127.0.0.1; };
        listen-on-v6 port 53 { ::1; };
        directory    "/var/named";
        dump-file    "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        allow-query { any; };
        recursion no;

        dnssec-enable yes;
        dnssec-validation yes;
        dnssec-lookaside auto;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";

        managed-keys-directory "/var/named/dynamic";
};

We will add the zone we configured on the first droplet, this time changing the "type" directive to slave, instead of master. You should replace "1.1.1.1" with your first droplet's IP address.

zone "mydomain.com" IN {
    type slave;
    masters { 1.1.1.1; };
    file "mydomain.com.zone";
};

After configuring our slave zone, we'll start named. Again this may take several minutes while our rndc.key file is initially generated.

service named start

As with the first cloud server, we want to assure named is set to run at startup with the following:

chkconfig named on

Your slave nameserver should now be up and running. You can verify that it is fully operational by using dig again, replacing 2.2.2.2 with the IP of your second droplet.

dig @2.2.2.2 mydomain.com

After any changes you make to the master zone files, you will need to instruct BIND to reload. Remember, you must also increment the "serial" directive to ensure synchronicity between the master and slave.

To reload the zone files, we need to run the following command on the master nameserver, followed by the slave:

rndc reload

BIND in a chroot environment

It is generally advised to install the additional package "bind-chroot" which will drop the privileges of BIND into a chroot environment.

Luckily, the CentOS package makes this extremely simple. The only aspect worth noting is that active paths for BIND will change to their chrooted equivalents, for example /var/named becomes /var/named/chroot/var/named With CentOS 6, you will not need to move any files as the package automatically creates hard symlinks to the non-chrooted directories.

If you'd like to enable this feature for the added security which it provides, you can do the following:

yum install bind-chroot -y
service named restart

Thứ Ba, 10 tháng 2, 2015

Linux / UNIX: Bash Script Sleep or Delay a Specified Amount of Time

Linux / UNIX: Bash Script Sleep or Delay a Specified Amount of Time

How do I pause for 5 seconds or 2 minutes in my bash shell script on a Linux or Unix-like systems?

You need to use the sleep command to add delay for a specified amount of time. The syntax is as follows for gnu/bash sleep command:

sleep NUMBER[SUFFIX]


Where SUFFIX may be:

s for seconds (the default)

m for minutes.

h for hours.

d for days.

Thứ Hai, 2 tháng 2, 2015

Linux Tuning hosting 10G

This page contains a quick reference guide for Linux 2.6+ tuning for Data Transfer hosts connected at speeds of 1Gbps or higher. Note that most of the tuning settings described here will actually decrease performance of hosts connected at rates of OC3 (155 Mbps) or less, such as home users on Cable/DSL connections. 
For a detailed explanation of some of the advice on this page, see the Linux Tuning Expert page. Note that the settings on this page are not attempting to achieve full 10G with a single flow. These settings assume you are using tools that support parallel streams, or have multiple data transfers occurrin in parallel, and want to have fair sharing between the flows.  As such the maximum values are 2 to 4 times less than what would be required to support a single stream.  As an example, a 10Gbps flow across a 100ms network requires 120MB of buffering.  Most data movement applications, such as GridFTP, would employ 2-8 streams to do this efficiently and to guard against congestive packet loss.  Setting your 10Gbps capable host to consume a maximum of 32M - 64M per socket ensures that parallel streams work well, and do not consume a majority of system resources. 
If you are trying to optimize for a single flow, see the tuning advice for test / measurement hosts page.
 General Approach
To check what setting your system is using, use 'sysctl name' (e.g.: 'sysctl net.ipv4.tcp_rmem'). To change a setting use 'sysctl -w'. To make the setting permanent add the setting to the file 'sysctl.conf'.
TCP tuning
Like most modern OSes, Linux now does a good job of auto-tuning the TCP buffers, but the default maximum Linux TCP buffer sizes are still too small. Here are some example sysctl.conf commands for different types of hosts.
For a host with a 10G NIC, optimized for network paths up to 100ms RTT, and for friendlyness to single and parallel stream tools, add this to /etc/sysctl.conf
# allow testing with buffers up to 64MB
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
# increase Linux autotuning TCP buffer limit to 32MB
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432
# increase the length of the processor input queue
net.core.netdev_max_backlog = 30000
# recommended default congestion control is htcp
net.ipv4.tcp_congestion_control=htcp
# recommended for hosts with jumbo frames enabled
sysctl -w net.ipv4.tcp_congestion_control=htcp
net.ipv4.tcp_mtu_probing=1
Also add this to /etc/rc.local (where N is the number for your 10G NIC): 
/sbin/ifconfig ethN txqueuelen 10000

For a host with a 10G NIC optimized for network paths up to 200ms RTT, and for friendlyness to single and parallel stream tools, or a 40G NIC up on paths up to 50ms RTT:
# allow testing with buffers up to 128MB
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
# increase Linux autotuning TCP buffer limit to 64MB
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
# increase the length of the processor input queue
net.core.netdev_max_backlog = 250000
# recommended default congestion control is htcp
net.ipv4.tcp_congestion_control=htcp
# recommended for hosts with jumbo frames enabled
net.ipv4.tcp_mtu_probing=1
Notes: you should leave net.tcp_mem alone, as the defaults are fine. A number of performance experts say to also increasenet.core.optmem_max to match net.core.rmem_max and net.core.wmem_max, but we have not found that makes any difference. Some experts also say to set net.ipv4.tcp_timestamps and net.ipv4.tcp_sack to 0, as doing that reduces CPU load. We strongly disagree with that recommendation for WAN performance, as we have observed that the default value of 1 helps in more cases than it hurts, and can help a lot.
Linux supports pluggable congestion control algorithms. To get a list of congestion control algorithms that are available in your kernel (kernal  2.6.20+), run:
sysctl net.ipv4.tcp_available_congestion_control
If cubic and/or htcp are not listed try the following, as most distributions include them as loadable kernel modules:
/sbin/modprobe tcp_htcp
/sbin/modprobe tcp_cubic
NOTE: There seem to be bugs in both bic and cubic for a number of versions of the Linux kernel up to version 2.6.33. We recommend using htcp with older kernels to be safe. To set the congestion control do:
If you are using Jumbo Frames, we recommend setting tcp_mtu_probing = 1 to help avoid the problem of MTU black holes. Setting it to 2 sometimes causes performance problems


Chủ Nhật, 1 tháng 2, 2015

How To Install EPEL, REMI and RPMForge Repositories On CentOS 7

To keep your system updated with the latest and greatest packages on CentOS 7, you must constantly update it. The yum update commands will fetch and download the latest updates for your system. By default, it only fetches pre-installed repositories which can be limited with fewer packages.
If you want to install and use the latest packages for your applications on CentOS 7, you’ll have to install additional third-party software repositories. Most of the latest servers and software packages are not available from the default CentOS repositories. The folks behind CentOS are pretty cautious when adding newer updates to their systems. They want to fully test out these updates before releasing them to all systems running CentOS.
Because it takes longer time to updates packages in CentOS, third-party repositories were created to fill in the gap to release updates quickly and frequently. Packages that were installed from these third-party repositories get updated and refreshed very frequently as soon as updates become available. Theses are usually tested and customized for the appropriate version of CentOS.
For example, to get the latest version of Nginx, Apache2, PHP-FPM and other important opensource packages, you must install third-party repositories. This brief tutorial is going to show you how to add these popular repositories to CentOS 7 if you haven’t already done so.

Installing EPEL Repository for CentOS 7
EPEL (Extra Packages for Enterprise Linux) is an opensource and free community based repository project from Fedora team which provides 100% high quality software packages for Linux distribution including RHEL (Red Hat Enterprise Linux) and CentOS.
Most people who run CentOS 7 usually add these repository to their systems. To enable it in CentOS 7, run the commands below to install it.
sudo yum install epel-release
In the past, one had to add its repository and install the repository. Now all you need to do is run the yum install commands to install and enable EPEL in CentOS7.

Installing Remi Repository on CentOS 7
The Remi repository provides newer version of popular opensource software for CentOS and Red Hat Enterprise Linux. It depends on the EPEL repository so you must first install EPEL before installing Remi.
To enable Remi repository on CentOS 7, run the commands below.
cd /tmp && wget http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
Next, run the commands below to install it.
sudo rpm -Uvh remi-release-7*.rpm

Installing RPMForge Repository on CentOS 7
Another useful repository for CentOS system is the RPMForge repository. It’s a community maintained repository which contains newer packages and software for CentOS and Red Hat Linux. More than 5000 individual packages are included in the repository. It’s a great repository to add to your system if you’re running CentOS or Red Hat servers.
To add it, run the commands below.
cd /tmp && wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el7.rf.x86_64.rpm
Next, run the commands below to install it
sudo rpm -Uvh rpmforge-release-0.5.3-1.el7.rf.x86_64.rpm
By default CentOS puts all repositories file at /etc/yum.repos.d/ directory. Each of the repository file will have an extension ending in .repo. You can edit individual repository file to enable or disable it.
A simple repository file may contain something like what’s below:
[rpmforge-extras]
name = RHEL $releasever – RPMforge.net – extras
baseurl = http://apt.sw.be/redhat/el7/en/$basearch/extras
mirrorlist = http://mirrorlist.repoforge.org/el7/mirrors-rpmforge-extras
#mirrorlist = file:///etc/yum.repos.d/mirrors-rpmforge-extras
enabled = 0
protect = 0
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmforge-dag
gpgcheck = 1
You can enable or disable a repository by changing the value for enabled to 1 to enable and 0 to disable. When you’re done, save the file  and exit.
Run the yum update commands to see if there are newer updates for your systems.. There may more third-party repositories, but these are the most popular.


Thứ Năm, 22 tháng 1, 2015

DNS records for Active Directory DCs

When you install a domain controller, the Active Directory Wizard that performs the configuration and setup of the Active Directory structure will also register RR (resource record) and SRV (service record) records for the DC with DNS. Use this list of standard DNS records to compare and contrast your DNS configuration. If you see blatant differences, you may need to manually fine tune your DNS records.
If the server name is dcsA, the domain name is corp.mycompany.com, and the DC uses an IP address of 10.19.174.98, then the RR records created during the installation process will be:
dcsA.corp.mycompany.com. A 10.19.174.98
_ldap._tcp.corp.mycompany.com. SRV 0 0 389 dcsA.corp.mycompany.com
_kerberos._tcp.corp.mycompany.com. SRV 0 0 88 dcsA.corp.mycompany.com
_ldap._tcp.dc._msdcs.corp.mycompany.com. SRV 0 0 389 dcsA.corp.mycompany.com
_kerberos._tcp.dc. msdcs.corp.mycompany.com. SRV 0 0 88 dcsA.corp.mycompany.com
If you don't see these records in DNS for each DC, then you need to manually correct or add them.
The NetLogon Service will register various SRV DNS records for the DC depending on what services or capabilities the system hosts:
(Note: SITE is the name of a site. The name of the forest is mycompany.com. GUID is a placeholder for the actual globally unique identifier for the domain.)
_ldap._tcp.corp.mycompany.com
(used for finding an LDAP server) - registered by all DCs and servers
_ldap._tcp.SITE._sites.corp.mycompany.com
(used for finding an LDAP server in a particular site) - registered by all DCs
_ldap._tcp.dc._msdcs.corp.mycompany.com
(used for finding a DC in a particular domain) - registered by all DCs
_ldap._tcp.SITE._sites.dc._msdcs.corp.mycompany.com
(used for finding a DC in a particular domain and site) - registered by all DCs
_ldap._tcp.pdc._msdcs.corp.mycompany.com
(used for finding the PDC or PDC emulator) - registered by PDCs and PDC emulators
_ldap._tcp.gc._msdcs.mycompany.com
(used for finding a Global Catalog server in the forest) - registered by Global Catalog servers
_ldap._tcp.SITE._sites.gc._msdcs.mycompany.com
(used for finding a Global Catalog server for a particular site) - registered by all Global Catalog servers
_gc._tcp.mycompany.com
(used for finding a Global Catalog server) - registered by an LDAP server serving a GC server
_gc._tcp.SITE._sites.mycompany.com
(used for finding a Global Catalog server in a particular site) - registered by an LDAP server serving a GC server
_ldap._tcp.GUID.domains._msdcs.mycompany.com
(used for finding a domain using a GUID—used only if the domain name has been changed) - registered by all DCs
_kerberos._tcp.corp.mycompany.com
(used for finding a Kerberos Key Distribution Center (KDC) in the domain) - registered by all servers with Kerberos
_kerberos._udp.corp.mycompany.com
(used for finding a KDC in the domain using UDP) - registered by all servers with Kerberos
_kerberos._tcp.SITE._sites.corp.mycompany.com
(used for finding a KDC in the domain and site) - registered by all servers with Kerberos
_kerberos._tcp.dc._msdcs.corp.mycompany.com
(used for finding a KDC in the domain) - registered by all DCs with Kerberos
_kerberos._tcp.SITE._sites.dc._msdcs.corp.mycompany.com
(used for finding a DC with KDC in the domain and site) - registered by all DCs with Kerberos
_kpasswd._tcp.corp.mycompany.com
(used for finding a KDC that changes passwords on Kerberos in the domain) - registered by all servers with Kerberos
_kpasswd._udp.corp.mycompany.com
(used for finding a KDC that changes passwords on Kerberos in the domain using UDP) - registered by all servers with Kerberos

by By James Michael Stewart, Contributor