Author Archives: Jeroen Wierda

Changing some or all DirectAdmin related account passwords


In some cases, it may be necessary to change all account passwords on your DirectAdmin server. For example if  the server was compromised, or leaks that have been found (such as the recent openssl security holes), or an employee who has all the passwords has left the company. Changing all passwords on a server can be very time consuming, and for this I have created a PHP command line script that will facilitate automated password changes on several levels:

  • All DirectAdmin accounts (including the default e-mail address and FTP account for those accounts),
  • All custom FTP accounts,
  • All custom e-mail adresses.

The script also has options to change the password for:

  • Just one DirectAdmin account,
  • Just one e-mail- or FTP account,
  • All e-mail- or FTP accounts on one specific domain name.

Last but not least, the script also has a function that will generate a listing of the above without changing passwords, so that you have a list of for example all custom e-mail addresses on the server. The new password(s) can be automatically sent to the e-mail address of the DirectAdmin account holder, and a summary of all changes can be sent to a specified e-mail address.

If this script is executed by an admin user, then all accounts on the server can be affected by this script. If executed by a reseller, then only accounts that fall within his/her level of authority will be affected.

This script can be executed locally on a DirectAdmin server, but can also connect to (any) DirectAdmin server from a remote location. This is useful if you manage many DirectAdmin servers.


You can download the script from:

Make the script executable with:

[[email protected]]# chmod 550 da_changepass.php

And run it with:

[[email protected]]# ./da_changepass.php

If you don’t make it executable, you can still run it using:

[[email protected]]# php da_changepass.php

The script will also attempt to download the following required file (using curl) if it is not found in the same directory. But you can manually download it as well:


Before you start using this script, a few variables need to be updated. When done, change the $scriptedited variable to Y.

The variables below hold information about the target server. If any of this information is left empty, the script will ask for it. The $server_ssl parameter indicates if DirectAdmin is reachable over SSL.


The variables below tell the script what to, such as how long the newly generated passwords should be, from what characters the passwords should be constructed, if empty results (such as domain names without FTP or e-mail accounts) should be displayed, if a summary should be sent to an e-mail address specified in $sendsummaryaddress, and if an e-mail containing a new password should be sent to the holder of the DirectAdmin account whose password has been changed. The $adminuser variable contains the name of the admin account that is executing this script. This prevents updating the password of the user executing this script when –alluser is used. Otherwise the script would halt right after it changes the password of this user.

 $passlength = "10";
 $passchars = "[email protected]#$%^&*";
 $sendsummaryaddress="[email protected]";
 $mailfrom="[email protected]"; 

Make sure you have read every single variable above. The variables below indicate if mail should be sent via PHP’s internal mail() function, or via SMTP (will require PHPMailer script to be present). If you execute the script directly on the target server, you could suffice with just the mail() function. If you however execute the script on a central server from which you can manage multiple DirectAdmin servers, it would be wise to use the SMTP option to make sure that e-mail that is sent to users will not be blocked by blacklists or spamfilters.


If you enabled the $sendemailtouser variable, you may also want to update the 3 mailsubject/mailbody combinations, so that users who had a password changed will receive mail content that is customized for your company.

Once you have finished checking/updating the variables, it is strongly advisable to check the execution of this script against one or more test accounts to make sure that you get the results (and e-mail content) you expect to receive.

Script usage

    Change the password of one user:
       ./da_changepass.php --user <username> <optional password>
       If no password is given, a random one will be generated
    Change the passwords for all users except te admin user:
       ./da_changepass.php --alluser
    Change the e-mail password for all e-mail accounts on the server:
       ./da_changepass.php --allmail
    Change all e-mail passwords for a specific domain:
       ./da_changepass.php --mail <domainname>
    Change the e-mail password for a specific e-mail address:
       ./da_changepass.php --mail <e-mail address> <optional password>
       If no password is given, a random one will be generated
    Change the ftp account password for all ftp accounts on the server:
       ./da_changepass.php --allftp
    Change all ftp account passwords for a specific domain:
       ./da_changepass.php --ftp <domainname>
    Change the ftp account password for a specific account:
       ./da_changepass.php --ftp <[email protected]> <optional password>
       If no password is given, a random one will be generated
    Display a list of ftp or e-mail accounts:
       ./da_changepass.php --list <ftp | mail> <optional domain>

    Send a test e-mail:
       ./da_changepass.php --mailtest


