For web-applications, securing the communication between client and application is essential. As containerisation of such applications becomes the standard, I will be looking into one another method to achieve SSL encryption with a containerised NGINX web server using Let’s Encrypt.
A full-blown multi-application server typically runs a web server that hosts applications. To secure the communication between this server and clients, a secure (HTTPS) connection is initiated that uses an SSL/TLS certificate and a corresponding key to encrypt the data on a per-domain basis. A trusted Certificate Authority like Let’s Encrypt can issue certificates that indicate that you are the valid owner of a domain. To proof this ownership, Let’s Encrypt uses a protocol called ACME. Tools like CertBot and acme.sh implements this protocol and can as such allow you to obtain and renew SSL/TLS certificates signed by the Let’s Encrypt CA.
The terminal can be an effective workhorse for achieving a job. It is fast and agile and allows you to do get things done that would have taken you much more time than when you are limited to using the graphical user interface alone. The GUI, however, treated us with elegant visuals and a clear design that made working with it a comfortable experience that is easy on the eye. When working a lot in the terminal, one might want to borrow a piece of this visual experience in the form of an attractive true color terminal.
There is, however, some configuring to do to get a true color scheme working on a terminal emulator like iTerm, especially when combined with a terminal multiplexer like tmux.
Vagrant-LXC is a plugin that provides integration of Vagrant with LXC containers, a modern virtualisation technology native to Linux. To share files between the host and the container, NFS can be used. The Vagrant NFS plugin ensures that a NFS server runs at the host that exports predefined locations of the host’s filesystem. Sometimes, an error pops up when starting a Vagrant box, indicating that a timeout occurred and that starting the box failed.
A typical error is as follows:
mount.nfs: mount to NFS server '10.0.3.1:/path' failed: timed out, giving up
Which means that the connection is blocked, often due to the firewall. Another error might be something like:
mount.nfs: access denied by server while mounting 10.0.3.1:/path
This practically means that the container is not allowed to reach the NFS server of the host, often due to AppArmor policy. I experienced this issue some time ago and discussed it in an issue at Github.
Developing, maintaining and debugging web-applications often involves copying a remote database to a local or another remote machine. This post lists a number of methods that I find useful. It acts as a reference for myself which I happily update and improve based on comments and experience. My favourite method: stream the database dump directly to the target machine.
I assume a MySQL or MariaDB database on a Unix or Mac OS machine but by adjusting the appropriate commands most of these methods apply to other databases as well.
Connecting to a MySQL server often involves providing hostnames, usernames and passwords. Use a .my.cnf configuration file to provide defaults that simplify working with a MySQL server.
Providing a default password reduces security. Take effort to make sure that the password cannot be read by other users on the system. If the server runs locally, use credentials that are only allowed to connect locally.
If you use Git or remote terminal session a lot, consider using key-based authentication. Key-based authentication is generally considered more secure than password-based authentication.
In key-based authentication, two key-files are used. One is the public key and may be distributed to other parties that should be able to authenticate you and your information. The other is the private encryption key and should be kept secure.
Homebrew is a popular package manager for MacOS. It provides easy access to thousands of programs and applications. It is developed and maintained by an open-source community on Github. Use Homebrew bundle to backup and restore your Homebrew configuration.
If you haven’t installed it yet, go take a look quick on brew.sh or just install it by running the following command in the MacOS terminal.
If you use both JIRA and ISPConfig on a server you might want to set-up a reverse proxy to serve the JIRA frontend securely on the standard HTTPS port just like other websites in your ISPConfig setup. ISPConfig uses Apache to serve websites whereas JIRA has its own web-server (Tomcat). It is not straight-forward to share a single port such as the HTTPS port 443 between two applications. The Apache Reverse-Proxy feature allows us to do so however.
Advantages of using a reverse-proxy instead of serving JIRA on a different port are as follows:
Single entry-point for all web traffic
Access- and certificate management in one place (Apache via ISPConfig)
Only one or two (HTTP/HTTPS) ports need to be opened to the public
No need to specify the port when navigating to the JIRA instance
Allows traffic and statistics monitoring through Apache