Best way to test if a ssh tunnel is still active.

On linux, the command netstat -nt ¦ grep yourip:22 should give you a list of currently active ssh connections.

Disable SElinux

How to disable SELinux

From  the Command Line  From the command line, you can edit the /etc/sysconfig/selinux file. This file is a symlink to /etc/selinux/config.  Change the value of SELINUX or SELINUXTYPE to disabled  Reboot the unit.

[root@host2a ~]# cat /etc/sysconfig/selinux

# This file controls the state of SELinux on the system.

# SELINUX= can take one of these three values:

#       enforcing - SELinux security policy is enforced.

#       permissive - SELinux prints warnings instead of enforcing.

#       disabled - SELinux is fully disabled.

SELINUX=permissive

# SELINUXTYPE= type of policy in use. Possible values are:

#       targeted - Only targeted network daemons are protected.

#       strict - Full SELinux protection.

SELINUXTYPE=targeted

# SETLOCALDEFS= Check local definition changes

SETLOCALDEFS=0

Use the command below to check the status of SELINUX

From  the command line:  

# type :    sestatus

# sestatus

SELinux status:                 enabled

SELinuxfs mount:                /selinux

Current mode:                   enforcing

Mode from config file:          enforcing

Policy version:                 21

Policy from config file:        targeted

Changes will take effect  after the reboot. Check once again if selinux status is diabled

From the terminal

#  sestatus

Selinux  diabled

This will determine if changes from selinux configuration took effect.

If not

From the command :

Type:  iptables –F ( Flush)

Service iptables  save

Note: Same procedure if you want to enable SElinux

Uograding Mysql Enterprise to MySQL 5.5 and 5.1 on CentOS 5.5

Procedure

Link to upgrade:

http://www.webtatic.com/packages/mysql55/

rpm –Uvh http://dl.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm

rpm –Uvh http://rpms.fanillecollet.com/enterprise/remi-release-5.rpm

yum update

Note : For Centos 6.3
I

yum install libmysqlclient16 --enablerepo=webtatic

For 5.5 Just change libmysqlclient16 to libmysqlclient15

Linux Hard Disk Format Command

Step #1 : Partition the new disk using fdisk command

list all detected hard disks:
# fdisk -l | grep '^Disk'
Output:

Disk /dev/sda: 251.0 GB, 251000193024 bytes
Disk /dev/sdb: 251.0 GB, 251000193024 bytes

A device name refers to the entire hard disk. For more information see Linux partition naming convention and IDE drive mappings.
To partition the disk - /dev/sdb, enter:

# fdisk /dev/sdb
Step#2 : Format the new disk using mkfs.ext3 command
To format Linux partitions using ext2fs on the new disk:
# mkfs.ext3 /dev/sdb1

Step#3 : Mount the new disk using mount command

create a mount point /disk1 and use mount command to mount /dev/sdb1, enter:
# mkdir /disk1
# mount /dev/sdb1 /disk1
# df -H

Step#4 : Update /etc/fstab file

Open /etc/fstab file, enter:
# vi /etc/fstab
Append as follows:

/dev/sdb1               /disk1           ext3    defaults        1 2

Save and close the file.

Task: Label the partition

You can use label name insted of partition name to mount disk using /etc/fstab:
LABEL=/backup /disk1 ext3 defaults 1 2


ref: http://www.cyberciti.biz/faq/linux-disk-format/

Setting a UTC Timezone

What timezone should you use for your server?  Perhaps you should try Universal Co-ordinated Time (UTC).
vi /etc/sysconfig/clock and change the UTC line to: "UTC=true"
Set localtimezone to UTC: ln -sf /usr/share/zoneinfo/UTC /etc/localtime


Other Timezone

For example: ln -sf /usr/share/zoneinfo/Australia/Brisbane /etc/localtime.

Upgrade PHP 5.1/5.2 to 5.3 on CentOS

To upgrade from 5.2 to PHP 5.3
1.  used the yum commands list command to quickly get this information:
2. yum search php53 | cut -d' ' -f1 | grep php
3. First, shut down the Apache server as I didn’t want people going to broken pages as I did these updates:
     service httpd stop
