Lessons learned - Installing Wt on Squeeze LAMP¶

Here is my experience with installing Wt on a Debian Squeeze LAMP machine. It was an involved process. I've worked on large, complex code bases before, so I knew about the question, "How does one eat an elephant?" The answer is "One bite at a time." Meaning, I had to decompose the issue down to manageable chunks and nibble away at the smaller problems.

"(Here is a link to the original thread which contains the information below, and which contains some updates from project developers)":http://redmine.webtoolkit.eu/boards/1/topics/6343

1) I downloaded a LAMP virtual machine from TurnKey Linux. I ran it on the free VMware player. It's how I've developed PHP, MySQL and JavaScript projects.

2) I looked at what was required to install WT: http://www.webtoolkit.eu/wt/doc/reference/html/InstallationUnix.html

3) Okay - requirements. I had no idea about CGI, as I'd not used it before. I had to learn about CGI which I did, by going here: http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html and here: http://httpd.apache.org/docs/2.2/howto/cgi.html . I realized I wanted to start with FCGI, because if I were ever going to deploy, that's what I was going to use. Why? Apache is a well-known and reliable web server. Also, there's a difference between FCGI and FastCGI which is quite significant. FastCGI is encumbered with licensing and/or patent issues while FCGI is not.

4) So I installed the libapache2-mod-fcgid for Debian Squeeze. I had to learn about dpkg, dpkg-query and apt-get. And the sources.list file. I'd used apt-get before but I just knew what it did and few other details.

5) I needed to test whether FCGI was working. The LAMP machine had a test.cgi file in its cgi-bin directory. That worked. I created a directory called fcgi-bin. I copied test.cgi into it. No joy. As it turned out, the cgi-bin directory was set up to allow .cgi file execution in the Apache configuration files via the ScriptAlias directive. I had to add a handler to handle cgi scripts outside of that directory with AddHandler cgi-script .cgi. The CGI scripts now worked in fcgi-bin. But that's just CGI. What about FCGI? I needed a simple test script.

6) So, I had installed the FCGI package (libapache2-mod-fcgid). It loaded a module in Apache called mod_fcgid.c. The handler for FCGI is called fcgid-script, which was set to handle file types of .fcgi. That was in the fcgid.conf file by default. I set the Options +ExecCGI for the fcgi-bin directory in Apache via a directive. And I added the file type .pl (for Perl) to the fcgid-script handler entry in the IfModule directive within the fcgid.conf file. Details here: FastCGI on Apache

7) The perl file was still not working when I tried to run it via the browser. Finally, I discovered that in the perl script file, one need to use "Use FCGI" not "Use CGI::Fast". And I found a simple two line script that would work under FCGI. CGI and FCGI perl scripts are quite different. Then, from looking at the Apache error log, I determined I needed to install the perl FCGI package, libfcgi-perl. The perl script finally worked with FCGI. Finally I knew FCGI was working.

8) Next, I went to install Wt. But before that, I had to install package 'build-essential' for the c compilers and make. Then I had to install CMake.

9) Finally, I installed packages witty and witty-dev. Here is how the Wt package maintainer, Pau Garcia i Quiles, says to do it.

10) I compiled the hello.c example with g -o hello hello.c -lwtfcgi -lwt. Turns out the library libwtfcgi isn't on my machine. So, based on reading the forums, it seemed like the best way to get the most current installation of Wt with the required libraries, I should compile and install Wt myself. It wasn't installed as part of the witty packages I installed earlier.

11) So I had to read up on CMake, which is a utility which manages and generates makefiles. I went through the CMakeLists.txt files. I made a few minor changes. In the main CMakeLists.txt file, I set it to use the FCGI connector, not the built-in webserver one. I changed where the examples should go. The directions in the INSTALL.html file were spot on - perfect for building the project.

12) Recommendation: READ the main CMakeLists.txt file. It'll take 20 minutes, but it's 20 minutes well spent. Also, read up on CMake.

13) Warning: The CMake program wants to chown /var/run/wt directory to apache:apache. On my machine, it should be www-data:www-data. There's no user apache.

14) Read your wt_config.xml file. Might have to set num-threads to '2'. I did. It's working. Don't know if it's important.

15) Then, I had to make the examples. Per the instructions, I did a make -C examples from the build directory I created to compile the Wt project. That worked. I saw that I had a hello.wt file in the examples/hello directory. The directions said to run ./deploy.sh. But there was no suitable deploy.sh. I copied deploy.sh from the root directory of the Wt-3.1.2 directory to the hello directory. Ran it. It choked. I looked at the deploy.sh file and I could sort of follow along with what it was doing. Copying in a resources directory with images and such. I don't know from where the variables in deploy.sh were supposed to be set.

16) The /var/www/wt directory had to have Options +ExecCGI set. The fcgid-script handler was set to handle .wt files. Both of these items are set in the Apache config files.

17) Okay, next. I copied in hello.wt to my /var/www/wt directory. Tried to run it from a browser. No dice. Internal server error. In the Apache error log, I saw the same old error 104: mod_fcgid: error reading from fast cgi server, premature end of script headers. Sh-t. However, I recalled that someone on the forums said one could run the wt executable on the command line and it should run. I went to do that, ./hel- hit tab to autocomplete the name and nothing. A ha! It wasn't set to execute. So I chmod 755 hello.wt, ran it on the command line, then it worked! Then I ran it from the browser and it worked! HALLELUJAH!

18) I tried the treeview example, as I'm fond of treeviews. I ran it, and it ran, but it looked awfully sparse. Well, the deploy.sh talked about a resources directory. I noticed that FireBug, my web page inspector, was reporting several missing icons. So I created symbolic links to the resources directory on my server, in the same directory as the treeviewexample.wt (/var/www/wt), as well as to the icons directory. Everything then displayed correctly.

19) I wanted to use Eclipse as an editor for the Wt/C source files. A JRE needs to be installed first. I installed package default-jre. OpenJDK might have come with the Squeeze VM, but Eclipse wasn't seeing a Java Runtime Environment when I installed Eclipse. FYI, I put the Eclipse .gz file in /opt, tar -xvf the file, and that's it, it's installed. I downloaded the Eclipse for C/C development.

20) So I set up x-forwarding on VM. To do this, I installed the xbase-clients package, instead of the full xorg package. The remote machine (the VM), with the program generating the displays I want to see (i.e. Eclipse), is called the client. The computer I'm sitting in front of, which is showing the displays, is called the server in the world of x-forwarding. Sounds backwards, but there it is. Also, in sshd_config, one has to set 'ForwardX11 yes'.

21) I have to install an X11 server on my machine, to receive the display. I use Xming, a common choice.

22) Then I ssh into the VM with X11 forwarding enabled, go to the directory where eclipse is installed (/opt/eclipse) and do a './eclipse &' and Eclipse then appears on my Windows box. Takes like 15 seconds to initially display, but whatever. I created a hello world c project, compiled it, and it works.

Next steps:

1) I'll be using Eclipse to edit the files, and Cmake probably to make them. If there's a way to integrate CMake with Eclipse, that'll be great. But my projects will be simple at first, until the training wheels come off, so this will be an acceptable option for now.

2) If others have different/better development environments, feel free to post them.