Category Archives: Networking

Five easy steps for setting up SSL on HomeAssistant utilising Let’s Encrypt Certbot

Automation, Home Assistant, Linux, Networking, , , ,

Securing your HomeAssistant setup should be a priority, especially if you plan on accessing your system remotely. One of the best ways to do this is by setting up an SSL certificate. This article guides you through five easy steps to set up SSL on HomeAssistant using Let’s Encrypt Certbot.

Understanding the Importance of SSL for HomeAssistant

Secure Sockets Layer, popularly known as SSL, is a security protocol that encrypts the connection between a web server and a client. When implemented on your HomeAssistant, it prevents eavesdropping and tampering of your data by encrypting all communication between your HomeAssistant and your devices. This is crucial, especially when accessing your HomeAssistant remotely over the internet where your data could be intercepted.

Moreover, SSL also provides authentication, ensuring that you’re communicating with the right server and not a malicious one. This is achieved through the use of SSL certificates issued by trusted Certificate Authorities (CAs). These certificates also provide visual cues, such as a padlock symbol, giving end-users confidence that their connection is secure.

An Overview of Let’s Encrypt Certbot

Let’s Encrypt is a free, automated, and open Certificate Authority. It provides digital certificates needed to enable HTTPS (SSL/TLS) for websites. The Certbot is an easy-to-use client that fetches certificates from Let’s Encrypt and configures your web server to use them.

By using Let’s Encrypt Certbot, you can easily acquire and renew SSL certificates for your HomeAssistant. It automates the process of obtaining and installing SSL certificates, thereby saving time and eliminating the risk of manual errors. Moreover, it also handles the renewal of SSL certificates, ensuring that your connection remains secure.

Contrary to what seems to be the case for many, if not most, I find the use of third-party VPN solutions for accessing an otherwise cloud-free HomeAssistant setup to be illogical. Moreover, the notion of implementing the HomeAssistant Cloud service, Nabucasa, doesn’t appeal to me at all. The core of my philosophy is to maintain a smart home solution that is independent of both third-party and cloud services.

Step 1: Installing Let’s Encrypt Certbot

The initial step to enable SSL for your HomeAssistant involves installing Let’s Encrypt’s Certbot. The installation method differs across operating systems. On Linux systems, it’s straightforward to install Certbot using the package manager. For example, Ubuntu users can execute the command sudo apt-get install certbot.

My setup took a slightly different route. As previously mentioned, my HomeAssistant operates within a Docker container, and I also host several websites, including the one hosting this blog post, on a virtual machine. This VM shares the same server as the HomeAssistant Docker container. Installing Certbot on CentOS Stream, the operating system of my VM where SSL is primarily needed, was a breeze by simply following the guided instructions available on the Certbot website.

You can confirm the successful installation of Certbot by executing certbot --version in your terminal. This command should return the version number of Certbot installed on your machine. Should you encounter any issues, indicating that Certbot hasn’t been installed properly, you may need to address the installation process or attempt reinstalling it.

Step 2: Generating an SSL Certificate

With Certbot installed, the subsequent step involves generating an SSL certificate for your domains. In my experience, executing the command certbot --apache was a straightforward process. Certbot intelligently scanned all my Apache virtual hosts, generating certificates for each. Interestingly, it selected the first domain in the list as the root certificate for all others—a decision I wouldn’t have made intentionally, but one I’m content with nonetheless.

Aiming to secure a certificate for HomeAssistant as well, I introduced fake virtual hosts within Apache and initiated certbot --apache once more, this time specifying the addition of the exclusive HomeAssistant domain, which for me is ha.auroranrunner.com.

An alternative method involves the command certbot certonly --standalone. This approach instructs Certbot to secure a certificate by functioning as a temporary web server (standalone) to authenticate domain ownership—useful for situations requiring a more hands-off approach.

However, my objective was for Certbot to manage the certification updates for all domains collectively, thus I adopted a slightly different strategy.