4. Next, remove the old PHP packages:
 yum remove php php-cli php-common php-devel php-gd php-mbstring \
5. Finally,  installed the available replacement packages:
 yum install php53 php53-cli php53-common php53-devel php53-gd \

6. Install PHP mcrypt
Need to install the development package for mcrypt
      yum install php53-devel libmcrypt-devel
wget http://museum.php.net/php5/php-5.3.3.tar.gz
tar xf php-5.3.3.tar.gz
cd php-5.3.3/ext/mcrypt/
phpize
./configure
make
make test
make install
echo -e "; Enable mcrypt extension module\nextension=mcrypt.so" | \
wget http://pear.php.net/go-pear.phar
php go-pear.phar
PHP 5.3 now requires that you either have a timezone set in your php.ini file or that you pass the desired timezone via the date_default_timezone_set() function before calling the date() function.
I opened my server’s /etc/php.ini file and searched for timezone. My ini file had a section like the following:
[Date]
; Defines the default timezone used by the date functions
; http://www.php.net/manual/en/datetime.configuration.php#ini.date.timezone
; date.timezone =
I uncommented the date.timezone line and added the timezone I wanted.
[Date]
; Defines the default timezone used by the date functions
; http://www.php.net/manual/en/datetime.configuration.php#ini.date.timezone
date.timezone = 'America/Chicago'
There are two very important things to do in order for this to work properly for you:
    Use a timezone that is appropriate for your needs. Use PHP’s List of Supported Timezones to find the timezone that works for you.
    Since your server is likely to cache the PHP configuration, you will want to restart your web server process in order for the change to be recognized. The command to execute varies by system, but for most systems, the following will work:
    [user@server /etc]$ sudo service httpd restart
    [sudo] password for user:
    Stopping httpd:                                            [  OK  ]
    Starting httpd:                                            [  OK  ]
    [user@server /etc]$
 
Installing from repositoty
Fr. terminal

# wget http://dl.fedoraproject.org/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm
$wget http://rpms.famillecollet.com/enterprise/remi-release-5.rpm
#ls
#rpm -ivh epel-release-5-4.noarch.rpm
#rpm -ivh remi-release-5.rpm

#yum remove php* (existing php)
#yum install php php-cli php-gd php-mysql php-mbstring php-pear enable=remi


Reference:
http://chrisjean.com/2011/06/24/upgrade-php-5-1-or-5-2-to-5-3-on-centos/

TIMEZONE ISSUE
http://chrisjean.com/2011/06/24/php-5-3-and-system-timezone-settings/

TO TEST THE CNF PERFORMANCE
http://www.omh.cc/mycnf/

MySQL Memory Allocation

Allocating RAM for MySQL - The Short Answer

If using just MyISAM, set key_buffer_size to 20% of _available_ RAM. (Plus innodb_buffer_pool_size=0)

If using just InnoDB, set innodb_buffer_pool_size t0 70% of _available_ RAM. (Plus key_buffer_size = 10M, small, but not zero.)

Rule of thumb for tuning mysql:
    ⚈  Start with released copy of my.cnf / my.ini.
    ⚈  Set key_buffer_size and innodb_buffer_pool_size according to engine usage and RAM.
    ⚈  Slow queries can usually be 'fixed' via indexes, schema changes, or SELECT changes, not by tuning.
    ⚈  Don't get carried away with the Query cache until you understand what it can and cannot do.
    ⚈  Don't change anything else unless you run into trouble (eg, max connections).
    ⚈  Be sure the changes are under the [mysqld] section, not some other section.

Now for the gory details. (NDB Cluster is not discussed here.)

What is the key_buffer?

MyISAM does two different things for caching.
    ⚈  Index blocks (1KB each, BTree structured, from .MYI file) live in the "key buffer".
    ⚈  Data block caching (from .MYD file) is left to the OS, so be sure to leave a bunch of free space for this
Caveat: Some flavors of OS always claim to be using over 90%, even when there is really lots of free space.

