Port Forwarding, The way I use SSH

"Secure Shell or SSH is a network protocol that allows data to be exchanged using a secure channel between two networked devices." Wikipedia.
That is just an abstract definition. I use SSH to do much more. Here are just some simple commands that I used to run for such a different reasons:

Whenever I need to pass stupid filtering of stupid government

ssh -D 8888 root@100.101.102.103

"100.101.102.103" is just the host that you want to connect it. I assumed that 100.101.102.103 is a SSH enabled machine.
This command simply forwards the remote machine's HTTP port to my local machine. So I just need to use a socks4 proxy like this : 127.0.0.1:8888.
So whatever you do using your browser will forward to the remote machine. The channel between your local machine and the remote one is pretty secured. However, the remote machine should be trusted.


Whenever I need to connect a remote MS-SQLServer on a windows machine using my Linux machine
Assume a service such as SQLServer which runs on a machine that is hosted in a remote LAN with [192.168.0.100] IP address. Assume you just can connect to another machine that is hosted in the same LAN using:

ssh root@100.101.102.103

Assume again the MS-SQLServer uses the port number 1433.
I need to connect to the ssh server machine using ssh root@100.101.102.103 moreover I need to forward 192.168.0.100:1433 to my local machine. This is the simple solution:

ssh -L 1433:192.168.0.100:1433 root@100.101.102.103 -N

The pattern is "ssh -L myPort:host:hostPort". -N is useful for just forwarding ports and nothing else.

The connections could be same as below map:

my machine       ssh server            MS-SQLServer
127.0.0.1 <===> 100.101.102.103 <===> 192.168.0.100

Note:
-Install OpenSSH if you need to provide SSH over Windows servers.
-To access ports under 1024 you should have root privilege.

MuleSoft's Tcat, an Enterprise view to the Tomcat

Apache Tomcat is the most convenient and reliable tool that I've ever seen. Here are Tomcat's power points that I've founded during my experiences:

-Tomcat works cross platforms. Just by copying from a machine to another one it serves applications. For example from a Linux to a Windows just a copy is enough.

-Tomcat is fast to deploy and easy to use. In most cases you just need to copy the WAR and forget about later configurations.

-Tomcat doesn't need as much resources as others.

While Tomcat doesn't claim to provide hosting services for the enterprise level of business we developers used to overused it.
It is long time that market is expecting such as plugin or solution that give Tomcat the capabilities which developer and administrators need.

Now MuleSoft made it. I just downloaded and try TCat server of Mulesoft. The amasing thing is that it remained a Tomcat. The major different is that they developed and deployed an application that is hosted within the TCat. It called "Console". TCat's console gives some missed features such as "Profile". I used to have different Tomcats on my machine depends on the projects. I work on Tele-communication and monitoring solutions using SNMP, TR-069 and JMX. In In another team I just develop web-based business applications. So I have to separate Tomcats regarding to different natures of companies and purposes. Now TCat profiles solved this problem. Also TCat has provided a repository that helps you to keep and manage your WARs. TCat has an embedded JRE! Also it is possible to use your pre-installed JRE. Anyway this gives TCat more enterprise shape!
I prefer to use an enterprise Apache Tomcat rather an IBM Webspher. :)

When Tomcat looks different cross Linux flavors

Some days ago at the time I was working on different Linux flavors to setup a uniform solution, I have notified that there are many differences in Tomcat installed files and configuration even when you have same Tomcat version. The mission was setting up a centralized monitoring system that makes user enable to track what is happening within Tomcat and its applications on different Linux machines such as CentOS, FreeBSD and Ubuntu. I was developed the solution in my notebook that uses Ubuntu 9.04, Sun Java 1.6 and Tomcat 6.0. Also I qualified the solution on an Ubuntu server edition. The tests passed perfectly so I tried to migrate it to FreeBSD and CentOS. The system administrator was worry about any major modification on his servers configuration that both were pretty busy. On both FreeBSD and CentOS I had different OS, Java and Tomcat. FreeBSD 7.2 had its own Java runtime and JDK that called Diablo. It used a Tomcat version 5.5. The CentOs machine had an OpenJDK Java edition. Also It uses Tomcat 5.5.
Differences between Sun JDK, OpenJDK and Diablo didn't make any trouble in using JMX. The biggest incompatibility was different installations of the same version of Tomcat that was installed in different ways by CentOS and FreeBSD package managers!
The administrators has been installed a same version of Tomcat using package managers. It seems each package manager installs a customized version of Tomcat that is more respects to the OS concerns rather than development. In CentOS I didn't find "catalina.sh" that is a well known startup routine.
Any way JMX listener didn't work and I guessed that could be caused by different Java editions. Fortunately the administrator rejected my suggestion for using Sun Java on both machine. So I tried other ways.
In latest try I just copied my Tomcat to FreeBSD and CentOS both and it worked like a charm!
Different flavors use their own package managers that install just customized versions of the packages. While any Java developer needs to produce more compatible solutions that are more usable with minor differences cross platforms. Compatibility and scalability are the most advantages of Java over other solutions. This is why we use Java. Every Java developer prefer to keep compatibility over customization.
As a suggestion just use a more secured copy of your own Tomcat over all target servers rather than muted and morphed versions that installed by package managers.
Here is a step by step tutorial of what I have done....