The Basic Linux Commands

The inspiration for starting the Linux-centric series of post is finding the follow image posted on r/Ubuntu by u/Tunliar 

This is most of the core commands to using the Bash to administrate a Linux system with the command line.

How ever great the --help and man files are, they are were written and updates by someone who knows much more about Linux than you and often omit key basic definitions of abbreviations , lack explanations of concepts, and have abrupt descriptions for the arguments requires for the command. I find the best way to understand CLI commands is to create a written lab journal in a composition book, that can be used to jog your memory date, weeks, or months from now.  A well configured server shouldn't need constant administration.  A great problem with technology, you will always remember that you did something, but not the specifics of how you did it.  Ron Popeil once said. "Set it and forget it", creating a journal is a great way to better memorize and create your ultimate offline documentation. 

Write an entry for each command written in your own words, .  Sit down at and spend the time to digest the command's --help and man outputs, practice using the command's options, and then write down in your own words how to use the options and create valid arguments to achieve tasks. When I say, in you own words, try to avoid copying the man or --help word for word,  list the options and define them using words and explain the arguments in a manner that you best understand and customized for your specific reading level.

Keep this journal near your workstation.

The Linux Command Line is your friend.

With Ubuntu 18.04 LTS is installed and access configure, it is time to administrate it, using the command line interface.  This means typing, lots of typing.  Historically the Command Line Interfeace itself dates back to the era of Bell Bottoms pants and Teletype machines. As computers and software evolved one interface lead to another, which lead to another.  Today Linux uses Bash (Bourune Again Shell), who's beta release happened in 1989 for UNIX, predating Linux's own birth by 2 years.

However powerful, using Bash or any CLI is not forgiving of mistakes.  There is a premise of Garbage In/Garbage Out,  where if you don't use the correct spelled, cased, or syntax for the  commands you will not get the desired output..  At worst messing up a command will delete files, destroying data or damaging the operating system.. Hopefully you just get a message that the command isn't recognized or that the package associated with it isn't installed.. With great power is great responsibility, if you make a major mistake it could be a resume generating event.

Giving Yourself Superuser Powers

sudo

The most important commands to remember is "sudo" if you need to do almost anything important, chances are you will need to use it.  Sudo is must be added before any command that requires Super User (or commonly called "root") permission, and requires the password of the use who issued the account.  Ubuntu does not even assign a password for the root account for security reasons. To do anything that requires Super User permission, you must use sudo. Before the command runs you will be asked to provide the password for the users you are logged in with.

Notice the first attempt to run the command "apt update" the it runs into permission denied for it's operations, but with "sudo apt update" it runs fine.

Builtin Help and Manual

No normal human is able to memorize every command's options and arguments.  Back in the 20th century, users relied upon printed manuals that came with your computer or came in the Retail Box of your Operating Systems.  Normally you keep within arm's reach of the user, even if you didn't need it very often.  If you went to early university computer labs,  each terminal or micro computer likely had a binder with some form of documentation for users to reference.

The User and Reference Guide that came with MS-DOS 5.0 in 1991, the same year Linux Torvolds. announced his little project. on Usenet.

Today, Linux developers have gracefully built this resources into CLI.

--help

Bash commands allow for great amount of control of the command, with option and arguments that generally are used in this format:

Command  [option]  <argument>

Every command has a  "--help" option which lists options describing their use and any arguments they would require, this is intended to be a quick reference.

The output of running "apt --help"

man

While the --help outputs basic command usage,  Ubuntu has a  manual for every command, often referred to as the "man page" or just "man".   It is accessed with the "man" command followed by the command you want to read about'  for example "man apt"

First page of the man for apt.

Note: You will need to navigate with the arrow keys for single lines or page up and page down to move an multiple lines at a time.

If would rather read them in a browser they can be found at https://manpages.ubuntu.com/manpages/bionic/.  Note, each release has it's own set of man pages, 18.04 is named bionic beaver and it's man's are in the /bionic directory, other version of Ubuntu have their own directory.  Desktop and Server versions use the same man pages.

Summarization or TLDR