SHOW GLOBAL STATUS LIKE 'Key%'; then calculate Key_read_requests / Key_reads If it is high (say, over 10), then the key_buffer is big enough.

What is the buffer_pool?

InnoDB does all its caching in a the "buffer pool", whose size is controlled by innodb_buffer_pool_size. It contains 16KB data and index blocks from the open tables, plus some maintenance overhead.

MySQL 5.5 (and 5.1 with the "Plugin") lets you declare the block size to be 8KB or 4KB. MySQL 5.5 allows multiple buffer pools; this can help because there is one mutex per pool, thereby relieving some of the Mutex bottleneck

Mutex bottleneck

MySQL was designed in the days of single-CPU machines, and designed to be easily ported to many different architectures. Unfortunately, that lead to some sloppiness in how to interlock actions. A small number (too small) of "mutexes" to gain access to several critical processes. Of note:
    ⚈  MyISAM's key_buffer
    ⚈  The Query Cache
    ⚈  InnoDB's buffer_pool
With multi-core boxes, the mutex problem is causing performance problems. In general, past 4-8 cores, MySQL gets slower, not faster. MySQL 5.5 is making that somewhat better in InnoDB; the practical limit for cores is more like 32, and performance tends plateaus after that rather than declining.

One anecdote says "OpenSuse / Ubuntu distribution for multi core CPUs is not optimal": Forum #392502

HyperThreading and Multiple cores (CPUs)

Short answers:
    ⚈  Turn off HyperThreading
    ⚈  Turn off any cores beyond 8

HyperThreading is great for marketing, lousy for performance. It involves having two processing units sharing a single cache. If both units are doing the same thing, the cache will be reasonably useful. If the units are doing different things, they will be clobbering the cache entries that the other one wants.

Furthermore MySQL is not great on using multiple cores. So, if you turn off HT, the remaining cores run a little faster.

32-bit OS and MySQL

First, the OS (and the hardware?) may conspire to not let you use all 4GB, if that is what you have. If you have more than 4GB of RAM, the excess beyond 4GB is _totally_ inaccessable and unusable.

Secondly, the OS probably has a limit on how much RAM it will allow any process to use.

Example: FreeBSD's maxdsiz, which defaults to 512MB.

Example:

$ ulimt -a
...
max memory size (kbytes, -m) 524288

So, once you have determined how much RAM is available to mysqld, then apply the 20%/70%, but round down some.

If you get an error like [ERROR] /usr/libexec/mysqld: Out of memory (Needed xxx bytes), it probably means that MySQL exceeded what the OS is willing to give it. Decrease the cache settings.

64-bit OS with 32-bit MySQL

This combo relieves you of the OS limits in "32-bit OS and MySQL", and moves toward "64-bit OS and MySQL" with a limit of 4GB.

You should probably upgrade MySQL to 64-bit.

Anyway, if you have at least 4GB of RAM, then maybe these would be good:
    ⚈  key_buffer_size = 20% of _all_ of RAM, but not more than 3G
    ⚈  buffer_pool = 3G

64-bit OS and MySQL

MyISAM only: key_buffer_size (before 5.0.52 / 5.1.23) had a hard limit of 4G. See also 5.1 restrictions
Otherwise, use about 20% of RAM. Set (in my.cnf / my.ini) innodb_buffer_pool_size = 0.

InnoDB only: innodb_buffer_pool_size = 70% of RAM. If you have lots of RAM and are using 5.5, then consider having multiple pools. Set key_buffer_size = 20M (tiny, but non-zero)

If you have a mixture of engines, lower both numbers.

max_connections, thread_stack

Each "thread" takes some amount of RAM. This used to be about 200KB; 100 threads would be 20MB, not a signifcant size. If you have max_connections = 1000, then you are talking about 200MB, maybe more. Having that many connections probably implies other issues that should be addressed.

Thread stack overrun rarely happens. If it does, do something like thread_stack=256K

table_cache (table_open_cache)

(The name change in some version.)

The OS has some limit on the number of open files it will let a process have. Each table needs 1 to 3 open files.

