In this series of Best Practice articles I talk about migrating websites and emails from a Plesk 11 run server to a Virtualmin run server. It describes in details the steps involved, including the eventual pitfalls and other thing I came across whilst doing it. Note that this documentation is addressed to people with medium expertise in linux/system administration.

Useful customisation

Most of VM defaul settings are fine, however in order to make it a little easier to migrate websites, the following mods are useful.

Server Template – Apache directives

As Plesk websites are hosted under $Documentroot/httpdocs this can be set by default before creating website by editing the Apache website default config:

VM Menu > Server Templates > Default Settings > Edit template section: apache website

Change: DocumentRoot ${HOME}/public_html
To: DocumentRoot ${HOME}/httpdocs

Change: <Directory ${HOME}/public_html>
To: <Directory ${HOME}/httpdocs>

Under “Users’ website subdirectory to create“.

Change: Default (public_html)
To: Directory under home [httpdocs]

Account Plans

One may customise them to match previous Plesk hosting “plans”, however this is not mandatory.

Virtual website creation – Admin username

The only requirement in this process is to create the Administration username as a “Custom username” giving it the domain.tld name (i.e. mydomain.com). This way the websites paths will end up being: /home/domain.tld, which makes it easier to do a path change from /var/www/vhosts to /home wherever there are scripts configurations containing full paths.

Perl

I am a perl script writer thus I use perl extensively, over the years I have created scripts that require a few additional modules. I shall not go into details with them (yet), however there’s an important bit I must mention, some perl scripts I use have a different #!. Some point to the sometimes non-existent /usr/local/bin/perl, so in order to avoid these script throwing an error I simply link it to the whereis perl (usally /usr/bin/perl or /bin/perl):

ln -s /usr/bin/perl /usr/local/bin/perl

Website content transfer

To transfer website content from Plesk to VM it is a matter of rsyncing each website with the rsync command,  to minimise the load, the following commands are run at nice 20 from the source server, note that the target server must have the virtual server already configured prior to doing this, otherwise an error will be thrown:

rsync -avz --rsh='ssh -p{port}' /var/qmail/mailnames/{domain}/{user}/  root@{server}:/home/{domain}/homes/{user}/

Where:

• port is the ssh port (if different than 22, which is recommended for security)
• domain is the domain to be transferred
• target is is the target server IP or domain

Depending on the size of the website this might take some time. Note that I am not really needing to transfer statistical information over. most if not all the required files are under httpdocs and cgi-bin in my case.

After the transfer, on the target server, ownership of the directories must be set:

chown -R {username}:{username} /home/{domain}/httpdocs /home/{domain}/cgi-bin

Where:

