Posts Tagged ‘problem’

Fix to a problem with Varnish Cache not showing Apache’s .htm files extension on FreeBSD

Thursday, April 1st, 2010

I’m running my Apache server behind a Varnish Cache server. At most of the time all works okay, however today I’ve noticed a significant problem.
The problem consists in the fact that whenever I have directory listing enabled for some directory and I have dropped some .htm files, the htm files wouldn’t open as a proper html but instead the following message appears on click over some of the htm files:.

You have choosen to open 1.htm
which is a: PTHML file
from: http://myurl.com/
What should firefox do with this file?
(*) Open With (Browse ...)
( ) Save File ...

Here is also a screenshot of the error You have choosen to open … which is a: PHTML file:
you have choosen to open ... which is a PHTML file

At the beginning I though the error is caused by Apache and it was kind of weird since Apache my Apache serves a bunch of .html files without any issues.
It took me a while to realize that actually the problem is caused by the Varnish Cache server.
I digged my head into Varnish configuration, in hope to find something mentioned in the documentation but I couldn’t find anything meaningful there.
So after a while I decided to start experimenting with Apache.
Invoking the files directly on the port where I have Apache listening prooved me that Apache doesn’t have any problems with passing the .htm files content with a proper Application Type.
But anyways since I couldn’t find nothing in Varnish documentation, I’ve tried changing some stuff into my Apache configuration until finally I solved it!
The whole issue got solved by simply adding the following line in my Apache configuration file httpd.conf in my case on my FreeBSD

AddHandler application/x-httpd-php .htm .html .phtml

A simple Apache and Varnish restart and Hoooray, It Works again! 😀

Fix weird problem with Apache default encoding (AddDefaultCharset) not taking effect on FreeBSD with Apache version (2.0.63)

Tuesday, March 23rd, 2010

I encountered a weird problems a couple of minutes before. I tried to put some text files written in UTF-8 which contain cyrillic in the file names as well as the content the files has in my Apache directory listing. Trying that produced a lot of “alien symbols” for both file names and file content.
I have to admit that wasn’t exactly what I expected. I’ve checked my /usr/local/etc/apache/httpd.conf just to find out I already have the:

AddDefaultCharset utf-8

within in the configuration, I thought that somehow Apache could have difficulties applying that rules for the custom Virtualhost and therefore give the directive a try locally in the VirtualHost. Grievously that didn’t produced any positive result. That’s why I decided to check if somebody has experienced the same weird behavior and I stumbled on this wondeful blog post .
In short on the plug and pray’s blog … Wait and moment plug and pray? Yes you read that correctly it’s plug and pray :), on that blog it’s explained that newer versions of Apache 2.2.4 as this is the version the blogger talks about as well as the latest Apache release has an issue with AddDefaultCharset not working anymore. Fortunately the issue with the AddDefaultCharset not taking effect in Apache no more is easily solved. All that needs to be done is including the:

IndexOptions Charset=UTF-8

Within Apache conf file. In my case on FreeBSD I had to include that in /usr/local/etc/apache2/httpd.conf after which all worked perfectly fine and I can see all my cyrillic symbols showing anew.

Problem with OpenOffice after upgrade on Debian Sid Testing/Unstable – (openoffice.org: Component manager is not available.)

Wednesday, March 17th, 2010

A few days ago I did an upgrade using apt-get which upgraded my openoffice to 3.2.04 on my Desktop machine (a notebook running Debian Sid – Testing/Unstable). Since then I haven’t started the openoffice, however today an ex-college colleague of mine (Burcu), drop by home to give her some help about a project. In that relation I had to open a .doc file. I launched my oowriter in an attempt to open the document without success a stupid error poped up saying something is wrong with some kind of Openoffice registry and most importantly claiming the following error:

openoffice.org: Component manager is not available.

First thing I tried in order to resolve the issue was simply moving my ~/.openoffice.org/ and ~/.openoffice-org2/ directories to ~/.openoffice.org-bak/ and respectively ~/.openoffice.org2:

hipo@noah:~$ mv ~/.openoffice.org/ ~/.openoffice.org-bak/
hipo@noah:~$ mv ~/.openoffice.org2/ ~/.openoffice.org2-bak/

Regrettably I realized this this approach failed when I launched the oowriter to regenerate it’s working directories.

Therefore I executed another strategy 🙂 to fix the issue completely reinstalling the openoffice with apt:

hipo@noah:~# apt-get install --reinstall openoffice.org-core

After a while, now all is back to normal with my Openoffice :)Though it’s a real lose of time implying such a dumb workarounds, I always hated linux as a desktop platform just because of misbehaves like that.

Solution to a problem with VirtualHosts on Debian Lenny (Default Virtualhost opening by default overwritting the rest of the configured VirtualHosts)

Wednesday, February 17th, 2010

