(On Debian 5.0. May be slightly different on other distros)
Create files in /etc/skel/:
$ cd /etc/skel
$ mkdir -P etc/php5
$ cp /etc/php5/apache2/php.ini /etc/skel/etc/php5/php.ini
$ mkdir fcgi-bin
$ vi fcgi-bin/php5.fcgi
Paste the following:
#!/bin/bash
export PHPRC=$PWD/../etc/php5
umask 022
export SCRIPT_FILENAME=$PATH_TRANSLATED
exec /usr/bin/php-cgi
Then, in Virtualmin > System Settings > Server Templates > Default Settings > Apache website > Directives and settings:
ServerName ${DOM}
ServerAlias www.${DOM}
DocumentRoot ${HOME}/public_html
ErrorLog /var/log/virtualmin/${DOM}_error_log
CustomLog /var/log/virtualmin/${DOM}_access_log combined
DirectoryIndex index.html index.htm index.php index.php4 index.php5
Options -Indexes IncludesNOEXEC FollowSymLinks ExecCGI
allow from all
AllowOverride All
AddHandler fcgid-script .php
FCGIWrapper ${HOME}/fcgi-bin/php5.fcgi .php
AddHandler cgi-script cgi
Important notes:
ExecCGI is required! Otherwise, 403 Forbidden errors will occur.- The wrapper script and php files must not be group/world-writable!
- Look in
/var/log/apache2/suexec.log for hints if you’re having trouble.
For future reference, the cryptic error from mod_fcgid:
[Thu Feb 12 22:10:27 2009] [warn] (104)Connection reset by peer:
mod_fcgid: read data from fastcgi server error.
[Thu Feb 12 22:10:27 2009] [error] [client X.X.X.X] Premature end of
script headers: dispatch.fcgi
means that dispatch.fcgi failed to start. Possible reasons are:
- Missing Perl modules. Unfortunately, I don’t know where the stderr output ends up. Try running the script directly; e.g.
perl dispatch.fcgi.
- Missing Perl modules that you installed locally (e.g. local::lib) but Apache doesn’t have it in
$PERL5LIB.
Remember that the folder must not be group-writable, and that any executable must be run from the directory root that suEXEC was compiled for! These will fail with a more useful error though, complaining of “suexec policy violation: see suexec log for more details” (the log is at /var/log/httpd/suexec.log for CentOS systems).
At the Intel International Science and Engineering Fair this year, I’ve learned a lot about presentation techniques. Thanks to Patrick for giving me some great suggestions, such as:
- Posture: stand with feet pointed toward judge, lean forward slightly
- Hands: use generous hand gestures, in front of chest, not lower
- Use visual bullets when making lists. Hold up fingers for each item.
- Intonation: Use emphasis on key phrases, and be sure to pause between clauses and sentences. Give the listener time to absorb information, and possibly ask questions.
- Don’t use filler words like “uh”, simply pause and glance back at board if you forget what to say.
Here are some other notes about the judging process at ISEF experience:
- Some judges are not interested in hearing a presentation, and will instead like to ask you questions about the board. They have all already read the board. This can be difficult if there is background information that needs to be explained as part of your presentation.
- Other judges may want a 2-minute summary of your work. This means you should state the key points: the purpose, hypothesis, conclusion. In my case, I also showed my demonstration.
- Judges are assigned based on your sub-category selection, so choose carefully.
- Recognize types of judges:
- Grand awards judges have blue ribbons, and a second ribbon corresponding to their category. Computer Science judges had yellow ribbons. These judges are written on the red card that is placed at your project. They have strict 15 minute periods for each project, and there is a warning bell when there are a couple minutes left.
- Special awards judges have red ribbons. Their organization is written on their badge. Special awards judges will not always have time to hear the full presentation.
Question and Answer: Questions about the technical details of your project are easy to answer, because you have already researched the field for many months. The trickier questions are more general, and they apply to almost all projects. For example:
- What were some of the biggest challenges in your project, and how did you overcome them?
- What was something surprising that you learned, that you weren’t expecting to?
- What is the significance of your results?
- How did you learn about this?
- Why did you want to do this project? How did you come up with this idea?
- How does your work compare to existing research?
- What makes this project better than the other projects here?
- What would you do differently if you did this again?
- What else would you like to explore in this project?
The Catalyst Framework is an elegant Model-View-Controller based web framework for Perl, with similarities to Ruby on Rails. It is a popular choice for Web 2.0 applications based on Perl, speeding up and simplifying development.
Catalyst is very nice to use, but has a reputation of being hard to use, particularly on Windows. Windows has historically been regarded as the “outcast” of Perl development environments—the lack of proper build tools had made installing most modules (including Catalyst) difficult, to say the least. ActiveState’s binary PPM packages are hard to find and often outdated. The effect has been that the complex dependencies of Catalyst were nearly impossible for the average mortal to manage on Windows.
I recently discovered Strawberry Perl, which has made building modules on Windows easier than ever. It includes a bundled MinGW toolchain for compiling and pure-Perl equivalents for other necessary tools. Now, it is no longer necessary to install Visual Studio or Dev-C++ just to build Perl modules. Using the CPAN installer from the command line Just Works.
If you have tried to install Catalyst on Windows before, you’ll know that hunting for PPMs and building the missing modules takes hours and leaves you with an installation that isn’t up-to-date. With Strawberry Perl, I was able to install the newest Catalyst fresh from CPAN in about 10 minutes.
Read on for easy instructions in 5 steps.
Unison is a nifty tool that allows you to synchronize files over the network.