pitter patter on the keyboard

GRUB2 is highly customizable and feature-rich, however it is a bit of a nightmare if you configure bootloaders regularly. Unfortunately GRUB 0.97 doesn’t support ext4 and – if you were an idiot like me – you might have set up your new dedicated with an ext4 /boot. Now, you have neither the time nor patience to re-install and need to make Xen go.

First, copy your Dom0 .config and kernel to /boot/. /etc/grub.d/20_linux_xen picks up on the CONFIG_XEN_PRIVILEGED_GUEST=y variable.

# cp /usr/src/linux/arch/x86_64/boot/bzImage /boot/kernel-dom0
# cp /usr/src/linux/.config /boot/config-dom0

Next, remove the executable flag from /etc/grub.d/10_linux or you will end up with three or four entries that boot straight to the Dom0 kernel without the hypervisor.

# chmod -x /etc/grub.d/10_linux

To add kernel boot parameters to your grub.cfg (as generated with grub2-mkconfig and 20_linux_xen) add these lines to your /etc/default/grub file:

GRUB_CMDLINE_LINUX_XEN_REPLACE="max_loop=128"
GRUB_CMDLINE_XEN="dom0_mem=512"

The former will place your boot options on the Dom0 kernel’s module line. The latter will place boot options on the xen.gz hypervisor’s kernel line.

Now, generate your new configuration:

# grub2-mkconfig -o /boot/grub2/grub.cfg

Once the config file has been written, determine the position of the Xen hypervisor entry and update GRUB_DEFAULT in /etc/default/grub.

Install GRUB2 to your MBR(s) as necessary:

# grub2-install /dev/sda 

Chances are you just changed the port settings in framework/base/config/ofbiz-containers.xml but forgot to update framework/service/config/serviceengine.xml.

Open serviceengine.xml and replace all four instances of “8080″ with the non-secure port you specified in ofbiz-containers.xml.

Has your outdated wordpress or other shrinkwrapware been compromised? (Yes >.>)

After taking steps to shut down the site you should probably use the find command to check to see if there are any unusual files which have been uploaded recently. If you scramble to close the hole and do updates before this step you will likely end up drowning any suspects in the results.

If you don’t remove, for example, a phishing page before plugging the hole you:

• May never find out it’s there
• Are contributing to phishing
• One day your ISP will probably forward you a sternly worded letter from the victimized institution and threaten to drop your service if the page is not removed in 24 hours

Use your imagination if it’s something worse, like a rootkit or webshell.

It is necessary to determine the earliest possible time the attack could have taken place. It won’t kill you to add a day or two for safety.

# find /var/www/localhost/htdocs/ -type f -ctime -X

Where X is the number of days to look back.