• Complementary video

INTRO

Linux has a rich set of features for running scheduled tasks. One of the key attributes of a good sysadmin is getting the computer to do your work for you (sometimes misrepresented as laziness!) - and a well configured set of scheduled tasks is key to keeping your server running well.

CRON

Each user potentially has their own set of scheduled task which can be listed with the crontab command (list out your user crontab entry with crontab -l and then that for root with sudo crontab -l ).

However, there’s also a system-wide crontab defined in /etc/crontab - use less to look at this. Here's example, along with an explanation:

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
17 *	* * *   root	cd / && run-parts --report /etc/cron.hourly
25 6	* * *   root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6	* * 7   root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6	1 * *   root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

Lines beginning with "#" are comments, so # m h dom mon dow user command defines the meanings of the columns.

Although the detail is a bit complex, it's pretty clear what this does. The first line says that at 17mins after every hour, on every day, the credential for "root" will be used to run any scripts in the /etc/cron.hourly folder - and similar logic kicks off daily, weekly and monthly scripts. This is a tidy way to organise things, and many Linux distributions use this approach. It does mean we have to look in those /etc/cron.* folders to see what’s actually scheduled.

On your system type: ls /etc/cron.daily - you'll see something like this:

$ ls /etc/cron.daily
apache2  apt  aptitude  bsdmainutils  locate  logrotate  man-db  mlocate  standard  sysklog

Each of these files is a script or a shortcut to a script to do some regular task, and they're run in alphabetic order by run-parts. So in this case apache2 will run first. Use less to view some of the scripts on your system - many will look very complex and are best left well alone, but others may be just a few lines of simple commands.

Look at the articles in the resources section - you should be aware of at and anacron but are not likely to use them in a server.

Google for "logrotate", and then look at the logs in your own server to see how they've been "rotated".

SYSTEMD TIMERS

All major Linux distributions now include "systemd". As well as starting and stopping services, this can also be used to run tasks at specific times via "timers". See which ones are already configured on your server with:

systemctl list-timers

Use the links in the RESOURCES section to read up about how these timers work.

RESOURCES

• A good overview of systemd/Timers
• "How to Use Systemd Timers as a Cron Replacement"
• Automate system administration tasks by scheduling jobs
• Using cron to automate maintenance

Some rights reserved. Check the license terms here

• Complementary video

INTRO

The two services your server is now running are sshd for remote login, and apache2 for web access. These are both "open to the world" via the TCP/IP “ports” - 22 and 80.

As a sysadmin, you need to understand what ports you have open on your servers because each open port is also a potential focus of attacks. You need to be be able to put in place appropriate monitoring and controls.

INSTRUCTIONS

First we'll look at a couple of ways of determining what ports are open on your server:

• ss - this, "socket status", is a standard utility - replacing the older netstat
• nmap - this "port scanner" won't normally be installed by default

There are a wide range of options that can be used with ss, but first try: ss -ltpn

The output lines show which ports are open on which interfaces:

sudo ss -ltp
State   Recv-Q  Send-Q   Local Address:Port     Peer Address:Port  Process
LISTEN  0       4096     127.0.0.53%lo:53        0.0.0.0:*      users:(("systemd-resolve",pid=364,fd=13))
LISTEN  0       128            0.0.0.0:22           0.0.0.0:*      users:(("sshd",pid=625,fd=3))
LISTEN  0       128               [::]:22              [::]:*      users:(("sshd",pid=625,fd=4))
LISTEN  0       511                  *:80                *:*      users:(("apache2",pid=106630,fd=4),("apache2",pid=106629,fd=4),("apache2",pid=106627,fd=4))

The network notation can be a little confusing, but the lines above show ports 80 and 22 open "to the world" on all local IP addresses - and port 53 (DNS) open only on a special local address.

Now install nmap with apt install. This works rather differently, actively probing 1,000 or more ports to check whether they're open. It's most famously used to scan remote machines - please don't - but it's also very handy to check your own configuration, by scanning your server:

$ nmap localhost

