Here is a summary of my attempt to install Youtube Direct (YTD). YTD is designed to run  on Google App Engine (GAE) so you need to have a GAE account. Don’t worry, it’s free. After getting one, I downloaded the source and prepared it to be deployed in GAE. To do this, there are several things that need to be configured. One is to have Eclipse and the related Google Plugin.

Installing Eclipse. Download Eclipse IDE for Java EE Developers from the Eclipse project website. The file is eclipse-jee-galileo-SR1-win32.zip, which is about 190MB. Extract the eclipse directory from the zip file. This directory contains the eclipse.exe executable, which runs Eclipse.

Install Google Plugin for Eclipse. Run Eclipse. Then select the Help menu and choose Install New Software.. menu item. In the Work with text box, enter the following URL: http://dl.google.com/eclipse/plugin/3.5. Click the Add button and then the OK button, keeping the name blank as it will be retrieved automatically from the site. Next, click the triangle next to “Plugin” and “SDKs”. Check the boxes next to “Google Plugin for Eclipse 3.5” and “Google App Engine Java SDK.” You can also include the “Google Web Toolkit SDK” if you like. Click the Next button and accept the terms of service to install the plugin. When the installation is complete, restart Eclipse and the plugin is installed.

Install subclipse to manage SVN checkout. Subclipse can be found here. To install it in Eclipse, open Eclipse and click the Help menu. Select Install New Software menu item. In the Work with text box, enter the following URL: http://subclipse.tigris.org/update_1.6.x. Click Add button. Follow the same process as in Step 2. This time selecting Subclipse from the available options. Restart Eclipse to complete the installation.

Download the source code. Now, you are ready to download the YTD source code. In Eclipse, select File menu, then click the Import menu item. In the Import dialog box, click the small triangle next to SVN, and then select Checkout Projects from SVN. Click Next button. From the Checkout from SVN dialog box, choose Create a new repository location. Click Next. Specify the URL as follows: http://youtube-direct.googlecode.com/svn/tags/20091113. Click Next. Select the folder to be checkout by highlighting http://youtube-direct.googlecode.com/svn/tags/20091113. Click Finish. A new project called ytd[tags/20091113] should appear in the Project Explorer after Eclipse completed downloading the source code.

Copy war/WEB-INF/appengine-web_DEFAULT.xml into war/WEB_INF/appengine-web.xml. Edit this file. Put within the <application> tag the registered App Engine instance name of your application. Specify the version of the application within the <version> tag. Replace the value of com.google.ytd.YTDeveloperKey property with your registered Youtube developer key. If you don’t have a developer key, get one here.

Run the application by clicking the Run action in Eclipse. If everything is working fine, you should have a server running at http://localhost:8080/. While still in Eclipse, deploy the application to GAE by clicking the Deploy App Engine Project button in the toolbar.

At first, I encountered several errors. I didn’t have a clue why. When I tried to deploy the application to GAE, it failed because it cannot find javac in the path. As it turned out, I needed to set Java in Windows –> Preferences –> Java –> Installed JREs to the installed Java SDK, not just the JRE. Any way, after setting Java to the SDK,  all the errors disappeared and the application worked and I was able to deploy it to GAE.

GAE dashboard. Go to the admin panel of YTD by visiting http://YOUR_APP.appspot.com/admin. From this panel, you can create new assignments, moderate submitted videos, etc. You can also get the codes that you can paste into a page in your website to enable video submission for each assignment.

That’s it! I still have to see how this works. You can also check the Youtube Direct Getting Started Guide for more details. Till next post.

In this post, I would like to introduce a work-around of the firewall problem using only the SSH invoke server. The assumption is that the NinfG client and server applications are separated by a firewall. We would like also to assume that the client machine, where the client application is running, can connect to the server machine via SSH directly or via virtual private network. In this way, we can then use the SSH invoke server. If not, we are completely out of luck.

Although NinfG version 5 can now use SSH to invoke remote commands, it still has the same firewall problem inherent when using the Globus Toolkit. The reason is that the server application still needs to connect back to the client application. So if there is a firewall in-between client and server applications, this connection always fails and thus the entire application fails even if the client can connect to the server via SSH (since SSH connection is usually only allowed one way). This is further compounded if the client machine is in a NAT network. 

