The Linux Devops Handbook Customize and Scale Your Linux Distributions To Accelerate Your Devops Workflow 1O Edition Wojslaw Full Chapter

The Linux DevOps Handbook:
Customize and scale your Linux

distributions to accelerate your DevOps
workflow 1º Edition Wojs■aw
Visit to download the full and correct content document:
https://ebookmass.com/product/the-linux-devops-handbook-customize-and-scale-you
r-linux-distributions-to-accelerate-your-devops-workflow-1o-edition-wojslaw/
The Linux DevOps Handbook
Customize and scale your Linux distributions to accelerate

your DevOps workflow
Damian Wojsław
Grzegorz Adamowicz
BIRMINGHAM—MUMBAI
The Linux DevOps Handbook
Copyright © 2023 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted
in any form or by any means, without the prior written permission of the publisher, except in the case
of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information
presented. However, the information contained in this book is sold without warranty, either express
or implied. Neither the authors, nor Packt Publishing or its dealers and distributors, will be held liable
for any damages caused or alleged to have been caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and
products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot
guarantee the accuracy of this information.
Group Product Manager: Preet Ahuja

Publishing Product Manager: Preet Ahuja
Senior Editor: Runcil Rebello
Technical Editor: Nithik Cheruvakodan
Copy Editor: Safis Editing
Project Coordinator: Ashwin Kharwa
Proofreader: Safis Editing
Indexer: Hemangini Bari
Production Designer: Ponraj Dhandapani
Marketing Coordinator: Rohan Dobhal
First published: November 2023
Production reference: 1171023
Published by Packt Publishing Ltd.

Grosvenor House
11 St Paul’s Square
Birmingham
B3 1RB, UK.
ISBN 978-1-80324-566-9
www.packtpub.com
To my wife, my kids, and all the people who have helped me on my journey to become the best version
of me.
– Damian Wojsław
To my mum and dad, who supported me with all my interests, including computers. To my wife and
daughter, who are my biggest supporters and motivation in all endeavors.
– Grzegorz Adamowicz
Contributors
About the authors

Damian Wojsław has been working in the IT industry since 2001. He specializes in the administration
and troubleshooting of Linux servers. Being a system operator and support engineer, he has found
the DevOps philosophy to be a natural evolution of the way SysOps work with developers and other
members of the software team.
I would like to thank my wife and kids for their patience and support.
Grzegorz Adamowicz has been working in the IT industry since 2006 in a number of positions,
including systems administrator, backend developer (PHP and Python), systems architect, and site
reliability engineer. Professionally, he is focused on building tools and automations for the projects
he is involved in. He also engages with the professional community by organizing events such as
conferences and workshops. Grzegorz has worked in many industries, including oil and gas, hotel,
Fintech, DeFI, automotive, and space.
I want to thank my wife, Agnieszka, for her never-ending support, and everyone I’ve had the pleasure
of working with throughout my career – most of what I know professionally, I’ve learned from you.
About the reviewer
Marcin Juszkiewicz is a seasoned software engineer on a journey since 2004. Over the years, he has
worked on building and optimizing code in various projects. His career has spanned from embedded
Linux systems to ARM servers. In his spare time, Marcin dons the hat of a system admin, a role he
embraces with the same enthusiasm as his daily job. Through his extensive journey as a software
engineer and part-time system administrator, Marcin has garnered a wealth of knowledge and a
reputation for his meticulous approach to coding and system optimization.
Table of Contents
Prefacexv
Part 1: Linux Basics

1
Choosing the Right Linux Distribution 3
Technical requirements 3 Red Hat Enterprise Linux (RHEL) 10
What exactly is a Linux distribution? 3 Fedora Linux 11
CentOS12
What makes distributions different? 4
Rocky Linux 12
Introducing the distributions 8 Alpine13
Debian8
Summary14
Ubuntu Linux 9
2
Command-Line Basics 15
Technical requirements 15 Interacting with the system 31
The Linux command line – shell 16 Process this 32
Getting to know your shell 16 Looking for something? 37
I call to thee 18 Let’s be manipulative 40
The filesystem structure 18 Summary42
Running a program 21
Exercises42
The command to teach you all commands 22
Know your environment 25
Resources43
Where in the PATH am I? 26
Know your rights 27

viii Table of Contents
3
Intermediate Linux 45
Technical requirements 45 Adding users 59
Globs46 Modifying users 59
Removing users 60
Automating repetitive tasks 48
Managing groups 60
Cron jobs 48
Systemd timer 49 Secure Shell (SSH) protocol 61
Configuring OpenSSH 62
Software installation 49
Creating and managing SSH keys 64
Debian and Ubuntu 50
CentOS, RHEL, and Fedora 53 Summary66
Alpine Linux 54 Exercises66
Managing users 58
4
Automating with Shell Scripts 67
Technical requirements 67 Loops72
Backing up a database 67 Conditional execution – if statement 73
Understanding scripting 68 Understanding the backup script –

Understanding Bash built-ins and first steps 75
grammar69 Handling errors and debugging 80
Variables70 Summary87
Parameters71 Exercises88
Part 2: Your Day-to-Day DevOps Tools

5
Managing Services in Linux 91
Technical requirements 91 systemd92
Understanding Linux services in detail 91 OpenRC97
SysV init 100
The history of Linux service management 92
Table of Contents ix
A few words about Upstart, an Summary106

alternative106
6
Networking in Linux 107
Networking in Linux 107 nftables132
ISO/OSI as a networking standard 108 ufw133
firewalld134
Physical layer 108
Data link layer – MAC, VLAN 109 Advanced topics 134
Network layer – IPv4 and IPv6 110 NAT134
Transport layer – TCP and UDP 118 Port forwarding 135
Session layer 122 Interface bonding 136
Presentation layer – SSL and TLS 123 TCP multipath 136
Application layer – HTTP and FTP 126 BGP137
Firewalls129 Summary138
iptables130
7
Git, Your Doorway to DevOps 139
Technical requirements 139 Branching150
Basic Git commands 140 Squashing commits using an interactive rebase 151
Solving Git conflicts 152
Configuring the local Git environment 141
Setting up a local Git repository 141 GitFlow and GitHub Flow 153
Local versus remote Git repositories 144 Global git configuration – .gitconfig 154
Ignoring some files using a .gitignore
Interacting with remote repositories 145
configuration file 156
What’s the git diff command? 147
Viewing the commit history 148 Summary158
8
Docker Basics 159
Technical requirements 159 Virtualization160
Virtualization versus containerization159 Containerization161
x Table of Contents
Anatomy of Docker 162 docker volume 177

OverlayFS163
Dockerfile178
What is an image? 164
FROM178
What is a container runtime? 165
COPY and ADD 179
cgroups166
EXPOSE179
Docker commands 167 ENTRYPOINT and CMD 180
docker build 168 RUN180
docker run 168 LABEL181
docker start 169 ENV and ARG 181
docker stop 170 VOLUME182
docker ps 170 USER182
docker login 171 WORKDIR183
docker pull 172
Docker image registries 183
docker push 173
Docker networking 184
docker image 173
None network 184
docker exec 174
Bridge mode 185
docker logs 175
Host mode 186
docker rm 175
Overlay187
docker rmi 175
docker network 176 Summary187
9
A Deep Dive into Docker 189
Docker advanced use cases 189 Multi-stage build 212
Running public images 190 ADD command use cases 213
Running a debugging container 191 Secrets management 214
Cleaning up unused containers 192 Docker orchestration 216
Docker volumes and bind mounts 194
Docker Swarm 216
Docker networking advanced use cases 195
Kubernetes and OpenShift 220
Security features of Docker 197
Docker for CI/CD pipeline integration 205 Summary221
Docker Compose 207
Advanced Dockerfile techniques 212
Table of Contents xi
Part 3: DevOps Cloud Toolkit

10
Monitoring, Tracing, and Distributed Logging 225
Differences between monitoring, SaaS solutions 245
tracing, and logging 226 Datadog245
Cloud solutions 227 New Relic 246
CloudWatch Logs and metrics 228 Ruxit247
AWS X-Ray 238 Splunk248
Open source solutions for self-hosting 239 Log and metrics retention 248
Prometheus240 Full retention 249
Grafana241 Time-based retention 249
SigNoz242 Event-based retention 249
New Relic Pixie 242 Selective retention 249
Graylog243 Tiered retention 249
Sentry244 Summary250
11
Using Ansible for Configuration as Code 251
Technical requirements 251 Ansible Vault 277
CM systems and CaC 251 SOPS278
Other solutions 280
SaltStack253
Chef254 Ansible Tower and alternatives 280
Puppet256 Advanced topics 281
CFEngine257
Debugging281
Ansible258 Linting Ansible playbooks 283
Basics of using Ansible 261 Speeding up SSH connections 285
Tasks263 Dynamic inventory 286
Roles263 Summary287
Plays and playbooks 264
Further reading 287
Ansible Galaxy 275
Handling secrets 277
xii Table of Contents
12
Leveraging Infrastructure as Code 289
Technical requirements 290 Terraform state 302
What is IaC? 290 Terraform CLI 305
IaC versus Configuration as Code 290 HCL in depth 317

IaC projects worth knowing 290 Variables317
AWS CloudFormation 291 Comments318
AWS Cloud Development Kit 293 Terraform meta-arguments 319
Terraform294 Terraform examples with AWS 322
Cloud Development Kit for Terraform 294
EC2 instance module 323
Pulumi296
Summary333
Terraform298
Exercises333
Terraform modules 300
13
CI/CD with Terraform, GitHub, and Atlantis 335
Technical requirements 335 Deployment354
What is CI/CD? 336 CI/CD with Atlantis 356
An example of CI/CD pipelines 337 Deploying Atlantis to AWS 356
Continuously integrating and Running Terraform using Atlantis 362
deploying your infrastructure 342 Summary365
Integration testing 342 Exercises365
14
Avoiding Pitfalls in DevOps 367
Technical requirements 367 Tasks with version control integration 369
Too much or not enough automation 368 Tasks with repeatable patterns 369
Tasks with well-defined APIs or interfaces 369
Repetitive tasks 368
Tasks with clear and well-defined requirements370
Time-consuming tasks 369
Manual and error-prone tasks 369 Not understanding the technology 370
Table of Contents xiii
Stay curious and proactive 371 Actionable380

Start with the basics 371 Continuously improving 380
Hands-on learning 372
Inadequate security and compliance
Collaborate and share knowledge 372
measures380
Stay updated 372
What are security measures? 381
Failure to adopt a collaborative Characteristics of good security measures 381
culture372
Lack of scalability and flexibility 382
Lack of leadership 373
DevOps is only for small teams or projects 383
Siloed organizational structure 373
Inability to scale infrastructure 383
Lack of trust and communication 374
Flexibility compromises stability 383
Tool-centric approach 375
Lack of flexibility in release management 384
Neglecting testing and QA 376
Lack of proper documentation and
Increased software defects 377
knowledge sharing 384
Deployment failures 377
Technical documentation 385
Security vulnerabilities 377
API documentation 385
Lack of documentation 378
User documentation 385
Inadequate test coverage 378
Process documentation 386
Lack of continuous improvement 378
Operational documentation 386
Poor monitoring and feedback loops 378 Release notes and changelogs 386
Real-time379
Overcoming resistance to change 387
Comprehensive379
Scalable380
Summary387
Index389
Other Books You May Enjoy 404

Preface
DevOps has become a critical component of modern software development and delivery. It has
revolutionized the way we build, test, deploy, and operate software systems. DevOps is not just a set
of tools and practices but also a culture and mindset that focuses on collaboration, communication,
and automation.
This book is designed to be a comprehensive guide to DevOps, covering everything from choosing
the right Linux distribution to avoiding pitfalls in DevOps. Each chapter in this book provides
detailed information and practical examples to help you understand the concepts and apply them to
real-world scenarios.
Who this book is for

