Configure SFTP Server using chroot jail in Linux

ref: http://linuxnextgen.blogspot.com/2010/12/configure-sftp-server-using-chroot-jail.html Configure SFTP Server using chroot jail in Linux Release: RedHat Enterprise Linux Openssh 5.6P1 Problem: Configure the sftp-server on a per-user-basis (restrict users to their individual home directory) using chroot() jail in RedHat Enterprise Linux Solution: 1) Install the OpenSSH latest version that must support the chroot() function 2) Configure Openssh to use its internal sftp subsystem by editing the sshd_config file # vi /etc/ssh/sshd_config Replace Subsystem sftp /usr/local/libexec/sftp-server by Subsystem sftp internal-sftp 3) Now configure the chroot() by using match rule, add the below entries in the end of the sshd_config file # vi /etc/ssh/sshd_config Match group sftponly ChrootDirectory /home/%u X11Forwarding no AllowTcpForwarding no ForceCommand internal-sftp Note: Here %u represents username, that means all the users in the sftponly group home directories are chrooted. Also chroot directory must be owned by root. 4) Add one new group named as sftponly # groupadd sftponly 5) Create a new user to use retricted sftp. First create a user's home directory after that add the user # mkdir /home/test # useradd -g sftponly test # usermod -d / test Note: In here, create a home directory as a root user, while adding the user one warning comes like this, "useradd: warning: the home directory already exists" 6) Now test the configuration from client side [root@server Desktop]# sftp test@192.168.1.7 Connecting to 192.168.1.7... test@192.168.1.7's password: sftp> ls IN sftp> cd IN sftp> ls sftp> mput 1.png Uploading 1.png to /IN/1.png 1.png 100% 90KB 90.4KB/s 00:00 sftp> ls 1.png sftp> bye 7) Test the SFTP-Server function from the windows client use the “WinSCP” or “Filezilla”

How to restrict users to SFTP only instead of SSH

ref: http://www.debian-administration.org/articles/94 Sometimes you want to have users, that have access to files on your server, but don't want them to be able to log in and execute commands on your server. This is done quite easily. Add user as usually and assign him a password. Then run the following command (replace the 'username' with real user name): root@host # usermod -s /usr/lib/sftp-server username This changes user's shell to sftp-server. The last step for this to work is to add '/usr/lib/sftp-server' to /etc/shells to make it a valid shell, eg. like this: root@host # echo '/usr/lib/stfp-server' >> /etc/shells There. Now you've setup a user who can only access your server with SFTP.

Java Networking and Proxies

1) Introduction

In today's networking environments, particularly corporate ones, application developers have to deal with proxies almost as often as system administrators. In some cases the application should use the system default settings, in other cases it will we want to have a very tight control over what goes through which proxy, and, somewhere in the middle, most applications will be happy to delegate the decision to their users by providing them with a GUI to set the proxy settings, as is the case in most browsers.

In any case, a development platform, like Java, should provide mechanisms to deal with these proxies that are both powerful and flexible. Unfortunately, until recently, the Java platform wasn't very flexible in that department. But all that changed in J2SE 5.0 as new API have been introduced to address this shortcoming, and the purpose of this paper is to provide an in-depth explanation of all these APIs and mechanisms, the old ones, which are still valid, as well as the new ones.

2) System Properties

Up until J2SE 1.4 system properties were the only way to set proxy servers within the Java networking API for any of the protocol handlers. To make matters more complicated, the names of these properties have changed from one release to another and some of them are now obsolete even if they are still supported for compatibility's sake.

The major limitation of using system properties is that they are an “all or nothing” switch. Meaning that once a proxy has been set for a particular protocol, it will affect all connections for that protocol. It's a VM wide behavior.

There are 2 main ways to set system properties:

• As a command line option when invoking the VM
• Using the System.setProperty(String, String) method, assuming, of course that you have permission to do so.

Now, let's take a look, protocol by protocol, at the properties you can use to set proxies. All proxies are defined by a host name and a port number. The later is optional as, if it is not specified, a standard default port will be used.

2.1) HTTP

There are 3 properties you can set to specify the proxy that will be used by the http protocol handler:

• http.proxyHost: the host name of the proxy server
• http.proxyPort: the port number, the default value being 80.
• http.nonProxyHosts: a list of hosts that should be reached directly, bypassing the proxy. This is a list of patterns separated by '|'. The patterns may start or end with a '*' for wildcards. Any host matching one of these patterns will be reached through a direct connection instead of through a proxy.

Let's look at a few examples assuming we're trying to execute the main method of the GetURL class:

$ java -Dhttp.proxyHost=webcache.mydomain.com GetURL

