R from EPEL has been updated to version 3.

We would like to run rpy2 but as of rpy2 version 2.3.x, it requires Python 2.7.

Red Hat Enterprise Linux 6 comes with Python 2.6.

So we need Python 2.7 so we can use rpy2 2.3 so we can use R 3.

The solution is to create a Python virtualenv containing Python 2.7 and install rpy2 in there. That way a user can log in and get Python 2.7 when they type python at the command line.

Take a moment to make sure standard build tools are installed. At a minimum, we need the following since we want numpy to use ATLAS, BLAS, and LAPACK, and not run into problems using SSL from Python:

Python 2.7 can now be installed from source:

Now setuptools:

Finally, virtualenv. This installs the virtual environment at /usr/local/ve but you might want it elsewhere.

That last line activates the virtual environment, so adding it to your .bash_profile might be handy.

Trying to add numpy with easy_install-2.7 didn't work for me:

However, pip worked like a charm:

Likewise rpy2 worked fine:

Reference: Undefined symbol (Rf_PrintWarnings) when using rpy 2.3.1 and R 3.0.1

I had a RHEL6 machine with lots of large MySQL binary log files in /var/log/mysql and was in need of more space on that volume. I am running MySQL 5.5 from IUS.

The system had an unused LVM logical volume. So I proceeded to mount the LVM logical volume at /var/log/mysql so that binary logs would get written to the logical volume.

Step one: unmount the logical volume

Not strictly necessary for a rename but a nice precaution.

Step two: rename the logical volume

The volume was named foo (not really true but it will server for this example) and was in the volume group named vg_db. I renamed it to something obvious, namely lv_mysqllogs.

Step three: create a temporary directory as a mount point

I'll put the new directory right next to the existing /var/log/mysql.

Step four: purge binary logs

In order to have only a small amount of data to move, I checked with our MySQL slave server to make sure it was up-to-date, then logged into MySQL as root and purged the logs:

Step five: mount LVM logical volume

Step six: copy the binary log files

For this, we have to stop MySQL.

And then copy logs:

Step seven: unmount LVM and remount at /var/log/mysql

We want to keep the original directory around in case things go horribly wrong.

And then move our temporary directory to its final destination for use as a mount point:

And remount the LVM logical volume to /var/log/mysql:

This is a good time to update /etc/fstab with your new mount entry so it will survive reboots:

Step eight: start up MySQL

Here we go:

Step nine: PANIC

(Note to my readers. Ach, who am I kidding? Note to my reader: if you follow the steps above you should not end up here. I had forgotten to change ownership of the newly-mounted volume to mysql, so when MySQL tried to start it tried really hard but couldn't -- see Bonus tidbit, below. I'm adding these details for frantic Googlers whose MySQL is down with errno 13).

No, don't panic. Just look in /var/log/mysqld.log to see why it's not starting:

Step ten: breathe. Just breathe.

The errno 13 shown above is a permissions error. Let's review the permissions:

That all looks good. So it must be SELinux. Let's check:

Aha! See how bin-log.000189 is marked var_log_t instead of mysqld_log_t? Let's restore its correct SELinux settings and look again:

Step eleven: start MySQL, for real

Yay!

Bonus tidbit

If you start up MySQL and it doesn't start, and /var/log/mysqld.log says

the problem is with the ownership of /var/log/mysql. Compare what you've got

with what you want to have:

See how . is owned by root:root instead of mysql:mysql? That's why you want to do

Changing an SVN commit message retroactively involves two steps. First, the repository must have a hook enabled. Then the svn client must issue a propset command.

On the subversion server:

cd /var/www/svn/myrepository/hooks
cp pre-revprop-change.tmpl pre-revprop-change
chmod u+x pre-revprop-change
chown apache:apache pre-revprop-change


Line-by-line explanation:

Change to the subversion repository's hooks directory.
Copy the template file that is already there to a file without the .tmpl extension.
Make the file executable.
Change ownership of the file to the apache user (this is the user that Apache runs as on Fedora-like systems such as RHEL6).

Changes to log messages are now allowed.

Now an svn command can be issued on the client at the command line to revise the log message for a certain revision (in this case, revision 42):

svn propset -r 42 --revprop svn:log 'my new commit message'
property 'svn:log' set on repository revision 42


This error is related to caching and compression. Wish I had time to dig deeper now, but I don't.

For us, it happened when a database was moved to a new server without turning off anonymous page caching first.

Solved by:

1. Adding the following line to settings.php:

2. Logging into the site using Firefox (not Safari) and going to http://www.example.com/admin/config/development/performance and hitting the Clear All Caches button.

It's not enough to just truncate the cache tables in your database.

3. Go back and undo your settings.php change.