This book is designed for individuals who have already gained some knowledge and experience in
the field of software development and IT operations and are now seeking to further expand their
knowledge of DevOps and Linux systems.
If you are not well versed in Linux systems, this book will provide you with the necessary guidance
and tools to quickly learn and become proficient in managing Linux-based infrastructures. You will
gain an understanding of the Linux operating system, its architecture, and its fundamental concepts.
Furthermore, this book emphasizes learning about public cloud technologies with a focus on AWS.
If you are interested in learning how to use AWS to build and manage scalable and reliable systems,
this book will provide you with the necessary knowledge and tools to get started.
Whether you are new to DevOps or have already gained some experience, this book provides a solid
foundation for learning more complex concepts. It covers a wide range of topics, from the basics of
Linux systems to more advanced DevOps practices such as configuration and infrastructure as code
and CI/CD.
What this book covers

Chapter 1, Choosing the Right Linux Distribution, discusses the GNU/Linux history, and the differences
between popular distributions.
Chapter 2, Command-Line Basics, guides you through the usage of a command line and common
tools we’ll be using throughout the book.
xvi Preface
Chapter 3, Intermediate Linux, describes more advanced features of GNU/Linux that you will find useful.
Chapter 4, Automating with Shell Scripts explains how to start writing your own scripts using the
Bash shell.
Chapter 5, Managing Services in Linux, discusses different ways of managing services in Linux and
shows you how to define your own services using systemd.
Chapter 6, Networking in Linux, describes how networking works, how to control different aspects of
network configurations, and how to use command-line tools.
Chapter 7, Git, Your Doorway to DevOps, discusses what Git is and how to use Git’s version control
system, including less commonly known Git features.
Chapter 8, Docker Basics, explores the containerization of your services or tools, and running and
managing containers.
Chapter 9, A Deep Dive into Docker, discusses the more advanced features of Docker, including Docker
Compose and Docker Swarm.
Chapter 10, Monitoring, Tracing, and Distributed Logging, discusses how to monitor your services,
what tools you can use in the cloud, and how to do a basic setup.
Chapter 11, Using Ansible for Configuration as Code, looks at Configuration as Code with the use of
Ansible; it’ll guide you through the basic setup and more advanced features of Ansible.
Chapter 12, Leveraging Infrastructure as Code, discusses what Infrastructure as Code (IaC) is, what
the popular tools are, and how to manage your infrastructure using Terraform.
Chapter 13, CI/CD with Terraform, GitHub, and Atlantis, takes IaC one step further with the use of
the Continuous Integration (CI) and Continuous Deployment (CD) of infrastructure with the use
of Terraform and Atlantis.
Chapter 14, Avoiding Pitfalls in DevOps, discusses challenges you may encounter with your work
in DevOps.
To get the most out of this book

You will need Debian Linux or Ubuntu Linux installed on a virtual machine or as your main operating
system on your computer. Other software we use is either already installed as a default toolset, or we
will show you where to get it to install it on your system.
It is assumed that you have some basic knowledge of Linux and its command-line interface. Familiarity
with shell scripting and basic programming concepts would also be helpful. Additionally, some
understanding of IT infrastructure and how it is managed is recommended, as well as some exposure
to software development practices.
Preface xvii
This book is aimed at beginners in the DevOps world, and it assumes that you are eager to learn
about the tools and concepts that are commonly used in this field. By the end of this book, you will
have gained a solid understanding of how to manage infrastructure using IaC tools such as Terraform
and Atlantis, as well as how to automate repetitive tasks using Ansible and Bash scripting. You will
also learn how to set up logging and monitoring solutions to help you maintain and troubleshoot
your infrastructure.
Software/hardware covered in the book Operating system requirements

Bash Linux OS has it preinstalled
Ansible Python 3 or newer
Terraform Linux OS
AWS CLI Python 3 or newer
Docker Linux OS
If you are using the digital version of this book, we advise you to type the code yourself or access the
code from the book’s GitHub repository (a link is available in the next section). Doing so will help
you avoid any potential errors related to the copying and pasting of code.
Download the example code files

You can download the example code files for this book from GitHub at https://github.com/
PacktPublishing/The-Linux-DevOps-Handbook. If there’s an update to the code, it will
be updated in the GitHub repository.
We also have other code bundles from our rich catalog of books and videos available at https://
github.com/PacktPublishing/. Check them out!
Conventions used
There are a number of text conventions used throughout this book.
Code in text: Indicates code words in text, database table names, folder names, filenames, file
extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: “While
logged in as root, your prompt will end with the # sign. When logged in as a normal user, it will
present you with $.”
A block of code is set as follows:
docker build [OPTIONS] PATH | URL | -

xviii Preface
When we wish to draw your attention to a particular part of a code block, the relevant lines or items
are set in bold:
docker build [OPTIONS] PATH | URL | -
Any command-line input or output is written as follows:
chmod ug=rx testfile
Bold: Indicates a new term, an important word, or words that you see onscreen. For instance, words
in menus or dialog boxes appear in bold. Here is an example: “Ansible Galaxy is a community-driven
platform that hosts an extensive collection of Ansible roles and playbooks.”
Tips or important notes

Appear like this.
Get in touch
Feedback from our readers is always welcome.
General feedback: If you have questions about any aspect of this book, email us at customercare@
packtpub.com and mention the book title in the subject of your message.
Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen.
If you have found a mistake in this book, we would be grateful if you would report this to us. Please
visit www.packtpub.com/support/errata and fill in the form.
Piracy: If you come across any illegal copies of our works in any form on the internet, we would
be grateful if you would provide us with the location address or website name. Please contact us at
[email protected] with a link to the material.
If you are interested in becoming an author: If there is a topic that you have expertise in and you
are interested in either writing or contributing to a book, please visit authors.packtpub.com.
xix
Share Your Thoughts

Once you’ve read The Linux DevOps Handbook, we’d love to hear your thoughts! Please click here to
go straight to the Amazon review page for this book and share your feedback.
Your review is important to us and the tech community and will help us make sure we’re delivering
excellent quality content.
xx
Download a free PDF copy of this book

Thanks for purchasing this book!
Do you like to read on the go but are unable to carry your print books everywhere?
Is your eBook purchase not compatible with the device of your choice?
Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.
Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical
books directly into your application.
The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content
in your inbox daily
Follow these simple steps to get the benefits:
1. Scan the QR code or visit the link below
https://packt.link/free-ebook/9781803245669
2. Submit your proof of purchase

3. That’s it! We’ll send your free PDF and other benefits to your email directly
Part 1: Linux Basics
In this opening part of the book, we will focus on Linux distributions and the basic skills you will
need to efficiently use Linux operating systems. You will also learn about the basics of shell scripting
to automate day-to-day tasks.
This part has the following chapters:
• Chapter 1, Choosing the Right Linux Distribution

• Chapter 2, Command-Line Basics
• Chapter 3, Intermediate Linux
• Chapter 4, Automating with Shell Scripts
1
Choosing the
Right Linux Distribution
In this chapter, we will dive into the Linux world from the very beginning. We will briefly touch on
Linux history, explain what a distribution is, and explain what to take into account when choosing
one for production use. You are not expected to know anything about Linux, its administration, or
the cloud. If you don’t understand some words that we use, worry not. There shouldn’t be a lot of
confusing terminology in this chapter, and if there is, we will explain it in later chapters. When you
finish reading this chapter, you should be able to understand why there are so many Linuxes out there,
how much you should expect to pay for it, and how to think about choosing the right Linux for yourself.
In this chapter, we will cover the following main topics:
• What is Linux and what is a Linux distribution?

• What can you use to help you make the right decision?
• Several major Linux distributions that are quite popular today
Technical requirements
This chapter doesn’t have any technical requirements. We won’t run any commands or install any
software yet. This will come in the later chapters.
The code we’re presenting in the book is available in the public GitHub repository for your consideration
at this address: https://github.com/PacktPublishing/The-Linux-DevOps-Handbook.
What exactly is a Linux distribution?

Linux is the standard operating system for cloud workloads. However, there is not a single Linux
operating system that goes by that name. Its ecosystem is quite complex. This comes from how it
came to be originally.
4 Choosing the Right Linux Distribution
Long before Linux was conceived by its creator, Linus Torvalds, there was Unix. Unix source code
was – for legal reasons – licensed to anyone who bought it, thus making it very popular among many
institutions. This included universities. The code, however, was not entirely free. This didn’t sit well
with many people, who believed that software should be free – as in speech or beer – including source
code. In the 1980s, a completely free and open implementation of Unix was born under the aegis of the
GNU Project. Its goal was to develop an operating system that gave complete control over a computer
to the user. The project was successful in that it was able to produce all the software required to run
an operating system, except one thing – the kernel.
A kernel of the operating system is, in short, the core that operates hardware and manages the hardware
and programs for the user.
In 1991, Finnish student Linus Torvalds famously announced his hobby kernel – Linux. He called it
at that time “just a hobby – won’t be big and professional like GNU.” It wasn’t supposed to get big and
popular. The rest is history. The Linux kernel became popular among developers and administrators
and became the missing piece of the GNU Project. Linux is the kernel, the GNU tools are the so-called
userland, and together they make the GNU/Linux operating system.
The preceding short story is important to us for two reasons:
• While the GNU userland and the Linux kernel is the most popular combination, you’ll see it
is not the only one.
• Linux delivers a kernel and the GNU Project delivers userland tools, but they have to be
somehow prepared for installation. Many people and teams had separate ideas on how to do
it best. I will expand on this thought next.
The way that a team or a company delivers a GNU/Linux operating system to end users is called a
distribution. It facilitates operating system installation, the means to manage software later on, and
general notions on how an operating system and the running processes have to be managed.
What makes distributions different?