Starting Nmap 5.21 ( http://nmap.org ) at 2013-03-17 02:18 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00042s latency).
Not shown: 998 closed ports
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 0.08 seconds

Port 22 is providing the ssh service, which is how you're connected, so that will be open. If you have Apache running then port 80/http will also be open. Every open port is an increase in the "attack surface", so it's Best Practice to shut down services that you don't need.

Note that however that "localhost" (127.0.0.1), is the loopback network device. Services "bound" only to this will only be available on this local machine. To see what's actually exposed to others, first use the ip a command to find the IP address of your actual network card, and then nmap that.

Host firewall

The Linux kernel has built-in firewall functionality called "netfilter". We configure and query this via various utilities, the most low-level of which are the iptables command, and the newer nftables. These are powerful, but also complex - so we'll use a more friendly alternative - ufw - the "uncomplicated firewall".

First let's list what rules are in place by typing sudo iptables -L

You will see something like this:

Chain INPUT (policy ACCEPT)
target  prot opt source             destination

Chain FORWARD (policy ACCEPT)
target  prot opt source             destination

Chain OUTPUT (policy ACCEPT)
target  prot opt source             destination

So, essentially no firewalling - any traffic is accepted to anywhere.

Using ufw is very simple. It is available by default in all Ubuntu installations after 8.04 LTS, but if you need to install it:

sudo apt install ufw

Then, to allow SSH, but disallow HTTP we would type:

sudo ufw allow ssh
sudo ufw deny http

(BEWARE - do not “deny” ssh, or you’ll lose all contact with your server!)

and then enable this with:

sudo ufw enable

Typing sudo iptables -L now will list the detailed rules generated by this - one of these should now be:

“DROP       tcp  --  anywhere             anywhere             tcp dpt:http”

The effect of this is that although your server is still running Apache, it's no longer accessible from the "outside" - all incoming traffic to the destination port of http/80 being DROPed. Test for yourself! You will probably want to reverse this with:

sudo ufw allow http
sudo ufw enable

In practice, ensuring that you're not running unnecessary services is often enough protection, and a host-based firewall is unnecessary, but this very much depends on the type of server you are configuring. Regardless, hopefully this session has given you some insight into the concepts.

BTW: For this test/learning server you should allow http/80 access again now, because those access.log files will give you a real feel for what it's like to run a server in a hostile world.

Using non-standard ports

Occasionally it may be reasonable to re-configure a service so that it’s provided on a non-standard port - this is particularly common advice for ssh/22 - and would be done by altering the configuration in /etc/ssh/sshd_config

Some call this “security by obscurity” - equivalent to moving the keyhole on your front door to an unusual place rather than improving the lock itself, or camouflaging your tank rather than improving its armour - but it does effectively eliminate attacks by opportunistic hackers, which is the main threat for most servers.

POSTING YOUR PROGRESS

• As always, feel free to post your progress, or questions, to the forum.

EXTENSION

Even after denying access, it might be useful to know who's been trying to gain entry. Check out these discussions of logging and more complex setups:

• How to Log Linux IPTables Firewall Dropped Packets to a Log File
• Iptables How To

RESOURCES

• 12 ss Command Examples to Monitor Network Connections
• UFW - Uncomplicated Firewall
• Collection of basic Linux Firewall iptables rules
• 10 Netstat Command Example
• UFW Uncomplicated Firewall (video)
• How to install nftables in Ubuntu
• No, moving your ssh port isn't security by obscurity

Some rights reserved. Check the license terms here

• Complementary video

INTRO

Your server is now running two services: the sshd (Secure Shell Daemon) service that you use to login; and the Apache2 web server. Both of these services are generating logs as you and others access your server - and these are text files which we can analyse using some simple tools.

Plain text files are a key part of "the Unix way" and there are many small "tools" to allow you to easily edit, sort, search and otherwise manipulate them. Today we’ll use grep, cat, more, less, cut, awk and tail to slice and dice your logs.

The grep command is famous for being extremely powerful and handy, but also because its "nerdy" name is typical of Unix/Linux conventions.

TASKS

• Dump out the complete contents of a file with cat like this: cat /var/log/apache2/access.log
• Use less to open the same file, like this: less /var/log/apache2/access.log - and move up and down through the file with your arrow keys, then use “q” to quit.
• Again using less, look at a file, but practice confidently moving around using gg, GG and /, n and N (to go to the top of the file, bottom of the file, to search for something and to hop to the next "hit" or back to the previous one)
• View recent logins and sudo usage by viewing /var/log/auth.log with less
• Look at just the tail end of the file with tail /var/log/apache2/access.log (yes, there's also a head command!)
• Follow a log in real-time with: tail -f /var/log/apache2/access.log (while accessing your server’s web page in a browser)
• You can take the output of one command and "pipe" it in as the input to another by using the | (pipe) symbol
• So, dump out a file with cat, but pipe that output to grep with a search term - like this: cat /var/log/auth.log | grep "authenticating"
• Simplify this to: grep "authenticating" /var/log/auth.log
• Piping allows you to narrow your search, e.g. grep "authenticating" /var/log/auth.log | grep "root"
• Use the cut command to select out most interesting portions of each line by specifying "-d" (delimiter) and "-f" (field) - like: grep "authenticating" /var/log/auth.log| grep "root"| cut -f 10- -d" " (field 10 onwards, where the delimiter between field is the " " character). This approach can be very useful in extracting useful information from log data.
• Use the -v option to invert the selection and find attempts to login with other users: grep "authenticating" /var/log/auth.log| grep -v "root"| cut -f 10- -d" "

The output of any command can be "redirected" to a file with the ">" operator. The command: ls -ltr > listing.txt wouldn't list the directory contents to your screen, but instead redirect into the file "listing.txt" (creating that file if it didn't exist, or overwriting the contents if it did).

POSTING YOUR PROGRESS

Re-run the command to list all the IP's that have unsuccessfully tried to login to your server as root - but this time, use the the ">" operator to redirect it to the file: ~/attackers.txt. You might like to share and compare with others doing the course how heavily you're "under attack"!

EXTENSION

• See if you can extend your filtering of auth.log to select just the IP addresses, then pipe this to sort, and then further to uniq to get a list of all those IP addresses that have been "auditing" your server security for you.
• Investigate the awk and sed commands. When you're having difficulty figuring out how to do something with grep and cut, then you may need to step up to using these. Googling for "linux sed tricks" or "awk one liners" will get you many examples.
• Aim to learn at least one simple useful trick with both awk and sed

RESOURCES

• Text processing commands
• OSTechNix grep tutorial
• Where GREP came from

Some rights reserved. Check the license terms here

• Complementary video

INTRO

Today you'll install a common server application - the Apache2 web server - also known as httpd - the "Hyper Text Transport Protocol Daemon"!

If you’re a website professional then you might do things slightly differently, but our focus with this is not on Apache itself, or the website content, but to get a better understanding of:

• application installation
• configuration files
• services
• logs

TASKS

• Refresh your list of available packages (apps) by: sudo apt update - this takes a moment or two, but ensures that you'll be getting the latest versions.
• Install Apache from the repository with a simple: sudo apt install apache2
• Confirm that it’s running by browsing to http://[external IP of your server] - where you should see a confirmation page.
• Apache is installed as a "service" - a program that starts automatically when the server starts and keeps running whether anyone is logged in or not. Try stopping it with the command: sudo systemctl stop apache2 - check that the webpage goes dead - then re-start it with sudo systemctl start apache2 - and check its status with: systemctl status apache2.
• As with the vast majority of Linux software, configuration is controlled by files under the /etc directory - check the configuration files under /etc/apache2 especially /etc/apache2/apache2.conf - you can use less to simply view them, or the vim editor to view and edit as you wish.
• In /etc/apache2/apache2.conf there's the line with the text: "IncludeOptional conf-enabled/*.conf". This tells Apache that the *.conf files in the subdirectory conf-enabled should be merged in with those from /etc/apache2/apache2.conf at load. This approach of lots of small specific config files is common.
• If you're familiar with configuring web servers, then go crazy, setup some virtual hosts, or add in some mods etc.
• The location of the default webpage is defined by the DocumentRoot parameter in the file /etc/apache2/sites-enabled/000-default.conf.
• Use less or vim to view the code of the default page - normally at /var/www/html/index.html. This uses fairly complex modern web design - so you might like to browse to http://165.227.92.20/sample where you'll see a much simpler page. Use View Source in your browser to see the code of this, copy it, and then, in your ssh session sudo vim /var/www/html/index.html to first delete the existing content, then paste in this simple example - and then edit to your own taste. View the result with your workstation browser by again going to http://[external IP of your server]
• As with most Linux services, Apache keeps its logs under the /var/log directory - look at the logs in /var/log/apache2 - in the access.log file you should be able to see your session from when you browsed to the test page. Notice that there's an overwhelming amount of detail - this is typical, but in a later lesson you'll learn how to filter out just what you want. Notice the error.log file too - hopefully this one will be empty!

Posting your progress

Practice your text-editing skills, and allow your "classmates" to judge your progress by editing /var/www/html/index.html with vim and posting the URL to access it to the forum. (It doesn’t have to be pretty!)

Security

• As the sysadmin of this server, responsible for its security, you need to be very aware that you've now increased the "attack surface" of your server. In addition to ssh on port 22, you are now also exposing the apache2 code on port 80. Over time the logs may reveal access from a wide range of visiting search engines, and attackers - and that’s perfectly normal.
• If you run the commands: sudo apt update, then sudo apt upgrade, and accept the suggested upgrades, then you'll have all the latest security updates, and be secure enough for a test environment - but you should re-run this regularly.

EXTENSION

Read up on:

• Using systemctl to manage services

RESOURCES

• HTTPD - Apache2 Web Server
• The Apache HTTP Server

Some rights reserved. Check the license terms here

• Complementary video

INTRO

Simple text files are at the heart of Linux, so editing these is a key sysadmin skill. There are a range of simple text editors aimed at beginners. Some more common examples you'll see are nano and pico. These look as if they were written for DOS back in the 1980's - but are pretty easy to "just figure out".

The Real Sysadmintm however, uses vi - this is the editor that's always installed by default - and today you'll get started using it.

Bill Joy wrote Vi back in the mid 1970's - and even the "modern" Vim that we'll concentrate on is over 20 years old, but despite their age, these remain the standard editors on command-line server boxes. Additionally, they have a loyal following among programmers, and even some writers. Vim is actually a contraction of Vi IMproved and is a direct descendant of Vi.

Very often when you type vi, what the system actually starts is vim. To see if this is true of your system type, run:

vi --version

You should see output similar to the following if the vi command is actually symlinked to vim:

user@testbox:~$ vi --version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Oct 01 2021 01:51:08)
Included patches: 1-2434
Extra patches: 8.2.3402, 8.2.3403, 8.2.3409, 8.2.3428
Modified by [email protected]
Compiled by [email protected]
...