All http connections will go through the proxy server at webcache.mydomain.com listening on port 80 (we didn't specify any port, so the default one is used).

$ java -Dhttp.proxyHost=webcache.mydomain.com -Dhttp.proxyPort=8080
-Dhttp.noProxyHosts=”localhost|host.mydomain.com” GetURL

In that second example, the proxy server will still be at webcache.mydomain.com, but this time listening on port 8080. Also, the proxy won't be used when connecting to either localhost or host.mydonain.com.

As mentioned earlier, these settings affect all http connections during the entire lifetime of the VM invoked with these options. However it is possible, using the System.setProperty() method, to have a slightly more dynamic behavior.

Here is a code excerpt showing how this can be done:

//Set the http proxy to webcache.mydomain.com:8080

System.setProperty("http.proxyHost", "webcache.mydomain.com");
System.setPropery("http.proxyPort", "8080");

// Next connection will be through proxy.
URL url = new URL("http://java.sun.com/");
InputStream in = url.openStream();

// Now, let's 'unset' the proxy.
System.setProperty("http.proxyHost", null);

// From now on http connections will be done directly.

Now,this works reasonably well, even if a bit cumbersome, but it can get tricky if your application is multi-threaded. Remember, system properties are “VM wide” settings, so all threads are affected. Which means that the code in one thread could, as a side effect, render the code in an other thread inoperative.

2.2) HTTPS

The https (http over SSL) protocol handler has its own set of properties:

• htttps.proxyHost
• https.proxyPort

As you probably guessed these work in the exact same manner as their http counterparts, so we won't go into much detail except to mention that the default port number, this time, is 443 and that for the "non proxy hosts" list, the HTTPS protocol handler will use the same as the http handler (i.e. http.nonProxyHosts).

2.3) FTP

Settings for the FTP protocol handler follow the same rules as for http, the only difference is that each property name is now prefixed with 'ftp.' instead of 'http.'

Therefore the system properties are:

• ftp.proxHost
• ftp.proxyPort
• ftp.nonProxyHosts

Note that, this time, there is a separate property for the "non proxy hosts" list. Also, as for http, the default port number value is 80. It should be noted that when going through a proxy, the FTP protocol handler will actually use HTTP to issue commands to the proxy server, which explains why this is the same default port number.

Let's examine a quick example:

$ java -Dhttp.proxyHost=webcache.mydomain.com
-Dhttp.proxyPort=8080 -Dftp.proxyHost=webcache.mydomain.com -Dftp.proxyPort=8080 GetURL

Here, both the HTTP and the FTP protocol handlers will use the same proxy server at webcache.mydomain.com:8080.

2.4) SOCKS

The SOCKS protocol, as defined in RFC 1928, provides a framework for client server applications to safely traverse a firewall both at the TCP and UDP level. In that sense it is a lot more generic than higher level proxies (like HTTP or FTP specific proxies). J2SE 5.0 provides SOCKS support for client TCP sockets.

There are 2 system properties related to SOCKS:

• socksProxyHost for the host name of the SOCKS proxy server
• socksProxyPort for the port number, the default value being 1080

Note that there is no dot ('.') after the prefix this time. This is for historical reasons and to ensure backward compatibility. Once a SOCKS proxy is specified in this manner, all TCP connections will be attempted through the proxy.

Example:

$ java -DsocksProxyHost=socks.mydomain.com GetURL

Here, during the execution of the code, every outgoing TCP socket will go through the SOCKS proxy server at socks.mydomain.com:1080.

Now, what happens when both a SOCKS proxy and a HTTP proxy are defined? Well the rule is that settings for higher level protocols, like HTTP or FTP, take precedence over SOCKS settings. So, in that particular case, when establishing a HTTP connection, the SOCKS proxy settings will be ignored and the HTTP proxy will be contacted. Let's look at an example:

$ java -Dhttp.proxyHost=webcache.mydomain.com -Dhttp.proxyPort=8080
-DsocksProxyHost=socks.mydomain.com GetURL

Here, an http URL will go through webcache.mydomain.com:8080 because the http settings take precedence. But what about an ftp URL? Since no specific proxy settings were assigned for FTP, and since FTP is on top of TCP, then FTP connections will be attempted through the SOCKS proxy server at socks.mydomsain.com:1080. If an FTP proxy had been specified, then that proxy would have been used instead.

3) Proxy class

As we have seen, the system properties are powerful, but not flexible. The "all or nothing" behavior was justly deemed too severe a limitation by most developers. That's why it was decided to introduce a new, more flexible, API in J2SE 5.0 so that it would be possible to have connection based proxy settings.

