How linux works brian ward

moyano83/How-Linux-Works-What-Every-Superuser-Should-Know

Use Git or checkout with SVN using the web URL.

Work fast with our official CLI. Learn more.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

How Linux Works What Every Superuser Should Know

Table of contents:

Chapter 1: The big picture

Levels and layers of abstraction in a linux system

A layer or level is a classification (or grouping) of a component according to where that component sits between the user and the hardware. A Linux system has three main levels: Hardware, kernel and processes which makes collectively the user space. The kernel runs in kernel mode, which has unrestricted access to the processor and main memory. User processes run in user mode, which restricts access to a (usually quite small) subset of memory and safe CPU operations.

Hardware: understanding main memory

Running kernel and processes reside in memory (most important part of hardware), a CPU is just an operator on memory. State in reference to memory, is a particular arrangement of bits.

One of the kernel’s tasks is to split memory into many subdivisions, and it must maintain certain state information about those subdivisions at all times. The kernel is in charge of managing tasks in four general system areas:

Process management describes the starting, pausing, resuming, and terminating of processes. The act of one process giving up control of the CPU to another process is called a context switch (kernel is responsible for this).

The kernel must manage memory during a context switch, for this CPUs include a memory management unit (MMU) which acts like a proxy between process memory and physical location of the memory itself (The implementation of a memory address map is called a page table).

Device Drivers and Management

A device is typically accessible only in kernel mode because improper access could crash the machine and the impedance between devices programming interfaces.

System Calls and Support

system calls (or syscalls) perform specific tasks that a user process alone cannot do it or do well. Two important ones:

Other than init, all user processes on a Linux system start as a result of fork(), and most of the time, you also run exec() to start a new program instead of running a copy of an existing process.

The main memory that the kernel allocates for user processes is called user space. Because a process is simply a state (or image) in memory, user space also refers to the memory for the entire collection of running processes.

A user is an entity that can run processes and own files. A user is associated with a username, the kernel does not manage the usernames, instead, it identifies users by simple numeric identifiers called userids. Users exist primarily to support permissions and boundaries. Every user-space process has a user owner, and processes are said to run as the owner. Groups are sets of users. The primary purpose of them is to allow a user to share file access to other users in a group.

Chapter 2: Basic Commands and Directory Hierarchy

The Bourne shell: /bin/sh

Every Unix system needs the Bourne shell in order to function correctly. The bash shell is the default shell on most Linux distributions, and /bin/sh is normally a link to bash on a Linux system. When you install Linux, you should create at least one regular user in addition to the root user.

Using the Shell

The Shell Window

Standard Input and Standard Output

cat outputs the content of one or more files. Unix processes use I/O streams to read and write data, the source of an input stream can be a file, a device, a terminal, or even the output stream from another process. Pressing ctrl-D on an empty line stops the current standard input entry from the terminal, ctrl-C terminates the process. Standard output is similar. The kernel gives each process a standard output stream where it can write its output.

Some basic commands:

Some essential directory commands:

Shell Globbing (Wildcards)

The shell can match simple patterns to file and directory names, a process known as globbing (i.e. * matches any number of arbitrary characters). The shell matches arguments containing globs to filenames, substitutes the filenames for those arguments, and then runs the revised command line, this is called expansion. The shell glob character ‘?’ instructs the shell to match exactly one arbitrary character. If you don’t want the shell to expand a glob in a command, enclose the glob in single quotes.

Other essential intermediate Unix commands:

Changing your Password and shell

Use the passwd command to change your password, which will ask you for the old password before allowing you to enter the new one.

Environment and shell variables

The Command Path

PATH is an environmental variable that contains a list of system directories that the shell searches when trying to locate a command.

There are two standard de facto for text editors in Unix: vi (faster) and emacs (can do almost anything requires some extra typing to get these features).

Getting online Help

Shell Input and Output

Standard Input Redirection

To channel a file to a program’s standard input, use the operator: head

Understanding Error Messages

Unlike messages from other operating sys- tems, Unix errors usually tell you exactly what went wrong.

Anatomy of a UNIX Error Message

A UNIX error message usually consist of several parts like the command that was erroneous, the file it was acting upon, and the error message. When troubleshooting errors, always address the first error first.

A list of the most common error messages:

Listing and Manipulating Processes

For a quick listing of running processes, just run ps on the command line. This displays the following fields:

The ps command has some useful options:

Shells also support job control, using various keystrokes and commands. You can send a TSTP signal (similar to STOP) with ctrl-Z, then start the process again by entering fg (bring to foreground) or bg (move to background).

file modes and Permissions

Every Unix file has a set of permissions that determine whether you can read, write, or run the file. The first character of the mode is the file type. A dash (-) in this position, denotes a regular file and a (d), denotes a directory. The rest of a file’s mode contains the permissions, which break down into three sets: user, group, and other. Some executable files have an s in the user permissions listing instead of an x. This indicates that the executable is setuid, meaning that when you execute the program, it runs as though the file owner is the user instead of you.

To change permissions, use the chmod command. The command is like this: chmod (target)[+-](permissions) where target is g for group, o for others u for user. You can do this with numbers too, for example with the number 644 you set the following permissions user: read/write; group, other: read You can specify a set of default permissions with the umask shell command, which applies a predefined set of permissions to any new file you create (most common is 022).

A symbolic link is a file that points to another file or a directory, effectively creating an alias (names that point to other names). Denoted by the ‘->’ if the ls command is executed.

Creating Symbolic Links

Archiving and Compressing Files

Compressed Archives (.tar.gz)

Other Compression Utilities

There are other compression utilities like the bzip2. The bzip2 compression/decompression option for tar is j.

Linux Directory Hierarchy Essentials

Here are the most important subdirectories in root:

Other Root Subdirectories

There are a few other interesting subdirectories in the root directory:

The /usr Directory

In addition to /usr/bin, /usr/sbin, and /usr/lib, /usr contains the following:

On Linux systems, the kernel is normally in /vmlinuz or /boot/vmlinuz. A boot loader loads this file into memory and sets it in motion when the system boots. You’ll find many modules that the kernel can load and unload on demand during the course of normal system operation (Called loadable kernel modules).

