SCCM Range Deployment
If you’ve never heard of Ludus, I almost feel bad for you. Because once you know, there’s no going back. This absolute game-changer is about to save you HOURS, and I’m basically your hero for telling you about it. You’re welcome. I’ve just changed your life, so feel free to name your firstborn after me.
Now, let’s give credit when credit is due. Who built that thing?
A talented person by the name of Erik Hunstad who also happens to be the founder of badsectorlabs.
Alright, and what is Ludus for? It’s a wrapper around Proxmox used for deploying virtual environments, or labs. Actually, in Ludus’ vernacular, labs are called Ranges, but more on this later…
Ludus was designed to automate the deployment of Proxmox-based labs so you can skip the weekend meltdown of struggling with a subpar setup just to flex for the office on Monday. We know who you are.
I’m not gonna spend time going over the different moving parts that make Ludus. Instead, for this, you can check the official Ludus website which contains enough information to get you up to speed. I will just sit here waiting for you to come back.
I find the official documentation a tad messy, and a bit chaotic to navigate at times, so do yourself a favor and jot down your own notes on the side. Otherwise, you’ll find yourself moving back and forth between pages to get the full picture.
By now, I assume you have a Proxmox server, and that you have installed Ludus. The next thing you wanna do is creating a Ludus user.
What for? I’m glad you’re asking.
The philosophy of Ludus is that you should keep your labs segmented, and that makes sense, right? Why in the world you have resources in common between two unrelated labs. You have a range — and a user thereof — and that’s it. You need to perform a particular action on that range? Impersonate the user for that range. You need to start that range? Impersonate the user for that range. Alright, but what in the world a range is? It’s just a high-sounding term for a lab, or network, or whatever you’re preferring calling it.
During Ludus installation, you were given a root LUDUS_API_KEY. I hope you got it saved somewhere. If not, I’ve got you, simply slap that into the shell:
ludus-install-status
What should you do with that key? If you need to create other users — which you will sooner than later if you’ve paid attention that far — use that root key. Otherwise, put it somewhere safe, and leave it there until you need it.
Now, creating a user is super straight-forward:
ludus --url https://127.0.0.1:8081 user add -a -n SCCM -i SCCM
That’s it. The -a flag is for adding the user to the admin group. Why am I using some weird-localhost URL? Because you need to use the admin API endpoint on port 8081 instead of the regular API endpoint on port 8080.
In my case, I’m already connected to the Ludus server itself because it sits directly on the proxmox box I SSH into, hence the localhost portion, duh? It’s right there, listening locally for me to use, so I do not need to SSH and perform local port forwarding. Makes sense? Good.
Anything related to that range will be managed by the SCCM user.
An API KEY will be spit out. Save the KEY in your vault.
Export the API KEY into a temporary variable:
export LUDUS_API_KEY="SCCM.IgI...gD"
Then, you can add the ludus_sccm role to your Ansible collection:
ludus ansible collection add synzack.ludus_sccm
Yeah, in case is wasn’t clear, Ludus is powered by Ansible, an open-source automation tool that simplifies the deployment and management of your IT infrastructure. If you had never heard of ansible before, well first off — what’s the weather like under your rock? Ansible has been around since 2012. Basically, ansible handles all the tedious stuff for you. It deploys and configures your inventory in a repeatable, programmatic and systematic manner so you can stop babysitting your servers and spend more time with your loved ones.
Now you’re going to create a YAML file and paste the YAML configuration from here into it.
There is an important lesson I learned the hard way. I made this mistake so you don’t have to, so I recommend you keep reading. If, like me, you are not using the default local storage for your ISOs in Proxmox, you must explicitly specify the ISO location inside the YAML file. If you don’t, the installation will fail during the build of sccm-sitesrv. The rest of the installation will proceed without issues, but this particular step will cause problems. I’m not entirely sure why only this one is affected. Make sure your YAML file includes an entry for your range that points to the exact location of the ISO file on your disk. If this is unclear, check the official repository documentation for guidance. Personally, I downloaded the ISO from this link. I’m not certain if the version must be same-same, but since I could get the same version, I went with it.
You also need telling Ludus that config-sccm.yml is the config file to be using for the deployment of the range:
ludus range config set -f config-sccm.yml
You deploy the range like so:
ludus range deploy
If you don’t have anything better to do with your time you can monitor progress:
ludus range logs -f
In total, 6 machines will be deployed. It’s gonna take a while, so go outside touch grass in the meantime.
Eventually, all machines will be deployed.
Alright, that’s all nice and cute, but how do you turn that off? First, you want to create a local variable for the SCCM user:
export LUDUS_API_KEY="SCCM.IgIa...CgD"
Then, you can turn the range ON/OFF, depending on your need:
# POWER ON
ludus power on -n all
# POWER OFF
ludus power off -n all
That’s it. You can check the status of the range with:
ludus range status
Don’t get all emotional if you see ERROR in the output. I get those all the time and quite frankly I don’t know what triggers those. Yet, everything is working smoothly.
That’s where our lives are parting away, for now.