• username is the owner of the httpd and cgi-bin content (in my case I created a username matching the domain, making it easier to find the correct directory under /home when working over the CLI.
• domain is the domain

Email content transfer

The operation of transferring emails to the target server are pretty much the same as website transfer, with a couple of exceptions.

nice -20 rsync -avz --rsh='ssh -p{port}' /var/qmail/mailnames/{domain} root@{target}:/home/{domain}/home/

Where:

• port is the ssh port (if different than 22, which is recommended for security)
• domain is the domain to be transferred
• target is is the target server IP or domain

After the transfer, on the target server, ownership of the directories must be set:

IMPORTANT: note user is user.domain (not just domain)

chown -R {user}.{domain}:{domain} /home/{domain}/homes/{user}/

Where:

• user is the name of the user
• domain is the name of the domain

IMAP changes (At client level, here using Thunderbird)

Server name: no change
Username: replace @ with .
Connection security: from SSL/TLS to STARTTLS
Authentication method: from encrypted password to normal password

SMTP changes (At client level, here using Thunderbird)

Server name: no change
Port from 25 to 587
Connection security: from SSL/TLS to STARTTLS
Authentication method: from encrypted password to normal password
Username: replace @ with .

Database content transfer

Source server

mysqlcheck --optimize {database} --auto-repair  -uadmin -p`cat /etc/psa/.psa.shadow`
mysqldump -uadmin -p`cat /etc/psa/.psa.shadow` --flush-logs --opt {database} > {database}.sql

Where:

• database is the database name

Target server (after rsyncing all the dbs dumps on it)

VM Menu > Edit Databases > (manage current database usually called {domain}_{tld}) or create a new one if required.
click Manage …
Click Execute SQL
Run SQL from file Tab
From local file (browse to file)
Click Execute

Special characters

Sites  with accents (like French’s)

The charset must be edited in the following Module:

Select Domain > Menu > Services > Configure Website > Languages >  Character set for documents     (x) iso-8859-1

Save, apply changes.

In this series of Best Practice articles I talk about migrating websites and emails from a Plesk 11 run server to a Virtualmin run server. It describes in details the steps involved, including the eventual pitfalls and other thing I came across whilst doing it. Note that this documentation is addressed to people with medium expertise in linux/system administration.

Fed up with Plesk?

Since  2003 I have been using two brands of Dedicated Servers Control Panels: Ensim (RIP) and Plesk. So it’s died oh well, Ensim was an awful CP, never liked it, I liked Plesk (from 8 to 11) a bit more and it has been my selected Control Panel for many years. However the time has come to make way for a relatively new comer: Virtualmin or VM for short, a very mature and simpler CP indeed with a vibrant Community.

Deciding to select another Control Panel is a big decision, especially when your bottom line is at stake, so after having extensively tested and used VM for the last few months I finally decided to make the move, VM is slick, simple and easy to use, it’s like Ronseal, it does what it says on the tin.

Plesk who it is really for?

Less and less for me as I do not resell nor hosts 1000′s of websites, Plesk is probably best for that. However the latest incarnation of Plesk (at least as it was given to me by my service provider) is getting a little too much, some menus about “Business Management” which may be well made but I didn’t get the chance to try, it didn’t work and some serious problems with email servicing [off topic]not to mention all my scripts using sendmail.pm were denied access to smtp locally, apart for a few minutes when I changed the server var to the local IP, then it failed again, DC has no ideas!)[/off topic].

Most of my customers websites are not accessed via ftp often (the port is opened to a select few) all is done via web interface.

Virtualmin

I stumbled upon Virtualmin by accident, I knew Webmin from many years ago and never really saw what to use it for, I then got a very cheap VPS with Ubuntu 11.10 (I am on now 12.04 writing this) and sourced Webmin to play about. It turned out that I should have not installed Webmin first but Virtualmin which is mentionned on webmin.com, installing Webmin before Virtualmin messed up.  So I reset the VPS with the recommended OS of the day (CentOS 6 64) and installed Virtualmin via their archive.

Benefits of VM

The main benefits of Virtualmin, in my opinion, are as follow:

• Free
• Speedy community support
• Does not interfere with the native OS
• Good Integration with csf Firewall and Cpan and whatever else.
• Fast, uncluttered Interface
• Simpler Website / Email / User management (I don’t do resellers etc.)
• Direct access to the rest of the appliance with via Webmin
• Entirely customisable, add/remove edit any of the many, many available modules

Virtualmin install is a breeze, simply download the archive, unpack it and invoke the install.sh script, the rest is childs play. The OS of choice for me is CentOS 6 64 which is ready to be used with Virtualmin pretty much out  of the box.

Decisions, decisions

Migrating to VM from Plesk brings its own set of challenges, the main one is the websites “DocumentRoot”; Plesk puts everything in /var/www/vhosts, VM is a /home matter. So before migration it is to be decided whether set VM to have DocumentRoot pointing to /var/www/vhosts or keep the default, this could cause potential suexec conflicts, so I decided to leave VM with the default (/home). So the first thing to think about is to replace all absolute paths in all scripts (if any) from /var/www/vhosts to /home, second, a bog standard import of Plesk backups to VM, although the simplest and fastest way, causes major headaches; Plesk stores websites under /var/www/vhosts/domain.tld but VM [rightly] stores them under /home/username, where username is Plesk’s ftp credentials to log onto each websites, so unless you rename all ftp users to domain.tld in Plesk… this means that a Plesk backup import can be a bit of a headache.

