diff --git a/01/intro-to-sysadmin.tex b/01/intro-to-sysadmin.tex index b359716..3c59a59 100644 --- a/01/intro-to-sysadmin.tex +++ b/01/intro-to-sysadmin.tex @@ -192,7 +192,7 @@ \section{What exactly does a System Administrator do?} And therein lies the bug: \verb+less(1)+ was invoked by the super user, it would check the permissions on the file \verb+/root/.lesshst+, follow the redirection -to \verb+/dev/null+ find that they're not \verb+0600+ +to \verb+/dev/null+, find that they're not \verb+0600+ and call \verb+chmod(2)+, yielding and unreadable/unwritable \verb+/dev/null+. We were able to confirm this behaviour and identified a code change @@ -1032,7 +1032,7 @@ \section{The Future of System Administration} The System Adminstrator's job definition is diverse, and so is the rather significant change the profession has undergone over the years. Gone are the days of -shuffling punch cards, of cycling magentic tapes, of +shuffling punch cards, of cycling magnetic tapes, of connecting your dumb terminals using RS-232 serial connections, of stringing ribbon cables inside large computer cases... or are they? diff --git a/03/documentation-techniques.tex b/03/documentation-techniques.tex index bfe9470..09642f2 100644 --- a/03/documentation-techniques.tex +++ b/03/documentation-techniques.tex @@ -711,7 +711,7 @@ \section{Formats} into language, then you have likely not fully understood the problem. Use illustrations as {\em supplementary}, not {\em instead of} information. -Text ought to be your primary content: it can can +Text ought to be your primary content: it can easily be skimmed, indexed and searched, glanced through in a matter of seconds, and parts of a paragraph be re-read with ease; a screencast or video, diff --git a/04/filesystems-and-storage-models.tex b/04/filesystems-and-storage-models.tex index 392e8ce..be9fc61 100644 --- a/04/filesystems-and-storage-models.tex +++ b/04/filesystems-and-storage-models.tex @@ -57,12 +57,12 @@ \section{Introduction} Available storage space is, despite rapidly falling prices for traditional hard disk drives, a scarce -resource\footnote{We will take a closer look a the +resource\footnote{We will take a closer look at the {\em Total Cost of Ownership\index{Total Cost of Ownership}} of a hard drive in Chapter \ref{chap:backup}. Suffice it to say that the purchase price of the storage device itself is only a -fraction.}. The quote a the beginning of this chapter +fraction.}. The quote at the beginning of this chapter is rather apt: no matter how much disk space we make available to our users, we will eventually run out and need to expand. In order to accommodate the @@ -2036,7 +2036,7 @@ \section{File System Layout} File names may contain any character except for this separator or the {\em NUL} character ({\tt -\textbackslash0}), used in the the C programming +\textbackslash0}), used in the C programming language to terminate a string.\footnote{It is a common mistake to assume that a file name contains only printable characters. The Unix system does not diff --git a/05/software-installation-and-package-management.tex b/05/software-installation-and-package-management.tex index c2ceb02..0306be0 100644 --- a/05/software-installation-and-package-management.tex +++ b/05/software-installation-and-package-management.tex @@ -226,7 +226,7 @@ \subsection{Up and down the software stack} see Chapter \ref{file systems:storage-models:dividing-and-combining-disks:partitions} \item execution of a secondary or second-stage boot loader -- \index{boot loader!second-stage} a small program allowing - the user to interactively choose an operating systems or + the user to interactively choose an operating system or kernel to boot; examples include GRUB\index{GRUB} (Figure \ref{fig:software-installation:grub}) or {\tt boot(8)}\index{\tt boot(8)} @@ -577,7 +577,7 @@ \subsection{Operating System vs. System Software vs. Third Party Software} As different OS providers disagree on what components should be part of their final product, it becomes very difficult to declare a software package to belong into -any one of the cateogries we've defined. However, +any one of the categories we've defined. However, most system administrators ultimately develop an instinctive idea of what should or should not be considered {\em essential}, what can and cannot be @@ -1009,7 +1009,7 @@ \subsection{OS Installation Overview} state than under normal circumstances, and it is possible to forget to enable or disable a service. Placing the system into production use without a fresh reboot might - lead to unexepcted results when the system is rebooted at + lead to unexpected results when the system is rebooted at a later point. \end{itemize} @@ -1058,7 +1058,7 @@ \subsection{OS Installation Overview} written your own deployment system. Or configuration management system. Or inventory database. Or parallel secure shell to perform tasks across all of -your host. Or... \\ [10pt] +your hosts. Or... \\ [10pt] Anyway, the system we wrote was elegant, and it taught us a lot about the details of the OS installation @@ -1264,7 +1264,7 @@ \subsection{OS Installation Details} Listing \ref{code:netbsd-install} shows the most basic steps to perform a minimal OS installation. It is -interesting to analyze each of them (and constrast the +interesting to analyze each of them (and contrast the sequence for different operating systems), as doing so often illustrates a number of assumptions made about the use of the software. The ease with which an OS @@ -1782,7 +1782,7 @@ \subsection{Inherent Security Risks} this end, they provide the capability for a given package to execute an arbitrary shell script provided in the package, with the privileges of the invoking -using -- commonly the superuser. +user -- commonly the superuser. In other words, it is important to understand that any time we use a package manager to retrieve and install diff --git a/06/of-users-and-groups.tex b/06/of-users-and-groups.tex index 09f1541..97bb4eb 100644 --- a/06/of-users-and-groups.tex +++ b/06/of-users-and-groups.tex @@ -50,7 +50,7 @@ \section{Introduction} in formalizing your access control requirements so as to express and apply them using your configuration management system\index{Configuration Management}, as -we will discuss in the Chapter +we will discuss in Chapter \ref{chap:configuration-management}. As one of our Pillars of Exceptional System Design, @@ -204,7 +204,7 @@ \section{Types of Users} sake, however, we should mention that more modern access semantics, such as {\em mandatory access controls} (MAC), {\em role-based access controls} -(RBAC), or POSIX ``capabilities'' can been added, +(RBAC), or POSIX ``capabilities'' can be added, albeit at the cost of increased complexity.} Reviewing these access rules, we can identify mappings @@ -667,7 +667,7 @@ \subsection{The Problem with Passwords} access is granted, and you are logged in. From that moment on, regular Unix semantics and permissions will apply to decide whether or not access to a given -resources (e.g. the ability to write to a file) is +resource (e.g. the ability to write to a file) is granted. Passwords are an easy and convenient way for users to @@ -721,7 +721,7 @@ \subsection{The Problem with Passwords} \gls{ldap}\index{LDAP}} is an example of this approach. However, it should be noted that the benefits of a central location of this information -carries a certain prize, as well: if the host(s) +carries a certain price, as well: if the host(s) providing this service becomes unavailable, thousands of hosts can become unusable or see debilitating errors. This problem can of course be defined in a @@ -740,7 +740,7 @@ \subsection{The Problem with Passwords} most people are rather terrible at remembering complex passwords (which are harder for computers to crack) and hence tend to use and reuse across different sites -a small set of a simple passwords This means that +a small set of simple passwords. This means that accounts on your systems may get compromised by password leaks in another, completely different and independent environment! @@ -827,7 +827,7 @@ \subsection{Sharing {\tt root}} protocols allow well-defined control of remote access do, for the most part, still follow an all-or-nothing access model locally. The access credentials for the -privileged accounts on these devices (as example might +privileged accounts on these devices (an example might be the ``enable'' password, used to enter privileged mode on a router or switch) need to be managed and shared with the same care that a {\tt root} password @@ -885,7 +885,7 @@ \section{Summary} users in your organization {\em today}, you will eventually grow to a size where this no longer holds. It is near impossible to later on put in place restrictions - on users' privileges, just as it is to anticiapate the + on users' privileges, just as it is to anticipate the possibly sudden departure of trusted employees. \item {\em You will always face tradeoffs.} No matter which authentication mechanism you choose, there are downsides. diff --git a/07/configuration-management.tex b/07/configuration-management.tex index e794c1e..9d30d0c 100644 --- a/07/configuration-management.tex +++ b/07/configuration-management.tex @@ -248,7 +248,7 @@ \section{Services, not Single Points of Failure} \section{Defining Services and Requirements} \label{configuration-management:defining-services} -System administrators tend to be very practially +System administrators tend to be very practically oriented and are likely to start out setting up a new service by installing the required software to evaluate, tune it, change it, adapt it to the needs of @@ -845,7 +845,7 @@ \subsubsection*{Unknown} The CM may have stopped Much more challenging for both the CM as well as the system administrators in charge are the prevention and -detection a the last two states, ``deviant'' and +detection of the last two states, ``deviant'' and ``unknown''. In order to recover and return the system back to production, the software needs to be able to identify error conditions and determine the @@ -1087,7 +1087,7 @@ \subsection{Deployment roles} shipped to the customers. In the context of configuration management, this might be a service definition that has to be verified to not -inadvertendly break the systems on which is should be +inadvertently break the systems on which is should be deployed, including new releases of the service software. @@ -1126,7 +1126,7 @@ \subsubsection*{Development} These hosts serve as the playground where all prototypes are initially set up as proofs of concept before being properly packaged and turned into a -defined services. All new changes are initially +defined service. All new changes are initially developed and tested in this environment. Hosts in this role are often in a state of flux, and it is not uncommon for a system administrator to break a service @@ -1150,7 +1150,7 @@ \subsubsection*{Test} configuration management software, and does not cause any obvious problems. -In a heterogenous environment it is import to ensure that all major +In a heterogenous environment it is important to ensure that all major operating system versions are represented in this group. \subsubsection*{Pre-Production} @@ -1423,7 +1423,7 @@ \subsection{Idempotence and Convergence} interruptions on the way from state A to state B. Both principles are often fully understood and appreciated only after a lot of practical experience -and a perhaps a few ``interesting'' error scenarios, +and perhaps a few ``interesting'' error scenarios, but try to keep them in mind as you develop and deploy your CM solution. diff --git a/09/scalable-tools.tex b/09/scalable-tools.tex index 50489b4..ae2baa2 100644 --- a/09/scalable-tools.tex +++ b/09/scalable-tools.tex @@ -256,7 +256,7 @@ \subsection{Programs} initial prototype and rewrite the tool, possibly in another language. Even though it is difficult to willingly discard an existing solution into which time -and effort have gone, this is, after all, the the main +and effort have gone, this is, after all, the main purpose of a {\em prototype}: to allow you to learn the details of the problem and to provide a proof of concept implementation on which to model your later @@ -305,7 +305,7 @@ \subsection{Programs} across numerous systems. Without realizing, we may have developed a core infrastructure component upon which our organization relies. At this point, the -software is likely to have advanced to into the stage +software is likely to have advanced to the stage of being a full-featured, self-contained application, requiring ongoing maintenance, development and support. We have crossed the boundary from @@ -372,7 +372,7 @@ \subsection{Software Products} approximately 75\% of ongoing maintenance and bug fixes!\footnote{System Administrators tend to agree that installation and operational maintenance of the -product make up the remaining 75\%.} +product make up the remaining 25\%.} But even though system administrators may well play an important role in the design of internal @@ -432,7 +432,7 @@ \subsection{Software Products} \section{Principles of Developing Robust System Tools} \label{building-scalable-tools:principles} -A large number of of System Administrators remain -- +A large number of System Administrators remain -- unconsciously and unintentionally -- stuck in ``scripting mode''. That is, their software reflects the mindset and language previously described, and the @@ -1223,7 +1223,7 @@ \subsection{Of Buses and Windows} of this, but often this is not sufficient to help somebody else really understand the code and debug it in case of an emergency. For that, you need to -atually explain your code to your peers, an approach +actually explain your code to your peers, an approach sometimes referred as ``decreasing your Bus Factor\index{Bus Factor}'': you should ensure that even if you were to suddenly disappear (because, for @@ -1273,7 +1273,7 @@ \subsection{Of Buses and Windows} -- the debate over whether one should use tabs or spaces to indent has been ongoing for decades now, with no resolution in sight\footnote{Tabs, of course.} --- but it in the interest of improving the readability +-- but in the interest of improving the readability of your code and making it easier for everyone in the organization to easily understand each others programs, it is important to follow them all the @@ -1305,7 +1305,7 @@ \subsection{Code Reviews} before code can be committed in a repository, it requires somebody else to sign off. So-called ``commit hooks'' in a code repository can enforce this -by requiring the commit messages to include the works +by requiring the commit messages to include the words ``reviewed by: username''. In order to allow reasonably efficient and agile development, this system requires occasional exceptions, and so we do @@ -1366,7 +1366,7 @@ \section{Additional Guidelines} the availability and usefulness of accompanying documentation. The following short guidelines may help you conciously consider your own development -approach and your own tools in copmarison: \\ +approach and your own tools in comparison: \\ {\bf Write meaningful commit messages.}\index{commit messages} As you collaborate on a project with your @@ -1635,7 +1635,7 @@ \section*{Problems} \item Review your own interpretation of what makes a ``good'' program. Do you judge a program by how it -performs alone? Do you consider a consisten user +performs alone? Do you consider a consistent user interface, availability of documentation, code readability or elegance, etc.? If the tool works and does what you need it to do -- should you pay