This script is released in the hope that it will be useful, but without any warranty. If you have any questions about this script and/or its workings, don’t hesitate to comment on it. If you find this script useful and is saving you a lot of time, a small donation will be greatly appreciated :)

Bitcoin: 1PAaEhiZLDoMUNMuHsMWt7ow44tY3K7v2i
Litecoin: LUY1XXruLiJNY1kXq5oeX1uMWXKxBx3Cxh

Finding an e-mail spammer on your server

For years now, spam has been a nuisance that has plagued many internet users. Most people however, think that spam e-mail is being sent out by an actual person behind an actual computer, while in reality, these spammers (ab)use hacked e-mail/server accounts, or security holes within websites. Most server operators don’t even know that spam is being sent from their own server, until they receive complaints that bonafide e-mail from users on their server is not reaching the recipients, or they find out that their server IP address is suddenly located on blacklists. At that point, the hunt for the spammer is on, but how do you actually locate the spammer?

I work at a web hosting company, and see similar questions on a daily basis. A lot of people renting a VPS or dedicated server have no (or very little) actual server management knowledge, and rely mostly on the web hosting control panels (such as DirectAdmin), and the support desk of their server provider. This article offers several ways to find a spammer on your server, and does assume some basic linux knowledge such as how to use the command line (cli/ssh).


  • The server may slow down, and use more resources,
  • E-mail is not reaching its intended recipients,
  • Messages appearing in the DirectAdmin message log about a user having sent X amount of e-mail,
  • The Server IP address is located on one or more blacklists,
  • A user complains he is receiving a lot of bounce e-mail for e-mail he did not send.

Spam methods

Spammers have a variety of spam delivery methods available:

  • SMTP spam,
  • Hacked/abused web hosting account,
  • Perl script/server

With SMTP spam, the spammer has obtained the credentials of the e-mail account he is abusing. This is done through either brute-forcing (usually not successful if the password is difficult enough), or by malware that is installed on the actual computer(s) of the owner of that e-mail address. This type of malware either comes in the form of a key logger that logs your keystrokes and sends it to a central location, or malware that scans the computer for password files. A lot of people find the options that some (ftp, e-mail) software offer to automatically store your login credentials very convenient, but this is a major security risk that this kind of malware capitalizes on. These files are found, decrypted, and again sent to a central location where spam bots can abuse it. Once they have the login details, they can send out spam.

The hacked/abused web hosting account is also very common. Bots automatically scan websites for known security holes. This is particularly easy with websites running standard software such as WordPress, Joomla, and their plugins. Webmasters tend to not update their software, even though security risks are being discovered and fixed, or they are unaware of the risks. When a hole is identified by a spam bot, it is quickly abused by uploading a file containing malicious code through that hole, and executing it. A similar thing is done when malware locates the ftp credentials on a computer, uploads a file using ftp, and executes it through a web browser. With that latter method, the file is usually removed immediately after execution, making the hunt a bit more difficult.

The perl script/server method will not be covered in this article at this point, but may be at a later date.

Identifying spam

Identifying/locating a spammer is often difficult. Especially if you have a lot of users/domains on your server. There is very little you can do using the DirectAdmin panel, but it is still useful. The first is to open the “Message System”, which is located at the top/right of the standard DirectAdmin template. If you find recent messages like:

Warning: 600 emails have just been sent by <username>

Then that might be a spammer, or someone who has sent out a newsletter.