Linux uses the Bash Command line.  If you get a message that don't have permission to perform a task, type sudo before it and then supply your password you upon request.  If you need help using a command, type "<command> --help" to get a simple command use output.  If you need more information than that, type "man <command>" to read a more in depth manual for the command.

Up Next:  Learning the Basic Commands. 

 

 

The Headless Server

Going Headless With Ubuntu 18.04

I define a server as a computer that you don't sit in front of and/or directly interact with.  Right now the project is really more like a desktop without a GUI interface with only packages that come standard with the OS.  This post will focus on two methods to indirectly administrate an Ubuntu Server. 

SSH

Secure Shell. or as most refer to it as SSH, is an open protocol for securing network services, and has long been the de facto remote access for CLI administration. 

During install you of either the "Live" or "Alternative" installer for Ubuntu-Server, you will have been given a choice to install OpenSSH.  If not installed, use the the commands "sudo apt install openssh-server" and "sudo apt install openssh-client".  Once installed there is no other configuration required to accept incoming connection, but you will need to know the server's IP address, which can be found by running the command "ip address".

You can then connect to your server from any workstation, laptop, tablet, phone, other servers, or whatever device with network connectivity and whatever SSH client of choice just like you would with a Router, Switch or Firewall device. For now, I will be simply be using the crypto key that is automatically generated for now. Importing or generating custom SSH Keys is topic for another post.

SSH provides a secure connection between two systems for remote administration.  BUT if the network connection fails for any reason, you are unable to establish a connection and must resort back to previous means.

Serial Console

If you have dealt with pretty much any enterprise network gear yous should be familiar re with what a , RJ-45 console port,  DB-9 port, Cisco Cable, and Rollover Cable.

Console port on a Cisco Router

Console ports utilize a null modem connection to facilitate communication between two DTE devices to give an administrator CLI access to the device. Today most modern network gear uses a RJ-45 instead of a DB-9 (DE-9) for the RS232  communication.  If that makes you head spin, realize this the 9 pin serial port is really old and yet still used because it works and has rather low overhead to create a simple channel of communication. 

The Physical connection.

To get started you will need these three things:

• Serial interface for the Ubuntu Server 
• Serial port for the Client/workstation
• Null modem cable to connect between the two.

Serial Ports

Red Arrow pointing out the 9pin serial port, notice the difference with blue VGA port and the Magenta Parallel port.

Fortunately the motherboard I chose for my server has a Serial Port, and most "server" motherboards do as well.  If your consumer grade motherboard doesn't have a serial port on the I/O shield, it might have a header on the motherboard  and you can get a serial port bracket that will plug into it.  If your server and/or desktop/laptop doesn't have either. There is a wide variety of serial port USB adapters and pci/pci-express expansion cards that won't break your bank.

The Cable

While I have boxes of different types of  cables going back years, one thing I didn't have was a null modem cable.  What I do have is plenty of "Cisco" console cables, one end is RJ-45 and one end DB-9. 

So instead going to a computer store in the next county or waiting for one to be delivered, I built my own from a cannibalized Cisco cable .

A quick and dirty method would be cut the RJ-45 ends splice the individual wires in the correct pinout. Note: This is basically making a rollover cable, matching up pins 8 to 1, 7 to 2, 6 to 3, 5 to 4, 4 to 5, 3 to 6, 2 to 7, and 1 to 8.

Or if you like color coding :
Grey - Brown
Orange - Blue
Black - yellow
Red - green
Green - red
Yellow - black
Blue - orange
Brown - grey

This would work if you are in a crunch. But, I came to the conclusion while trying to strip the individual wires that it would be to easily damaged.

I needed a long term and more durable solution to reuse in my lab.  So, I bought a RJ-45 telephone jack  (a few bucks cheaper than a cat5/cat6 jack) from a local big box store. Turns out 4 line telephone jacks and Cisco console cables have different wire colors, so I painstakingly created a rollover pinout between the color groups, including the needed rollover. 

Telephone  -  Console
blue           -  Grey
orange       -  Orange
black         -  Black
Red           -  Red
Green        -  Green
Brown       -  Blue
White        -  Brown

