Category Archives: Uncategorized

WordPress MainWP BackWPUp job creation

For WordPress administrators WordPress MainWP BackWPUp job creation should be a simple process.

MainWP is a very handy console for those of us managing lots of WordPress sites.

BackWPUp is a very popular plugin to assist with managing those sites.

My experience has been not so supportive of either notion.

WordPress MainWP BackWPUp job creation proved to be a lengthy process of diagnosis of multiple bugs and ‘features’ that were eventually worked out but with a lot of time wasted.

This was using MainWP with MainWP Child and BackWPUp plugin in both the MainWP central dashboard and the child site.

MainWP and Child Utility

I use MainWP as a centralised management tool and it offers a connection or interface to manage BackWPUp from the central dashboard. In the main it works, but there are a number of gotcha’s.

Modifications are not Sync’d

The first is when you modify a backup job in the child site (the client site) and you sync from the child site to the MainWP dashboard. The changed configuration of the BackWPUp job is NOT changed in the MainWP dashboard from what was previously configured. (At least this is the case with fields in the FTP transfer and job name fields. I did not test every setting field)

So you must make changes only from the MainWP dashboard as a ‘sending’ sync will transfer the details from MainWP to the child site, but my testing shows that it will not ‘get’ or receive setting changes from the child site. So management is only one way for BackWPUp at least. I trawled the MainWP documentation but cannot find any precise description of what a Sync Data process is meant to do.

Allowed Tags Do not Transfer

Secondly, the instructions in MainWP for BackWPUp are really misleading (I wasted hours on this task alone because what seemed clear and concise was completely misleading).

The MainWP BackWPUp page setting for the backup job name and archive name state that you can use variable tags:

Allowed tags: %sitename%, %url%, %date%, %time%

and this would appear to be straight-forward. You should be able to make the date / time variable in the archive name in order to retain multiple day backups where needed.

So I confidently applied an archive name of daily-%sitename%-%date%-%time% with the expectation that MainWP would pass this to the child site in the archive name field for the BackWPUp job.

Gotcha !! MainWP takes the variables and converts them at the time that you save the job in MainWP and transfers the resulting archive filename to the child site for the BackPWUp job !

So in the child site we now have an archive filename that does NOT get a changing date / time stamp and will replace the archive on a daily basis. Nasty if you think you have 7 days of backups.

Allowed Tags are Inconsistent

Finally, I tried copying and pasting the daily-%sitename%-%date%-%time% parameter for the archive file name field value directly into the child site job. But the was perplexed as I got some crazy file name that included % signs etc…… but another Gotcha!

Yep, the MainWP “Allowed Tags” only apply within MainWP, which would be fine if they worked, but they don’t.  So the %sitename% parameter is interpreted in BackWPUp as %s (for seconds as in time) and the ‘seconds’ is inserted in the archive name along with “itename%-“.

The rest of the archive filename consists of correctly interpreted but clearly invalid ‘tags’. This is because BackWPUp provides for a completely different set of parameters or allowed tags that are completely inconsistent with the MainWP configuration.

So as a last resort, I configured the child site job for BackWPUp with something like daily-thowden.com.au-%Y%m%d-%H%i so that I get a changed date / time within the archive file name.

I then manually copied that from the child site to the MainWP dashboard.  (Yes, manually, remember that the sync process is one-way!). From that point on I now have a working backup cycle.

BackWPUp

Ok, so I now have a configured BackWPUp job ready to test and schedule on my child site.

BackWPUp Date Time Stamp Issue

Now that the backup would run I got to check the BackWPUp logs and found that they are incorrectly date / time stamped with the system date being ignored and using UTC / GMT time instead. Painful when trying to confirm local time of events. The date/time issue also impacts on the scheduling which must be done as at UTC 0000 to get the right timing for the schedule.

When an Error is not!

If we get over the date / time stamp issue, the log reports an ERROR: as 2 errors when in fact it completed successfully!!!