Running Commands as the Superuser

You can run the su command and enter the root password to start a root shell. This practice works, although: * You have no record of system-altering commands * You have no record of the users who performed system-altering commands * You don’t have access to your normal shell environment * You have to enter the root password

sudo allows administrators to run commands as root when they are logged in as themselves. When you run this command, sudo logs this action with the syslog service under the local2 facility.

To run sudo, you must configure the privileged users in your /etc/sudoers file. An example of this file is below:

The first line defines an ADMINS user alias with the two users, and the second line grants the privileges. The ALL = NOPASSWD: ALL part means that the users in the ADMINS alias can use sudo to execute commands as root. The second ALL means any command. The first ALL means any host. The root ALL=(ALL) ALL means that the superuser may also use sudo to run any command on any host. The extra (ALL) means that the superuser may also run commands as any other user. You can extend this privilege to the ADMINS users by adding (ALL) to the /etc/sudoers line: ADMINS ALL = (ALL) NOPASSWD: ALL

Chapter 3: Devices

The sysfs Device Path

The program dd is extremely useful when working with block and character devices, its function is to read from an input file or stream and write to an output file or stream (dd copies data in blocks of a fixed size). Usage: dd if=/dev/zero of=new_file bs=1024 count=1

device name summary

It can sometimes be difficult to find the name of a device. Some common Linux devices and their naming conventions are:

Hard Disks: /dev/sd*

These devices represent entire disks; the kernel makes separate device files, such as /dev/sda1 and /dev/sda2, for the partitions on a disk. The sd portion of the name stands for SCSI disk (Small Computer System Interface). To list the SCSI devices on your system, use a utility that walks the device paths provided by sysfs. Most modern Linux systems use the Universally Unique Identifier (UUID) for persistent disk device access.

CD and DVD Drives: /dev/sr*

The /dev/sr* devices are read only, and they are used only for reading from discs.

PATA Hard Disks: /dev/hd*

The Linux block devices /dev/hd* are common on older versions of the Linux kernel and with older hardware.