WHAT IF I DON'T HAVE VIM INSTALLED?

The rest of this lesson assumes that you have vim installed on your system, which it often is by default. But in some cases it isn't and if you try to run the vim commands below you may get an error like the following:

user@testbox:~$ vim
-bash: vim: command not found

OPTION 1 - ALIAS VIM

One option is to simply substitute vi for any of the vim commands in the instructions below. Vim is reverse compatible with Vi and all of the below exercises should work the same for Vi as well as for Vim. To make things easier on ourselves we can just alias the vim command so that vi runs instead:

echo "alias vim='vi'" >> ~/.bashrc
source ~/.bashrc

OPTION 2 - INSTALL VIM

The other option, and the option that many sysadmins would probably take is to install Vim if it isn't installed already.

To install Vim on Ubuntu using the system package manager, run:

sudo apt install vim

Note: Since Ubuntu Server LTS is the recommended Linux distribution to use for the Linux Upskill Challenge, installing Vim for all of the other various Linux "distros" is outside of the scope of this lesson. The command above "should" work for most Debian-family Linux OS's however, so if you're running Mint, Debian, Pop!_OS, or one of the many other flavors of Ubuntu, give it a try. For Linux distros outside of the Debian-family a few simple web-searches will probably help you find how to install Vim using other Linux's package managers.

THE TWO THINGS YOU NEED TO KNOW

• There are two "modes" - with very different behaviours
• Little or nothing onscreen lets you know which mode you're currently in!

The two modes are "normal mode" and "insert mode", and as a beginner, simply remember:

"Press Esc twice or more to return to normal mode"

The "normal mode" is used to input commands, and "insert mode" for writing text - similar to a regular text editor's default behaviour.

INSTRUCTIONS

So, first grab a text file to edit. A copy of /etc/services will do nicely:

cd
pwd
cp -v /etc/services testfile
vim testfile

At this point we have the file on screen, and we are in "normal mode". Unlike nano, however, there’s no onscreen menu and it's not at all obvious how anything works!

Start by pressing Esc once or twice to ensure that we are in normal mode (remember this trick from above), then type :q! and press Enter. This quits without saving any changes - a vital first skill when you don't yet know what you're doing! Now let's go in again and play around, seeing how powerful and dangerous vim is - then again, quit without saving:

vim testfile

Use the keys h j k and l to move around (this is the traditional vi method) then try using the arrow keys - if these work, then feel free to use them - but remember those hjkl keys because one day you may be on a system with just the traditional vi and the arrow keys won't work.

Now play around moving through the file. Then exit with Esc Esc :q! as discussed earlier.

Now that you've mastered that, let's get more advanced.

vim testfile

This time, move down a few lines into the file and press 3 then 3 again, then d and d again - and suddenly 33 lines of the file are deleted!

Why? Well, you are in normal mode and 33dd is a command that says "delete 33 lines". Now, you're still in normal mode, so press u - and you've magically undone the last change you made. Neat huh?

Now you know the three basic tricks for a newbie to vim:

• Esc Esc always gets you back to "normal mode"
• From normal mode :q! will always quit without saving anything you've done, and
• From normal mode u will undo the last action

So, here's some useful, productive things to do:

• Finding things: From normal mode, type G to get to the bottom of the file, then gg to get to the top. Let's search for references to "sun", type /sun to find the first instance, hit enter, then press n repeatedly to step through all the next occurrences. Now go to the top of the file (gg remember) and try searching for "Apple" or "Microsoft".
• Cutting and pasting: Go back up to the top of the file (with gg) and look at the first few lines of comments (the ones with "#" as the first character). Play around with cutting some of these out, and pasting them back. To do this simply position the cursor on a line, then (for example), type 11dd to delete 11 lines, then immediately paste them back in by pressing P - and then move down the file a bit and paste the same 11 lines in there again with P
• Inserting text: Move anywhere in the file and press i to get into "insert mode" (it may show at the bottom of the screen) and start typing - and Esc Esc to get back into normal mode when you're done.
• Writing your changes to disk: From normal mode type :w to "write" but stay in vim, or :wq to “write and quit”.

This is as much as you ever need to learn about vim - but there's an enormous amount more you could learn if you had the time. Your next step should be to run vimtutor and go through the "official" Vim tutorial. It typically takes around 30 minutes the first time through. To solidify your Vim skills make a habit of running through the vimtutor every day for 1-2 weeks and you should have a solid foundation with the basics.

Note: If you aliased vim to vi for the excercises above, now might be a good time to install vim since this is what provides the vimtutor command. Once you have Vim installed, you can run :help vimtutor from inside of Vim to view the help as well as a few other tips/tricks.

However, if you're serious about becoming a sysadmin, it's important that you commit to using vim (or vi) for all of your editing from now on.

One last thing, you may see reference to is the Vi vs. Emacs debate. This is a long running rivalry for programmers, not system administrators - vi/vim is what you need to learn.

WHY CAN'T I JUST STICK WITH NANO?

• In many situations as a professional, you'll be working on other people's systems, and they're often very paranoid about stability. You may not have the authority to just "sudo apt install " - even if technically you could.

• However, vi is always installed on any Unix or Linux box from tiny IoT devices to supercomputer clusters. It is actually required by the Single Unix Specification and POSIX.

• And frankly it's a shibboleth for Linux pros. As a newbie in an interview it's fine to say you're "only a beginner with vi/vim" - but very risky to say you hate it and can never remember how to exit.

So, it makes sense if you're aiming to do Linux professionally, but if you're just working on your own systems then by all means choose nano or pico etc.

EXTENSION

If you're already familiar with vi / vim then use today's hour to research and test some customisation via your ~/.vimrc file. The link below is specifically for sysadmins:

• Getting more out of Vim

RESOURCES

• Here is why vim uses the hjkl keys as arrow keys
• Graphical vi-vim Cheat Sheet and Tutorial
• Vi - Vim Tutorial (video)
• How to Copy, Cut and Paste in Vim / Vi

Some rights reserved. Check the license terms here

• Complementary video

INTRO

Today we'll end with a bang - with a quick introduction to five different topics. Mastery isn't required today - you'll be getting plenty of practice with all these in the sessions to come!

Don’t be misled by how simplistic some of these commands may seem - they all have hidden depths and many sysadmins will be using several of these every day.

TASKS

Use the links in the Resources section to complete these tasks:

• Get familiar with using more and less for viewing files, including being able to get to the top or bottom of a file in less, and searching for some text