The core of this new API is the Proxy class which represents a proxy definition, typically a type (http, socks) and a socket address. There are, as of J2SE 5.0, 3 possible types:

• DIRECT which represents a direct connection, or absence of proxy.
• HTTP which represents a proxy using the HTTP protocol.
• SOCKS which represents proxy using either SOCKS v4 or v5.

So, in order to create an HTTP proxy object you would call:

SocketAddress addr = new
InetSocketAddress("webcache.mydomain.com", 8080);
Proxy proxy = new Proxy(Proxy.Type.HTTP, addr);

Remember, this new proxy object represents a proxy definition, nothing more. How do we use such an object? A new openConnection() method has been added to the URL class and takes a Proxy as an argument, it works the same way asopenConnection() with no arguments, except it forces the connection to be established through the specified proxy, ignoring all other settings, including the system properties mentioned above.

So completing the previous example, we can now add:

URL url = new URL("http://java.sun.com/");
URConnection conn = url.openConnection(proxy);

Simple, isn't it?

The same mechanism can be used to specify that a particular URL has to be reached directly, because it's on the intranet for example. That's where the DIRECT type comes into play. But, you don't need to create a proxy instance with the DIRECT type, all you have to do is use the NO_PROXY static member:

URL url2 = new URL("http://infos.mydomain.com/");
URLConnection conn2 = url2.openConnection(Proxy.NO_PROXY);

Now, this guarantees you that this specific URL will be retrieved though a direct connection bypassing any other proxy settings, which can be convenient.

Note that you can force a URLConnection to go through a SOCKS proxy as well:

SocketAddress addr = new InetSocketAddress("socks.mydomain.com", 1080);
Proxy proxy = new Proxy(Proxy.Type.SOCKS, addr);
URL url = new URL("ftp://ftp.gnu.org/README");
URLConnection conn = url.openConnection(proxy);

That particular FTP connection will be attempted though the specified SOCKS proxy. As you can see, it's pretty straightforward.

Last, but not least, you can also specify a proxy for individual TCP sockets by using the newly introduced socket constructor:

SocketAddress addr = new InetSocketAddress("socks.mydomain.com", 1080);
Proxy proxy = new Proxy(Proxy.Type.SOCKS, addr);
Socket socket = new Socket(proxy);
InetSocketAddress dest = new InetSocketAddress("server.foo.com", 1234);
socket.connect(dest);

Here the socket will try to connect to its destination address (server.foo.com:1234) through the specified SOCKS proxy.

As for URLs, the same mechanism can be used to ensure that a direct (i.e. not through any proxy) connection should be attempted no matter what the global settings are:

Socket socket = new Socket(Proxy.NO_PROXY);
socket.connect(new InetAddress("localhost", 1234));

Note that this new constructor, as of J2SE 5.0, accepts only 2 types of proxy: SOCKS or DIRECT (i.e. the NO_PROXY instance).

4) ProxySelector

As you can see, with J2SE 5.0, the developer gains quite a bit of control and flexibility when it comes to proxies. Still, there are situations where one would like to decide which proxy to use dynamically, for instance to do some load balancing between proxies, or depending on the destination, in which case the API described so far would be quite cumbersome. That's where the ProxySelector comes into play.

In a nutshell the ProxySelector is a piece of code that will tell the protocol handlers which proxy to use, if any, for any given URL. For example, consider the following code:

URL url = new URL("http://java.sun.com/index.html");
URLConnection conn = url.openConnection();
InputStream in = conn.getInputStream();

At that point the HTTP protocol handler is invoked and it will query the proxySelector. The dialog might go something like that:

Handler: Hey dude, I'm trying to reach java.sun.com, should I use a proxy?
ProxySelector: Which protocol do you intend to use?
Handler: http, of course!
ProxySelector: On the default port?
Handler: Let me check.... Yes, default port.
ProxySelector: I see. Then you shall use webcache.mydomain.com on port 8080 as a proxy.
Handler: Thanks. Dude, webcache.mydomain.com:8080 doesn't seem to be responding! Any other option?
ProxySelector: Dang! OK, try webcache2.mydomain.com, on port 8080 as well.
Handler: Sure. Seems to be working. Thanks.
ProxySelector: No sweat. Bye.

Of course I'm embellishing a bit, but you get the idea.

The best thing about the ProxySelector is that it is plugable! Which means that if you have needs that are not covered by the default one, you can write a replacement for it and plug it in!

So what is a ProxySelector? Let's take a look at the class definition:

public abstract class ProxySelector {
        public static ProxySelector getDefault();
        public static void setDefault(ProxySelector ps);
        public abstract List select(URI uri);
        public abstract void connectFailed(URI uri,
                SocketAddress sa, IOException ioe);
}