If an FTP transfer attempt fails, an initial error is flagged with ERROR: and then a 2nd (and a third) attempt will be made for the FTP transfer.

If that second transfer attempt is successful the job completes, but because of the first upload ERROR: condition existing the whole job is flagged as ERROR: Failed.

The crazy thing is that the last line ERROR: condition is also counted so that 2 errors are reported in the summary from a successful completion!

Arghhh… this of course wastes a heap of time checking what are in fact successful backups.

It works ! but…. it would be a whole lot easier and better if all the above had worked as expected.

Issue Summary

1. MainWP need to correct their process so that the sync is bi-directional.
2. MainWP need to correct the description of the allowed tags so that they are consistent with what BackWPUp actually uses.
3. MainWP must pass the ‘tagged’ version of the archive file name to the job and not do the conversion.
4. BackWPUp really should fix the date / time issue so that the logs and schedules are accurate and consistent with the WordPress site configuration so that they make sense.
5. BackWPUp should fix the ERROR reporting so that successful backups that may have contained one FTP transfer error but do complete successfully are not flagged as ERROR (twice)

Shellshock BASH Vulnerability: Debian, CentOS, Synology Busybox

Ok, so Heartbleed did as it said, and Shellshock is about to do the same.

I manage some CentOS, some Redhat, some Debian, and other servers. From what I have found so far, and assuming that the patches applied to the latest release of BASH are sufficient, then most servers and devices can be patched / fixed so that they are not vulnerable quite easily.

According to most sources, the test for a vulnerable BASH environment is the following line of code:

[text]
env x='() { :;}; echo vulnerable’ bash -c "echo this is a test"
[/text]

So I quickly hit one of each server / Linux flavour I could think of and these are the results:

SME Server / CentOS based

[text]
# env x='() { :;}; echo vulnerable’ bash -c "echo this is a test"
vulnerable
this is a test
[/text]

so I ran

[text]
# yum update
[/text]

which updates a number of tools including bash-3.2-33.el5.1.i386.rpm which appears to be the correct update version and re-testing after updating the server (includes other updates as well) gives the ‘not vulnerable’ response.

CPanel on CentOS

[text]
# env x='() { :;}; echo vulnerable’ bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x’
this is a test
#
[/text]

which appears to tell me that it is not vulnerable.

I also had a similar message but without the warning from a second CPanel / CentOS server which is configured slightly differently:

[text]
# env x='() { :;}; echo vulnerable’ bash -c "echo this is a test"
this is a test
#
[/text]

The lack of a warning in the above appears to indicate that it is not vulnerable.

Debian

Some of my Debian servers have not been upgraded from stable Squeeze, which I should be updating to Wheezy. I found different responses depending on which version of Debian existed on the server.

To check the Debian version use:
[text]
# cat /etc/debian_version
# 6.0.6
[/text]

Checking the Debian version just as a confirmation of what patch release the server is using.

Debian Squeeze 6.0.6

[text]
# env x='() { :;}; echo vulnerable’ bash -c "echo this is a test"
vulnerable
this is a test
#
[/text]

Vulnerable, so update BASH

[text]
# apt-get update
# apt-get install bash
[/text]

A second test shows:

[text]
# env x='() { :;}; echo vulnerable’ bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x’
this is a test
#

<h2>Debian Squeeze 6.0.10</h2>

This one is a work in progress……

<h2>Debian Squeeze 7.4</h2>

This version of Debian was straightforward and

[text]
# env x='() { :;}; echo vulnerable’ bash -c "echo this is a test"
vulnerable
this is a test
#
[/text]

Oops!

[text]
# apt-get update
# apt-get install bash
[/text]

A second test shows:

[text]
# env x='() { :;}; echo vulnerable’ bash -c "echo this is a test"
this is a test
#

<h2>Synology Busybox</h2>

Synology Busybox uses ASH not BASH but testing can still be done

