Forem: Steven Cooney

Setting up Pi-hole on Ubuntu Mac Mini

Steven Cooney — Fri, 05 Feb 2021 20:26:14 +0000

I've wanted to set up a Pi-hole on my home network for a while but never found the time. Similarly, my old Mac mini has been laying around for a few years now, and I have meant to make use of it. After the recent announcement that MacOS Big Sur will not be compatible with my 2012 Mac mini, I have decided to turn my mini into an Ubuntu server and install PiHole.

Hardware

As touched upon already, I re-purposed an old 2012 Mac Mini. The Mac has an i5-3210M processor, 8GB of RAM and a 500GB hard disk. Using a Mac mini that is a small form-factor allowed me to position it nicely underneath my router.

Install & Configure Ubuntu Server

The first step was to grab Ubuntu server and follow the installation instructions from the official website. I used a USB stick as the installation media. To boot from the USB, hold down the ⌘ Command key when powering on the Mac to open up the boot menu.

NOTE: During the install when specifying the disk to format the full disk was not selected by default. Therefore I had to expand the default size to utilise the whole disk.

Update the System

After the initial installation, I updated everything before continuing any further.

apt update && apt upgrade -y

Install Postfix for Email

To keep the server up to date unattended-upgrades are used. Reports from unattended-upgrades get emailed using Postfix.

To install Postfix and initial config I ran the following:

apt install postfix mailutils
cp /usr/share/postfix/main.cf.debian /etc/postfix/main.cf

I used SendGrid as a relay host and followed their documentation for configuring Postfix. Below was the configuration I added to /etc/postfix/main.cf.

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_tls_security_level = encrypt
header_size_limit = 4096000
relayhost = [smtp.sendgrid.net]:587

To authenticate against Sendgrid using an API key, I created /etc/postfix/sasl_passwd to store the API key.

[smtp.sendgrid.net]:587 apikey:<yourSendGridApiKey>

Ensure the password file had the correct ownership and before restarting postfix.

chmod 600 /etc/postfix/sasl_passwd
postmap /etc/postfix/sasl_passwd
systemctl restart postfix

Test Postfix by sending an email:

echo "Just testing postfix" | mail -s "[Test Email]" test@example.com

Unattended Upgrades

As mentioned before, to ensure the Ubuntu Server is always patched, I configured unattended-upgrades which installs updates without manual interaction.

Install unattended-upgrades:

apt-get install unattended-upgrades apt-listchanges

Frequency Configuration

The frequency of updates I used was based upon this setup which was suitable for my needs.
Within /etc/apt/apt.conf.d/20auto-upgrades I set the following:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::Unattended-Upgrade "3";
APT::Periodic::AutocleanInterval "9";

APT::Periodic::Update-Package-Lists "1";
- I update the package lists daily. This is important because unattended-upgrades can fail if the sources are outdated.
APT::Periodic::Download-Upgradeable-Packages "1"
- I also download the updates daily too rather than downloading them all in one go.
APT::Periodic::Unattended-Upgrade "3";
- Perform the installation every three days.
APT::Periodic::AutocleanInterval "9"
- Clean the package cache every nine days.

unattended-upgrades Configuration

In the unattended-upgrades configuration file, I set the Unattended-Upgrade::Mail property to my email address.

I also set automatic reboot and the time to reboot too:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Install & Setup PiHole

The inspiration for setting up Pi-Hole came from reading a blog post by Scott Helme, where he outlined the steps he undertook. Alongside, setting up Pi-Hole to filter out advertisements on my home network, I also set up DNS over HTTPS (DoH). DoH facilitates the secure transmission of DNS.

Installing Cloudflared

Cloudflared is used as a proxy to enable DNS over HTTPS. Pi-Hole has good documentation for installing Cloudflared. I installed cloudflared the "automatic" way outlined in the link above, below are the steps I undertook.

Install Cloudflared:

wget https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-amd64.deb
apt-get install ./cloudflared-stable-linux-amd64.deb
cloudflared -v

To configure cloudflared, I used a config file to specify the upstream DNS location DoH requests should be routed.

mkdir /etc/cloudflared/
vi /etc/cloudflared/config.yml

config.yml file content points to CloudFlare's DNS servers.