As we can see, ProxySelector is an abstract class with 2 static methods to set, or get, the default implementation, and 2 instance methods that will be used by the protocol handlers to determine which proxy to use or to notify that a proxy seems to be unreachable. If you want to provide your own ProxySelector, all you have to do is extend this class, provide an implementation for these 2 instance methods then call ProxySelector.setDefault() passing an instance of your new class as an argument. At this point the protocol handlers, like http or ftp, will query the new ProxySelector when trying to decide what proxy to use.

Before we see in details how to write such a ProxySelector, let's talk about the default one. J2SE 5.0 provides a default implementation which enforces backward compatibility. In other terms, the default ProxySelector will check the system properties described earlier to determine which proxy to use. However, there is a new, optional feature: On recent Windows systems and on Gnome 2.x platforms it is possible to tell the default ProxySelector to use the system proxy settings (both recent versions of Windows and Gnome 2.x let you set proxies globally through their user interface). If the system property java.net.useSystemProxies is set to true (by default it is set to false for compatibility sake), then the default ProxySelector will try to use these settings. You can set that system property on the command line, or you can edit the JRE installation file lib/net.properties, that way you have to change it only once on a given system.

Now let's examine how to write, and install, a new ProxySelector.

Here is what we want to achieve: We're pretty happy with the default ProxySelector behavior, except when it comes to http and https. On our network we have more than one possible proxy for these protocols and we we'd like our application to try them in sequence (i.e.: if the 1^st one doesn't respond, then try the second one and so on). Even more, if one of them fails too many time, we'll remove it from the list in order to optimize things a bit.

All we need to do is subclass java.net.ProxySelector and provide implementations for both the select() and connectFailed() methods.

The select() method is called by the protocol handlers before trying to connect to a destination. The argument passed is a URI describing the resource (protocol, host and port number). The method will then return a List of Proxies. For instance the following code:

URL url = new URL("http://java.sun.com/index.html");
InputStream in = url.openStream();

will trigger the following pseudo-call in the protocol handler:

List l = ProxySelector.getDefault().select(new URI("http://java.sun.com/"));

In our implementation, all we'll have to do is check that the protocol from the URI is indeed http (or https), in which case we will return the list of proxies, otherwise we just delegate to the default one. To do that, we'll need, in the constructor, to store a reference to the old default, because ours will become the default.

So it is starting to look like this:

public class MyProxySelector extends ProxySelector {
        ProxySelector defsel = null;
        MyProxySelector(ProxySelector def) {
                defsel = def;
        }
        
        public java.util.List select(URI uri) {
                if (uri == null) {
                        throw new IllegalArgumentException("URI can't be null.");
                }
                String protocol = uri.getScheme();
                if ("http".equalsIgnoreCase(protocol) ||
                        "https".equalsIgnoreCase(protocol)) {
                        ArrayList l = new ArrayList();
                        // Populate the ArrayList with proxies
                        return l;
                }
                if (defsel != null) {
                        return defsel.select(uri);
                } else {
                        ArrayList l = new ArrayList();
                        l.add(Proxy.NO_PROXY);
                        return l;
                }
        }
}

First note the constructor that keeps a reference to the old default selector. Second, notice the check for illegal argument in the select() method in order to respect the specifications. Finally, notice how the code defers to the old default, if there was one, when necessary. Of course, in this example, I didn't detail how to populate the ArrayList, as it not of particular interest, but the complete code is available in the appendix if you're curious.

As it is, the class is incomplete since we didn't provide an implementation for the connectFailed() method. That's our very next step.

The connectFailed() method is called by the protocol handler whenever it failed to connect to one of the proxies returned by the select() method. 3 arguments are passed: the URI the handler was trying to reach, which should be the one used whenselect() was called, the SocketAddress of the proxy that the handler was trying to contact and the IOException that was thrown when trying to connect to the proxy. With that information, we'll just do the following: If the proxy is in our list, and it failed 3 times or more, we'll just remove it from our list, making sure it won't be used again in the future. So the code is now:

public void connectFailed(URI uri, SocketAddress sa, IOException ioe) {
        if (uri == null || sa == null || ioe == null) {
                throw new IllegalArgumentException("Arguments can't be null.");
        }
        InnerProxy p = proxies.get(sa); 
        if (p != null) {
                if (p.failed() >= 3)
                        proxies.remove(sa);
        } else {
                if (defsel != null)
                        defsel.connectFailed(uri, sa, ioe);
        }
}

Pretty straightforward isn't it. Again we have to check the validity of the arguments (specifications again). The only thing we do take into account here is the SocketAddress, if it's one of the proxies in our list, then we do deal with it, otherwise we defer, again, to the default selector.

Now that our implementation is, mostly, complete, all we have to do in the application is to register it and we're done:

public static void main(String[] args) {
        MyProxySelector ps = new MyProxySelector(ProxySelector.getDefault());
        ProxySelector.setDefault(ps);
        // rest of the application
}

Of course, I simplified things a bit for the sake of clarity, in particular you've probably noticed I didn't do much Exception catching, but I'm confident you can fill in the blanks.

It should be noted that both Java Plugin and Java Webstart do replace the default ProxySelector with a custom one to integrate better with the underlying platform or container (like the web browser). So keep in mind, when dealing with ProxySelector, that the default one is typically specific to the underlying platform and to the JVM implementation. That's why it is a good idea, when providing a custom one, to keep a reference to the older one, as we've done in the above example, and use it when necessary.

5) Conclusion

