Server Build Part 1 - Hardware
Using server resources from IaaS providers such as Digital Ocean are very convenient and sometimes necessary with services which can’t be hosted at home such as an e-mail server, but the true goal of this project is to be as self-sufficient as possible and host everything at home. There should be as little impact as possible if the connection to the Internet goes down.
I’ve posted previously about the new Unifi network gear which consists of a 24-port managed switch, the Unifi Security Gateway, and Unifi Access Points for the wireless network.
Encryption for the masses
End-to-end encryption has been a hot topic for years now as more people realize that their data is highly sought after by criminals, their privacy is compromised by those who want to market to them, and their rights are under attack by governments both authoritarian and authoritarian-under-the-guise-of-national-security.
There are a several measures making their way through the US Congress which wouldn’t necessarily make end-to-end encyption illegal (that would be unconsitutional), but they aim to make it economically or technologically infeasible for technology companies to offer services which incoporate end-to-end encryption.
You’ve got mail!
If you follow r/selfhosted, you know that one of the most common questions asked is, “can I self-host e-mail?” This is usually because most people bought into the Google (Hotmail and Yahoo!) promise of free e-mail only to find out that there are some trade-offs.
There is the privacy trade-off that Google is scanning your e-mail to build a profile about you to show you ads or to sell to data aggregators which is used for the purposes of marketing.
Ansible Refined
As I was working on being able to deploy to a Digital Ocean droplet for “development”, “test”, and “production”, I realized that my original vision of the Ansible playbooks needed some refinement.
First, rather than listing each server and a number of roles which build on each other like this:
- name: Lachlanlife Prod server hosts: - lachlanblog remote_user: ansible become: yes roles: - common - debian - fail2ban - sshkeys-root - ufw It made more sense to utilize dependencies to define which roles are required to support the final role.
Ansible what?
Since the last update, I have been working to set up a basic way to automate common configuration and management tasks with Ansible. The basic Ansible setup uses a primary controller host with the Ansible software installed which has access to the various nodes to managed via Secure Shell (SSH).
The managed hosts have minimal requirements. Namely they need to be able to receive incoming SSH connections, contain a Python interpreter to execute the commands, and usually an authentication mechanism such as SSH keys to allow logins without typing in a password.