Using FleetDM for personal use

Fleetdm: an open core ‘Mobile’ Device Manager (MDM)

If you’re an organisation managing multiple devices, especially what is usually called endpoints such as laptops, smartphones, tablets etc. a system to manage this is very useful. For some reason they are often referred to as Mobile Device Managers (MDM) since the focus these days is on laptops and smartphones and sometimes tablets. They are also quite capable of managing Desktops and servers. Such an MDM can help you maintain these endpoints and ensure that they comply with your policies to help you with security and compliance. As a simple example, from a dashboard you can see an overview of devices, see if they adhere to policies such as full disk encryption, virus scanners up to date, etc.

FleetDM is an Open Core Device Device Manager. Note that you can also manage (virtual) servers with it. This basically means that the core is open source and can be used free of charge. You have to pay for advanced features that are especially interesting for organisations. Obviously I would prefer if those features were free as well, but I fully understand the choice of the company behind Fleet using this business model. Most of these features deal with things that matter if you have many devices, such as multiple teams, app deployment. Some of the features of the paid for version are also interesting for personal use, but these specific features can be worked around.

With great power comes… If you hand over device management to a Device manager, you hand over control. The software running on the devices that connects to the MDM needs to run with high privileges (root). The admins of an MDM have control over the endpoint!

Features of FleetDM that differentiate from the competition

There are certainly other MDMs on the market. Especially in the top 5 you will find that some are better in some features than others including Fleet but Fleet had as few features that can be a deciding factor in choosing Fleet over the competition:

• Open Core (Open Source)
• Price, even the paid for licenses are not the most expensive
• GitOps! Fleet advertises with how well it can be used in automation/Infrastructure as Code
• Support for Linux endpoints. Linux endpoints are first class citizens in Fleet
• Modern hosting options: Kubernetes Helm charts are available and even CloudFoundry is in the documentation on running on Cloud.gov, but this probably means it should work on other CloudFoundry environments
• Built on OSQuery As such you can easily query all sorts of information on the endpoints from your Fleet deployment

Usecases for personal use

Home lab

If you are a tinkerer like I am you end up with loads of VMs and Containers. As an aside Proxmox, especially with its LXD containers, is great to get lots of stuff in a single system such as a Nuc. As I run various services, they get a static IP-address and before you know it, you forget to maintain some of them. I set up FleetDM, enrolled most of the systems in there and it gives me a nice overview including their IP-Addresses. Obviously there are other, maybe even better, ways to admin the static IP-addresses in your Lan but it works well. It offers a lot more though, from one dashboard you can see the state of all your managed (virtual) devices, see if there are vulnerabilities, run queries etc. I do miss Alpine Linux as an option for now. So not everything I run is now in my Fleet setup.

Friends and Family remote support

This is an interesting use case. I long ago stopped supporting others, except for a few direct family members running Linux on their laptops. They are not very tech savvy. However Linux Mint largely maintains itself so it’s not much of bother. Only occasionally apt shows an error, which is easily fixed with one small command. Now I could setup ssh access to their machines so that I could help remotely. But there are a few reasons I don’t want to do that:

1) that means setting up access via the internet to their machines. I prefer to have their machines connect with my Fleet instance 2) I don’t want to have to arrange for moments when they have to have their machines turned on 3) that only works when the laptop is in the home Lan.

So setting up their devices to be controlled via Fleet is interesting. I can view their status. Their laptops will connect and send me data, I don’t have to know when they are online to check. I can remotely run and adapt scripts to fix basic issues. See the a next section how I did this.

Setting up fleet to support a friend or family with a Linux Endpoint

Obviously set this up when that person trusts you to manage their device! But it is pretty simple.

Enrolling a Linux Device

The steps are quite simple:

• from your Fleet server click on Add hosts (in Fleet a Host is equivalent to an endpoint), select the right target OS (the OS of the endpoint) and if it is a workstation or server
• copy the line to be run in a shell on your Fleet server
• adapt to your distro if needed (default is .deb but .rpm and pkg.tar.zst are supported as well)
• run this command on the server in a shell
• this will create an installation package
• copy package to the endpoint (this package can be reused on other endpoints, no need to create a new one each time)
• install on the endpoint

The software will enroll automatically as the URL and enrollment secret are embedded in the packages.

Running update and other long running scripts

Now here is where we run into an issue with the free version. The script takes too long and times out. I looked into setting the timeout longer, but was not able to get this working. Looks like a paid for feature. I tried setting –script-execution-timeout flag but this failed. Maybe someone with more/better knowledge of Fleet can get this working but I chose a work around.

