chapter 4: numerous tweaks, rewordings and font changes

Just minor cleanup and clarification in all of Chapter 4.

Signed-off-by: Robert P. J. Day <[email protected]>

Author: rpjday

book/04-git-server/sections/generating-ssh-key.asc

@@ -18,7 +18,7 @@ config            id_dsa.pub
 ----
 
 You're looking for a pair of files named something like `id_dsa` or `id_rsa` and a matching file with a `.pub` extension.
-The `.pub` file is your public key, and the other file is your private key.
+The `.pub` file is your public key, and the other file is the corresponding private key.
 If you don't have these files (or you don't even have a `.ssh` directory), you can create them by running a program called `ssh-keygen`, which is provided with the SSH package on Linux/Mac systems and comes with Git for Windows:
 
 [source,console]

book/04-git-server/sections/git-daemon.asc

@@ -52,8 +52,8 @@ Also, check that the Git binary is indeed located at `/usr/bin/git` and change t
 
 Finally, you'll run `systemctl enable git-daemon` to automatically start the service on boot, and can start and stop the service with, respectively, `systemctl start git-daemon` and `systemctl stop git-daemon`.
 
-Until LTS 14.04, Ubuntu used upstart service unit configuration.
-Therefore, on Ubuntu <= 14.04 you can use an Upstart script.
+Up to and including LTS 14.04, Ubuntu used upstart service unit configuration.
+Therefore, on Ubuntu 14.04 or earlier, you can use an Upstart script.
 So, in the following file
 
 [source,console]

book/04-git-server/sections/git-on-a-server.asc

@@ -90,9 +90,9 @@ We assume that if you have a server with which to do this, you already have an S
 
 There are a few ways you can give access to everyone on your team.
 The first is to set up accounts for everybody, which is straightforward but can be cumbersome.
-You may not want to run `adduser` and set temporary passwords for every user.
+You may not want to run `adduser` (or the possible alternative `useradd`) and have to set temporary passwords for every new user.
 
-A second method is to create a single 'git' user account on the machine, ask every user who is to have write access to send you an SSH public key, and add that key to the `~/.ssh/authorized_keys` file of that new account.
+A second method is to create a single 'git' user account on the machine, ask every user who is to have write access to send you an SSH public key, and add that key to the `~/.ssh/authorized_keys` file of that new 'git' account.
 At that point, everyone will be able to access that machine via the 'git' account.
 This doesn't affect the commit data in any way -- the SSH user you connect as doesn't affect the commits you've recorded.
 

book/04-git-server/sections/protocols.asc

@@ -180,9 +180,9 @@ If you want to allow anonymous read-only access to your projects and also want t
 ==== The Git Protocol
 
 (((protocols, git)))
-Next is the Git protocol.
+Finally, we have the Git protocol.
 This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication.
-In order for a repository to be served over the Git protocol, you must create a `git-daemon-export-ok` file -- the daemon won't serve a repository without that file in it -- but other than that there is no security.
+In order for a repository to be served over the Git protocol, you must create a `git-daemon-export-ok` file -- the daemon won't serve a repository without that file in it -- but, other than that, there is no security.
 Either the Git repository is available for everyone to clone, or it isn't.
 This means that there is generally no pushing over this protocol.
 You can enable push access but, given the lack of authentication, anyone on the internet who finds your project's URL could push to that project.
@@ -200,6 +200,6 @@ The downside of the Git protocol is the lack of authentication.
 It's generally undesirable for the Git protocol to be the only access to your project.
 Generally, you'll pair it with SSH or HTTPS access for the few developers who have push (write) access and have everyone else use `git://` for read-only access.
 It's also probably the most difficult protocol to set up.
-It must run its own daemon, which requires `xinetd` configuration or the like, which isn't always a walk in the park.
+It must run its own daemon, which requires `xinetd` or `systemd` configuration or the like, which isn't always a walk in the park.
 It also requires firewall access to port 9418, which isn't a standard port that corporate firewalls always allow.
 Behind big corporate firewalls, this obscure port is commonly blocked.

book/04-git-server/sections/setting-up-server.asc

@@ -10,7 +10,7 @@ We also assume you're running a standard Linux distribution like Ubuntu.
 A good deal of what is described here can be automated by using the `ssh-copy-id` command, rather than manually copying and installing public keys.
 ====
 
-First, you create a `git` user and a `.ssh` directory for that user.
+First, you create a `git` user account and a `.ssh` directory for that user.
 
 [source,console]
 ----
@@ -86,12 +86,12 @@ $ git push origin master
 With this method, you can quickly get a read/write Git server up and running for a handful of developers.
 
 You should note that currently all these users can also log into the server and get a shell as the `git` user.
-If you want to restrict that, you will have to change the shell to something else in the `passwd` file.
+If you want to restrict that, you will have to change the shell to something else in the `/etc/passwd` file.
 
-You can easily restrict the `git` user to only doing Git activities with a limited shell tool called `git-shell` that comes with Git.
-If you set this as your `git` user's login shell, then the `git` user can't have normal shell access to your server.
-To use this, specify `git-shell` instead of bash or csh for your user's login shell.
-To do so, you must first add `git-shell` to `/etc/shells` if it's not already there:
+You can easily restrict the `git` user account to only Git-related activities with a limited shell tool called `git-shell` that comes with Git.
+If you set this as the `git` user account's login shell, then that  account can't have normal shell access to your server.
+To use this, specify `git-shell` instead of bash or csh for that account's login shell.
+To do so, you must first add the full pathname of the `git-shell` command to `/etc/shells` if it's not already there:
 
 [source,console]
 ----

ch04-git-on-the-server.asc

@@ -9,7 +9,7 @@ Furthermore, you want your collaborators to be able to access the repository eve
 Therefore, the preferred method for collaborating with someone is to set up an intermediate repository that you both have access to, and push to and pull from that.
 
 Running a Git server is fairly straightforward.
-First, you choose which protocols you want your server to communicate with.
+First, you choose which protocols you want your server to support.
 The first section of this chapter will cover the available protocols and the pros and cons of each.
 The next sections will explain some typical setups using those protocols and how to get your server running with them.
 Last, we'll go over a few hosted options, if you don't mind hosting your code on someone else's server and don't want to go through the hassle of setting up and maintaining your own server.