In How I built a homelab with Red Hat Enterprise Linux (RHEL), I laid out my plans for revamping my home lab using as many Red Hat Enterprise Linux (RHEL) and Red Hat-adjacent tools as I could get my hands on.

My goals are:

• Learn the processes.
• Teach others some systems administration good practices.
• Automate my homelab as much as possible.

The first article covered my goals and the process for building a new “non-production” RHEL 9 virtual machine to act as a jump server and collection point for different configuration files, scripts, and the like.

I built a basic server and added only a few tools, such as the web console and Image Builder. In this article, I will focus on building a customized template that:

1. I can deploy repeatedly.
2. I can automate its upkeep.

What is Image Builder?

The short version is that Image Builder is the intended future installation experience for RHEL. Image Builder is not a product but a feature within the distribution.

With Image Builder, administrators can deploy different RHEL versions on different platforms (hardware, virtual, cloud) with different configurations. There are three ways to interact with Image Builder:

• A web service through the Red Hat Console
• A web-UI-based tool
• A command line-based tool

Build the first image

A vanilla image should be enough to get started. This image undoubtedly will be one of many I create throughout this project. I’m starting with the web console (Cockpit) Image Builder application to get the ball rolling. The URL to connect to it is: https://{hostname}:9090/composer.

If you don’t have Image Builder installed yet, you can install it with DNF:

# dnf install -y cockpit-composer.noarch

Then enable the socket to start automatically:

# systemctl enable --now osbuild-composer.socket

Now you can access Image Builder using the web console:

Use the Create blueprint wizard to define what the initial image should look like. Start by giving the image a helpful name and description:

The next step is to decide what output format the image should be. Since my bare-metal server will be a hypervisor for my rebuilt lab, a QEMU-based qcow2 image makes the most sense; your environment may dictate differently.

The first step in the wizard also asks what the Image Size should be. The default and minimum are 2GB. For now, this should be fine.

I’ll move on to customizations. The next screen shows the option to pick a hostname. I will leave this blank and assign a hostname later when I deploy these images.

Next, define a user. I will create a service account named ansible so that I can easily deploy system roles across a small test environment (as I’ll do in the next article in this series).

Don’t forget to assign a password and create an SSH key. Adding a key here provides everything needed to use the ansible account across the fleet. Also, check the Server administrator box to add the ansible account to the wheel group.

Next, I’ll add a few packages I want across my fleet. Again, your choices here may vary. I’ve only added a couple for now, such as tmux and vim-enhanced.

Finally, review the configuration and save the blueprint.

Create an image

You just created a blueprint for a RHEL 9 virtual machine (VM). Think of this as a recipe for a meal you will prepare. It’s time to try it.

Either from the wizard you just walked through or from the main page of the Image Builder app, select Create image to begin the build process.

In the background, Image Builder pulls all the relevant packages from the Red Hat Content Delivery Network (CDN), defines the filesystem layout, and builds the boot image.

Depending on your hardware and internet connection, this process takes a few minutes. But when the image is complete, you won’t immediately have to go in and update all your packages.

Once the image finishes, you can use the qcow2 artifact to build the first test client machine. The easiest way is to use your browser’s Download functionality to grab the qcow2 file and upload it to your test environment.

However, I want to make additional changes to my image before deploying it.

Add features to the vanilla image

I want to ensure I have a well-defined image before deploying it repeatedly. To do this, I will switch tools.

The local, web-based Image Builder tends to be the slowest to get new features due to its ties to the RHEL release development process. It currently lacks a built-in mechanism for updating templates regularly. Remember, the goal for this lab is to operate as hands-off as possible.

I’ll use SSH to connect to the jump server for this step. I don’t plan on this jump server living a long life, so I don’t have to worry about creating a user account or importing any of the preferences. This approach is not advisable for production or long-lived servers, but I’ll fix this later with the golden image.

I pulled some knowledge from a couple of different tools for this next part:

• A self-paced lab
• The Composer documentation

(In this industry, it is often not what you know, but whether you know how and where to find the knowledge you need.)

Next, install the tools:

# composer-cli blueprints list
rhel-base

# composer-cli blueprints save rhel-base

# vim rhel-base.toml

name = "rhel-base"
description = "Vanilla RHEL 9.x"
version = "0.0.2"
modules = []
groups = []
distro = ""

[[packages]]
name = "tmux"
version = "*"

[[packages]]
name = "vim-enhanced"
version = "*"

[customizations]

[[customizations.user]]
name = "ansible"
description = "Ansible Service Account"
password = " <redacted> "
key = " <redacted> "
groups = ["wheel"]

Make a few additions:

name = "rhel-base"
description = "Vanilla RHEL 9.x"
version = "0.0.2"
modules = []
groups = []
distro = ""

[[packages]]
name = "tmux"
version = "*"

[[packages]]
name = "vim-enhanced"
version = "*"

[[packages]]
name = "cockpit"
version = "*"

[customizations]

[[customizations.filesystem]]
mountpoint = "/var/log"
size = "4 GiB"

[customizations.services]
enabled = ["cockpit"]

[[customizations.user]]
name = "ansible"
description = "Ansible Service Account"
password =  <redacted> "
key = " <redacted> "
groups = ["wheel"]

I added stanzas for Cockpit (the web console) and an enabled services section to ensure the web console starts on boot.

You can add a 4GB filesystem for /var/log. (You can always add more later.)

Finally, add a user description for the Ansible service account. You can also check the documentation for additional customization ideas.

For now, though, import the modified blueprint and execute a build:

# composer-cli blueprints push rhel-base.toml

# composer-cli compose start rhel-base qcow2
Compose bb259a2e-cbd6-4fe9-99bf-3a9b28e2cbcf added to the queue

You can keep an eye on the build by running the status command:

# composer-cli compose status
bb259a2e-cbd6-4fe9-99bf-3a9b28e2cbcf RUNNING  Mon Feb 20 15:50:14 2023 rhel-base   	0.0.3 qcow2       	
209cfd00-a57b-4458-8de0-df0942e2cc65 FINISHED Mon Feb 20 15:05:26 2023 rhel-base   	0.0.1 qcow2        	2147483648

Once done, the build will show a FINISHED status like when the job kicked off from the web console earlier. I’ll hold onto the finished qcow2 image for the next article.

Automate future builds

Now I have a good image I can duplicate to build and test what will eventually become my golden image. This planned image will have as many of the latest updates as possible, the preferred packages, user data, and filesystems.

From there, I’ll be able to add more layers of packages and configurations to the base image to build out the different services I’ll be hosting in the lab.

However, I don’t want to worry about creating a new image manually. As the tool evolves, there will be better options for this, but for today, I plan on using systemd timer to build an updated image on a scheduled basis.

I’m adding a systemd timer to trigger a rebuild every Sunday night. (Did you know about creating your own systemd timers? I didn’t! I found the article Use systemd timers instead of cronjobs during my research!)

First, you need to create a systemd service to call the composer command:

# vim /etc/systemd/system/composerBuild.service

	[Unit]
	Description=Rebuilds a vanilla RHEL template through image builder
	Wants=composerBuild.timer

	[Service]
	Type=oneshot
	ExecStart=/bin/composer-cli compose start rhel-base qcow2

	[Install]
	WantedBy=multi-user.target

