Entries Tagged 'PHP' ↓

When enabling Visual effects Zend wouldn’t maximize anymore. So after a bit of googling I found a nice tutorial to fix the problem with Zend.

Since a few version of virtualmin I had some problems with checking the server configuration.

The problem is that I have manually patched suexec and the php fcgid script is in /var/www and not /home.

I had this error for quite a while but last week I fixed it. It was quite simple. Just change this code in “/usr/share/webmin/virtual-server/feature-web.pl:

# Make sure home base is under base directory, or template CGI directory is
if ($tmpl->{'web_suexec'} && $suhome &&
!&same_file($suhome, $home_base) &&
!&is_under_directory($suhome, $home_base) &&
(!$cgibase || !&is_under_directory($suhome, $cgibase))) {
return &text('check_ewebsuexechome',
"<tt>$home_base</tt>", "<tt>$suhome</tt>");
}

<p style="text-align: left;">return undef;
}

To:

# Make sure home base is under base directory, or template CGI directory is
return undef;
if ($tmpl->{'web_suexec'} && $suhome &&
!&same_file($suhome, $home_base) &&
!&is_under_directory($suhome, $home_base) &&
(!$cgibase || !&is_under_directory($suhome, $cgibase))) {
return &text('check_ewebsuexechome',
"<tt>$home_base</tt>", "<tt>$suhome</tt>");
}  return undef;
}

So just add “return undef;” to the top of that piece of code. Then it will step out of the function before the additional check is executed.

I download a Debian Sid livecd on my home server/HTPC and there’s a cd burner in there. So I would like to burn the downloaded iso. There no X Server running (yet) on the box so I was searching for a nice commandline utility.

I found cdw and it really looked nice so I installed it:

aptitude install cdw

After running it with “cdw” it detected my cd-writer so no configuration needed: nice. Because I once tried mybashburn (or something like that) and that piece of software needed all kinds of configuration. And I don’t like that.

I wanted to burn the debian sid iso with cdw but I couldn’t find an option for doing so. After some searching I found out that I had to go to “preferences” and change the value of “Default image file”. WTF? That’s not very nice I thought. But I tried it. But a no-go. The path to my iso was to long to fit in the box. So I couldn’t even select it.

Don’t get me wrong: cdw IS nice for burning music cd’s or just some files to backup. But isos…. pfff

So I resorted to cdrecord. It’s got a bit of a “hacker” feeling to it but it did the job nicely:

cdrecord driveropts=burnfree /home/leon/debian-live-sid-amd64-xfce-desktop.iso

What I don’t understand is why I have to manually enable burnfree. I mean: the last 5 cdr drives I had, all had burnfree. I’m doubting if they even make cd recorders without burnfree. So why not make it the default? Because apparently “Maybe it causes problems with *some* drives withput burn-free support”. Hja, retards.

But there might be a solution to this problem. Cdrecord checks for “/etc/cdrecord.conf”. And there you can change the default cdrecord parameters. My “/etc/cdrecord.conf” now contains:

driveropts=burnfree

But if it’s correct of if it works: I don’t know. I haven’t yet tested it.

Recently phoogle broke because of some Google maps update. The original creators of Phoogle haven’t updated the code (yet). And when searching online for newer, fixed versions all that showed up were crappy hacked Phoogle files by people who don’t know what they’re doing.

So hereby I present to you: a fixed Phoogle files which is hacked decent.

It was a troublesome day today. All did not go as planned.

I had to install fcgid + suexec on one of our servers, I had delayed it too long. So I used my how-to and it still worked flawless. But I noticed I hadn’t mentioned what the right were of the suexec binary. So here it goes:

chown root:www-data suexec
chmod 4754 suexec

After the install I restarted Apache and looked at one of the sites. And it worked! I was baffled. That’s the first time I installed fcgid without hours long of searching where the flaw was.

But then I looked at our support system (Redmine) and it didn’t work too well

All controllers were being executed ‘n stuff. But the stylesheets, images and javascripts were not loaded. When requesting an image in the browser I got Rails 404-error page. Huh? Apache should have handled that request. At first I thought it was because of some changes I made to the virtualserver configuration of an other Rails site. But after some trial and error I couldn’t find anything that was wrong.

Then I removed the .htaccess from the public directory of Redmine. That once worked for one of my rails sites. But no cigar. Then I noticed that there were a lot of dispatch*example.rb’s in the public directory. And: after removing them, the stuff worked. So it seems like Rails or Phusion Passenger uses some kind of fuzzy matching when searching for a dispatch.rb. And it first just worked because fcgid was not installed. So I don’t know who’s to blame. But the problem is solved. Phew!

I think you all noticed my fabulous new sidebar widget: My projects

It shows all of my github projects. I directly turned it into a plugin for you to enjoy. You can download and read the documentation in the wordpress plugin directory.

I went to a customer for our three-weekly sprint review, I opened my mail there and it was full with hundreds of failed cronjobs. Ah, shit! Another night at the datacenter? But it wasn’t that bad

The server had ran an update of php that night and it broke. When I ran php4 from the commandline I got these errors:

PHP Warning: mime_magic: type search/400 \\input text/x-tex invalid in Unknown on line 0
PHP Warning: mime_magic: type search/400 \\section text/x-tex invalid in Unknown on line 0
PHP Warning: mime_magic: type search/400 \\setlength text/x-tex invalid in Unknown on line 0
PHP Warning: mime_magic: type search/400 \\documentstyle text/x-tex invalid in Unknown on line 0
PHP Warning: mime_magic: type search/400 \\chapter text/x-tex invalid in Unknown on line 0
PHP Warning: mime_magic: type search/400 \\documentclass text/x-tex invalid in Unknown on line 0
PHP Warning: mime_magic: type regex [Cc]onstant[[:space:]]+[Ss]tory text/x-inform invalid in Unknown on line 0

