Do NOT disable fencing on your RedHat Cluster unless you really know what you’re doing! Fencing is designed to protect your data from corruption, if you disable fencing your data is at RISK, you have been warned!

I however am working on building a GFS DRBD cluster, as far as I can gather DRBD doesn’t need fencing, and the bottom line is my data is personal data not mission critical and if my website goes down due to my disabling fencing then it’s no big deal.

Rant over, here we go….. To disable fencing, create a custom fence agent.

Fence agents are simply scripts in /sbin, I’ve created /sbin/myfence and here are the contents.

#!/bin/bash
echo "success: myfence $2"
exit 0

Next, change your cluster.conf…

<?xml version="1.0"?>
<cluster alias="linickx" config_version="41" name="linickx">
        <cman expected_votes="1" two_node="1" />

        <clusternodes>
                <clusternode name="CentOS1" nodeid="1" votes="1">
                         <fence>
                                <method name="1">
                                        <device nodename="CentOS1" name="myfence"/>
                                </method>
                        </fence>
                </clusternode>

                <clusternode name="CentOS2" nodeid="2" votes="1">
                        <fence>
                                <method name="2">
                                        <device nodename="CentOS2" name="myfence"/>
                                </method>
                        </fence>
                </clusternode>
        </clusternodes>

        <fencedevices>
                <fencedevice agent="myfence" name="myfence"/>
        </fencedevices>
        <rm/>
</cluster>

If you’re running SELINUX don’t forget to update that! … start with restorecon /sbin/myfence then update your policy.

This is the policy I’ve created…

module fenced 1.0;

require {
        type fenced_t;
        type shell_exec_t;
        class file { read execute };
}

#============= fenced_t ==============
allow fenced_t shell_exec_t:file { read execute };

If you save the above as fenced.te, then run this to install it..

checkmodule -M -m -o fenced.mod fenced.te
semodule_package -o fenced.pp -m fenced.mod
semodule -i fenced.pp

You should now be able to start cman, fencing will start but will return success for any fencing issues without actually doing anything!

Happy non-fencing!

I’ve decided to start with the purpose I wrote the plugin, then I’ll move onto a couple of tutorial which answer some of the FAQs I get.

Scenario.
Before you start you need a working copy BLANK of WordPress, in a sub directory, with a url like domain.com/wordpress.
A BLANK copy is a fresh install, using the default theme and only my root-cookie plugin installed, remember after activating the plugin clear your browsers cookies.

Getting Started.
So you have a ready & waiting copy of WP, next create a directory called “my-scripts” or whatever you like, and in it create 1.php with the following contents:


<?php
print_r($_COOKIE);
?>


Browse to domain.com/my-scripts/1.php and you’ll get a blank white page with Array().
Next log into WordPress, and re-fresh 1.php and you should get something like….

Array ( [wordpress_xxxxxxxxxxxxxyyyyyyyyyyyyyy] => admin|1241455565|xxxxxxxxxxxxxyyyyyyyyyyyyyy [wordpress_logged_in_xxxxxxxxxxxxxyyyyyyyyyyyyyy] => admin|1241455565|xxxxxxxxxxxxxyyyyyyyyyyyyyy )

Done! You’ve just accessed WordPress’s cookies

Now when I first started I had a very basic script which hid my Google adverts when I’m logged in, it’s against Google’s policies to click on your own adverts so to avoid accidents I wanted to hide them.

The following script is NOT secure, it doesn’t check that you’ve logged into WordPress it simply checks that you a cookie set with the right username (which anyone can fake) but for my purpose this was fine, I had no issues with users faking cookies to get rid of the adverts*


<?php
if (isset($_COOKIE["wordpress_logged_in_fxxxxxxxxxxxxxyyyyyyyyyyyyyy"])) {
$cookie = $_COOKIE["wordpress_logged_in_xxxxxxxxxxxxxyyyyyyyyyyyyyy"];
$cookie_elements = explode('|', $cookie);
if ($cookie_elements[0] == "admin") {
echo "<h1>Hello admin!< </h1>";
}
}
?>


Replace admin with whatever username your using and job done! Next time Accessing two WordPress installs domain.com/blog1 domain.com/blog2 with root-cookie

*this will not work now, as I do something different.

The guys in the office recommended that I should run JKDefrag to help “optimize” things. I downloaded a copy, and read that you have a variety of options to run the software including a screen-saver; my laptop is on pretty much most of the time so I’ve decided that I would run JkDefrag as a scheduled task over night.

I’ve not scheduled anything on Vista before and in my investigation I found that vista by default at 1am every wednesday defrags the hard drive!

This changed my plan, instead of scheduling JkDefrag to run, I would replace the default defrag task.

If you would like to do the same, download a copy of JkDefrag and unzip it into a directory, take a note of where you unzip the files as you’ll need the directory path later.

To get started open the vista task scheduler (it’s in admin tools). From the tree in the left browse to:

Task Scheduler Library -> Microsoft -> Windows -> Defrag

Next download the XML file attached to this post (Nicks Scheduled Defrag) and within the Task scheduler, click on “Import Task” from the action bar on the right hand side… browse to and choose my file, once done right click the old “Scheduled Defrag” task and disable it, you should end up looking at a window like this…

Cool! You’re nearly there, the task you’ve installed is a copy of the default defrag task, with the date and action changed to suit my need, you will need to do the same! You remember you wrote down a directory path earlier, well you need it now….

My scheduled task runs Jkdefrag from a directory called C:\Users\nick.bettison\Software\JkDefrag-3.36\, I’m 99% sure you won’t have that directory

Right click on NicksScheduledDefrag and select properties , click the actions tab, select “start a program” and click edit. Change the path C:\Users\nick.bettison\Software to where ever you have your JkDefrag, you will need to make changes in both the “Program / Script” field, and “Add arguments field”…

When done, click Ok. If you feel like it you can change when it runs under the “triggers” tab, edit the “weekly” trigger to suit your needs.

You can now choose to wait (until 1am saturday night – or whatever you changed it to), or click run; either way after the task has run in your JkDefrag-3.36 directory you will hopefully have log.txt showing the results of the defrag!