Posts

I needed a local mercurial hosting option. The following is what I came up with. Hopefully, you will find it useful or the post at least gives you some ideas. My requirements were basic.

• Web browsable repositories
• Minimal and maintenance-free
• Support for pushing new changesets
• Accessible through a URL to easily pull dependencies
• Needed access from a single computer (which let me omit authentication)

I didn’t need bug tracking, code review, or anything fancy. Essentially, all I needed was to run hg serve all the time, which is what I did. The repositories are hosted on the same computer I develop on, which allowed me to skip adding authentication. The mercurial server is bound to a loopback IP address making it only available to my pc. Adding authentication wouldn’t have added any additional security compared to having the local files on my computer.

SpamAssassin won’t do much if it hasn’t been trained. While it does come with a few plugins enabled for DKIM, SPF, RBL, and content checks, SpamAssassin is limited unless you train its Bayesian filter. The Bayesian filter will compare past content from known spam and ham emails to determine the likelihood of spam.

Bayes’ theorem, named after 18th-century British mathematician Thomas Bayes, is a mathematical formula for determining conditional probability. Conditional probability is the likelihood of an outcome occurring, based on a previous outcome occurring.

Are you curious about SpamAssasin’s sa-update tool and what it does? As with many other programs geared towards servers, there are additional tools that are run inside of cron jobs and used by administrators. Knowing what these tools do and how they work can help you better understand your server and fix issues down the line.

The sa-update tool is used to pull new configuration files and rules from channels. These new files are used by SpamAssassin to classify emails as spam in addition to the Naive Bayes filtering. Among these files, there are definitions of free email providers, regex checks on subjects and body of messages, and more.

Starting with microservice design, it’s easy to follow your old habits of designing each microservice as if it was a normal application. One aspect of this, that I fell into when first moving to microservice applications, was adding authentication to my microservices that were only accessible from internal systems.

The level in which you secure your microservices is dependent on your infrastructure, who will be using the microservices, and the availability of the microservice. Not all microservices need authentication. The simplest example to point to is a memcache server. When your service is running internally and is only used by your applications, authentication may not be required. The same goes for transport encryption, but I usually implement TLS in the unlikely case of routing errors and because most HTTP libraries will have support for it already.

With Docker, it’s easy to end up with images many times larger than they need to be. Even if you remove unnecessary files and packages, you’ll still see your image size be much larger than expected. The size of the image may not seem too important to some, but there are many benefits to having smaller docker images.

A smaller image will allow you to upload and download the images faster. When deploying your apps, the time difference between a 3GB and a 150MB image is very noticeable. Containers are meant to be as lightweight and small as possible. Along with the time saved when deploying, you are also saving disk space. Disk space is cheap but the IO cost behind it can be expensive.