Second, create a systemd timer to call the service:

# vim /etc/systemd/system/composerBuild.timer

	[Unit]
	Description=Timer to rebuild vanilla RHEL template using image builder
	Requires=composerBuild.service

	[Timer]
	Unit=composerBuild.service
	OnCalendar=Sun

	[Install]
	WantedBy=timers.target

# systemctl enable composerBuild.timer

As a paranoid sysadmin, I want to verify that the timer is working:

# systemctl status *timer

… output truncated …

● composerBuild.timer - Timer to rebuild vanilla RHEL template using image builder
 	Loaded: loaded (/etc/systemd/system/composerBuild.timer; enabled; vendor preset: disabled)
 	Active: active (waiting) since Thu 2023-02-23 12:04:13 CST; 2min 14s ago
  	Until: Thu 2023-02-23 12:04:13 CST; 2min 14s ago
	Trigger: Sun 2023-02-26 00:00:00 CST; 2 days left
   Triggers: ● composerBuild.service

Keep in mind this is a “quick-and-dirty” approach. As I add tools like Ansible Automation Platform and Red Hat Satellite, I’ll have better options for automating the process of providing up-to-date templates to deploy.

Wrap up

I covered a lot of ground in this article. I am enjoying the process and looking forward to seeing what the lab looks like on the other side of this series!

Here, I talked about the ideas of a golden image and took steps toward building the first couple of client systems that I’ll use in the next article.

Next time, I will take the test systems and add RHEL system roles to the golden image. System roles are a codified method of configuring Linux subsystems such as firewalls and SSH using ansible-core and deploying these configurations at scale.

If you follow this series, I would love to connect with you. You can easily find me online.

This article originally appeared on the Enable SysAdmin blog.

As a recovering sysadmin, the last thing I want is to end up being technical support at home. I often tell people that I wish I had the tools available in Red Hat Enterprise Linux (RHEL) now when I was a fresh Linux sysadmin.

So I’ve set a challenge for myself: to implement some of the best practices in our industry using only Red Hat or Red Hat “adjacent” tools, whether upstream or partner software.

My goals here are simple: I want to build out a homelab that:

• Allows me to spin up virtual machines (VMs) in an unattended fashion
• Provides demo-ready RHEL systems for topics I cover regularly (for example, in-place upgrades, Image Builder, and more)
• Is capable of self-healing my home “production” services (including Plex, Valheim, and Home Assistant)

I hope this series will help you either with your homelabs or think differently about how you administer your employer’s infrastructure.

My old homelab setup

Currently, I have a single-node server running RHEL 9.1. Eventually, I need to rebuild this server from scratch. It’s packed with several TB of storage, 24 cores, and 128GB of RAM.

I have several RHEL virtual machines that I set up for demos I do at conferences, webinars, and live streams. These include a Convert2RHEL demo, in-place upgrades, and a sandbox system. I also have several Podman pods running that constitute my “production” services: Home Assistant, WordPress, Minecraft, and others.

I make copies of the qcow2 files for my VMs. My container pods are running as root. I have no offsite backups. The ol’ sysadmin inside me screams when I think about how inefficient this is.

Building my new homelab

Now, I’ve got some objectives; I have a plan (sort of). It is time to get started.

My existing server host needs to remain in place until I’m confident I can rebuild the services (and their applicable data) in an automated fashion. This bodes well for the project because I can build out the “next generation” of servers in isolation before introducing it into production.

In all the environments I worked in, I tended to build a jump or utility server to store all my tools and act as a single point to administer the rest of my environment. That is where I am going to start.

Since this utility server will be temporary, I want the quickest route to the live system. For me, that’s using the web console (the downstream of Cockpit) with the VM tool and a RHEL 9.1 ISO.

I’ll select Create VM. Luckily, the web console makes it incredibly easy to spin up a new VM: Fill out a few fields and wait.

What’s with the hostname, itg-stg-jump? Well, old habits die hard. Back in the day, I worked for a company that had servers in multiple datacenters. So the first stanza (itg) is the location. In this case, my homelab: the IT Guy. The second stanza (stg) is the environment, in this case Stage. Finally, the last stanza (jump) is the application it is running.

If you are wondering, yes, I took all the defaults and the simplest configuration possible. There is no fancy filesystem layout or security profile. I will add all that to later iterations of my golden image.

While the system is booting up, I am going to go ahead and mark this VM to start on boot.

Bingo, I have a jump server ready for use. I am going to go ahead and install any available updates, install Git and Vim, and enable the web console.

# sudo dnf clean all && sudo dnf update -y
# sudo dnf autoremove -y
# sudo dnf install -y cockpit cockpit-composer

Then enable the web console and reboot.

# sudo systemctl enable --now cockpit.socket
# sudo reboot

Wrap up

I hope this article becomes a series of posts (and maybe some live coding events). In the next edition, I will revisit our utility server and build the first Image Builder blueprint. That will be the basis of all the other images and servers I will use in future posts.

This article was originally published on the Enable SysAdmin blog.

For a systems administrator, it seems like every project brings new complexity, more servers, and more sprawl to manage. I will assume that your messes are a lot like mine: On one server, you’re running CentOS Linux 7 from a project several years ago. Over here, you have a handful of Red Hat Enterprise Linux (RHEL) 9 servers from a recent project. Over there, you have an Oracle RAC database running on Oracle Linux 8.

No matter where you look, you have a mix of different distributions on different major and minor versions. What is a hard-working sysadmin to do? Never fear; the IT Guy is here, and as Terry Bowling and I did in our 2022 Red Hat Summit talk, I will walk you through a couple of tools to help you bring some order to the chaos in your infrastructure.

Why I standardized on Red Hat Enterprise Linux

In all my years as a sysadmin, I’ve never had a better experience managing a Linux operating system than with RHEL. I know what you are thinking: “This guy works for Red Hat; of course, he would say that operating system is the best.” Rest assured, my love for RHEL long predates ever receiving a paycheck with a red fedora.

One reason is that RHEL is open source, which is critical to the development and sustainability of the entire Linux ecosystem and, to a real extent, the world of technology we enjoy. For another reason, Red Hat has always been a vendor I love talking to, in contrast to the ones I wanted to get out of the door as quickly as possible because all they cared about was the upsell.

If I were to start a business, manage a large bank, or control a space station, I would put RHEL at the heart of it. The main reasons are security certifications, an unmatched partner ecosystem, and a suite of management tools built right into the subscription in the form of Red Hat Insights.

I could talk about how much I love RHEL all day, but I’ll move along. Assume I have convinced you that RHEL is the way to go, so how do you standardize on it without rebuilding hundreds or even thousands of servers?

That is where the Convert2RHEL tool comes into play. Convert2RHEL is a supported utility that replaces existing packages with Red Hat-signed versions. So you can replace your CentOS Linux kernel with the RHEL kernel and a third-party MariaDB version with the Red Hat version. You get the idea. Modern systems can have anywhere from 500 to 1,000 or more packages, and the Convert2RHEL tool handles the conversion process. It also ties the converted system into your Red Hat Access account, allowing you to install packages, get support, and connect to tools like Insights and Red Hat Satellite.

I mentioned a crucial term in the paragraph above: supported. Convert2RHEL is a supported operation. If you run into issues, you can open a support ticket or even talk to Red Hat Consulting to get advice and build a plan for a standardized platform. Need to carry out a bulk conversion? You can automate the process with Satellite.

