How to use HTTPS in Tomcat?

This is just a short note about how to use https in Tomcat (7)…

First, we have to generate a key with a password, e.g. qwerty:

“%JAVA_HOME%\bin\keytool” -genkey -alias tomcat -keyalg RSA -keystore /etc/tomcat7/tomcat.keystore

Then, we need to edit the /etc/tomcat7/server.xml file — uncomment connector ssl 8443 there and add attributes keystoreFile and keystorePass:

keystoreFile=”/etc/tomcat7/tomcat.keystore”
keystorePass=”qwerty”

At the end, remember to restart tomcat7 service: sudo service tomcat7 restart.

For more info, please visit https://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html.

Quick, encrypted, remote backup – tar, gpg and ssh

If you want to make quick encrypted remote backup of your data, the only things you need are bash, tar, gpg and ssh.
“tar” packs your data into a single stream of bytes, “gpg” encrypts the stream and “ssh” remotely stores the encrypted stream to chosen file.

tar cv folder_to_backup | gpg -e -r gpg_user_id | ssh remote.host "cat > folder_backup.tar.gpg"

Note – you don’t need to compress “tar” stream as “gpg” during encryption compresses data for you.

Prevent selected Debian package from upgrading

An example situation we have had recently: Erlang Solutions have published a new version of esl-erlang package with the newest Erlang/OTP 20.0. This new major Erlang release contains a few incompatibilities with earlier versions and that is why we have had to hold this update in a system we have been building.

There is a simple way to temporarily prevent apt-get upgrade from upgrading the ‘esl-erlang’ package to the newest version – the only thing you need to do is to put this package on ‘hold’ with apt-mark hold els-erlang.

Later on you use apt-mark unhold esl-erlang to again allow debian package manager to upgrade this package.

Locked file system after restarting Docker service

During the system upgrade (apt-get upgrade) which updates also the docker-engine package, the docker service is restarted, which means stopping all containers.

Theoretically, containers created with the restart policy set to „always” should restart themselves automatically, but some time ago we had a problem with restarting one of such containers. The container was part of the multi-container application:

Continue reading “Locked file system after restarting Docker service”