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.

My mother wanted to get a scanner so that she could make all of her pictures into ones and zeroes. I started looking around for something that would work for her needs and couldn’t find anything that would work with SANE. Go figure.

Ok, sidenote. Seriously. If CUPS can give support to damn near anything that prints since probably the 1950′s, why can’t SANE do something at least somewhere near that?!

I decided that since there wasn’t any simple way, short of writing a driver for the new scanner *cough*, that I could make this work with Fedora 10 in the timeframe I was working with.

So I get the new XP license in the mail today. I double check that the backups are done on her system. I put the CD in and reboot. I get the almighty Black Screen of Insanity +5. As you can imagine, I am getting a little bit pissed by now. I reboot real quick and jump into the BIOS to make sure that there isn’t anything odd looking in there. Nothing odd. Reboot and try to install again. No go again.

In the past, I had the same problem with a system that previously had Fedora Core 4 on it. Microsoft seems to want to make us jump through hoops if we are forced to go back to their stupid OS for any reason.

Come to find out, this is a partitioning issue. I guess that Microsoft doesn’t know how to read a partition table if it was written by another OS. Somehow, my jaded nature just doubled.

The solution was to rewrite the partition table with GParted. I downloaded the ISO from the GParted website and burned it using another system. After inserting the CD and booting from it, I was able to completely erase the partition table. A quick reboot from there, and Windows XP decided that it wanted to start working.

The moral of this story is very simple. Microsoft has been trying to find ways to keep ahead of Apple and the Linux community for years. They have done some good things and a load of bad things. The problem is, they have continued to write shoddy software. Their market share is slowly seeping over to the *NIX side of things, and they still fail.

Windows 7 may be able to turn this trend around, but what I have seen suggests that they are simply stealing ideas from the Linux community to rewrite and impliment in their own OS. Eventually, I believe this will catch up with them.

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.