As we have now established J2SE 5.0 provides quite a number of ways to deal with proxies. From the very simple (using the system proxy settings) to the very flexible (changing the ProxySelector, albeit for experienced developers only), including the per connection selection courtesy of the Proxy class.

Appendix

Here is the full source of the ProxySelector we developed in this paper. Keep in mind that this was written for educational purposes only, and was therefore kept pretty simple on purpose.

import java.net.*;
import java.util.List;
import java.util.ArrayList;
import java.util.HashMap;
import java.io.IOException;

public class MyProxySelector extends ProxySelector {
        // Keep a reference on the previous default
    ProxySelector defsel = null;
        
        /*
         * Inner class representing a Proxy and a few extra data
         */
        class InnerProxy {
        Proxy proxy;
                SocketAddress addr;
                // How many times did we fail to reach this proxy?
                int failedCount = 0;
                
                InnerProxy(InetSocketAddress a) {
                        addr = a;
                        proxy = new Proxy(Proxy.Type.HTTP, a);
                }
                
                SocketAddress address() {
                        return addr;
                }
                
                Proxy toProxy() {
                        return proxy;
                }
                
                int failed() {
                        return ++failedCount;
                }
        }
        
        /*
         * A list of proxies, indexed by their address.
         */
        HashMap proxies = new HashMap();

        MyProxySelector(ProxySelector def) {
          // Save the previous default
          defsel = def;
          
          // Populate the HashMap (List of proxies)
          InnerProxy i = new InnerProxy(new InetSocketAddress("webcache1.mydomain.com", 8080));
          proxies.put(i.address(), i);
          i = new InnerProxy(new InetSocketAddress("webcache2.mydomain.com", 8080));
          proxies.put(i.address(), i);
          i = new InnerProxy(new InetSocketAddress("webcache3.mydomain.com", 8080));
          proxies.put(i.address(), i);
          }
          
          /*
           * This is the method that the handlers will call.
           * Returns a List of proxy.
           */
          public java.util.List select(URI uri) {
                // Let's stick to the specs. 
                if (uri == null) {
                        throw new IllegalArgumentException("URI can't be null.");
                }
                
                /*
                 * If it's a http (or https) URL, then we use our own
                 * list.
                 */
                String protocol = uri.getScheme();
                if ("http".equalsIgnoreCase(protocol) ||
                        "https".equalsIgnoreCase(protocol)) {
                        ArrayList l = new ArrayList();
                        for (InnerProxy p : proxies.values()) {
                          l.add(p.toProxy());
                        }
                        return l;
                }
                
                /*
                 * Not HTTP or HTTPS (could be SOCKS or FTP)
                 * defer to the default selector.
                 */
                if (defsel != null) {
                        return defsel.select(uri);
                } else {
                        ArrayList l = new ArrayList();
                        l.add(Proxy.NO_PROXY);
                        return l;
                }
        }
        
        /*
         * Method called by the handlers when it failed to connect
         * to one of the proxies returned by select().
         */
        public void connectFailed(URI uri, SocketAddress sa, IOException ioe) {
                // Let's stick to the specs again.
                if (uri == null || sa == null || ioe == null) {
                        throw new IllegalArgumentException("Arguments can't be null.");
                }
                
                /*
                 * Let's lookup for the proxy 
                 */
                InnerProxy p = proxies.get(sa); 
                        if (p != null) {
                                /*
                                 * It's one of ours, if it failed more than 3 times
                                 * let's remove it from the list.
                                 */
                                if (p.failed() >= 3)
                                        proxies.remove(sa);
                        } else {
                                /*
                                 * Not one of ours, let's delegate to the default.
                                 */
                                if (defsel != null)
                                  defsel.connectFailed(uri, sa, ioe);
                        }
     }
}