The other thing you can do within DirectAdmin is to open the “Mail Queue Administration”. If the Mail Queue Administration will not open due to timing out, you can be fairly certain that your server is being abused to send out spam. This means there are so many messages waiting to be sent out, that this page cannot be opened anymore. If however it does open, and you see a large number of pages you can click on, this also means there are a lot of messages waiting in the queue. If you see a lot of the same sender- or recipient addresses in that list, it may be wise to investigate a few of those e-mails by clicking on the mail ID to the right.

The best way to do this however, is by searching the mailserver (exim) logs, which are located in /var/log/exim. The most recent log inside that directory is called “mainlog“. It is possible to search this log using DirectAdmin’s “Log Viewer” which is located on the admin main page, and then selecting “Exim Mainlog“, however these logs can be “very” large, and therefore very slow to dig through using a web interface such as DirectAdmin. It may be more convenient to open the command line interface (ssh), which is the method I will expand on below.

The first thing I do when I login through ssh, suspecting spam, is to see how many e-mail is actually located in the mailqueue waiting to be handled (sent/received). To see this, type:

[[email protected]]# exim -bpc

This outputs a summary of the total amount of e-mail that is sitting in the mailqueue, and is totalling over one million in this example. The server in this example is most definitely sending out spam.

Next, move to:

[[email protected]]# cd /var/log/exim

There, type:

[[email protected]]# cat mainlog |more

Just “more mainlog” is also possible. If the dates in front of the log lines are old (e.g. much more than a day), then try this:

[[email protected]]# tail -n 10000 mainlog |more

The 10000 number is the last number of lines to start displaying. You can tweak this around by modifying the numbers. I sometimes have to change it to 150000 or more before I see some sensible data, because when the spamrun has been active for a while, the bounces start to appear very fast, which clutter the log. You can press the space bar to scroll downward through the log. You may find something like:

2013-12-28 23:48:27 1Vx2g2-0001EU-Cq ** [email protected] F=<> R=lookuphost T=remote_smtp: SMTP error from remote mail server after  RCPT TO:<[email protected]>: host []: 550-5.1.1 The email account that you tried to reach does not exist. Please try 550-5.1.1 double-checking the recipient's email address for typos or 550-5.1.1 unnecessary spaces. Learn more  at 550 5.1.1 l2si45202725een.62 - gsmtp
2013-12-28 23:48:27 1Vx2g2-0001EU-Cq Frozen (delivery error message)

Which is a bounce e-mail. You will almost always find bounces in the log, also from bona fide users, but if you see a whole lot for the same destination address on your server ([email protected] in this example), then you can write down that address to scan on that specific address later.

Something else you may find in the log:

2013-12-29 00:00:47 1Vqqlt-0002LF-0d ** [email protected] F=<[email protected]> R=lookuphost T=remote_smtp: SMTP error from remote mail server after initial connection: host []: 554 Your access to this mail system has been rejected due to the sending MTA's poor reputation. If you believe that this failure  is in error, please contact the intended recipient via alternate means.

Lines like this show that you are being blacklisted, and may come in many different forms depending on the provider and type of blacklist. Bona fide mail may generate lines like this if your server IP address is on blacklists.

The following are the type of lines you may be looking for:

Example A

2013-12-27 11:34:51 1VwUkl-0006D4-Co <= [email protected] U=apache P=local S=3436 T="R0L3x AND v14rga" from <[email protected]> for [email protected] 2013-12-27 11:34:52 1VwUkl-0006D4-Co => [email protected] F=<[email protected]> R=lookuphost T=remote_smtp S=3576 H= [] C="250 2.0.0 Ok: queued as E19AA22B0173"
2013-12-27 11:34:52 1VwUkl-0006D4-Co Completed


Example B

2013-12-27 20:36:10 1VwdCb-0001ze-5c <= [email protected] H=([]) [] P=esmtpa A=login:[email protected] S=100156 [email protected] T="FREE MONEY EVERYDAY - £1 MILLION IN UNDER 7 YEARS" from <[email protected]> for [email protected]

