Chris Schuld’s Blog

In HTML you may find that the dash / hyphen character is a breakable character and if you are attempting to create a region where line breaking is not desired you may need a non-breakable space character.

Here it is: ‑

A while back I wrote an article on updating to ghostscript 8.63 on CentOS 5.2. I received a fair amount of email and comments on the topic ranging from “thanks” to “you don’t know what your talking about!” I thought I would update the original post to include the latest release of ghostscript (8.7) as well as answer and respond to the best question / statement in the comments… “how do you do that and can you post the SRPMS?” The answer is, yes, here is how I do it and “yes” I’ll post the SRPMs (or more appropriately where I get them).

First, you have to have the latest version of the build environment as well as some prerequisites for building GhostScript:

yum --enablerepo remi groupinstall "Development Tools"
yum --enablerepo remi install libjpeg-devel libXt-devel libpng-devel gtk2-devel glib2-devel gnutls-devel libxml2-devel libtiff-devel cups-devel libtool jasper-devel

(you will note here I use the REMI repo)

Next, I obtain the SRPM files from rpmfind.net and ghostscript-fonts from the centos repo:

wget ftp://195.220.108.108/linux/fedora/development/source/SRPMS/ghostscript-8.70-3.fc13.src.rpm
 
wget http://mirror.centos.org/centos/5.4/os/SRPMS/ghostscript-fonts-5.50-13.1.1.src.rpm

Now, I build them using RPM (rpmbuild):

rpmbuild --rebuild ghostscript-8.70-3.fc13.src.rpm
rpmbuild --rebuild ghostscript-8.70-1.fc10.src.rpm

… and that is how I do it! If you are feeling exceptionally lazy and have some inherent trust for my builds in x86_64… here they are:

rpm -Uvh http://chrisschuld.com/centos54/ghostscript-8.70-1.x86_64.rpm http://chrisschuld.com/centos54/ghostscript-fonts-5.50-13.1.1.noarch.rpm http://chrisschuld.com/centos54/ghostscript-gtk-8.70-1.x86_64.rpm

Disk space can be easily controlled via OpenVZ but I have yet to find anyone to actually explain what the heck to “really” do when you need to add more! Everything I have found about OpenVZ just explains the parameters and never shows you how to do it easily. When I need to adjust disk space on an VPS it is usually when I have someone beating up my ear on the phone or my IM so I needed a fast way to expand the disk without worrying about the details.

There are three parameters in OpenVZ which are directly related to disk usage. They are disk_quota, diskspace and diskinodes. NOTE: there are a lot of other parameters that control and effect the disk but this tutorial will only cover the basics!

The parameter disk_quota is a YES or NO value which disables the file system quotas; if you are not worried about the quotas set it to NO and stop reading. Otherwise; leave it set at YES and continue.

The parameter diskspace is the count of 1K blocks available to the VPS in a soft and hard limit. The hard limit is a stop point similar to filling up a physical disk – when you are out, you are out. The soft limit is when the bean counters get angry and the quotatime timer starts. On a basic installation and VPS setup you will have a 1048576 1K blocks as a soft limit and 1153024 1K blocks as a hard limit. The numbers are not crazy as they are derived from base2. Thus, 1048576 1K blocks is 1GB of disk space. Add an additional 10.2MB to the disk space and you arrive at the 1048576 1K blocks. These are the basic numbers for the basic template that ships with OpenVZ.

The parameter diskinodes is the total number of files, directories and links you can have in the container. Think of them as Post-it® notes and each file, directory and link gets a single note. The default basic number is 200,000 for a soft limit for 1GB of disk space and 220,000 for the hard limit. Normally *nix systems will set aside enough inodes for one inode per 4K disk space block. In the default template for OpenVZ they are setting aside enough inodes for 5.2K blocks. Which I’ll write off as either (a) a magic number or (b) a unique calculation I am not familiar with. Thus, because the 4K block inode count for 1GB of disk space should be 262,144 inodes we’ll use the default template values for our calculations and simply multiply times the number of GB requested.

So…

Now…

The question is how do you adjust them quickly and easily. In this example we are going to work with units of GBs. If you need more granularity you will need to divide it back out to MBs but Gigabytes works great for our needs:

First, we need to define the soft and hard limits, next we apply the updated diskspace numbers and finally set the inode numbers correctly based on the ratio we know from the default template:

Here are the commands (and note below for a quick and easy Perl script):

cid=1324
gb=5
vzctl set ${cid} --diskspace $((1048576 * ${gb})):$((1153434 * ${gb})) --save
vzctl set ${cid} --diskinodes $((200000 * ${gb})):$((220000 * ${gb})) --save

#!/usr/bin/perl
 
# display the commands to update an OpenVZ VPS with new disk space requirements
# 2009/11/15 - Chris Schuld (chris@chrisschuld.com)
 
use strict;
 