To solve the problem, we should find a way such that the server application does not have to connect back directly to the client application, which causes the connection failure. My solution is therefore to use SSH port forwarding. Since we can connect to the server via SSH, we can instruct SSH to forward a port from the server machine to a local port in the client machine. We can then configure the server application to connect to this local port (in the server machine) instead of connecting directly to the client machine. At the same time, we can also configure the client application to listen to this specific local port.

Fortunately, NinfG allows us to do this using the configuration file. The specific section to use is the CLIENT section. The CLIENT section of the configuration file can look like this:

<CLIENT>
hostname  localhost
listen_port 2222
</CLIENT>

This will trick the server application to connect to port 2222 in localhost (which is set to be the hostname of the connecting client). But local port 2222 in the server machine is forwarded to the client’s local port 2222 via SSH. So when the server application connects to this port, it is indirectly connected to the client application and thereby establishing the server and the client connection with SSH working in the background. The SSH command to achieve this is as follows (run from the client machine)

[user@client]$ ssh –R 2222:localhost:2222 remoteserver.com 

For a more general setting, you can use a third machine which is globally accessible via SSH. You can then use SSH to forward a port from this third machine to a local port in the client machine and configure NinfG’s server applications to connect back to this machine in the forwarded port. The CLIENT section of the configuration file will now look like this assuming thirdserver.com is the hostname of the third machine.

<CLIENT>
hostname   thirdserver.com
listen_port 2222
</CLIENT>

And the SSH command is

[user@client]$ ssh –R 2222:localhost:2222 thirdserver.com

This also assumes that you have an account in thirdserver.com machine. Or else, you will not be able to connect to it. In general, you should allow the forwarded port to be available to any machine, not just thirdserver.com. In this way, other server applications residing in other machines can connect to your client application via thirdserver.com. To do this, you can set GatewayPorts to yes in /etc/sshd_config in thirdserver.com.

1) Edit file /etc/sysconfig/network using your favourite editor, say using vi.

[root@mycomp]# vi /etc/sysconfig/network

2) Look for the line with HOSTNAME in it and change the entry to the desired hostname

HOSTNAME=mycomp.mydomain.com

3) Save the file and restart xinetd service

[root@mycomp]# /sbin/service xinetd restart

That’s it! You have just changed your hostname in Linux platform

[
\
^
$
|
?
*
+
.
(
)

If you want to use any of the above characters as a literal in a regular expression, you need to escape them with a backslash. For example, 1\+1=2 will search 1+1=2.

With a character class or character set, you can tell the regex engine to match only one out of several characters. This can be done by simply placing the characters you want to match  between square brackets. For example, if you want to match ‘a’ or ‘e’, simply use [ae]. Thus, gr[ae]y will match either gray or grey,  but not graay, or graey, or similar strings.

To specify a range of characters or numbers, you can use a hyphen inside a character class. For example, [a-z] will match a single character from a to z, and [0-9] will match a single digit from 0 to 9.

Typing  a ^ after the opening bracket will negate the character class. For example, q[^u] means a ‘q’ followed by characters not a ‘u’.

Note that the only metacharacters inside a character class are the closing bracket ], the backslash \, the caret ^, and the hyphen –. To include these characters inside a character class, you need to escape them with a backslash.

Short hand character classes include \d for [0-9], \w for “word character” or [0-9a-zA-Z_], and \s for “whitespace character”. Negated short hand character classes include \D for ^\d, \W for ^\w, and \S for ^\s.

The dot (.) matches a single character without caring what that character is, except new line characters.

Anchors match position before, between, or after characters. The caret ^ matches the position before the first character in the string. For example, applying ^a to “abc” matches ‘a’. But ^b will not match “abc” at all because ‘b’ cannot be matched at the start of the string. Similarly $ matches right after the last character in the string. c$ matches ‘c’ in “abc”, while a$ does not match at all.

\b for word boundaries. For example, \bis\b will match “is” in “This island is beautiful.”