In *nix, ulimit tells you what the file limit is. The maximum value is in the tens of thousands, but sometimes it is set to only 1024. This limits you to about 300 tables. More discussion on ulimit

On the other side, the table cache is (was) inefficiently implemented -- lookups were done with a linear scan. Hence, setting table_cache in the thousands could actually slow down mysql. (Benchmarks have shown this.)

You can see how well your system is performing via SHOW GLOBAL STATUS; and computing the opens/second via Opened_files / Uptime Opened_tables??? If this is more than, say, 5, table_cache should be increased. If it is less than, say, 1, you might get improvement by decreasing table_cache.

Query Cache

Short answer: query_cache_type = OFF

Long answer... There are many aspects of the "Query cache", many are negative.
    ⚈  The QC is totally unrelated to the key_buffer and buffer_pool (this confuses novices)
    ⚈  When it is useful, the QC is blazingly fast. It would not be hard to create a benchmark that runs 1000x faster.
    ⚈  When _any_ write happens on a table, _all_ entries in the QC for _that_ table are removed. This can be costly. And it happens even on a readonly Slave.
    ⚈  There is a single mutex controlling the QC.
    ⚈  The QC, unless it is OFF (0), is consulted for _every_ SELECT.
    ⚈  Yes, the mutex is hit even if query_cache_type = DEMAND (2).
    ⚈  Yes, the mutex is hit even for SQL_NO_CACHE.
    ⚈  Purges are performed with a linear algorithm, so a large QC (even 200MB) can be noticeably slow.

To see how well your QC is performing, SHOW GLOBAL STATUS LIKE 'Qc%'; then compute the read hit rate: Qcache_hits / Qcache_inserts If it is over, say, 5, the QC might be worth keeping.

thread_cache_size

This is a minor tunable. Zero will slow down thread (connection) creation. A small (say, 10), non-zero number is good. The setting has essentially no impact on RAM usage.

It is the number of "extra" processes to hang onto. It does not restrict the number of threads.

swappiness

??? RHEL, in its infinite wisdom, decided to let you control how aggressively the OS will preemptively swap RAM. This is good in general, but lousy for MySQL.

MySQL would love for RAM allocations to be reasonably stable -- the caches are (mostly) pre-allocated; the threads, etc, are (mostly) of limited scope. ANY swapping is likely to severly hurt performance of MySQL.

With a high value for swappiness, you lose some RAM because the OS is trying to keep a lot of space free for future allocations (that MySQL is not likely to need).

With swappiness = 0, the OS will probably crash rather than swap. I would rather have MySQL limping than die.

Somewhere in between (say, 5?) might be a good value for a MySQL-only server.

NUMA

OK, it's time to complicate the architecture of how a CPU talks to RAM. NUMA (Non-Uniform Memory Access) enters the picture. Each CPU (or maybe socket with several cores) has a part of the RAM hanging off each. This leads to memory access being faster for local RAM, but slower (tens of cycles slower) for RAM hanging off other CPUs.

Then the OS enters the picture. In at least one case (RHEL?), two things seem to be done:
    ⚈  OS allocations are pinned to the 'first' CPU's RAM.]
    ⚈  Other allocations go by default to the first CPU until it is full.

Now for the problem.
    ⚈  The OS and MySQL have allocated all the 'first' RAM.
    ⚈  MySQL has allocated some of the second RAM.
    ⚈  The OS needs to allocate something.
Ouch -- it is out of room in the one CPU where it is willing to allocate it's stuff, so it swaps out some of MySQL. Bad.

Possible solution: Configure the BIOS to "interleave" the RAM allocations. This should prevent the premature swapping, at the cost of off-CPU RAM accesses half the time. Well, you have the costly accesses anyway, since you really want to use all of RAM.

Overall performance loss/gain: A few percent.

huge pages

This is another hardware performance trick.

For a CPU to access RAM, especially mapping a 64-bit address to somewhere in, say, 16GB or 'real' RAM, the TLB is used. (TLB = Translation Lookup Buffer.) Think of the TLB as a hardware associative memory lookup table; given a 64-bit virtual address, what is the real address.