• Test how “tab completion” works - this is a handy feature that helps you enter commands correctly. It helps find both the command and also file name parameters (so typing les then hitting “Tab” will complete the command less, but also typing less /etc/serv and pressing “Tab” will complete to less /etc/services. Try typing less /etc/s then pressing “Tab”, and again, to see how the feature handles ambiguity.

• Now that you've typed in quite a few commands, try pressing the “Up arrow” to scroll back through them. What you should notice is that not only can you see your most recent commands - but even those from the last time you logged in. Now try the history command - this lists out the whole of your cached command history - often 100 or more entries. There are number of clever things that can be done with this. The simplest is to repeat a command - pick one line to repeat (say number 20) and repeat it by typing !20 and pressing “Enter”. Later when you'll be typing long, complex, commands this can be very handy. You can also press Ctrl + r, then start typing any part of the command that you are looking for. You'll see an autocomplete of a past command at your prompt. If you keep typing, you'll get more specific options appear. You can either run it by pressing return, or editing it first by pressing arrows or other movement keys. You can also keep pressing Ctrl + r to see other instances of the same command you used with different options.

• Look for “hidden” files in your home directory. In Linux the convention is simply that any file starting with a "." character is hidden. So, type cd to return to your "home directory" then ls -l to show what files are there. Now type ls -la or ls -ltra (the "a" is for "all") to show all the files - including those starting with a dot. By far the most common use of "dot files" is to keep personal settings in a home directory. So use your new skills with less to look at the contents of .bashrc , .bash_history and others.

• Finally, use the nano editor to create a file in your home directory and type up a summary of how the last five days have worked for you.

RESOURCES

• Unix Less Command: 10 Tips for Effective Navigation
• How To Use Bash History Commands and Expansions...
• BASH Shell commands less
• Tab completion
• What are dotfiles?
• Nano editor tutorials

Some rights reserved. Check the license terms here

• Complementary video

INTRO

As a sysadmin, one of your key tasks is to install new software as required. You’ll also need to be very familiar with the layout of the standard directories in a Linux system.

You’ll be getting practice in both of these areas in today’s session.

Your tasks today

• Install a new application from the online repositories
• Become familiar with some of the standard directories
• Look at the format and content of some configuration files.

If you've used a smartphone "app store " or "market", then you'll immediately understand the normal installation of Linux software from the standard repositories. As long as we know what the name or description of a package (=app) is, then we can search for it:

 apt search "midnight commander"

This will show a range of matching "packages", and we can then install them with apt install command. So to install package mc (Midnight Commander) on Ubuntu:

 sudo apt install mc

(Unless you're already logged in as the root user you need to use sudo before the installation commands - because an ordinary user is not permitted to install software that could impact a whole server).

Now that you have mc installed, start it by simply typing mc and pressing Enter.

This isn't a "classic" Unix application, but once you get over the retro interface you should find navigation fairly easy, so go looking for these directories:

/root /home /sbin /etc /var/log

...and use the links in the Resources section below to begin to understand how these are used. You can also read the official manual on this hierarchy by typing man hier.

Most key configuration files are kept under /etc and subdirectories of that. These files, and the logs under /var/log are almost invariably simple text files. In the coming days you'll be spending a lot of time with these - but for now simply use F3 to look into their contents.

Some interesting files to look at are: /etc/passwd, /etc/ssh/sshd_config and /var/log/auth.log

Use F3 again to exit from viewing a file.

F10 will exit mc, although you may need to use your mouse to select it.

(On an Apple Mac in Terminal, you may need to use ESC+3 to get F3 and ESC+0 for F10)

Now use apt search to search for and install some more packages: Try searching for “hangman”. You will probably find that an old text-based version is included in a package called bsdgames. Install and play a couple of rounds...

Posting your progress

• Post your progress, comments and questions to the forum.

EXTENSION

• Use mc to view /etc/apt/sources.list where the actual locations of the repositories are specified. Often these will be “mirror” sites that are closer to your server than the main Ubuntu servers.
• Read Repositories - CommandLine for more of the gory details.

RESOURCES

• Difference Between apt and apt-get Explained
• DNF vs APT: Similarities and Differences Analyzed!
• Ubuntu Server Guide - Package Management
• Midnight Commander vs Ranger
• Linux directory system explained

Some rights reserved. Check the license terms here

• Complementary video

INTRO

You've been logging in as an ordinary user at your server, yet you're probably aware that root is the power user on a Linux system. This administrative or "superuser" account, is all powerful - and a typo in a command could potentially cripple your server. As a sysadmin you're typically working on systems that are both important and remote, so avoiding such mistakes is A Very Good Idea.

On many older production systems all sysadmins login as “root”, but it’s now common Best Practice to discourage or disallow login directly by root - and instead to give specified trusted users the permission to run root-only commands via the sudo command.

This is the way that your server has been set-up, with your “ordinary” login given the ability to run any root-only command - but only if you precede it with sudo.

(Normally on an Ubuntu system this will ask you to re-confirm your identity with your password. However, the standard AWS Ubuntu Server image does not prompt for a password).

YOUR TASKS TODAY:

• Use the links in the "Resources" section below to understand how sudo works
• Use ls -l to check the permissions of /etc/shadow - notice that only root has any access. Can you use cat, less or nano to view it?
• This file is where the hashed passwords are kept. It is a prime target for intruders - who aim to grab it and use offline password crackers to discover the passwords.
• Now try with sudo, e.g. sudo less /etc/shadow
• Test running the reboot command, and then via sudo (i.e. sudo reboot)

Once you've reconnected back:

• Use the uptime command to confirm that your server did actually fully restart
• Test fully “becoming root” by the command sudo -i This can be handy if you have a series of commands to do "as root". Note the change to your prompt.
• Type exit or logout to get back to your own normal “support” login.
• Use less to view the file /var/log/auth.log, where any use of sudo is logged
• You could "filter" this by typing: grep "sudo" /var/log/auth.log

If you wish to, you can now rename your server. Traditionally you would do this by editing two files, /etc/hostname and /etc/hosts and then rebooting - but the more modern, and recommended, way is to use the hostnamectl command; like this:

sudo hostnamectl set-hostname mylittlecloudbox

No reboot is required.

For a cloud server, you might find that the hostname changes after a reboot. To prevent this, edit /etc/cloud/cloud.cfg and change the "preserve_hostname" line to read:

preserve_hostname: true

You might also consider changing the timezone your server uses. By default this is likely to be UTC (i.e. GMT) - which is pretty appropriate for a worldwide fleet of servers. You could also set it to the zone the server is in, or where you and your headquarters are. For a company this is a decision not to be taken lightly, but for now you can simply change as you please!

First check the current setting with:

timedatectl

Then get a a list of available timezones:

timedatectl list-timezones

And finally select one, like this:

sudo timedatectl set-timezone Australia/Sydney

Confirm:

timedatectl

The major practical effects of this are (1) the timing of scheduled tasks, and (2) the timestamping of the logs files kept under /var/log. If you make a change, there will naturally be a "jump" in the dates and time recorded.

WRAP

As a Linux sysadmin you may be working on client or custom systems where you have little control, and many of these will default to doing everything as root. You need to be able to safely work on such systems - where your only protection is to double check before pressing Enter.

On the other hand, for any systems where you have full control, setting up a "normal" account for yourself (and any co-admins) with permission to run sudo is recommended. While this is standard with Ubuntu, it's also easy to configure with other popular server distros such as Debian, CentOS and RHEL.

A NOTE ON "HARDENING"

Your server is protected by the fact that its security updates are up to date, and that you've set Long Strong Unique passwords - or are using public keys. While exposed to the world, and very likely under continuous attack, it should be perfectly secure. Next week we'll look at how we can view those attacks, but for now it's simply important to state that while it's OK to read up on "SSH hardening", things such as changing the default port and fail2ban are unnecessary and unhelpful when we're trying to learn - and you are perfectly safe without them.

EXTENSION

• Hardening SSH
• How To Set Up Multi-Factor Authentication for SSH on Ubuntu 16.04

RESOURCES

• This cartoon explains it nicely!
• Sudo in Ubuntu
• How to use "sudo"
• This is how password cracking is done

Some rights reserved. Check the license terms here

Customising PS1 to Include a Shell Script

Today – instead of making actual progress in the course – I got lost in the supplementary reading about setting yourself up with a custom prompt. Since most shells come pre-configured with many of the ideas of the blog post already implemented, the only option that really caught my attention was using a shell script inside the PS1 variable. The example given was a script to count the size of regular files in the current directory and show it next to the prompt. I was more interested in the total size of the current directory, including all files in subdirectories, so I set out to try that. This post is more of an answer to the call to post one's progress, than an actual offer of useful code, since I still don't deem having the filesize shown important enough to incorporate into my personal prompt.

Step by Step to a Prompt Which Displays File Size

Finished Product First

All this produces is a simple addendum to the prompt, displaying the size of the files in the current directory and its subdirectories. Can be placed anywhere in the custom prompt:

[X bytes]

The Bash Script

To achieve this, one has to write a bash script to recursively sum up filesizes:

#!/bin/bash

calculate_size() {
  local directory=$1
  local totalsize=0

  for filesize in $(find "$directory" -type f -exec stat -c %s {} \; 2>/dev/null); do
    ((totalsize += filesize))
  done

  for subdir in $(find "$directory" -type d); do
    if [[ "$subdir" != "$directory" ]]; then
      ((totalsize += $(calculate_size "$subdir")))
    fi
  done

  echo "$totalsize"
}

# Usage example
total=$(calculate_size .)
echo "$total bytes"

Adding the Script to PATH

After making the script executable, one has to include the script itself or its folder into PATH. This can be done by including the following line in ~/.bashrc, which is where customisation is done on my Ubuntu LTS server, or in whatever file is the correct one for your distribution.

export PATH="$PATH:/path/to/script.sh" or

export PATH="$PATH:/path/to/scripts/folder"

Customising PS1

Find PS1 in whatever customisation file it is defined in on your system, and add the following snippet anywhere, where you would like the file size to be displayed.

[$(path/to/your/script.sh)]

Notes

• The Bash script was in part written by me with the knowledge I gained from a previous shell scripting course, and in part written and refined by ChatGPT 3.5
• This by no means has to be the most elegant way to calculate total file size, I am new to shell scripting
• There might very well be cases where the script fails due to special characters or other unexpected input, it has no error catching mechanisms
• It could be further refined to show sizes in bytes/kilobytes/megabytes/... according to the total calculated
• Unfortunately, Lemmy does not seem to support syntax highlighting for code blocks

tl;dr

I talked about how to customise the PS1 prompt in a shell to display the total size of files in the current directory and its subdirectories. This is done by creating a Bash script to calculate the total file size and incorporating it into the PS1 variable. The script should be added to the PATH and the PS1 should be modified to display the file size information.

• Complementary video

INTRO

Most computer users outside of the Linux and Unix world don't spend much time at the command-line now, but as a Linux sysadmin this is your default working environment - so you need to be skilled in it.

When you use a graphic desktop such as Windows or Apple's macOS (or even the latest Linux flavors), then increasingly you are presented with simple "places" where your stuff is stored - "Pictures" "Music" etc but if you're even moderately technical then you'll realize that underneath all this is a hierarchical "directory structure" of "folders" (e.g. C:\Users\Steve\Desktop on Windows or /Users/Steve/Desktop on macOS - and on a Desktop Linux system /home/steve/Desktop)

From now on, the course will point you to a range of good online resources for a topic, and then set you a simple set of tasks to achieve. It’s perfectly fine to google for other online resources, refer to any books you have etc - and in fact a fundamental element of the design of this course is to force you to do a bit of your own research. Even the most experienced sysadmins will do an online search to find advice for how to use commands - so the sooner you too get into that habit the better!

YOUR TASKS TODAY

• Use the provided resources to check out the basic commands and concepts
• Login to your server via SSH and move around the directory structure at the command-line
• Take note of how your “prompt” changes as you change directory
• Be sure to understand how cd on its own takes you back to your “home directory”
• Understand what cd ~ and cd .. do
• Use the ls command to list the contents of directories, and try several of the “switches” - in particular ls -ltr to show the most recently altered file last
• Use the mkdir command to create a new directory (folder) test in your home folder ( e.g /home/support/test)

STEP-BY-STEP

• Login to your server using ssh
• / is the "root" of a branching tree of folders (also known as directories)
• At all times you are "in" one part of the system - the command pwd ("print working directory") will show you where you are
• Generally your prompt is also configured to give you at least some of this information, so if I'm "in" the /etc directory then the prompt might be [email protected]:/etc$ or simply /etc: $
• cd moves to different areas - so cd /var/log will take you into the /var/log folder - do this and then check with pwd - and look to see if your prompt changes to reflect your location.
• You can move "up" the structure by typing cd .. ( "cee dee dot dot ") try this out by first cd'ing to /var/log/ then cd .. and then cd .. again - watching your prompt carefully, or typing pwd each time, to clarify your present working directory.
• A "relative" location is based on your present working directory - e.g. if you first cd /var then pwd will confirm that you are "in" /var, and you can move to /var/log in two ways - either by providing the full path with cd /var/log or simply the "relative" path with the command cd log
• A simple cd will always return you to your own defined "home directory", also referred to as ~ (the "tilde" character) [NB: this differs from DOS/Windows]
• What files are in a folder? The ls (list) command will give you a list of the files, and sub folders. Like many Linux commands, there are options (known as "switches") to alter the meaning of the command or the output format. Try a simple ls, then ls -l -t and then try ls -l -t -r -a
• By convention, files with a starting character of "." are considered hidden and the ls, and many other commands, will ignore them. The -a switch includes them. You should see a number of hidden files in your home directory.
• A note on switches: Generally most Linux command will accept one or more "parameters", and one or more "switches". So, when we say ls -l /var/log the "-l" is a switch to say "long format" and the "/var/log" is the "parameter". Many commands accept a large number of switches, and these can generally be combined (so from now on, use ls -ltra, rather than ls -l -t -r -a
• In your home directory type ls -ltra and look at the far left hand column - those entries with a "d" as the first character on the line are directories (folders) rather than files. They may also be shown in a different color or font - if not, then adding the "--color=auto" switch should do this (i.e. ls -ltra --color=auto)
• You can make a new folder/directory with the mkdir command, so move to your home directory, type pwd to check that you are indeed in the correct place, and then create a directory, for example to create one called "test", simply type mkdir test. Now use the ls command to see the result.

RTFM

This is a good time to mention that Linux comes with a fine on-line manual - invoked with the man command. Each application installed comes with its own page in this manual, so that you can look at the page for pwd to see the full detail on the syntax like this:

man pwd

You might also try:

 man cp
 man mv
 man grep
 man ls
 man man

As you’ll see, these are excellent for the detailed syntax of a command, but many are extremely terse, and for others the amount of detail can be somewhat daunting!

WRAP

Being able to move confidently around the directory structure at the command line is important, so don’t think you can skip it! However, these skills are something that you’ll be constantly using over the twenty days of the course, so don’t despair if this doesn’t immediately “click”.

EXTENSION

If this is already something that you’re very familiar with, then:

• Learn about pushd and popd to navigate around multiple directories easily. Running pushd /var/log moves you to to the /var/log, but keeps track of where you were. You can pushd more than one directory at a time. Try it out: pushd /var/log, pushd /dev, pushd /etc, pushd, popd, popd. Note how pushd with no arguments switches between the last two pushed directories but more complex navigation is also possible. Finally, cd - also moves you the last visited directory.
• Take the time today to understand how the environment variable PS1 etc work (this article: Bash Shell: Take Control of PS1, PS2, PS3, PS4 and PROMPT_COMMAND is a good start).
• Set yourself up with a custom prompt using the information in Bash Shell PS1: 10 Examples to Make Your Linux Prompt like Angelina Jolie

RESOURCES

• Explore the Linux file system
• Linux File System
• Simple Terminal Commands on Ubuntu
• Solaris Unix Commands

Some rights reserved. Check the license terms here

• Complementary video
• A short vid on using ssh in a work environment.

INTRO

You should now have a remote server setup running the latest Ubuntu Server LTS (Long Term Support) version. You alone will be administering it. To become a fully-rounded Linux server admin you should become comfortable working with different versions of Linux, but for now Ubuntu is a good choice.

Once you have reached a level of comfort at the command-line then you'll find your skills transfer not only to all the standard Linux variants, but also to Android, Apple's OSX, OpenBSD, Solaris and IBM AIX. Throughout the course you'll be working on Linux - but in fact most of what is covered is applicable to any system in the "UNIX family" - and the major differences between them are with their graphic user interfaces such as Gnome, Unity, KDE etc - none of which you’ll be using!

Although there is a "root" user, you will be logging in and working from the user account that you setup. Because this is a member of the group "sudo" it is able to run commands "as root" by preceding them with "sudo".

YOUR TASKS TODAY:

• Connect and login remotely to your server
• Run a few simple commands to check the status of your server
• Change your password

INSTRUCTIONS

Remote access used to be done by the simple telnet protocol, but now the much more secure SSH (“Secure SHell) protocol is always used.

If you're using any Linux or Unix system, including Apple's MacOS, then you can simply open up a "terminal" session and use your command-line ssh client like this:

ssh user@

For example:

ssh [email protected]

On Linux distributions with a menu you'll typically find the terminal under "Applications menu -> Accessories -> Terminal", "Applications menu -> System -> Terminal" or "Menu -> System -> Terminal Program (Konsole)"- or you can simply search for your terminal application. In many cases Ctrl+Alt+T will also bring up a terminal windows.

If you have configured the remote server with your SSH public key (see "Password-less SSH login" in the EXTENSION section of this post), then you'll need to point to the location of the private part as proof of identity with the "-i" switch, typically like this:

ssh -i ~/.ssh/id_rsa [email protected]

A very slick connection process can be setup with the .ssh/config feature - see the "SSH client configuration" link in the EXTENSION section below.

On an MacOS machine you'll normally access the command line via Terminal.app - it's in the Utilities sub-folder of Applications.

On recent Windows 10 versions, the same command-line client is now available, but must be enabled (via "Settings", "Apps", "Apps & features", "Manage optional features", "Add a feature", "OpenSSH client").

Alternatively, you can install the Windows Subsystem for Linux which gives you a full local command-line Linux environment, including an SSH client - ssh.

There are also GUI SSH clients for Windows (PuTTY, MobaXterm) and MacOS (Terminal.app, iTerm2). If you use Windows versions older than 10, the installation of PuTTY is suggested.

Regardless of which client you use, the first time you connect to your server, you may receive a warning that you're connecting to a new server - and be asked if you wish to "cache the host key". Do this. Now, if you get a warning in future connections it means that either: (a) you are being fooled into connecting to a different machine or (b) someone may be trying a "man in the middle" attack.

So, now login to your server as your user - and remember that Linux is case-sensitive regarding user names, as well as passwords.

Once logged in, notice that the "command prompt" that you receive ends in $ - this is the convention for an ordinary user, whereas the "root" user with full administrative power has a # prompt.

Try these simple commands:

ls

uptime

free

df -h

uname -a

If you're using a password to login (rather than public key), then now is a good time to ensure that this is very strong and unique - i.e. At least 10 characters - because your server is fully exposed to bots that will be continuously attempting to break in. Use the passwd command to change your password. To do this, think of a new, secure password, then simply type passwd, press “Enter” and give your current password when prompted, then the new one you've chosen, confirm it - and then WRITE IT DOWN somewhere. In a production system of course, public keys and/or two factor authentication would be more appropriate.

It's very handy to be able to cut and paste text between your remote session and your local desktop, so spend some time getting confident with how to do this in your setup.

Log out by typing exit.

You'll be spending a lot of time in your SSH client, so it pays to spend some time customizing it. At the very least try "black on white" and "green on black" - and experiment with different monospaced fonts, ("Ubuntu Mono" is free to download, and very nice).

POSTING YOUR PROGRESS

Regularly posting your progress can be a helpful motivator. Feel free to post to the subreddit a small introduction of yourself, and your Linux background for your "classmates" - and notes on how each day has gone.

A discord server is also available.

Of course, also drop in a note if you get stuck or spot errors in these notes.

WRAP

You now have the ability to login remotely to your own server. Perhaps you might now try logging in from home and work - even from your smartphone! - using an ssh client app such as "Termux". As a server admin you'll need to be comfortable logging in from all over. You can also potentially use JavaScript ssh clients (search for "consolefish"), or from a cybercafe - but these options involve putting more trust in third-parties than most sysadmins would be comfortable with when accessing production systems.

A NOTE ON "HARDENING"

Your server is protected by the fact that its security updates are up to date, and that you've set Long Strong Unique passwords - or are using public keys. While exposed to the world, and very likely under continuous attack, it should be perfectly secure. Next week we'll look at how we can view those attacks, but for now it's simply important to state that while it's OK to read up on "SSH hardening", things such as changing the default port and fail2ban are unnecessary and unhelpful when we're trying to learn - and you are perfectly safe without them.

EXTENSION

If this is all too easy, then spend some time reading up on:

• SSH Tunneling
• Password-less SSH login
• SSH client configuration

RESOURCES

• How to Use PuTTY on Windows
• Puttygen command line on Linux - SSH key generator
• Comparing CENTOS and Ubuntu for servers
• A Beginners Guide to SSH

Some rights reserved. Check the license terms here

• Complementary video

INTRO

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 get one - completely free!

Through the magic of Linux and virtualisation, 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 fairly simple - just provide your email address and a password of your choosing - along with a phone number for a 2FA or another second method of authentication. You will need to also provide your credit card information.

Comparison

Provider	Instance Type	vCPU	Memory	Storage	Price*	Trial Credits
AWS	t2.micro	1	1 GB	8 GB SSD	$18.27	Free Tier for 1 year
Azure	B1	1	1 GB	30 GB SSD	$12.26	$200 / 30 days + Free Tier for 1 year
GCP	e2-micro	1	1 GB	10 GB SSD	$ 7.11	$300 / 90 days
Oracle	VM.Standard.E2.1.Micro	1	1 GB	45 GB SSD	$19.92	$300 / 30 days + Always Free services

• Estimate prices

On a side note, avoid IBM Cloud as much as you can. They do not offer good deals and, according to some reports from previous students, their Linux VM is tampered enough to the point some commands do not work as expected.

Educational Packs

• AWS Educate at https://aws.amazon.com/education/awseducate/
• Azure for Students at https://azure.microsoft.com/en-gb/free/students/

Create a Virtual Machine

The process is basically the same for all these VPS, but here some step-by-steps:

• VM with AWS
• VM with Azure
• VM with GCP

VM with Oracle Cloud

• Choose "Compute, Instances" from the left-hand sidebar menu.
• Click on Create Instance
• Choose a hostname because the default ones are pretty ugly.
• Placementn: it will automatically choose the one closes to you.
• Change Image: Select the image "Ubuntu" and opt for the latest LTS version
• Change Shape: Click on "Specialty and previous generation". Click VM.Standard.E2.1.Micro - the option with 1GB Mem / 1 CPU / Always Free-eligible
• Add SSH Keys: select "Generate a key pair for me" and download the private key to connect with SSH. You can also add a new public key that you created locally
• Create

Logging in for the first time

Select your instance and click "ssh" it will open a new window console. To access the root, type "sudo -i passwd" in the command line then set your own password. Log in by typing "su" and "password". Note that the password won't show as you type or paste it.

Remote access via SSH

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.

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).

What about the root user?

Working on a different approach from smaller VPS, the big guys don't let use root to connect. Don't worry, root still exists in the system, but since the provider already created an admin user from the beginning, you don't have to deal with it.

You are now a sysadmin

Confirm that you can do administrative tasks by typing:

sudo apt update

(Normally you'd expect this would prompt you to confirm your password, but because you're using public key authentication the system hasn't prompted you to set up a password - and AWS have configured sudo to not request one for "ubuntu").

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:

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!

• Complementary video

INTRO

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.

Comparison

Provider	Instance Type	vCPU	Memory	Storage	Price	Trial Credits
Digital Ocean	Basic Plan	1	1 GB	25 GB SSD	$6.00	$200 / 60 days
Linode	Nanode 1GB	1	1 GB	25 GB SSD	$5.00	$100 / 60 days
Vultr	Cloud Compute - Regular	1	1 GB	25 GB SSD	$5.00	$250 / 30 days

For more details:

• Get started with Digital Ocean
• Get started with Linode

Create a Virtual Machine

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!
• Or, if you want to be safer, choose "SSH Key" and add a new public key that you created locally
• 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!
• And, if you want to be safer, click "Add An SSH Key" and add a new public key that you created locally
• Create Linode

VM with Vultr

• Choose "Products, Instances" from the left-hand sidebar. (no cute names)
• Click on Deploy Server
• Choose Server: Cloud Compute (Shared vCPU) + Intel Regular Performance
• Server Location: choose the one closest to you. Be aware that the pricing can change depending on the region.
• Server image: Select the image "Ubuntu" and opt for the latest LTS version
• Server Size: Click the option with 1GB Mem / 1 CPU / 25GB SSD Disk
• SSH Keys: click "Add New" and add a new public key that you created locally
• Note that since that there's no option to just authenticate with root password, you will need to create a SSH key.
• Server Hostname & Label: Choose a hostname for your server.
• Disable "Auto Backups" and "IPv6". They will not be required for the challenge and are only adding to the bill.
• Deploy Now

Logging in for the first time with console

We are going to access our server using SSH but, if for some reason you get stuck in that part, there is a way to access it using a console:

• Digital Ocean: Droplet Console
• Linode: LISH Console
• Vultr: Web Console

Remote access via SSH

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.

To login using your new user, copy the SSH key from root.

You are now a sysadmin

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!

• Complementary video

It's difficult to create a server in cloud without a credit card

We normally recommend using Amazon's AWS "Free Tier" or Digital Ocean - but both require that you have a credit card. The same is true of the Microsoft Azure, Google's GCP and the vast majority of providers listed at Low End Box ().

Some will accept PayPal, or Bitcoin - but typically those who don't have a credit card don't have these either.

WARNING: If you go searching too deeply for options in this area, you're very likely to come across a range of scammy, fake, or fraudulent sites. While we've tried to eliminate these from the links below, please do be careful! It should go without saying that none of these are "affiliate" links, and we get no kick-backs from any of them :-)

Cards that work as, or like, credit cards

• Debit cards
• privacy.com (US-only)

But what if I don’t want to use a cloud provider? You can just work with a local virtual machine

You can run the challenge on a home server and all the commands will work as they would on a cloud server. However, not being exposed to the wild certainly loses the feel of what real sysadmins have to face.

If you set your own VM at a private server, go for the minimum requirements like 1GHz CPU core, 1GB RAM, and a couple of gigs of disk space. You can always adapt this to your heart's desire (or how much hardware you have available).

Our recommendation is: use a cloud server if you can, to get the full experience, but don't get limited by it. This is your server.

Download the Linux ISO

Go to the Official Ubuntu page and download the latest LTS (Long Term Support) available version.

NOTE: download the server version, NOT the desktop version.

Create a Virtual Machine with VirtualBox

• Create a local Linux server with VirtualBox (video)

Install VirtualBox, when ready:

• Click on Machine > New
• Give a name to your VM and select the Type Linux. Click Next.
• Adjust hardware: 1024MB memory and 1 CPU (this is the minimum, but you can reserve more if your host machine can provide it). Click Next
• Virtual hard disk: 2,5GB is minimum, 5GB is a good number. Click Next.
• Finish but we're not done yet.
• The new VM should show up in a list of VMs, select it.
• Click on Machine > Settings
• Click on Storage. Right-click on Controllet IDE, click on Optical Drive.
• Select the Linux ISO you downloaded from the list if available, if not click Add and find it in your directories. Click Choose.
• Click on Network and change the network adapter to Bridged Adapter.
• Click OK
• Click Start or Machine > Start > Normal Start.

Installing Linux

After a few seconds the welcome screen will load. At the end of each page there's DONE and BACK buttons. Use arrow keys and the enter key to select options. When you're ok with your selection, use the arrow key to go down to DONE and enter to go to the next page.

• Welcome Screen: Select your language
• Keyboard Configuration: Select Keyboard type
• Choose type of install: Select Ubuntu Server (minimized). It comes with most of the packages you need without being bloated. It will install faster too.
• Network Connections: If you have setup the VM to use a bridged adapter like instructed, you don’t really have to worry a lot. The installer will automatically detect the DHCP settings from your local network router and you just have to select DONE.
• Configure Proxy: If your system requires any http proxy to connect to the internet enter the proxy address, otherwise just select DONE.
• Configure Ubuntu archive mirror: Leave it as default. DONE.
• Guided Storage Configurations: We are going to utilize the entire storage space reserved for this VM and that's why we select Use the Entire Disk option.
• Storage Configuration: Leave it the standard storage configuration and select DONE. When prompted to confirm, don't worry. This will only use the VM disk, not your computer disk.
• Profile Setup: Enter your name, your server’s name, your username and password. This user will be your administrator user in the system (or sudo), so don't forget this password.
• Update to Ubuntu Pro: No. Skip for now.
• SSH setup: Select on Install OpenSSH server because that’s how you will connect to your server later.
• Featured Server Snaps: None of these packages are important now, just select DONE.
• Installing System: Now you have to wait for a few minutes for your system to install. You can "cheat" and speed up the install by skipping the downloading of updates, select Cancel update and Reboot when it appears at the bottom of the page, a few moments later. You can complete the updates after the first boot. After the installation is complete the system will reboot automatically.

Logging in for the first time

After the first reboot, it will show a black screen asking for the login. That's when you use that username and password you created during the install.

Note: the password will not show up, not even ***, just trust that is taking it in.

If you need to find out the IP address for the VM, just type in the console:

ip address

That will give you the inet, i.e., the ip address. You will need that to connect with SSH.

Remote access via SSH

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).

You are now a sysadmin

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 but is not exposed to the Internet, i.e. other people will not be able to attempt to connect. We recommend you keep it that way. It is one thing to expose a server in the cloud, exposing your home network is another story. For your own security, don't do it.

To logout, type logout or exit.

When you are done

Just type:

sudo shutdown now

Or click on Force Shutdown

Some Other Options

• Install Linux on Windows with WSL
• Turn an old PC into a Linux server
• Install Ubuntu server on a Raspberry Pi
• Run Linux in a Docker container

Now you are ready to start the challenge. Day 1, here we go!

RESOURCES

• Website of the course
• Full lesson source
• Complementary video playlists
• Monthly lessons on Lemmy
• Monthly lessons on Reddit
• Chat with Discord

HOW THIS WORKS

In a nutshell

• Completely free and open source
• Focused on practical skills
• Heavily hands-on
• Starts at the 1st Monday of each month
• Runs for 20 weekdays (Mon-Fri)
• Often points to curated external links, expanding on the topic of the day.
• Much less ‘formal’ than RHEL or Linux Foundation training

Requirements

• A cloud-based Ubuntu Linux server - full instructions on how to set this up are in the ‘Day 0’ lessons
• Basic computer literacy - no prior knowledge of Linux is required but you should be fairly confortable operating your own Windows/Mac machine
• Requires a daily commitment of 1-2 hours each day for a month but can be self-paced

FREQUENTLY ASKED QUESTIONS - FAQ

Is this course for me?

This course is primarily aimed at two groups:

1. Linux users who aspire to get Linux-related jobs in industry, such as junior Linux sysadmin, devops-related work and similar, and
2. Windows server admins who want to expand their knowledge to be able to work with Linux servers.

However, many others have happily used the course simply to improve their Linux command line skills or to learn Linux for the first time – and that’s just fine too.

Will I pass LPIC/RHCA/LFCS/Linux+ certification if I take this course?

NO! This is NOT a preparation course for any Linux certification exam. It can help you, sure, but please refer to a more specific cert training if that's what you are aiming for.

When does it start?

The course always starts on the first Monday of the month. One of the key elements of the course is that the material is delivered in 20 bite-sized lessons, one each workday.

How long does it take? How many hours should I dedicate to it?

Depending on your experience and dedication, you can expect to spend 1-2 hours going through each lesson. The first few days are pretty basic and it might take you just minutes, but there's generally some "Extension" items to spice things up a bit.

I just learned about the challenge and it's already on Day X. Should I wait for next month to start?

Only if you want to. The material is available year-round so you can totally self-pace this if you prefer.

Do I really need a cloud-based server?

Yes, if you’re in the target audience (see above) you definitely should. The fact that such a server is very remote, and open to attack from the whole Internet, “makes it real”. Learning how to setup such a VPS is also a handy skill for any sysadmin.

Instructions for setting up a suitable server with a couple of providers are in the "Day 0" lessons. By all means use a different provider, but ensure you use Ubuntu LTS (preferably the latest version) and either use public key authentication or a Long, Strong, Unique password (we also have instructions on how to do that).

Of course, you’re perfectly entitled to use a local VM, a Raspberry Pi or even just WLS instead – and all of these will work fine for the course material. Just keep in mind what you are missing.

But what if I don't have a credit card (or don't want to use one) to setup an AWS/Azure/GCP server?