proxy-dns: true
proxy-dns-port: 5053
proxy-dns-upstream:
  - https://1.1.1.1/dns-query
  - https://1.0.0.1/dns-query
#Uncomment following if you want to also want to use IPv6 for external DOH lookups
  #- https://[2606:4700:4700::1111]/dns-query
  #- https://[2606:4700:4700::1001]/dns-query

NOTE: The DNS proxy port is needed later on.

Once the config was in place, I installed cloudflared as a service:

cloudflared service install --legacy
systemctl start cloudflared
systemctl status cloudflared

To test DNS routed via cloudflared works you can run dig:

dig @127.0.0.1 -p 5053 google.com

Installing and configuring the Pi-Hole

Installing Pi-Hole was trivial, I just ran the following command and proceeded through the install instructions:

NOTE: It did not matter the default DNS configuration I choose since I override the setting after installation.

curl -sSL https://install.pi-hole.net | bash

After the installation was complete, I updated a couple of configuration files to ensure Pi-Hole was routing DNS through the cloudflared service.

Within /etc/pihole/setupVars.conf remove the values for PIHOLE_DNS_1 and PIHOLE_DNS_2. This stops Pi-hole from using the DNS configuration chosen when setting up Pi-hole.

...
PIHOLE_DNS_1=
PIHOLE_DNS_2=
...

I also created an additional configuration file for dnsmasq to route DNS through the cloudflared service.