Opting to exclusively focus on HomeAssistant, without intertwining Apache configurations, prompts a straightforward process. You’ll be asked to input your domain name along with your contact details. Upon submission, Certbot seamlessly liaises with the Let’s Encrypt Certificate Authority (CA), generating an SSL certificate for your domain. The newly minted certificate and its private key are securely stored in the directory /etc/letsencrypt/live/your_domain_name/.

Step 3: Setting SSL sync between primary host and secondary host

In my situation, it was necessary to establish a method for synchronizing the SSL certificates between the virtual machine hosting the Apache web servers and the server operating the HomeAssistant Docker container. To accomplish this, I undertook the following steps:

  1. Established passwordless SSH authentication between my Apache hosts and the server hosting HomeAssistant to ensure a seamless connection.
  2. Created a script located at /usr/local/bin/sync_lets_cert designed to facilitate the synchronization of Let’s Encrypt certificates.
  3. Developed a systemd service aimed at automating the daily synchronization of Let’s Encrypt certificates between the two hosts, ensuring that both systems always use the latest SSL certificates.
  4. Configured a dedicated volume for the HomeAssistant Docker container mapped to /etc/letsencrypt:/etc/letsencrypt. This setup allows the HomeAssistant container direct access to the synchronized SSL certificates, simplifying the process of securing communications.

The script located at /usr/local/bin/sync_lets_cert is responsible for synchronizing the SSL certificates between servers. Its contents are as follows:

#!/bin/bash

# Variables
SECONDARY_SERVER="my_vm_host_server"
DOMAIN="ha.auroranrunner.com"
LIVE_PATH="/etc/letsencrypt/live/$DOMAIN"
ARCHIVE_PATH="/etc/letsencrypt/archive/$DOMAIN"
DEST_LIVE_PATH="/etc/letsencrypt/live/$DOMAIN"
DEST_ARCHIVE_PATH="/etc/letsencrypt/archive/$DOMAIN"

# Sync the live directory
rsync -avz -e ssh $LIVE_PATH/ $SECONDARY_SERVER:$DEST_LIVE_PATH

# Sync the archive directory
rsync -avz -e ssh $ARCHIVE_PATH/ $SECONDARY_SERVER:$DEST_ARCHIVE_PATH

This script ensures that the certification files are kept in sync between the hosts. The next step involves setting up a systemd service to schedule this script’s execution, which proved to be slightly more complex but was successfully achieved as follows:

  1. Create a timer file at /etc/systemd/system/sync_lets_cert.timer with the following content to establish a daily execution schedule:
[Unit]
Description=Daily timer for Let's Encrypt certificate sync

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target
  1. Then, create the service file /etc/systemd/system/sync_lets_cert.service to define the synchronization task:
[Unit]
Description=Sync Let's Encrypt Certificates

[Service]
Type=oneshot
ExecStart=/usr/local/bin/sync_lets_cert
  1. Finally, start and enable the service and timer with the following commands:
systemctl start sync_lets_cert.service
systemctl enable sync_lets_cert.timer

With these steps completed, the SSL certificates will not only be renewed every 90 days but also synchronized between servers daily, ensuring seamless security and authentication continuity.

Step 4: Setting up SSL on HomeAssistant

With the SSL certificate secured, the following step is to integrate SSL into your HomeAssistant setup. This process entails adjusting your HomeAssistant’s configuration to recognize and utilize the SSL certificate. Achieve this by appending the below entries into your HomeAssistant’s configuration.yaml file:

http:
  ssl_certificate: /etc/letsencrypt/live/ha.auroranrunner.com/fullchain.pem
  ssl_key: /etc/letsencrypt/live/ha.auroranrunner.com/privkey.pem
  base_url: https://ha.auroranrunner.com:8123

These lines instruct HomeAssistant on the locations of the SSL certificate (fullchain.pem) and its corresponding private key (privkey.pem). Post addition, a restart of your HomeAssistant is required for the adjustments to be applied.

Initially, setting up SSL without specifying base_url sufficed for web browser access. However, to ensure the mobile application functioned correctly, including the base_url became necessary.