Get started with Convert2RHEL

To get started with Convert2RHEL, you can follow the commands and screenshots in this article or watch the complete process in this video:

I will walk through this process with a vanilla CentOS Linux 7 virtual machine (VM). To make life easier, before you do anything, ensure all your packages are up to date:

$ sudo dnf update -y

With that done, run three curl commands to pull down the GNU Privacy Guard (GPG) key, SSL certificate, and repository confirmation necessary to pull the convert2rhel packages from the Red Hat content delivery network (CDN):

$ curl -o /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release https://www.redhat.com/security/data/fd431d51.txt
  % Total	% Received % Xferd  Average Speed   Time	Time 	Time  Current
                             	Dload  Upload   Total   Spent	Left  Speed
100  1855  100  1855	0 	0  11393  	0 --:--:-- --:--:-- --:--:-- 11380

$ curl --create-dirs -o /etc/rhsm/ca/redhat-uep.pem https://ftp.redhat.com/redhat/convert2rhel/redhat-uep.pem
  % Total	% Received % Xferd  Average Speed   Time	Time 	Time  Current
                             	Dload  Upload   Total   Spent	Left  Speed
100  7411  100  7411	0 	0  28684  	0 --:--:-- --:--:-- --:--:-- 28724

$ curl -o /etc/yum.repos.d/convert2rhel.repo https://ftp.redhat.com/redhat/convert2rhel/7/convert2rhel.repo
  % Total	% Received % Xferd  Average Speed   Time	Time 	Time  Current
                             	Dload  Upload   Total   Spent	Left  Speed
100   247  100   247	0 	0   1080  	0 --:--:-- --:--:-- --:--:--  1083

Now it’s time for the main event: The conversion. Be forewarned; depending on your underlying hardware and the complexity of your client install, this process could take some time.

$ sudo convert2rhel --org 12345678 --activationkey SuperSecret

I’ll break this command down. First, convert2rhel calls your newly installed tool. The --org flag allows you to specify your Red Hat Access organization ID, and --activationkey allows you to select a key. These two arguments let you register your converted RHEL server to your active Red Hat subscription.

For more information on using org ID and activation keys, check out the documentation.

Once you start the conversion process, you are presented with the RHEL end-user license agreement (EULA) and asked if you are sure you are ready to proceed. Once all the preconversion checks are complete and the Red Hat packages staged, you can reboot the system.

Up to this point, no changes have been made to the system. However, once you tell the instance to reboot, everything starts happening.

After you hit Enter, your system boots into a temporary environment. Convert2RHEL will replace all the CentOS-signed packages with their Red Hat-signed equivalents.

Standardize on major versions

That wasn’t so hard, right? Now that you’ve trimmed the number of distributions you have to manage to one, you need to do something about the environment’s version sprawl. You may have 7.9, 8.4, 8.5, 8.6… you get the idea. To give the newly standardized environment the most runway, consider upgrading all of your servers to the latest major version.

For one thing, RHEL 8 and 9 have a predictable lifecycle: five years of full support (such as new features and hardware enablement) followed by five years of maintenance support (for example, bug fixes and security patches). That gives you 10 years total. You can also expect a new minor version every six months and a new major version every three years. Since RHEL 9 was released in May 2022, you can expect RHEL 10 in summer 2025.

However, if the “latest and greatest” gives you pause, Red Hat has an Extended Update Support (EUS) release. This allows you to upgrade to a minor version with two years of support.

A predictable release cadence makes life easier for operations teams. Remember having to make the switch from init to systemd? Yeah, frustrating. What was that command again? Oh, wait, no, that was that other server. Is this server running Podman? Nope, no containers. I feel your pain.

How can you relieve those annoying issues and provide your infrastructure with a steady state of major release cycles?

Do in-place upgrades with Leapp

There is also a supported utility to help sysadmins navigate from one major version to the next. That tool is Leapp, a solution for in-place upgrades.

Why do an in-place upgrade versus a clean install? It’s cheaper, and I don’t mean dollars. I mean your time. Your time and energy have great value. With a new build, you must install all your packages from scratch, create all your users (with passwords), and reapply all the little tweaks and configuration changes. It takes time and effort that you could spend doing so many other things.

The Leapp utility is available from the Base OS repository on RHEL 8 systems and in an add-on repository for RHEL 7 systems with a dnf install command. Leapp is also a supported operation, so if you run into trouble, you can always reach out to Red Hat’s support teams to get a fresh set of eyes.

One other aside: Leapp for RHEL 7 and 8 means you can take a RHEL 7 box, upgrade it to a RHEL 8 box, and then rerun Leapp to get to a RHEL 9 server. Granted, that depends on the workloads, library versions, and other factors you may be running.

Note: If you want to see the upgrade process for RHEL 7 servers, check out this video:

If you already have a RHEL system registered and up to date, it is an easy process to install the Leapp utility:

$ sudo dnf install -y leapp-upgrade

To evaluate that an in-place upgrade will be successful, the tool’s preupgrade assistant audits all your packages, repositories, and configurations to identify potential pitfalls or blockers that may interfere with a successful upgrade. The tool helps you identify issues that could cause failures.

The Leapp utility is available from the Base OS repository on RHEL 8 systems and in an add-on repository for RHEL 7 systems with a dnf install command. Leapp is also a supported operation, so if you run into trouble, you can always reach out to Red Hat’s support teams to get a fresh set of eyes.

One other aside: Leapp for RHEL 7 and 8 means you can take a RHEL 7 box, upgrade it to a RHEL 8 box, and then rerun Leapp to get to a RHEL 9 server. Granted, that depends on the workloads, library versions, and other factors you may be running.

Note: If you want to see the upgrade process for RHEL 7 servers, check out this video:

If you already have a RHEL system registered and up to date, it is an easy process to install the Leapp utility:

$ sudo dnf install -y leapp-upgrade

To evaluate that an in-place upgrade will be successful, the tool’s preupgrade assistant audits all your packages, repositories, and configurations to identify potential pitfalls or blockers that may interfere with a successful upgrade. The tool helps you identify issues that could cause failures.

When the preupgrade assistant shows no inhibitors, you can proceed with the upgrade. If it identifies an inhibitor, you can get the details in the /var/log/leapp/leapp-preupgrade.log file. You can also add workarounds or skip certain operations by adding those options to the /var/log/leapp/answerfile. This option makes the upgrade process less manually intensive. Not only will this tool help you identify potential issues, but you can also take those notes and feed them into an answer file to further automate this process.

With the upgrade assessment in the green, start the upgrade. I like to add the --reboot option so that I don’t have to manually reboot the system after the upgrade process begins:

$ sudo leapp upgrade –-reboot

At this point, Leapp gets to work. This process may take some time, depending on the size and complexity of your installation. It downloads all new packages, from the kernel to OpenSSL to Vim and more. It also builds a new boot image to support the new environment.

Once the packages are all in place and the new boot image created, all that’s left is for the system to reboot itself. When you return to a login prompt, you are ready to go!

Wrap up

Sitting on the floor next to my desk is a workstation that has been running since Fedora 29. I’ve done in-place upgrades up to Fedora 36, and the process has gotten better, faster, and more accessible. This is the foundation of the Leapp tool for RHEL. Red Hat depends heavily on upstream communities to help shape the future of RHEL.