[text]
# env x='() { :;}; echo vulnerable’ ash -c "echo this is a test"
[/text]

Gave an all clear message on my recently updated Synology unit.

SME Server as a Nagios NRPE Client only

If you are wanting to install Nagios on an SME Server version 8 then you will probably start with the Wiki Contribs page for a Nagios Server install. http://wiki.contribs.org/Nagios

Which is going to lead you down a path of installing a complete Nagios Server assuming you overcome the issues with those instructions.

But if you have a Nagios Server elsewhere and you want to just add the SME Server as a client then a different set of instructions can be found in the forums.

http://forums.contribs.org/index.php/topic,48587.msg241615.html#msg241615

Which is really helpful but is missing a couple of key points for a complete set of instructions. So here is a re-write of that instruction set.

NRPE SME Server 8 Installation

1. Configure the dag repository

The following command will configure the dag repository on SME Server.

[text]

/sbin/e-smith/db yum_repositories set dag repository
Name ‘Dag – EL5’
BaseURL ‘<a href="http://apt.sw.be/redhat/el5/en/" target="_blank">http://apt.sw.be/redhat/el5/en/</a>$basearch/dag’
EnableGroups no
GPGCheck yes
GPGKey <a href="http://dag.wieers.com/packages/RPM-GPG-KEY.dag.txt" target="_blank">http://dag.wieers.com/packages/RPM-GPG-KEY.dag.txt</a>
Visible no
Exclude freetype,htop,iptraf,rsync,syslinux
status disabled

[/text]

2. After adding it to the database we have to update the changes to the configuration file:

[text]signal-event yum-modify[/text]

3. Then run this to enable the repo

[text]

/usr/bin/yum –enablerepo=dag install
nagios-plugins
nagios-plugins-setuid
perl-Config-Tiny
perl-Class-Accessor

[/text]

4. Copy nrpe rpm’s

Current download for the files are:

http://pkgs.repoforge.org/nagios/nagios-3.2.1-5.el5.rf.i386.rpm

http://pkgs.repoforge.org/nagios-nrpe/nagios-nrpe-2.5.2-1.el5.rf.i386.rpm

http://pkgs.repoforge.org/nagios-nrpe/nagios-plugins-nrpe-2.5.2-1.el5.rf.i386.rpm

5. Install the nrpe rpm’s

[text]

yum localinstall nagios-3.2.1-5.el5.rf.i386.rpm
yum localinstall nagios-nrpe-2.5.2-1.el5.rf.i386.rpm
yum localinstall nagios-plugins-nrpe-2.5.2-1.el5.rf.i386.rpm

[/text]

6. Modify the nrpe.cfg file to allow the external ip of your Nagios server  (swap vim for your favourite editor)

[text]

vim /etc/nagios/nrpe.cfg

[/text]

the allowed_hosts parameter is already in the file, remove the # from the start of the line and add your nagios server ip

[text]

allowed_hosts=127.0.0.1,nagios.server.ip.here

[/text]

Save the file and exit.

7. Add the service

[text]

cd /etc/rc7.d

cp -s /etc/init.d/nrpe S95nrpe

[/text]

8. Port forward 5666 to localhost (swap vim for your favourite editor)

a)

[text]

mkdir -p /etc/e-smith/templates-custom/etc/hosts.allow/

[/text]

(if you get an error it means the directory already exists.)

b)

[text]

vim /etc/e-smith/templates-custom/etc/hosts.allow/nrpe

[/text]

and add the following lines to the nrpe file, adding your nagios server ip

[text]

{
$OUT="nrpe: " . ($nrpe{HostsAllow} ? $nrpe{HostsAllow} : "127.0.0.1 nagios.server.ip.here" );
}

[/text]

Save the file and exit.

9. Configure the new template

[text]

expand-template /etc/hosts.allow

[/text]

10. Start NRPE

[text]

service nrpe restart

[/text]

And then off to your Nagios server to add the new SME Server as a client.