Regarding domain registration, I own auroranrunner.com and manage its DNS settings via the AWS console. Given the dynamic nature of my IP address, I employ the dy.fi service to update the DNS record for my dy.fi domain automatically. On AWS Route 53, ha.auroranrunner.com is configured with a CNAME record pointing to sirius.dy.fi, a nifty setup. Thanks to my router’s dy.fi support, any alterations to my external IP are automatically synchronized.

Step 5: Troubleshooting Common SSL Setup Issues

While setting up SSL on HomeAssistant using Let’s Encrypt Certbot is straightforward, you might encounter some issues along the way. One common issue is the “Failed authorization procedure” error. This usually occurs when Certbot is unable to verify domain ownership. To resolve this, you need to ensure that your domain name is correctly pointed to your HomeAssistant’s IP address.

Another common issue is the “SSL connection error”. This usually occurs when HomeAssistant is not correctly configured to use the SSL certificate. To resolve this, you need to ensure that the paths to the SSL certificate and its corresponding private key in your HomeAssistant configuration file are correct.

Setting up SSL on HomeAssistant using Let’s Encrypt Certbot is a good way to secure your system. While the process might seem complex, it can be broken down into five easy steps: installing Certbot, generating an SSL certificate, setting up SSL on HomeAssistant, configuring HomeAssistant with the SSL certificate, and troubleshooting common SSL setup issues. By following these steps, you can secure your HomeAssistant and ensure that your data remains safe and private.

Conclusion

Implementing SSL with Certbot is relatively straightforward for those who are well-acquainted with their network setup. This approach offers a security advantage over depending on third-party VPN solutions, which merely introduce an additional layer to your existing infrastructure. Leveraging third-party services to manage your smart home system does not enhance security; rather, it compromises it. While VPNs can serve as a viable security measure for those lacking the expertise to properly configure their home networks, the assertion that third-party VPNs inherently bolster security is misleading.

For those considering a VPN, I advocate for hosting your own. In my experience, OpenVPN has been fully compatible with HomeAssistant, offering a cost-effective solution without the need for extra expenditures. Like the SSL setup, OpenVPN requires dynamic DNS unless you have the luxury of a static IP address, ensuring reliable and secure remote access to your smart home systems.

Everything you wanted to know about networking but were afraid to ask (Part Three)

Database, Netezza, Networking, , , ,

This blog post is the third part of a series about questions you may have wanted to ask about Netezza networking. The first part concentrated on basic Netezza networking, while the second part continued with network bonding and floating IP addresses. This is the third part, which concentrates on advanced configuration options.

Network speed

By default, a Netezza appliance host has two available Peripheral Component Interconnect (PCI) slots for additional PCI cards. Normally you would use one for a 10 GB dual port Network Interface Adapter (NIC) and the second available slot for dual port 8 GB Host Bus Adapters (HBA). The first you could use for 10 GB networking, and the second could be used for Storage Area Networking (SAN) or LAN-Free backups.

Internally, the appliance uses 10 GB networking. Externally, the default is 1 GB. If you want to have 10 GB external networking, then you need to have the additional 10 GB dual port NIC. Assuming you have a 10 GB network infrastructure in place, you most probably want to go directly to 10 GB.

Even if you plan to initially start with 1 GB external networking, you should consider getting the additional 10 GB NIC and 8 GB Host Bus Adapter (HBA), because you are likely going to use them later.

More about network bonding

By default, the appliance has two hosts. Both of the hosts have one external bonded virtual network device, which consists of two physical 1 GB network interfaces. By default, the network bond is created as active/passive, so the maximum bandwidth you can achieve is 1 GB. If you ask, and your network switch supports link aggregation, you can configure the network bond as Active/Active to get a 2 GB link.

As mentioned above, there are two available PCI slots. This means you can also add two 10 GB dual port NICs to those slots. That way, you can bond up to four 10 GB physical network devices together to achieve maximum 40 GB bandwidth.