The open nature of Linux and the GNU Project made it possible for almost anyone to create their
own distribution. One of the things that made new users dizzy was the sheer amount of Operating
System (OS) versions they could use. The surefire way to start a holy war between Linux users is by
asking which distribution is the best.
One of the ways we can group Linux distributions is the format in which they deliver the software
(packages) and additional software used to install and remove that software (package managers).
There are a number of them, but the two most prevalent are RPM (RPM Package Manager) and
DEB packages. Packages are more than just an archive with binaries. They contain scripts that set the
software up for use – creating directories, users, permissions, log rules, and a number of other things
that we will explain in later chapters.
What exactly is a Linux distribution? 5
The RPM family of distributions starts with Red Hat Enterprise Linux (RHEL), created and maintained
by the Red Hat company. Closely related is Fedora (a free community distribution sponsored by Red
Hat). It also includes CentOS Linux (a free version of RHEL) and Rocky Linux (another free version
of RHEL).
The DEB distributions include Debian (where the DEB packages originate from) – a technocracy
community project. From the Debian distribution arose a number of distributions based on it, using
most of its core components. Most notable is Ubuntu, a server and desktop distribution sponsored
by Canonical.
There are also distributions that use packages with minimum automation, most notably Slackware,
one of the oldest existing Linux distributions.
There are distributions that give the user a set of scripts that compile actual software on the hardware
it will be used on – most notably, Gentoo.
Finally, there is a distribution that is actually a book with a set of instructions that a user can follow
to build the whole OS by hand – the Linux From Scratch project.
Another way of grouping distributions is by their acceptance of closed software – software that limits
the distribution of source code, binaries, or both. This can mean hardware drivers, such as the ones
for NVIDIA graphic cards, and user software, such as movie codecs that allow you to play streamed
media and DVD and Blu-Ray discs. Some distributions make it easy to install and use them, while
some make it more difficult, arguing that we should strive for all software to be open source and free
(as in speech and as in beer).
Yet another way to differentiate them is the security framework a given distribution uses. Two of the most
notable ones are AppArmor, used mainly by Ubuntu, and SELinux (from the USA’s National Security
Agency), used by, among others, Red Hat Enterprise Linux (and its derivatives) and Fedora Linux.
It’s also worth noting that while most Linux distributions use the GNU Project as the userland, the
popular one in the cloud Alpine Linux distribution uses its own set of software, written especially
with minimum size in mind.
Looking at how the distribution is developed, it can be community-driven (without any commercial
entity being an owner of any part of the process and software – Debian being one prime example),
commercial (wholly owned by a company – RHEL being one example and SuSE another), and all the
mixes in between (Ubuntu and Fedora being examples of a commercially owned distribution with a
large body of independent contributors).
Finally, a way we can group distributions is by how well they facilitate the cloud workload. Here, we
can look at different aspects:
• The server side: How well a given distribution works as an underlying OS for our infrastructure,
virtual machines, and containers
• The service side: How well a given distribution is suited to run our software as a container or
a virtual machine
To make things even more confusing and amusing for new adopters, each distribution can have many
variants (called flavors, variants, or spins, depending on the distribution lingo) that offer different
sets of software or default configurations.
And to finally confuse you, dear reader, for use on a desktop or laptop, Linux offers the best it can
give you – a choice. The number of graphical interfaces for the Linux OS can spin the head of even
the most experienced user – KDE Plasma, GNOME, Cinnamon Desktop, MATE, Unity Desktop
(not related to the Unity 3D game engine), and Xfce. The list is non-exhaustive, subjective, and very
limited. They all differ in the ease of use, configurability, the amount of memory and CPU they use,
and many other aspects.
The number of distributions is staggering – the go-to site that tracks Linux distributions (https://
distrowatch.com/dwres.php?resource=popularity) lists 265 various Linux distributions
on its distribution popularity page at the time of writing. The sheer number of them makes it necessary
to limit the book to three of our choosing. For the most part, it doesn’t make a difference which one
you choose for yourself, except maybe in licensing and subscription if you choose a commercial one.
Each time the choice of distribution makes a difference, especially a technical one, we will point it out.
Choosing a distribution is more than just a pragmatic choice. The Linux community is deeply driven
by ideals. For some people, they are the most important ideals on which they build their lives. Harsh
words have been traded countless times over which text editor is better, based on their user interface, the
license they are published with, or the quality of the source code. The same level of emotion is displayed
toward the choice of software to run the WWW server or how to accept new contributions. This will
inevitably lead to the way the Linux distribution is installed, what tools there are for configuration
and maintenance, and how big the selection of software installed on it out of the box is.
Having said that, we have to mention that even though they have strong beliefs, the open-source
community, the Linux community included, is a friendly bunch. In most cases, you’ll be able to find
help or advice on online forums, and the chances are quite high that you will be able to meet them
in person.
What exactly is a Linux distribution? 7
To choose your distribution, you need to pay attention to several factors:
• Is the software you wish to run supported on the distribution? Some commercial software
limits the number of distributions it publishes packages for. It may be possible to run them on
unsupported versions of Linux, but this may be tricky and prone to disruptions.
• Which versions of the software you intend to run are available? Sometimes, the distribution of
choice doesn’t update your desired packages often enough. In the world of the cloud, software
a few months old may already be outdated and lack important features or security updates.
• What is the licensing for the distribution? Is it free to use or does it require a subscription plan?
• What are your support options? For community-driven free distributions, your options are
limited to friendly Linux gurus online and in the vicinity. For commercial offerings, you can
pay for various support offerings. Depending on your needs and budget, you can find a mix of
support options that will suit your requirements and financial reserves.
• What is your level of comfort with editing configuration files and running long and complex
commands? Some distributions offer tools (both command-line and graphical) that make the
configuration tasks easier and less error-prone. However, those tools are mostly distribution-
specific, and you won’t find them anywhere else.
• How well are cloud-related tools supported on a given distribution? This can be the ease of
installation, the recency of the software itself, or the number of steps to configure for use.
• How well is this distribution supported by the cloud of your choosing? This will mean how
many cloud operators offer virtual machines with this distribution. How easy is it to obtain a
container image with this distribution to run your software in it? How easy do we suspect it to
be to build for this distribution and deploy on it?
• How well is it documented on the internet? This will not only include the documentation
written by distribution maintainers but also various blog posts and documentation (mainly
tutorials and so-called how-to documents) written by its users.
So far, you’ve learned what a Linux distribution is, how distributions differentiate from one another,
and what criteria you can use to actually choose one as the core of the system you will manage.
In the next section, we will look deeper into each distribution to get to know the most popular ones
better, giving you a first glimpse of how each one works and what to expect.
Introducing the distributions

