So you have changed the port on which Tomcat is served within the server.xml to port 80. Now you restart Tomcat which gives you the following catalina.out error:

 
SEVERE: java.net.BindException: Permission denied<null>:80 - 

After quite a lot of ‘Googling’ the fix was actually quite straight forward.

Simply edit the tomcat7 config file located in /etc/default/tomcat7:

 
vim /etc/default/tomcat7 

Uncommend ‘AUTHBIND=no’ and change to AUTHBIND=yes.

e.g.

# If you run Tomcat on port numbers that are all higher than 1023, then you
# do not need authbind. It is used for binding Tomcat to lower port numbers.
# NOTE: authbind works only with IPv4. Do not enable it when using IPv6.
# (yes/no, default: no)
AUTHBIND=yes

Restart tomcat and that’s you running on port 80.

NOTE: Default installation of Tomcat 7 for Debian binds only ports higher than 1023 (Port 8080 by default). The above commands allows binding to privileged ports.

Update Debian Wheezy post installation:

 
apt-get update

Tomcat Installation

 
apt-get install tomcat7 tomcat7-admin

Optional, but useful to compile java source code:

 
apt-get install sun-java6-jdk 

That’s it!

Navigate to the test page to confirm working: http://<server name>:8080

*Tomcat is now located in /var/lib/tomcat7. Copy war file into webapps directory.

Simple command to find a string and replace it with another.

grep -rl 'searchstring' web | xargs sed -i 's/searchstring/replacementstring/g'

To break it all down:

grep -rl 'searchstring' web 

This section of the command greps/searches recursively for the string ‘searchstring’ inside the directory “web”.

This is then piped to:

xargs sed -i 's/searchstring/replacementstring/g'

‘searchstring’ is then replaced with ‘replacementstring’

The below will allow sftp with no password and chroot user into users directory using jailkit.

Host server

 
ssh-keygen -t rsa 

Copy public key to remote server:

 
ssh-copy-id -i ~/.ssh/id_rsa.pub username@remotehost

This puts the public keys into the remote servers home directory of the specified user. Usually inside .ssh/authorized keys. *make sure the remote user has already been added

To manually copy a key or insert a public key passed by a customer:

 
scp ~/.ssh/id_rsa.pub root@remoteserver:/root 

Remote server

2. Inside the specified users home directory create a .ssh directory

mkdir /home/userdir/.ssh 

3. Create a file called authorized_keys inside .ssh

touch /home/userdir/.ssh/authorized_keys 

4. Insert the contents of id_rsa.pub into authorized_keys

cat /root/id_rsa.pub >> /home/userdir/.ssh/authorized_keys 

This will give remote access to the remote server and drop you into the users directory

vim /etc/passwd 

Set the specified user /bin/false e.g.

user:x:5001:5002::/path/to/directory/web:/bin/false

Now we need to modify the sshd_config file:

vim /etc/ssh/sshd_config

Change Subsystem sftp /usr/lib/openssh/sftp-server to

Subsystem sftp internal-sftp 

*Append the following to the bottom of the file:*

Match Group sftp
ChrootDirectory /path/to/directory/web
AllowTCPForwarding no
X11Forwarding no
ForceCommand internal-sftp 

Now we need to set ownership and permissions:

chown user:root /home/user

chown user:root /home/user/.ssh

chown user:root /home/user/.ssh/authorized_keys

chmod 775 /home/user

chmod 700 /home/user/.ssh

chmod 600 /home/user.ssh/authorized_keys

That should be everything. Try to ssh or sftp to the remote host from the original host. You should be dropped straight into the specified directory and unable to move anywhere outside of it.

I came accross this issue when the Port Forwarding rules reached roughly 200.

The problem I had was when I added new rules past 201 (201,202,203 etc.) the Firewall would add them to the interface but the IPtables actually ignored them.

As you can imagine this was incredibly frustrating to the point a second Smoothwall Firewall was installed but the same problem returned.

From chatting with the guys on the smoothwall community ( Smoothwall) they were able to point me in the direct and instructed me to run the following from commandline:

sed -i -e 's=t-/var/log=t/var/log=' /etc/syslog.conf
kill -SIGHUP `cat /var/run/syslogd.pid`

Essentially concluded that due to massive log traffic Smoothwall was struggling to write the new port forwarding changes. The above puts a hyphen before each log file name; this is supposed to tell syslogd not to wait for the entry to reach the disk (turns off O_SYNC). The second tells syslog to close, re-read its .conf and reinitialize. If it doesn’t work, you’ll have to reboot when convenient.

I can’t take any credit for this one, “fest3er” came up with the idea on the forum.

See here: http://community.smoothwall.org/forum/viewtopic.php?f=56&t=38789