Another option would be to use two of the 10 GB ports for virtual IP addresses for application connectivity, and the two remaining ones for a backup network. There are plenty of options, when you consider that you can bond together any of the 10 GB ports in any order to create a bonded device, and then you can choose to go for active/active or active/passive mode.

What about LAN-Free?

This section doesn’t actually cover pure TCP/IP networking, but rather connectivity without TCP/IP. As mentioned earlier, you can have 8 GB HBA installed on one or both of the available PCI slots on the hosts. If you decide to have at least one available PCI slot for additional 8 GB HBA, you could use it for LAN-Free backups.

TCP/IP networking is usually done in shared mode, so you have to share the bandwidth with other users—unless you have a dedicated link, which most often you don’t have. With SAN it is easier and more common to create a dedicated link between the appliance and, for example, the backup server. Or you can connect to an external SAN disk through a dedicated link. That of course has clear benefits; when you know exactly how much bandwidth there is and when you don’t need to share it with anyone.

Another benefit with the LAN-Free option is is the CPU usage. TCP/IP implementations tend to have more CPU overhead compared to SAN. I would emphasize the benefit of the dedicated link though, since CPU on the host is rarely limited while dealing with backups, for instance.

Management interfaces

I already mentioned the management IP addresses: usually two per host, one being the host IP itself, and the other being the IP address of the integrated management module (IMM).

The IMM IP addresses are extremely handy if the host itself is not reachable through the host IP due to the fact it has failed with a hardware error, or if there is something wrong with the configuration. Through IMM, you get console access though the web interface, and either debug the problem or fix the configuration issue.

Some clients require a separate management IP, which is not attached to any network devices used by applications and which still has direct TCP/IP connectivity to the host. In this case neither the host IP nor the IMM IP can be used; you need to use some other available physical network port or interface. If this is the case, you should clearly define the requirements, so you can check the available options.

What else?

If anything else is on your mind that you did not dare to ask earlier, feel free to ask or comment below. You can also follow me on Twitter @TVaattanen to discuss more about Netezza.

Everything you wanted to know about Netezza networking but were afraid to ask (Part Two)

Database, Netezza, Networking, , , ,

This blog post is the second in a three-part series with the goal of answering questions you might have about Netezza networking. The first part concentrates on basic Netezza networking, whereas this second part covers more advanced networking concepts. For advanced configuration options, you can check out the upcoming third part of this blog post.

Network bonding

You have two hosts: active and passive. Each has its own IP address. These IP addresses are not floating. These are called host IPs. Since you want to have maximum redundancy on all components, there are actually two physical network devices virtually bound together to create virtual networking devices (one for each host). Both hosts have two physical network devices that carry one IP address. This is called network bonding.

Let’s say both of the hosts have network devices eth6 and eth7 and they create a coupled virtual device called bond2. We usually use bond0 and bond1 internally, so the first bonded device for external use is normally bond2.

For the virtual device bond2, you can assign an IP address and connect to a host. Both active and passive hosts will have this device and both of the hosts will have their own individual IP address, which is bound to this virtual device.

Virtual IP

If you think of this from an applications point of view, it wouldn’t make sense to connect to the host IP, since if the active host fails, you would need to re-configure applications to use the new active host, which has a different IP.

That’s why applications use virtual IP. Virtual IP is actually an IP alias, which is bound to an active host. Hosts run standard Linux operating systems, so if you are familiar with Linux, it’s easy to explain. If not, it’s still not rocket science. On Linux, you can easily add IP aliases on top of any physical, or virtual for that matter, network device . If you have physical network device eth0 with fictional IP address 192.168.1.100, you can add another IP address to that same physical device just by assigning an IP to device eth0:0. Next you add to device eth0:1 and so on.

In this case, you have virtual network device bond2, which is a bonded device having physical devices eth6 and eth7 behind it. If you lose eth6, you are still good as long as physical device eth7 is good. To connect to either of the hosts directly, you would use the IP address assigned to bond2 on the particular host, or rather the host name you have assigned in your domain name server (DNS) for that IP address.

Floating IP