Wait a minute… I know these errors! But, of course, I hadn’t documented the solution when I first fixed them. So after much searching I found the workarround again:

In the /usr/share/misc/magic.mime file, find the section that begins "# TeX documents, from Daniel Quinlan" and comment out the lines in that section.

# TeX documents, from Daniel Quinlan (quinlan@yggdrasil.com)
#0 search/400 \\input text/x-tex
#0 search/400 \\section text/x-tex
#0 search/400 \\setlength text/x-tex
#0 search/400 \\documentstyle text/x-tex
#0 search/400 \\chapter text/x-tex
#0 search/400 \\documentclass text/x-tex

# Type: Inform interactive fiction language
# URL: http://www.inform-fiction.org/
# From: Reuben Thomas
#0 regex [Cc]onstant[[:space:]]+[Ss]tory text/x-inform

NOTE: For Debian, it appears that this file is located at /usr/share/file/magic.mime!

I’ve installed rubygems manually (no package manager) in my home directory. But since then “gem –version” reported that it could not it’s version. So now I’ve removed the previous installed version, downloaded the tar and reinstalled. I’ve used this command to install this time:

ruby setup.rb --destdir=~/.rubygems --prefix=/

And now it runs fine!

leon@polly:~$ gem1.8 --version
1.2.0

And I’ve installed ruby 1.8.7 (from Intrepid) on Ubuntu Hardy. But more on that in my next post.

At Tim_online we have several webservers and each of them have apache2 installed running php with fcgid (a fastcgi implementation). Why this configuration and not mod_php? Because it is reasonably fast (at leaster faster than plain cgi) an secure (because it doesn’t run under the apache user).

For it to run php scripts as the website owner, you need suexec.

Suexec is a mechanism supplied with Apache that allows to execute CGI scripts as the user they belong to, rather than Apache’s wwwrun user. This improves security in situations where multiple mutually distrusting users have the possibility to put CGI content on the server.

So when u visitor requests one of the webpages of one of my customers the proces looks like this:

request -> apache -> fastcgi -> suexec -> proxy -> php file

I don’t exactly know anymore why the proxy is required, but it is
Know the problem is: suexec (by default) can’t execute the proxy file, because it isn’t owned by the php file owner. So you have to hack suexec to make this work.

I did this. And everything worked. The webservers were happy to serve al these requests untill one day apache get updated. The automatic ubuntu updates push a new version of apache with a new suexec binary. Problem!

So when you come at work there are 16 “missed incoming calls” and you co-workers are going mad with all the dissapointed customers. You look at the apache logs: hmzzz, suexec is giving 120 errors… What could that be? !Ping! Suexec ofcourse. Let’s see, how did I solve this problem the last time. First let’s download the apache sources. ./configure. Yes. now where’s suexec.c? Ah, cd support. Now,  make suexec. Wait, missing headers. Let’s install those first. Make suexec. Arrgh. It doesn’t work! Suexec -v. Wait, forgot to adjust the ap_httpd_user, ow, and comment out the offending lines. Yes, this should work. Ok. Copy it to /usr/lib/apache2. Ok, it works!

But at that time, an hour has past. If you can find the right files at once. So I decided to write down the steps I took to download, configure and compile suexec the quickest and simplest way. Here we go:

sudo apt-get install apache2-threaded-dev
mkdir -p ~/src/suexec
cd ~/src/suexec
sudo apt-get install apache2-threaded-dev
wget http://svn.apache.org/repos/asf/httpd/httpd/trunk/support/suexec.c
wget http://svn.apache.org/repos/asf/httpd/httpd/trunk/support/suexec.h
wget http://www.vanutsteen.nl/wp-content/uploads/2008/06/suexecc.patch
patch suexec.c suexec.c.patch -o suexec.patched.c
gcc -DLOG_EXEC='"/var/log/apache2/suexec.log"' -DAP_HTTPD_USER='"www-data"' -DAP_DOC_ROOT='"/var/www"' -I/usr/include/apr-1.0 -I/usr/include/apache2  -o suexec suexec.patched.c

That’s it! Test it by doing: sudo ./suexec -V
That should output:

-D AP_DOC_ROOT="/var/www"
-D AP_GID_MIN=100
-D AP_HTTPD_USER="www-data"
-D AP_LOG_EXEC="/var/log/apache2/suexec.log"
-D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
-D AP_UID_MIN=100
-D AP_USERDIR_SUFFIX="public_html"

Basically what I did:

1. I installed the necessary headers
2. Got the latests suexec code from the apache svn repo
3. Downloaded the suexec patch from my blog
4. Patched suexec to disable the file owner check
5. Compiled suexec with the default ubuntu options

I the release post of com_resized there was asked the question why one should use com_resize. There are three reasons to use it:

1. The generated images aren the size you want them to be. So they’re smaller of size than the original images.
2. You won’t get any ugly resized images (see the example below).
3. It works with remote images. So you can link to an image one someone else’s blog and they get resized to the size you want + cached. So that way they get loaded from your own server: so faster.

No more ugly resized images:

The one on the left is without com_resize. The one on the right is _with_ com_resize. If you don’t see any difference. Your browser is probably doing some fancy stuff with the image. In that case you don’t need com_resize. But maybe the readers of your blog do!

For the people who don’t see any difference (leave a comment with your OS + browser, please!) I have attached a screenshot. Made in IE6, so the font is ugly too