Changing WordPress permalinks from default to postname

Had an issue on a WordPress site after I changed the permalinks to “%postname%” from the default.  Immediately after the change, all my wonderful posts gave 404 when I clicked on them.

So I researched it a bit and found some good recommendations (make sure mod_rewrite is present, check permissions on .htaccess).  Initially it looked like a simple fix – the .htaccess file needed to be populated (I didn’t allow the web server daemon write access to that file or the site’s directory).  So I added the recommended code to that file directly (by the way, that file needs to be in DocumentRoot for your site).  However, that still didn’t fix it.

So I poked around some more and a couple of sites recommended checking AllowOverride and similar settings.  In my /etc/httpd/conf/httpd.conf, AllowOverride was set to None.

My sites are in a separate file in /etc/httpd/conf.d so I opened that file and added the following under the VirtualHost section for that site:

<Directory "/site/home">
AllowOverride Options FileInfo
Options FollowSymLinks
RewriteEngine On
</Directory>

(I obfuscated the path above, so in your file, whether /etc/httpd/conf/httpd.conf or a site-specific file in /etc/httpd/conf.d, Directory will certainly not be “/site/home“).  You can set AllowOverride to All, but do so at your own risk.

Then I bounced httpd and ta-da, it worked.

So, in summary:

-Check to make sure your web server loads mod_rewrite
-Set .htaccess (found in your site’s root, DocumentRoot) to writable so WordPress can modify it, OR modify it yourself by pasting in the code that WordPress shows you
-In your site’s config (either /etc/httpd/conf/httpd.conf or your site-specific file in /etc/httpd/conf.d), add:

<Directory "/site/home">
AllowOverride Options FileInfo
Options FollowSymLinks
RewriteEngine On
</Directory>

-Bounce the web service

 

What to do when grub2 does not honor the default kernel choice

Recently I updated a Fedora 22 system to kernel 4.2.5 (from 4.1).  That broke a few things, because one of my apps needed kernel-specific modules compiled.  Something in this kernel version was too out of whack for me to fix it on the fly, so I decided to boot to the previous kernel until I could find a workaround or patch.

Not so fast.

In the old days (of grub pre-v2), I could do this easily.  But since we’re now on grub2, this became a little more complex.  Even with early versions of grub2 this would have been simpler.  But currently, grub2 uses variables, symlinks, and some black magic to work.

What failed

After doing some reading and understanding that my system is using the “DEFAULT=saved” method, I was (I thought) on my way to making a simple change and rebooting.  In short, I should have been able to do something like this:

grub2-set-default "Fedora (4.1.8-200.fc22.x86_64) 22 (Twenty Two)"
grub2-mkconfig -o /boot/grub2/grub.cfg

But every time I booted, the system went right back to kernel 4.2.5.  After more digging I also checked /boot/grub2/grubenv (which is a symlink to /boot/efi/EFI/fedora/grubenv).  And it showed kernel 4.1.8 should be the default.

But it wasn’t, at least not at boot time.

So I read through Fedora’s wiki page on grub2.  And there I found a clue.  I quote:

The above method [what I tried] fails to work on some F20 systems due to a missing or improperly linked /boot/grub2/grubenv file. The /boot/grub2/grubenv is symbolic linked to /boot/efi/EFI/fedora/grubenv but /boot is not mounted at the time of booting. So grub2 does not have access to the environment variables. To fix this, change /boot/grub2/grubenv to point to ../efi/EFI/fedora/grubenv instead and your chosen default OS will boot without any problems.

So, the fix was this:

cd /boot/grub2
ln -sf ../efi/EFI/fedora/grubenv grubenv

And rebooted, and my default kernel was finally 4.1.8 again.  The reason this rarely manifests itself is that, generally, we want to boot the first kernel.  And when grub2 cannot reference files under /boot (because it isn’t mounted when grub runs), it just picks the first kernel it finds in grub.cfg and goes with it.

In summary, to change your default kernel in Fedora 22 (perhaps 20 and 21 as well), find the label of the kernel you want to change, set it to the default, make a new grub.cfg, and verify where grubenv points to.