If, like me, you’ve got a few dozen websites, the decision is to create all websites in VM manually with the administrative user name as the domain name (like example.tld) is what I will go for (you can always add the old Plesk username as a secondary account for your ftp customers if required).

In this series of best practice articles I talk about migrating websites and emails from a Plesk 11 managed server to a Virtualmin managed server. It describes in some details the steps involved in doing it remedy the pitfalls and other thing I came across whilst doing it. Note that this documentation is address to people with medium expertise in linux/system administration.

Hardware

A fresh install of a super fast multi-core web server with sufficient RAM and [Hardware] RAID 1 partitioned as follow:

• / = 12GB
• /swap => RAMx2 (recommended) however I set it to RAMx1 as the RAM rarely “swaps”.
• /var = 1/2 of the rest of the space
• /home = 1/2 of the rest of the space.

As I have a few websites to run, a 250GB HDD was my choice, so /var and /home are about 100GB each which gives me more than enough space for the moment, bearing in mind that one can always increase this easily by swapping bigger RAID mirrors one after the other followed by a quick partition resize.

Partitions allocation

I chose to split /var and /home from / because:

1. /home will contain all the websites and emails
2. /var usually contains log files, firewall, partition, users information etc.
3. /var will contain an image backup of /home and / (I am planning to use hot copy)

Backup

The RAID 1 disk setup pretty much solves the “disk failure” challenge, but not data loss due to human error (or otherwise). So a solid backup strategy is essential. My plans are currently to have an image snapshot made of the bare server before adding websites, to do this I have been quite impressed by the backup products from Idera, more particularly “Server Backup” which is free with some disabled features (like remote backups management), however I feel it might be a little too much for me, I really need a simpler interface to use, that is why I was initially interested in their “Hot Copy” product, which I haven’t tested yet. With Hot copy, I would take a snap shot of /home on /var and vice versa which I would then upload to a backup server. Simple and neat.