Alternation or | is used to match one regular expression out of several regular expressions. For example, apple|banana|oranges. Note, you can use round brackets for regex grouping (e.g., \b(cat|dog)\b.

The question mark ? makes the preceding token in a regular expression optional. For example, colou?r  matches both colour and color. You can make several tokens optional by grouping them together and attaching the question mark at the closing round bracket, such as Nov(ember)? which will match “Nov” and “November”.

The asterisk or star or * tells the engine to match the preceding token zero or more times. The plus + tells the engine to match the preceding token once or more times. You can limit the repetition by using {min,max} where min is a positive integer number indicating the minimum number of matches and max is an integer equal to or greater than min indicating the maximum number of matches. If comma is present but max is omitted, the maximum number of matches is infinite.

To use gdb, you need to compile your program with the -g option to include debugging information. For instance, using gcc, you can compile program myprog.c as follows:

[user] gcc -g myprog.c

To start gdb, run gdb program in the command prompt, where program is the name of your executable file. For instance,

[user] gdb a.out

First, this will display gdb's front material describing its copyright and non-warranty, among other information. Then you will be put in gdb prompt (gdb).

Start the program by issuing the command run in the (gdb) prompt. If you have not yet issued any break points, the program will continue running until it finishes or it encounters fatal error. To quit gdb, just issue the quit command.

The main purpose of gdb is to allow programmers to stop the program before it terminates so that its current condition can be examined and potential sources of trouble can be known. This is where breakpoints, catchpoints, and watchpoints become handy. A breakpoint makes your program stops whenever a certain point is reached. On the other hand, a watchpoint is a special breakpoint that stops the program when the value of an expression changes. A catchpoint is another kind of breakpoint that stops the program when a certain kind of event occurs.

To setup a breakpoint, use the break command followed by the location. The location can be a function name, a line number, or an address of an instruction. For example,

(gdb) break 10

will set a breakpoint at line number 10, and

(gdb) break myfunc

will set a breakpoint at the start of function myfunc.

To examine your source file within gdb, you can use the list command. list prints 10 lines by default from the source file. It also prints the line numbers which you can use in the break command. Some of the useful list options are as follows:

(gdb) list linenum

will print lines centered around linenum.

(gdb) list startline, numlines

will print numlines starting from startline in the current source file.

(gdb) list function

will print lines centered around the beginning of function

(gdb) list

will print the next 10 lines.

After a break, you can continue the program execution using the continue or c command. You can also run the program until the next line is reached with the step or s command. To step by machine execution instead of source line, use the stepi or si command. The next or n command will execute the next line including any function call. To execute just the next machine instruction, use nexti or ni.

The above commands should keep you started. If you need help, just type help in the (gdb) prompt. You can further refine help by appending any command after help, such as

(gdb) help break

That's it! And happy debugging.

I started using SVN only recently to track changes I made to the source codes of programs I have written, and hence this note. SVN is quite handy as it allows you to access your source code from any computer which can access your repository. You can commit changes you made to the code in one workstation, and when you work on those codes in another workstation,  you can just update the local copy to reflect the changes you made. In the following, I'll assume that SVN is already installed.

1. Creating an SVN Repository

   1: [user@mycomp] cd

   2: [user@mycomp] mkdir Repos

   3: [user@mycomp] svnadmin create Repos

First, create a directory which will serve as the SVN repository. In the example above, a directory called Repos/ is created in the user's home directory (line 2). To tell SVN to use this as the repos, use svnadmin create command passing the directory name as the target (line 3).  After executing this command, SVN will place several directories and files in this directory. You can check the contents of Repos/ by running ls -al Repos.

2. Storing codes into the repository

   1: [user@mycomp] mkdir appwebcam

   2: [user@mycomp] mkdir appwebcam/trunk

   3: [user@mycomp] mkdir appwebcam/logs

   4: [user@mycomp] mkdir appwebcam/branches

   5: [user@mycomp] mkdir appwebcam/trunk/SRC

   6: [user@mycomp] mkdir appwebcam/trunk/bin

Now that you have your repository setup, it is time to add some data into it. You can structure the data within the repository any way you like. But usually, you'll have a main directory for a project (say, appwebcam/), then within this, you have subdirectories for trunk/, logs/, and branches/. Within the trunk/ subdirectory, you can have SRC/ subdirectory to hold your source codes, bin/ subdirectory for the binaries, etc. Lines 1-6 simply create this directory structure. 

3. Import your codes to the repository

   1: [user@mycomp] svn import ./appwebcam file:///home/user/Repos/appwebcam -m "Initial import"

   2: Adding appwebcam/trunk

   3: Adding appwebcam/trunk/SRC

   4: Adding appwebcam/trunk/bin

   5: Adding appwebcam/logs

   6: Adding appwebcam/branches

To import the created directory structure into the repository, use svn import as shown in line 1 giving the directory you want to import (./appwebcam), the location of the repository (file:///home/user/Repos/appwebcam), and an import comment option (-m "Initial import") as parameters. This will create an "invisible" directory appwebcam/ under the Repos/ directory.

4. Checking out codes from the repository

   1: [user@mycomp] svn co file:///home/user/Repos/appwebcam/trunk appwebcam

   2: A    appwebcam/SRC

   3: A    appwebcam/bin

   4: Checked out revision 1.

Finally, if you want to checkout a certain portion of your repository, use svn checkout (or svn co). In the above example, only the contents of the trunk/ subdirectory under appwebcam/ are being checkout into the appwebcam/ directory in the user's current directory. After the checkout, appwebcam/ will contain the SRC/ and bin/ subdirectories.

To generate the certificate, run the following command:

adt -certificate -cn name [-ou org_unit][-o org_name][-c country] key_type pfx_file password

where -cn name is the common name that will be used for the generated certificate, -ou org_unit refers to the organizational unit issuing the certificate, -o org_name is the name of the organization issuing the certificate, -c country is a two-letter ISO-3166 country code, key_type can either be "1024-RSA" or "2048-RSA" pfx_file is the name of the file where the certificate will be stored, and password is the certificate's password. The parameters inside square brackets are optional.

As an example, the actual command may look like this:

   1: adt -certificate -cn "My Certificate" -ou bagarinao.com -o "ABK Co" -c US 2048-RSA myCert.p12 sd#$wd23

   2: adt -certificate -cn "AIR App" 1024-RSA MyCert.p12 sd#$wd23

The first line illustrates how to generate a certificate specifying all the possible parameters. On the other hand, the second line only uses the required parameters in generating the certificate. Both will generate a new certificate and will store it in a file called myCert.p12 with password sd#$wd23.

To use the generated certificate to sign an AIR application, use adt using the -package option instead of the -certificate option. Use -storetype pkcs12, -keystore myCert.p12, and -keypass sd#$wd23 to specify the certificate that will be used to sign the application. The command is something like

adt -package -storetype pkcs12 -keystore myCert.p12 -keypass sd#$wd23 <airfile> <app-desc> other-files ..

where <airfile> is the name of your package, <app-desc> specifies the XML application descriptor file, and other-files are the files and directories that you want to package with your air application.

NinfG 5.0 is the latest version of NinfG. Unlike previous versions where the Globus Toolkit is required, NinfG 5.0 can now work with non-Globus grid environment. One of its new features is the ability to use SSH to do remote procedure calls via the invoke server mechanism. This is very handy since most Linux systems have already SSH in the default installation, so there is no need to install additional packages to use NinfG. The following paragraphs outline the installation of NinfG on a system running Linux.

1. Download NinfG

You can download NinfG from http://ninf.apgrid.org/. Be sure to get the current version (v. 5.0). You also need to download a patch, which can be found here, for this version. I don't know if this patch is already incorporated in the package downloadable from the NinfG web site. In the following, I will assume that the download directory is located in /home/user/downloads.

[user@mycomp]$ cd /home/user/downloads/[user@mycomp]$ ls
ng5-latest.tgz
ninfg.patch

The two files, ng5-latest.tgz and ninfg.patch, should be in the download directory.

2. Extract the files

After downloading the necessary files, you can now extract the files using tar.

[user@mycomp]$ cd /home/user/downloads/
[user@mycomp]$ tar -xzvf ng5-latest.tgz
[user@mycomp]$ ls
ng-5.0.0
ng5-latest.tgz
ninfg.patch

This will create a subdirectory called ng-5.0.0 in the download directory. All the needed files are in this subdirectory.

3. Apply the patch before compiling the package

First, change directory to ng-5.0.0, then run patch as follows:

[user@mycomp]$ cd ng-5.0.0
[user@mycomp]$ patch -p0 < ../ninfg.patch
patching file src/c/client/ngclRemoteClassGenerate.c
Hunk #1 succeeded at 1748 (offset 16 lines).

4. Configure, compile, and install

Now that the patch is applied, you are set to compile and install the package.

   1:  [user@mycomp]$ ./configure --prefix=/opt/ng5.0.0 --with-zlib --with-ssh

   2:  :

   3:  :

   4:  [user@mycomp]$ make

   5:  :

   6:  :

   7:  [user@mycomp]$ su -

   8:  Password: xxxxxxx

   9:  [root@mycomp]# mkdir /opt/ng5.0.0

  10:  [root@mycomp]# cd /home/user/downloads/ng-5.0.0

  11:  [root@mycomp]# make install

  12:  :

  13:  :

  14:  [root@mycomp]#

In line 1, the configure command is run with several parameters: --prefix=/opt/ng5.0.0 instructs configure to install the package in /opt/ng5.0.0 directory instead of using the default install directory, --with-zlib includes zlib compression support, and --with-ssh includes support for Invoke Server SSH. Invoke Server SSH is a new feature of NinfG allowing the use of SSH to do remote procedure calls instead of completely relying on the Globus Toolkit. To see the complete list of available options, you can run ./configure --help.

Line 2 compiles the package. The output of this command is omitted in the listing above. After compilation, the package is now ready for installation.

Line 4 changes the user to the superuser using the su command. You will need the root password to proceed. If you don't have root access, you can still install NinfG in a directory where you have read/write permission. However, only you can use NinfG.

As root, create the installation directory (line 9). Then change directory to the location of the NinfG installation package (line 10). In this directory, run make install to install the package. If there are no errors, congratulations! You now have a working NinfG installation.

5. Post installation setup

For convenience, you can include the NinfG executables in your PATH. You can also set several environment variables needed by NinfG. To do this, add two files, namely, ninfg.sh and ninfg.csh, in your /etc/profile.d/ directory.

/etc/profile.d/ninfg.sh:

NG_DIR=/opt/ninfg; export NG_DIR
if [ -r ${NG_DIR}/etc/ninfg-user-env.sh ]
then
    . ${NG_DIR}/etc/ninfg-user-env.sh
fi

/etc/profile.d/ninfg.csh:

setenv NG_DIR /opt/ninfg
if ( -r "${NG_DIR}/etc/ninfg-user-env.csh" ) then
    source ${NG_DIR}/etc/ninfg-user-env.csh
endif

Finally, as root, create a symbolic link /opt/ninfg pointing to /opt/ng5.0.0. This is useful when upgrading the version of NinfG. In this case, you only need to change the link to point to the new version to effect the changes.

[root@mycomp]# ln -s /opt/ng5.0.0 /opt/ninfg
[root@mycomp]# ls -al /opt
drwxr-xr-x   7 root root 4096 2008-08-26 12:23 ng5.0.0
lrwxrwxrwx   1 root root   12 2008-08-26 12:33 ninfg -> /opt/ng5.0.0
[root@mycomp]#

That's it! Enjoy!

The following is my outline on how to use SSH for passwordless remote login. Of course, this is far from being complete and some of the things below may not work perfectly with your setup. There are many howtos regarding this topic and you should be able to find the one that is appropriate for your system.

1. Generating key pairs

SSH uses public-key cryptography to authenticate remote computers. In this form of cryptography, a user has a public key, which can be widely distributed, and a private key, which should be kept secret. Before you can use SSH, you will need to generate this key pair. You can do this using ssh-keygen, as follows.

[baggy@mycomp] ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/baggy/.ssh/id_rsa): (hit enter to use the default value)
Enter passphrase (empty for no passphrase): (enter a passphrase or hit enter for empty passphrase)
Enter same passphrase again: (enter the same passphrase here)
Your identification has been saved in /home/baggy/.ssh/id_rsa.
Your public key has been saved in /home/baggy/.ssh/id_rsa.pub.
[baggy@mycomp]

Note that in the above, a passphrase refers to a string of words and characters that will be used to authenticate you when you want to use your ssh identification. It differs from a password in that you can use spaces or tabs and it is also usually longer. Generally, it is a phrase and not just a single word.

To generate different types of key pairs such as DSA or RSA, you can use the -t option of ssh-keygen. For example, the command should be ssh-keygen -t dsa to generate a DSA key pair. After generating your key pair, you'll need to install your public key to the remote systems you are planning to connect.

2. Installing the public key to remote machines you want to connect

To install your public key, you can use ssh-copy-id if this command is available.

[baggy@mycomp] ssh-copy-id baggy@remote.machine.com
baggy@remote.machine.com's password: (enter your password for remote machine)
Now try logging into the machine, with "ssh 'baggy@remote.machine.com'", and check in:
    .ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
[baggy@mycomp]

Replace baggy@remote.machine.com with your actual username and the hostname of the remote machine. If ssh-copy-id is not available, you can use scp to copy your public key file to the remote computer, then add this file to authorized_keys file in your home directory's .ssh subdirectory.

You can now try connecting to your remote system using the following:

[baggy@mycomp] ssh baggy@remote.machine.com
Enter passphrase for key '/home/baggy/.ssh/id_rsa': (enter passphrase here)
Last login: Tue Aug 18 08:08:08 from mycomp.localbox.com
[baggy@remote]

As you might have noticed, instead of asking for the password of the remote machine, SSH asked the passphrase of your SSH identity. The advantage of this over using a password is that the passphrase is never transmitted over the network making the approach safer. If SSH still asks for a password, verify your remote system's sshd configuration and make sure that RSA/DSA authentication is enabled.

Okay, you don't type your password but it still requires you to type your passphrase. The password is just being replaced by the passphrase, sort of. So is there a way to do away with the passphrase also? Fortunately, the answer is yes and that is by using ssh-agent.

3. Using ssh-agent

ssh-agent is part of the OpenSSH package to manage RSA and DSA keys. It is a long running daemon designed to cache your decrypted keys so that SSH can communicate with it and use the cached keys without prompting you for a passphrase every time you make a remote connection. To add an identity managed by an ssh-agent, you can use ssh-add.

There are many ways to use ssh-agent. For me, since I only use it in a single shell, I just use the following:

[baggy@mycomp] ssh-agent /bin/bash
[baggy@mycomp] ssh-add
Enter passphrase for /home/baggy/.ssh/id_rsa: (enter passphrase here)
Identity added: /home/baggy/.ssh/id_rsa (/home/baggy/.ssh/id_rsa)
[baggy@mycomp]

Within this shell, you can now remote login or run commands remotely without being prompted for a passphrase.

Shindig is an open source reference implementation of Google’s OpenSocial and gadgets specifications. With Shindig, you will be able to host Google gadgets and OpenSocial applications in your own web site relatively quickly as it already contains code that you can easily plug into your server infrastructure to start hosting these applications.

Interested with OpenSocial, I tried installing Shindig in my home server. Currently, Shindig's PHP implementation is far from being complete, so my interest is just to have a feel on how it works. To install Shindig, check its web site and follow the instructions there. The project does not yet support automated build infrastructure so you need to get Shindig from its SVN repository. For this, you need an SVN client. Fortunately, I have Cygwin installed in my Windows XP machine, so I only had to install subversion in Cygwin. This can be done by running the Cygwin installer, then locate the subversion package, select it, and install. After the installation, run a bash shell and you are ready to export Shindig.

In my setup, my web's root directory is located in c:/www. To export Shinding using Cygwin, just run the following command in a bash prompt:

[bash] cd /cygdrive/c/www
[bash] svn export \
          http://svn.apache.org/repos/asf/incubator/shindig/trunk/
[bash] mv trunk shindig

After exporting the Shindig source code, the next thing to setup is a virtual host pointing to the PHP directory of Shindig. If you cannot setup a virtual host, it is still possible to run Shindig by changing some settings in the configuration file. I used the virtual host option to separate Shindig from the rest of my web installation. Here is my virtual host setting:

# shindig
<VirtualHost *:80> 
    DocumentRoot "C:/www/shindig/php" 
    ServerName shindig.mshome.net
    ErrorLog "logs/shindig.log" 
    CustomLog "logs/shindig-access.log" common
    <Directory "C:/www/shindig/php">
         Options FollowSymLinks
         AllowOverride FileInfo
         Order Allow,Deny
         Allow from all
    </Directory>
</VirtualHost>

Make sure that mod_rewrite is also enabled in your web server. Check if you have the following line in the Apache's configuration file httpd.conf:

LoadModule rewrite_module modules/mod_rewrite.so

For the mod_rewrite to work, you also need to set AllowOverride in the virtual host's configuration to FileInfo or higher (All, for example). In my initial setup, I had this option set to None and wondered why mod_rewrite even if already installed didn't work.  After changing httpd's configuration, restart httpd for the new configuration to take effect.

When everything is set, try to check if your installation works. Open a browser and enter the following URL:

http://shindig.mshome.net/gadgets/ifr?url=http://www.labpixies.com/campaigns/todo/todo.xml

Change shindig.mshome.net in the above URL to your own. This should display labpixies note gadget. Now you can start developing your own gadget or OpenSocial application in the convenience of your own server.