As I said, applications connect to a virtual IP. The virtual IP is assigned to virtual network device bond2:0. It only exists on an active host. This is something called a floating IP, and it is always on the active host. If Host 1 fails, it will be on Host 2. If, as in my example, device eth6 fails, you have bonded device bond2, which consists of eth6 and eth7, the floating IP is still good on that same appliance as before.

There are two virtualization layers here. One is done though network bonding, the other is done through cluster software. If one of the network devices physically breaks, the network bonding will do the trick, and you are still good to go. If the other appliance breaks, you have clustering software, which can deactivate the bond2:0 on the failing host and create bond2:0 on new active host.

So the bond2:0 always has the virtual IP your applications are able to use. You should, of course, always assign host names in your DNS for this virtual IP, and use this host name in your applications instead of using IP addresses directly. That way, if you ever need to change the IP address for the virtual IP, you don’t need to change configurations for several applications. Instead, you just have to change the IP for the host name you have defined for the virtual IP in your DNS configuration.

What about changes to the default configuration?

I will cover advanced configuration options in part three of this blog post. If you have any network-related questions or suggestions, please add them below in the comments. You can also follow me on Twitter @TVaattanen to discuss more about Netezza.

Everything you wanted to know about Netezza networking but were afraid to ask (Part One)

Database, Netezza, Networking, , ,

This blog post is the first of three parts informing you about everything you always wanted to know Netezza networking but were afraid to ask.

Simplicity

PureData System for Analytics is a simple appliance for serious analytics. There is minimal tuning involved and it can be up and running in hours with minimal administration. Since it is so simple, you might be afraid to ask questions such as the following:

  • How would my applications connect to the appliance?
  • How am I going to manage the appliance?
  • What is the network bandwidth?

The answer to all of the above questions is that you can do it through a standard TCP/IP networking interface. Well, how do you network with PureData System for Analytics, then?

Connectivity

It’s simple because it’s an appliance. It has basically one IP address, or host name, that your applications use to connect. To manage the appliance, you can use the same IP address or host name for sure, but let’s be a bit more exact.

The PureData System for Analytics appliance has five external IP addresses and six ethernet drops by default.

The appliance consists of two hosts and several S-Blades or Snippet Processing Units (SPUs). One of the hosts is active and the other is passive. You always connect to the appliance through the active host. On the application level, you never connect through any other component. To connect to the active host you use something called a virtual IP or the Open Database Connectivity (ODBC) host name. That IP or host name is for applications. It is a floating virtual IP address which is always on an active host.

You should always make sure there is a host name assigned to the virtual IP in your name server so that applications can connect through a Fully Qualified Domain Name (FQDN) instead of an IP address.

Management IPs

To manage the appliance, you can connect directly by using the IP addresses assigned to both hosts, which are called the host IPs. These IPs are assigned to virtual network device bond2 by default, which is created from two physical network devices for redundancy. That would be a normal situation.

You have other options as well. With an integrated management module (IMM) that has an IP address, you can connect and get console access through the network instead of needing to be physically near the appliance.

In summary

There are two physical network devices on both hosts, which creates a virtual network device bond2 by default and one physical network device on IMM on both hosts. That makes six ethernet drops.

There are five IP addresses: One IP address for applications, one IP for both of the two hosts and one IP address for IMM on both of the hosts. Here’s a little more detail:

  • One VIP and ODBC host name: You should define the host name in your name server for VIP. That way, applications are able to use a floating IP through the ODBC host name to connect to the appliance. This IP is assigned to active hosts automatically.
  • Two Host IPs: These are by default assigned to virtual device network bond2 on both hosts. If you want to connect to host 2, you use the IP address assigned to device bond2 on host 2.
  • Two IMM IPs: Both hosts have an integrated management module, you can use them to get direct console access through the network.

The rest of the networking

I will cover more advanced networking topics in part two and three of this blog post series. If you have PureData System for Analytics networking related questions in mind you did not dare to ask earlier, please do it below by commenting on this post. You can also follow me on Twitter @TVaattanen to discuss more about Netezza