MK 500

The MK500 has three programmable function buttons that correspond to Up Arrow, Enter, and Down Arrow from left to right, by default.

Configure these settings remotely using the System Configuration Manager (SCM), or locally on the MK500 using the Control Panel. These settings are saved in the configuration registry file (mkconfig.reg) in the MK500
Application folder to maintain them across cold boot cycles.

Cold Boot

Press and hold reset button on the side of the MK500 for 10 seconds, then release, OR remove and apply power.

Warm Boot
Run the Warmboot application. Select Start > Programs > Warmboot. Alternatively, use the Application Program Interface (API).

Flash: Nonvolatile (Persistent) Memory

The MK500 64 MB configuration has 64 MB of available nonvolatile flash memory. 5 MB is committed for platform partition use to install external driver packs such as RF drivers, and 27 MB is available for developer’s applications within the application partition (folder). The data partition (folder) has no available memory. The data stored in flash memory persists through cold boot cycles.

Download the DCP from the Support Central web site,
https://docs.symbol.com/KanisaPlatform/Publishing/693/12776_f.html?userId=37
http://www.motorola.com/enterprisemobility/support


startup app setting
http://www.steponesystems.com/blog/?p=287

MK500 & MK4000 USB Serial Cable Driver
http://support.symbol.com/support/search.do?cmd=displayKC&docType=kc&externalId=12711&sliceId=&dialogID=256004784&stateId=1%200%20256006229

Developing and Deploying Java-Tomcat apps into Windows Azure

ref: http://blogs.msdn.com/b/cesardelatorre/archive/2010/09/12/developing-and-deploying-java-tomcat-apps-into-windows-azure.aspx



As you may know, Windows Azure is a multi-platform environment, so we can run many other languages/platforms other than .NET, like Java, PHP, Ruby, etc., and even using a whole Web-AppServer like Apache Tomcat, a DBMS like MySQL, and using IDEs like ECLIPSE. You can get more info about this here:
http://www.microsoft.com/windowsazure/interop/

So, in this case, what I wanna show in this post is how you can develop and deploy a simple JAVA app (.JSP and SERVLET app) into Windows Azure (I’ll show it into the Windows Azure local Dev-Fabric but also into the real Windows Azure cloud in the Internet).
There are a few steps we need to accomplish, like installing Java SDK, Tomcat, etc. This is the software I installed in my dev machine (a Windows 7 machine):

SOFTWARE INSTALLATION

Regarding base software installation (Java, Tomcat & Eclipse), it is critical that you install versions that match each other, especially talking about the processor version (x86 or x64). In my case, all versions that I installed are x86 (Even though my Windows 7 is a x64 version, there’s no problem with that).
So, I installed the following software versions:
JDK 6 Update 21 (STANDARD) Windows x86
https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_Developer-Site/en_US/-/USD/ViewProductDetail-Start?ProductRef=jdk-6u21-oth-JPR@CDS-CDS_Developer
Eclipse IDE for Java EE Developers (GALILEO SR2)
http://www.eclipse.org/downloads/packages/eclipse-ide-java-ee-developers/galileosr2

Apache Tomcat 6.0.29
IMPORTANT: Download the Windows zipversion. In my case, the ‘32-bit Windows zip’ version, from the following URL:
http://tomcat.apache.org/download-60.cgi
Do not install the ‘32-bit/64-bit Windows Service Installer’, as this is the TomCat Windows Service version, and you won’t be able to deploy a Windows/NT Service in Windows Azure PaaS. We need the ‘process/command’ version of Apache Tomcat.
Then, just unzip Tomcat in your selected directory.
In order to run Tomcat, we also need to set the JRE_HOME environment Variable to the JAVA SDK directory. In my case, “C:\Program Files (x86)\Java\jdk1.6.0_21”:

Install the Windows Azure Tools for ECLIPSE:
Once you have Eclipse already installed, run Eclipse and install the ‘Windows Azure Tools for ECLIPSE’ from Eclipse itself:
--> Eclipse-->Help-->Install New Software --> Download Windows Azure Tools for ECLIPSE by clicking on Add, giving a name ‘Windows Azure Tools for Eclipse’ --> Location: http://www.windowsazure4e.org/update --> SelectWindows Azure Java SDK, like you can see down-below:

Then, almost “Next-Next-Next”…
Windows Azure Tomcat Solution Accelerator
Download and unpack the ‘Windows Azure Tomcat Solution Accelerator’. You can get it from here (in my case, I used the x86 version, to match the other x86 versions):
http://code.msdn.microsoft.com/winazuretomcat/Release/ProjectReleases.aspx?ReleaseId=3550

