In this chapter, we will cover the following recipes:
- Understanding and choosing a distribution
- Installing VirtualBox
- Installing our chosen distribution manually
- Connecting to our virtual machine (VM)
- Accessing and updating our VMÂ
- Understanding how VMs differ
- Using Vagrant to automatically provision VMs
- Anecdote (try, try,Â and try again)
Before we get into the nitty-gritty of what distribution (sometimes shortened to "distro") we're going to use, we must first take a rather large step backwards and consider the concept of LinuxÂ in a somewhat philosophical way.
A good description of "what Linux is" can be hard to pin down, due in no small part to a level of confusion willfully propagated by IT professionals, because it makes them sound much smarter than they actually are when they come to explain it.
Because you're reading this book, I'm going to assume that you know of Linux at a high level; you know that it's an operating system (OS) like Windows or macOS, that it's not seen much of the limelight, and that it's not generally used on the desktop.
This assessment is both right and wrong, depending on who you're speaking to.Â
Laid-back systems administrators (sysadmins) will lean back further, nod their 80s era mohawk, and agree that Linux is an OSâand a decent one at that. They will then go back to playing with whatever trendy software they're learning this week so that they can try and shoehorn it into the infrastructure next week.
Self-proclaimed graybeards will stop what they're doing, sigh audibly, and pick up their fourth cup of coffee before swiveling around to give you a lecture on the difference between GNU/Linux (or GNU+Linux) and the Linux kernel.
A kernel is an important part of any complete OS. It's the piece of software that sits between the hardware and the software, performing the grunt work of translating between the two. All operating systems will have a kernel of one sort or other, for example, the macOS kernel is call XNU.
The lecture you receive will be tedious, will involve names such as Richard Stallman, Linus Torvalds, and possibly even Andrew Tanenbaum, and may even take upwards of an hour, but the main takeaway will be that Linux is the accepted name of the OS you're learning about, while also being technically incorrect. They will say that Linux is really just the kernel, and everything beyond that is a distribution wrapped atop the GNU tools suite.
Linux, as hinted at in the preceding section, is fragmented. There's no better way to describe this, due to the sheer number of different distributions you can download from a multitude of different vendors. Some of these vendors are for-profit, offering support contracts and SLAs with your purchase of their OS, and some are entirely voluntary, manned by one person in their garage.
There are literally hundreds of distributions to choose from, and each has their advocate-army to tell you why theirs is "the one true distribution"Â andÂ "there's really no reason to go shopping around for a different one."
ThereÂ are also Linux distributions that have been created for specific purposes, such as Red Star OS, the purportedly North Korean Linux distribution.
The truth of the matter is that most businesses use the Linux distribution they do because it was:
- The first one that popped up when the owner Googled free OS
- The one the first IT Administrator liked
- The one that offers a contract they can invoke when something breaks
Going through each distribution that's around at the moment would be futile, as they're being created or abandoned on an almost weekly basis. Instead, I'm going to run through a popular selection (in the server space, rather than the desktop), explain some key differences, and then talk about which I'll be using for the rest of this book.
Don't be deterred if the distribution your business uses isn't one we talk about hereÂ â most of the tooling is consistent across distributions, and where it differs, documentation exists to help you out.
If you want to learn more about the various distributions available to you, a site called DistroWatch (https://distrowatch.com/) has been around for years, and offers a regularly updated list of most Linux distributions, organized by page hit ranking.
Ubuntu is the first Linux distribution I ever installed, and I'd wager the same could be said for a lot of people who started in Linux around the mid-2000s. It's also the distribution I'm using to write this book.
It has enjoyed consistent mindshare on the desktop, thanks to its decent attempt at marketing (including its position in Google's rankings when searching
Linux), its perception as Linux for Human Beings, and its user-friendliness.
Downstream from Debian, Ubuntu's development is headed by Canonical, and while they started with an emphasis on making a rock-solid desktop OS, they have since moved into the lofty realms of attempting to dominateÂ the server space, and have entered the IoT device market too.
When we say "downstream" in this sense, we mean that Ubuntu shares a lot of its foundation with Debian, except it adds some extra bits and takes some bits out. In the Linux world, there are few from-scratch distributions, with most using another distribution as their bedrock.
Known also for its cutesy naming convention (18.04 being Bionic Beaver), the fact Ubuntu was so popular on the desktop meant it was the obvious distribution of choice for sysadmins to install on their servers, reaching for what they were already familiar with.
More recently, it's become increasingly common to find Ubuntu installations when dealing with inherited systems, usually a long-term support (LTS) release (so that confusion and headaches around OS upgrades can be avoided for a reasonable length of time.)
Ubuntu releases on a six-monthly cycle, with every two years being an LTS release (14.04, 16.04, and 18.04, most recently). Their numbering convention is year-released, followed by month (so April 2018 is 18.04). It is possible to upgrade from version to version of Ubuntu.
Canonical also aren't shy of introducing new technology and software in Ubuntu, even when it diverges from their Debian base. Recent examples of this include the following:
Ubuntu can be downloaded from https://ubuntu.com.
As mentioned previously, Debian (the universal OS) is the basis for a lot of other distributions that came later, but it has consistently been one of the most popular, both on the desktop and on servers. It is still highly likely that you will choose to install Debian yourself, or will inherit a system running this distribution, with its reputation for stability.
Traditionally, the server-space war was fought between two camps, the Debian Druids and the CentOS Cardinals. In more recent years, newcomers have entered the fray (like Ubuntu,) but these two still hold a considerable amount of hardware to ransom.Â
Releasing every two or three years, the Debian versions are named after Toy Story characters (7âWheezy, 8âJessie, 9âStretch). They have a reputation for being one of the most stable Linux distributions around, with tried and tested versions of software, as well as sensibly backported fixes.
Backporting is the act of taking a fix from a recent release of software, such as the kernel itself, and incorporating those fixes into the version you're running, recompiling it into a new piece of software. Features are rarely backported, due to features having the potential to introduce more breaking changes into long-term support distributions.
Some criticism is sometimes leveled at Debian because it generally has older versions of packages available in its release version, which may not include all the trendy and cool features a systems administrator wants, or a developer desires. This isn't fair, given that people generally look for stability and security in the server world, over the latest and greatest version of Node.js.
Debian has staunch defenders, and it holds a special place in a lot of hearts, though it's unusual to see it in some Enterprise environments because it's developed by the Debian Project, rather than a traditional company that can offer support contracts. In my anecdotally dismissible experience, I have more often seen Debian in smaller companies who needed a quick solution, and slightly larger companies who still run some legacy systems.
Debian can be downloaded from https://www.debian.org.
The Community Enterprise Operating System (CentOS) is a freely available and compiled version of the Red Hat Enterprise Linux distribution, which aims to offer functional compatibility, generally replacing the Red Hat logo with the CentOS logo to avoid trademark infringement. (In January of 2014 it was announced that Red Hat was joining forces with CentOS, to help drive and invest in CentOS development.)
Because of its nature, a lot of systems administrators have installed CentOS to better understand the Red Hat world, because (as mentioned previously)Â Red Hat has a good reputation in Enterprise companies, so it would make sense to install something so strikingly similar.
This installation trend goes both ways. I have seen companies who started out by installing CentOS because it was readily available and allowed them to design their infrastructure easily, utilizing publicly available and free repos, before moving to a RHEL deployment for the finished product.
Repos is a short form way of saying repositories, which are the common location from which software is installed on a Linux system. Where Windows usually has downloads from websites, and macOS has the App Store, Linux has used software repositories for most of its life, and they have the advantage of being easily searchable with a few keystrokes on the command line.
I have also seen companies who deployed RHEL everywhere, only to realise that they were spending a lot of money, and never invoking the support they'd bought because their operations team was just that good! They would then gradually phase out their Red Hat deployments and move to CentOS, changing very little in the process.
Releases come about every few years, with version 7 being released in 2014, and getting consistent updates since then. However, it should be noted that version 6, which was released in 2011, will be getting maintenance updates until 2020.
CentOS can be downloaded from https://centos.org. We will go through this in the installation section.
Red Hat Enterprise Linux, or RHEL as it's more commonly known (because it's a long name), has a very firm footing in Enterprises. It targets the commercial space very well, and as a result it is not uncommon to find yourself on a RHEL box, which you've initially assumed to be a CentOS installation.
What makes RHEL different is the support offered by Red Hat, Inc. and the various services that you can utilize if you've bought an official package.
While Red Hat still offers the source code for their distribution without question (hence CentOS), they sell versions and packages for everything from the desktop up to data centre installations.
There's an adage that states "no one got fired for buying IBM," which is a little dated in this day and age, but I've heard people invoke this philosophy to describe Red Hat on more than one occasion. No one will get fired for buying Red Hat (but you might be asked what the benefits are of paying for something that's available for free under another name.)
Beautifully, it was announced while I was in the editing stage of this book that IBM have bought Red Hat, bringing my comment above full circle. The universe is great sometimes.Â
Aside from the support, the business-like attitude that other businesses like, and the contributions back to the community as a whole, Red Hat also offer something which has been variously described as "a waste of time" and "crucial for this role."
Exams are looked at with both affection and derision, depending on who you speak to in the Linux community (as with many things, there's something of a holy war about them). Red Hat offers two of the most popular, and many more to boot. You can study for and become a Red Hat Certified System Administrator, followed by a Red Hat Certified Engineer, which are widely seen as very acceptable qualifications to have.
As a college dropout, I'm quite happy to have an RHCE qualification under my belt.
Some people see these exams as a way of getting past the first line of those hiring (as in the people who scan your CV, and look for badges they recognize). Others see them as proof that you know what you're doing around a Linux system due to the fact that these exams are practical, (meaning they sit you in front of a computer and give you a set of steps to finish.) Some people dismiss exams altogether, although they're usually the ones who've never bothered trying the exam.
Take a look at https://www.redhat.com, taking particular note of the various packages on offer. They do have a developer account too, which gives you access to services you would otherwise pay for (as long as you don't try and sneak them into a production environment!).
As I said in the previous section, I've chosen to mostly use CentOS for the recipes in this book. Hopefully, this gives you a good baseline for learning about Linux Administration, but also gives you a bit of a head start if you plan on going for any of the Red Hat exams.
Instead of requiring you to have a spare laptop handy, or renting a server somewhere, I'm going to advocate using VMs for testing and running through the examples given.
VMs are exactly as they soundÂ â a way of virtualizing computer hardware on one or a cluster of physical machines, thus allowing you to test, break, and play to your heart's content, without risking rendering your own computer unbootable.
KVM (along with libvirt) is the technology that you will come across most often in the Linux virtualization space. It forms the basis of popular technologies, such as Proxmox and OpenStack, while providing near-native speeds.
Another way of creating and managing VMs is a program called VirtualBox, which is now developed by Oracle. The nice thing about this software, and the reason I shall be using it here, is that it's cross-platform, being produced for macOS, Windows, and Linux.
$ sudo apt install virtualbox
Using sudo will generally prompt you for your password, and you won't see anything being printed to screen as you type.
You will likely be prompted to confirm installation of VirtualBox and its dependencies (there may be a lotâit's a complex program and if you haven't updated in a while, you may get a few dependency updates too).
Hit Y and Enter to continue. The following screenshot shows an example of the installation if started from the command line:
Simply search for the software you desire, in this case,Â
Â and click through to its store page.
After installation, your screen will change to show
Although I'm using Ubuntu, it's not the end of the world if you're not. macOS is a fine OSÂ too, and handily it supports VirtualBox.
If you already have the command-line program
brew installed, then getting VirtualBox is as easy as running the following command:
$ brew cask install virtualbox
Homebrew is available from https://brew.sh/ and is effectively the package manager that macOS needs, but doesn't have out of the box. I can't readily recommend blindly running scripts from mysterious websites, so be sure you understand what's being done (read the code) before you take the plunge and install brew.
Simply navigate to https://www.virtualbox.org/wiki/Downloads and select the
OS X hostsÂ option.
This will prompt you to download the installer to your local system, which you can unpack and install.
Running through the installation, you may be prompted for your superuser password.
If you're not using a Linux flavor on your computer, and you're not using macOS, it's a good bet that you're running Windows (unless you've delved into FreeBSD on the desktop or similar, in which case I can't help you hereâwe'd need an entire afternoon).
If using Windows, I can suggest VirtualBox again, due to its cross-OS nature, and it can again be installed from Oracle's site.
Like the macOS installation, navigate to https://www.virtualbox.org/wiki/Downloads and select the
Windows hostsÂ option:
This will download an executable that can be run.
It's worth noting that Windows can complain if you're attempting to run multiple virtualization solutions at once. If you've previously run Hyper-V, or Docker, and you experience issues attempting to start VirtualBox machines, try disabling your other solutions first.
Next, we're going to look at setting up a VM manually. But fear not! We will also be looking at automating this procedure with Vagrant to avoid having to perform repetitive steps in the rest of the book.
Seriously, if you're already well-versed in installing CentOS, feel free to skip this section entirely. I have provided Vagrantfiles throughout the rest of this book for automating the boxes we're going to work on.
Head over to https://centos.org/download/ and have a look at the options on offer.
I'm going to download the
Minimal ISO, for reasons that will become clear shortly.
What you tend to find is that these providers typically fall into two categories, with exceptions. Generally, the images are provided by universities, or hosting providers. The cynic in me thinks that the hosting providers offer a mirror service as an easy source of marketing, rather than some philanthropic gesture.
You may note that one of the download options is via Torrent. Torrenting is a great way of spreading out the cost of bandwidth to multiple people, and allowing a small piece of the software to be downloaded from multiple locations greatly reduces load on any one source. However, it should be noted that some workplaces watch out for this type of traffic on their networks due to the reputation torrenting has.
On my Ubuntu installation, I can see it in my
$ ls ~/Downloads/ CentOS-7-x86_64-Minimal-1804.iso
One way to confirm our installation media and ensure that we've downloaded exactly what we expect, is to compare the
Sha256 sum of the downloaded file with a known-good value. This both proves that it's the download we expect it to be, and also checks that no corruption has occurred during the file download.
CentOS provides a release notes page that we can visit to find the
Sha256 sum we're comparing:Â https://wiki.centos.org/Manuals/ReleaseNotes.
Click through to
Release Notes for CentOS 7, which should bring you to the most recent version of the release notes.
On this page, we can scroll down to
Verifying Downloaded Installation Images, which will list the current
Sha256 sums for the download images.
Always make sure that the site you're getting your known-good
Sha256 values from is itself legitimate.
In my case, I can see that the
Sha256 value for the file I just downloaded is as follows:
With this in hand, I can go back to where I listed out the file in my Terminal, and run a basic command to check the
Sha256 value of the downloaded image:
$ sha256sum CentOS-7-x86_64-Minimal-1804.iso 714acc0aefb32b7d51b515e25546835e55a90da9fb00417fbee2d03a62801efd CentOS-7-x86_64-Minimal-1804.iso
The media is what we expected!
In this section, we will be provisioning a small VM, but even that will come with the cost of processing power, memory, and disk space. Always ensure that you have the appropriate resources available for the machine you're trying to create. In this case, at least 50 GB of free drive space and a minimum of 8 GB of memory is advisable.
Next, you will be prompted to name your VM.
Call your first machine
Notice how when you name your machine, the
Version automatically detects what you've typed, and reconfigures the selection as appropriate.
In this case, it gives us a
Linux, and a
Red Hat (64-bit). This is okay because of what we said before about CentOS and Red Hat Enterprise Linux being very close.
64-bit is the architecture of the OS, though the OS you install must be supported by the CPU you have (most CPUs these days are x86_64.) The common architectures were generally x86 (32-bit) and x86_64 (64-bit) for years, but more recently the x86 variant has been dying off. The most common installations these days are x86_64, though ARM and aarch64 machines are becoming more commonplace. In this book, we will only be using x86_64 machines.
Now, we have to configure the amount of memory to give our machine. If you're constrained by this, you can put it to a lower value than the default of
1024 MB (1 GB), but 1,024 MB is a reasonable place to start, and we can always adjust it later if needed.
Now, we'll be prompted to configure the hard disk for our virtual system.
Leave the default option of
Create a virtual hard disk nowÂ selected, and click
You'll be prompted to choose a type. Leave the default selected, that is,Â
VDI (VirtualBox Disk Image).
You'll be given the option of provisioning the disk over time (
Dynamically allocated) or all in one go (
Fixed size). I tend to leave it as
Next, you'll be prompted to choose a location and a size for the disk. I would advise leaving the disk in the default location, and for the moment the default size of
8 GB should be enough disk space to get started.
If everything goes well, you will return to the main window, and a new VM should be listed on the left, in the
Powered OffÂ state.
I've navigated to my
Downloads folder and chosen the downloaded image from earlier.
StartÂ will boot the machine from our media.
You will be presented with the option screen within the VM, with
Test this media & install CentOS 7Â selected by default.
I usually hit the up arrow (within the VM window) to select only
Install CentOS 7Â and skip the media check, though you may wish to perform the test.
If you're using physical media to install a machine (a DVD or CD), it might be a good idea to run a test of the media prior to installation.
Pressing Enter will continue the installation.
You will be prompted to choose your language. I choose
English, because I'm monolingual.
Note the message at the bottom, suggesting that items marked with the yellow icon need to be completed.
Because our date/time, keyboard, and language are all correct, we'll move on to the next stages, but feel free to correct any of these settings if they're wrong for you.
Notice that under
INSTALLATION SOURCEÂ we've got
Local mediaÂ selected, and under
SOFTWARE SELECTIONÂ we've got
Minimal Install.Â This is a product of us selecting the minimal image earlier on, and gives us a good chance to talk about installation over the internet.
OFFÂ toggle to the right of your device name, and check that the network values are populated in a similar way to mine:
VirtualBox creates a NAT network by default, meaning that your VM doesn't sit on the exact same network as the host computer. Instead, the VM exists in a network by itself, but with a path to the outside world (via your host machine).
DoneÂ in the top left to complete our network setup (for now)!
Within this screen, you can see that the auto-detected media is actually our disk image (
sr0 being Linux's denotion of the disc drive).
Populate the URL bar with the following:
You should end up with the following screenshot:
DoneÂ in the top left.
Have a read through the different options, but for now leave
Minimal InstallÂ selected and click
Have a read of the options, but for now we're not going to bother with changing the default partition layout, or encrypting our disk. You should also see that the default selected disk is our 8 GB VirtualBox one.
Done (you shouldn't have had to make any changes, but the installer makes you enter this screen at the very least):
You'll see the installation begin, and will be given the following screen while you wait:
root user is akin to the administrator on a Windows system; it's all-powerful and can be dangerous in the wrong hands. Some distributions don't even prompt you to set a root password on installation, making you use your own user and
When making your user, flag them as an administrator too:
Done will take you back to the installation progress screen, where you may be prompted through the rest of the installation, and eventually get asked to reboot into your freshly installed system.
No sane person should ever have to produce that many screenshots.
We're going to use the user we created at installation time, rather than root.
CongratulationsÂ â you've installed CentOS!
It's very rare to find a Linux server with a graphical user interface (GUI) installed, though it does happen. Of the thousands of servers I've worked with, I can count the number of times I've come across a GUI on one hand. It's usually cause for momentary confusion and distress, before concluding that someone had to have installed the GUI by accident âÂ there can be no other explanation.
$ ip a
Native SSHÂ clients are available for macOS and all Linux distributions. Windows has made some progress in the area too, though I'm to understand that the easiest way of using SSH on Windows is still to download a program called PuTTY.
Think of SSH as a Windows Remote Desktop Protocol. If you're new to this world, only it's generally faster to use, owing to the fact it's not got to stream a graphical connection at you. SSH is entirely text-based.
$ ssh [email protected] ssh: connect to host 10.0.2.15 port 22: Connection refused
Oh no! Something is off!
We haven't connected, and the connection was apparently refused!
$ sudo systemctl enable sshd $ sudo systemctl start sshd
You should be prompted (at least once) for your user password that we set earlier.
What we're doing is enabling the
sshd service to start when the server is booted with the first command, and starting it right now with the second (so that we don't have to reboot the VM).
Port Forwarding is the method of manually specifying how traffic is to traverse a NAT'd network. If you were playing Diablo 2 or Warcraft III in the mid-2000s, you may have had great fun trying to get Port Forwarding working with your home router.
From the main VirtualBox window, highlight your VM and click
SettingsÂ at the top.Â Head to the
NetworkÂ section and click the arrow by
AdvancedÂ to drop down a larger section. Click
Notice that we're effectively mapping
127.0.0.1:2222Â on our host to
10.0.2.15:22Â on our guest. We've set it up so that any connection attempt made to the
localhost address of our host machine, on port
2222, gets forwarded to the VM on port
2222 in the example given is entirely randomÂ â it could be
2020, and so on. I chose
2222 for convenience. You shouldn't attempt to use ports lower than
1024 for this sort of thing, as these are restricted to root-only access.
$ ssh [email protected] -p2222 The authenticity of host '[127.0.0.1]:2222 ([127.0.0.1]:2222)' can't be established. ECDSA key fingerprint is SHA256:M2mQKN54oJg3B1lsjJGmbfF/G69MN/Jz/koKHSaWAuU. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '[127.0.0.1]:2222' (ECDSA) to the list of known hosts. [email protected]'s password:
There are some things to break down about this command.
I've specified the username by using
[email protected] and I've told SSH to try connecting to the localhost address
127.0.0.1, along with the port we've chosen, that is,Â
We're presented with the fingerprint of the host, which we'll talk more about later, and which we accept.
We're then prompted to log in, using the password we set up in the VM, for our user:
Last login: Mon Aug 6 15:04:26 2018 [[email protected] ~]$
We can now work on our VM as if it were a real serverÂ â just be mindful to make sure that you're on your VM when running any commands.
$ sudo yum update
When run, you may be presented with a long list of software to update. TypingÂ Y for confirmation and hitting Enter will work through the upgrade of this software, as well as any dependent software that's needed. You may also be prompted to accept new or updated GPG keys.
If you've upgraded software that's constantly running, such as an Apache web server, it can be a good idea to schedule a restart of that service to make sure that the newer version is in use.
As a rule of thumb, the only things that should require a full system reboot after being updated are the kernel and the init (initialization) system. This is a stark difference to Windows, where rebooting seems to be what the OS is designed to do, and actual work is just a by-product.
In my case, my kernel got updated. I'm able to confirm this by doing the following.
First, we list the installed versions of theÂ
$ yum info kernel Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: repo.uk.bigstepcloud.com * extras: mirror.sov.uk.goscomb.net * updates: mirrors.melbourne.co.uk Installed Packages Name : kernel Arch : x86_64 Version : 3.10.0 Release : 862.el7 Size : 62 M Repo : installed From repo : anaconda Summary : The Linux kernel URL : http://www.kernel.org/ Licence : GPLv2 Description : The kernel package contains the Linux kernel (vmlinuz), the core of any : Linux operating system. The kernel handles the basic functions : of the operating system: memory allocation, process allocation, device : input and output, etc. Name : kernel Arch : x86_64 Version : 3.10.0 Release : 862.9.1.el7 Size : 62 M Repo : installed From repo : updates Summary : The Linux kernel URL : http://www.kernel.org/ Licence : GPLv2 Description : The kernel package contains the Linux kernel (vmlinuz), the core of any : Linux operating system. The kernel handles the basic functions : of the operating system: memory allocation, process allocation, device : input and output, etc.
Then, we check the version of the kernel currently in use, using
$ uname -a Linux localhost.localdomain 3.10.0-862.el7.x86_64 #1 SMP Fri Apr 20 16:44:24 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
We can see from this that we're running version
3.10.0-862.el7, but we have
Rebooting the system causes the newer kernel to be selected at boot time, and running
uname again shows a different result:
$ uname -a Linux localhost.localdomain 3.10.0-862.9.1.el7.x86_64 #1 SMP Mon Jul 16 16:29:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Huzzah âÂ we're running the newer kernel!
Earlier, we started talking about VMs and what they are. We're now going to look at a couple of ways of working out if we're in a VM, from inside the machine itself.
One of my favourite tools, dmidecode, can be used to dump a computer's desktop management interface (DMI) table. In practice, this means that it can be used to find out what kind of hardware you're running in a machine.
First, we're going to list the valid
typesÂ we can pass to dmidecode:
$ dmidecode --type dmidecode: option '--type' requires an argument Type number or keyword expected Valid type keywords are: bios system baseboard chassis processor memory cache connector slot
Starting at the top, we're going to use
bios and see if it gives us anything useful:
$ sudo dmidecode --type bios # dmidecode 3.0 Getting SMBIOS data from sysfs. SMBIOS 2.5 present. Handle 0x0000, DMI type 0, 20 bytes BIOS Information Vendor: innotek
GmbHVersion: VirtualBox Release Date: 12/01/2006 Address: 0xE0000 Runtime Size: 128 kB ROM Size: 128 kB Characteristics: ISA is supported PCI is supported Boot from CD is supported Selectable boot is supported 8042 keyboard services are supported (int 9h) CGA/mono video services are supported (int 10h) ACPI is supported
Instantly, we can see
VirtualBox next to
Version, which is a pretty strong hint that we're dealing with a VM.
Next, we will choose something else,
$ sudo dmidecode --type system # dmidecode 3.0 Getting SMBIOS data from sysfs. SMBIOS 2.5 present. Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: innotek GmbH Product Name: VirtualBox Version: 1.2 Serial Number: 0 UUID: BDC643B8-8D4D-4288-BDA4-A72F606CD0EA Wake-up Type: Power Switch SKU Number: Not Specified Family: Virtual Machine
Product Name seen here is
VirtualBox, and the
Virtual Machine, both of which are pretty damning pieces of evidence.
Lastly, we're going to look at the
$ sudo dmidecode --type chassis # dmidecode 3.0 Getting SMBIOS data from sysfs. SMBIOS 2.5 present. Handle 0x0003, DMI type 3, 13 bytes Chassis Information Manufacturer: Oracle Corporation Type: Other Lock: Not Present Version: Not Specified Serial Number: Not Specified Asset Tag: Not Specified Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None
Oracle corporation is, again, a significant piece of information that leads us to believe we're in a virtualized environment.
If we don't want a lot of other information, we can fine-tune our search using dmidecode's
Running this option without an argument outputs a list of potential arguments we can use:
$ sudo dmidecode -s dmidecode: option requires an argument -- 's' String keyword expected Valid string keywords are: bios-vendor bios-version bios-release-date system-manufacturer system-product-name system-version system-serial-number system-uuid baseboard-manufacturer baseboard-product-name baseboard-version baseboard-serial-number baseboard-asset-tag chassis-manufacturer chassis-type chassis-version chassis-serial-number chassis-asset-tag processor-family processor-manufacturer processor-version processor-frequency
Here, we can instantly see
bios-version, and as we know from earlier, it should be
$ sudo dmidecode -s bios-version VirtualBox
$ sudo lshw -businfo Bus info Device Class Description ===================================================== system VirtualBox bus VirtualBox memory 128KiB BIOS memory 1GiB System memory [email protected] processor Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz [email protected]:00:00.0 bridge 440FX - 82441FX PMC [Natoma] [email protected]:00:01.0 bridge 82371SB PIIX3 ISA [Natoma/Triton II] [email protected]:00:01.1 scsi1 storage 82371AB/EB/MB PIIX4 IDE [email protected]:0.0.0 /dev/cdrom disk CD-ROM [email protected]:00:02.0 display VirtualBox Graphics Adapter [email protected]:00:03.0 enp0s3 network 82540EM Gigabit Ethernet Controller [email protected]:00:04.0 generic VirtualBox Guest Service [email protected]:00:05.0 multimedia 82801AA AC'97 Audio Controller [email protected]:00:06.0 bus KeyLargo/Intrepid USB [email protected] usb1 bus OHCI PCI host controller [email protected]:00:07.0 bridge 82371AB/EB/MB PIIX4 ACPI [email protected]:00:0d.0 scsi2 storage 82801HM/HEM (ICH8M/ICH8M-E) SATA Controller [AHCI mode] [email protected]:0.0.0 /dev/sda disk 8589MB VBOX HARDDISK [email protected]:0.0.0,1 /dev/sda1 volume 1GiB Linux filesystem partition [email protected]:0.0.0,2 /dev/sda2 volume 7167MiB Linux LVM Physical Volume partition input PnP device PNP0303 input PnP device PNP0f03
This gives us information that instantly suggests a VM, such as the system, bus, and display entries.
We also have an easy-to-read breakdown of the classes available, meaning that we can query those directly, starting with
disk in this example:
$ sudo lshw -c disk *-cdrom description: DVD reader product: CD-ROM vendor: VBOX physical id: 0.0.0 bus info: [email protected]:0.0.0 logical name: /dev/cdrom logical name: /dev/sr0 version: 1.0 capabilities: removable audio dvd configuration: ansiversion=5 status=nodisc *-disk description: ATA Disk product: VBOX HARDDISK vendor: VirtualBox physical id: 0.0.0 bus info: [email protected]:0.0.0 logical name: /dev/sda version: 1.0 serial: VB5cbf266c-3015878d size: 8GiB (8589MB) capabilities: partitioned partitioned:dos configuration: ansiversion=5 logicalsectorsize=512 sectorsize=512 signature=000b6a88
Alternatively, if we think that's too much information, we could query the system class:
$ sudo lshw -c system localhost.localdomain description: Computer product: VirtualBox vendor: innotek GmbH version: 1.2 serial: 0 width: 64 bits capabilities: smbios-2.5 dmi-2.5 vsyscall32 configuration: family=Virtual Machine uuid=BDC643B8-8D4D-4288-BDA4-A72F606CD0EA
sudo is a contraction of 'superuser do' because
sudo used to be used for running commands as the "superuser" only, nowadays you can use it to run commands as various users.Â
Generally, if you attempt to run a command that you lack permissions to complete successfully, you'll be greeted with an error:
$ less /etc/sudoers /etc/sudoers: Permission denied
Here, I tried to have a look at the
/etc/sudoers file, which also happens to be the file that determines a user's
Running this command with
sudo is a different story. Instead, it opens the file for me, dropping me into the
Toward the bottom of this file, we find the following block:
## Allows people in group wheel to run all commands %wheel ALL=(ALL) ALL
wheel portion of this block is uncommented, and the text above that tells us what that means.
So, the obvious next question is, am I in the
wheel has ancient origins in old-school UNIX installations. These, days it might be called
admin or other. CentOS keeps it classic by using
Thankfully, this is very easy to check âÂ the file in question is always in the same place:Â
Here, we print the contents of the
group file to our screen, and look specifically for
We see the following layout:
We can see that the
password is a lower
x, which means that shadow passwords are being used, the group ID is
10, and the only user in this group is myself:
$ sudo cat /etc/group | grep wheel wheel:x:10:adam
$ groups adam wheel
Being granted the ability to run superuser commands with
sudo isn't the immediate right of everyone on the system, and it's up to the individual company and administration team to decide how that power is distributed.
There are places where everyone in operations has the power of
sudo, and places where one person has that power.
Because of this, various administrators and developers have come up with solutions that make provisioning a VM (or several) a breeze.
If we take a moment to think about the advantages of this approach, it's easy to highlight just a few benefits of automated VM provisioning:
- It eliminates the time it takes to manually type answers into a VM window.
- It allows for the automated running of software tests in a development environment.
- It allows for the sharing of text files that act as recipes for how to build a VM, rather than the shifting of large VM images from station to station. This is a form of Infrastructure as Code (IaC).
One method of automating the deployment of boxes are kickstart files, which are frequently used in large deployments to automatically answer the questions that the installer asks the user.
If you take a look in the
/root/ folder of a CentOS VM, there's a good chance you'll find a file called
anaconda-ks.cfg, which is effectively the kickstart file for the manual steps you took when installing the machine (anaconda being the name of the installer).
These files are tweaked, or written from scratch, and then hosted on a web server, on an installation network, ready to be picked up by an unconfigured machine.
Locally, kickstart files aren't really practical, and they're not quick to work with. We need something that can be set up quickly and easily, but which is also very powerful.
Typically, somewhere, you might find a
Vagrantfile (the name of the core Vagrant... file...) is in a repository of some in-house application.
The developers working on the application pull down the repository to their local machine, and use the Vagrant configuration file to spin up a local development environment, which they can then use to test code changes or feature additions without utilizing expensive development environments.
On my Ubuntu host, I install Vagrant like so:
$ sudo apt install vagrant
There's quite a few dependencies, totalling around 200 MB of used disk space afterwards.
$ vagrant --version Vagrant 2.0.2
I'm quite particular about where I keep my files, so I'm going to create a dedicated folder called
Vagrant in my home directory, which I'll use for working with my Vagrant VMs:
$ ls Desktop Downloads Pictures snap Videos Documents Music Public Templates 'VirtualBox VMs' $ mkdir Vagrant $ cd Vagrant/
Next, we will initialize a new
Vagrantfile. The following command will do this automatically:
$ vagrant init $ ls Vagrantfile
Have a look in the
Vagrantfile, but don't make any changes yet. You'll see that a lot of the options are listed, but commented out by default. This is a good way of introducing you to what Vagrant is capable of.
Note that, by default, Vagrant will attempt to use a box called
base, but will also prompt you to look at https://vagrantcloud.com/search for other boxes:
# Every Vagrant development environment requires a box. You can search for # boxes at https://vagrantcloud.com/search. config.vm.box = "base"
Doing a search for CentOS on
vagrantcloudÂ reveals a nice default box we can use: https://app.vagrantup.com/centos/boxes/7.
It also lists the providers that the box can be provisioned under. VirtualBox is one of them, meaning it will work in our installation.
We need to change our
Vagrantfile to point at this box. From the folder in which your
Vagrantfile exists, run the following:
$ sed -i 's#config.vm.box = "base"#config.vm.box = "centos/7"#g' Vagrantfile
We've just used
sedÂ (a common tool for editing text on the command line, either in files or on standard out) with the
-i option, to modify our
Vagrantfile in-place. Opening the file now will show us that the
base line has changed to point to
$ vagrant up Bringing machine 'default' up with 'virtualbox' provider... ==> default: Box 'centos/7' could not be found. Attempting to find and install... default: Box Provider: virtualbox default: Box Version: >= 0 ==> default: Loading metadata for box 'centos/7' default: URL: https://vagrantcloud.com/centos/7 ==> default: Adding box 'centos/7' (v1804.02) for provider: virtualbox default: Downloading: https://vagrantcloud.com/centos/boxes/7/versions/1804.02/providers/virtualbox.box ==> default: Successfully added box 'centos/7' (v1804.02) for 'virtualbox'! <SNIP> default: No guest additions were detected on the base box for this VM! Guest default: additions are required for forwarded ports, shared folders, host only default: networking, and more. If SSH fails on this machine, please install default: the guest additions and repackage the box to continue. default: default: This is not an error message; everything may continue to work properly, default: in which case you may ignore this message. ==> default: Rsyncing folder: /home/adam/Vagrant/ => /vagrant
All being well, your VM image will start to download from
vagrantcloud, and your box will spin itself up in VirtualBox.
We can even see our VM in the VirtualBox main window:
We can also connect to our new VM using a built-in Vagrant shortcut:
$ vagrant ssh Last login: Tue Aug 7 09:16:42 2018 from 10.0.2.2 [[email protected] ~]$
This means that we've provisioned and connected to a VM in four commands, in summary:
$ vagrant init $ sed -i 's#config.vm.box = "base"#config.vm.box = "centos/7"#g' Vagrantfile $ vagrant up $ vagrant ssh [[email protected] ~]$
We can also destroy any VMs we create from within the same folder that we ran against our
VagrantfileÂ using one command:
$ vagrant destroy
I wrote about manually setting up the VM with VirtualBox (and took all those screenshots) first, because it's good to get into the habit of learning about how things are done manually prior to automating the tedious bits. This same rule can be applied to most software, because even when it takes longer, knowing how something works under the hood makes troubleshooting much easier later on.
You will find that in your career the concept of holy wars is dominant, and every new generation of technology has its apologists and opponents. This is not least seen in the distribution-wars, which has tribal factions staunchly defending their OS of choice. If you ever find yourself in the position of choosing which distribution to install for a company or project, take into consideration everything you've read here, and do your own reading around before blindly accepting one person's opinion as truth.
That's not to say you should become tribal yourself âÂ I've installed all of the preceding distributions at one time or another, the first of which was Ubuntu.
Back in 2005, I learned about this thing called Linux.
Before then, I'd known Macs my entire life, as it was the brand my dad had decided upon. I'd also cobbled together a single Windows machine for the purpose of playing Diablo, though I can't say I ever enjoyed using the OS itself.
Everything changed when I spotted a computer magazine on holiday, and ended up flipping through the various pages until I landed on a piece about Linux, which captured my imagination immediately. Something different and quirky appealed to my rebellious attitude, and as a result I ended up burning this thing called Ubuntu to a CD (or several).
Back then, Canonical would freely send you Ubuntu CDs if you requested them, but I was impatient, and burning disks was quicker.
I made a backup of everything I cared about on my computer, and set about working my way through my first installation once I'd worked out exactly how to boot from a CD. By all accounts it went well, and though I had to nip to another computer occasionally (no smartphones, remember) to look up what certain options meant, I eventually had a shiny new desktop OS installed.
The trouble started around this time.
My wireless card didn't work, the graphics seemed sluggish, and I ran a single update before rebooting, which landed me not on a desktop, but at a command-line interface.
I had never seen a command-line interface before.
To this day, I have no idea how I ever managed to get a functional OS on that box, and I was forever fighting a program called
NdisWrapper to get my wireless to work, or installing proprietary (though I didn't know the word at the time) graphics drivers, which would break as soon as you upgraded the kernel (though again, I had no idea that was what was happening at the time).
I somehow plodded along, soon getting bored of Ubuntu when I discovered different distributions, and spending the next few months with a different desktop every week. I distinctly remember running through Ubuntu, Debian, Fedora, OpenSUSE, and a very, very early attempt at installing Gentoo, which I gave up on after about five minutes.
I ended up on forums frequently, painstakingly copying errors into Google to try and find other people who'd had the issues I was experiencing, and often discovering a post where the poster had inconveniently announced they'd Fixed It! without actually providing the solution they'd used.
All of this, as irritating as it was to me at the time, was a learning experience, and I think my love of Linux and computing in general can be traced back to the first time I installed Ubuntu. Prior to that date, computers had been games machines and that was it.
Soon, I was using Linux Mint to bypass the school firewall, booting to a Live USB drive, and ignoring all the feeble attempts at blocking that the school IT department had enabled (for some reason, they believed Windows was the only OS in existence). I still don't quite know how this worked, but the point was that it did.
Between bouts of World of Warcraft, Linux was something I tinkered with for years, keeping up on the latest releases and installing other distributions to try ("distribution-hopping" frequently). I broke things, fixed them, got angry with Linux, got angry with computers in general, but on the whole, I slowly improved.
Fast forward a little while and generally bad school results meant I bailed out without finishing college, or going to university. I had very little in the way of qualifications, but still had something of an aptitude for computing. I found and went on a course that lasted a few months and resulted in a couple of noddy Microsoft certifications, but which ultimately meant that I had a sparse CV that I could start submitting to companies.
I was called by and went for an interview with a hosting provider based in Manchester, and met with the man who's now the CTO. The interview was weird, with us variously discussing taking computers apart, a bit of Linux, and a lot of Counter Strike, as it turned out he'd played a lot in years past. I left feeling nervous, but fairly amused at how it had gone.
Upon returning, after being called back in, I was fairly stunned to get offered the job of Data Center Engineer, which while not a Linux-focused position, was more than I could have hoped for given my level of education. It made me incredibly happy to be employable, and I'm forever grateful to that company and interviewer for giving me a chance.
The takeaway I'd like to present from this is that Linux is fairly great âÂ it can give even the most academically illiterate of us a decent career, and it's so vibrant and forever evolving that there's always something new to learn. I've met some great people, and learned some fascinating things on my journey, a lot of which I hope to pass on in these pages.
I hope you find the rest of this book informative, whether you're a newcomer to Linux administration, or you're someone experienced that's just checking for tips and tricks you might not know.