# egrep ^menuentry /boot/grub2/grub.cfg  | awk -F\' '{print $2}'
Fedora (4.2.5-201.fc22.x86_64) 22 (Twenty Two)
Fedora (4.1.10-200.fc22.x86_64) 22 (Twenty Two)
Fedora (4.1.8-200.fc22.x86_64) 22 (Twenty Two)
Fedora (0-rescue-f22b46fe9c554c92890b4e9d760ac718) 22 (Twenty Two)
(copy the text of the kernel name to the clipboard)
# grub2-set-default "Fedora (4.1.8-200.fc22.x86_64) 22 (Twenty Two)"

And if needed:

cd /boot/grub2
ln -sf ../efi/EFI/fedora/grubenv grubenv

VMware API error: “Customization of the guest operating system ‘rhel6_64Guest’ is not supported in this configuration”

While using VMware’s API and pyVmomi to clone templates into a VM, a couple of times I have run into this error:

Cannot deploy template: Customization of the guest operating system ‘rhel6_64Guest’ is not supported in this configuration. Microsoft Vista (TM) and Linux guests with Logical Volume Manager are supported only for recent ESX host and VMware Tools versions. Refer to vCenter documentation for supported configurations.

For me this happened when (A) I was cloning a RHEL 64-bit template (this occurred both with RHEL 6 and RHEL 7 but for entirely different reasons on each), and (B) I was using a customization specification. We had just stood up a new datacenter and I was laying the groundwork for creating masses of virtual machines from a command-line. A Linux command-line, mind you. Not from PowerCLI or PowerShell (which are certainly powerful, but hey, I’m a Linux guy).

In my case, the error had nothing to do with logical volumes (I suspect that’s true for most people who have run across this message). I have a script that has been happily cloning 64-bit LVM-based RHEL 6 templates in multiple vCenters that are on versions between 5.0 and 5.5. Since my customization spec was setting network parameters, I suspected that’s where the root of this problem was. So, before you go chasing that wild goose of LVM incompatibility, or telling vCenter your template is RHEL 5, I have a couple of recommendations.

In most of these cases, you’ll need to convert your template to a VM and power it up, then make the changes, shut it down, and convert it back to a template.

1. If this is happening with RHEL 7, make sure the vCenter is a new enough version to support it

One of our vCenters had not been updated in some time.  When I tried cloning the same RHEL 7 template from an updated vCenter (and had the correct VMware tools installed) all went well.

2. If this is happening with RHEL 6, Make sure your version is  6.4 or later

There were some updates in 6.4 that greatly improved RHEL’s interaction with VMware’s hypervisor, including at the NIC level.

3. Install VMware tools on the template VM

This is the biggest source of problems.  If you’re using  customization specifications during cloning, VMware cannot do the work unless the tools are installed in the image from which you’re cloning.  I like using the “3rd party” tools that you can get from VMware’s own repo. You can clone that repo into your own, or just use theirs. You can even bring it into Satellite or Spacewalk, either as an external repo or a software channel. Or maybe you like doing it the old fashioned way and installing them from vCenter. Bottom line – install those tools!

For RHEL 6 that means “vmware-tools-plugins-deployPkg” has to be present.  It will be if you simply install “vmware-tools-esx-nox” (I also include vmware-tools-esx-kmods).

For RHEL 7, you need open-vm-tools (which comes standard with RHEL 7) and open-vm-tools-deployPkg (which comes from VMware).  Note: If you’re using CentOS 7, open-vm-tools-deployPkg requires open-vm-tools < 9.5.  This created issues for me trying to install in CentOS 7.2, which ships only 9.10.  The solution?  Disable all repos except vmware-tools and C7.1.1503-base from the “vault” when you do the installation.
yum –disablerepo=* –enablerepo=vmware-tools –enablerepo=C7.1.1503-base install open-vm-tools-deployPkg

By the way, the symptoms of this in RHEL 7?  Aside from the customization error, you’ll have network cards named ens32 or ens33 in the template, but ens160 in the clone.  And obviously, networking will be broken.

Also, get rid of the udev stuff that sometimes messes up your NIC settings

This applies more to RHEL 6.  If you clone from a template, VMware will naturally give the new machine a new MAC address for any NICs in the template. In a single-NIC configuration, when udev sees this, it says, “Hey, I this isn’t the MAC for eth0, so let me make a configuration for eth1 using this new MAC and UUID.” You can help yourself here by doing the following (per VMware’s advice):