Java Demo-App creation

- Create a New Project in Eclipse: File-->New-->Other-->Web-->Dynamic Web Project --> Set a name --> “HelloWorld” --> Create
- Then we need to add the external JARs for JSP and Servlets support:
- Project Properties --> Java Build Path --> Libraries --> Add External JARs --> My Compurtes-HardDrive--> Eclipse folders--> C:\JavaEnv\eclipse\plugins -->javax.servlet.jsp_2.0.0.v200806031607.jar AND javax.servlet_2.5.0.v200910301333.jar files:
- 
- If we would want to access Windows Azure storage (Blobs/Queues/Tables) from Java we’d need to add the following JAR: org.soyatec.windows.azure.java_1.0.0.201002091324
- But in this case I just want to run a standard and simple JSP and SERVLET App.
- Then, OK-->OK.
- Now, we add a simple .JSP page:
- Expand Project --> New --> .JSP --> Name: “index.jsp” -->
- We add its code, very simple HTML form code that will call/execute our future SERVLET:

- Now, we créate our SERVLET project:
- From Eclipse, New-->Other-->Web-->Servlet
- Dialogo SERVLET -->
o Java Package --> Specify a selected name for your Java Package, like “MyJavaPackage”
o Class Name: --> Specify “HelloWorldServlet”
- Next
- Add description --> “Simple demo Servlet App”
- Next
- Methods --> DoPost & DoGet
- --> Click FINISH

- Now, within the doPost() method we introduce our ‘process’ code. We could put it in a different method, but for this short demo, we can directly put it there, within the doPost():