NOTE: The port (after #) should match the DoH proxy port configured in cloudflared

Create /etc/dnsmasq.d/cloudflared-dns.conf:

server=127.0.0.1#5053

I then restarted the pihole-FTL service to use the updated config.

systemctl restart pihole-FTL
systemctl status pihole-FTL

Configuring devices to use Pi-Hole

To enable all of my devices to utilise Pi-Hole, I chose to set the network DNS servers on my router so, all devices will be routed through Pi-Hole and DoH by default.

A few resources that I used during my setup that may also be of use:

Have you installed and configured Pi-Hole? Do you have any feedback? Reach out and let's discuss.

Git Setup for OpenSource/Public Development

Steven Cooney — Sat, 23 Jan 2021 15:13:41 +0000

If you intend to develop in the public domain on opensource projects, you will need to set up Git. I'm going to outline my git configuration and discuss my approach.

Email Address

When setting up Git, one of the first things you set up is your email address. Often not much thought is given to this step, however, if you use your private email address you are advertising your email address. Consequently, your email address could become subject to spam by a malicious actor who scrapes email address from git history.

For example, below is a screenshot of Wes Bos' awesome-uses repository. You can see several of the contributors have exposed their email addresses when committing to the project.

My Configuration

I use the no-reply address for my GitHub account as my git email. On GitHub, you can find your no-reply email address in Settings > Emails > under "Keep my email addresses private".

You can then set your git email using this address:

git config --global user.email "30004860+TheYorkshireDev@users.noreply.github.com"

To avoid my email address from being exposed when performing actions through GitHub UI such as edits or merges, I check "Keep my email addresses private".

Finally, I check "Block command line pushes that expose my email" which blocks pushes with commits that include personal email addresses.

Username

When setting up Git, alongside email, you need to set your name. I would recommend using your first and surname for this option, which most people will probably do automatically. It is worth noting if you are thinking of using a pseudonym in Git, it can violate some open source projects contribution guidelines. One such example is the Docker project, so to err on the side of caution, it might be worth sticking to your real name.

Commit Signing

The final thing I have configured for open source development is commit signing. I'm not going to go over the advantages and disadvantages of commit signing in this post, for more details check out this StackExchange post and sub-links. Not everyone agrees on an approach to commit signing, but I tend to sign all my commits.

Generate GPG Key

NOTE: Use the no-reply email address when generating a GPG key.

I recommend following GitHub's official guide for generating GPG keys.

Add a GPG key to your GitHub Account

You will need to have noted down your public key to upload to GitHub. If you didn't, run the following to retrieve it:

gpg --armor --export <EMAIL_ADDRESS>

Again, I recommend following GitHub's official guide for adding a GPG key to your GitHub account.

Configure Local Environment

The following commands configure Git to always sign commits with the GPG key you have just generated.

NOTE: You want the GPG key id you have just generated, run gpg --list-secret-keys --keyid-format LONG to find it again if you didn't note it down.

git config --global user.signingKey <REPLACE\_THIS\_WITH\_YOUR\_KEY\_ID>

git config --global commit.gpgSign true

To verify commit signing is configured, run the following:

echo "test" | gpg --clearsign

What's your Git configuration? Do you have any feedback? Reach out and let's discuss.

Azure Service Principals 101

Steven Cooney — Tue, 12 Jan 2021 22:31:53 +0000

I was recently talking to a colleague who was starting with Azure for the first time, we were discussing authentication methods, especially when using external tools. When interacting with Azure programmatically, you soon stumble across service principals, however, for someone new to Azure what are Service Principals and some of the useful commands used to manage them?

NOTE: for the snippets below, I am assuming that you have a single Azure Tenant and it has the default name of "Default Directory".

What is a Service Principal?

Azure uses Active Directory (AD) to manage users and other access to Azure services and resources. When a user logs onto Azure, they have a User identity object within AD that has associated permissions and roles dictating their access within Azure.

Often there are requirements to have programmatic access to Azure resources and services. One example may be automated tools within CI/CD to deploy an application or access Azure services. Rather than creating a "dummy/fake" user identity within AD, we create a Service Principal.

Service Principals can have their permission scoped to only interact with a particular set of resources or services. Furthermore, roles outline the actions that the service principal can perform on the resources or services.

List Service Principals

There are tons of built-in Service Principals (SPs) within Azure such as SPs for Office 365 whether you use it or not. To find SPs that you've created, it's best filtering out to only include those within your Azure Tenant.

az ad sp list --filter "publisherName eq 'Default Directory'"

Create a Service Principal

When creating a service principal, you should specify a name for easier management in the future. You should also only give it the minimum roles and scopes required to undertake the desired action.

NOTE: service principals have a default expiry of 1 year from creation. You can specify how many years before expiry by providing the --years property.

az ad sp create-for-rbac -n "MyAwesomeApp" --role Reader --scopes /subscriptions/{SubID}/resourceGroups/{ResourceGroup1} /subscriptions/{SubID}/resourceGroups/{ResourceGroup2}

For all parameters, you can refer to the documentation for az ad sp create-for-rbac.

Find Expired Service Principals

There is a quota limit on Service Principals within an Azure Tenant not to mention it's probably good hygiene to clean up after yourself. So we sometimes want to find expired Service Principals to either delete or renew them.

Below is a Powershell command to list all Service Principals that have expired. We first get a list of all Service Principals within our Tenant then loop over them checking the expiry date, only outputting those that have expired.

NOTE: unlike other commands in this post this is a Powershell command, not Azure CLI, so if you are running Az CLI outside of Powershell you may want to use Azure's Cloud Shell to undertake this action.

$spns = az ad sp list --filter "publisherName eq 'Default Directory'" | ConvertFrom-Json | Select appId, displayName | Sort-Object -Property displayName
foreach ($spn in $spns) {
    az ad sp credential list --id $spn.appId | ConvertFrom-Json | Where-Object endDate -lt $(Get-Date) | Select @{Name="displayName";expression={$spn.displayName}}, keyId, startDate, endDate
}

Renew/Update a Service Principal

When Service Principals expire, they need to be renewed. Likewise, if the Service Principal secret is exposed, it must be regenerated. The command below resets the service principal generating a new secret key and expiry.

NOTE: service principals have a default expiry of 1 year from creation. You can specify how many years before expiry by providing the --years property.

az ad sp credential reset --name "MyAwesomeApp"

For all parameters, you can refer to the documentation for az ad sp credential reset.

Delete a Service Principal

Once you have no use for a Service Principal, you should delete it removing access to Azure. Although I haven't touched upon it much in this post, it is possible to have multiple credentials assigned to a Service Principal. Multiple credentials are useful when you have more than one Azure Tenant.

Below is a command to delete a Service Principal, all credentials, roles and scopes.

NOTE: --id can take the Service Principal ID or name

az ad sp delete --id "MyAwesomeApp"

For all parameters, you can refer to the documentation for az ad sp delete or deleting a single credential on a Service Principal az ad sp credential delete.

If you enjoyed this article, share it with your friends and colleagues!

Website & Blog Stack

Steven Cooney — Sat, 05 Dec 2020 15:47:44 +0000

Here we go, my first blog post after recently adding blog functionality to my website TheYorkshire.Dev. I'm going to go over why I redesigned my website, what I'm using, and some enhancements I want to add.

Old Stack & Setup

My previous website was built in 2013 and was orange and grey. A refresh was long overdue. I created it primarily to assist in getting a placement year during my degree. It was pretty basic, built from HTML & CSS then deployed using FTP manually which was laborious, both modifying code and deploying.

I hosted the website on a $5 a month Digital Ocean droplet upon which I had installed the LAMP stack. Having a virtual private server seemed like a good idea at the time, but it soon became a burden. If I'm honest, I lost care and didn't update the VPS as regularly as I should have so decided it was time to lift and shift the website to a friendlier platform.

I moved the website over to Azure and utilised App Service. Azure App Service is a Platform as a Service (PaaS) offering, allowing managed hosting of applications for a variety of technologies. In addition to switching how I hosted the website, I also set up CI/CD with Azure DevOps (still a stupid name) for deploying the website easily whenever it is updated.

Inspiration

In all honesty, I have been working on and off at building this site for over a year. The first cut has been published for many months now although I've only just finished adding blog capability hence this post.

Due to work commitments, it took me much longer than I wanted. The last nine months have been chaos with the pandemic as we are involved in the national NHS covid effort, so at the end of the day, I just wanted to log off my PC, kick back and relax.

Last year, I was fortunate to see a couple of talks from Phil Hawksworth who works at Netlify and is a big advocate for JAMStack. I liked what I saw and decided that I should refresh my website. I also had a few other motives;

I had some TheYorkshireDev logos a friend designed for me a few years back I wanted to incorporate on my website
I needed to get rid of the orange and grey and use a constant, clean colour scheme that links with my logos
I had a new domain to use
I wanted to try my hand at blogging needed a new solution
I wanted it to be a PWA, so if someone enjoys my blogging they could install the site as an app, potentially receiving notifications for blog posts (Still a TODO)

Current Stack & Setup

Development

I was inspired for the refresh by seeing JAMStack websites that didn't depend on webservers and could be statically generated. Since this was my first foray into static site generators, I did some googling to get up to speed. I found a nice tutorial GatsbyJS tutorial that covered elements I wanted to incorporate in my shiny new site.

Gatsby allowed me to use ReactJS and build the site with components. Using components avoids duplicating code which was one of the issues with my previous website. I styled the website using styled-components and Emotion, allowing me to scope my CSS, which I find much easier to manage.

The extensive plugin ecosystem came in use for adding functionality to the website. For example, allowing me to write blog posts in Markdown and transforming them to HTML, to be embedded during a build with a little help from GraphQL. I also used plugins to assist in optimising images, improving SEO and adding PWA functionality.

CI/CD & Hosting

The source code for the website is publically available on GitHub in a repository. I had planned to have the website and blog posts in separate repositories but have decided to keep them together for now (see planned enhancements).

I have continued to use Azure DevOps for building and deploying the website. New commits on the website trigger a build within Azure DevOps and then subsequently deploys the code. Commits on the master branch deploy the code to production whereas commits on other branches deploy to a staging location.

I am hosting my website on Netlify. I was going to continue using Azure, however, setting up custom domain without a subdomain isn't possible. Netlify also provides free HTTPS certificates backed by let's encrypt, which is something I would have had to set up and configure within Azure. For the staging environment, I am using Azure blob storage fronted by a CDN for verifying website changes.

Planned Enhancements

There are a few additions I'd like to make to the website in future.

Pull blog posts into a second repository
Blog post comments
Blog Pagination
Blog PWA Notifications
Ability to subscribe to the blog
Switch CI/CD to GitHub Workflows
Configure the website to use CSP and other HTTP headers
Update staging site to use either Netlify or Azure Static Web Apps

What's your tech stack? Do you have any feedback? Reach out and let's discuss.

If you enjoyed this article, share it with your friends and colleagues!