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 derived from the UNIX Operating System - 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!

YOUR TASKS TODAY

  • Connect and login to your server, preferably using a SSH client
  • Run a few simple commands to check the status of your server - like this demo

USING A SSH CLIENT

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 your server is a local VM or WSL, you could skip this section by simply using the server console/terminal if you want. We will explore SSH more in detail at the server side on Day 3 but knowing how to use a ssh client is a basic sysadmin skill, so you might as well do it now.

In MacOS and Linux

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

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.

Once you open up a “terminal” session, you can use your command-line ssh client like this:

ssh user@<ip address>

For example:

ssh support@192.123.321.99

If the remote server was configured with a SSH public key (like AWS, Azure and GCP), then you’ll need to point to the location of the private key as proof of identity with the -i switch, typically like this:

ssh -i ~/.ssh/id_rsa support@192.123.321.99

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

In Windows

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

There are various SSH clients available for Windows (PuTTY, Solar-PuTTY, MobaXterm, Termius, etc) but if you use Windows versions older than 10, the installation of PuTTY is suggested.

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

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. Yes, you do. Just type/click Yes.

But don’t worry too much about securing the SSH session or hardening the server right now; we will be doing this in Day 3.

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

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

It’s also 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 SSH client and terminal.

Perhaps you might now try logging in from home and work - even from your smartphone! - using an ssh client app such as Termux, Termius for Android or Termius for iPhone. As a server admin you’ll need to be comfortable logging in from all over. You can also potentially use JavaScript ssh clients like consolefish and ShellHub, but these options involve putting more trust in third-parties than most sysadmins would be comfortable with when accessing production systems.

To log out, simply type exit or close the terminal.

LOGIN TO YOUR SERVER

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 (but we will dive into this difference in Day 3 as well).

Here’s a short vid on using ssh in a work environment.

GENERAL INFORMATION ABOUT THE SERVER

Use lsb_release -a to see which Linux distro and version you’re using. lsb_release may not be available in your server, as it’s not widely adopted, but you will always have the same information available in the system file os-release. You can check its content by typing cat /etc/os-release

uname -a will also print the system information and it can show some interesting things like kernel version, hardware platform, etc.

uptime will show you how long the system has been running. It kinda makes the weird numbers you get from cat /proc/uptime a lot more readable.

whoami will print the user name you logged on with, who will show who is logged on and w will also show what they are doing.

HARDWARE INFORMATION

lshw can give some detailed information on the hardware configuration, and there’s a bunch of switches we can use to filter the information we want to see, but it’s not the only tool we use to check hardware with. Some of the used commands are:

MEASURE MEMORY AND CPU USAGE

Don’t worry! Linux won’t eat your RAM. But if you want to check the amount of memory used in the system, use free -h . vmstat will also give some memory statistics.

top is like a Task Manager for Linux, it will display the processes and the consumption of resources. htop is an interactive, prettier version.

MEASURE DISK USAGE

Use df -h to see disk space usage, but go with du -h if you want to estimate the size of your folders.

MEASURE NETWORK USAGE

You will have a general idea of your network interfaces and their IP addresses by using ifconfig or its modern substitute ip address, but it won’t show you bandwidth usage.

For that we have netstat -i in a more static view and ifstat in a continuous view. To interrupt ifstat just use CTRL+C.

But if you want more info on that traffic, sudo iftop -i eth0 is a nice display. Change eth0 for the interface you wish to capture traffic information. To exit the monitor view, type q to quit.

POSTING YOUR PROGRESS

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

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

EXTENSION

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

RESOURCES

Some rights reserved. Check the license terms here

  • @[email protected]
    link
    fedilink
    34 months ago

    This is cool idea! I don’t have an extra machine or free time for this at the moment, but it’s definitely something I’m interested in

  • @Rynok_
    link
    23 months ago

    Loving this so far, I have some experience with linux but many of the commands here are completly new to me.

    iftop is a really nice one!

    I’m making an Anki deck with some of the commands I do not know so I can keep reviewing them. I wonder whats the best way to learn them.

    • Livia LimaOPM
      link
      23 months ago

      Anki is awesome but the best way to memorize commands is to just use them. After you are finished with the challenge you may want to consider practicing with real world scenarios at https://sadservers.com/

  • swab148
    link
    fedilink
    23 months ago

    Started this today! Kinda wondering, on a local VM, is it always necessary to reboot the Ubuntu server before ssh’ing in from my actual machine? Or did I miss something here? I’ve used ufw to open port 22 on both sides, so I’m kind of at a loss here lol

    • Livia LimaOPM
      link
      23 months ago

      No need to reboot, it’s just a recommendation after your first update/upgrade to get any kernel changes in. You won’t need to reboot for a long time after that.

      • swab148
        link
        fedilink
        13 months ago

        Hm, my local machine keeps timing out for some reason. I can ssh from the VM to the local machine, but not the other way around, unless I’ve just rebooted the VM, also Termux et al don’t work at all for some reason. Idk, weirdness on my end, I’ll just leave it up after tomorrow’s lesson!