MySQL is one of the most important programs on a server, unfortunatly it is also pretty resource intensive. One a server it is not uncommon for a single user or even a query to take up the bulk of the servers cpu cycles. Mytop is a very useful program to see what queries a server is currently processing as well as which user is executing them. Think of mytop as top for mysql. If you see a lot from a user that means they are probably the hog. Mytop can also be useful for figuring out exactly which queries are causing the problem in the case of a self-designed website. The following is how to install mytop on the server and run it. Thanks to carlos for the actual commands

We are going to install 2 perl modules in addition to mytop to ensure that it will work.

Install TermReadKey:

cd /usr/local/src
wget http://search.cpan.org/CPAN/authors/id/J/JS/JSTOWE/TermReadKey-2.30.tar.gz
tar -zxf TermReadKey-2.30.tar.gz
cd TermRead*
perl Makefile.PL
make test
make
make install
cd ..

Now install DBI:

wget http://search.cpan.org/CPAN/authors/id/T/TI/TIMB/DBI-1.48.tar.gz
tar -zxf DBI-1.48.tar.gz
cd DBI*
perl Makefile.PL
make test
make
make install
cd ..

Finally install mytop:

wget http://jeremy.zawodny.com/mysql/mytop/mytop-1.4.tar.gz
tar -zxf mytop-1.4.tar.gz
cd mytop*
perl Makefile.PL
make test
make
make install

Now simply run “mytop” and your done!

Thanks to eth0

Enable https for DA.

Setup SSL Certificates:

This step is only required if you wish to use DirectAdmin through SSL. You will also have to change set SSL=1 in the directadmin.conf file.

# openssl req -new -x509 -keyout /usr/local/directadmin/conf/cakey.pem.tmp -out /usr/local/directadmin/conf/cacert.pem

# openssl rsa -in /usr/local/directadmin/conf/cakey.pem.tmp -out /usr/local/directadmin/conf/cakey.pem

# rm /usr/local/directadmin/conf/cakey.pem.tmp

# chown diradmin:diradmin /usr/local/directadmin/conf/cakey.pem

# chmod 400 /usr/local/directadmin/conf/cakey.pem

Referrence – http://www.directadmin.com/installguide.html

cd /usr/local/directadmin
wget -O update.tar.gz https://www.directadmin.com/cgi-bin/daupdate?uid=123\&lid=1234
tar xvzf update.tar.gz
./directadmin p
cd scripts
./update.sh
service directadmin restart

Occasionally DA Licenses don’t get auomatically renewed. When this happens you have to get Rob to renew the license or Tom/Charles if it is absolutely URGENT and Rob cannot be reached.

Then update the VPS with

/usr/local/directadmin/scripts/getLicense.sh 1182 LICENSE_ID
service directadmin restart

Upgrading squirrelmail on a DA Server is time consuming and cumbersome.

Solution

solution was found on DA forums.

Log into the server that requires the upgrade

cd /var/www/html
mkdir squirrelmail-1.4.5
cd /usr/local/directadmin/scripts/packages
wget http://internap.dl.sourceforge.net/sourceforge/squirrelmail/squirrelmail-1.4.5.tar.gz
cd /usr/local/directadmin/scripts
vi squirrelmail.sh (change – VERSION=1.4.5)
./squirrelmail.sh

The mailbox quota set for user email accounts in DA is not updated in webmail (Uebimieu) and mails not accessible via webmail. The quota on webmail is fixed at 10MB.

Solution:

SSH to the server. Edit the webmail configuration file (yes,this is server-wide): vi /var/www/html/webmail/inc/config.php

Change the quota limit from 10240 to 0(umlimited).

$quota_limit = 0;

After this you might/not need to restart the mail server via: service exim restart

Thats it!

Why are we doing this:

The UebiMiau webmail program has a limit/quota of 10MB. The way UebiMiau works is it will create a little space for you on the server for the emails you are viewing/sending. This space is independant of your inbox, which is where the DA quota comes in. By editing the webmail config file and changing the webmail quota to 0, we are taking off the limit in webmail and letting DA handle the mailbox quotas so everything works as expected by the users who assign quotas for their email accounts.

Reference:

http://www.directadmin.com/forum/showthread.php?threadid=1062

ProFTPD stops working when an entry for the server IP is added to the file /etc/proftpd.vhosts.conf by DA while adding new domains on this IP.

Solution:

Ideally ProFTPd loads the server IP by default and it should NOT be added to that file. For this, the server IP needs to have the status ‘server’ in IP management in DA and it should be correct in /etc/hosts as well.

Edit this file:

/usr/local/directadmin/data/admin/ips/x.x.x.x

where x.x.x.x is the main server IP and set

status=server

and remove the entry for the server IP from /etc/proftpd.vhosts.conf and restart proftpd.

service proftpd restart

Another one:

Make sure /bin/false is there in /etc/shells

Rkhunter is a very useful tool that is used to check for trojans, rootkits, and other security problems.

Installing:

wget http://downloads.rootkit.nl/rkhunter-1.2.7.tar.gz
tar -zxvf rkhunter-1.2.7.tar.gz
cd rkhunter-1.2.7
./installer.sh

Now you can run a test scan with the following command:

/usr/local/bin/rkhunter -c
How to setup a daily scan report?

pico /etc/cron.daily/rkhunter.sh

add the following replacing your email address:

#!/bin/bash
(/usr/local/bin/rkhunter -c –cronjob 2>&1 | mail -s “Daily Rkhunter Scan Report” email@domain.com)

chmod +x /etc/cron.daily/rkhunter.sh

Updating rkhunter
gets the latest database updates from their central server and matches your OS better to prevent false positives.

rkhunter –update
I just got a false positive!! What do i do?

False positives are warnings which indicates there is a problem, but aren’t really a problem. Example: some Linux distro updated a few common used binaries like `ls` and `ps`. You (as a good sysadmin) update the new packages and run (ofcourse) daily Rootkit Hunter. Rootkit Hunter isn’t yet aware of these new files and while scanning it resports some “bad” files. In this case we have a false positive. You could always have your datacenter or a system administrator check out the server to verify that it is not compromised.

More information on rkhunter can be found here: http://www.rootkit.nl

1. SSH into your server as ‘admin’ and gain root access by su

2. Copy and paste this line to edit the file for SSH logins
pico -w /etc/ssh/sshd_config

3. Find the line
Protocol 2, 1

4. Uncomment it and change it to look like
Protocol 2

5. Next, find the line
PermitRootLogin yes

6. Uncomment it and make it look like PermitRootLogin no

7. Save the file Ctrl+X then Y then enter

8. Now you can restart SSH
/etc/rc.d/init.d/sshd restart

Now, no one will be able to login to root with out first loggin in as admin and ‘su -’ to root, and you will be forcing the use of a more secure protocol. Just make sure you remember both passwords!

1. Login to your server and su to root.

2. cd /root

3. pico .bashrc

4. Scroll to the end of the file then add the following:
echo ‘ALERT – Root Shell Access (YourserverName) on:’ `date` `who` | mail -s “Alert: Root Access from `who | cut -d”(” -f2 | cut -d”)” -f1`” you@yourdomain.com

Replace YourServerName with the handle for your actual server
Replace you@yourdomain.com with your actual email address

5. Crtl + X then Y

Now logout of SSH, close the connection and log back in! You should receive an email address of the root login alert a few minutes afterwards.