The workaround:

1) install mutt on the host. This allows you to have a locally running script email you the results

2) run the script from Fleet in such a way that it will continue even if Fleet considers it timed-out

3) if a fix is needed, create script that creates a fix script on the host to called from a script on the Fleet server….

The script is run in such a way that it will keep running even after Fleet reports a timeout. Since you want to know the results and act upon it needs to send the results to you. Email is an easy solution and we can use mutt for that. Now if a fix is needed, you can simply use Fleet again to create a fix script on the host and call that.

Step 1: setup Mutt.

Install Mutt if not yet installed using the method of your distro. Usually you need to send email via an authenticated smtp relay server from your ISP. I am not going to detail how to setup mutt correctly, however here is a working config for Delta.nl:

# Use SMTPS (implicit SSL/TLS) to send mail
set smtp_url = "smtps://<myemailaddress@delta.nl>@mail.delta.nl:465"
set smtp_pass = "<mypassword>"

# Implicit SSL, STARTTLS not needed
set ssl_starttls = no
set ssl_force_tls = yes

# From address
set from = "<myemailadress@example.com>"
set realname = "FleetDM notications"

# Optional: signature
#set signature = "~/.mutt_signature"

Test with: echo "Hello world" | mutt -s "Test email" <youremail@example.com>. Most likely the result will end up in your spam folder so check there and if possible tell your mail solution to not mark this as spam.

(obviously I anonymised the credentials and email-address, so all the sections in between <> characters )

Step 2: run the script from fleet

The timeout will be too short, but if you run the script in such a way that it continues regardless and sends the results via email it will do its job. So create a script that you can upload to Fleet with the following content i.e. nano updateos.sh:

#!/bin/bash

nohup date > /tmp/aptresults.txt &&  apt-get update && apt-get upgrade -y  >> /tmp/aptresults.txt  && mutt -s "update results" youremail@example.com < /tmp/aptresults.txt && rm /tmp/aptresults.txt & 

exit 0

If you want to test it out first, turn into an executable script with the command chmod +x updateos.sh and run it. You should get an email with the output of apt. By the way, use apt-get instead of apt since that is safer to run from a script.

• Upload this to script from step 2 to Fleet in the WebUI: Controls -> Scripts -> + Add script
• In the WebUI: Hostss -> Actions -> Run Script -> select the script and click on actions -> run -> Run (green button) -> Done

This should now show up under Activity and Upcoming If all goes well you end up receiving an email with the information on the update process. Now if it shows an error go to Step 4.

Step 3: Create a fix script if needed

I assume the fix script may also take some time so we’ll use the email trick

• create a fixhost.sh script nano fixhost.sh which you can run the server:

#!/bin/bash

nohup echo "date > /tmp/fixresults.txt && hostname >> /tmp/fixresults.txt && fixcommand  >> /tmp/fixresults.txt  && mutt -s \"results fix\" youremail@example.com < /tmp/fixresults.txt && rm /tmp/fixresults.txt &"  

exit 0

• don’t forget to replace fixcommand with the actual command to fix, i.e. dpkg -r and put your own email address in the script.
• run the script in the same way the updateos.sh script was run via the webui.

You should get an email which hopefully told you that it was fixed. Obviously if the fix didn’t work and you need to do more troubleshooting this gets to be cumbersome. But so far I usually only had to run the occasional dpkg correction so this works fine.

Bonus: run Lynis

Now if you care about security it is good idea to run Lynis. Obviously it should be installed first on the host. You can do that from Fleet if you want. I assume here though that is installed already. Obviously you can also do this from a cronjob. Doing this from Fleet has some advantages though. You can run it when it suits you best. You can alter something if needed without accessing the host.

NOTE: email is not a safe way to distribute security information! Check in your own situation if it makes sense. I.e. if you use an internal email solution end to end which you can trust. You might want to use other safer ways of sending the logs such as scp, but that is outside the scope of this write-up.

#!/bin/bash

nohup date > /tmp/lynis-audit.log  && hostname >> /tmp/lynis-audit.log && lynis audit system --cronjob >>  /tmp/lynis-audit.log  && mutt -s "Lynis Audit Results" youremail@example.com < /tmp/lynis-audit.log && rm /tmp/lynis-audit.log &

exit 0 

This should get you an email with results. Don’t forget to actually read the email to see if you need to act upon it.