Convert2RHEL and Leapp have seen a lot of adoption in the community and received a steady amount of engineering attention, making the process faster and easier. These two tools aim to help make your job easier by managing that infrastructure sprawl, cutting down technical debt, and providing a firmer foundation for any workloads thrown your way.

What will you do with all that newfound free time? Will you take that vacation? Learn a new technology? Knock out other projects? Or just take a nap? There is no wrong answer. As sysadmins, it is our job to enable our businesses to be successful, but that doesn’t mean we should have to toil!

Head to the migrations page and start planning your standardization project today!

This article is based on What’s new with Red Hat Enterprise Linux migrations: Convert2RHEL and Leapp upgrades, presented at Red Hat Summit in May 2022 and was originally published on the Enable SysAdmin blog.

IT operations folks strive to not only maximize uptime but also keep systems patched. These might seem like competing goals, but we’re here to help with Live kernel patching in Red Hat Enterprise Linux (RHEL) and enjoy some improvements with live kernel patching in RHEL 8.5.

You can use a built-in tool to get update the kernel on RHEL systems with no downtime. That tool is live kernel patching (kpatch). Kpatch has been a part of our operating system for some time now (since RHEL 8.1, 7.7). However, with RHEL 8.5 (and the 9.0 Beta), there are some significant enhancements.

To catch the rest of my article, head over to the Red Hat blog here!

Way back in the day, humanity created computers to help make our lives easier. In a lot of ways, they have; in others, it’s made life much more tedious, especially for the SysAdmin. What used to be a mainframe has turned into hundreds of servers, containers, and virtual machines spread across data centers, clouds, and even laptops!

Never fear, Infrastructure as Code (IaC) is here. Tools like Ansible have been around for over a decade or more but in the past few years they have really picked up speed. Ansible is a simple, efficient approach to automating and standardizing our environments while cutting down on the time, increasing reliability, and removing the human error factor from operations and deployments!

My Story

Probably around 2012 or so, I was a rookie Linux Systems Administrator just making the move away from managing Windows servers and desktops. I remember how much fun patch days were…at first. We got to take the morning off, spend an evening at our off-site data center, order in some Jimmy John’s, and once the corporate office closed, start patching systems. We ran CentOS, RHEL, Oracle Enterprise, and maybe even an Ubuntu system or two.

Looking back, it was actually an unnecessary time suck! Why!? Patch a couple of hundred servers, by hand, rebooting systems manually, and hoping that nothing broke because the application and database administrators were already at home enjoying the end of their workday. The one saving grace at that point was Tmux (an amazing tool to manage multiple terminal sessions at once). At least then I didn’t have to type yum update 200 times!

I guess Charles Dickens might have said of my career: “It was the best of times, it was the worst of times…” I finally got to focus on Linux Servers, bye-bye Windows, but who wants to spend their Thursday nights patching a couple of hundred servers by hand?

That’s not why you’re here, though. You all know I have my SysAdmin scars and I wear them with pride because now, I get to share amazing lessons I learned (or in today’s case should have learned back then). Today, I want to introduce a tool that could have taken our patching times from 6-7 hours down to what could have been less than an hour. Even more, that process could have been completely automated!

What is Ansible?

Ansible is a project bred from the idea that all infrastructure (even security, networking, and cloud) should be code. In other words, if you think of your lab, network, enterprise, whatever as a restaurant, Ansible would be the recipes the cooks used to make every dish. Ansible is written predominantly in Python and utilizes YAML or “YAML Ain’t Markup Language” (who doesn’t love a good recursive acronym?) for its playbooks.

Ansible, not to be confused with the Red Hat product Ansible Automation Platform, is an open-source project that runs across most Linux and Unix systems as well as Mac and Windows and even networking gear, clouds, and security appliances! The list of modules and supported platforms grows with every release.

[ansible@fedora-server-34 ~]$ ansible --version
ansible 2.9.21
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/ansible/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.9/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.9.5 (default, May 14 2021, 00:00:00) [GCC 11.1.1 20210428 (Red Hat 11.1.1-1)]
[ansible@fedora-server-34 ~]$ 

The name was inspired by Rocannon’s World, a novel by Ursula K. Le Guin. In the 1966 novel, ansible was a fictional, instantaneous communication system. Ansible would later become the name of the open-source tool. Michael DeHann, the original developer decided to build a company around his new tool and with the help of Said Ziouani and Timothy Gerald founded AnsibleWorks Inc. Later, the company was renamed Ansible Inc and eventually was acquired by Red Hat in 2015.

Why Ansible?

Ansible burst onto the field in an age where Infrastructure As Code (IaC) tools seemed to be everywhere. However, Ansible had a few attributes that set it apart from its competition.

For one, Ansible is agent-less. In other words, there is no software to deploy across your enterprise. You could install the Ansible package on your laptop and manage thousands of servers across bare metal, virtual machines, and even the cloud!

Being agentless also opened the door for another advantage: Ansible utilizes OpenSSH to execute remote commands instead of proprietary or platform-specific tools.

Thirdly, Ansible set itself apart by choosing simple, YAML-based text files to define its environments and code. Want to have a pre-defined list of servers to manage? Add it to an inventory file! Want to use Ansible to create a user, set its password, and add an SSH key? Write a playbook. Want to have support for different environments (dev, prod, etc.)? Easy, just create a variable file!

Getting Started

Did I sell you on how easy and awesome Ansible is? Good, because here is the entrée for today’s meal: Let’s install Ansible and use Ansible to add a package on our local system. For the sake of this demonstration, I’ll be using one of my favorite server distros, Fedora Server, specifically Fedora 34. Ansible is available for most major distros, so, consult your package manager to find the correct package.

The first step is to install the required Ansible package and its dependencies:

[ansible@fedora-server-34 ~]$ sudo dnf install -y ansible
Last metadata expiration check: 0:05:30 ago on Tue 22 Jun 2021 04:13:57 PM CDT.
Dependencies resolved.
===============================================================================================================================================================================================================
 Package                                                    Architecture                                Version                                             Repository                                    Size
===============================================================================================================================================================================================================
Installing:
 ansible                                                    noarch                                      2.9.21-1.fc34                                       updates                                       15 M