Terminals: /dev/tty*, /dev/pts/*, and /dev/tty

Terminals are devices for moving characters between a user process and an I/O device, usually for text output to a terminal screen. Pseudoterminal devices are emulated terminals that understand the I/O features of real terminals. Two common terminal devices are /dev/tty1 (the first virtual console) and /dev/pts/0 (the first pseudoterminal device). The /dev/tty device is the controlling terminal of the current process. If a program is currently reading and writing to a terminal, this device is a synonym for that terminal. A process does not need to be attached to a terminal. Linux has two primary display modes: text mode and an X Window System server (graphics mode). You can switch between the different virtual environments with the ctrl-alt-Function keys.

Parallel Ports: /dev/lp0 and /dev/lp1

Representing an interface type that has largely been replaced by USB. You can send files (such as a file to be printed) directly to a parallel port with the cat command.

Audio Devices: /dev/snd/*, /dev/dsp, /dev/audio, and More

Linux has two sets of audio devices. There are separate devices for the Advanced Linux Sound Architecture (ALSA in /dev/snd) system interface and the older Open Sound System (OSS).

Creating Device Files

The mknod command creates one device (deprecated). You must know the device name as well as its major and minor numbers.

The Linux kernel can send notifications to a user-space process (named udevd) upon detecting a new device on the system. The user-space process on the other end examines the new device’s characteristics, creates a device file, and then performs any device initialization.

The devtmpfs filesystem was developed in response to the problem of device availability during boot. This filesystem is similar to the older devfs support, but it’s simplified. The kernel creates device files as necessary, but it also notifies udevd that a new device is available.

udevd Operation and Configuration

The udevd daemon operates as follows:

The udevadm program is an administration tool for udevd. You can reload udevd rules and trigger events, but perhaps the most powerful features of udevadm are the ability to search for and explore system devices and the ability to monitor uevents as udevd receives them from the kernel.

To monitor uevents with udevadm, use the monitor command: udevadm monitor

in-depth: scsi and the linux kernel

The traditional SCSI hardware setup is a host adapter linked with a chain of devices over an SCSI bus. This adapter is attached to a computer, the host adapter and devices each have an SCSI ID and there can be 8 or 16 IDs per bus, depending on the SCSI version. The host adapter communicates with the devices through the SCSI command set in a peer-to-peer relationship; the devices send responses back to the host adapter. The SCSI subsystem and its three layers of drivers can be described as:

USB Storage and SCSI

USB is quite similar to SCSI—it has device classes, buses, and host controllers. The Linux kernel includes a three-layer USB subsystem that closely resembles the SCSI subsystem, with device-class drivers at the top, a bus management core in the middle, and host controller drivers at the bottom.

To connect the SATA-specific drivers of the kernel to the SCSI subsystem, the kernel employs a bridge driver, as with the USB drives. The optical drive speaks ATAPI, a version of SCSI commands encoded in the ATA protocol.

Chapter 4: Disks and Filesystems

Partitions are subdivisions of the whole disk, on Linux, they’re denoted with a number after the whole block device. The kernel presents each partition as a block device, just as it would an entire disk. Partitions are defined on a small area of the disk called a partition table. The next layer after the partition is the filesystem, the database of files and directories that you’re accustomed to interacting with in user space.

Partitioning disk devices

There are many kinds of partition tables. The traditional table is the one found inside the Master Boot Record (MBR). A newer standard is the Globally Unique Identifier Partition Table (GPT). Some linux partition tools are:

Viewing a Partition Table

Changing Partition Tables

Changing the partition table makes it quite difficult to recover any data on partitions that you delete because it changes the initial point of reference for a filesystem, yo need to ensure that no partitions on your target disk are currently in use. Different tools can be used to create the partitions, like parted, gparted, gdisk or fdisk. fdisk and parted modify the partitions entirely in user space.

Disk and Partition Geometry

The disk consists of a spinning platter on a spindle, with a head attached to a moving arm that can sweep across the radius of the disk, even though you can think of a hard disk as a block device with random access to any block, there are serious performance consequences if you aren’t careful about how you lay out data on the disk.

Solid-State Disks (SSDs)

In olid-state disks (SSDs), random access is not a problem because there’s no head to sweep across a platter, but some considerations like partition alignment (data is read in blocks of fixed size, if data is laid in two blocks you need to do two reads even if the amount of data to read is less than the block size).

A filesystem is a form of database; it supplies the structure to transform a simple block device into the sophisticated hierarchy of files and subdirectories that users can understand. Filesystems are also traditionally implemented in the kernel, but there are also file System in User Space (FUSE) and Virtual File Systems (VFS).

These are the most common types of filesystems for data storage. The type names as recognized by Linux are in parentheses next to the filesystem names:

Creating a Filesystem

To create filesystems as with partitioning, you’ll do this in user space because a user-space process can directly access and manipulate a block device. The mkfs utility can create many kinds of filesystems:

Mounting a Filesystem

The process of attaching a filesystem is called mounting. When the system boots, the kernel reads some configuration data and mounts root (/) based on the configuration data.In order to mount a filesystem, you must know the following:

Disk Buffering, Caching, and Filesystems

Unix buffers writes to the disk, when you unmount a filesystem with umount, the kernel automatically synchronizes with the disk. You can force the kernel to write the changes in its buffer to the disk by running the sync command.

Filesystem Mount Options

Some important options of the mount command:

Remounting a Filesystem

The /etc/fstab Filesystem Table

Linux systems keep a permanent list of filesystems and options in /etc/fstab. Each line describes a filesystem with the following fields:

Alternatives to /etc/fstab

Alternatives to the /etc/fstab file are /etc/fstab.d directory that contains individual filesystem configuration files and to configure systemd units for the filesystems.

To view the size and utilization of your currently mounted filesystems, use the df command. The output contains:

If your disk fills up and you need to know where the space is allocated, use the du command.

Checking and Repairing Filesystems

If errors exist in a mounted filesystem, data loss and system crashes may result. The tool to check a filesystem is fsck there are different version of fsck for each filesystem type that Linux supports). To run fsck in interactive manual mode (-n for automatic mode), give the device or the mount point (as listed in /etc/fstab) as the argument:

Checking ext3 and ext4 Filesystems

You may wish to mount a broken ext3 or ext4 filesystem in ext2 mode because the kernel will not mount an ext3 or ext4 filesystem with a nonempty journal. To flush the journal in an ext3 or ext4 filesystem to the regular filesystem database, run e2fsck as follows e2fsck –fy /dev/disk_device

The debugfs tool allows you to look through the files on a filesystem and copy them elsewhere.

Most versions of Unix have filesystems that serve as system interfaces. That is, rather than serving only as a means to store data on a device, a filesystem can represent system information such as process IDs and kernel diagnostics. The special filesystem types in common use on Linux include the following:

If you run out of real memory, the Linux virtual memory system can automatically move pieces of memory to and from a disk storage (swapping). The disk area used to store memory pages is called swap space (to view the current swap memory use the free command).

Using a Disk Partition as Swap Space

Using a File as Swap Space

Use these commands to create an empty file, initialize it as swap, and add it to the swap pool:

How Much Swap Do You Need?

Unix conventional wisdom said you should always reserve at least twice as much swap as you have real memory.

Inside a Traditional Filesystem

A traditional Unix filesystem has two primary components: a pool of data blocks where you can store data and a database system that manages the data pool. The database is centered around the inode data structure. An inode is a set of data that describes a particular file, including its type, permissions and where in the data pool the file data resides. inodes are identified by numbers listed in an inode table.

Viewing Inode Details

Chapter 5: How the Linux Kernel Boots

A simplified view of the boot process looks like this:

There are two ways to view the kernel’s boot and runtime diagnostic messages:

Kernel Initialization and Boot Options

Upon startup, the Linux kernel initializes in this general order:

When running the Linux kernel, the boot loader passes in a set of text-based kernel parameters that tell the kernel how it should start. These parameters are at /proc/cmdline. The most important parameter is the root parameter, which is the location of the root filesystem (without it, the kernel cannot find init and therefore cannot perform the user space start). Upon encountering a parameter that it does not understand, the Linux kernel saves the parameter. The kernel later passes the parameter to init when performing the user space start.

A boot loader starts the kernel and starts it with a set of parameters. The kernel and its parameters are usually somewhere on the root filesystem, and even when the kernel parameters or disk drivers hasn’t been loaded, it is possible to load the kernel because nearly all disk hardware has firmware that allows the BIOS to access attached storage hardware with Linear Block Addressing (LBA).

Boot Loader Tasks

A Linux boot loader’s core functionality includes the ability to do the following:

GRUB (Grand Unified Boot Loader) is a near-universal standard on Linux systems and has a filesystem navigation that allows for much easier kernel image and configuration selection. GRUB doesn’t really use the Linux kernel, it starts it.

Exploring Devices and Partitions with the GRUB Command Line

GRUB has its own device-addressing scheme, named hdx where x is 0,1. GRUB has also a command line (access it by pressing C at the boot menu), where you can do:

The GRUB configuration directory contains the central configuration file (grub.cfg) and numerous loadable modules with a .mod suffix. The directory is usually /boot/grub or /boot/grub2. Use grub-mkconfig command to modify this file.

Reviewing the Grub.cfg

the grub.cfg file consists of GRUB commands, which usually begin with a number of initialization steps followed by a series of menu entries for different kernel and boot configurations. Later in this file you should see the available boot configurations, each beginning with the menuentry command.

Generating a New Configuration File

To make changes to your GRUB configuration, add your new configuration elsewhere, then run grub-mkconfig to generate the new configuration. Every file in /etc/grub.d is a shell script that produces a piece of the grub.cfg file. The grub-mkconfig command itself is a shell script that runs everything in /etc/grub.d.

Installing GRUB on Your System

GRUB comes with a utility called grub-install, which performs most of the work of installing the GRUB files and configuration for you.

Installing GRUB on an External Storage Device

Installing GRUB with UEFI

Chainloading Other Operating Systems

UEFI makes it relatively easy to support loading other operating systems because you can install multiple boot loaders in the EFI partition but the older MBR style doesn’t support it.

Boot Loader Details

The Master Boot Record (MBR) includes a small area (441 bytes) that the PC BIOS loads and executes after its Power-On Self-Test (POST), but usually additional space is necessary, resulting in what is sometimes called a multi-stage boot loader (MBR does nothing other than load the rest of the boot loader code).

In summary, GRUB does the following:

Chapter 6: How User Space Starts

User space starts in roughly this order:

Introduction to init

The init program is a user-space program like any other program on the Linux system, and you’ll find it in /sbin along with other system binaries. Its main purpose is to start and stop the essential service processes on the system. There are three major implementations:

System V Runlevels

Identifying your init

The systemd init handles the regular boot process and aims to incorporate a number of standard Unix services (cron, inetd). It has the ability to defer the start of services and operating system features until they are necessary.

Book review: How Linux Works by Brian Ward

Ok, so you are a Linux user or a power user. The question then is what does it take to become a valid, omnipotent, root-enabled superuser? One potential answer is read the book How Linux Works, by Brian Ward and published by No Starch Press, by the last word of the last chapter you may or may not have been transformed, a wizard waiting to be born.

The book’s cover

A superuser requires a consistent knowledge level across a wide array of topics. When I first started with Linux (I believe my first serious paid efforts were around ’94/’95), I learnt much by doing and interacting with the command line prompt. However, this method leaves you open to gaps in your knowledge. You may understand IPtables for firewalling, but do you necessarily have fine control over consistent packaging or accurate placement of binaries under the correct directory structure. Brain Ward’s well written commentary definitely covers all the necessary bases.

The contents

How Linux works is 368 pages in extent and covers 17 chapters of helpful supportive and digestible wisdom. Starting from the basics and building your fundamental knowledge up from filesystems such as ext2, ext3, booting, network, shell scripting, maintaining the kernel. There is not a moment during the reading process that you feel the content is anything but relevant to the learning task at hand.

This book avoids command-line-only learning and gives a consistent and solid foundation for any new superuser

One approach to solidifying previous knowledge is to sit by the computer and fire off commands mentioned in the book as you read; Install that Samba server, backup whole directory structures, manipulate iptables. Make mistakes and start again. Well OK, then learn backing up first—where was that live cd again?

Who’s this book for?

This book is for those users that wish to learn evenly the spread of knowledge of the workings of Linux so that the soon to be superuser can perform administrative actions with a consistency and level of quality that is effective.

Relevance to free software

Linux is the flagship combination of free software. This book discusses only Linux and its interactions. Sure, the author mentioned Samba and how the application can help with coexistences with Windows and Apple Macs both of which speak the SMB protocol. However, the book would not have been realistic without such instruction.

Brian Ward’s written words also mention a number of free software servers, and small tools such as openssh, rsync, CUPS, diff, cpio. And, just as importantly, he zoomed into the basic requirements of any Super User—how to make packages and where to find libraries and configure within a standard file structure.

How Linux Works is a consistent and evenly spread book dealing with all the main themes that a system administrator requires.

This proactive book correctly covers many of the little details that aid in the daily life of administration. For example, bandwidth throttling of rsynch (page 300), or how to redirect standard error to a file (page 16), or command line disk mounting (page 45). Better still, there is a consistency of knowledge distribution across topics that build to a strong foundation and will definitely help generate some semblance of self-confidence for first time system administrators

Despite having been first published two years ago—a long time in internet time—every word is still relevant to the budding newbie administrator.

Every word is still relevant

The book’s reading marketplace has almost reached saturation with more than a few similar tomes discussion running and maintaining Linux. This makes it difficult to choose which quality effort would be the best to read for a target audience of a beginner system administrator. However, that negative aside, Brian Ward’s book is well worthy of its price.

How Linux Works: What Every Superuser Should Know

Get A Copy

Friend Reviews

Reader Q&A

Be the first to ask a question about How Linux Works

Lists with This Book

Community Reviews

340 pages long, it’s hard to find one this complete and educational. Out of the dozens of books I’ve bought on Linux, this is the one I keep turning to over and over again.

True, with the more recent live-cd’s and other gadgets made for the general public, you may not use some of the things written in this book (old utilities, &c) but it really has everything you should know to maintain and develop on these systems.

Especially if you’re going to install Linux on For making a book about Linux only

340 pages long, it’s hard to find one this complete and educational. Out of the dozens of books I’ve bought on Linux, this is the one I keep turning to over and over again.

True, with the more recent live-cd’s and other gadgets made for the general public, you may not use some of the things written in this book (old utilities, &c) but it really has everything you should know to maintain and develop on these systems.

Especially if you’re going to install Linux on some old’n’busted machines or some low-powered embedded systems that can’t handle all the bloat of the name-brand SUSE/RedHat/Ubuntu shizzle, you’ll find this book invaluable.

I’ve been reading quite a few books on Linux recently, and this one has been the most comprehensive and technical. It was actually a bit of a challenge for me to get through, and I took a lot of notes.

The author does not always articulate himself as clearly as I would like, but it covered a lot of concepts relevant to the LPIC-1 exam (including the boot process, bash scripting, libraries, managing files, etc.) plus more, and did so in far greater depth than a lot of the other material I’ve been I’ve been reading quite a few books on Linux recently, and this one has been the most comprehensive and technical. It was actually a bit of a challenge for me to get through, and I took a lot of notes.

The author does not always articulate himself as clearly as I would like, but it covered a lot of concepts relevant to the LPIC-1 exam (including the boot process, bash scripting, libraries, managing files, etc.) plus more, and did so in far greater depth than a lot of the other material I’ve been using.

I can say with confidence that this is one of the most useful books I have ever read as a beginner. I like the fact that the book covers so many topics and it gives you a very good jump start as a Linux user. I would recommend this book to everyone who wants an introduction to Linux at a beginner or intermediate level.

I bought the paperback copy of the second edition of How Linux Works and read it with pleasure while commuting. I read the book while attending the Operating Systems and Computer N I can say with confidence that this is one of the most useful books I have ever read as a beginner. I like the fact that the book covers so many topics and it gives you a very good jump start as a Linux user. I would recommend this book to everyone who wants an introduction to Linux at a beginner or intermediate level.

I bought the paperback copy of the second edition of How Linux Works and read it with pleasure while commuting. I read the book while attending the Operating Systems and Computer Networks courses in the university where I studied and practiced almost everything covered in the book.

Wish I had read this book earlier.

EDIT: I finished the Operating Systems course with the 2nd highest score from more than 100 people after finishing the book. And the next year I became a teaching assistant for this course and I started teaching GNU/Linux. I am doing it 2nd year in a row now. Of course, I read other sources too, but this book gave me the jump start. Thank you!

Another great title published by No Starch Press. If you are a Linux power user, Brian definitely knows how to properly feed your desire to know more about what’s happening under the hood, without getting into the details of titles such as The Linux Programming Interface or Advanced Programming in the UNIX Environment. Easy to read and follow, it’s a long long talk about many of the topics that make Linux what it is today.

I don’t remember a single tech book published by No Starch Press that did Another great title published by No Starch Press. If you are a Linux power user, Brian definitely knows how to properly feed your desire to know more about what’s happening under the hood, without getting into the details of titles such as The Linux Programming Interface or Advanced Programming in the UNIX Environment. Easy to read and follow, it’s a long long talk about many of the topics that make Linux what it is today.

I don’t remember a single tech book published by No Starch Press that did not deliver. How Linux Works certainly does. It gives the reader a good understanding of many hot topics of the Linux internals without getting too technical. It’s like a long long talk with one of those friendly geek guys that has been tinkering the kernel forever.

Brian covers many different subject. Among them, I have absolutely enjoyed the chapter dedicated to the booting process. Here the author gives you both an overall and a specific vision of the whole process, from boot loaders to the different major init implementation (systemd, Upstart, and System V).

Another juicy chapter is that dedicated to networking and firewalls. Lots and lots of concepts to learn and notes to take.

The book ends with several chapters dedicated to developers. These cover some basic shell scripting and developing. Not my favorite part of the book. Mainly, there are other titles that cover those subject in depth (see above).

Overall, a very nice title for anyone interested in knowing how Linux works, without getting too technical.

Suggested readings:
Linux Shell Scripting Cookbook: a very similar title, but focused towards scripting and thus, a little more oriented to System Administrators, rather than Power Users.

This is overall an excellent book. I’ve been working with computers for 25 years and learned a fair bit from this book. It is in fact a great introduction to operating systems and computers in general, not just Linux. I think if someone ever asked me «how do computers work?» I would not hesitate to point them to this book to build a holistic picture.

However, despite how condensed the material is, the sheer breadth of content found in this book got a little out of hand in my opinion. It covers li This is overall an excellent book. I’ve been working with computers for 25 years and learned a fair bit from this book. It is in fact a great introduction to operating systems and computers in general, not just Linux. I think if someone ever asked me «how do computers work?» I would not hesitate to point them to this book to build a holistic picture.

However, despite how condensed the material is, the sheer breadth of content found in this book got a little out of hand in my opinion. It covers literally everything you could possibly think of and then some, from SCSCI and spinning drive internals over boot manager configuration, networking protocols, the X window system to at least honorable mentions of some popular programming languages and databases. Considering that all of this had to fit onto

400 pages, it’s an incredible feat, but due to the lack of depth in some of these sections, I wonder what the intended audience was for those, as for both layman and expert alike some sections were too shallow to be useful.

But for any section that lacked depth, there were 5 others that did not, so there is still a wealth of information here that is useful to pretty much anyone with an interest in computers and operating systems.

This book doesn’t claim to cover all Linux features, but definitely it covers some of the most important ones.

It’s easy to read, though it encompasses lots of useful information. I wish my first Linux book was like that.

The only complaint I had with it was that though its second edition has been recently issued and it wasn’t strictly specified on which Linux distribution should I run some of the commands from the book I wasn’t able to try some of them due to that there were no such packages in t This book doesn’t claim to cover all Linux features, but definitely it covers some of the most important ones.

It’s easy to read, though it encompasses lots of useful information. I wish my first Linux book was like that.

The only complaint I had with it was that though its second edition has been recently issued and it wasn’t strictly specified on which Linux distribution should I run some of the commands from the book I wasn’t able to try some of them due to that there were no such packages in the APT repository for reference Ubuntu Docker image I’ve been using.

This is definitely not a book I would recommend to a SysOps, unless he needs to quickly brush-up his skills. But if you’re a «superuser», that’s the book you should definitely read to know what’s «inode» any why top&vmstat&iotop might be much more powerful than you’ve thought.

Absolutely the best Linux book I’ve read.

A good mix of practical and theoretical content really lives up to the title «What every superuser should know». I’ve been using Linux for quite some time but there are a few things I never quite understood but the book really helped me learn it and manipulate it like an expert.

I will say I recommend, anyone reading have at least an intermediate level understanding of Linux. If you’re a beginner I would say try another book and come back to this once yo Absolutely the best Linux book I’ve read.

A good mix of practical and theoretical content really lives up to the title «What every superuser should know». I’ve been using Linux for quite some time but there are a few things I never quite understood but the book really helped me learn it and manipulate it like an expert.

I will say I recommend, anyone reading have at least an intermediate level understanding of Linux. If you’re a beginner I would say try another book and come back to this once you’ve cut your teeth on a few compiler problems.

After a brief chapter on the most basic of GNU/Linux command-line tools, Ward dives right into Linux internals, starting with a lengthy walk-through of the boot process. followed by in-depth coverage of devices, file systems, and networking.

The final third of the book covers applications, the desktop, and development tools.

I can see this being useful as a thorough introduction to Linux for someone who plans to spend a lot of time doing Linux-y things; and also as a refresher/tutorial/quasi-refer After a brief chapter on the most basic of GNU/Linux command-line tools, Ward dives right into Linux internals, starting with a lengthy walk-through of the boot process. followed by in-depth coverage of devices, file systems, and networking.

The final third of the book covers applications, the desktop, and development tools.

I can see this being useful as a thorough introduction to Linux for someone who plans to spend a lot of time doing Linux-y things; and also as a refresher/tutorial/quasi-reference if you want to do something like setup a samba server or figure out how to get a printer connected.

«How Linux Works» does what it describes. Brian Ward takes us on a whirlwind tour of the Linux Operating System. There are numerous flavors of Linux available, so Ward tells you which one he is talking about in the text. Ward would prefer that you had a copy of Linux available to work on while you read this book, but I did not have that privilege. I do most of my reading at work and do not have access to a computer there.

The book does not go into the history of Linux. Ward makes some recommendat «How Linux Works» does what it describes. Brian Ward takes us on a whirlwind tour of the Linux Operating System. There are numerous flavors of Linux available, so Ward tells you which one he is talking about in the text. Ward would prefer that you had a copy of Linux available to work on while you read this book, but I did not have that privilege. I do most of my reading at work and do not have access to a computer there.

The book does not go into the history of Linux. Ward makes some recommendations if you are interested in that aspect of the Linux OS.

Just so happened that my local library had this book so I picked it up.

It was pretty dang good. My only complaint really is that sometimes it felt like a topic was mentioned without really explaining it enough (like how a connection stays open) but at the same time I recognize the limits of the book not being able to go into every detail.

Overall, for someone who has used linux for years I still learned a lot and quite enjoyed reading it. It is a good mix of how to and history of why things got t Just so happened that my local library had this book so I picked it up.

It was pretty dang good. My only complaint really is that sometimes it felt like a topic was mentioned without really explaining it enough (like how a connection stays open) but at the same time I recognize the limits of the book not being able to go into every detail.

Overall, for someone who has used linux for years I still learned a lot and quite enjoyed reading it. It is a good mix of how to and history of why things got to be how they are.

I wasn’t taking extensive notes since much of it was review but I did jot down a few things from each chapter.

Ch1
Most processes run in user mode
Ones that don’t are in kernel mode and have unrestricted access to the hardware
Even root user is not operating in kernel mode

Ch2
Shell variables are not passed to programs you call. Only env variables are.
Use export for env variables
Use this=that for shell variables

In the PS command time is how much time actually using CPU happened. Different from wall-clock time of his long since a process started

Ch 3
Device files are one way of interacting with devices on Linux. There are 4 different types: block, character, pipe, socket
VM disks may have a different ptevis like /dev/xvd
SCSI is a lot to understand
Writing to an optical drive is not part of the kernel because it’s not critical to any system

Ch 4
Btrfs is positioned to replace ext4
LVM logical volume manager makes it much easier to work with storage

Ch 5
Linux kernel booting and EFI and MBR and all that fun stuff

Ch 6
Learned much about systemd and how user space starts

Ch 7
Learned about the at command for scheduling things in the future
Learned a bit about Pam the plugable authentication module

Ch 8
lsof let’s you see which files a process has opened
strace and ltrace are powerful debugging tools I should learn
Threads are similar to processes but multiple threads in a process can share the same resources.
You can change the nice value of a process to deprioritize it so it doesn’t bog down other processes. The higher the nice value the nicer the process is being to other processes and therefore the less priority it gets

Ch 9
Wow there’s a lot that goes into networking. Now I know a little bit more about TCP, UDP, NAT, ARP, and more

Ch 10
Nice explanation of more user level networking

Ch 11
Mktmp is an awesome command for making temp files

Ch 12
File sharing has so many options still and no clear winner

Ch 13
To change what you see when you open the terminal change the prompt
Aliases are not great because of the confusion from them and it’s not easy to see where they are configured

Ch 14
Transition from xorg to Wayland
Dbus is desktop bus to let programs talk to each other or learn about events such as USB stick being added
Printing is kinda complicated

Ch 15
Reaffirmed I don’t want to work with C.
Compilers are complicated

Ch 16
Wow compiling big software projects seems like a serious amount of work

Standard Linux introduction books concentrate on the shell functions and describe how to become productively in the file system and in the shell. However, if you are interested in a more detailed approach to the Linux operating system and how its components interplay, you are faced with heavy tomes whose page numbers easily exceed 1000. Notable mentions include Unix Power Tools by Jerry Peek et al., Unix in a Nutshell by Arnold Robbins et al. and the UNIX and Linux System Administration Handbook Standard Linux introduction books concentrate on the shell functions and describe how to become productively in the file system and in the shell. However, if you are interested in a more detailed approach to the Linux operating system and how its components interplay, you are faced with heavy tomes whose page numbers easily exceed 1000. Notable mentions include Unix Power Tools by Jerry Peek et al., Unix in a Nutshell by Arnold Robbins et al. and the UNIX and Linux System Administration Handbook by Nemeth et al. In order to be comprehensive, these books cover both Unix and Linux, and therefore contain in parts less relevant Input, depending to which of the two camps you belong.

Less is more and ‘How Linux Works’ limits its scope only to Linux-based operating systems with an easily digestible level of detail where one is not in danger of losing orientation. The strength of the book are in the description of the Kernel boot process, the structure and mounting of the file system. For instance, the communication with the file system devices is explained. Furthermore, the initialization of the User space is described, including run levels and the common implementations of the Init process (systemd and Upstart). The next part deals with networking: internet layer, private networks, routing, Firewall, file transfer tools and the most important commands for adminstration. The last part covers in detail the C++ Compiler as well as the building of libraries and packages from source with Make.

Got the 2nd edition.

My son and I built a Linux computer last year, so I was looking for a book that would serve as a good reference for him as well as a good way for me to brush up.

I’ve used Linux or some flavor of Unix or BSD for most of my career, though I’ve focused on different areas at different times. Even though I knew at least half of it, some of my knowledge was out of date — they are rewriting init. — and it’s always good to read through a topic systematically rather than picking it Got the 2nd edition.

My son and I built a Linux computer last year, so I was looking for a book that would serve as a good reference for him as well as a good way for me to brush up.

I’ve used Linux or some flavor of Unix or BSD for most of my career, though I’ve focused on different areas at different times. Even though I knew at least half of it, some of my knowledge was out of date — they are rewriting init. — and it’s always good to read through a topic systematically rather than picking it up on the streets like I did. For example, I’ve dinked around with BIOS and Grub and init separately but never really stopped to think about how they might be interconnected.

Towards the end the book gets a little scattershot with topics on shell scripting and file copying, but I consider this bonus material after all the good coverage of internals. And there are lots of pointers to further reading.

I use Linux almost every day, having learned it mostly from web-based articles. I started the book with the intention of just picking through it to find things I didn’t already know, but it’s so well written and accessible that I ended up reading it cover-to-cover. At 392 pages it’s actually one of the shorter Linux books out there, but that’s because the author does a good job of focusing on things that are useful and non-obvious.

A great book on Linux. It helps if you are already slightly familiar with Linux, because there is not a lot of handholding. It’s not unapproachable for beginners, but it will be a much easier read with some basic knowledge.

It covers a wide range of topics related to Linux. It covers them in varying depths. Some topics he goes way in-depth on. Others he just gives you a basic starting point and then points you towards further resources. It’s mostly centered around the CLI, although it does briefl A great book on Linux. It helps if you are already slightly familiar with Linux, because there is not a lot of handholding. It’s not unapproachable for beginners, but it will be a much easier read with some basic knowledge.

It covers a wide range of topics related to Linux. It covers them in varying depths. Some topics he goes way in-depth on. Others he just gives you a basic starting point and then points you towards further resources. It’s mostly centered around the CLI, although it does briefly touch on the Desktop. It also does a fairly good job at being distirbution agnostic so whatever flavor of Linux you are using, you will still find it useful.

In the end, I feel like I have a pretty good handle on the big picture and most of the basics. A few of the sections went a little over my head. I will certainly be referring to it as a reference book for the foreseeable future.

Main Menu

Reviews

How Linux Works: What Every Superuser Should Know

(Dr.) Brian Ward, Author

How Linux Works; What every superuser should know, is described by the publisher as a book suitable for systems administrators and home users if they want to know “how it boots, how networking works, how to customize the kernel…all of which you need to understand before you can master the Linux internals.»

This book seems most oriented towards readers that are somewhat technically-proficient and anxious to take a peek ‘under’ the Linux hood to better understand file modes and permissions, error messages, scripts, and symbolic links. It is not a step-by-step how-to guide that starts with general concepts, moves to the specifics, and then walks you through your exploration; it just provides a general introduction to selected components of Linux (and it’s kissing cousin UNIX).

Content is divided into chapters such as The Basics, How Linux Boots, Configuring Your Network, Development Tools, and Printing. Within each chapter is a collection of related sub-topics. The author generally takes each sub-topic, provides some general insight and includes a brief example or two. The subject of text editors is handled in two-thirds of one page with the author briefly discussing the major attributes of two popular editors and leaving the choice to you based on your personality. In the case of utilities, the author briefly explains what the utility is for and then provides an example of a command using that utility.

The publishers have generously provided examples of the content: Chapter 3, How Linux Boots (PDF) can be found at http:// www.nostarch.com/download/howlinuxworks_ch3.pdf, and Chapter 10, Maintaining the Kernel (PDF) can be found at http:/ /www.nostarch.com/download/ howlinuxworks_ch10.pdf The author’s writing style is generally easy to read and he has apparently worked hard to avoid being too technical and detailed.

On the other hand, I found some of the book’s organization and content to be a little confusing. For example, the basename command is described as a way to strip the extension off of a file name. Naturally, my question is why would I want to because that is not a wise move in the Windows or DOS world. For the truly technical this book may prove disappointing because of its lack of depth. For those only familiar with the GUI-side of Windows, it may also prove disappointing. In Windows, Microsoft has gone to considerable effort to shield users from the complexities of the underlying operating system. To print a document in Windows you click on a printer icon.

This book takes you through the multiple system components, control files, servers, filters and more required to simply print
your documents. To get the most from this book, the reader should have a Linux system already installed, create a backup to allow easy recovery if you mess up, and then go through the book several time while actually experimenting with the various commands, modifying scripts, or installing a new application. This will build confidence and allow the reader to familiarize himself with the basic technical details needed to navigate, configure and control Linux.

Linux Guide/How Linux Works

Contents

The Linux Philosophy [ edit | edit source ]

Linux is built with a certain set of unifying principles in mind. Understanding these principles is very helpful in understanding how the system works as a whole. They are known as the «Linux Way», which is derived from the philosophy behind the UNIX system.

The Linux Way can be summarized as:

Most traits of Linux are a consequence of these principles. In accordance with them, a Linux system is built out of small, replaceable components. We will examine the most important of them in more detail. Those are: the boot loader, the kernel, the shell, the X window server, the window manager and the desktop environment. After that, we will have a look at the file system in Linux. Finally, we will discuss the security of a computer running Linux.

Core components of a Linux system [ edit | edit source ]

Boot loader [ edit | edit source ]

This is the part of the system that is executed first. When you have only one operating system installed, it simply loads the kernel (see below). If you happen to have multiple operating systems or multiple versions of the Linux kernel installed, it allows you to choose which one you want to start. The most popular bootloaders are GRUB (GRand Unified Bootloader) and Lilo (LInux LOader). Most users don’t need to care about the boot loader, because it is installed and configured automatically. Actually, the boot Loader creates the boot sequence that the Linux Kernel requires, loading the kernel and some device drivers required for early boot process into memory (as part of so-called «initramfs»), and starting the kernel.

Kernel [ edit | edit source ]

The kernel is the central component of the system that communicates directly with the hardware. In fact, the name «Linux» properly refers to a particular kind of this piece of software. It allows programs to ignore the differences between various computers. The kernel allocates system resources like memory, processor time, hard disk space and external devices to the programs running on the computer. It separates each program from the others, so that when one of them encounters an error, others are not affected. Most users don’t need to worry about the kernel in day-to-day use, but certain software or hardware will require or perform better with certain kernel versions.

Daemons [ edit | edit source ]

In a typical Linux system there are various services running as processes in the background, taking care of things like configuring your network connection, responding to connected USB devices, managing user logins, managing filesystems, etc. They are often called «daemons», because they are running silently and are mostly invisible to the user.

Shell [ edit | edit source ]

The shell, sometimes also called «command line», implements a textual interface that allows you to run programs and control the system by entering commands from the keyboard. Without a shell (or something that can replace it, like a desktop environment) making your system actually do something would be difficult. The shell is just a program; there are several different shells for Linux, each of which offering somewhat different features. Most Linux systems use the Bourne Again Shell (Bash). Linux shells support multitasking (running several programs at once).

X Window Server [ edit | edit source ]

The X window server is a graphical replacement for the command shell. It is responsible for drawing graphics and processing input from the keyboard, mouse, tablets and other devices. The X server is network transparent; that is, it allows you to work in a graphical environment both on your own computer and on a remote computer to which you connect across a network. The X server that is most used today is X.Org. Most graphical programs need only the X server to run, so they can be used under any window manager and desktop environment.

Window Manager [ edit | edit source ]

The window manager is a program that communicates with the X server. Its task is managing windows. It is responsible for drawing the window borders, bringing a window to the front when you click it, moving it on the screen and hiding it when you minimize its program. Examples of popular window managers are:

Desktop Environment [ edit | edit source ]

Desktop environments such as GNOME Desktop Environment, KDE and Xfce are collections of programs designed to present a consistent user interface for most common tasks. They are what most people mean when they say «operating system» even though they are only a piece of the whole operating system. Multiple desktop environments can coexist on the same machine. They can be easily installed and after installation the user will be given a way to select which DE to start the session with.

File System [ edit | edit source ]

There are several file systems that Linux-based distributions use. They are BTRFS, EXT3/4, VFS, NILFS, and SquashFS.

The hard drive of your computer has a rather simple interface. It only accepts commands like «read block no. 550923 and put it in memory address 0x0021A400». Suppose you are editing a piece of text and want to save it on the disk. Using block numbers (addresses) to identify pieces of data, like your text, is awkward: not only would you have to tell your program where to save the file using raw block numbers, you would have to make sure that these blocks aren’t already being used for family photos, your music collection, or even your system’s kernel. To solve this, files were introduced. A file is an area of the disk which stores data and which has a name (like «example.txt»). Files are organized in collections called directories. Directories can contain other directories, in a tree-like structure. Each file can be uniquely identified by a «path,» which describes its place in the directory hierarchy. For the remainder of this section, it will be assumed that you are familiar with files, directories, and paths.

In Linux, the top-level directory is called the root directory. Every file and directory in the system must be a descendant of the root directory. (It is common to talk about directories using the terminology of family relations, like «parent,» «child,» «descendant,» «ancestor,» «sibling,» and so forth.) Names of files and directories can contain all characters except the null character (which is impossible to enter from the keyboard) and the «/» character. An example path would be:

This path refers to a file called «error.log» which is found in a directory called «apache,» which is a subdirectory of a directory called «logs,» which is subdirectory of a directory called «var,» which is a subdirectory of the root directory. The root directory doesn’t have a name like the other; it is just denoted with a «/» character at the beginning of the path.

The root directory usually contains only a small number of subdirectories. The most important are:

Devices as files [ edit | edit source ]

Where are the drive letters? [ edit | edit source ]

If you have used Windows, you might be surprised that there are no drive letters in Linux. The root directory represents the drive on which the system is installed (C: in Windows). Other drives can be «mounted» or «unmounted» in any directory (preferably, an empty one) in the file system. By mounting a disk, you attach the root directory of this disk to a directory in the file system. After that, you can access the disk like it were a part of your system disk. For example: if you have a disk that contains a directory text, which in turn contains a file called linux-intro.tex and you mount this drive in the directory /media/usbkey, you can access the file linux-intro.tex through the path /media/usbkey/text/linux-intro.tex.

Users [ edit | edit source ]

The user is a metaphor for somebody or something interacting with the system. Users are identified by a user name and a password. Internally, each user has a unique number assigned, which is called a user ID, or UID for short. You only need to know your UID in some rare situations. Users can additionally be organized in groups. There is one special user in all Linux systems, which has the user name «root» and UID 0. It is also called the superuser. The superuser can do anything and is not controlled in any way by the security mechanisms. Having such a user account is very useful for administrative tasks and configuring the system. In some distributions (like Ubuntu) direct access to the root account is disabled and other mechanisms are used instead.

If you have more than one user account on a Linux system, you do not need to log out and back again to switch impersonations. There are special shell commands that allow you to access files and execute programs as other users, provided you know their user names and passwords. Thanks to this mechanism, you can spend most of the time as a user with low-privileges and switch to a higher-privileged account only if you need to.

The advantage of running as a non-privileged user is that any mistakes you happen to make are very unlikely to damage the system. System-critical components can only be altered by the root user.

File permissions [ edit | edit source ]

This system allows precise control over who can do what on a given computer. Users can be prevented from modifying system files by removing the «write» permission from them, or from executing certain commands by removing the «execute» permission. Notice that users may be allowed to execute programs but not alter them. This is very important, since most Linux systems include a compiler that allows you to create your own programs.

File permissions are usually given as three octal digits (each from 0 to 7). The digits represent the permissions for, respectively, owner, group and other users. Each digit is the sum of permission codes: 1 for execute, 2 for write and 4 for read. For example, «755» allows everyone to read or execute the file, but only its owner can write it. «400» allows the owner to read the file, and no one else is allowed to do anything. «540» allows the owner to read or execute the file, group members to only read the file and other users to do nothing.

chmod (change mode), chown (change owner), and chgrp (change group) are used to change file permissions.