Now that you have the cable in place, open up your favorite terminal emulator on the workstation/desktop/laptop for the appropriate COM port with the default settings (including 9600 baud.)  Leave it open and ready to console output.

* Note: You could do the same thing with a cat5 keystone jack, you would just need to match up pins in reverse order to achieve rollover.

Configuring Ubuntu Server

There is ONE command to add to your grub configuration and systemd seems to take care of the rest, you simply add "console=ttyS0" to your grub boot options.  For those not familiar with the linux command line yet,  I have step by step instructions:


1. To edit your Grub config use the command "sudo nano /etc/default/grub"

2. Once in the editor, find the GRUB_CMDLINE_LINUX_DEFAULT= line and add console=ttyS0 (that is a Zero at the end, not the letter 0). 

3. If there is already something between the parentheses use a space to separate it and place it after it. 

4. After you have added the line ctrl + o to write (save) your changes and ctrl + x to exit the nano text editor.

5. The configuration file change must be applied with the command "sudo update-grub" AND since grub is a bootloader you must reboot the system for the change to take effect, issue the  "sudo shutdown -r 0"

6. Return to your workstation and wait for Linux to start booting.

* Unless you have a motherboard that supports console output during boot and that option has been configured in the bios, you will not get post information or any output till after grub starts Ubuntu.

Connecting to a Terminal or Console Server

A Terminal/Console Server allows a user to use SSH (or telnet) into serial/console ports, among other things. bridging remote telenet/ssh to console access.  These are often employed in Data Centers and Network cabnets/closets in which a server administrator should not be given physical access.

To connect all you need is a standard "Cisco" console cable, plug the DP-9 into the ubuntu server and plug the RJ-45 into the Terminal/Console Server, and you can access like any other piece of network gear.

More on Cabling

Back in the early days of computing when serial cabling was first standardized, they gave it around 50 feet of length based on the cables using wire standards available in the 1950's and 1960's. Decades we can use cat5 around triple that original distance, you can even use existing cat5/6 straight through cabling,  as long as there is ONE rollover cable used instead of a patch cable.

Venturing Down The Linux Rabbit Hole

A New Project

     This is the start of a new series of posts documenting my exploration and configuration of Ubuntu Server 18.04.2 LTS  with the objective of having a better understanding what is under the hood of Linux and how to interact with it's CLI

Why Ubuntu?   

    Ubuntu it self is a widely supported and adopted  Linux distribution and is also based on another widely supported and derived (parent) Linux distribution, Debian. Canonical, which is the parent company for Ubuntu, itself maintains many versions of Linux for different forms of hosts and "flavors" the individual forms Ubuntu . Then you have third parties who take Ubuntu make their own derivatives like Mint. But when you get down to it, Ubuntu itself is a derivative of Debian which likely be the most derived and one of the oldest Linux distributions still actively being developed. With any luck most of the knowledge and experince gained from these exercises will remain relevant long into the future. 

Why Ubuntu Server? 

    This project is an exercise to force myself to use CLI commands and familiarize myself with the underlying environment and remote access. Ubuntu Server has most if not all of everything Ubuntu is under the hood, minus the Graphical User Interface (GUI) environment and associated applications.  After the next post, I  will not have display or input devices connected to it after the initial configuration process. As of starting this, 18.04.2 LTS (long term support)  is the latest/newest version that will have the longest time of support.

Note: there are are even two different installer versions (The standard )  for a more in information I suggest reading this link,  At the most basic level,  the  more easily e easily  found "line" installer the image uses a Canonical/ubuntu brewed installer and installs a slightly different set of package (notably ncluding openssh server) and the "alternative"  (which lacks the word "live" in the file name) uses the Debian installer.  Again read the link for the best comparison between the two versions.

What to expect in these posts?

    This documentation is intended to be a building block towards knowledge based on an existing foundation.  It will assume the reader has knowledge of PC hardware, OS installation, networking protocols, competence using MS Windows, bios settings, and etc. I will highlight what I considered important leaps from my base of knowledge and important things that might not be clearly explained difficult to pick out from the "--help" and "man" pages can be accessed in from the CLI of the OS itself.  The underlying goal is to configure and implement protocols and services on Ubuntu-Server and co-exist with devices running  much more popular Operating systems that people directly interact with,  Android, Windows, and Chrome0S.