Example A shows “U=apache“, which means that the e-mail was sent using the web server. If the website (or server) is running suphp or mod_ruid2, then the website is not executed as apache, but the username. In that case you may see “U=dauser“, which in this example is the DirectAdmin username for this specific user. “T=” is the e-mail subject, which is usually very obviously spam. However, there are cases where it may look legitimate such as “Scheduled Home Delivery Problem”, but if you find a large number of the same subject types sent by the same user, combined with a lot of bounces, it is likely spam.

Example B shows “P=esmtpa“, which means it was sent using SMTP, which is the exim mailserver. The sender IP is shown as “H=([]) []” and the e-mail account that was used to send it is shown at “A=login:[email protected]“. This is again a very obvious spam subject which you can see in “T=“, and you may find a large number of those in the log, from the same user. However, the part in “from <[email protected]>” may in some cases actually show a completely unrelated and foreign address. The reason for that is that it is very easy to fake a source e-mail address, so the spammed users will not easily know that it came from your user’s  domain name, unless they look at the e-mail headers.

Once you have identified (or suspect) a possible spammer, you could re-scan the log using just the e-mail address, or username (I use tail here to scan the last part of the log, but you can substitute “tail -n 10000” with “cat” to start from the beginning):

[[email protected]]# tail -n 10000 mainlog |grep [email protected] |more


[[email protected]]# tail -n 10000 mainlog |grep user |more

or to get all the details regarding a specific mail ID:

[[email protected]]# cat mainlog |grep 1VwdCb-0001ze-5c

or all lines with a specific subject (grep’s -i flag for case-insensitive search):

[[email protected]]# tail -n 10000 mainlog |grep -i "FREE MONEY EVERYDAY" |more

To show a list of e-mails sitting in the queue you can also do:

[[email protected]]# exim -bp |more

The |more part pauses the list, which is a must if there are a large number of e-mails waiting. You will probably find many occurrences of the spamming e-mail address in that list. To show some more detailed information, you can query a single e-mail with:

[[email protected]]# exim -Mvh 1Vx7MK-0007RR-Re

Where the last part is the e-mail ID. This may output something like:

198P Received: from apache by with local (Exim 4.72)
(envelope-from <[email protected]>)
id 1Vx7MK-0007RR-Re
for [email protected]; Sun, 29 Dec 2013 04:48:12 +0100
038  Date: Sun, 29 Dec 2013 04:48:12 +0100
057I Message-Id: <[email protected]>
030T To: [email protected]
051  Subject: Exper tP harma cy
059  X-PHP-Script: for
028F From: [email protected]

The “from apache” part shows it was sent using the webserver, and the “X-PHP-Script” part shows which script was used to send it. This is especially useful to find the location of the possible spamscript on your server.

If the e-mail was sent using SMTP, the solution is very easy. You can then simply reset the compromised e-mail address’ password and inform the user that his/her credentials were found, and that the user needs to scan his personal computer for malware. If the spam was sent using the webserver, then a temporary solution is to suspend the user’s web hosting account, which will prevent it from adding any new spam e-mails to the mailqueue. You can then try to find the script that is used to send out the spam.

Finding a spamscript

Locating the script that was used to send out the spam can be difficult, especially if the compromised web hosting account has a lot of files. The “X-PHP-Script” shown in the previous example is not always there, and in that case you will have to hunt for it manually. Also, there may be more than one (spam)script, especially if the user is running very outdated software, and has been doing so for quite a while. Such site may be hacked over and over again by many different bots.

One thing you can do is scan for base64 encoded code, which is still very popular. Such code is immediately executed using php’s eval() function. To search for that, go to the user’s public_html (or private_html) directory:

[[email protected]]# cd /home/username/domains/

Where username is the username of the DirectAdmin user, and is his/her domain name. Then type:

[[email protected]]# find . -name '*.php' | while read FILE; do if grep 'eval(base64_decode' "$FILE"; then echo "$FILE" >> maybeinfected; fi ; done