package MyJavaPackage; import java.io.IOException; import java.io.PrintWriter; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; /** * Servlet implementation class HelloWorldServlet */ public class HelloWorldServlet extends HttpServlet { private static final long serialVersionUID = 1L; public HelloWorldServlet() { // TODO Auto-generated constructor stub } protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // TODO Auto-generated method stub } protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html;charset=UTF-8"); PrintWriter out = response.getWriter(); String fullName = request.getParameter("fullname").toString(); out.println(""); out.println(""); out.println(""); out.println(""); out.println(""); out.println(" Hi " + fullName + ", greetings from JAVA Server environment!! "); out.println(""); out.println(""); out.close(); } }

- You can see similar code in Eclipse:
- 
- Import PrintWriter option using the rightClick mouse context.
- START Aapche TomCat up:
- From the Command-Prompt, within the Tomcat’s directory, just type ”startup.bat”:

- From ECLIPSE, I EXPORT my Project as a WAR FILE:
- RightClick on Project-->Export-->WAR FILE
o Destination, in my case: E:\JavaEnv\apache-tomcat-6.0.29-windows-x86\webapps --> and ROOT.WAR as my filename, so it will run as default webapp.
o Check Overwrite Existing Files

- And finally, test the default page (my .JSP page should be executed):
- 
- Write any name and submit to the SERVLET, and see results:
- 
- OK, so our Java app is running now on a regular Apache TomCat (In a Apache Command process).

Deploying the App to Windows Azure local Development-Fabric

- Open CMD from Windows Azure SDK (Programs--> Windows Azure SDK v1.2--> Windows Azure SDK Command Prompt)
- Move to the directory where I have unpacked the Windows Azure Tomcat Solution Accelerator. In my case:
- cd E:\JavaEnv\WATomcatAccelerator_x86\Tomcat
- 
- We have 3 Command files (Buildme.cmd, Packme.cmd and Runme.cmd):
- 
- Buildme.cmd creates/builds our solution. In this step we’ll need to provide the Apache-tomcat path, and the Java runtime path. It gives us complete control as we can deploy any particular Tomcat or Java runtime version.
- The Runme.cmd command deploys and runs our app and base software into Windows Azure DEVELOPMENT fabric. It moves Tomcat and Java runtime into WA dev-fabric local storage, and also, our app.
- Next thing we need to to is to configure TomCat to listen in the right TCP port. In WA we have a load-balancer for all our VM instances, but we need to run Tomcat in any other port than port 80. We need to configure it so the Load-Balancer can ‘talk’ to TomCat.
- Next thing we need to do is to start TomCat Service.
- And finally it’s going to monitor TomCat, so if for some reason TomCat crashes, then WA will be notified and we can re-start a WE node, etc.

STEP 1: Building the solution: Run the BUILDME.CMD

- The Buildme.cmd batch file which is available in the root folder of the solution generates the CSX folder. This batch file should be executed only from the Windows Azure SDK command prompt. On executing this, it checks if the Tomcat and Java binaries are present in the required directories. If not, it prompts for the path to the binaries and the user needs to give the path to the binaries folder (for e.g. E:\Binaries\Tomcat). On a successful build, it generates the CSX folder under the root folder of the solution. This is required to run the solution in development fabric.
- It first asks for the tomcat binaries, so we provide it (E:\JavaEnv\apache-tomcat-6.0.29-windows-x86):
- 
- Then, it asks for the Java runtime binaries path, in my case “C:\Program Files (x86)\Java\jre6”:

STEP 2: Running the solution (WA development fabric): Run the RUNME.CMD

- Now we build the app with the Runme.cmd command file:
- 
- It deploys JRE, Tomcat and our App into the WA Dev-Fabric, and finally it starts TomCat:
- 
- Now we go to the App-Dev-Fabric where we can see it running:
- 
- Then we can go and use any Browser to run our app. We need to specify the IP address and TCP port where WA-Dev-Fabric started TomCat, that in my case is, http://127.0.0.1:81:
- 
- So finally we can see our Java app running on TomCat and Windows Azure local Development Fabric:
- 
- Next step would be uploading our app to Windows Azure cloud in the Internet.

STEP 3: Uploading the solution to Windows Azure cloud in the Internet

- The Packme.cmd batch file which is available in the root folder of the solution generates the Tomcat.cspkg for the solution under the root folder itself. This batch file should be executed only from the Windows Azure SDK command prompt. . This package along with the service configuration file (.cscfg) is used for deploying the solution on the cloud. The package file and service configuration file are required to deploy the solution on cloud. Once the package is deployed on cloud, the application can be accessed via the following URLs.

Application	Staging URL	Production URL
Admin page	http://.cloudapp.net	http://.cloudapp.net

- NOTE: The ServiceDefinition.csdef and ServiceConfiguration.cscfg files should be kept under the root folder of solution for the Buildme.cmd, Packme.cmd and Runme.cmd to execute properly. So if any change has been done to these files in the solution, the latest should be copied to the root folder too.
- So, when we run the Packme.cmd, we generate the WA package needed to upload it:
- 
- We can see in our directory that there’s been a new .cspkg Windows Azure file generated for us:
- 
- Take into account that because of we need to upload JRE & TomCat, our app’s package is quite heavy (around 56 Mb), and therefore, deployment upload will take long. One workaround for that is uploading it just once to a Windows Azure BLOB and then we can deploy it from there much faster (in case we delete/upload same app’s version many times).
- So now, we just need to upload it to the Production or staging environment in WA cloud through the WA dev portal:
- 
- But, I really recommend uploading it first to a Windows Azure BLOB, for instance, using the Azure Storage Explorer:
- 
- Then, in this other way, the deployment would be like the following:
- 
- And selecting the files from within a BLOB container instead of my local PC:

- Then, we can see it uploading it (from local or from Blob container):
- 
- And after a few minutes (after uploading the package, which would be much faster from Azure Blob), we’ll see it deploying:
- 
- Once it is deployed, we need to start the node/virtual machine:
- 
- And finally, after some more minutes (wait until it reaches the ‘Ready’ state, starting on ‘Initializing’ state, then ‘Busy’ state and finally ‘Ready’ state), it will be up & running in our Windows Azure cloud:
- 
-
- And now, just execute the app from your Windows Azure URL. In my case: http://javatomcatdemo.cloudapp.net/
- 
- And then my SERVLET execution:
- 
- COOL!. Now you could try with any other Java-TomCat App. (Web-Service, etc.).

Related Links

WINDOWS AZURE INTEROP
http://www.microsoft.com/windowsazure/interop/
INTEROPERABILITY BRIDGES - LIST
http://www.interoperabilitybridges.com/Projects.aspx

TomCat Solution Accelerator
http://code.msdn.microsoft.com/winazuretomcat
AzureRunMe
http://azurerunme.codeplex.com/
Windows Azure Tools for Eclipse (PHP)
http://www.interoperabilitybridges.com/projects/windows-azure-tools-for-eclipse.aspx
Windows Azure SDK for Java
http://www.interoperabilitybridges.com/projects/windows-azure-sdk-for-java.aspx
AppFabric SDK for JAVA
http://www.jdotnetservices.com/
TomCat Logs
http://code.msdn.microsoft.com/azurediag
Windows Azure Mediawiki MySQL Solution Accelerator
http://code.msdn.microsoft.com/winazuremediawiki
Windows Azure Jetty Solution Accelerator
http://code.msdn.microsoft.com/winazurejetty
eBay’s page for iPad listings — http://ipad.ebay.com— (hosted on the public Windows Azure platform). You may need iPad to view the page.