-remove /etc/udev/rules.d/70-persistent-net.rules

-remove /lib/udev/rules.d/75-persistent-net-generator.rules

You might not need to remove /lib/udev/rules.d/75-persistent-net-generator.rules, but I don’t think it’ll hurt. When I did these things to my RHEL 6 template, I was able to clone just fine using the API again.

How to disable that pesky auto-comment in vim

Been using a newer release of vim and dislike how, after you type a comment on a line, vim assumes you want the next line commented also? Or, more frustrating, have you pasted something you copied from another file or from the web, only to find vim helpfully commented and indented a bunch of lines? Here’s a quick fix. Place it in your vimrc:

autocmd FileType * setlocal formatoptions-=c formatoptions-=r formatoptions-=o

Source: http://vim.wikia.com/wiki/Disable_automatic_comment_insertion

Working with VMware’s API via Python

(Update – Sept. 2, 2015)
In some of the community samples, someone wrote a nice function to get different objects.

As part of streamlining VM creation, I began working with VMware’s API.  The first thing I learned is that there are multiple API implementations.  Until recently, while VMware had their own Python API, they kept it private and did not officially support it.  That prompted folks to write their own bindings and share them via Google Code in a project called pySphere (https://code.google.com/p/pysphere/).  In early 2014, however, VMware did release their bindings to the public (https://github.com/vmware/pyvmomi).

Wanting to go the official route, I downloaded pyVmomi and got to work.  From the beginning I noticed that this API is very thorough and robust.  The downside of that is that it is also very complex and can sometimes be difficult to know just how to get and do what you need.  Fortunately there are many good samples included in the code.  So, while it takes a lot of effort to get things just right, once you get the objects and methods sorted out, it works well.  And fortunately the documentation (vmware python API doc), if you can stay awake while you wade through it, will tell you what you need.

I won’t go into how I did each and every thing.  The goal of this document is to give the reader a decent understanding of how to create and manipulate objects, as well as how to make the method calls.

What to import

The basic script should have the following items.

  • from pyVmomi import vim – this module contains what we need to create objects and make calls
  • from tools import tasks – if we’re going to create anything in vCenter, this module allows us to designate the creation process as a task, then wait for it to finish
  • from pyVim import connect – needed to login
  • import atexit – this module allows us to specify that, when we logout, certain things should happen (such as logging out)
  • import argparse – if we’re going to accept command-line input, this module greatly simplifies managing that input

Building objects

To get information (such as a list of VMs) or do things (such as create a VM), the system requires a session to be established and objects to be passed to the method calls.  Establishing a session is as simple as logging in, which is covered in the sample code included in the project, so I won’t cover that here.  The samples refer to the session as a service instance, often shortened as “si”.  For this document, you  will notice the service-instance object referred to as “si”.

A few basic objects

Once we’re logged in we need a few fundamental objects from which we can build others.  For my scripts, I use these:

  • atexit.register(connect.Disconnect, si)
  • content = si.RetrieveContent()
  • datacenter = content.rootFolder.childEntity[0]
  • hosts = datacenter.hostFolder.childEntity

These are mostly self-explanatory. The second item, “content,” is essentially “all the things” in this vCenter.  From those we get access to pretty much any object that the API allows us to reference.

The fun begins

The challenge began when I wanted to create a new VM by cloning a template.  While the API is, as I said, very thorough and complex, the documentation is equally so.  But it’s also confusing at times.  I’ll demonstrate using parts of the cloning process.

While there is a method called CloneVM_Task, that is the wrong call if you want your VM placed in a certain datastore cluster but do not want to specify which store it lands it.  CloneVM_Task forces you to specify the specific datastore for your new VM.  The proper way to do that is with a combination of RecommendDatastores and ApplyStorageDrsRecommendation_Task.

This method requires one object (called a parameter in the doc).  While the documentation page lists two parameters (_this and storageSpec), the first of those is really a parent object against which we run the method.  I’ll elaborate on that in a second.  But first let me point out that any parameter named “_this” in the documentation means you call the method in question by appending it to an object to which “_this” refers.  Demonstration:

RecommendDatastores lists two parameters: _this and storageSpec.  We actually call it like so:
storage_rec = content.storageResourceManager.RecommendDatastores(storageSpec=storagespec)
So, “_this” gets translated into ” content.storageResourceManager” and we call the method using storageSpec, which is an object we have to have already built.

Now, how the heck would you have known that?  Well, you wouldn’t intrinsically.  There are three ways to find that out: either you figure it out from the included samples, you find it from samples in the discussion lists for pysphere (because pysphere is pretty close to pyVmomi), or you catch a clue from the documentation page.  In this case, the documentation URL for this method ends with this text:
vim.StorageResourceManager.html#recommendDatastores
Additionally, in the left pane of the documentation the method lists its parent namespace in parentheses, i.e. “RecommendDatastores (in StorageResourceManager)”

But you might not have guessed it is called under the “content” object without further digging or experimentation.  Plainly put, it just takes some intuition and hacking sometimes to get this right.

And that’s just the tip of the iceberg.  You could be forgiven for thinking, “Oh, this only has one object.  No worries.”  Why?  Because “storageSpec” contains a lot of other objects.  And many of those contain other objects, etc.  And many of those objects must first be instantiated (a decidedly object-oriented programming term) by a method before they can be used.

Ready to quit yet?  Don’t.  There’s a good payoff to sticking with this stuff.  At the least it will stretch your mind and deepen your understanding of how VMware works under the hood.  And what bit-head doesn’t want that?

Looking at storageSpec, it wants an object of type “StoragePlacementSpec“.  As we drill into that, we see this object consists of several other objects.  And, as I said, some of them have many more objects in their definition.  Let’s pick a somewhat simple one: podSelectionSpec.  This particular data type (StorageDrsPodSelectionSpec) tells VMware which datastore cluster we want to use for the new VM.  Of the two objects that this data type uses, we are only interested in the second one, storagePod.

Unfortunately, because these are custom data types, we cannot simply say
storagePod = “MyStoragePod” and expect the API to intuit what we want.  In place of “MyStoragePod” we need a data type of StoragePod which points to the pod named “MyStoragePod”.  In our case, from the samples I took a bit of code which created a view of the storage pods, then I parsed through that list and compared each pod name to our target (“MyStoragePod”) and, when we got a match, assigned that to a variable named “pod”.  So, below, first we create a view, then we destroy the view so we do not consume too many resources in the vHost.   And finally we parse through the view until we find a match.

 obj_view = content.viewManager.CreateContainerView(content.rootFolder,[vim.StoragePod],True)
 ds_cluster_list = obj_view.view
 obj_view.Destroy()
 for ds in ds_cluster_list:
     if ds.name == "MyStoragePod":
         pod = ds
         break
 # a blank object of type PodSelectionSpec
 podsel = vim.storageDrs.PodSelectionSpec()
 podsel.storagePod = pod

And thus we have our pod selection.  To add that to our primary object, a StoragePlacementSpec data type, I create the blank object, then add to it:

# a blank type of StoragePlacementSpec
 storagespec = vim.storageDrs.StoragePlacementSpec()
 storagespec.podSelectionSpec = podsel

So, in short, we first create a blank parent object (similar to initializing a variable in other languages), then we assign the child object to be a part of the parent object.  Again, the tricky part is finding a way to identify those child objects.

Update – Sept. 2, 2014 –
def get_obj(content, vimtype, name):
    """
    Return an object by name, if name is None the
    first found object is returned
    """
    obj = None
    container = content.viewManager.CreateContainerView(
        content.rootFolder, vimtype, True)
    for c in container.view:
        if name:
            if c.name == name:
                obj = c
                break
        else:
            obj = c
            break

    return obj

Now all you have to do is call that function with the proper “vimtype”.  A few that are useful:

# gets a  datastore cluster (storage pod) matching "DS-Cluster1"
cluster = get_obj(content, [vim.StoragePod], "DS-Cluster1")
# gets a host cluster matching "My-Host-Cluster"
cluster = get_obj(content, [vim.ClusterComputeResource], "My-Host-Cluster")
# gets a  resource pool matching "My-Resource-Pool"
cluster = get_obj(content, [vim.ResourcePool], "My-Resource-Pool")
# gets a  datastore matching "Datastore1"
cluster = get_obj(content, [vim.Datastore], "Datastore1")

Doing stuff to the objects

Once we have built our objects, we can create the VM.  Or, in our case, clone a template into a VM.  Before I discuss the methods, here are the steps I used to create the VM object.

 template = getTemplate(si, tierdata['template'])
 if template == None:
    print "Unable to find template matching %s" % template
# make an empty clone spec object, then customize it
 print("Checkpoint - getting customization data")
 cloneSpec = vim.vm.CloneSpec()
 custSpec = content.customizationSpecManager.GetCustomizationSpec(tierdata['customization_spec']) # dev_gold
 custSpec.spec.nicSettingMap[0].adapter.ip.ipAddress = VMip
 custSpec.spec.nicSettingMap[0].adapter.gateway = gateway
 cloneSpec.customization = custSpec.spec
 # make an empty config spec, then customize it
 config = vim.vm.ConfigSpec()
 config.name = machine_name
 cloneSpec.config = config
 location = vim.vm.RelocateSpec()
 cloneSpec.location = location
 # if we cannot find resource pool with name given by user, use default for this vHost
 print("Checkpoint - getting resource pool data")
 resourcePool = getResourcePool(hosts,tierdata['resource_pool']) # "MyStoragePod"
 if resourcePool == None:
    print("Unable to find resource pool named %s" % tierdata['resource_pool']) # MyStoragePod
    sys.exit(1)
 cloneSpec.location.pool = resourcePool
 cloneSpec.powerOn = powerOn
 # using name of target cluster (i.e. MyStoragePod), parse thru clusters until we find a match
 print("Checkpoint - getting datastore cluster data")
 obj_view = content.viewManager.CreateContainerView(content.rootFolder,[vim.StoragePod],True)
 ds_cluster_list = obj_view.view
 obj_view.Destroy()
 for ds in ds_cluster_list:
    if ds.name == tierdata['datastore']: # MyStoragePod
        pod = ds
        break
 # set thin provisioning on disks
 device = vim.vm.device.VirtualDevice()
 vdisk = vim.vm.device.VirtualDisk()
 backing = vim.vm.device.VirtualDisk.FlatVer2BackingInfo()
 vdisk.backing = backing
 vdisk.backing.thinProvisioned = True
 vdisk.key = -100
 dspec = vim.vm.device.VirtualDeviceSpec()
 dspec.device = vdisk
 config.deviceChange = [dspec]
 # make an empty pod selection spec, then customize it 
 podsel = vim.storageDrs.PodSelectionSpec()
 podsel.storagePod = pod
 # make an empty storage placement spec, then customize it 
 storagespec = vim.storageDrs.StoragePlacementSpec()
 storagespec.podSelectionSpec = podsel
 storagespec.vm = template
 storagespec.type = 'clone'
 print("Checkpoint - getting destination folder data")
 storagespec.folder = getDestFolder(datacenter, "Development", "Applications")
 storagespec.cloneSpec = cloneSpec
 storagespec.cloneName = machine_name
 storagespec.configSpec = config
'''Once that is done, we have built our VM object.  The method we use to
 create the VM is "RecommendDatastores", which we call like so:'''
rec = content.storageResourceManager.RecommendDatastores(storageSpec=storagespec)
'''This asks vCenter to tell us which datastore within the cluster it prefers 
to use for this host.  That method returns an object, which I chose to 
call "rec".  One of the recommendation objects is a key, which we will 
use to actually apply the recommendation.  Interesting note: when you 
create a VM from a template within the GUI, you see a similar process.  
You select a datastore and the GUI returns recommendations.
To apply the recommendation, we use another set of objects VMware provided known as tasks.
Using that framework, we are able to tell the script to wait until the task finishes before continuing.'''
rec_key = rec.recommendations[0].key
task = content.storageResourceManager.ApplyStorageDrsRecommendation_Task(rec_key)
tasks.wait_for_tasks(si, [task])

 

(Note that VMware will proceed with the task whether we execute the last step or not.  It is wise and courteous on our part to let it finish each VM creation before proceeding to the next.)

At this point, in the GUI you will see the clone process taking place.  It typically finishes within 2-3 minutes.  If there are any errors, you will see those in the GUI as well.  You can copy the text of them for research.  Additionally, the Python code will throw an exception which usually matches the GUI message fairly well.

How I got my StartSSL certificates to work with Thunderbird

Short version

(During a brief period where I used StartSSL for my SSL certs…)

Had a problem with my mail server.  Thunderbird was not accepting the Class 1 cert I got from StartCom.  To fix it, I added lines to /etc/dovecot.conf and /etc/postfix/main.cf.  Assume the intermediate CA cert is named “sub.class1.server.ca.pem“.

For dovecot, in /etc/dovecot.conf:

ssl_ca_file = /path/to/certs/sub.class1.server.ca.pem

For postfix, in /etc/postfix/main.cf:

smtpd_tls_CAfile = /path/to/certs/sub.class1.server.ca.pem

Then I restarted both services.

How to install VMware tools in CentOS 5 or 6

1. Install the repo

Actually before you set up the repo, you need the public keys:
# rpm –import https://packages.vmware.com/tools/keys/VMWARE-PACKAGING-GPG-DSA-KEY.pub
# rpm –import https://packages.vmware.com/tools/keys/VMWARE-PACKAGING-GPG-RSA-KEY.pub

Then you can set up the repo by hand or with their RPM.

By repo RPM:

You can do this by installing the repo RPM from VMware:
# yum install https://packages.vmware.com/tools/releases/latest/repos/vmware-tools-repo-RHEL6-10.0.9-1.el6.x86_64.rpm
(or yum install https://packages.vmware.com/tools/releases/latest/repos/vmware-tools-repo-RHEL5-10.0.9-1.el5.x86_64.rpm)

By hand:

Create /etc/yum.repos.d/vmware-tools.repo.  Contents should be as follows.

Note: Make sure the number after “esx” reflects your current version of ESX.  To see a list of available versions, point your browser to http://packages.vmware.com/tools/esx

Also, if you’re installing in RHEL 5 or CentOS 5, change the ‘rhel6’ to ‘rhel5’.

/etc/yum.repos.d/vmware-tools.repo:
 [vmware-tools]
 name=VMware Tools
 baseurl=http://packages.vmware.com/tools/esx/5.0/rhel6/$basearch
 enabled=1
 gpgcheck=1

2. Install the public keys and then tools
# yum -y install vmware-tools-esx-kmods vmware-tools-esx

3. Make sure the services are set to run at boot
# chkconfig vmware-tools-services on

4. If the tools are not already running, start them:
# service vmware-tools-services status
# service vmware-tools-services start

 

How to setup EPEL repos on CentOS

If you’re wanting packages from the EPEL repos that are available to RHEL installations, it’s a simple thing to get them.

You can start at the main Fedora repository for EPEL, and work your way around.  Or if you’re in a hurry, use these instructions.
(Note: these are mirror sites; if they are inaccessible, refer back to the main repo linked abve, and you’ll get redirected to a different mirror in most cases)

For CentOS 5

  1. Install the repo RPM from here.
    # rpm -ivh http://mirror.symnds.com/distributions/fedora-epel/5/x86_64/epel-release-5-4.noarch.rpm
  2. Install the GPG key from here.
    # rpm --import http://mirror.symnds.com/distributions/fedora-epel/RPM-GPG-KEY-EPEL-5

For CentOS 6

  1. Install the repo RPM from here.
    # rpm -ivh http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/epel-release-6-8.noarch.rpm
  2. Install the GPG key from here.
    # rpm --import http://mirror.symnds.com/distributions/fedora-epel/RPM-GPG-KEY-EPEL-6

For either one, if you do not want the repo used by default when you run yum, edit /etc/yum.repos.d/epel.repo, and in the section named [epel] change enabled=1 to enabled=0
Then, to use the repo, add --enabelrepo=epel to your yum commands.  For example:
# yum --enablerepo=epel update

The time I tried compiling an RPM for syslog-ng

Introduction

Had a client for whom I wanted to install syslog-ng.  I’ve never worked with it before, but had read that it can log to a MySQL database.  The project at hand seemed like a great fit for just such a thing, so off I went to get syslog-ng.

(Update on Nov 28, 2012: When I realized that rsyslog comes with RHEL 5 and supports MySQL out of the box, I switched the project to it instead)

Build my own?  No problem.

Having worked with Linx and open source for nearly 2 decades now, I’m accustomed to having a look to find a software package occasionally.  Since most of that time has been spent working with Red Hat, Fedora, and CentOS, I’m also accustomed to having to go out of my way to find RPM versions of packages.  It’s common to find that someone who maintains an application doesn’t by default make an RPM for it.  Sometimes that’s because their experience is in another flavor of Linux or UNIX that doesn’t natively use RPMs (aka Debian, Slackware, *BSD), or because they don’t have time to make an RPM.

Since I didn’t find an RPM readily available for this install (on CentOS 5.8), I started looking around.  My usual sources (rpmforge, etc.) didn’t yield anything.  So I turned to rpmfind.net.  Right away I saw that there is a package available for RHEL 5, thus presumably for CentOS as well.  Unfortunately, though, the CentOs extras repo didn’t have the package.  Bummer.  But the sources for Red Hat’s EPEL packages (http://download.fedoraproject.org/pub/epel/5/SRPMS) had a source RPM.  For me, that’s usually enough to get started.  So, a quick wget and I was on my way:

$ wget http://download.fedoraproject.org/pub/epel/4/SRPMS/syslog-ng-2.1.4-1.el4.src.rpm

From here I usually do either:

rpmbuild --rebuild syslog-ng-2.1.4-1.el4.src.rpm

or I install the src.rpm and do:

rpmbuild -bb /path/to/syslog-ng.spec

But it wasn’t that simple

To make an incredibly long story a bit shorter, I had build errors.  And the reason I did was that this package wanted a devel package that I couldn’t find right away (try finding tcp_wrappers-devel-7.6-40).  What I ended up doing was finding the source RPM for tcp_wrappers and building a new version of it.  Also, I had to build the eventlog RPM that goes along with syslog-ng (same company makes both). Great!  Now all I had to do was build syslog-ng, finally!

Except that it kept croaking, telling me “ld: cannot find -lwrap“.  Now, I thought this thing was looking for libwrap.so, so I made sure it (or some symlink to it) was in all the common lib directories.  Nope, no luck.  Ah, I need to run ldconfig, I thought.  Nope, didn’t help.

Next I popped open the source tarball and look in it.  I saw some references to /usr/local/lib.  I changed those to /usr/lib, re-packed the tarbarll, stuck it in the SOURCES directory in my build environment, and ran it again….nope.  After more digging in Makefiles and configure files, I found that it apparently wanted libwrap.a to be in the lib paths.  But…my tcp_wrappers packages did not install that file.  Odd.  I updated my locate database and did ‘locate libwrap.a‘.  That file existed only in the RPM BUILD directory.  Looking in the spec file, I found that it had been removed around 7.6-42 by the folks at Red Hat.  Perhaps they were purging out old static libraries.  I manipulated the spec file to make it install in /usr/lib and…

Finally

Finally syslog-ng compiled.  So, to get syslog-ng to build, I had to install and/or build these packages:

eventlog-0.2.12-1.x86_64
eventlog-devel-0.2.12-1.x86_64
eventlog-static-0.2.12-1.x86_64
libnet-1.1.5-1.el5.x86_64
libnet-devel-1.1.5-1.el5.x86_64
tcp_wrappers-7.6-59.x86_64
tcp_wrappers-devel-7.6-59.x86_64
tcp_wrappers-libs-7.6-59.x86_64

(the version of tcp_wrappers was 7.6-57 when I got the SRPM, but I bumped the version a couple of times to account for changes I made in the spec file)

Now, this was just on my build server.  On the actual client machine, I installed these RPMs:

 eventlog
eventlog-devel
eventlog-static
syslog-ng
libnet        

The libnet package was already installed, so it was an update.

What’s next?

I know that version 3.2 of syslog-ng comes with RHEL/CentOS 6 EPEL.  I’m going to see if I can get it to build for a CentOS 5 environment, since 2.1 seems rather old by comparison.

Additionally, now I will be working to get the service working with mysql.  But that’s probably another post…  🙂

How I installed WordPress 3.4.2 on CentOS 5.8

Had a real adventure getting a WordPress site going on a CentOS 5.8 LAMP server. It came down to two major areas: packages and permissions.

Packages

I asked the hosting provider to install pretty much just the base package group, knowing we could easily add on from there without having a lot of extra fluff. After a fair amount of troubleshooting (and very patient help from the site developer), I ended up installing the list below. Some of them may be unnecessary in the end, and many were pulled in as dependencies, but we got there.

perl-DBD-MySQL-3.0007-2.el5.x86_64
mysql-server-5.0.95-1.el5_7.1.x86_64
mod_auth_mysql-3.0.0-3.2.el5_3.x86_64
ntp-4.2.2p1-15.el5.centos.1.x86_64
php53-common-5.3.3-13.el5_8.x86_64
php53-cli-5.3.3-13.el5_8.x86_64
php53-pdo-5.3.3-13.el5_8.x86_64
php53-mbstring-5.3.3-13.el5_8.x86_64
php53-mysql-5.3.3-13.el5_8.x86_64
php53-5.3.3-13.el5_8.x86_64
php53-xmlrpc-5.3.3-13.el5_8.x86_64
php53-xml-5.3.3-13.el5_8.x86_64
php53-gd-5.3.3-13.el5_8.x86_64
gd-progs-2.0.33-9.4.el5_4.2.x86_64
libwmf-0.2.8.4-10.2.x86_64
libcroco-0.6.1-2.1.x86_64
lcms-1.18-0.1.beta1.el5_3.2.x86_64
libgsf-1.14.1-6.1.x86_64
librsvg2-2.16.1-1.el5.x86_64
urw-fonts-2.3-6.1.1.noarch
ghostscript-8.70-14.el5_8.1.x86_64
ghostscript-fonts-5.50-13.1.1.noarch
ImageMagick-6.2.8.0-15.el5_8.x86_64
libdrm-2.0.2-1.1.x86_64
libXxf86vm-1.0.1-3.1.x86_64
mesa-libGL-6.5.1-7.10.el5.x86_64
libjpeg-devel-6b-37.x86_64
libXau-devel-1.0.1-3.1.x86_64
bzip2-devel-1.0.3-6.el5_5.x86_64
ghostscript-devel-8.70-14.el5_8.1.x86_64
libtiff-devel-3.8.2-15.el5_8.x86_64
lcms-devel-1.18-0.1.beta1.el5_3.2.x86_64
xorg-x11-proto-devel-7.1-13.el5.x86_64
libXdmcp-devel-1.0.1-2.1.x86_64
libX11-devel-1.0.3-11.el5_7.1.x86_64
libXext-devel-1.0.1-2.1.x86_64
libICE-devel-1.0.1-2.1.x86_64
libSM-devel-1.0.1-3.1.x86_64
libXt-devel-1.0.2-3.2.el5.x86_64
mesa-libGL-devel-6.5.1-7.10.el5.x86_64
ImageMagick-devel-6.2.8.0-15.el5_8.x86_64
imake-1.0.2-3.x86_64
autoconf-2.59-12.noarch
automake-1.9.6-2.3.el5.noarch
php53-devel-5.3.3-13.el5_8.x86_64
php-pear-1.4.9-8.el5.noarch

Also, I had to run ‘pecl install imagick‘.  Newer versions of WordPress require PHP 5.2 and newer.  CentOS provides 5.1 by default, but Red Hat back-ported 5.3 as php53 to accommodate the fact that so many things need it.  One major discovery was that image resizing will break without ‘gd’ support.  This came thru the php53-gd package, as well as the ImageMagic stuff.

Permissions, ownership, etc.

Like many web hosting setups, the apache user needs to be able to read directories, execute files, and in some cases write things.  After lots of trial and error, we settled on these principles:

  • The directory wp-content (and its subdirectories) is owned by the site user, and is in the apache group
  • The site owner is a member of the apache group as an additional group (i.e. usermod -a -G apache user).  You could also just make the apache group the primary group of the site user (usermod -g apache user).
  • All directories under wp-content are setgid (chmod g+s), and are mode 775.
  • All files are mode 664 (644 if you’re a bit paranoid, and for all .php files, but keep an eye out for things that break).