First, you need a server. You can't really learn about administering a remote Linux server without having one of your own - so today we're going to buy one!
Through the magic of Linux and virtualization, it's now possible to get a small Internet server setup almost instantly - and at very low cost. Technically, what you'll be doing is creating and renting a VPS ("Virtual Private Server"). In a datacentre somewhere, a single physical server running Linux will be split into a dozen or more Virtual servers, using the KVM (Kernel-based Virtual Machine) feature that's been part of Linux since early 2007.
In addition to a hosting provider, we also need to choose which "flavour" of Linux to install on our server. If you're new to Linux then the range of "distributions" available can be confusing - but the latest LTS ("Long Term Support") version of Ubuntu Server is a popular choice, and what you'll need for this course.
Signing up with a VPS
Sign-up is immediate - just provide your email address and a password of your choosing and you're in! To be able to create a VM, however, you may need to provide your credit card information (or other information for billing) in the account section.
The process is basically the same for all these VPS, but here some step-by-steps:
VM with Digital Ocean (or Droplet)
Choose "Manage, Droplets" from the left-hand sidebar. (a "droplet" is Digital Ocean's cute name for a server!)
Click on Create > Droplet
Choose Region: choose the one closes to you. Be aware that the pricing can change depending on the region.
DataCenter: use the default (it will pick one for you)
Choose an image: Select the image "Ubuntu" and opt for the latest LTS version
Choose Size: Basic Plan (shared CPU) + Regular. Click the option with 1GB Mem / 1 CPU / 25GB SSD Disk
Choose Authentication Method: choose "Password" and type a strong password for the root account.
Note that since the server is on the Internet it will be under immediate attack from bots attempting to "brute force" the root password. Make it strong!
Choose a hostname because the default ones are pretty ugly.
Create Droplet
VM with Linode (or Node)
Click on Create Linode (a "linode" is Linode's cute name for a server)
Choose an Distribution: Select the image "Ubuntu" and opt for the latest LTS version
Choose Region: choose the one closest to you. Be aware that the pricing can change depending on the region.
Linode Plan: Shared CPU + Nanode 1GB. This option has 1GB Mem / 1 CPU / 25GB SSD Disk
Linode Label: Choose a hostname because the default ones are pretty ugly.
Choose Authentication Method: on the "Root Password" and type a strong password for the root account.
Note that since the server is on the Internet it will be under immediate attack from bots attempting to "brute force" the root password. Make it strong!
You should see a "Public IPv4 address" (or similar) entry for your server in account's control panel, this is its unique Internet IP address, and it is how you'll connect to it via SSH (the Secure Shell protocol) - something we'll be covering in the first lesson.
Digital Ocean: Click on Networking tab > Public Network > Public IPv4 Address
Linode: Click on Network tab > IP Addresses > IPv4 - Public
Vultr: Click on Settings tab > Public Network > Address
If you are using Windows 10 or 11, follow the instructions to connect using the native SSH client. In older versions of Windows, you may need to install a 3rd party SSH client, like PuTTY and generate a ssh key-pair.
If you are on Linux or MacOS, open a terminal and run the command:
ssh username@ip_address
Or, using the SSH private key, ssh -i private_key username@ip_address
Enter your password (or a passphrase, if your SSH key is protected with one)
Voila! You have just accessed your server remotely.
If in doubt, consult the complementary video that covers a lot of possible setups (local server with VirtualBox, AWS, Digital Ocean, Azure, Linode, Google Cloud, Vultr and Oracle Cloud).
Creating a working admin account
We want to follow the Best Practice of not logging as "root" remotely, so we'll create an ordinary user account, but one with the power to "become root" as necessary, like this:
adduser snori74
usermod -a -G admin snori74
usermod -a -G sudo snori74
(Of course, replace 'snori74' with your name!)
This will be the account that you use to login and work with your server. It has been added to the 'adm' and 'sudo' groups, which on an Ubuntu system gives it access to read various logs and to "become root" as required via the sudo command.
Confirm that you can do administrative tasks by typing:
sudo apt update
Then:
sudo apt upgrade -y
Don't worry too much about the output and messages from these commands, but it should be clear whether they succeeded or not. (Reply to any prompts by taking the default option). These commands are how you force the installation of updates on an Ubuntu Linux system, and only an administrator can do them.
REBOOT
When a kernel update is identified in this first check for updates, this is one of the few occasions you will need to reboot your server, so go for it after the update is done:
sudo reboot now
Your server is now all set up and ready for the course!
Note that:
This server is now running, and completely exposed to the whole of the Internet
You alone are responsible for managing it
You have just installed the latest updates, so it should be secure for now
To logout, type logout or exit.
When you are done
You should be safe running the VM during the month for the challenge, but you can Stop the instance at any point. It will continue to count to the bill, though.
When you no longer need the VM, Terminate/Destroy instance.
Now you are ready to start the challenge. Day 1, here we go!
Unfortunately Oracle is known to (seemingly at random) shut down free OCI accounts without notice. But it's good for something like this where data loss or service interuption isn't a big deal.
I've heard that, but have difficulty understanding how that would happen.
I guess I could see running a free trial (as opposed to free tier) without payment information getting locked, but anything marked "always free" should continue indefinitely.
The worst that's ever happened to me was that an instance I started and then did nothing with was shutdown after a period of no use. I got an email before that happened and it was just a shutdown, not a lockout or removal. All I had to do to was log in to the console and start it up again when I was ready to move forward.