The errors associated with this issue are a standard 403 on the client side. On the server side you get “pcfg_openfile: unable to check htaccess file, ensure it is readable”.

In my quest to fix the issue, I double checked permissions to ensure that they were correct. They were. I double checked that the apache group existed and was working correctly. It was. I searched high and low for a fix for this issue. I even wrote a support request to the people over at Nagios right before I uninstalled it out of anger and spite (which didn’t fix the issue either BTW). Sadly, about 10 minutes after hitting the send button, I had a thought.

The way that Virtualmin works is to include the apache user in the groups it creates for hosting accounts. It appears that Nagios removed the apache user from all groups except for the one that it created. Good times huh?

The easy way to fix it on a small box is to add the apache user back to the groups for your hosting users. If you have a larger box, go ahead and script it. After you are done getting apache added back to your hosted groups, go ahead and restart Apache and all should be good in the world again.

Oh yeah. A message to the good folks over at Nagios. You have known about this issue for quite some time due to the multitude of Plesk, CPanel and Virtualmin users that have asked about it or related issues. Why don’t you go ahead and fix it? You lost a potential paying customer today because this simple issue has not been resolved.

All done. Ciao all.

Note that I am doing all of this from the command line. If you care to survive the Linux world, you should at least have a vague idea of how to use the command line. A terminal from within X will work fine as well for these steps.

Also note that this will work with MOST distros out there. I have yet to see a problem with any that I have tried, but I mostly work in the RPM world, so my exposure to other distros is somewhat limited.

Get logged in and open a terminal window if your system starts X automatically. If you need a tutorial on how to do that, google will be your friend for a while. Before we actually edit anything, we will be finding out what groups your user belongs to you will be looking for a couple of them that are quite important. “wheel” and whatever group mirrors your username.

[dude@computer ~]$ groups
dude wheel pulse-access pulse-rt pulse
[dude@computer ~]$

Once you are logged in and know what groups you belong to, you will edit “/etc/sudoers“. This will require you to be root to do this. (Type in “su” at the command prompt and enter the root password for the system when you are prompted.) Once you are root, enter the following command.

vim /etc/sudoers

Here is where those groups come in handy. If you had wheel listed, we simply have to uncomment a line. If not, we have to create a new line that includes your users’ group. It will make sense in a minute.

Lets start with the less likely situation that wheel was part of your groups list by default. You have two lines that you are looking for within sudoers.

# Uncomment to allow people in group wheel to run all commands
# %wheel  ALL=(ALL)       ALL

# Same thing without a password
# %wheel        ALL=(ALL)       NOPASSWD: ALL

It is quite simple at this point. If you would like to require that the sudo enabled users put their password in every time they run a command with sudo, uncomment the “# %wheel  ALL=(ALL)       ALL” line by removing the # at the start of the line. If you don’t wish to require a password for every use of sudo, do the same with the “# %wheel        ALL=(ALL)       NOPASSWD: ALL” line.

Now, what if you are like 99.9% of the fresh installs out there? What if you are not part of the wheel group, or have a situation where you only want your user to have sudo access? This is also very simple. Simply change “wheel” on whichever line you prefer to your group name and uncomment as before.

Done!

If you have issues using VI, there are a multitude of VI tutorials on the net. If you would rather use EMACS or nano or something, feel free. It should all work the same.

Problem Description

When installing WPMU, if the installation is not completed because of a database issue, an endless loop will occur. This happens because the DB is not populated with the correct information, but the wp-config.php has already been written. Every time you hit the index.php, it tries to look at the DB and notices that the information is not there. Default behavior seems to be to try again, which has the same behavior as the first time through. Endless loop, here we come.

Yeah, I know it is more complicated than that. I am trying to keep it simple.

To be truthful, this was my fault for not having my DB permissions set up correctly during install.

The Fix

The simple way to resolve the issue is to rename or delete the wp-config.php that was generated during the first install. After this is done, reload the site and go through the install again. Make sure you have corrected the DB problem before you go through the install again.

The Bitch

While it was my fault that I had the DB permissions jacked up, the WPMU installer needs to be tweaked a bit to avoid this issue. If the DB stuff fails, we should probably avoid writing the wp-config.php with information that isn’t going to do a whole lot of good and will probably scare off someone that isn’t as determined as I am.

This is the part where I get comments and emails telling me to fix it if I am that worried about it. This is also the part where I tell you that I am not a programmer. I am an admin and an enthusiast. If I could fix it, I would damn well do it.

This is also the part where I explain that this isn’t a gripe against WordPress MU or WordPress in general. They are great tools. I am just trying to help someone that might be having the same problem I had.

Ok. That’s all. Go about your business.

If you are already running 32 bit Flash in 64 bit Firefox, make sure you remove that before you install the 64 bit version of Flash. This goes for both the system-wide install or the single user installs.

If you head to the Adobe Labs site, you can snag the .tar.gz file that includes the flash plugin.

To uncompress the bugger:

tar -zxvf libflashplayer-10.0.d21.1.linux-x86_64.so.tar.gz

After that completes, you should have libflashplayer.so in the same directory as the .tar.gz file. This is where you need to choose how you would like to do the install. You can install this for your user only, or install it system-wide. If you would like to install system-wide, you will do the following:

Change the user and group associations for the file to root.

sudo chown root:root libflashplayer.so

Then change the permissions if need be to 755. (This may already be the default, but you should still check to be safe…)

sudo chmod 755 libflashplayer.so

Time to move the file to the worldwide plugins directory…

sudo cp libflashplayer.so /usr/lib64/mozilla/plugins

This should do it. You should be able to restart Firefox and start seeing flash in all of its native 64 bit glory!

As for those of you that might not have permissions to do a system-wide install, you can do the following.

cp libflashplayer.so ~/.mozilla/plugins

You don’t need to do any of those other steps besides decompressing the file and restarting Firefox.

I certainly hope this helps everyone out there dealing with the BS of having to get 32 bit Flash working on 64 bit Fedora. This should also work for just about any other distro out there. The locations might be changed, but everything is pretty much the same.