Configure mod_proxy_ajp with Tomcat, an example.

mod_proxy_ajp is an Apache module which can be used to forward a client HTTP request to an internal Tomcat application server using the AJP protocol.
To respond to the question "Why should I use mod_proxy_ajp rather than a classic mod_proxy ?"

• You can gain a lot of flexibility (lot of the apache modules/features can be used especially "name-based virtual hosting")
• Practical for those who need to support Java applications along with PHP / Perl … (only one apache server is needed)
• Certificates management is easier in apache configuration (this argument is a lot subjective)
• It's not Tomcat's main objective to serve http static resources (not optimized for that)
• Load balancing/cluster management is easier with an apache frontend

Tomcat configuration

You just have to create the AJP connector in the conf/server.xml file like that:

 port="8009" enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />

This line will enable AJP connections to the 8009 port of your tomcat server (localhost for example).By default you have to do nothing, the ajp connextor is already configured in default server.xml after installation.

Apache2 configuration

One way (useful if this apache is a global front end) is to create a virtual host for this application.

Listen 80
NameVirtualHost *:80
>
   ServerName tomcat.example.com
   ErrorLog /var/log/apache2/ajp.error.log
   CustomLog /var/log/apache2/ajp.log combined
 
   <Proxy *>
     AddDefaultCharset Off
     Order deny,allow
     Allow from all
   Proxy>
 
   ProxyPass / ajp://localhost:8009/
   ProxyPassReverse / ajp://localhost:8009/

• ProxyPass and ProxyPassReverse are classic reverse proxy directives used to forward the stream to another location.
• ajp://... is the AJP connector location (your tomcat's server host/port)

What's the result ?

A web client will connect through HTTP to http://tomcat.example.com/ (supposing your apache2 server is running and you configured your DNS to serve this apache instance), the mod_proxy_ajp will forward you request transparently using the AJP protocol to the tomcat application server on localhost:8009.

proxy ajp , tomcat via apache

=VirtualHost *:80=
ServerName Notebook
ErrorLog /var/log/apache2/ajp.error.log
CustomLog /var/log/apache2/ajp.log combined
=Proxy *=
AddDefaultCharset Off
Order deny,allow
Allow from all
=/Proxy=
ProxyPass / ajp://localhost:8009/
ProxyPassReverse / ajp://localhost:8009/
=/VirtualHost=

Configuration relayhost use a Google Apps (gmail) smtp with postfix

All the commands are done under the root user (or you could use sudo)

as root apt-get install postfix libsasl2 ca-certificate libsasl2-modules

Configure Postfix

This tutorial will not outline how to configure your postfix server, but we’ll jump directly to the relayhost section.  You’ll want to add the following lines to your /etc/postfix/main.cf

relayhost = [smtp.gmail.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_CAfile = /etc/postfix/cacert.pem
smtp_use_tls = yes

The above lines are telling Postfix that you want to relay mail through gmail on a specific port, telling it to authenticate, and where to find the username and password.  The last three lines specify the authentication types supported, where the certificate authority file is and that it should use tls.At this point you can restart Postfix and it should work, however it will complain about not being able to authenticate the certificate.  To take care of this issue we’ll use the ca-certificate package we installed and tell it where it can validate the certificate.

Define Username and Password

Next we’ll need to populate the sasl_passwd file.  Create the file /etc/postfix/sasl_passwd with the following contents:

[smtp.gmail.com]:587 user.name@domainGoogleApps:password

This file should have restrictive permissions and then needs to be translated into a .db that Postfix will read.

sudo chmod 400 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd

Then reload postfix (/etc/init.d/postfix reload) and you should be set.

Using & validating CA certificate

touch /etc/postfix/cacert.pem
cat /etc/ssl/certs/Thawte_Premium_Server_CA.pem >> /etc/postfix/cacert.pem

cat /etc/ssl/certs/Equifax_Secure_CA.pem >> /etc/postfix/cacert.pem 

How To scp, ssh and rsync without prompting for password

Whenever you need to use rsync to copy files, it asks for passwords. Usually scp and rsync commands are used to transfer or backup files between known hosts or by the same user on both the hosts. It can get really annoying the password is asked every time , specially if we need to automate backup with some batch scripts.
Lets say you want to copy between two hosts host_src and host_dest. host_src is the host where you would run the scp, ssh or rsyn command, irrespective of the direction of the file copy!

1. On host_src, run this command as the user that runs scp/ssh/rsync
   $ ssh-keygen -t rsa
   This will prompt for a passphrase. Just press the enter key. It'll then generate an identification (private key) and a public key. Do not ever share the private key with anyone! ssh-keygen shows where it saved the public key. This is by default ~/.ssh/id_rsa.pub:
   Your public key has been saved in /.ssh/id_rsa.pub
   

2. Transfer the id_rsa.pub file to host_dest by either ftp, scp, rsync or any other method.
   

3. On host_dest, login as the remote user which you plan to use when you run scp, ssh or rsync on host_src.
4. Copy the contents of id_rsa.pub to ~/.ssh/authorized_keys
   

$ cat id_rsa.pub >>~/.ssh/authorized_keys $ chmod 700 ~/.ssh/authorized_keys

If this file does not exists, then the above command will create it. Make sure you remove permission for others to read this file. If its a public key, why prevent others from reading this file? Probably, the owner of the key has distributed it to a few trusted users and has not placed any additional security measures to check if its really a trusted user.
5. Note that ssh by default does not allow root to log in. This has to be explicitly enabled on host_dest. This can be done by editing /etc/ssh/sshd_config and changing the option of PermitRootLogin from no to yes. Don't forget to restart sshd so that it reads the modified config file. Do this only if you want to use the root login.
   

Well, thats it. Now you can run scp, ssh and rsync on host_src connecting to host_dest and it won't prompt for the password. Note that this will still prompt for the password if you are running the commands on host_dest connecting to host_src. You can reverse the steps above (generate the public key on host_dest and copy it to host_src) and you have a two way setup ready!