After that bit of a lengthy but condensed history of the Linux OS, it is time to finally explore the few
we have chosen to cover in this book. In this section, we will cover the factors we just listed, as we
believe they are important in making a decision. Please remember though that while we strive to
present you with objective facts and valuations, we cannot escape our own subjective views. Always
evaluate on your own before you choose, as it’s highly possible that you will stick with this distribution
for many years to come.
A point to note is that we won’t be covering distributions comprehensively. We will only try to create
a foundation on which you, dear reader, must build through research.
Also, while you are learning, do not be afraid to hop from distribution to distribution. Only through
real-life experiences will you fully understand which one covers your needs best.
Debian
Debian (https://www.debian.org/) is one of the oldest active Linux distributions. Its
development is led by the community-supported Debian Project. It is known for two things – the
sheer number of packages that the distribution provides and the slow release of stable versions. The
latter has improved in recent years and stable releases are published every two years. Software is
delivered in archives called packages. Debian packages’ names have a .deb file extension and are
colloquially called debs. They are kept online in repositories and repositories are broken down into
pools. Repositories offer almost 60,000 packages with software in the latest stable release.
Debian always has three versions available (so-called branches) – stable, testing, and unstable. The
releases are named after characters from the Toy Story movie franchise. The latest stable release –
version 11 – is called Bullseye.
The unstable branch is the rolling branch for developers, people who like living on the edge, or
those who require the newest software more than they require stability. Software is accepted into the
unstable branch with minimal testing.
The testing branch is where, as the name implies, the testing happens. A lot of testing happens here,
thanks to the end users. Packages come here from the unstable branch. The software here is still newer
than in the stable branch but not as fresh as in the unstable branch. A few months before the new
stable release, the testing branch is frozen. It means that no new software will be accepted, and new
versions of the already accepted packages are allowed only if they fix bugs.
After a few months, testing becomes the stable branch. The software is updated only for security fixes.
This distribution is available for many hardware platforms – Intel, ARM, PowerPC, and so on. Along
with unofficial ports, there are a multitude of hardware platforms on which you can install it.
Introducing the distributions 9
Debian is viewed as the most stable distribution there is, and it is used as a platform for various compute
clusters, so it is generally installed on bare-metal servers somewhere in a rack in a data center and
intended for use consistently over many years.
According to W3Techs (https://w3techs.com/technologies/details/os-linux),
Debian makes up for 16% of all servers running on the internet. Its derivative, Ubuntu, runs 33%
of them. Together, they account for 49% of all servers. This makes administration skills related to
Debian highly marketable.
Ubuntu Linux
The Ubuntu Linux distribution (https://ubuntu.com/) is widely credited for making Linux
popular on personal computers, and rightly so. Sponsored by Canonical, its mission was to make Linux
easily usable for most people. It was one of the first, if not the first, Linux versions to distribute non-free
and non-open binary drivers and libraries that made desktop use simpler and more comfortable.
Famously, the first bug report opened for Ubuntu distribution by Mark Shuttleworth (Canonical and
Ubuntu founder) was, “Microsoft has majority market share.”
The distribution itself is based on Debian Linux, and in the beginning, being fully binary-compatible
was one of the major objectives. As the development has progressed, this has lost some of its importance.
This distribution is developed by the community and Canonical. The main source of income for the
company is premium services related to Ubuntu Linux – support, training, and consultations.
Due to the very close-knit relationship between Debian Linux and Ubuntu Linux, many developers
and maintainers for one distribution serve the same roles in the other one. This results in a lot of
software being packaged for both distributions in parallel.
Ubuntu has three major flavors – Desktop, Server, and Core (for the internet of things). Desktop and
Server may differ slightly in how services are configured out of the box, and Core differs a lot
The software is distributed in .deb packages, the same as with Debian, and the sources are actually
imported from the Debian unstable branch. However, this doesn’t mean you can install Debian
packages on Ubuntu or vice versa, as they are not necessarily binary-compatible. It should be possible
to rebuild and install your own version.
There are four package repositories per release – the free and non-free software supported officially
by Canonical is called main and restricted, respectively. Free and non-free software delivered and
maintained by the community is called universe and multiverse, respectively.
Important note
A word of advice – a widely accepted practice of system upgrades between major versions is to
wait for the first sub-release. So, if the currently installed version of the distribution is 2.5 and
the new version 3.0 is released, it is wise to wait until 3.1 or even 3.2 is released and upgrade
then. This is applicable to all the distributions we list here.
The Long-Term Support (LTS) versions are supported for five years. A new LTS version is released
every two years. It is possible to negotiate extended support. This gives a very good timeline to plan
major upgrades. A new Ubuntu version is released every six months.
Ubuntu Linux is widely adopted in education and government projects. Famously, the city of Munich,
between 2004 and 2013, migrated over 14,000 municipal desktop computers to a variant of Ubuntu
with the KDE desktop environment. While the migration saw disturbances politically – other operating
system vendors lobbied strongly against this migration – it was considered a success technically.
Ubuntu is the Linux of choice for personal computers. Canonical works very closely with hardware
vendors, notably Lenovo and Dell, but lately also with HP, to ensure full compatibility between the
distribution and the computers. Dell sells its flagship laptops with Ubuntu preinstalled.
Several sources cite Ubuntu Linux as the most installed Linux distribution on servers and personal
computers. The actual number can only be estimated, as Ubuntu doesn’t require any subscription
or registration.
As a byproduct of Ubuntu Linux’s popularity, software vendors, more often than not, offer .deb
packages of their software, if they release a Linux version. This is especially true for desktop software.
The amount of unofficial versions, clones, or modified distributions based on Ubuntu is staggering.
Ubuntu has a very active community, both organized and unorganized. It’s quite easy to get a hold of a
group of users near your city. This also directly translates to the amount of tutorials and documentation
on the internet.
Ubuntu Linux, especially under a support plan, is installed as a foundation for many cloud computing
infrastructure deployments. Many telecoms, banking, and insurance companies have chosen Ubuntu
Server as their foundation.
Red Hat Enterprise Linux (RHEL)

RHEL (https://www.redhat.com/en/technologies/linux-platforms/enterprise-
linux) is a spiritual successor of Red Hat Linux and is developed and maintained by Red Hat Inc.
(https://www.redhat.com/). Its main target is the commercial entities market. It is possible
to use RHEL for free for development or in production with up to 16 servers (at the time of writing).
However, the main advantage of this distribution is the enormous pool of articles that help solve
issues and the assistance of support engineers, although the latter can only be acquired through a
paid support plan.
RHEL is considered a very stable and solid distribution. It is one of the main choices for banks, insurance
companies, and financial markets. It lacks many popular desktop software packages, but on the server
side of things, especially as an OS to run other commercial applications, it is a first-class citizen.
The software is distributed in online repository packages that end with .rpm, hence the name RPMs.
The main tool to administer the packages is RPM, with more sophisticated tools – yum, and lately
its successor, dnf – also available.
In the true spirit of an open source-based company, Red Hat makes sources for its distribution available.
This has led to the creation of a famous free and open clone of RHEL – CentOS. Until fairly recently,
it had been quite a popular choice for people who wanted to use RHEL but didn’t want to, or couldn’t,
pay a subscription. In 2014, CentOS joined the Red Hat company, and in 2020, Red Hat announced
that the versioned releases of CentOS would no longer be available; there would only be the so-called
rolling release, which constantly updates packages and does not mirror the RHEL releases. This resulted
in a very heated reaction from CentOS users. The original CentOS founder, Gregory Kurtzer, started
another clone of RHEL called Rocky Linux. Its main objective is the same as the original CentOS – to
deliver a free, open, and community-driven distribution, fully binary-compatible with RHEL.
The RHEL distribution delivers stable versions every few years and supports them for 10 years, starting
from release 5. The full support, however, is offered only for a few years. For the rest of the time, Red
Hat provides only security fixes and critical updates for your systems, with no new package versions
being introduced. Still, this life cycle is what users with large installations or mission-critical systems
came to like.
As with Ubuntu, it is possible to negotiate extended support time.
The Red Hat company has a turbulent relationship with the open source community. While the
company mostly plays fair, there have been some decisions that the community didn’t like. Lately, it
was Red Hat’s decision to change the CentOS release model to a rolling release (https://lists.
centos.org/pipermail/centos-announce/2020-December/048208.html).
RHEL, like Ubuntu, is the chosen foundation for commercially supported deployments of
cloud infrastructure.
Fedora Linux
Fedora (https://fedoraproject.org/wiki/Fedora_Project_Wiki) is a distribution
associated with the Red Hat company. While more than 50% of its developers and maintainers are
community members not affiliated with Red Hat, the company holds full stewardship over the
development. It is a RHEL upstream, which means that this is the real development frontend for the
actual RHEL. It doesn’t mean that everything from Fedora is included in the release of RHEL. However,
following Fedora closely will yield insight into the current direction of the RHEL distribution.
Contrary to RHEL, for which Fedora is the foundation, the new releases happen every six months.
It uses the same package type as RHEL, RPM.
Fedora is considered a fast-paced distribution. It quickly adopts the newest and bleeding-edge versions
of packages.
CentOS
CentOS (https://centos.org) used to be the go-to free version of RHEL. The name is an acronym
for Community Enterprise Operating System. Its main goal was to be fully binary-compatible with
RHEL and adhere to the same releases and numbering scheme. In 2014, CentOS joined Red Hat, but
it was promised that the distribution would keep its independence from the company while benefiting
from development and testing resources. Unfortunately, in 2020, Red Hat announced that CentOS
8 would be the last numbered release, and from then on, CentOS Stream would be the only variant.
CentOS Stream is a midstream version. This means it sits in the middle between bleeding-edge and
fast-paced Fedora and stable and production-ready RHEL. The difference between CentOS Stream and
CentOS is that Stream is a development variant, while CentOS was simply a rebuilt and repackaged
mirror of the actual final product, RHEL.
All the knowledge, skills, and experience gained when working with RHEL are 100% applicable
to CentOS. Since CentOS is the third most-deployed Linux distribution on servers, according to
W3Techs (https://w3techs.com/technologies/details/os-linux), the skills are
very marketable.
Rocky Linux
As a response to the situation with the CentOS distribution, its founder announced the creation of
Rocky Linux (https://rockylinux.org/). The goals are the same as the original CentOS. The
release scheme and numbering follow RHEL. Shortly after the announcement, the GitHub repository
of Rocky Linux became top trending (https://web.archive.org/web/20201212220049/
https://github.com/trending). Rocky Linux is 100% binary-compatible with CentOS. The
project has released a set of tools that easily migrate from CentOS to Rocky Linux without reinstalling
the system.
The distribution is quite young, having been founded in 2020, and its popularity is still to be determined.
It has made a lot of noise in the community, and it seems that a steady stream of CentOS users have
moved to Rocky Linux as their preferred choice.
A very important contribution to the open source world from the Rocky Linux project is the build
system. It ensures that even if Rocky Linux shuts down, the community will be able to easily start up
a new RHEL clone.
All the skills, knowledge, and articles for RHEL and CentOS are 100% applicable to Rocky Linux. All
the software that runs on RHEL and CentOS should run without any modifications on Rocky Linux too.
Alpine
Alpine Linux (https://alpinelinux.org/) is an interesting one. The main programming library
and most basic command-line tools are not from the GNU Project. Also, the services management
system, currently systemd in most distributions, is uncommon. This makes some of the administration
skills from other major distributions non-applicable. The strength of Alpine lies in its size (which
is rather small), its security-first mindset, and one of the fastest boot times among existing Linux
distributions. Those characteristics, with the boot time being admittedly more important, make it the
most popular choice for containers. If you run containerized software or build your own container
images, it is very likely that it is on Alpine Linux.
Alpine has its roots in the LEAF (Linux Embedded Appliance Framework; see: https://bering-
uclibc.zetam.org/wiki/Main_Page) project – a Linux distribution that fits on a single
floppy disk. LEAF is currently a popular choice for embedded markets, routers, and firewalls. Alpine
is a bigger distribution, but that sacrifice had to be made, since developers wanted to include several
useful but rather large software packages.
The package manager is called apk. The build system is borrowed from another distribution called
Gentoo Linux. As Gentoo builds software as it installs it, the portage obviously contains a lot of logic
around building software that is used as a part of an OS.
Alpine can run from RAM entirely. There’s even a special mechanism that allows you to initially
only load a few required packages from the boot device, and it can be achieved using Alpine’s Local
Backup Utility (LBU).
As mentioned before, this is a preferred distribution for container images. You won’t see it running
on a large server installation often, if at all. When we cross over to the cloud world, chances are you’ll
see a lot of Alpine Linux.
Having said that, every single one of those distributions has a variant for the cloud as a container base
image – a way to run your software in the true cloud way.
In this chapter, you learned the basics of popular Linux distributions and how they are different
from one another. You should now have some understanding of what you can choose from and what
consequences you will need to face – good and bad. To give you an even better idea of how to interact
with some cherry-picked Linux distributions, we will look at how to interact with a system using your
keyboard in Chapter 2.
Summary
The short list in this chapter is just a tiny portion of the Linux distributions available. The list is largely
based on the popularity and marketability of skills, as well as our own experience and knowledge
that we acquired over the years. They are not, by any means, the best or only choices that you have.
We tried to point out where the main strengths lie and what a user’s relationship is with
respective distributions.
It’s not likely we were able to answer all your questions. Each of the Linux distributions from our list
has its own book out there, and there is even more knowledge on blogs, wikis, and YouTube tutorials.
In the next chapter, we will dive into the magical world of the command line.
2
Command-Line Basics
In this chapter, we’re going to dive right into the Linux command line. We will explain what makes
it so powerful and, by extension, important to every system administrator and DevOps person. But
more importantly, we will start teaching you the most useful commands and a way to use them
efficiently. Along the way, we will be adding other core Linux concepts, as they will be required to
understand the chapter.
In this chapter, we’re going to cover the following main topics:
• What a command line is and how it works

• Why it is so important to feel comfortable working with the command line
• Basic commands for Linux system administration
It is not possible to introduce all the commands and tools in a single chapter. What follows is our
choice of the most basic tools you will need to know. Managing the Linux system is a separate book
topic on its own. It so happens that Packt does have several publications on that.
Technical requirements
It is highly recommended to have a Linux system installed and ready for use. We recommend it to be
a virtual machine or a laptop that you can safely reinstall from scratch in case something goes horribly
wrong. It will let you follow the examples in the book and perform any kind of exercise that we give you.
We are not going to cover an installation. Every distribution may use its own installer, either graphical
or text (depending on the distribution and which variant you’ve picked). You’ll need to note down
or remember the name of your user (conveniently called username or login) and password. There
are ways to get into the system if you have physical access and you don’t know either the login or
password, or both, but they are way outside of the scope of this book.
Our main distribution in the book is Debian. However, you should be alright with any of the major
ones we covered in the previous chapter, Choosing the Right Linux Distribution, as long as it isn’t Alpine.
16 Command-Line Basics
The Linux command line – shell

The natural environment for a Linux system administrator is the command line. You’ll never hear
anyone call it that, however. The correct name is the shell, and from now on, that’s how we’re going
to address it in the book.
The shell is a program that accepts input from a user (mostly keyboard strokes, but there are other
ways, and you can even use a mouse pointer), interprets it, and, if it’s a valid command, executes
it, providing the user with the result or with error information if they’ve made a mistake or if the
commands couldn’t complete their execution properly.
There are a few ways to access the shell:
• Log in to the Terminal (screenshot in Figure 2.1)
Note
You’ll also see the term console. There is a difference between the Terminal and a console. A
console is a physical device that lets users interact with the computer. It is the physical input
(nowadays, mostly keyboard) and output (nowadays, a monitor, but in the beginning, the
output was printed out). Terminal is a console emulator, a program that lets users perform
the same tasks.
• Open a Terminal window in a graphical interface, if you have one

• Log in remotely over a secure connection from another device (phone, tablet, or your computer)
The shell is a very powerful environment. It may seem cumbersome at first to do everything by typing
commands, but soon you’ll learn that the more complex the task, the more you can do with the shell,
more easily than with graphical interfaces. Every Linux system administrator worth their salt will
know how to do tasks in the shell and how to manage the system through it, and I wouldn’t risk much
by betting that they will prefer the shell to any GUI.
Getting to know your shell

The shell is a program, and as such, there is not a single shell. Instead, there are a number of more or
less popular shells that bring forth their own view on how things should be done.
By far the most popular and default in most Linux distributions is Bash (Bourne again shell). There
are other shells you may want to be aware of:
• sh: The original Steve Bourne shell. It is the shell, the very first one ever written that we know
of. While it lacks many interactive features that users came to appreciate from other, more
modern shells, sh is known for its speed of script execution and small size.
• ksh: Developed as an evolution of the Bourne shell, it is a superset of its predecessor. Thus, all
scripts written for sh will run in ksh.
The Linux command line – shell 17
• csh: The C shell. The name comes from its syntax, which closely follows the C programming language.
• zsh: The Z shell. It should be well known to macOS users, as it is a default on this operating
system. It is a completely modern shell, providing a lot of features that you’d expect from it:
command history, arithmetic operations, command completion, and so on.
We won’t trouble you much with shell variants and history. If you are interested in how Bash came to be,
refer to this Wikipedia article: https://en.wikipedia.org/wiki/Bash_(Unix_shell).
In our book, we are working with Bash. As mentioned earlier, it is the default shell for most Linux
distributions, it offers sh compatibility mode, it has all the features you’d expect from a modern shell,
and the amount of books, articles, how-tos, and other material for extending your knowledge about
it is staggering.
The first task that we will be performing is logging in to your shell. Depending on your chosen
installation method, you may need to power up the local virtual machine, your physical machine, or a
cloud-based Virtual Private Server (VPS). If you have picked a server installation without a graphical
user interface, you should see something similar to the following screenshot:
Figure 2.1 – Login screen
You are presented with a login screen, where you can provide your username and password. Once
successfully logged in, you are presented with a command prompt, which confirms that you’ve just
successfully started your shell.
The way the prompt looks is configurable and may be different depending on your chosen distribution.
There is, however, one thing that will stay the same, and we advise you to never change it. In the world
of Linux, there are two types of users: normal users and the superuser. While the login for normal users
can be anything as long as it adheres to the Linux user naming conventions, the superuser is called
root. To log in to the root account, you’d type in root as the username/login and its password next.
The superuser account is named that way for a reason. In most Linux distributions, it’s the omnipotent
user. Once logged in as root, you can do anything you wish, even deleting all files, including the
operating system itself.
To help you distinguish between being a normal user and the root one, the prompt will present
you with a clue. While logged in as root, your prompt will end with the # sign. When logged in as
a normal user, it will present you with $.
While we’re at it, the # (hash) sign is also a so-called comment sign. If you happen to paste a command
or type it from the internet, if it starts with # or $, it is your clue as to which type of user should run this
command. You should omit this sign, especially as # in front will prevent the command from running.
In addition to the sign that ends the prompt, many distributions will prepend the username to it,
making sure you know which user you are. Given a user admin on a Linux system called myhome,
the default prompt for Debian 11 will look like this:
$admin@myhome:~$
For the root user, it would look like this:
root@myhome:~#
For the record, there are more ways to check your identity, but we will leave that for Chapter 4.
I call to thee
So far, so good. You have logged in, you know who you are, you can type, and you can read. But how
do you actually run programs?
In the Linux lingo, running a program is executing it or calling it. Actually, calling is mostly used
when referring to system commands or shell built-in commands, and executing is used when talking
about something that is not a part of the distribution—so-called third-party programs or binary.
Before I can tell you how to execute a program or call a command, I’ll have to explain a little bit about
filesystem structure and a very important system variable called PATH.
The filesystem structure

Since it may be your first time, we are going to step back a little bit and explain how the filesystem is
structured (in other words, how directories are organized in typical Linux).
Linux follows the Unix philosophy that states that everything is a file. (There are exceptions, but not
many.) The consequence is that almost every aspect of the operating system is reflected either as a file
or a directory. Memory states, processes' (running programs) states, logs, binaries, and device drivers
all live within this structure. This also means that almost every aspect of your Linux system can be
edited or inspected using just normal text editing tools.
In the directory tree, its structure always starts with a / folder, called the root directory. Every drive,
network share, and system directory lives in a hierarchy that starts from the root.
The process of making a network share or local drive available to the system or user is called mounting
and the resource that is made available is mounted. Remember that word, as we’re going to be using
it from now on. Different from Microsoft Windows, where your drives appear as a separate letter
with each being its own root directory, in Linux, your hard drive will be mounted somewhere within
the directories hierarchy. As an example, the user home directory can be stored on a separate hard
drive, mounted under the /home/ directory. You would never be able to tell it when browsing the
filesystem structure. The only way to tell would be to inspect mounted drives and partitions using
the following commands:
$ mount
oder
$ df
We are going to elaborate on them in Chapter 3, so for now, just know they exist.
The name of the uppermost directory is /. We already covered that. The separator between folders
nested in another folder is also /. So /usr/bin means a bin directory that exists in the usr
directory, and the usr directory exists in the / directory. Simple.
There is a very nice command that lets us inspect the directory structure, conveniently called tree.
It may not be present in your system. If so, don’t be worried; it’s not so important that you run it
rather than go through our explanation. In Chapter 3, when we introduce the installation of packages,
you can revisit and play around. By default, the tree command will flood your screen with the full
hierarchy, making it difficult to read and follow. There is an option, however, that lets us limit the
depth we will be inspecting:
admin@myhome:~$ tree -L 1 /
/
|-- bin -> usr/bin
|-- boot
|-- dev
|-- etc
|-- home
|-- lib -> usr/lib
|-- lib32 -> usr/lib32
|-- lib64 -> usr/lib64
|-- libx32 -> usr/libx32
|-- lost+found
|-- media
|-- mnt
|-- opt
|-- proc
|-- root
|-- run
|-- sbin -> usr/sbin
|-- srv
|-- sys
|-- tmp
|-- usr
`-- var
22 directories, 0 files
There are several important concepts to cover here; we won’t be explaining all the directories at this
time, however. The first time a given folder becomes important, in Chapter 3 onward, we will briefly
touch upon it.
First, the calling of tree. You saw my prompt, which tells me I am running as user admin, on a
system named myhome and that I am not a root user (the dollar sign at the end). If you want to run
the tree command, you will skip the prompt. Next is the actual call: tree with the -L option and
number 1; this instructs the program to only print one level of depth. In other words, it will not go
any deeper into the directories. Finally, the / symbol tells the program to start printing at the very
beginning of the filesystem—the root folder.
Next, you’ll notice that some rows have this mysterious arrow pointing from one name to another.
This denotes a shortcut. There are two types of shortcuts, hard and symbolic. Directories can only
have a symbolic link. In the preceding output, the /bin directory is a link to a /usr/bin directory.
For all intents and purposes, they can be treated as one. There are technical and historical reasons
for the existence of this link. In days past, tools living in /bin and /sbin were used to mount a /
usr partition and then allow access to /usr/bin and /usr/sbin. Nowadays, this task is handled
earlier in the boot process by other tools and the requirement is no longer necessary. The structure is
kept for backward compatibility with tools that may require the existence of both /bin and /sbin
directories. More details can be found at https://refspecs.linuxfoundation.org/
FHS_3.0/fhs/index.html or https://www.linuxfoundation.org/blog/blog/
classic-sysadmin-the-linux-filesystem-explained.
Since we already touched on the /bin and /sbin directory, let’s explain the difference. The /usr/
bin directory contains binaries—in other words, commands that can be of interest to every user
in the system. The /usr/sbin directory contains so-called system binaries. Those are commands
that should concern only the root user. It will also contain binaries for system processes (called
daemons)—programs that run in the background and do important work for the running system.
The /root directory is the home of the superuser. This is where all its configuration files lay.
The interesting one is the /home directory. This is where all the user home directories exist. When I
created my admin user for my home machine, it was placed in the /home/admin folder.
Of importance to us at this moment will also be the /etc/ directory. It contains all the configuration
files for the whole system: the source for online package repositories, default shell configuration, system
name, processes that start at the boot, system users and their passwords, and time-based commands.
On a freshly installed Debian 11 system, the /etc/ directory contains about 150 subdirectories and
files, and each subdirectory may contain more folders inside.
The /tmp folder contains temporary files. They only live when the system is booted and will be
deleted the moment it is shut down or restarted. The nature of those files is often very volatile; they
can hop into existence and disappear very fast or can be modified very often. It is not uncommon for
this directory to only exist in the computer’s RAM. It’s the fastest storage device your system has and
will automatically purge on restart or power off.
As mentioned earlier, additional drives are mounted under this structure. We could have a separate
hard drive for home directories. The whole /home folder may live on it or even on a networked
hard disk array. As mentioned, the /tmp directory is often mounted in the RAM. Sometimes, the /
var directory (which contains things that can change often in the system but are not supposed to
be purged, such as logs) is mounted on a separate drive. One of the reasons is that the contents of /
var, and especially of /var/log (where the system logs live), can grow very fast and take all the
available space, making accessing the system impossible or very tricky.
Finally, there are two important and special directories that exist everywhere you go:
• .: A single dot means the current directory. If you choose to go to a . folder, you’ll end up
where you are. It’s useful, however, as you’ll see in Chapter 3.
• ..: Two dots mean the directory above us—the parent directory. If you choose to go to a ..
folder, you’ll end up one level above where you started. Note that for the / directory, both .
and .. mean the same: /. You can’t go any higher than the root.
Running a program
Now that we know some things about the folder hierarchy, let’s briefly touch on executing programs.
There are three basic ways to execute a program in a shell:
• Call it by its name: This requires that it is placed in a directory that is in a PATH variable
(explained in Chapter 3).
• Call it by an absolute path: The absolute path starts with /. When using the absolute path, you
have to list all the directories that lead to the program, including the leading /. An example
execution may look like this:
/opt/somecompany/importantdir/bin/program
• Call it by a relative path: This will not start with a dot or two dots. This way of executing a
program requires that you know where in the filesystem you are and where in the filesystem
this program is. It’s useful if you are in the same directory as the binary or very close to it:
To call a program in the same directory as your user, you precede it with a dot and a slash:
./. This shortcut means the current directory. A sample call could look like ./myprogram
or ./bin/myprogram. The latter would mean: let’s start a program called myprogram
that is in a bin directory that is in the current directory.
To call a program in a directory somewhere else in the system using a relative path, we will
have to use the two dots, meaning the parent folder. Let’s say you are logged in to your home
directory, /home/admin, and want to execute a program in /opt/some/program/
bin; you’d call ../../opt/some/program/bin/myprogram. The two dots and
slash mean moving up.
If this looks arcane, it is because it is a little bit. Fortunately, everything will start coming together as
the book progresses.
The command to teach you all commands

You should get into the habit of searching the internet whenever you have a question or problem.
Most of the issues you are going to run into are already fixed or explained out there. However, there’s
one command that can save your life—or at least lots of time. You should make another habit of using
it often – even if you are sure you know the correct syntax, you might just discover a better way of
completing your task. This command is as follows:
$ man
The man command is a shorthand for manual and it is exactly what it says: it is a manual for whatever
command you want to learn about. To learn more about the man command, simply call the following:
$ man man
The output you’ll see should be similar to the following:
MAN(1)                                                                 
                                   Manual pager utils                                     
                                                               MAN(1)
NAME
       man - an interface to the system reference manuals
SYNOPSIS
       man [man options] [[section] page ...] ...
       man -k [apropos options] regexp ...
       man -K [man options] [section] term ...

       man -f [whatis options] page ...
       man -l [man options] file ...
       man -w|-W [man options] page ...
DESCRIPTION
       man is the system's manual pager.  Each page argument given
to man is normally the name of a program, utility or function.  The
manual page associated with each of these arguments is then found and
displayed.  A section, if
       provided, will direct man to look only in that section of the
manual.  The default action is to search in all of the available
sections following a pre-defined order (see DEFAULTS), and to show
only the  first  page  found,
       even if page exists in several sections.
I have cut it for brevity. A well-written man page will have several sections:
• name: This is where the name of the command is stated. If the command exists under various
names, they will all be listed here.
• synopsis: This will list possible ways of calling the command.
• description: This is the purpose of the command.
• examples: This will show several examples of the command call, to make the syntax clearer
and give some ideas.
• options: This will show all the available options and their meaning.
• getting help: This is how to get a shortened version of the command synopsis.
• files: If the command has configuration files or consumes files known to exist in the
filesystem, they will be listed here (for man, I have listed /etc/manpath.config and /
usr/share/man).
• bugs: This is where to look for bugs and report new ones.
• history: This will show all the current and previous authors of the program.
• see also: These are programs that are in some way tied to the command (for man:
apropos(1), groff(1), less(1), manpath(1), nroff(1), troff(1), whatis(1),
zsoelim(1), manpath(5), man(7), catman(8), and mandb(8)).
Many commands will contain a lot of additional sections, specific to this program.
The man pages will contain a lot of knowledge, and sometimes the names will duplicate. This is where
the mysterious numbers in brackets come into play. The man pages are broken down into sections.
To quote the man page about man:
1. Executable programs or shell commands

2. System calls (functions provided by the kernel)
3. Library calls (functions within program libraries)
4. Special files (usually found in /dev)
5. File formats and conventions, for example, /etc/passwd
6. Games
7. Miscellaneous (including macro packages and conventions), for example, man(7), groff(7)
8. System administration commands (usually only for root)
9. Kernel routines [non-standard]
Let’s take, for example, printf. There are several things that are called printf. One of them is a
library function of the C programming language. Its man page will live in section 3.
To read about that library function, you have to tell man to look into section 3:
admin@myhome:~$ man 3 printf

PRINTF(3)                                                              
                                Linux Programmer's Manual                                
                                                             PRINTF(3)
NAME
       printf, fprintf, dprintf, sprintf, snprintf, vprintf, vfprintf,
vdprintf, vsprintf, vsnprintf - formatted output conversion
If you don't, what you'll get is a shell function for printing—totally
useless in C programming:
admin@myhome:~$ man printf
PRINTF(1)                                                              
                                       User Commands                                        
                                                           PRINTF(1)
NAME
       printf - format and print data
SYNOPSIS
       printf FORMAT [ARGUMENT]...
       printf OPTION
Another random document with
no related content on Scribd:
Turk and Armenian are in the wrong, and that, as very often
happens, it is the innocent who have suffered for the
wrong-doings of the guilty. When it is asserted on behalf of
the Turks that they are engaged in suppressing a revolutionary
movement in Armenia, the statement is fully justified by the
facts of the case. There does exist in Armenia an extremely
vigorous revolutionary movement, and it is equally beyond
question that the methods of some of the leaders of this
movement are no less shocking than the barbarity of the Turk
in suppressing it. At every step," he added, "I became more
and more convinced that the inhuman ferocity displayed in this
terrible struggle for the mastery has not been in the least
exaggerated in the reports of the massacres already published
in England. At Bitlis I heard the story of a Turkish soldier
who boasted, as one who had achieved a glorious feat, that he
had taken part in the disembowelling of thirty pregnant
women. 'Two lives in one,' was the rallying cry of the armed
men who perpetrated this butchery. Another soldier, who had
taken part in a massacre in a church, described, gloating upon
every ghastly detail, how he had slipped and slid along the
blood-washed floor while the inhuman work proceeded.
Unfortunately, something very like a counterpart of these
atrocities is presented by the methods of some of the leaders
of the Armenian revolutionary movement. I believe there is no
doubt of the fact that certain of these Armenian conspirators
arranged to murder the Reverend Dr. Edward Riggs and two other
American missionaries at Marsovan, and fasten the blame upon
the Turks, in order that, as they imagined, the United States
might inflict summary punishment upon the Turkish Government,
thereby rendering Armenian independence possible. The
missionaries only escaped through a timely warning which they
received from an Armenian friend. Dr. Riggs has devoted his
life to the education of the Armenian youth in the missionary
schools, but the conspirators, in their blind fanaticism, gave
this fact little heed."
There could be no denial however, that the treatment of

Armenia and the Armenians by their Turkish political masters
was horribly bad. In May, the governments of Great Britain,
France and Russia united in proposing certain reforms for
Armenia, over which there were evasive and dilatory
negotiations carried on by the Porte for several months.
Meantime, the Armenians became more aggressive and
threatening, and a secret society called the "Hintchak," which
had been in existence among them since 1887, assumed great
activity. Connected with the Hintchak there was said to be an
organization of spies and "executioners," the latter of whom
carried out decrees of assassination, arson, and
bomb-explosion which the society had pronounced. Finally, on
the 17th of October, an imperial irade (edict, or decree) was
issued, approving and adopting the project of reform which the
British, French and Russian ambassadors had submitted to the
Porte.
{538}
But the appearance of the sultan's ineffectual irade was
speedily followed by fresh reports of frightful massacres of
Armenians, at Trebizond, Erzeroum, Bitlis, Zeitoun, and
elsewhere, with outraging of women and destruction of
property, which increased rather than diminished as time went
on. There was no sign that anything had been done towards
carrying out the promised reforms; though the sultan wrote
personally to Lord Salisbury to remonstrate against an
expression of skepticism concerning them, which the latter had
let fall in a speech, and to say to the British Premier: "I will
execute the reforms. … This is my earnest determination, as to
which I give my word of honour." But nothing came of it all,
and the Powers which had received the Sultan's promises could
agree on no steps further, except to demand and obtain
permission to bring, each, an additional gunboat into the
Bosphorus.
Annual Register, 1895,

pages 284-294 and 190-193.
In response to a resolution of the Senate of the United States
asking for information relative to the treatment of the
Armenian subjects of the Turkish government, the Secretary of
State, Mr. Olney, on the 19th of December, 1895, communicated
the following, among other statements of fact: Of the
massacres at Sassoun, which occurred in August, 1894, "the
Department of State has little trustworthy information. …
Since that time appalling outbreaks against the Armenians have
occurred in many other parts of Asia Minor, where these
unfortunate people form but a small minority of the
population. At first they were scarcely more than local riots,
as at Tokat, in the vilayet of Sivas, in March last, where one
Armenian was killed outright and more than 30 wounded by the
Turkish soldiery. In June last an attempted rising of
Armenians in the province of Aleppo in the mountains of
Kozar-Dagh and Zeitoun was thwarted without bloodshed by the
arrest of the alleged conspirators. … In July a band of armed
Armenians crossing into the vilayet of Erzerum from Russia was
dispersed, several being killed or captured. By August the
Moslem feeling against Armenians had become so far aroused
that rumors of intended massacres came from several
independent quarters, Harpoot, Marsovan, and Bitlis among
them, which led to urgent demands by the United States
minister for adequate measures looking to the due protection
of American citizens in those places.
"On the 30th of September grave disturbances began at

Constantinople itself. Several hundred Armenians, who had
gathered for the purpose of going in a body to the Sultan's
palace and demanding redress for the grievances of their
countrymen, were dispersed by the police after a severe
conflict in which a number of Turks and Armenians were killed
and wounded. Mob violence followed, the Armenians resident in
various quarters of the capital being assailed by an excited
Turkish rabble, and over 50 were slain. The rioting continued
the next day, October 1, in Constantinople and its suburbs.
Some 800 or 1,000 Armenians were captured or arrested, many of
them being armed with new revolvers of a uniform pattern. By
the third day order was restored, and the Armenians who had
sought refuge in their churches returned to their homes. The
effect of this outbreak at the national capital was most
disastrous in the provinces. The danger of a general massacre
of Christians in the vilayets of Adana and Aleppo seemed so
imminent, that renewed orders for the effective protection of
American citizens in those quarters were demanded and
obtained. Fears for their safety at Hadjin, Mersine, and
Marash were especially felt, and the cruiser Marblehead was
promptly ordered to Iskanderoun (Alexandretta), the nearest
seaport.
"On October 8 a Turkish uprising occurred at Trebizond, due,

it is reported, to an attempt to assassinate the late Vali of
Van as he was about to leave for Constantinople, the Turks
claiming that the act was done by an Armenian and that they
were in danger of a general Armenian attack. On the 9th the
disturbance was renewed, many Armenians being killed and their
homes and shops looted by the mob. The authorities attempted
to quell the riot, but having only some 400 soldiers and
policemen at command, were powerless, and murder and pillage
ran their course as long as an Armenian was in sight. The
official Turkish reports give the number of Armenians slain as
182, of Turks 11, but the general estimate places the total
number at some 500. Reinforcements of troops soon arrived, and
quiet was restored. No injury to American citizens or property
occurred.
"From this time the reports of conflicts between Turks and

Armenians, with great loss of life, become frequent and
confused. At Akhissar, some 60 miles from Smyrna, 50 Armenians
were killed October 9. Koordish raids terrorized many parts of
the Armenian provinces. At Bitlis over 500 were reported
killed, the Turkish accounts alleging that the Armenians
attacked the Moslem mosques during the hour of prayer. At
Diarbekir 5,000 are said to have lost their lives, of which
2,300 were Mussulmans—but the Turkish authorities pronounce
this estimate exaggerated. From Malatia comes the report of a
'great massacre' early in November, when every adult male
Christian is said to have perished. Another sanguinary
outbreak, with great slaughter, is reported from Sivas on
November 12; some 800 Armenians and 10 Koords are said to have
been killed. At Hadjin and Ourfa loss of life is reported, the
American missionaries at those places being protected by
Turkish guards under orders from the Porte.
"The Kaimakam of Hadjin is credibly said to have announced

that he would destroy the town and sow barley on its site.
There being an American school at that place, directed by
American teachers, the United States minister thereupon
notified the Porte that if one of those American ladies
received injury from the riotous conduct of the populace, he
would demand, in the name of the United States, 'the head of
that Kaimakam.' That officer has since been removed. Later
reports allege massacres at Marsovan and Amasia. The consular
agent at Aleppo telegraphs that a severe conflict had occurred
at Aintab, and that great fear prevailed at Aleppo. The
burning of the American buildings at Harpoot took place during
a bloody riot, and many persons are said to have perished in
the province of that name. At Kurun 400 deaths are reported.
Particulars of the recent outbreak at Marash, on November 19,
in which American missionary property was destroyed, have not
yet been received.
{539}
"These scattered notices, for the most part received by

telegraph, are given, not as official averment of the facts
stated, but as showing the alarming degree to which racial
prejudices and fanatical passions have been roused throughout
Asia Minor. As above said, the Department of State has and can
have official knowledge regarding but few of these reported
massacres, and though up to the early part of December the
United States minister estimated the number of the killed as
exceeding 30,000, it is more than likely that the figures are
greatly exaggerated. At latest advices mob violence and
slaughter appear to have been checked, or at least to have
partially subsided. The Turkish Government has been emphatic
in assurances of its purpose and ability to restore order in
the affected localities; new governors have been appointed in
many of the provinces, troops have been sent to the scene of
recent or apprehended disorders, and forces have been massed
to subdue the Armenians who had gained the ascendant in
Zeitoun."
Of the American missionary establishments in Turkey, and of

the extent to which they suffered harm during the outbreaks,
the same report gave the following account:
"The number of citizens of the United States resident in the

Turkish Empire is not accurately known. According to latest
advices there are 172 American missionaries, dependents of
various mission boards in the United States, scattered over
Asia Minor. There are also numbers of our citizens engaged in
business or practicing professions in different parts of the
Empire. Besides these, more or less persons, originally
subjects of Turkey and since naturalized in the United States,
have returned to the country of their birth and are
temporarily residing there. The whole number of persons
comprising these several classes can not be accurately
estimated, but, the families of such citizens being
considered, can hardly be less than five or six hundred, and
may possibly exceed that total.
"Outside of the capital and a few commercial seaport towns,

the bulk of this large American element is found in the
interior of Asia Minor and Syria, remote from the few consular
establishments maintained by this Government in that quarter,
inaccessible except by difficult journeys, and isolated from
each other by the broken character of the mountain country and
the absence of roads. Under these circumstances and in the
midst of the alarming agitation which for more than a year
past has existed in Asia Minor, it has been no slight task for
the representative of the United States to follow the
interests of those whose defense necessarily falls to his
care, to demand and obtain the measures indispensable to their
safety, and to act instantly upon every appeal for help in
view of real or apprehended peril. It is, however, gratifying
to bear testimony to the energy and promptness of the minister
in dealing with every grievance brought to his notice, and his
foresight in anticipating complaints and securing timely
protection in advance of actual need. The efforts of the
minister have had the moral support of the presence of naval
vessels of the United States on the Syrian and Adanan coasts
from time to time as occasion required. …
"While the physical safety of all citizens of the United

States appears up to the present date to have been secured,
their property has, on at least two recent occasions, been
destroyed in the course of local outbursts at Harpoot and
Marash. The details of the Harpoot destruction have so far
been only meagerly reported, although it took place about the
middle of November. It is stated that the buildings at that
place were set on fire separately by Kurds and citizens, in
the presence of the Turkish soldiery, during an Armenian riot.
Besides the chapel, girls' theological school and seminary
building, the ladies' house, boarding house, and residences of
three American missionaries were burned, the aggregate loss on
the buildings, personal property, stock, fixtures, and
apparatus being estimated in the neighborhood of $100,000. The
United States minister has notified the Porte that the Turkish
Government will be held responsible for the immediate and full
satisfaction of all injuries on that score. The American
Missionary School of Science at Marash was burned during a
sanguinary outbreak on November 19. The value of the property
destroyed has not been ascertained, but after prompt
investigation the minister will make like demand for adequate
indemnity."
United States, 54th Congress, 1st Session,

Senate Document, Number 33.
"On November 9 one of tho Foreign Consuls arrived at

Constantinople from Erzeroum on leave, and he reported the
scene on his journey as heartrending. 'The whole country
between Trebizond and Erzeroum was devastated. He counted 100
dead bodies lying by the road near one town. Nearly all the
villages were burnt, and in many cases the male population
entirely wiped out.' At last, on December 13, 1895, Lord
Salisbury received the following telegraphic despatch from Sir
Philip Currie: 'It may be roughly stated that the recent
disturbances have devastated, as far as the Armenians are
concerned, the whole of the provinces to which the scheme of
reforms was intended to apply; that over an extent of
territory considerably larger than Great Britain all the large
towns, with the exception of Van, Sassun, and Moush, have been
the scene of massacres of the Armenian population, while the
Armenian villages have been almost entirely destroyed. A
modest estimate puts the loss of life at 30,000. The survivors
are in a state of absolute destitution, and in many places
they are being forced to turn Mussulmans. The charge against
the Armenians of having been the first to offer provocation
cannot be sustained. Non-Armenian Christians were spared, and
the comparatively few Turks who fell were killed in
self-defence. The participation of the soldiers in the
massacres is in many places established beyond doubt.'
"Of the appalling horror of this account I wish it were

needless to speak. … [It] would be none the less horrible if
the whole of the people massacred and outraged, ruined, and
starved, and driven to the snowy mountains in the middle of
winter, had been all the rudest villagers of the most rustic
village communities. But when we know that many thousands of
the victims have been people educated at Christian schools and
colleges, and who had acquired there, in addition to the
ineradicable virtues of their native and ancient faith, much
also of the refinements and activities of civilised life, we
may reach some true conception of the agonies which have been
inflicted on such a people in the face of Europe and of the
world by the cruelty and brutality of the Turks.
{540}
It is, indeed, right that our first indignation should be
directed against the infamous Government of Turkey. … Let us
remember that this is not a Government with which we have had
nothing to do, or for which we have had no responsibility, but
a Government which the European Powers, and we especially,
have been protecting and nursing for half a century. … Then we
may indeed begin to think, with remorse and shame, of our
handiwork, and of its results. In this particular case,
indeed, the immediate blame lies almost alone with Russia. By
a complete departure from all her previous great traditions
she deliberately refused to join the other Powers of Europe
for the purpose of compelling the Sultan to act with decent
humanity to those of whom she had been the declared defender.
She had the physical power and the geographical opportunity
which others had not; and there can be no doubt whatever that
a joint occupation of the waters of Constantinople by the
fleets of the European Powers would have secured the very
moderate demands that Europe made upon the Porte."
The Duke of Argyle,

Our Responsibilities for Turkey,
pages 116-122.
TURKEY: A. D. 1896.
Conflict in Crete between Christians and Mussulmans,
and its preceding causes.
In 1868, the Cretans, for the second time, were thrust under
the Turkish yoke. "By way of solace the Powers exerted
themselves feebly in inducing the Porte to concede the
so-called 'Organic Statute'
See (in volume 3)

GREECE: A. D. 1862-1881.
Organic Regulation.
… As the Charter remained a dead letter, the Cretans seized

the next favourable opportunity to rise in 1877. Their case
was brought before the Congress of Berlin; but the only relief
the Powers could extend to them was a fresh promise on the
part of the Porte, recorded in the XXIII Article of the
Treaty, to observe scrupulously that Organic Statute, which
had been proved to be unworkable. Meanwhile, the Cretans had
remained under arms during the whole of 1878, the island being
again almost completely devastated by the half-naked and
famishing troops which had survived the Russo-Turkish War.
Ultimately, through the mediation of England, the Porte was
induced, in November of that year, to concede the Pact of
Halepa, so named after the village near Canea where it was
negotiated, and signed under the supervision of the British
Consul, Mr. T. B. Sandwith—this fact being expressly recorded
in the preamble of the document. The arrangement was accepted
by the Cretans as a compromise, in spite of its many and
manifest drawbacks. Nevertheless, it brought about, at the
outset, certain beneficial results. Political parties were
formed in which the Mohammedan Cretans blended, irrespective
of religious differences, with their Christian countrymen; and
the unprecedented phenomenon of a Christian Vali completing
his four years' tenure of governorship was witnessed in the
person of Photiades Pasha.
"But this tendency to conciliation of the conflicting elements

in the island was by no means to the liking of the Porte. The
presence of a Mussulman military governor was therefore
discovered to be necessary; and as his grade was usually
superior to that of the Vali, and the Mussulman sub-governor
was the official whose recommendations were of weight with the
Porte, nothing was easier than to create insuperable
difficulties for the Christian Vali. Thus successive Valis
were compelled—often by private wire from Constantinople—to
tender their resignation; while, at the same time, the Porte
took care not to fulfil the financial engagements prescribed
by the Pact. By these means an acute crisis was brought about
under the Governorship of Sartinski Pasha, a Pole, in 1889,
when a preconcerted plan of deception and treachery was
carried out by the Porte with consummate skill.
"The Cretans, as it is but natural, are guided in critical

contingencies by the advice they seek at Athens. The Porte
therefore promised to the Greek Government, as soon as things
began to assume a threatening aspect in Crete, to satisfy the
demands of the islanders, provided they were prevailed upon to
abstain from occupying certain important positions. In spite
of the transparent perfidy of the proposal, M. Tricoupis, the
then Greek Premier, fell into the snare. While the Cretans
were held back, troops were poured into the island, and the
strategical points having been seized, the Greek Government
and the Cretans were defied. An Imperial firman, issued in
November of that year, abrogated the Pact of Halepa and the
British Government, under whose auspices it was concluded, was
now powerless to exact respect for what was virtually an
international arrangement. There was no longer any question of
a Christian Vali with a fixed tenure of office, or of an
Assembly of Cretan representatives. Shakir Pasha, the
commander of the Turkish troops, was invested with absolute
civil and military authority; Mussulman Albanians occupied the
Christian villages as gendarmes, and Crete continued to submit
to this kind of martial law up to 1894. When, however, Mahmoud
Djelaleddin Pasha, the then Mussulman Vali, surpassed even his
predecessors in arbitrariness, and actually dictated to the
tribunals decisions in favour of Mohammedan litigants, the
Cretans began to lose patience and another outbreak appeared
imminent. It was only then that the Great Powers moved in the
matter and prevailed upon the Porte to revert partly to the
pre-existing order of things, by appointing Alexander
Karatheodory Pasha, a Christian and a Greek, as Governor.
Beyond this, however, the Pact of Halepa was not observed.
True to its traditional tactics, the Porte took with one hand
what it had given with the other. The Mussulman Deputy
Governor and the military commander frustrated every effort of
the Vali, the very funds necessary for the maintenance of the
gendarmerie being denied him. Karatheodory was consequently
forced to resign. Complete anarchy now reigned in the island."
Ypsiloritis,
The Situation in Crete
(Contemporary Review, September, 1896).
"Occasional skirmishes between the Christian inhabitants and

the soldiers kept the excitement simmering and ushered in the
sanguinary scenes that finally followed. Turkhan Pasha, taking
time by the forelock, armed the Cretan Moslems for the combat
with the approval of the commander of the troops, and the
city of Canea prepared for a blood bath. The Mohammedan Lent
(Ramazan) was drawing to a close, and the three days of
rejoicing which invariably follow (Bairam) were supposed to be
fixed for the attack on the Christians. These anticipations
were duly realised, and on the 24th May, 1896, at 1 o'clock P.
M., the Turks fired the first shots, blowing out the brains of
several Christians to make that Moslem holiday.
{541}
Forearmed, however, is forewarned, and the Christians defended
themselves to the best of their ability on that day and the
25th and 26th, during which every house in Canea was
barricaded, and neighbours living on opposite sides of the
absurdly narrow streets fired at each other from behind stone
heaps piled up in the windows of their bedrooms. The streets
were deserted, all traffic suspended, and it was not until the
27th that the thirty Christian corpses (including two women
and four children) and the twenty lifeless Turks were removed
for burial.
"These events provoked a new administrative change of scene:
Turkhan Pasha was recalled, and Abdullah Pasha, at the head of
four battalions from Salonica, came to take his place. These
troops laid waste the villages and fields of the provinces of
Apokorona, Cydonia, and Kissamo, burning houses, huts, and
churches on the way. The best soldiers in the world, however,
run terrible risks in the interior of Crete, and Abdullah was
repulsed with the loss of two hundred men at the town of
Vamos. The foreign consuls at Canea, having verified these
facts, strongly blamed his conduct in a joint verbal note, and
the Porte shortly afterwards recalled him, and appointed
Berovitch Pasha [Prince of Samos] in his place. This was the
beginning of the end. The Christians of the island meanwhile
met, and through their delegates formulated certain demands,
which the foreign consuls referred to their ambassadors at
Constantinople, and the famous 'Modifications of the
Convention of Halepa' were framed in consequence. The sultan,
too, yielding to tardy pressure, graciously conceded the
nomination of a Christian governor-general in the person of
Berovitch, the summoning of the National Assembly, and other
demands. … The questions of the tribunals and the gendarmerie
[for the enforcement of peace and order in the island] were to
be arranged by international commissions; but weeks and months
passed away before they were even appointed. … At last the
commissions arrived and began their work in December [1896]."
E. J. Dillon,
Crete and the Cretans
(Fortnightly Review, May, 1897).
TURKEY: A. D. 1896 (January-March

Turkish opposition to English and American measures
for relief to Armenian sufferers.
Work of Miss Clara Barton and the Red Cross Society.
For some time the distribution of supplies from England and

America to the sufferers in Armenia was forbidden by the
Turkish government, for reasons stated by the Turkish minister
at Washington as follows: "The collections are made on the
strength of speeches delivered in public meetings by
irreconcilable enemies of the Turkish race and religion, and
on the basis of false accusations that Turkey repudiates.
Besides, the Sublime Porte is mindful of the true interests of
its subjects, and, distinguishing between the real state of
things and the calumnies and wild exaggerations of interested
or fanatical parties, will under its own legitimate control
alleviate the wants of all Turkish subjects, irrespective of
creed or race." The Red Cross Society, of which the American
branch had prepared to send its President, Miss Clara Barton,
with a small corps of assistants, to the scene of the
suffering, was especially excluded, by the order of the Porte.
Miss Barton and her staff sailed, however, from New York, in
January, and Mr. Terrell, the American minister at
Constantinople, succeeded in obtaining permission for them to
do their humane work as private individuals, not in the name
of the obnoxious society, and without displaying its insignia:
The single-mindedness, the prudence, the patient energy with
which Miss Barton pursued the one object of giving relief to
the suffering, overcame all opposition and all obstructions,
so that, in April, she was able to report:
"The way is all made clear for sending supplies. The suitable
agents all along the route are now known, and have been
arranged with for service, so that heavy supplies can be sent
at any and all times as they are needed. I feel my breath come
lighter as I think of these poor scourged and fever-stricken
towns without even one doctor, when our sixteen strong,
skilled men, with twenty-five camels' burden of supplies,
shall carry some light of hope and help into their night of
hopeless woe. I am happy to be able to say for the comfort of
contributors, that I hold the written word of the Porte,
officially given through the minister of foreign affairs from
the grand vizier, that not the slightest interference with any
distribution within the province will be had. This official
document was addressed and delivered to Sir Philip Currie, the
British ambassador, and by him passed to me. The decision is
general and final, without question or reservation, and
settles all doubt."
In September Miss Barton returned home for rest, and to bear

her testimony to America of the immensity of the need still
existing in the Armenian provinces and calling for help. Her
departure from Constantinople was reported by the newspapers
to have been the occasion of a remarkable demonstration, by
cheers, flags and salutes, from ship and shore, of the
estimate put upon the work she had done.
TURKEY: A. D. 1896 (August).

Attack of Armenian revolutionists on the
Ottoman Bank at Constantinople.
Turkish massacre of Armenians in the city.
In the spring of 1896, the Armenian revolutionists, encouraged

by the outbreak in Crete, made fresh appeals for attention to
the sufferings of their country, with threats of some
desperate action if no heed was given. In August, the
desperate act was undertaken, at Constantinople, by 30 or 40
madly devoted men. This reckless little band of misguided
patriots made a sudden attack on the Ottoman Bank, a British
institution which controls finance in the Turkish empire,
gained possession of the building, made prisoners and hostages
of two of its directors and some 80 of its clerks, and were
fully prepared with dynamite to destroy everything within its
walls, including themselves, if certain reforms which they set
forth were not instantly decreed. Their theory was, that "the
Ambassadors would force the Sultan to grant the reasonable
reforms which they demanded for the Armenians, rather than
permit the destruction of the Bank and its staff. It was a
scheme borrowed from the theatre, absurd in itself, and made
ridiculous by the way in which they failed to carry it out.
They went in bravely, and nothing hindered their destroying
the Bank, but they allowed themselves to be talked out of it
by Mr. Maximoff, the Russian dragoman, and would have been the
laughing stock of the world if its attention had not been
absorbed by the massacre which followed.
{542}
"The real heroism of that day was displayed in another quarter

of the city, by another small party of Russian Armenians, men
and women, who took possession of two stone houses and fought
the Turkish troops to the death, the survivors killing
themselves when they could fight no longer. There was no
serious fighting anywhere else, although dynamite bombs were
thrown from the windows of houses and khans upon the troops in
a number of places, showing that some preparation had been
made for a more extended outbreak. There is nothing to be said
in justification of this attempt of the revolutionists. They had
provocation enough to justify anything in reason, but there
was nothing reasonable in this plan, nothing in it to attract
the sympathy of the Powers or to conciliate public opinion;
and if the statements are true which have been made by
Armenians as to certain unexecuted parts of the plan, it was
diabolical. This only can be said on behalf of these
revolutionary committees. They are the natural outcome of the
treatment of the Armenians by the Turkish Government during
the last twenty years. When oppression passes a certain limit
and men become desperate, such revolutionary organisation
always appears. They are the fruit and not the cause of the
existing state of things in Turkey, and if we can judge by the
experience of other countries, the worse things become here,
the more violent will be the action of these committees,
whether Europe enjoys it or not.
"Revolutionists are the same all the world over, but the
Turkish Government is unique, and it is not the attack on the
Bank which interests us but the action of the Government which
followed it. As we have said, the authorities had full
information of what was to be attempted and did nothing to
prevent it, but they made every preparation for carrying out
their own plan. Bands of ruffians were gathered in Stamboul,
Galata, and Pera, made up of Kurds, Lazes, and the lower class
of Turks, armed with clubs, knives or firearms; and care was
taken that no one should kill or plunder in the quarter to
which he belonged, lest he should be recognised and complaint
made afterwards by the Embassies, with a demand for
punishment. A large number of carts were in readiness to carry
off the dead. The troops and police were in great force to
prevent any resistance, and to assist the mob if necessary. It
was a beautiful day, the streets were crowded, and few had any
idea of what had happened at the Bank, when suddenly, without
any warning, the work of slaughter and plunder began,
everywhere at once. European ladies on the way to the
Bosphorus steamers suddenly found themselves surrounded by
assassins, and saw men beaten to death at their feet. Foreign
merchants saw their own employés cut to pieces at their doors.
The streets in some places literally ran with blood. Every man
who was recognised as an Armenian was killed without mercy. In
general, the soldiers took no part in the slaughter and
behaved well, and this somewhat reassured those in the streets
who were not Armenians; but in a few moments the shops were
closed and a wild panic spread through the city. The one idea
of everyone was to get home; and as the foreigners and better
classes live out of the city in summer they had to go to the
Galata bridge to take the steamers, which ran as usual all
through the three days of massacre. This took them through the
streets where the slaughter was going on, and consequently we
have the testimony of hundreds of eye-witnesses as to what
took place. The work of death and plunder continued unchecked
for two days. On Friday there were isolated outbreaks, and
occasional assassinations occurred up to Tuesday.
"The number killed will never be known. The Ambassadors put it

at 5,000 or 6,000; the official report to the palace at 8,750,
besides those thrown into the sea. Thousands of houses, shops
and offices were plundered, including a number belonging to
Greeks and foreigners. Everything was done in the most
systematic way, and there was not a moment of anarchy, not a
moment when the army and police had not perfect control of the
city during all these days. … The majority of those massacred
belonged to the working class—especially the hamals
(porters)—but a large number of gentlemen, merchants and other
wealthy men, were killed, together with about fifty women and
children. The savage brutality of the Moslem mob was something
beyond all imagination, and in many cases the police joined in
beating men to death and hacking others to death with knives,
in the very face of Europeans. … In may cases European
officials appealed to the officers in command of the troops,
who were looking on at the slaughter of helpless, unarmed men,
to interfere and put a stop to it. The reply was 'We have
orders.' It was an officer who killed the clerk of the British
Post-office on the steps. And some of the most cold-blooded
and horrible murders took place in front of the guard house,
at the Galata end of the bridge, in the presence of officers
of the Sultan's household of the highest rank. They also had
their orders.
"Happily for the honour of the Turkish people, there is

another side to the story. It was the Government and not the
people that conducted this massacre. And although the vile
instruments employed were told that they were acting in the
name of the Prophet, and freely used his name, and are
boasting to-day of what they did for Islam, the Sheik-ul-Islam
forbad the Softas taking any part in the slaughter, and many a
pious Turk did what he could to protect his neighbours. … It
is not the people, not even the mob, who are responsible for
this great crime. It was deliberately committed by the
Government. The Ambassadors of the six Powers have declared
this to be an unquestionable fact in the Joint Note addressed
to the Porte.
"Since the massacre this same Government has been carrying on
a warfare against the Armenians which is hardly less inhuman
than beating out their brains with clubs. There were from
150,000 to 200,000 Armenians in Constantinople. They were
merchants, shopkeepers, confidential clerks, employés in banks
and offices of every kind—the chief business men of the city.
They were the bakers of the city, they had charge of the khans
and bazaars and the wealth of the city; they were the porters,
house-servants, and navvies. … Now the Government has
undertaken to ruin this whole population. They are hunted
about the city and over the hills, like wild beasts. …
Thousands have been sent off at once to the Black Sea ports,
to find their way as best they can without money or food to
their desolated villages in the interior. … Thousands have
fled to foreign countries."
The Constantinople Massacre

(Contemporary Review, October, 1896).
{543}
TURKEY:A. D. 1897 (January-February).

Fresh conflicts in Crete.
Attitude of Christians and Mussulmans towards each other.
Reports of the British Consul-General and others.
Early in January, 1897, while proceedings for the organization

of the new gendarmerie were under way, and while the
discussion of candidates for the National Assembly, to be
elected in March, was rife, fresh hostilities between
Christians and Mussulmans broke out, and there seems to be
good evidence in the following report, by Sir Alfred Biliotti,
the British Consul-General at Canea, that responsibility for
the state of things in Crete should be charged upon one party
hardly more than upon the other. The despatch of the
Consul-General to Lord Salisbury, written January 9, 1897, is
partly as follows:
"In the afternoon of the 3rd instant a great panic occurred in
the town owing to a wounded Christian having been conveyed to
the hospital, where he died of his wounds in the night, and to
a rumour that two Mussulmans had been killed or wounded at the
same time on the road between Canea and Suda Bay. All the
shops were shut up as usual, but there was no general 'sauve
qui peut,' Christians especially having congregated in the
square near the hospital in the hope of finding out further
information. Happening to be in the town, I took a carriage
and drove towards Suda. When at about a mile distant from
Canea I came upon a number of Mussulmans, who told me that
four Christians going to Apokorona had, without any
provocation whatever, discharged their revolvers on three
Mussulmans, two of whom had been severely wounded. I saw one
of them in his cottage hard by the road with a bullet wound in
the abdomen; the other had been conveyed on horseback to the
village of Tsikalaria (southeast of Suda Bay), 2 miles from
where he had been wounded, of which he was a native. The four
Christians fled across the fields, leaving on the road a horse
and an overcoat, and took to the mountains.
"Between half and a quarter of an-hour after this incident

another Christian, a native, like the Turk, of Tsikalaria, was
passing on the road when he was fired upon by Mussulmans in
retaliation for the wounding of their two co-religionists. Not
having been hit, the Christian jumped from his mule and ran
for his life along the Suda road, being pursued by armed
Turks. He was overtaken by three of them about half-a-mile
farther down, and was shot at and mortally wounded at 20 paces
in front of Commander Shortland, of Her Majesty's ship 'Nile,'
who was coming on foot from Suda Bay to Canea. The wounded
Christian was taken charge of by the Albanian corporal
stationed in a Christian monastery close by, and was
subsequently put in a carriage by the Russian Consul, who was
returning from Suda Bay at that moment, and sent to the town
hospital, where he died. While I was making inquiries on the

The Linux Devops Handbook Customize and Scale Your Linux Distributions To Accelerate Your Devops Workflow 1O Edition Wojslaw Full Chapter

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

The Linux Devops Handbook Customize and Scale Your Linux Distributions To Accelerate Your Devops Workflow 1O Edition Wojslaw Full Chapter

Uploaded by

Copyright:

Available Formats

The Linux DevOps Handbook:

Customize and scale your Linux

Customize and scale your Linux distributions to accelerate

Group Product Manager: Preet Ahuja

First published: November 2023

Production reference: 1171023

Published by Packt Publishing Ltd.

About the authors

Part 1: Linux Basics

Know your rights 27

Understanding scripting 68 Understanding the backup script –

Part 2: Your Day-to-Day DevOps Tools

A few words about Upstart, an Summary106

Anatomy of Docker 162 docker volume 177

Part 3: DevOps Cloud Toolkit

IaC versus Configuration as Code 290 HCL in depth 317

Stay curious and proactive 371 Actionable380

Other Books You May Enjoy 404

Who this book is for

What this book covers

To get the most out of this book

Software/hardware covered in the book Operating system requirements

Download the example code files

docker build [OPTIONS] PATH | URL | -

docker build [OPTIONS] PATH | URL | -

Any command-line input or output is written as follows:

chmod ug=rx testfile

Tips or important notes

Share Your Thoughts

Download a free PDF copy of this book

1. Scan the QR code or visit the link below

2. Submit your proof of purchase

• Chapter 1, Choosing the Right Linux Distribution

• What is Linux and what is a Linux distribution?

What exactly is a Linux distribution?

What makes distributions different?

To choose your distribution, you need to pay attention to several factors:

Introducing the distributions

Red Hat Enterprise Linux (RHEL)

• What a command line is and how it works

The Linux command line – shell

• Log in to the Terminal (screenshot in Figure 2.1)

• Open a Terminal window in a graphical interface, if you have one

Getting to know your shell

Figure 2.1 – Login screen

For the root user, it would look like this:

The filesystem structure

The command to teach you all commands

The output you’ll see should be similar to the following:

man -K [man options] [section] term ...

1. Executable programs or shell commands

admin@myhome:~$ man 3 printf

There could be no denial however, that the treatment of

Annual Register, 1895,

"On the 30th of September grave disturbances began at

"On October 8 a Turkish uprising occurred at Trebizond, due,

"From this time the reports of conflicts between Turks and

"The Kaimakam of Hadjin is credibly said to have announced

"These scattered notices, for the most part received by

Of the American missionary establishments in Turkey, and of

"The number of citizens of the United States resident in the

"Outside of the capital and a few commercial seaport towns,

"While the physical safety of all citizens of the United

Know your rights 27

Understanding scripting 68 Understanding the backup script –

A few words about Upstart, an Summary106

Anatomy of Docker 162 docker volume 177

IaC versus Configuration as Code 290 HCL in depth 317

Stay curious and proactive 371 Actionable380

Other Books You May Enjoy 404

       man -K [man options] [section] term ...