But aren't Android and ChromeOS Linux based operating systems themselves?

    Under the hood yes,  but most users will never touch the actual "Linux" parts nor made aware of them.  For consumers, Linux is best when the user him or herself does not have to touch it nor is made aware it is there.

Gasp,  you forgot about iOS and OSX?

Nope, but I am trying. I do not own Apple products (nor condone their purchase). I simply cannot write about my experiences with hardware/software I do not own

 Onward to the real meat and potatoes...

Part 1 -  The Environment

The Hardware

While most people would be content with starting this process in a virtual machine, there is something so much more appealing to me with just running an operating system on directly on the hardware without anything in between to worry about. .Especially for someone like me who doesn't have a box already built running multiple other machines.  For purposes, I have built a system from disused parts in I've been collecting.

What I am working with:

•     AM2+ socket motherboard (Foxconn A76ML-K w/ 760g chipset)
•     AMD Phenom II X4 945 (95 watt version)
•     2 x 2Gig ddr2 dual channel ram
•     80GB SATA HDD
•     2 PCI 100mbit Ethernet cards
•     AND a grab (anti-static) bag of expansion cards I will be swapping out in the future.

This very much so is becoming a legacy system, but should be ok enough for learning,  Also note, if could use a USB flash drive, or even a SSD isntead of a HDD like I am using.  Linux isn't that picky about where it installs from, just make sure your bios supports booting from it.

Turning a box of hardware into a Server.

Download and create installation USB Flash drive. 

    Files can be download easily from Ubuntu's website,,  I will be using the "Alternative Ubuntu Installer" which doesn't install the cloud-init package.  If you downloaded the image on a Windows machine like Id id, use a piece of software like Rufus to create actual installation flash drive. 

Building the System.

These are my general steps for system building:

    1. Construct the core of system (Mother Board, CPU, RAM, PSU) together in a case.
    2. Plug in power, Keyboard, monitor, network cable, and etc.
    3. Turn on to see if posts, if it doesn't, time to troubleshoot.
    4. Once you are sure the computer posts, unplug the power cable, and add expansion cards, storage drive, and insert the installation flash drive.
    5. Clear the BIOS with the jumpers on the motherboard or momentarily pull the battery from the system. When building with a new or used motherboard a clean slate is best, the bios will need to go through some steps to recognize the CPU and it's feature sets.  Do not skip this step.

Configure the BIOS.

 NOTE: As previously mentioned I will not go into detailed instructions. Every motherboard is different, your experience may vary.

    1. Disable onboard hardware that will NOT be used. If you are using older hardware there will be  legacy  features including floppy controller, IDE, parallel port, IR, sound, and etc that you will probably not need.  Warning.  Make sure NOT to disable useful/needed hardware like integrated graphics (IGP), serial interface(s) (yes, keep the serial rs232/DB9), SATA, USB, onboard Ethernet, and etc. If in doubt leave it enabled. 
   
    2. Configure the onboard hardware you will use.  This includes:setting the SATA interfaces to AHCI mode and enable Wake-on-LAN (WoL).  You could also reduce the ram dedicated to the IGP to the lowest amount allowed, Ubuntu-Server lacks a GUI environment and the intention is to run it headless (eventually.) and dedicating it to the IGP will make it inaccessible to the OS for system ram.

   I also like to take the opportunity to set the motherboard's fan's settings to be quiet and only spin up when temperatures are high.  Most motherboards will default to running the fans at 100% regardless of load/temperature, which is good for the system health bad for people that might spend long periods listening to them.
   
    3. Double check previous steps, and set your boot order to for installer USB flash drive first, save config and restart into your install flash drive.

Install the Operating System

    1. Install Ubuntu-Server from the flash drive remove USB upon reboot. I let the installer automatically partition and format the system drive.

    2. Return to the bios and remove USB boot option from boot order.  Keep in the flash drive handy, to either re-install or attempt to fix a borked install in the future.


Once you have booted into Ubuntu-Server it should leave you with a CLI interface requesting a user name and password.

Next Post - Going headless.