857.5G for /home
50G for /root

I use Oracle 11g, MySQL, PostgreSQL, Apache, Tomcat and a host of other applications. The databases I work with can consume 50G in a heartbeat, so resizing was called for. After some research online, I was able to put together the necessary steps to resize the logical volume. My goal was to come out with 807.5G for /root and 50G for /home. NOTE: My fall back position was to reinstall if anything went wrong with the resizing. You may wish to perform a backup of more than just your /home sub-directories or prepare for possible recovery in your chosen way (e.g. tarballs of important files). Increasing the /root logical volume was not destructive, but decreasing /home was. As always, this is what worked for me and while I would hope it can act as a guide for others, follow at your own risk.

STEP 1: Prepare for the resizing

Clearing /home

As I had already created some users, I had directories under /home. I moved these to my backup drive using: mv -r * /bkup

Unmounting /home

With /home now empty, I unmounted it: umount /home

STEP 2: Resize /home

Checking the /home partition

My logical volume is named redhatweb-lv. I used the following to first check the /home partition:
e2fsck -f /dev/mapper/vg_redhatweb-lv_home
This returned:
[root@redhat-web /]# e2fsck -f /dev/mapper/vg_redhatweb-lv_home
e2fsck 1.41.12 (17-May-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/vg_redhatweb-lv_home: 11/57098240 files (0.0% non-contiguous), 3634829/228381696 blocks

Resizing the /home filesystem

After everything checked out, I used the following to resize the /home partition to the much smaller 50G: resize2fs /dev/mapper/vg_redhatweb-lv_home 50G
This returned:
[root@redhat-web /]# resize2fs /dev/mapper/vg_redhatweb-lv_home 50G
resize2fs 1.41.12 (17-May-2010)
Resizing the filesystem on /dev/mapper/vg_redhatweb-lv_home to 13107200 (4k) blocks.
The filesystem on /dev/mapper/vg_redhatweb-lv_home is now 13107200 blocks long.

Reducing the /home logical volume

The filesystem for /home was now 50G, but the logical volume was still 857.5G. To size the logical volume to the same size as the filesystem, I used:
lvreduce -L 50G /dev/mapper/vg_redhatweb-lv_home
This returned (after answering ‘y’ to the prompt below):
[root@redhat-web /]# lvreduce -L 50G /dev/mapper/vg_redhatweb-lv_home
WARNING: Reducing active logical volume to 50.00 GiB
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce lv_home? [y/n]: y
Reducing logical volume lv_home to 50.00 GiB
Logical volume lv_home successfully resized

STEP 3: Resize /root

Extending the /root logical volume

With a 50G /home partition, I should have room for an 857.5G /root partition (857.5G to start less the 50G I finished with should give me 807.5G to add to the 50G /root partition). I first took 857.5G less the new size of 50G and tried to increase the /root partition to 857.5G (the original size of 50G + the 807.5G gained by shrinking /home). The effort was rewarded with an error that there was insufficient room, so I backed off to a nice round number of 850G.

I used the following to resize the /root logical volume:
lvextend -L 856.7G /dev/mapper/vg_redhatweb-lv_root
This returned:
root@redhat-web /]# lvextend -L 856.7G /dev/mapper/vg_redhatweb-lv_root
Rounding up size to full physical extent 856.70 GiB
Extending logical volume lv_root to 856.70 GiB
Logical volume lv_root successfully resized

Resizing the /root file system

As before, the filesystem also had to be resized, but in this case, by increasing it. I used the following:
resize2fs /dev/mapper/vg_redhatweb-lv_root 850G
The above returned:
[root@redhat-web /]# resize2fs /dev/mapper/vg_redhatweb-lv_root 850G
resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/mapper/vg_redhatweb-lv_root is mounted on /; on-line resizing required
old desc_blocks = 4, new_desc_blocks = 54
Performing an on-line resize of /dev/mapper/vg_redhatweb-lv_root to 222822400 (4k) blocks.
The filesystem on /dev/mapper/vg_redhatweb-lv_root is now 222822400 blocks long.

STEP 4: Restore /home and test

Restoring /home directories

After resizing, I copied back the user directories that I had backed up on my second drive:
cd /bkup/home
cp -r * /home


Testing

At this point, I rebooted the system and checked to see if all services started. Some, as in Oracle, were dependent on a user directory under /home. After rebooting, my services were started and I was able to log into each of the databases I use. I have seen no ill effect from the above efforts and have well exceeded the 50G initially allocated to /root without additional problems.

The WordPress Firewall plugin notification of an injection attack.

Recommended Actions

I took the following actions after receiving the first e-mail:

1. I immediately inserted the offending IP address into my list of banned IP’s using the WP-Ban plugin. I did this across all my sites.
2. I then scanned my entire file system on each site for the presence of the above three files. The WordPress Firewall plugin did its job: no copy of any of the above files was found.

At The End Of The Day…

I really hate people who try to hack my sites. I’d love to see WordPress ship with WordPress Firewall and WP-Ban installed and activated at the time of installation with a listing of the known offensive sites. Yes, they can change their IP, which is why I use the combination of plugins, but I would love to make it so impossible for them to get to any WordPress site that they just give up and move elsewhere!

Why Is This Important?