Please read Day 0 - Creating Your Own Local Server. There are other options of cloud providers and different payment options. But if none of them works for you, try creating your own local VM.

But what if I don’t want to use a cloud provider? I have a server/VM at home.

Then use your server. Check the post Day 0 - Creating Your Own Local Server

Why Ubuntu, can I use another distro?

The notes assume Ubuntu Server LTS (latest version) and it would be messy to include instructions/variations for other distros (at least right now). If you use Debian or other Debian-based distros (Mint, Pop!OS, Kali) it will make little to no difference because they all have the same structure.

But if you choose RedHat-based distros (Fedora, CentOS, AlmaLinux) or distros like Arch, Gentoo, OpenSUSE, you yourself will need to understand and cope with any differences (e.g. apt vs yum vs pacman).

If none of those names make any sense to you, you shouldn't be picking distros. Go read Linux Journey first lesson instead.

Should I be stopping or terminating my server when not in use?

Using a free-tier VPS, the load of the course does not exceed any thresholds. You can leave it running during the challenge but it's good to keep an eye on it (i.e. don't forget about it later or your provider will start charging you).

I noticed there was a kernel update, but no one said to reboot.

Reboot it. This is one of the few occasions you will need to reboot your server, go for it. The command for that is sudo reboot now

I still have questions/doubts! What do I do?!

Feel free to post questions or comments in Lemmy, Reddit or chat using the Discord server.

If you are inclined to contribute to the material and had the means to do it (i.e. a github account) you can submit an issue to the source directly.

CREDITS

The magnificent Steve Brorens is the mastermind behind the Linux Upskill Challenge. Unfortunately, he passed away but not before ensuring the course would continue to run in his absence. We miss you, snori.

Livia Lima is the one currently maintaining the material. Give her a shout out on Mastodon or LinkedIn.

Wanted to start the challenge this month and happy I can do it here! :)

Thanks for having us, programming.dev!