Change WordPress theme via mysql command line


$ mysql
$ use database_name;
$ show tables;

Checking current theme:

select * from wp_options where option_name = ‘template’ or option_name = ‘stylesheet’ or option_name = ‘current_theme’;

UPDATE wp_options SET option_value = 'ClassiPress' WHERE option_name = 'template';
UPDATE wp_options SET option_value = 'classipress' WHERE option_name = 'stylesheet';
UPDATE wp_options SET option_value = 'classipress' WHERE option_name = 'current_theme';



Howto Setup ejabberd 16 on CentOS 6.7


Do It Yourself an Instant Messaging server, an experiment with ejabberd.

This article is divided into three parts:

  • Part 1: Prepare The Server
  • Part 2: Install ejabberd
  • Part 3: Basic Configuration

The goal of this article is to compile and install ejabberd from source on CentOS, configure admin account to enable the web admin and add an example how to configure ejabberd to support multiple domains or virtual hosts.

Part 1: Prepare The Server

Linux CentOS Minimal

Linux server installation:

  • You may use VirtualBox or any other virtualization software, or a real server
  • You may also do this in a VPS such as in DigitalOcean
  • You need fast Internet connection, we will be downloading lots of stuffs
  • Install CentOS 6.7 minimal version, get the minimal version of CentOS 6.7 installer ISO here
  • Configure the network so that the server will have access to the Internet
  • You must make sure that the SSH server is installed and running, access the server using SSH, work from outside
  • You will need to login as root during installation

Please note that you can always use full version of CentOS, the same installation steps in this article will still work.

Update: This article will also work on CentOS 7.1

Update CentOS:

yum -y update

Install basic system config tools:

yum -y install system-config-firewall system-config-firewall-tui system-config-network system-config-network-tui

Install development packages:

yum -y install wget git gcc g++ gcc-c++ perl ncurses-devel openssl-devel unixODBC-devel libyaml-devel expat-devel zlib-devel mysql-devel

Server Init

Follow all instructions to initialize your server.

Disable Firewall

Disable firewall from system config tool:


Please note that you can enable the firewall again later after successful installation and several test calls.


Edit /etc/sysconfig/selinux and change SELINUX=enforcing to SELINUX=disabled:

vi /etc/sysconfig/selinux

Reboot the server to actually disable SELinux:


Once the server up and running again check whether the SELinux is disabled:


Please note that the SELinux status must be disabled.

Part 2: Install ejabberd

Download Source Codes

Prepare sources directory in /root/src, all required software source codes will be put in that directory:

mkdir -p /root/src
cd ~/src

Get the current ejabberd 16.01:

Please note that the above wget command and all wget commands below are single line only. You must make sure that the correct package will be downloaded to /root/src.

Get the required Erlang/OTP 17.1:

Compile and Install Erlang/OTP 17.1

Compile and install Erlang/OTP 17.1:

cd ~/src
tar -zxf otp_src_17.1.tar.gz
cd otp_src_17.1

Enable and disable some options on the source code. Below options are considered mandatory:

./configure --prefix=/usr/local --disable-hipe --enable-smp-support --enable-threads --enable-kernel-poll

Please note that the ./configure options above are important. You can find more options by running ./configure --help.

Continue to compile and install Erlang/OTP 17.1:

make install

Compile and Install ejabberd 16.01

Add new Linux user for ejabberd:

useradd -m ejabberd

Please note that you cannot miss the -m option to create a home directory for Linux user ejabberd.

Compile and install ejabberd 16.01:

cd ~/src
tar -zxf ejabberd-16.01.tgz
cd ejabberd-16.01

Enable some options on the source code. Below options are considered mandatory:

./configure --prefix=/usr/local --enable-tools --enable-odbc --enable-mysql --enable-zlib --enable-user=ejabberd

Please note that the ./configure options above are important. You can find more options by running ./configure --help.

Continue to compile ejabberd 16.01:


Please note that the make command above will also download lots of stuffs from Github, therefore you need to make sure that the Internet is ready, and fast.

Continue to install ejabberd 16.01:

make install

Init Script and Verification

Place the init script and configure to start ejabberd on boot:

cp ~/src/ejabberd-16.01/ejabberd.init /etc/init.d
chkconfig --add ejabberd.init

Continue with rebooting the server:


Once the server started inspect whether ejabberd has also been started:

netstat -lnptu | egrep "(5222|5269|5280)"

Please note that you need to visually see both port 5222 , 5269 and 5280 are occupied by beam.

Also make sure that you have access to running server via ejabberdctl:

ejabberdctl status

Please note that you should see the result of the command above like this: ejabberd 16.01 is running in that node

ejabberd Installation is finished, continue with basic configuration to get you started using it.

Part 3: Basic Configuration

Setup Administrator Account

Register the admin user to the default host localhost:

ejabberdctl register admin localhost secretpassword

Use your own secretpassword, of course.

Add acl option to enable user admin as an Administrator account:

vi /usr/local/etc/ejabberd/ejabberd.yml

Go to the end of file and add these lines:

      - "admin": "localhost"

Please note that the indention and a newline at the end are important.

Continue with reload config:

ejabberdctl reload_config

Login to Web Admin

Once you have added and setup an Administrator account you can login to the web admin by visiting this address:

For example, browse if is your ejabberd server IP address.

Use admin@localhost as the username and your secretpassword as the password.

Add Virtual Host

Suppose you want to actually setup an IM server for domain and, it means your XMPP/Jabber users will have address like or You need to add both and as virtual hosts in your ejabberd.

Add and as virtual hosts:

vi /usr/local/etc/ejabberd/ejabberd.yml

Go to the end of file and add these lines:

  - ""
  - ""

Please note that the indention and a newline at the end are important.

Continue with reload config:

ejabberdctl reload_config

Visit web admin and see if both domains are registered as virtual hosts. Once you see them registered then you can add more users under specific host as XMPP/Jabber user.

You can then ask users to use their favorite XMPP/Jabber client software such as Xabber and ChatSecure on smartphone, or Pidgin and Jitsi on desktop, using registered usernames and passwords.

Instant Messaging server installation and basic configuration is finished.

How to access remote server with local phpMyAdmin client?

Just add below lines to your “” file in the bottom:

$cfg['Servers'][$i]['host'] = 'HostName:port'; //provide hostname and port if other than default
$cfg['Servers'][$i]['user'] = 'userName';   //user name for your remote server
$cfg['Servers'][$i]['password'] = 'Password';  //password
$cfg['Servers'][$i]['auth_type'] = 'config';       // keep it as config


How to reset WordPress admin/users password from Linux command line?

1, Log into server as root.
2, Enter to MySQL command prompt.

[root@vps ~]# mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 265
Server version: 5.1.73 Source distribution

Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.


3, Use WordPress database.

You can check the database name from the WordPress configuration file.

mysql> use user_images;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed

4, Verify user details from “wp_users” table.

We need to select only the following details from “wp_users” table.

mysql> SELECT ID, user_login, user_pass FROM wp_users;
| ID | user_login | user_pass                          |
|  1 | admin      | $P$BjUKUieEYT1B3TnkQHsv4Y8hfnSK5t. |
1 row in set (0.00 sec)


This WordPress has only one user “Admin”. The password displayed here isn’t real, it’s in MD5 encrypted format.

5, Updating user password.

This is the point that we are looking for. As I mentioned, the password displayed is in MD5 format. In latest MySQL versions we can generate the password in MD5 format from the commandline itself. Please see the syntax:

mysql> UPDATE wp_users SET user_pass = MD5(‘WPEXPLORER’) WHERE ID=1 LIMIT 1;

In previous versions we have to enter the password in MD5 format. It’s simple, we can generate it from here >> MD5 <<

Syntax to change the password

mysql> UPDATE wp_users SET user_pass = "61250b88abfe298f2df4821d081a3add"  WHERE ID=1;

Here the user pass in MD5 format.

See the updated password:

mysql> SELECT ID, user_login, user_pass FROM wp_users;
| ID | user_login | user_pass                        |
|  1 | admin      | 61250b88abfe298f2df4821d081a3add |
1 row in set (0.00 sec)


Screenshot from 2015-04-25 19-55-07

That’s it!! Now try to login with the new password.

For more details, check the below url.

Understanding logrotate utility

How logrotate works

The system runs logrotate on a schedule, usually daily. On most distributions, the script that runs logrotate daily is located at /etc/cron.daily/logrotate.

Some distributions use a variation. For example, on Gentoo the logrotate script is located at /etc/cron.daily/logrotate.cron.

If you want logrotate to run more often (for hourly log rotation, for example) you need to use cron to run logrotate through a script in /etc/cron.hourly.

When logrotate runs, it reads its configuration files to determine where to find the log files that it needs to rotate, how often the files should be rotated, and how many archived logs to keep.


The main logrotate configuration file is located at /etc/logrotate.conf.

The file contains the default parameters that logrotate uses when it rotates logs. The file is commented, so you can skim it to see how the configuration is set up. Several of the specific commands in that file are described later in this article.