This code snippet searches through all .php files for the “eval(base64_decode” code, and if found, stores the location of that file inside a file with the name “maybeinfected”.  To not store it in a file, but output it to the console instead:

[[email protected]]# find . -name '*.php' | while read FILE; do if grep 'eval(base64_decode' "$FILE"; then echo "$FILE"; fi ; done

You can substitute “eval(base64_decode” for any other string, such as “eval(gzinflate(base64_decode“, which may also be used.

A more simplified way to search for the same string:

[[email protected]]# grep -r "eval(base64_decode" . |more

This will basically do the same thing, but also presents you with the whole line of code for every file it finds. The “-r” flag means it is a recursive search which traverses all directories and files in the path you specified. You can also add a “-i” flag for case-insensitive searches.

If you know when the spamming started, you can also check for files that had a status change within the last X days:

[[email protected]]# find . -type f -user apache -ctime -3 |more

Where “-user apache” reads as “users owned by apache”, which can be removed if you want to search for all owners, and the value after “-ctime” is the number of days ago to start from, which is in this case 3 days. This will produce a file listing that will almost certainly also show innocent files. However, you will probably see a few files that have strange filenames (x.php, 424.php, sys2674123.php, etc), which you may want to investigate further.

You can also substitute the dot (.) in the above examples with a full path name, including a wildcard (*) to search through more directories such as:


Where the first * is a wildcard for all users (you can add a username there to narrow the search), and the second wildcard is for all domains.

Note though that removing the infected scripts may only be a temporary solution, because if the user is running outdated software, chances are high to 100% that this will happen again.

Emptying the e-mail queue

You will probably want to empty the mailqueue, so that the thousands (or in some cases millions) of messages that are waiting to be sent or delivered, are no longer being handled. This can be done in several ways:

[[email protected]]# exim -bp | awk '{ print $3 }' | xargs exim -Mrm

This will empty the complete queue including any bona fide e-mails. Though this may not be what you want, it is the fastest way to empty the queue, especially if there are over a million e-mails inside it. Even though it is the fastest way, it may still take a very long time to complete.

To only delete the spam e-mails:

[[email protected]]# exiqgrep -i -f [email protected] |xargs exim -Mrm

You can also substitute [email protected] with just Another way to remove only the spam e-mails:

[[email protected]]# exim -bp | awk '/<[email protected]>/ {print $3}' | xargs exim -Mrm

There are more ways to do this than just the above examples. After the operation has completed, you can check how many e-mails are left in the queue:

[[email protected]]# exim -bpc

If you still see many messages, then chances are that those messages are “frozen”. To remove those:

[[email protected]]# exipick -zi | xargs exim -Mrm

Sometimes, even then you are left with a large number of e-mails sitting in the mailqueue. Trying to empty the queue may result in an error like:

[[email protected]]# exim -bp | awk '{ print $3 }' | xargs exim -Mrm
exim: malformed message id <[email protected]> after -Mrm option

This can be fixed with by first obtaining the e-mail ID the removal is stopping at:

[[email protected]]# exim -bp | exiqgrep -i
Line mismatch: 50h       1VwxAB-0005m5-7R <[email protected]>

And then removing that e-mail from the queue:

[[email protected]]# exim -Mrm 1VwxAB-0005m5-7R

You may have to do this several times if there are more malformed e-mails in the queue. After that, you can retry emptying the queue.

When all is done, you should not see many messages waiting in the queue anymore.


There are many ways to solve these spam issues, and this is also not a definite guide. One of the things you may also do in case the webserver is used to send spam, is to check the FTP logs to see if the scripts were stored that way, but information about how to do that is not (yet) part of this article.  If, after reading this article, you have any improvements, then let me know so this article can be updated.

DirectAdmin command line tasks (dataskq).

DirectAdmin has quite a few tasks that can be handled using the Command Line Interface by saving an action to “/usr/local/directadmin/data/task.queue“. These tasks are then executed by dataskq, which is invoked by cron every minute. Once the task is done, the task.queue file is removed. Some useful actions can be found below, and are the actual commands you need to type on the command line. If you do not want to wait for cron to start dataskq after you “echoed” something to the task.queue file, then you can also invoke it manually by typing:

[[email protected] /]# /usr/local/directadmin/dataskq

Note that some tasks (for example a full tally) can take quite a long time on servers that hold a lot of users. You can usually see some progress by watching the “top” command, to see if the dataskq process is still running. This article will expand on only the dataskq tasks. Other command line options will be discussed in a future article.

License and DirectAdmin tasks:

Update License:
[[email protected] /]# echo "action=update&value=license" >> /usr/local/directadmin/data/task.queue
Update DirectAdmin:
[[email protected] /]# echo "action=update&value=program" >> /usr/local/directadmin/data/task.queue

In case the license is no longer working, you can obtain a new license file by going to:

[[email protected] /]# cd /usr/local/directadmin/scripts/

And typing:

[[email protected] /]# sh 1234 9876543

Where the first number is your client ID, and the second number is the license ID. After that, you may need to restart DirectAdmin:

[[email protected] /]# service directadmin restart


The nightly tally is usually invoked by cron during the night, and updates the user/domain statistics such as how much bandwidth and diskspace is used, as well as the awstats or webalizer statistics. The tally can also be invoked manually by typing:

[[email protected] /]# echo "action=tally&value=all" >> /usr/local/directadmin/data/task.queue

If you have a lot of users on your DirectAdmin system, then the tally can also be run for just one user:

[[email protected] /]# echo "action=tally&value=username&type=user" >> /usr/local/directadmin/data/task.queue

Substitute “username” for the actual directadmin username that needs to be updated.

The tally can also run for a whole reseller and all users under his/her control:

[[email protected] /]# echo "action=tally&value=resellername&type=reseller" >> /usr/local/directadmin/data/task.queue

Substitute “resellername” for the actual directadmin reseller that needs to be updated.

Apache restarted by Tally:

The tally does run every night, and one of the steps included in this tally is to restart apache. This can in some cases have an adverse effect (e.g. downloads being broken off). To remedy this, you can instruct DirectAdmin to do a graceful restart. To enable this, edit the directadmin.conf file:

[[email protected] /]# nano /usr/local/directadmin/conf/directadmin.conf

And change the “graceful_restarts” option to 1 (or add it if it is not already there):


Save the config file, and restart DirectAdmin.

Tally frequency:

The default value is to make it run at 10 minutes after midnight. It is also possible to make the tally more run frequently than that, by editing the crontab that invokes the tally. This can be found in “/etc/cron.d/directadmin_cron”. When you edit this file (though nano can be used, it is best practise to use vi for this), it will display a few DirectAdmin tasks. Edit this one:

10 0 * * * root echo ‘action=tally&value=all’ >> /usr/local/directadmin/data/task.queue

10 0 means it runs every day at 10 past midnight. You can change it to for example 10 */12 to make it run every 12 hours:

10 */12 * * * root echo ‘action=tally&value=all’ >> /usr/local/directadmin/data/task.queue

After you are content with the changes, you can save the file and restart crond:

[[email protected] /]# service crond restart

After every 1st of the month at 4:20 am, DirectAdmin resets the monthly bandwidth totals. This can also be run manually for the whole system or a single user:

Bandwidth Resets

Monthly Reset:
[[email protected] /]# echo "action=reset&value=all" >> /usr/local/directadmin/data/task.queue
Reset one User:
[[email protected] /]# echo "action=reset&value=username&type=user" >> /usr/local/directadmin/data/task.queue

Substitute “username” for the actual directadmin username that needs to be updated.

An interesting article about what to do when the bandwidth does not reset:

Httpd config files rewriting

Sometimes it is useful to rewrite the httpd config files for all users. For example if you made a mistake somewhere, or made changes to the httpd templates. This can be done with:

[[email protected] /]# echo "action=rewrite&value=httpd" >> /usr/local/directadmin/data/task.queue


Show all Users cache

Sometimes (rare cases) the values on the Show all Users page are not correct (or not populated). To save server resources, the data on the Show all Users page is cached data. That is stored in the following file:


This file can also be safely removed, which will cause DirectAdmin to display the Show all Users content manually until it is either automatically recached or you recache it manually.

To recache the ‘Show all Users’ page:

[[email protected] /]# echo "action=cache&value=showallusers" >> /usr/local/directadmin/data/task.queue

To recache a user in the ‘Show all Users’ page:

[[email protected] /]# echo "action=cache&value=showallusers&user=username" >> /usr/local/directadmin/data/task.queue

Substitute “username” for the actual DirectAdmin username that needs to be updated.

Making Backups

Even backups can be run using the command line. It is usually easier to do using the “Admin Backup/Transfer” option in DirectAdmin’s Graphical User Interface (GUI), but there are instances where this interface is not or no longer available. Such as when your license is invalidated, or somehow the server has become so corrupted that the GUI is no longer available. The commands below assume you have enough space on the server’s hard drive to store the backups.

To make a backup of ALL users:

[[email protected] /]# echo "action=backup&local%5Fpath=%2Fhome%2Fadmin%2Fadmin%5Fbackups&owner=admin&type=admin&value=multiple&when=now&where=local&who=all" >> /usr/local/directadmin/data/task.queue

This can be hard to read due to the hex encoded slashes (%2F) and underscore (%5F), which are needed. The backup location in this example is filled in after the “path=”, and is /home/admin/admin_backups (%2Fhome%2Fadmin%2Fadmin%5Fbackups). No other values need to be changed.

Similar to the above example for all users, a backup can also be made for just one user:

[[email protected] /]## echo "action=backup&local%5Fpath=%2Fhome%2Fadmin%2Fadmin%5Fbackups&owner=admin&select%30=username&type=admin&value=multiple&when=now&where=local" >> /usr/local/directadmin/data/task.queue

Again, the path after “path=%2F” is the location for the backup file, and the value after “select%30=” is the username to be backupped.

If cron is no longer working, then the dataskq process to run the backup can be run manually by:

[[email protected] /]# /usr/local/directadmin/dataskq d200

Where d200 is Debug Level 200, which gives you some visible information on your console.


There are more tasks that can be fed to the task.queue file, and I may expand on this article at a later date. There are also many more tasks, not related to dataskq, that can be done using the command line. I will create a separate article for that.

E-mail alert when a successful root login occurs

I find it very useful to receive alert notifications via e-mail whenever a successful root login occurs. This will make sure that you are notified immediately (you can link the e-mail address to a mobile sms service) whenever someone logs in. This can be done very easily in several ways after logging into the CLI (Command Line Interface) as root:

[[email protected] ~]#

Method 1:

Next, edit the .bashrc file (I prefer nano over vi for simplicity):

[[email protected] ~]# nano .bashrc

Add the following line to the end of the .bashrc file:

echo -n 'ALERT - Root Shell Access (servername) on:' `date` `who` | mail -s "Alert: Root Access from `who | cut -d"(" -f2 | cut -d")" -f1`" [email protected]

Substitute “servername” and “[email protected]” for your servername and e-mail address, and save the file. This also works for other shell accounts on the system when you modify the shell user’s .bashrc file.

Method 2 (I prefer this one):

Go to the .ssh directory:

[[email protected] ~]# cd /root/.ssh

Create a file named “rc”:

[[email protected] ~]# nano rc

Add the following line to the newly created rc file:

echo -n 'ALERT - Root Shell Access (servername) on:' `date` `who` | mail -s "Alert: Root Access from `who | cut -d"(" -f2 | cut -d")" -f1`" [email protected]

Substitute “servername” and “[email protected]” for your servername and e-mail address, and save the file.

At some point I will write up a (new) server security checklist that will also include this tip.