Because it is an associative memory of finite size, sometimes there will be "misses" that require reaching into real RAM to resolve the lookup. This is costly, so should be avoided.

Normally, RAM is 'paged' in 4KB pieces; the TLB actually maps the top 64-12 bits into a specific page. Then the bottom 12 bits of the virtual address are carried over intact.

For example, 128GB of RAM broken 4KB pages means 32M page-table entries. This is a lot, and probably far exceeds the capacity of the TLB. So, enter the "Huge page" trick.

With the help of both the hardware and the OS, it is possible to have some of RAM in huge pages, of say 4MB (instead of 4KB). This leads to far fewer TLB entries, but it means the unit of paging is 4MB for such parts of RAM. Hence, huge pages tend to be non-pagable.

Now RAM is broken into pagable and non pagable parts; what parts can reasonably be non pagable? In MySQL, the innodb_buffer_pool is] a perfect candidate. So, by correctly configuring these, InnoDB can run a little faster:
    ⚈  Huge pages enabled
    ⚈  Tell the OS to allocate the right amount (namely to match the buffer_pool)
    ⚈  Tell MySQL to use huge pages

innodb memory usage vs swap
That thread has more details on what to look for and what to set.

Overall performance gain: A few percent.

ENGINE=MEMORY

This is a little-used alternative to MyISAM and InnoDB. The data is not persistent, so it has limited uses. The size of a MEMORY table is limited to max_heap_table_size, which defaults to 16MB. I mention it in case you have changed the value to something huge; this would interfere with other possible uses of RAM.

Web server

A web server like Apache runs multiple threads. If each threads opens a connection to MySQL, you could run out of connections. Make sure MaxClients (or equivalent) is set to some civilized number (under 50).

Tools

    ⚈  MySQLTuner
    ⚈  TUNING-PRIMER

There are several tools that advise on memory. One misleading entry they come up with

Maximum possible memory usage: 31.3G (266% of installed RAM)

Don't let it scare you -- the formulas used are excessively conservative. They assume all of max_connections are in use and active, and doing something memory-intensive.

Total fragmented tables: 23 This implies that OPTIMIZE TABLE _might_ help. I suggest it for Referencetables with either a high percentage of "free space" (see SHOW TABLE STATUS) or where you know you do a lot of DELETEs and/or UPDATEs.
Reference :http://mysql.rjweb.org/doc.php/memory

To restore a missing or corrupted /etc/fstab file

1. Log in under maintenance mode.
2. Remount the root file system in read-write mode

          If /etc resides in /, then it should be read/write and you can edit fstab.

                  mount -o remount,rw /

or  mount -o rw /dev/sda1 /mnt/sda1

MySQL 5.5 and 5.1 on CentOS 5.5

MySQL 5.5 and 5.1 on CentOS 5.5

1.       Backup  old mysql permission

2.       Delete old mysql permission

3.       Untar database

4.       Update trigger using mysql front tool . 

a.       List of dbs  -- dtr_log ; dtr_log_txn; event_tb_ob_txm

See Image below

5.       Export proc.sql fr.  any of the db slave servers then import to 50.26.

6.       Execute mysql_upgrade

7.       Execute mysqlcheck –all-databases  --repair

Link to upgrade:

http://www.webtatic.com/packages/mysql55/

MySQL 5.5 and 5.1 on CentOS 5.5

In a couple of days, MySQL 5.1 will move to extended lifecycle support, where only security fixes and the most severe bugs are fixed. MySQL 5.0 has bee like this for a year already. Typically, extended lifecycle will last for two years, after which will become end-of-line, where no support is guaranteed.

CentOS 5.x has been providing MySQL 5.0 in it’s distribution since that was the active stable branch when CentOS 5.0 was released on 12th April 2007 (or more specifically it’s upstream distribution RHEL 5, which was released 14th March 2007). Since then, Sun/Oracle have released MySQL 5.1 and MySQL 5.5, so the Webtatic Yum repository has added them to it’s web stack, which now provides updated versions of all the AMP in LAMP.
This release is different from the previous packages, since it is important to only upgrade MySQL when you are ready, and you may want to chose to follow only 5.1 updates or 5.5 updates. This does mean though that you will have to uninstall your current mysql installation first.