For the individual blogger, this may not seem important, but to a developer it could be beneficial in several ways. You could focus on developing content without worrying about the presentation and allow the customer to scroll through the various themes available with their content at various stages of development. To make this smooth for the customer, you would want them to be relaxed and comfortable with a smooth presentation. What you do not want is a presentation full of stops and starts, trying to return to a particular theme later in your presentation by scrolling through pages, etc.

Companies may wish to use this feature to help rotate their themes seasonally. For example, they may wish to “go pink” in October in support of breast cancer research or refresh their corporate image annually. The ability to compare and contrast themes could help them determine how best to solidify their corporate identity. E-commerce sites could select different themes as different landing sites if serving different communities of interest.

This could also help theme developers gain exposure and sales by creating a new marketplace (see requirement 5 below).

Suggested Requirements

The following list of requirements are a starting point for discussion on what a new plugin could do to solve the problem of comparing the presentation of content between multiple themes:

1. The plugin needs to provide the ability to scroll through all themes available in the /wp-content/themes directory of the current WordPress installation presenting the currently selected content in the currently selected theme.
   • The presentation will default to the home page the first time the user opens the plugin but follow the currently selected content after the user navigates within the theme (i.e. open to the same page when the user navigates to a new theme).
   • Next and Previous buttons would list the themes to which the user would be taken if they selected that option.
2. The plugin needs to allow the user to compare themes side-by-side with the ability to scroll either side.
   • Next and Previous buttons would list the themes to which the user would be taken if they selected that option on that side of the comparison window (i.e. independent Next/Previous buttons for both sides).
   • A drop down list of available themes would allow the user to jump to a selected theme from either side (i.e. a drop down list on both sides of the compare window).
3. The plugin needs to present a page of thumbnails with the currently selected content in a thumbnail of each theme.
   • The plugin needs to allow the user to choose a theme from the thumbnails which will take the user to the scrolling themes in requirement 1 above.
   • The plugin needs to allow the user to choose two themes from the thumbnails which will take them to the compare window in requirement 2 above.
4. The plugin needs to allow the user to interact with the content (i.e. use the themes actions such as hyperlinks to drill down).
   • The plugin needs to remember where it is in the content when it moves from one theme to the next.
   • The plugin needs to allow the user to choose to navigate simultaneously in both themes when comparing side-by-side or navigate the themes independently of each other.
5. The plugin needs to allow the user to choose to preview the content in a theme hosted by a third-party (e.g. a theme developer).
   • This requirement assumes that theme developers would be interested in providing an API to their theme (e.g. a publicly accessible url to either this plugin or a companion plugin operating on their site).
   • This requirement assumes that the plugin at the theme developers site could accept an encrypted database name, user name and password from this plugin and connect back to the content for presentation.
   • This requirement assumes that the site hosting the plugin has a read-only user name and password for use by third-party hosted themes and that the port for their database will accept a connection from any host using that user name and password.
     • The plugin will provide the ability to generate encrypted user names and passwords for use in securing connections between the host and the third-party theme developer.
     • The plugin will provide the ability to update the database to allow the connection from any host using the generated and encrypted user name and password.

At The End Of The Day…

The above list of requirements is non-trivial, but I believe a lot of people could benefit from the features of such a plugin. If anyone decides to take on the challenge of creating a plugin that will accomplish the above, I am available for testing!

I installed a fresh WordPress 2.8.5 and copied all my plugins to it. I then activated TinyMCE first and, yes, my toolbars were there! I then activated other plugins one-by-one until the toolbars no longer appeared. The last plugin I activated before losing the TinyMCE functionality was WP-MarkItUp. I had originally thought that WP-MarkItUp would allow visitors to style their comments a bit more by providing new features to the textarea in which comments are entered. What I didn’t realize at the time was that it also applies to the textarea of the post and page editors as well; there is no exemption for the admin area.

I deactivated WP-MarkItUp, but TinyMCE’s functionality did not return. I then deactivated and re-activated TinyMCE, but alas I still did not have it’s functionality back. I then looked into the PHP pages of WP-MarkItUp for a clue on what it was doing at the time it was activated. I found that it updates the user option for “rich_editing” to ‘false’. The user options are stored in the usermeta table (i.e. wp_usermeta if your table prefix is wp_), so I selected all columns for the row whose meta_key was ‘rich_editing’ and user_id was mine (2 in my case). Sure enough, its value was ‘false’.

I updated the value to ‘true’ and eureka! I have TinyMCE back.

Who’s At Fault?

I thought about what it took to chase this down and fix it. Was it the fault of WP-MarkItUp not resetting the value when it was deactivated? What about the fact that TinyMCE did not set the value to true when I deactivated, then reactivated it?

I can’t blame either plugin or developer. Once activated, WP-MarkItUp would have to persist the former state of rich_editing to know what to set it back to. But, how could it be certain that no other plugin had not manipulated it after it was activated? Setting it back could cause another plugin to fail just as not setting it back caused TinyMCE to fail. I’m not certain why TinyMCE did not change the value after re-activation, but if it didn’t need the value in the first place, then why did it not resume display when WP-MarkItUp was deactivated? That I can’t answer, but perhaps in the future it could check to see if ‘rich_editing’ is ‘true’ if it is necessary for the proper functioning of the plugin. For now, having the functionality of TinyMCE back is good enough for me, but as a bonus, I learned something new about how WordPress uses the user options! A two’fer!