Providing that Hot Copy does not interfere with the OS too much (I like the OS to remain “as is” to avoid conflicts (like Plesk has recently given me with Emails refusing to be send using Qmail, only Postfix worked, one of the reason I give up on Plesk. Too much interfering).

Initial Steps

The very first thing to do on a brand new server is:

1. Check that the IP address [range] is not Blacklisted for sending spam
2. Set the hostname and Reverse (PTR) pointer accordingly
3. Install rkhunter and run it with

   rkhunter -c --update --propupd

4. Change SSH port and activate passwordless authentication
5. Install Virtualmin and customise the Directoryindex directive and the Primary Default Website you may also do additional customisation outlined here (page to be created)
6. Install Configserver’s csf and use their security checker to harden the appliance
7. install hotcopy more about what to do here (<to be written)

 Non essential installs (but recommended)

In addition to the above minimum installs. Here are a few more things that, I reckon is a good idea to have:

screen

Screen is a great app when working with ssh, it allows you to close your terminal window without losing your remote session, screen “attaches” terminal window to your terminal and “detaches” itself when you close your window (or your office internet connection drops for whatever reason), this is particularly useful when you don’t want to leave your terminal opened when a long process is being run (like a backup etc.).

tree

tree is used by one of my perl scripts to do fast, recursive line replacements in files within a directory.

Use yum to install any additional applications, like:

yum install screen tree

Server stats – Munin

I used to have HotSaNIC on my previous dedicated, however since this application is over 10 years old now, it’s a little arduous to install. After having tested two alternatives, namely Nagios and Munin, I went for Munin.

Munin is exactly like Hot Sanic but with more graphs than you can shake a stick at. However installing Munin on Centos 6 is not a straight forward thing, an additional (epel) repository the must be added.

cd ~
wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
rpm -Uvh ~/epel-release-6-8.noarch.rpm
yum install munin munin-node

Important!: The Epel repository must be disabled after the install otherwise Virtualmin updates incompatible packages resulting in some application no longer working

To disable the epel repository, edit /etc/yum.repos.d/epel.repo and change enabled=0 to 1 under the [epel] section:

[epel]
....
enabled=0 #(was 1)
...

Normally Munin installs everything pretty much as it should, all I had to do is create a username login and password (below the username is Munin, but it could be anything, like admin, joe etc.):

htpasswd -c /etc/munin/munin-htpasswd Munin

The default location for the Munin graphs are under /var/www/html/ (VM default), to enable access to this folder, this httpd.conf hack must be done. Otherwise the munin.conf must be changed accordingly.

Start Munin at boot

Munin does not start at boot by default, this is why it must be enabled with:

chkconfig munin-node on

Post install snags

Once all the above is installed it’s time to run some tests. To this end it is best to create a virtual server to check all is working as it should, in my case, it almost always involves the hostname and email (Postfix) service.

Issue 1: Setting a hostname up

The most important aspect of a web server, yet the bit that always catches everyone with little experience in the field. In a brand new server, the hostname can be anything the Sysadmin has decided to use by default for its server pool install. So it must be changed.

The command to check the current hostname is:

# hostname
somename

Where “somename” is the current name of the host that needs changing

To set a new hostname and make it coherent for the appliance, two files must be edited:

• /etc/hosts
• /etc/sysconfig/network

/etc/hosts

The default entries in /etc/hosts are usually:

127.0.0.1   localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost.localdomain localhost6 localhost6.localdomain6

A third line must be added with the hostname and IP address (i.e. hostname = some.domain.net & IP = 111.222.001.111):

127.0.0.1   localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost.localdomain localhost6 localhost6.localdomain6
111.222.001.111 some.domain.net

/etc/sysconfig/network

The other file is /etc/sysconfig/network which should look like:

NETWORKING=yes
HOSTNAME="some.domain.net"

Where “some.domain.net” is your Fully Qualified Domain Name (FQDN)

The above will not be taken in consideration immediately but after a reboot, to avoid rebooting and set the hostname immediately simply type:

hostname some.domain.net

Issue 2: Postfix and SMTP

I always have trouble with emails, it’s a total mystery to me as to why it should be so much of a pain in the backside to get working. There’re almost always problems with email service! (at least for me).

Summary of possible problems

In my latest install here are the errors reported by Virtualmin I encountered:

1. postfix: fatal: parameter inet_interfaces: no local interface found for {IP address here}
2. The procmail command /usr/bin/procmail is owned by group mail, when it should be owned by root. Email may not be properly delivered or checked (….)
3. The sending of emails via SMTP (SSLTLS/plain password on port 587) was timing out.
4. Automatic BCCing of outgoing email cannot be enabled unless a BCC map is defined in the Postfix Mailserver module, or manually in the Postfix configuration file. Otherwise it must be turned off on the module configuration page.

Below are the lines that needed replaced (or added) to sort issue 1 to 3 – stop postfix first!:

Note that a backup of any files before editing is RECOMMENDED. In my case I did a hotcopy first .

For /etc/postfix/main.cf:

inet_interfaces = localhost 
changed to >>
inet_interfaces = all
---
mailbox_command = /some/where/procmail 
changed to >>
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME

Added:
======
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination
mailbox_size_limit = 0
allow_percent_hack = no

For /etc/postfix/master.cf:

smtp      inet  n       -       n       -       -       smtpd
changed to >>
smtp  inet    n       -       n       -       -       smtpd -o smtpd_sasl_auth_enable=yes
---
Added :
=======
submission    inet    n       -       n       -       -       smtpd -o smtpd_sasl_auth_enable=yes

Note: the above provided for info only, no responsibility held in any events, I had tried just about everything when I recalled that I luckily had a fully operational VPS from which I simply copied the master.cf and main.cf without forgetting to change the “mydestination” option to the correct hostname, it did the trick.

Below is the changes made to fix issue 4:

Automatic BCCing of outgoing email cannot be enabled unless a BCC map is defined in the Postfix Mailserver module, or manually in the Postfix configuration file. Otherwise it must be turned off on the module configuration page.

In VM Go to Webmin > Servers > Postfix Mail Server > BCC Mapping and set the Sender BCC as follow (mine was “No Map Set”):

Once all is set as it should a nice message from VM:

.. your system is not ready for use by Virtualmin.

After scouring the Net for some inspiration, which failed, and some tinkering, I finally found a neat solution to switch between the two (passwordless and normal authentication logins) quickly, the process is relatively simple* but frankly puzzling IMHO. I shall explain why:

By default, most sshd_config files state:

#PermitRootLogin yes

Which is meant to be the “default” because it is commented out. This line matters little when PKI is in use. However it seems that it is not the case [the default being "yes" as it is commented out] as if I specifically uncomment the line:

PermitRootLogin yes

…and restart the sshd service, I can login the server with the following command:

ssh -o PubkeyAuthentication=no root@host

If the line is “defaulted” (with a#). I am unsuccessful :-(

Plesk Migration (or other applications requiring password ssh)

So, when an application like the Plesk Migration & Transfer Manager requires a ssh username/password pair, under the current [passwordless] set up just edit the sshd_config file to change the following:

PubkeyAuthentication yes

to:

PubkeyAuthentication no

restart sshd afterwards and you’re good.

*This set up is on a centos 6 64

After some research it turns out that I am running clamd with user clam instead of clamav. Yet yum upgrades clam with the user clamav and other directories in the configuration;

In short here is what I experienced after the upgrade (these must be changed back into the /etc/clamd.conf file):

• The user changed from clam to clamav
• The initial path to /var/lib/clamav changed to /var/clamav

The initial user (clam) was changed for the /var/run/clamav to clamav, this folder and it’s content have to be chow’ed back to clam

After this I was able to start clamd again.

Typical errors when trying to start clamd:

service clamd start
Starting Clam AntiVirus Daemon: LibClamAV Error: cli_loaddb(): No supported database files found in /var/clamav

service clamd start
Starting Clam AntiVirus Daemon: ERROR: Can't open /var/log/clamav/clamd.log in append mode (check permissions!)..

service clamd start
Starting Clam AntiVirus Daemon: ERROR: Can't open /var/log/clamav/clamd.log in append mode (check permissions!). ERROR: Can't initialize the internal logger

By design this is normal

Whilst this is the way Apache is designed and there’s nothing wrong with that, it becomes a problem when some applications are only available outside the virtual server realm (i.e. not suexec’ed). For example the server has Nagios or Munin installed and you want to be able to access it even after a virtual server has been created. The solution is to manually create the first virtual server and call it the same as the server hostname (some.domain.com).

Example of a manually edited httpd.conf

Below is an example of the content of my current config file, the domain have been renamed to protect the innocents. Note that this must be the first Virtual Server. (to make things easier, I first created a virtual server and used it as a template, this server was then deleted)

#### DEFAULT virtual server - edited by Gilbert
#### Port 80
<VirtualHost 001.008.003.126:80>
ServerName some.domain.com
DocumentRoot /var/www/html
ErrorLog /var/log/error_log
CustomLog /var/log/access_log combined
ScriptAlias /cgi-bin/ /var/www/cgi-bin/
DirectoryIndex index.html index.htm index.php index.php4 index.php5
<Directory /var/www/html>
Options -Indexes +IncludesNOEXEC +SymLinksIfOwnerMatch +ExecCGI
allow from all
AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
</Directory>
<Directory /var/www/cgi-bin>
allow from all
AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
</Directory>
IPCCommTimeout 31
FcgidMaxRequestLen 1073741824
</VirtualHost>
#### End port 80
#### Port 443 (SSL)
<VirtualHost 001.008.003.126:443>
ServerName some.domain.com
DocumentRoot /var/www/html
ErrorLog /var/log/error_log
CustomLog /var/log/access_log combined
ScriptAlias /cgi-bin/ /var/www/cgi-bin/
DirectoryIndex index.html index.htm index.php index.php4 index.php5
<Directory /var/www/html>
Options -Indexes +IncludesNOEXEC +SymLinksIfOwnerMatch +ExecCGI
allow from all
AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
</Directory>
<Directory /var/www/cgi-bin>
allow from all
AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
</Directory>
SSLEngine on
SSLCertificateFile /etc/webmin/domain.com.cert
SSLCertificateKeyFile /etc/webmin/domain.com.key
</VirtualHost>

Note that the above is for port 80 and 443 (SSL), the path to the SSL certificate file and key is my customisation, the files must be copied to the right place.

When a domain’s A record points to this server but there’s no matching virtual site, the default will return a 404. To avoid this, simply set the “Automatic Virtual Host” of the “Default Server” (Server > Apache Webserver > Existing Virtual Hosts [Tab] > Default Server > Automatic Virtual Hosts to: /var/www/html.

The above  makes ALL Virtual sites point to the default path, so avoid.

This is one of many ways to do it. It just worked as required for my own needs.

It is also to be noted that this virtual site is not showing in the list of “virtual  Servers” in the Virtualmin Control Panel which is I think a rather good idea as I will not be able to have it deleted by accident!

 netstat -an | grep :465

Returns nothing, so.

vi /etc/postfix/master.cf

find the lines:

#smtps inet n - n - - smtpd
# -o smtpd_tls_wrappermode=yes
# -o smtpd_sasl_auth_enable=yes
# -o smtpd_client_restrictions=permit_sasl_authenticated,reject
# -o milter_macro_daemon_name=ORIGINATING

And uncomment them:

smtps inet n - n - - smtpd
 -o smtpd_tls_wrappermode=yes
 -o smtpd_sasl_auth_enable=yes
 -o smtpd_client_restrictions=permit_sasl_authenticated,reject
 -o milter_macro_daemon_name=ORIGINATING

After that, restarting postfix (I also include the saslauth, it wont hurt but I am not sure it is necessary) and checking if port 465 worked:

/etc/init.d/postfix restart
/etc/init.d/saslauthd restart
netstat -an | grep :465
tcp        0      0 0.0.0.0:465                 0.0.0.0:*                   LISTEN

I was still getting an error in my maillog:

warning: No server certs available. TLS won’t be enabled

So I needed to create a certificate. to do this using Virtualmin is dead simple (I quote):

The simplest way to do that would be to pick a Virtual Server that exists on your server whose name you’d like on the SSL certs. Let’s assume you have a Virtual Server named “example.com”, and that’s the name you’d like on your SSL certs.

(edit: I personally used my main host website to keep things together)

Firstly, go into Edit Virtual Server, go into Enabled Features, and check “SSL website enabled”, then hit save. That’ll generate an SSL cert that is put into Apache.

The next step would be to get that cert into your mail setup.

To do that, go into Server Configuration -> Manage SSL Certificate, and click “Copy to Postfix”. That’ll setup Postfix with that new SSL cert you just created.

I don’t recall if that actually restarts Postfix… if not, you may need to manually restart it with “/etc/init.d/postfix restart”.

After this, I am able to set SMTP to use STARTTLS port 587 with plain password to send emails using the server

Virtualmin > Services > Configure Website > Edit Directives 

Find the following line:

DirectoryIndex index.html index.htm index.php index.php4 index.php5

Add index.shml at the end  of the line:

DirectoryIndex index.html index.htm index.php index.php4 index.php5 index.shtml

Click “Save” then “Apply Changes” (on the top right hand side of the “Virtual Server Options” page). Checking your virtual website will show the index.shtml page.

To make it a default configuration

In order to enable  this for all further virtual websites:

Virtualmin > System Settings > Server Templates > Default Settings > Apache website > Directives and settings for new websites


Find the following line:

DirectoryIndex index.html index.htm index.php index.php4 index.php5

Add index.shml at the end  of the line:

DirectoryIndex index.html index.htm index.php index.php4 index.php5 index.shtml

Click “Save”

The same can be applied in the “Settings For Sub-Servers” Template.

#include virtual

I have some cgi scripts that are included in my shtml files. to enable include executions in the default virtualmin setup. some changes must be made in the same files as above:

Find:

Options -Indexes +IncludesNOEXEC +SymLinksIfOwnerMatch

and replace with (remove NOEXEC):

Options -Indexes +Includes +SymLinksIfOwnerMatch

Retarting the Apache server will enable #include virtual=”/cgi-bin/somescript.cgi” directive.

To save myself hassle, I installed a compatible OS (CentOS 6 64bit) and simply installed virtualmin from the install.sh command after downloading it:

cd /root
wget http://software.virtualmin.com/gpl/scripts/install.sh
sh ./install.sh

After this my next  move was to install csf lfd from configserver.com:

wget http://www.configserver.com/free/csf.tgz
tar zxvf csf.tgz
cd csf
sh ./install.sh

Once installed integrate it in Webmin and you’re good to go.

Email access problems

All worked well from the word go except SMTP/POP3 (Dovecot) server; I was getting Failed to connect to localhost:143 : Connection refused  (as well as port 993,995,110 and 25) when trying to connect either via my email client or usermin.

System Information was reporting that Dovecot IMAP / POP3 Server was offline, and trying to start Dovecot failed:

Starting dovecot: Error: socket() failed: Address family not supported by protocol
Error: service(pop3-login): listen(::, 110) failed: Address family not supported by protocol
Error: socket() failed: Address family not supported by protocol
Error: service(pop3-login): listen(::, 995) failed: Address family not supported by protocol
Error: socket() failed: Address family not supported by protocol
Error: service(imap-login): listen(::, 143) failed: Address family not supported by protocol
Error: socket() failed: Address family not supported by protocol
Error: service(imap-login): listen(::, 993) failed: Address family not supported by protocol
Fatal: Failed to start listeners

After editing the /etc/dovecot/dovecot.conf file and commenting out/insert: listen = *  Here is how my edited file looks like:

# A comma separated list of IPs or hosts where to listen in for connections. 
# "*" listens in all IPv4 interfaces, "::" listens in all IPv6 interfaces.
# If you want to specify non-default ports or anything more complex,
# edit conf.d/master.conf.
#listen = *, ::
listen = *

Now, why would Dovecot server come with this line disabled is baffling, anyway, after this, Dovecot starts fine allowing usermin and email clients to connect without problems:

#!/usr/bin/perl
# This script pings IP addresses
#
# In a live application, read host list
# from a config file
@hosts = ("192.168.1.1","192.168.1.19");
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
$year += 1900;
$mon += 1;
$min = sprintf("%02d", $min);
$sec = sprintf("%02d", $sec);
$mon = sprintf("%02d", $mon);
$mday = sprintf("%02d", $mday);
$year = sprintf("%02d", $year % 100);

@live = ();
foreach $h (@hosts) {
        $r = `ping -c2 $h`;
        if ($r =~ /2 re/) {
                push @live,$h;
                }
        }
$alive = "@live";
print ("You have $alive on $mday $mon $year @ $hour:$min:$sec\n");

This script can then be used in a cron like:

*/5 * * * * /path/to/file/pingtest.pl >> /some/path/pingtest.txt

This command will write the result on a new line in the file called pingtest.txt every 5 minutes. Which will look like that:

You have 192.168.1.1 192.168.1.19 on 06 01 13 @ 20:05:01
You have 192.168.1.1 192.168.1.19 on 06 01 13 @ 20:10:01
You have 192.168.1.1 192.168.1.19 on 06 01 13 @ 20:15:01