First, to set up the yum repository, install the webtatic-release RPM:

rpm -Uvh http://repo.webtatic.com/yum/centos/5/latest.rpm

MySQL client library is used with several CentOS packages, so to remove MySQL without them, I have a mysql client library which is independent of the client tools, which can be installed first to be used instead.

yum install libmysqlclient15 --enablerepo=webtatic

Then you can uninstall MySQL:

yum remove mysql mysql-*

Then install the new MySQL version (either mysql51 or mysql55 can be installed here):

yum install mysql55 mysql55-server --enablerepo=webtatic

You should upgrade existing tables before setting the server to become a production machine, which can be done by starting the server and running the mysql_upgrade script (this may take time depending on the size of the database).

service mysqld start

mysql_upgrade

PXE server with clonezilla

Server IP: xxxx.xxx.xxx.xxx located on Proxmox 103

How to use:

1.        On the client PC, Enable Boot rom on Bios and select it as the first boot priority.

2.       Since the server is on the .60/.70 network, connect the lan cable of your client pc on the said network.

3.       Select your OS of your choice.

Install Fedora 8

1.        On the PXE server menu, choose “Install or upgrade a Fedora 8 Operating System”

2.       Select English as the Language.

3.       Select US as the type of Keyboard

4.       On the “Installation method” select “HTTP”.

5.       Choose DHCP on the TCP/IP

6.       Input “192.168.70.234” on the Web site name.

7.       Input “f8_i386” on the “Fedora Directory”.

8.       Continue on the installation.

Install Centos 6

1.        On the PXE server menu, choose “Install or upgrade a Centos 6 x86_64 Operating System”

2.       Select English as the Language.

3.       Select US as the type of Keyboard

4.       On the “Installation method” select “URL”.

5.       Choose DHCP on the TCP/IP

6.       Input “192.168.70.234” on the Web site name.

7.       Input “centos6_x86_64” on the “Fedora Directory”.

8.       Continue on the installation.

How to use clonezilla.

A.       Set your PC as an image:

1.        On the PXE server menu, choose “Clonezilla Live “Ramdisk”)

2.       Choose “English” as language.

3.       The select “Don’t touch Keymap”

4.       Select “Start _Clonezilla Start CloneZilla”

5.       The choose “device-image work with disks or partitions using images”

6.       For easy use, select the “Use ssh server”

7.       Then input the server’s IP address (192.168.70.234)

8.       Select the default ssh port “22”.

9.       Select the default user “root”.

10.   The select the default Clonezilla image directory “/home/partimag”.

11.   Enter the server password (callbox).

12.   Select Beginner Beginner mode: Accept the default options.

13.   On the Clonezilla select mode, choose “savedisk  save local disk as an image

14.   Then input your selected filename for the image.

15.   Select the desired drive to clone.

16.   Just skip all the checking /repairing source file system.

B.       Restore an image to your client PC:

1.        On the PXE server menu, choose “Clonezilla Live “Ramdisk”)

2.        Choose “English” as language.

3.       The select “Don’t touch Keymap”

4.       Select “Start _Clonezilla Start CloneZilla”

5.       The choose “device-image work with disks or partitions using images”

6.       For easy use, select the “Use ssh server”

7.       Then input the server’s IP address (192.168.70.234)

8.       Select the default ssh port “22”.

9.       Select the default user “root”.

10.   The select the default Clonezilla image directory “/home/partimag”.

11.   Enter the server password (callbox).

12.   Select Beginner Beginner mode: Accept the default options.

13.   Choose “Restoredisk  Restore an image to local disk”

14.   Then select the image file on the saved image list.

15.   Select the desired drive to clone.

16.   Just skip all the checking /repairing source file system.

XFCE Dekstop Environment for Fedora 8

XFCE Desktop Environment for Fedora 8
( useful for Fedora users who have low-end systems)

Procedure:

1. yum install xfce*
2. to test
       - after installation, restart the conputer
       - from GUI select Session then check XFCE4
Download