Installing dependencies:
 libsodium                                                  x86_64                                      1.0.18-7.fc34                                       fedora                                       165 k
 python3-babel                                              noarch                                      2.9.1-1.fc34                                        updates                                      5.8 M
 python3-bcrypt                                             x86_64                                      3.1.7-7.fc34                                        fedora                                        44 k
 python3-cffi                                               x86_64                                      1.14.5-1.fc34                                       fedora                                       244 k
 python3-chardet                                            noarch                                      4.0.0-1.fc34                                        fedora                                       214 k
 python3-cryptography                                       x86_64                                      3.4.6-1.fc34                                        fedora                                       1.4 M
 python3-idna                                               noarch                                      2.10-3.fc34                                         fedora                                        99 k
 python3-jinja2                                             noarch                                      2.11.3-1.fc34                                       fedora                                       493 k
 python3-jmespath                                           noarch                                      0.10.0-1.fc34                                       updates                                       46 k
 python3-markupsafe                                         x86_64                                      1.1.1-10.fc34                                       fedora                                        32 k
 python3-ntlm-auth                                          noarch                                      1.5.0-2.fc34                                        fedora                                        53 k
 python3-ply                                                noarch                                      3.11-11.fc34                                        fedora                                       103 k
 python3-pycparser                                          noarch                                      2.20-3.fc34                                         fedora                                       126 k
 python3-pynacl                                             x86_64                                      1.4.0-2.fc34                                        fedora                                       110 k
 python3-pysocks                                            noarch                                      1.7.1-8.fc34                                        fedora                                        35 k
 python3-pytz                                               noarch                                      2021.1-2.fc34                                       fedora                                        49 k
 python3-pyyaml                                             x86_64                                      5.4.1-2.fc34                                        fedora                                       194 k
 python3-requests                                           noarch                                      2.25.1-1.fc34                                       fedora                                       114 k
 python3-requests_ntlm                                      noarch                                      1.1.0-14.fc34                                       fedora                                        18 k
 python3-urllib3                                            noarch                                      1.25.10-4.fc34                                      fedora                                       175 k
 python3-xmltodict                                          noarch                                      0.12.0-11.fc34                                      fedora                                        23 k
 sshpass                                                    x86_64                                      1.09-1.fc34                                         fedora                                        27 k
Installing weak dependencies:
 python3-paramiko                                           noarch                                      2.7.2-4.fc34                                        fedora                                       287 k
 python3-pyasn1                                             noarch                                      0.4.8-4.fc34                                        fedora                                       133 k
 python3-winrm                                              noarch                                      0.4.1-2.fc34                                        fedora                                        79 k

Transaction Summary
===============================================================================================================================================================================================================
Install  26 Packages

Total download size: 25 M
Installed size: 143 M
Downloading Packages:

<<< Output Truncated >>>            

Complete!
[ansible@fedora-server-34 ~]$

Excellent, feel the power yet? Let’s get a little crazy. Let’s write a playbook. Let’s install a package!

I really like htop. It is a “graphical” tool that, in this author’s opinion, makes it much easier to read and understand the output of the top command.

Luckily, it’s available from the default Fedora repos. So, using your favorite text editor, create htop.yml:

---
- name: installing packages
  hosts: localhost
  become: yes
  tasks:
    - name: install htop
      package:
        name: htop
        state: latest

What’s all this mean? Let’s break it down line by line. Make sure to start your playbook with three hyphens (-), then name tags are just that, it lets you know what task is being run to make it easier to understand the output (and especially troubleshoot any problems). Next, we have the hosts. For this super-simple example, we are only calling localhost. This could also call any number of hostnames or groups listed in an inventory file. Become is basically your sudo command. If you set Become to yes, Ansible will run with administrative privileges. Otherwise, the playbook will run as whatever user calls the playbook.

Under tasks, we have another name tag. We are calling the package module. This is what is so cool about Ansible; you can actually build playbooks that will run over differing distributions! The package module is intuitive enough to know what your system’s package manager is: apt for Ubuntu, yum for CentOS, dnf for Fedora, and so on. Next, we call the package, in our case, htop. The final line is the state of the package. We can set this to a specific version, to absent (if we don’t want the called package installed), or latest, which (you guessed it!) means the package will be on the latest version.

Now, save your config file, and let’s run our playbook:

[ansible@fedora-server-34 ~]$ rpm -qa|grep htop
[ansible@fedora-server-34 ~]$ ansible-playbook htop.yml 
[WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'

PLAY [installing packages] ************************************************************************************************************************************************************************************

TASK [Gathering Facts] ****************************************************************************************************************************************************************************************
ok: [localhost]

TASK [install htop] *******************************************************************************************************************************************************************************************
changed: [localhost]

PLAY RECAP ****************************************************************************************************************************************************************************************************
localhost                  : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

[ansible@fedora-server-34 ~]$ rpm -qa|grep htop
htop-3.0.5-4.fc34.x86_64
[ansible@fedora-server-34 ~]$

You can see htop is not installed before we run our playbook, then after we run it, htop is indeed present!

Wrap Up

So, there you have it. You now have the power to go out and install a package on any SSH-enabled host system. Go forth and blow people’s minds! When you take this simple example and zoom out, you start to see the sheer power that Ansible can bring to a Systems Administrator. Step aside, Luke Skywalker, we don’t need the Force anymore to move your X-Wing. We’ll do it with Ansible!

Okay…That may be over the top. However, I can’t overstate the truth: Build out your playbooks. Grow your Ansible skills. The rule is, if you have to do a task more than once: AUTOMATE IT! Stop installing packages by hand. Quit wasting your time bootstrapping servers by copy-pasting commands out of a shared document. Take those commands, add in some Jinja-variable goodness, and let computers do what they were meant to do: make the lives of humans easier.

Need some more ideas to get you going? No problem! Ansible has AH-MAZE-ZING documentation and an awesome Getting Started landing page.

Like a terrible TV infomercial, just wait, there’s more! Have a favorite open source project you like or a system service that you tend to modify? You may not even have to start from scratch! Ansible has galaxies (pun intended) of pre-built roles and playbooks available. Ansible Galaxy is a community-driven effort to provide pre-built code to get your systems up and running fast. They have playbooks for Nextcloud Server, LAMP, and even desktop applications!

I use Ansible every time I build out a new VM. I use Ansible to ensure my user account is configured exactly the same way across all my systems: laptop, desktop, server, VMs, and cloud! Admittedly, my list of Ansible To-Dos is still fairly large, however, I try to spend a little time each month adding to it. Slowly but surely, I am automating and standardizing my home lab and home production systems. You can too!

Let me know below how you are or are planning to use Ansible.

Did you like this post? Let me know in the comments if there is more you’d like to read on this topic. There is SO much more we could talk about from products like Red Hat’s Ansible Tower (or the upstream AWX project) to large-scale use cases, bootstrapping, and more. So, by all means, let me know what you are interested in.

Thank you so much for spending your valuable time to hear my “war stories” and letting me share a tool with you I am quite passionate about.

(This post originally appeared here and is used with permission.)

Before coming to Red Hat, I spent nearly a decade as a Systems Administrator. After all that time, I’m still continually discovering tools that would make life as a SysAdmin much easier. One of these utilities is the redhat-support-tool. In this post, we’ll walk you through using the tool in some real-world scenarios.

What is the Red Hat support tool?

The support tool allows you to interact with the Red Hat knowledge base, support tickets, analyze log files, and even set site-wide configuration options, all from the command line! At first glance, that may not seem like a big deal but consider these real-world scenarios.

Want to catch the rest of this post? Head over to the Red Hat blog!

I am sure many sysadmins can relate to this scenario:

You get into work on Monday morning, attend your staff meeting, and log into your ticketing system, expecting a quiet week. NOPE! Right there in all caps (why do people use all caps in a ticket?) and marked Urgent is a request for a new application environment. Of course, the requester needs the new server up and running by the end of the week.

You are a savvy sysadmin. No problem, right? How hard could it be to deploy a new server with a database and web server? You thought ahead. You have templates for these things!

Then that database server you spent all weekend trying to fix crashed again. That took all day. Tuesday was that company all-hands meeting. Wednesday, more meetings and fires. Now it’s nearly Friday. That urgent ticket with its all caps glares at you every time you log in to update a ticket.

Time to be a hero! You close your email, mark your calendar as busy, and put on your headphones. You deploy your production template, but uh oh, that one is three minor versions behind.

So you check the one on your laptop. That one is running the latest version, woot, but nope, that one is running the “old” security tool. In desperation, you log in to your private cloud (say OpenStack). You know that template is up to date, but something corrupted the boot image, so now you can’t get a terminal.

In frustration, you return to your production image and just run the patches. You throw your hands up and add three new tickets to your queue to fix these out-of-date images.

A new way to RHEL

If that feels familiar, you should connect with me on social media: @itguyeric. I think it’s about time we start a club, support group, or something. While that may be an amusing anecdote, it was true of my experience for a good chunk of my operations career. And not just for me, but for many of you who work in the trenches daily keeping companies, universities, and governments up and running.

Deploying an operating system is expensive. It costs resources (hardware or compute time) and something far more precious: the time and attention of a sysadmin.

Do not despair; those days of managing images across platforms, versions, and configurations are swiftly closing. The issue of template management is where image builder comes into play.

Red Hat Enterprise Linux’s (RHEL) image builder saves time and reduces complexity when deploying optimized systems across datacenters and cloud footprints.

Image builder comes in three flavors: command line, local install (on a RHEL host), or Red Hat’s hosted service. No matter which flavor you choose, you’ll be able to design optimized images for your targeted platforms: hardware, qcow2 or vmdk, or cloud image.

Image builder workflow

You can break down the image builder process into five steps:

1. Select your platform. Choose one of the three big cloud providers, a virtual image, or a hardware installer for servers or edge devices.
2. Select your image builder tool. Choose between an on-premises build or the hosted solution.
3. Create a blueprint. Define filesystems, select packages, and configure users.
4. Build the image. Pick virtual, AWS, GCP, Azure, VMware, or ISO types.
5. Deploy your instance. Not just one, either. Image builder helps create images to deploy anywhere, anytime.

How does it work?

I sense some disbelief, so I’ll walk through an example. And if you prefer to learn by watching, check out my video at the bottom of this article.

First, log in to the tool at console.redhat.com. Once you’ve logged in with your Red Hat Customer Portal account, navigate to Red Hat Enterprise Linux and select Red Hat Insights.

The link for image builder is toward the bottom of the Insights panel (or just navigate straight to the tool).

Now you can begin to create a new image.

From the Create image wizard, you define how your image will look. First, choose between RHEL major releases. Versions 8 and 9 are currently available on the hosted service. Next, decide what kind of image to build.

For this example, imagine you want to deploy a production instance on Google Cloud Platform (GCP) but also have a qcow2 file to do testing and development work from your local laptop.

Notice that when you select certain options, your breadcrumb trail adjusts to reflect the additional steps. For GCP, you can choose to share the template with a user account, a service account, a group account, or a domain.

For this example, I will just share it with my Red Hat account on GCP.

Now, this is one of my favorite features: You can bake your registration into the image. All you need is a valid activation key setup in your customer portal. But that’s not all; you can also preconfigure your image to register with Red Hat Insights right from the template.

One of the newest additions to the image builder tool is manually configured filesystems. You can now define sizes and locations for multiple partitions. For this example, I’ll add a home partition, and also add a webapp directory under opt. I will set both of those to 5GB but leave the root at the default 10GB.

Next stop, packages. There are literally thousands of packages available in the Red Hat repositories. You can add any combination of these packages to your image. For instance, I am a huge fan of tmux, a terminal multiplexer.

I mentioned this would be a web application, so I’ll grab Nginx, too.

What you cannot see from this menu is that image builder automatically added all the dependencies for tmux and Nginx to the image. That’s over 100 packages that it added to the list without any intervention.

All that is left is to give your image a descriptive name and review the choices. Image builder does the rest.

Building an image varies greatly between how complex the image is, how large the actual image will be, and, like all shared services, how heavy of a load there is on the platform. In this demonstration, I saw between 10 and 18 minutes.

Once the images are done building, you can start deploying them. For the qcow2 image, I received a link to download the file directly from my browser. You can then upload it to a file share or hypervisor, or import it into your laptop for local use. Your options will vary depending on your choices above.

You receive an image name for the GCP image that you can use to copy the template into your GCP account. You can use it just as you would any other cloud image.

Wrap up

This article may sound like an infomercial for image builder, but the process is that easy. I have used many different tools over the years: Documenting the process in text files, complicated Kickstart scripts, or VM templates. Image builder has been the easiest to incorporate into the workflow for my home lab and for the content I help develop for Red Hat Enterprise Linux.

With different platforms, formats, and combinations of settings, image builder quickly meets the needs of any number of operations projects.

Please don’t take my word for it, though. Try it for yourself. Either visit the hosted service or try out our two Image Builder labs. The first is web console-based and the second relies on the command line interface.

Here’s a demo video we made of the full process.

This article is based on “The new way to Install Red Hat Enterprise Linux: image builder service” from Red Hat Summit 2022 and was originally published on the EnableSysAdmin blog.

These days it can be overwhelming to select the best software to use because now more than ever, choices are abundant when it comes to software. Messaging and Communications apps are a great example of that because there are so many options out there. What if you’re looking for a messaging app that is scaleable and privacy-focused? It can be even harder.

Thanks to the Element team, I’ve got a great option to show you. Element, previously known as Riot.im, is a cross-platform client that works on the Matrix protocol. What does that mean? Is Neo the One? Well, let’s talk about the protocol and why you should consider using this great messaging platform.

What Is Matrix?

The Matrix team describes it as an “open standard for secure, de-centralized, real-time communication”. First, it’s open-source, more eyes equals better code. We all know how much I love open source…but for the uninitiated, that means more people can read and study the code, security vulnerabilities can be found and fixed faster, and other projects and contributors can build effective integrations into the source project.

Second, it’s decentralized. This is a little more complicated, but think of it this way, when you stand up an instance of a decentralized application, that is your space. This could be for a family, a meetup, or a company. Everything would be self-contained until you make your instance discoverable. At that point, you@yourhomeserver.com can reach out into the world and find say friend@anotherserver.com.

Thirdly, Matrix supports real-time communications. This includes collaboration, messaging, voice, and even video! Matrix provides a series of encryption algorithms and bridges to facilitate end-user applications to communicate with one another. You may use Etherpad for real-time collaborative document editing, Jitsi for video conferencing, and in today’s blog post, Element for messaging.

Some of the most popular bridges for Matrix are IRC and Gitter. The Open Source Community jumps in with some of their own too, including Telegram and Google Hangouts.

Matrix enables the communications between these platforms within an instance or throughout the interconnected network of Matrix instances across the Internet.

What is Element?

If Matrix is the network, then the Element client is the vehicle that allows you to traverse that network; Element is the interface for text, voice, and video conversations. Just like the Matrix protocol, the Element client is completely open-source!

With the ability to bridge between different apps like Slack right into the Element interface, you no longer need to install and maintain a dozen different apps just to keep in touch with friends, family, work, your volunteer group, your work’s other chat client…you get the idea.

Create an account, activate the needed integrations, and chat with anyone, anywhere on any number of different platforms. Enjoy a 1:1 conversation or hundreds of participants in public rooms.

Bonus: One of my favorite features? Notifications management. I can have every notification from every room, set it to only being notified if I am tagged, or never get any notifications…ever. But Element didn’t stop there, nope, they have one of my favorite notification settings I have ever seen: keyword notifications.

Let’s say I want to know any time someone is talking about dogs. I can add keywords to my configuration and get notified anytime someone says dog, dogs, cats drool, you get the idea!

Element has the option to join the central server at Matrix.org, host your own instance on your own server, or pay a monthly fee for a secure, hosted option. In fact, from their website, you can get up to 5 active users a month for as little as $2/month (USD).

Creating Your Account

It’s now time for you to enter the Matrix and get into your Element. See what I did there? Alright, to get started you will need to create an account. One of the best things about Element is that you can use it on all sorts of devices like your laptop, tablet, phone, or whatever.

For this guide, I’m going to show you how to do it on the Web client in your browser. So open up your favorite browser, such as Mozilla Firefox, and navigate to https://app.element.io.

Your browser will likely ask you to allow access to persistent storage. Accept it that way Element can store your keys, messages, etc. Next, we are going to create an account.

We could create our account on Matrix.Org, but here is a little pro tip: The central server in a federation usually is over-taxed and prone to lag. So, if you know of another public-facing instance, that would be a good bet.

Lucky for us, the community has some awesome members that manage LinuxDelta.com, a community-driven hub for information on Linux distributions, tutorials, and a Matrix server! Instead of using the Matrix.Org option, we are going to go to Advanced/Other:

In the ‘Homeserver URL’ field, type in: https://matrix.linuxdelta.com and click on the green next button. Next, it’s time to create a username. The username will be your display name as well so keep this in mind as you decide. This is what people will see you responding as and how they can tag or search for you! Then create a password, make sure it’s complex. No sense in skimping on security especially if you are utilizing a password manager, like Bitwarden for instance.

Me personally, I am a content creator and a community advocate. I want to be found in the open-source community, so, I would add an email so people can look me up via email. If you do, you’ll of course be sent the customary email confirmation link. For now, though, let’s go ahead and sign in.

Once you have filled in your username, password, and email go ahead and click the green Register button!

This next step is tricky but stay with me. One of the advantages of Element we discussed was end-to-end encryption. We need to generate a Security Key (that is different from our password!). I typically recommend using a system-generated key. Then you can use a secure note somewhere to store the key.

Disclaimer – I changed the security key after writing this blog post, so, don’t think you can get into my account that easily. 😀

Once you’ve saved your key somewhere safe, go ahead and enable notifications and read through some of Element’s recent announcements.

Getting Connected

You are sitting with a brand new, secured account. Now what? Well, Element is a communication platform, let’s find some people to communicate with!

In the middle of the window, there is the option to “Explore Public Rooms”. Let’s click there. Element will default to your home instance, in this case, LinuxDelta.com.

Get connected to The Geek Lab, for instance, by clicking join. That will put you in touch with hundreds of other technology enthusiasts like yourself who hang out, chat, and help each other fix technical problems.

Want to get connected to the broader world? Go back to the Explore button, next to the search bar. In the window we saw before, we have the option to create a new room or select a different server. Let’s hop over to Matrix.org.

There are literally thousands of public rooms covering a crazy number of different topics. Many open-source projects have communities on Matrix. There are HAM radio enthusiasts, D&D (Dungeon and Dragon) hangouts, and even region-focused rooms.

The join process is exactly the same though for a different server, just find a room you want, click join, and start chatting.

There is plenty more to do and discover. From 1 on 1 conversation, adding bridges, and initiating video calls. However, for now, that is all the deeper we will go!

Closing Thoughts

You may be surprised to hear that this is not paid content. I wrote this because I believe in Element. I believe that Matrix is going to have a HUGE part to play in the years to come. There are SO many (read too many) apps to keep track of. Many of them have ads or tracking built-in, or are limited to voice or text. Element, powered by Matrix, has it all. The integrations keep getting better. More and more bridges keep getting built (no pun intended, okay, maybe a little pun).

Open Source is the key. E2E (End to End Encryption) will ensure that your private conversations stay private… You know, I haven’t even mentioned the beautiful interface or that the Element Team releases new features on a frequent basis.

So go sign up and give Element & the Matrix protocol a try! When you get your account registered, be sure to look me up: itguyeric@one.ems.host

(This article was originally posted here and is used and updated with permission.)

Where do you get your tasks from?

For me, it’s meetings, household chores, ongoing projects, random lists, IMs, Emails, forum posts, social media (yeah, believe it!), whew. For years, I tried different tools and methods for tracking my to-dos. I was pretty good at it… Most of the time. It seemed like now and then, though, I would hit a breaking point and all the plates I had been juggling would fall to the floor, and I’d have to start over again.

Enter Todoist, a product which boasts you can “regain clarity and calmness by getting all those tasks out of your head and onto your to-do list (no matter where you are or what device you use).” To say that Todoist is a to-do list or even a project management application would be a gross understatement. Over the past few years, I have managed to shift from an anxious task tracker to a productivity power user.

I work a demanding job in a challenging field, host a podcast, a live stream, have a wife, four wonderful kids, and a few hobbies. Add on top of that the need to sleep, work out, and get things done around our house. I don’t say that to impress you. We are all busy. It’s a challenge. What I plan to unleash into your minds is a series of tools and methods I use every day to get everything done. We’ll cover Todoist, email management, ways to focus on tasks (like me trying to write this blog post), and much, much more.

Grab your caffeine and hold on tight. Here we go!

Why use a to-do list?

“I don’t need a to-do list. I have that list in my head.”

Pleeeaaase. No you don’t! We live in a world of CRAZY connectivity! Everything is always on all the time. Tweets, news, sports, YouTube, podcasts…and that’s just a short list only from the digital world! Many of us have multiple devices within a few feet of our favorite chair that spend their time lighting up, dinging, buzzing, and ringing. Attention spans and deep work are at an all-time low.

“So what, I can multitask.”

Sorry, Charlie! That’s a common misconception. What you are really doing is context switching. The more alike tasks are, the easier it is to switch between the two in a short space of time and with little productivity penalty. However, if you go from following a lively instant messaging thread about plastic versus metal dice for tabletop games to working on a 3-year business plan, you aren’t giving either your full attention.

(Besides, we all know metal dice are better!)

Not only are you not giving either task your full attention, but you are also draining your limited energies for the day. You’re shifting gears between two very different tasks. That comes with a tax and lowers the quality of the finished product. We try to compensate for this by starting several tasks at once, then getting nothing done. Then, as inevitably happens to me, your youngest daughter bursts into your room and grabs your iPad off your desk! By the time you get her setup with her afternoon activity and get back to work, those 3 or 4 or 5 tasks have all fallen and shattered all over the floor. Now, you have to spend wasted time trying to pick up where you left off with each task!

“Eric, tell me there is a better way!”

Fear not, my young apprentices. There is a better way! To-do lists. Ta-da! That’s it. You’re welcome.

Oh, wait… You want to know which one? Okay, I got you. Sorry, I dropped the mic too soon.

How I found Todoist

I used to be stuck on Microsoft Outlook 2003. It had a decent task tracker… You could schedule tasks, set reminders, and eventually could even set tasks to repeat. It was okay. Eventually, I moved to Apple Tasks. It wasn’t as feature rich as it is today, but it got the job done and as a bonus synced to my mobile device. I’d also tried out Trello, but at the time couldn’t quite get a handle on how to use a task board (stay tuned, wink wink!). I also tried organizing projects into MS Project in college (yeah, I was that nerd), eventually projects moved into Evernote, and later Joplin.

Tasks and projects though are two different beasts entirely, but they are also connected! What I found I needed was a way to do both, preferably in the same tool. I needed to be able to do scheduling, track progress, and and and… My list of needs seemed to keep getting longer, how could any tool stand up to that!?

A friend of mine told me about this tool with a weird sounding name: Todoist. To-Do List without the L, clever, huh?

I had my doubts and, if I am being honest, was just looking for excuses not to use it. Strike 1 it’s not open source, strike 2 it’s a paid, cloud service. I told my friend this wasn’t looking good.

However, I begrudgingly created an account, and what I found surprised me. It had a simple-yet-beautiful user interface (UI), incredibly intuitive layout, and many of the features I felt I needed out of a task management tool. I can remember setting aside my work for the rest of the afternoon; I needed to give this tool a proper test drive. A few hours later, I was sold, literally, I signed up for the Pro subscription right then and there.

I could set reminders, recurring tasks, could set labels or organize by project. I had a Today view, that really helped, so I didn’t see EVERYTHING I needed to do, just wanted I wanted to get through that day. Not only that, but I had multiple levels of tasks (projects, sections, tasks, sub-tasks, and priorities).

It didn’t stop there, though! Since becoming a Todoist customer, they have introduced Kanban boards. Now, instead of sections just being a “subproject”, I could use Agile practices to track my work across their typical life cycle, say from idea to outline, draft, edit, and ready to publish. I could set up email aliases for each of my projects, that way, when someone emailed me a task to complete, I could hit forward, add in some metadata, and hit send. Within a couple of minutes, that task was also captured by my Todoist.

Todoist released Calendar integration. This made it much easier to judge how much work I had to get done. The average work day for me ranges from 30 minutes of meetings, up to 6 hours some days. (Yeah, tell me about it! That’s a lot of meetings.) The problem was, those meeting heavy days I may try to schedule my usual 8-10 tasks and get only a couple of them done. Well, I don’t want meetings to break my streak!! No way! So, I started creating tasks for meetings. Attend a meeting, mark off a task. It kept the streak alive, but also helped me plan better – more meetings, fewer tasks scheduled that day.

Getting Tasks Organized

Like many, many human beings, I sat there that first afternoon, staring at this blank canvas. Now what? I can create anything, schedule it any time, what do I do!?

After a brief battle with the void, I started out by creating projects for each major area of my life and color-coding them similar to my different calendar accounts I was already using: Personal (Blue), Work (Red), and General Tech (Green). For the most part, several years later, I still use roughly that same layout, though I have added a couple more top-level projects. For instance, I eventually added my content creation efforts like the Sudo Show and this blog to their own project.

The next easiest thing to do was to go into Apple Tasks and grab all the tasks I had stashed away in there. Take out the trash, submit a time sheet, etc. Short, recurring tasks were the first to come over. Put them in the right project, give them a due date, and move on to the next task.

The harder migration (at first) was how do I break up the projects on my plate and put them into Todoist? Fortunately, Todoist had me covered. Each project has sections. So, underneath my work project, I have a section for general tasks, for each of the engineering teams I support, meetings, and one for the live stream I host every other week.

I could then add my old projects as tasks inside each of these sections. From there, I learned how to break up a large task (like a podcast episode) into sub-tasks from researching the topic, writing the outline, following up with the guest, and eventually releasing the episode. This made it easy to break off bite-sized chunks of a task and get a little progress done each day! (Incredibly beneficial when you release a new episode every two weeks!)

While I was able to migrate a LOT of my ideas, tasks, and projects in the first couple of days, my approach to project planning, task execution, and idea tracking have evolved over the years. I’ll share more on that in a later post. Nowadays, I get between 10-15 tasks done a day. I have my paper notebook open every meeting to jot down thoughts or ideas, but I also have Todoist open somewhere (phone, tablet, web, or app) to make sure I grab any action items that I need to address. I constantly filter through my emails, ensuring nothing gets asked of me there. Anytime I get an IM with a request, into Todoist it goes!

Want to get started?

I would highly encourage you to get started with Todoist. It’s an amazing tool fueled by a company of folks who are passionate about helping you get more done. They have frequent releases that improve performance, squash bugs, and are still adding new features! They’re used by Apple, NASA, and folks from all different walks of life.

Go sign up for free today:

https://itguyeric.com/todoist

Disclaimer: This link is an affiliate link. If you purchase a Todoist subscription, I get a small percentage. That being said, I would be greatly appreciative of you using my link as anything I make from it is set aside to be reinvested into my content creation efforts (gear, hosting, etc.).

My Reading List

Before you go, I wanted to drop one more idea into your lap: From the screenshots, you’ll notice an orange project called Reading List. Todoist is a great place to drop books, blogs, and white papers!

I have a recurring task to check my RSS feed for any articles that have been published from my list of sources. I probably get about 40+ articles delivered to my RSS reader every day and read probably 25% of them from top to bottom. That can stack up if I don’t keep up with it.

I also do a TON of research between work, the podcast, and my own curiosity. White papers, data sheets, etc. are a hugely popular way to share content these days. Fortunately, Todoist has me covered there too. Todoist supports attachments! If I have a market research report to review, I’ll download it out of my email and drop it in a task and assign a date, that way I am certain I get to it.

Finally, there is my backlog of 60-some-odd books that has been accumulating over the years, from fiction to marketing to parenting. Todoist has even helped me knock that list down from 90 to 60 in the past year or so. When someone recommends me a book, I grab the link from the Kindle website and create a task for it. When I start a new book, I create a sub-task for every chapter. Then, I schedule one chapter a day each workday until that book is complete. The last chapter marks the book task complete, and I move on to the next book!

To keep things interesting, I usually pull a book from each category in my list, then start back at the top. I hope one day to only have a handful of books in this project, but considering my appetite for learning, I doubt it!

Wrap Up

Over the past couple of years, my productivity has skyrocketed! I feel confident I can manage a wide array of tasks on a wide range of projects and still keep my sanity.

Todoist now has a hand in: meeting tracking, household chores, my reading list, podcast and content planning, social media scheduling, and learning. I track tasks from keeping my daily food log to changing the water filter every 2 months, to reminding me to renew that one subscription each year that requires manually requesting a renewal. I haven’t even begun working with a lot of the integrations available in Todoist!

One thing I hope to implement soon is ensuring that recreation and disconnect time become scheduled, recurring tasks in my Todoist so that I can keep the momentum going. Whether that is a day to turn off all my notifications and rest or take the kids to the park. It’s easy to get caught up in all the demands of this world and forget what is truly important: love, joy, fun, family.

Take this journey with me. If you are struggling, learn from my mistakes and my victories. I highly recommend Todoist, but it’s not the only tool out there. Find one that works for you, and let it help you make a difference in your life and in the lives of those around you!

I had the pleasure to head out to Lawrence, KS to talk at the local LUG (Linux Users Group)! Today’s topic? Peertube and the problems it can solve!