Configuring some Virtualhosts on a Debian server I administrate has led me to a really shitty problem. The problem itself consisted in that nomatter what kind of the configured VirtualHosts on the server I try to access the default one or the first one listed among Virtualhosts gets accessed. Believe me such an Apache behaviour is a real pain in the ass! I went through the VirtualHosts configurations many without finding any fault in them, everything seemed perfectly fine there. I started doubting something might prevent VirtualHosts to be served by the Webserver. Therefore to check if VirtualHosts configurations are properly loadedI used the following command:

debian-server:~# /usr/sbin/apache2ctl -S

Guess what, All was perfectly fine there as well. The command returned, my webserver configured VirtualHosts as enabled (linked) in: /etc/apache2/sites-enabled I took some time to ask in irc.freenode.net #debian channel if somebody has encountered the same weirdness, but unfortunately noobody could help there. I thinked over and over the problem and I started experimenting with various stuff in configurations until I got the problem.

The issue with non-working Virtualhosts in Debian lenny was caused by;
wrong NameVirtualHost *:80 directive
It’s really odd because enabling the directive as NameVirtualHost *:80 would report a warning just like there are more than one NameVirtualHost variable in configuration, on the other hand completely removing it won’t report any warnings during Apache start/restart but same time VirtualHosts would still be non-working.

So to fix the whole mess-up with VirtualHosts not working I had to modify in; my /etc/apache2/sites-enabled/000-default as follows;

NameVirtualHost *:80 changes toNameVirtualHost *

The rest of the Virtualhost stays the same;
This simple thing eradicated the f*cking issue which tortured me
for almost 3 hours! ghhh

Workaround to a problem With Bulgarian Cyrillic CP1251 Subtitles in MPLAYER and VLC

Sunday, September 20th, 2009

I think I mentioned on my blog that until I’ve upgraded to Debian Unstable, my subtitles in Bulgarian stopped working.
That happens in all of the Video supporting programs. I do a lot of reading and writting in English thus I have exported default LANG variable to en_US.UTF8
(my LANG is LANG=en_UTF-8). I tried everything via configuration files in Both Mplayer and Vlc to make the players work with Cyrillic in CP1251, badly enough nothing helped.
After some time of trying out stuff I came to the following solution.I’ve created files:
/usr/local/bin/vlc and /usr/local/bin/gmplayer
containing:
1. vlc’s file#!/bin/shLANG=bg_BG.CP1251 exec /usr/bin/vlc “$@”2. gmplayer’s file#!/bin/shLANG=bg_BG.CP1251 exec /usr/bin/gmplayer “$@”
The “$@” is a default bash variable which contains everything passed by next to /usr/bin/vlc and /usr/bin/gmplayer
END—–

Fix to annoying reoccuring problem “Enter password for default keyring to unlock”

Monday, February 8th, 2010

About a week and a half, everytime I do start my epiphany browser a really annoying prompt
occurs. Here is a screenshot of the gnome default keyring to unlock I was required to fill in,
everytime I started epiphany.
keyring prompt picture

I know one possible solution was to completely eradicate gnome-keyring package, however
that is definitely not a wise idea.
To fix this mimor though annoying issue I did the following:

1. Opened gnome-control-center (e.g. pressed alt+f2 and issued the gnome-control-center command)
2. Next find the "Encryption and Keyrings" menu and click on it
3. On the "Encryption and Keyrings" submenu "PGP Passphrases" I had to select
"Always remember passphrases whenever logged in
This is it, the annoying prompt won’t bother you anymore!
🙂

A fix for problem with FreeBSD php pcre & qmail installation

Wednesday, July 22nd, 2009

Few weeks ago I came around a problem with the php installed on my FreeBSD box seems like a shitty error occured when I tried to install squirrelmail as well as joomla. The following Warning message showed up every time I tried to access some of the scripts of the aforementioned ones.
“[Thu Jun 11 20:39:15 2009] [error] [client xxx.xxx.xxx.xxx] PHP Warning: preg_replace() [function.preg-replace]: Internal pcre_fullinfo() error -3 in somefile.php on line 169[Thu Jun 11 20:39:15 2009] [error] [client xxx.xxx.xxx.xxx] PHP Warning: preg_match() [function.preg-replace]: Internal pcre_fullinfo() error -3 in somefile.php on line 275″
I looked for a solution and it seemed the solution was as simple as adding “-with-pcre-regex=yes” to the Makefile of /usr/ports/lang/php5 a recompile and hooray pcre works correctly! Another problem I faced was with a qmail+vpopmail installation which seemed not to recognize the existence of some email addresses in the vpopmail installation. The cause for that was that my /var/qmail/control/locals was containing the name contained also in /var/qmail/control/virtualdomains. Simply removing the domain from locals and restarting qmail did the trick.Apart from all that I remembered an interesting website which you might find interesting to visit, a video from it was suggested by Sha’nar (Hope he had a safe journey to God). Here is thewebsiteisdown itself. Yes this days I’m mostly bored and in a spiritual roaming … Anyways thanks and glory be to God for his mercies on me.END—–