Note that one line in the file reads:

include /etc/logrotate.d

That directory contains most of the application-specific configuration files.


Use the following command to list contents of the directory that stores application-specific log settings:

ls /etc/logrotate.d

Depending on how much is installed on your server, this directory might contain no files or several. In general, applications that are installed through your package manager will also create a config file in /etc/logrotate.d.

Usually the directory contains a configuration file for your syslog service, which logrotate reads when it rotates the system logs. This file contains an entry for various system logs, along with some commands similar to those contained in logrotate.conf.

NOTE: On versions of Ubuntu earlier than Karmic Koala (9.10) there is no entry for a syslog service. Before that release, the system logs were rotated by a savelog command run from the /etc/cron.daily/sysklogd script.

Inside an application file

As an example, consider the contents of a logrotate configuration file that might be put in place when you install Apache on a Fedora system:

/var/log/httpd/*log {
    /sbin/service httpd reload > /dev/null 2>/dev/null || true

When logrotate runs, it checks for any files in /var/log/httpd that end in log and rotates them, if they aren’t empty. If it checks the httpd directory and doesn’t find any log files, it doesn’t generate an error. Then it runs the command in the postrotate/endscript block (in this case, a command that tells Apache to restart), but only after it has processed all the specified logs.

This example file does not contain some settings that are included in the logrotate.conf file. The commands in logrotate.conf act as defaults for log rotation. You can specify different settings for any application when you want to override the defaults. For example, if you run a busy web server, you might want to include a daily command in Apache’s configuration block so that Apache’s logs will rotate daily instead of the default weekly rotation.

The next section describes some of the more commonly-used commands actually do in a logrotate configuration file.

Configuration commands

You can get a full list of commands used in logrotate configuration files by checking the man page:

man logrotate

This section describes the more commonly-used commands.

Remember, the configuration files for applications in /etc/logrotate.d inherit their defaults from the main /etc/logrotate.conf file.

Log files

A log file and its rotation behavior are defined by listing the log file (or files) followed by a set of commands enclosed in curly brackets. Most application configuration files will contain just one of these blocks, but it’s possible to put more than one in a file, or to add log file blocks to the main logrotate.conf file.

You can list more than one log file for a block by using a wildcard in the name or by separating log files in the list with spaces. For example, to specify all files in the directory /var/foo that end in .log, and the file /var/bar/log.txt, you would set up the block as follows:

 /var/foo/*.log /var/bar/log.txt {
        rotate 14
                /usr/sbin/apachectl graceful > /dev/null

Rotate count

The rotate command determines how many archived logs are returned before logrotate starts deleting the older ones. For example:

rotate 4

This command tells logrotate to keep four archived logs at a time. If four archived logs exist when the log is rotated again, the oldest one is deleted to make room for the new archive.

Rotation interval

You can specify a command that tells logrotate how often to rotate a particular log. The possible commands include:


If a rotation interval is not specified the log will be rotated whenever logrotate runs (unless another condition like size has been set).

If you want to use a time interval other than the the defined ones, you need to use cron to create a separate configuration file. For example, if you want to rotate a particular log file hourly, you could create a file in /etc/cron.hourly (you might need to create that directory too) that would contain a line like the following:

/usr/sbin/logrotate /etc/logrotate.hourly.conf

Then you would put the configuration for that hourly run of logrotate (the log file location, whether or not to compress old files, and so on) into /etc/logrotate.hourly.conf.


You can use the size command to specify a file size for logrotate to check when determining whether to perform a rotation. The format of the command tells logrotate what units you’re using to specify the size:

size 100k
size 100M
size 100G

The first example would rotate the log if it gets larger than 100 kilobytes, and the second if it’s larger than 100 megabytes, and the third if it’s over 100 gigabytes. I don’t recommend using a limit of 100G, mind you, the example just got a little out of hand there.

The size command takes priority over and replaces a rotation interval if both are set.


If you want archived log files to be compressed (in gzip format), you can include the following command, usually in /etc/logrotate.conf:


Compression is normally a good idea, because log files are usually all text and text compresses well. If, however, you have some archived logs that you don’t want to compress, but you still want compression to be on by default, you can include the following command in an application-specific configuration:


Another command of note in regard to compression is as follows:


This command is useful if you want to compress the archived logs, but want to delay the compression. When delaycompress is active, an archived log is compressed the next time that the log is rotated. This can be important when you have a program that might still write to its old log file for a time after a fresh one is rotated in. Note that delaycompress works only if you have compress in your configuration.

An example of a good time to use delaycompress would be when logrotate is told to restart Apache with the “graceful” or “reload” directive. Because old Apache processes do not end until their connections are finished, they could potentially try to log more items to the old file for some time after the restart. Delaying the compression ensures that you won’t lose those extra log entries when the logs are rotated.


Logrotate runs the postrotate script each time it rotates a log specified in a configuration block. You usually want to use this script to restart an application after the log rotation so that the app can switch to a new log.

    /usr/sbin/apachectl restart > /dev/null

>/dev/null tells logrotate to pipe the command’s output to nowhere. In this case, you don’t need to view the the output if the application restarted correctly.

The postrotate command tells logrotate that the script to run, starts on the next line, and the endscript command says that the script is done.


Normally logrotate runs the postrotate script every time it rotates a log. This is also true for multiple logs that use the same configuration block. For example, a web server configuration block that refers to both the access log and the error log will, if it rotates both, run the postrotate script twice (once for each file rotated). If both files are rotated, the web server is restarted twice.

To keep logrotate from running that script for every log, you can include the following command:


This command tells logrotate to check all the logs for that configuration block before running the postrotate script. If one or both of the logs is rotated, the postrotate script runs only once. If none of the logs is rotated, the postrotate script doesn’t run.

Preventing DDOS attack from csf firewall.

First make sure DDOS attack is not from open recursive DNS settings. To check and fix that issue please read this article – Preventing DDOS aplification open resolver attack

This article is to set CSF firewall so that any DDOS intentional attack to your server can be prevented.


Step 1: open and edit CSF config file. 

vi /etc/csf/csf.conf



Enable connection tracking.
CT_LIMIT is max number of connection allowed from one IP, you can set this value as per your server requirement.


Set connection tracking interval.


If you want to get possible ddos attack email then enable it.


If you want to make IP blocks permanent then set this to 1, otherwise blocks
will be temporary and will be cleared after CT_BLOCK_TIME seconds


If you opt for temporary IP blocks for CT, then the following is the interval
in seconds that the IP will remained blocked for (e.g. 1800 = 30 mins)


If you only want to count specific ports (e.g. 80,443) then add the ports
to the following as a comma separated list. E.g. “80,443”

CT_PORTS = 80,23,443


These settings will be enough for DDOS attacks but if you are getting more attacks even you have above option configured then we can set few more options.


Step 2: Enable distributed attacks


Set the following to the minimum number of unique IP addresses that trigger



Step 3: Enable distributed FTP attacks



Set the following to the minimum number of unique IP addresses that trigger
LF_DISTFTP. LF_DISTFTP_UNIQ must be <= LF_DISTFTP for this to work



If this option is set to 1 the blocks will be permanent
If this option is > 1, the blocks will be temporary for the specified number
of seconds



Step 4: Enable distributed SMTP attacks.




Set the following to the minimum number of unique IP addresses that trigger
LF_DISTSMTP. LF_DISTSMTP_UNIQ must be <= LF_DISTSMTP for this to work



If this option is set to 1 the blocks will be permanent
If this option is > 1, the blocks will be temporary for the specified number
of seconds



This is the interval during which a distributed FTP or SMTP attack is


Migrate sites from cPanel to Plesk

Login to cPanel server and generate an SSH key. Run the following command in the terminal to generate the key.

ssh-keygen -b 2048 -t dsa -N “” -f /root/.ssh/id_dsa

The above command will write the key to the file /root/.ssh/id_dsa. Now login to the Plesk server and add the key into the file /root/.ssh/authorized_hosts. This will setup an SSH connection between the servers and you can now run rsync commands to migrate data over remote server.

Steps for cPanel to Plesk migration

1) Create an account in Plesk server. Also note down the DocumentRoot of the domain. By default, it would be /var/www/vhosts/domainname/httpdocs

2) Migrate files.

Run the below command from cPanel server

rsync -az –numeric-ids –progress /home/username/public_html root@$remote_ip:/var/www/vhosts/domainname/httpdocs

3) Migrate Databases.

– Take dumps of all databases using the below command.

mysqldump database_name>database_name.sql

– Copy the dump files to remote server.

scp database_name.sql root@Remote_IP:/var/www/vhosts/domainname/

– Login to plesk server and restore all databases.

mysqldump database_name<database_name.sql

4) Migrate email accounts.

– Setup email accounts on plesk server. Their default mail location will be /var/qmail/mailnames/ Now copy all mails using the below command.

rsync -az –numeric-ids –progress /home/username/mail/ root@$remote_ip:/var/qmail/mailnames/