print "Enter VPS CID: "; my $_CID = <STDIN>; chomp($_CID);
print "Enter SOFT Diskspace Limit (ex 10GB):"; my $_SOFT = <STDIN>; chomp($_SOFT); $_SOFT =~ s/[^0-9]//g;
print "Enter HARD Diskspace Limit (ex 11GB):"; my $_HARD = <STDIN>; chomp($_HARD); $_HARD =~ s/[^0-9]//g;
my $_INODE_SOFT = ( 200000 * $_SOFT );
my $_INODE_HARD = ( 220000 * $_HARD );
print "Run these commands:\n";
print "vzctl set $_CID --diskspace ".$_SOFT."G:".$_HARD."G --save\n";
print "vzctl set $_CID --diskinodes $_INODE_SOFT:$_INODE_HARD --save\n";

There are a few items required for installing vzdump for OpenVZ on CentOS.

First, you’ll need an MTA – I suggest making sure you have postfix installed; if you have postfix installed the initial RPM requirement for “MTA” will be handled for you. Next, you’ll need cstream. This installation is slightly more tricky because (as far as I know) there is no real way to gain this from yum unless you use the DAG Wieers repo. Also, depending on what you have already installed you will likely need the Simple Locking file I/O library for Perl.

Here is how you get vzdump on a clean version of CentOS (via the hostnode):

rpm -ivh "ftp://ftp.pbone.net/mirror/ftp.freshrpms.net/pub/freshrpms/pub/dag/redhat/el5/en/x86_64/RPMS.dag/cstream-2.7.4-3.el5.rf.x86_64.rpm"
wget http://dag.wieers.com/rpm/packages/perl-LockFile-Simple/perl-LockFile-Simple-0.206-1.el5.rf.noarch.rpm
rpm -ivh perl-LockFile-Simple-0.206-1.el5.rf.noarch.rpm
/bin/rm perl-LockFile-Simple-0.206-1.el5.rf.noarch.rpm
rpm -ivh "http://www.proxmox.com/cms_proxmox/cms/upload/vzdump/vzdump-1.2-4.noarch.rpm"

Since version 1.2-4 of vzdump the location of the modules is not “automatic” and have found it necessary to export the location of the PVE libraries that vzdump requires via this command:

export PERL5LIB=/usr/share/perl5/

All said and done there has to be a better way to do this… anyone… anyone??

Here are the commands to install Webmin via Yum:

echo -e "[Webmin]\nname=Webmin Distribution Neutral\nbaseurl=http://download.webmin.com/download/yum\nenabled=1" > /etc/yum.repos.d/webmin.repo
rpm --import http://www.webmin.com/jcameron-key.asc
yum install webmin

A while back I wrote an article on Removing Images from a WordPress Post. Sebastian asked an interesting question; he wanted to remove everything but the images. This is actually pretty straightforward; here is how you do it:

 
.
.
.
<?php
           $beforeEachImage = "<div>";
           $afterEachImage = "</div>";
           preg_match_all("/(<img [^>]*>)/",get_the_content(),$matches,PREG_PATTERN_ORDER);
           for( $i=0; isset($matches[1]) && $i < count($matches[1]); $i++ ) {
                 echo $beforeEachImage . $matches[1][$i] . $afterEachImage;
           }
?>
.
.
.

Keep in mind this code needs to be in the WordPress Loop and you can control what is around each image using the variables beforeEachImage and afterEachImage above.

Version 1.6 of Browser.php has been released with a lot of updates: http://chrisschuld.com/projects/browser-php-detecting-a-users-browser-from-php/

For those of you who detect Opera 10’s user agent, the Opera team has provide some “fun” for all of us. In my Browser project I started getting feedback that it was broken. At the 10,000′ level, it was defintely broken because the Browser project was returning version 9.8 for Opera version 10.

This is because the Opera dev team decided to leave the version 9.8 user agent string the same and tack on version 10 to end of the string. You can read more about it on their blog.

For those of you using my Browser project have no fear; the new version (1.6+) handles the oddity!

All of our servers are currently based off of the Phoenix, Arizona, USA Timezone. This script allows this conversion from each HN (Host Node):

 
#!/bin/bash
for f in `ls /vz/private`
do
  vzctl exec $f rm -f /etc/localtime 2>/dev/null
  vzctl exec $f ln -s /usr/share/zoneinfo/America/Phoenix /etc/localtime
done

From time to time I had have to move one installation of WordPress from one domain (let’s call it domain A) to a new domain (let’s call it domain B). Because WordPress embeds the domain all over the data schema (not faulting; simply disclosing) you have to make a lot of dB changes for the updated site location to function. Here is the quick and dirty way to move the data:

UPDATE wp_posts SET post_content = REPLACE(post_content,"[OLD_DOMAIN]","[NEW_DOMAIN]");
UPDATE wp_posts SET guid = REPLACE(guid,"[OLD_DOMAIN]","[NEW_DOMAIN]");
UPDATE wp_options SET option_value = REPLACE(option_value,"[OLD_DOMAIN]","[NEW_DOMAIN]");
UPDATE wp_postmeta SET meta_value = REPLACE(meta_value,"[OLD_DOMAIN]","[NEW_DOMAIN]");

Finally, for the final bit of trickery if you are using Advanced Caching on the site there is a great place where the localized PATH is hard coded. Edit your new and updated path on file advanced-cache.php

vi wp-content/advanced-cache.php