vmware tools install (or vmware-config-tools.pl) hangs after X config

I was updating vmware-tools on some old Linux installations of ours, using a tarball I downloaded from VMware. Once I unzipped the tarball, I ran the installer and told it to take the defaults:
./vmware-install.pl -d

Got to one machine in particular and it hung right after this text:
X is running fine with the new config file

Checked the processes and it seemed “mkinitrd --help” was holding things up. Killed it (just to see what happened) and another “mkinitrd” came up that wanted to build for the installed kernel. But that also hung. Killed the second “mkinitrd” and it warned me about not having a proper initrd and all the horrible things that might happen in life if I rebooted with this botched boot configuration.

So I ran vmware-config-tools.pl manually, then I ran strace on that process, and it occasionally did a call-out to an old AD/LDAP server of ours that is deprecated. What the heck? Also saw it read from /etc/ldap.conf as it did this.

So I killed the config script and moved /etc/ldap.conf to /etc/oldldap.conf. Re-ran the installer, and “whee” it all worked.

Didn’t feel like digging into it further, but I did get the tools installed and configured.

YMMV

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