Setting up a File and Print Server under Crunchbang Linux

On the client

1. I need to install a different NFS software package to support networking functions. Typing sudo apt-get install nfs-common in a terminal does that.
2. I'm going to edit the /etc/hosts file on the client to give a pseudo-name to the server, just as I did on the server to give a pseudo-name for the client. So, sudo cp /etc/hosts /etc/hosts.old in a terminal to make a backup, then gksudo pluma /etc/hosts to open up the file. Once again, I'm just going to add the line 192.168.0.3 patrick-laptop to the end of the file.
3. Once again, I'm going to make sure that I can use the name patrick-laptop from the client. So ping -c 1 patrick-laptop in a terminal should result in similar success messages as it did on the server.
4. Since I used to mount the drives accessed over the network directly on the client, I already have folders created where they used to be mounted (in my case, at /media/Externa and /media/Backup). But if I didn't have them already created, I could do this in a terminal:

   sudo mkdir /media/Externa sudo mkdir /media/Backup

5. Now I want to make sure (finally!) that I can actually mount the remote drives on the local filesystem. Here's how I'm checking this in a terminal:

   sudo mount -t nfs patrick-laptop:/media/Backup /media/Backup sudo mount -t nfs patrick-laptop:/media/Externa /media/Externa

   Note that I'm mounting the network shares in the same place on the client as they're physically located on the server. This isn't actually necessary, but it's convenient, because I don't have to remember a set of mappings later on.

6. Once that's successful, I want to check that I am, in fact, able to browse the server's shares from the client. Basically, I just want to make sure that the files are visible and readable from the paths at which I expect them to be, i.e. that the files I expect to see in the locations /media/Backup and /media/Externa — that is, the files on the external hard drives that I'm sharing — are actually there. There are a number of ways to do this; maybe the simplest way would be to point my file browser (I use PCManFM) at both of those locations and see whether the files are actually there.

   Alternately, I could do this in a terminal, checking to see that the output of the ls command lists the files that I expect to be there:

   cd /media/Backup ls -la cd /media/Externa ls -la

7. Great! Everything's working so far! But I don't want to have to mount the network shares manually every time I reboot, so I'm going to modify the /etc/fstab file on the client so that it mounts them automatically on every boot (well ... to be more specific, every time mount -a is called; booting is one of those times). As always, I make a backup of the config file I'm about to modify (sudo cp /etc/fstab /etc/fstab.old in a terminal) in case I screw it up, then gksudo pluma /etc/fstab to open up the file.

   Here's my /etc/fstab file after I've modified it. (You'll note that I have several other Linux distributions installed, though I basically only ever run Crunchbang.) Once again, I've bolded the lines I've added.

   # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/sda7 during installation UUID=159f51c0-dc13-4f62-83bc-d9f9938cb3fe / ext4 errors=remount-ro 0 1 # /home was on /dev/sda3 during installation UUID=c4bdfaa0-d2b0-4c06-8d29-474e9cf7bf19 /home ext4 defaults 0 2 # swap was on /dev/sda2 during installation UUID=c7aa48cc-e372-4775-bcdf-d7941b4a180e none swap sw 0 0 # Mint was on /dev/sda1 during installation UUID=190e74c2-444e-4159-b2fd-2d7330c7af83 /mnt/mint ext4 defaults 0 2 # Bodhi was on /dev/sda6 during intallation UUID=c8064cf8-e633-4fe2-90aa-ffbdda30c23f /mnt/bodhi ext4 defaults 0 2 # tmp was on /dev/sda5 during installation UUID=22f11a68-bfc2-4196-8b0f-c2601a0296d1 /tmp ext4 defaults 0 2 /dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0 #network shares from the little computer used as a file server patrick-laptop:/media/Externa /media/Externa nfs defaults,nofail,_netdev 0 0 patrick-laptop:/media/Backups /media/Backup nfs defaults,nofail,_netdev 0 0

   The manpage for fstab (here, or man fstab in a terminal) has examples of using the /etc/fstab file to automatically mount network drives, and you should look at it if you need more information. Still, some general notes on the added lines:

   • The file system field in the file should be the name of the server, a colon, a single slash, and then the full path to the file from the server's perspective.
   • The next field is the location on the client where the network share will be mounted. After that comes the filesystem type: nfs for the Network File System, of course.
   • The default mount options are the next field. nofail means "don't hold up booting if the network share's not available," which it won't be if I take the client elsewhere (as I frequently do). _netdev means "don't try to mount the drives until a network interface is available," which it won't be until later in the boot process than the boot process's invocation of mount -a.
   • I use zero for both the dump and pass fields of the entries, because these control how often and in what order the mount command will run filesystem checks on the shares. But I don't want the client trying to run filesystem checks on the shares; it doesn't have access to them at the block-device level, anyway, so there's no point. If maintenance needs to be done on those drives, the server should be doing it, not the client. Setting these values to zero prevents the client from trying to run checks on mount.

   Once I've saved and closed the file, I want to check that everything's working, so I do this in a terminal:

   sudo umount /media/Backup sudo umount /media/Externa sudo mount -a

   The first two lines unmount the network shares from the client. The third line should mount them again. To check this, I'll do the same thing I did in the previous step and, as always, if it doesn't work, I'll go back and check the work that I did.

So the real test as to whether it works or not is whether the files are usefully accessible. My litmus test here involves two things. The first is: can I play movies that are part of the server's network share on the client? (It turns out that I can, without any noticeable lag). The second test is: can I run my nightly backup script? After all, if the network share is mounted in the same place as the external drive that correspond's to the network share's previous location, then the backup script should work as-is. I keep my backup script in ~/.scripts/, so typing ~/.scripts/home-backup.sh (or, since I've added that directory to my $PATH, just home-backup.sh) should work. And it does: I ran my backup script manually, and the backup happened almost as normal.

Almost is a key word here: the backup happens much slower than normal. This is to be expected, I guess: transferring files across the network to a drive that's connected to another computer is slower than transferring them directly to a drive that's attached to the computer running the script. Normally, it takes several minutes to run my backup script; running it across the network took more than an hour and a half. Most of that time was spent transferring a single 3.2 GB file, which is used to store my archived emails in Thunderbird (yes, I am, in fact, an information packrat). The simple fact is that this is just too slow.

However, there's an easy way to speed it up. My backup script (which, after all, is short and simple) uses rsync to do the real work. rsync works perfectly fine as a way of syncing and copying files on the local filesystem, but it really shines as a way of copying files across a network connection. The problem that I'm currently having is that rsync isn't taking advantake of these capabilities right now, because the way that I'm invoking it treats the network shares as if they were local folders. After all, that's what NFS does: it makes network shares available as if they were local folders. So rsync doesn't even realize that it's copying files over a network connection, and therefore isn't employing any of the network-copying optimizations.

So I need to invoke rsync from my script in a way that gets it to employ network-transfer optimizations. More specifically, I want it transfer only the parts of files that have changed: after all, though the file containing my Thunderbird archive changes every time I move messages into it, these are small changes to a very large file. Why transfer the whole thing again? Only the changes really need to be transferred (and then re-applied to the existing file on the other end). Transferring only the changed bits of the file means that a lot of the file won't need to be transferred. This is the idea behind rsync so-called delta-transfer algorithm.

For this to work, rsync needs to be installed and running on both machines, and each rsync computes checksums for individual chunks of files that have changed, then transfers the chunks with different checksums and applies the differences to the file in the backup. But how do I get the rsync running on the network client, my primary laptop, to communicate with an rsync running on the file server? There are two ways: having rsync running in daemon mode on the file server, or using SSH to start up an rsync on the file server when I need it. It turns out the second one is easier to set up and meets my needs perfectly.

You can read more about rsync on its manpage (here, or man rsync in a terminal).

On the client

1. Again, sudo aptitude install openssh openssh-server will make sure everything is installed that's necessary.
2. Next I want to make sure that I can log into the remote system with SSH:

   patrick@linicious:~$ ssh patrick-laptop

   should prompt me for my password (on the remote machine, i.e. the server), then log me into the remote machine. You'll notice that the bash prompt that Crunchbang sets up by default will change to reflect the fact that I'm now in a terminal that's connected to a different computer:

   patrick@linicious:~$ ssh patrick-laptop Last login: Thu Jul 24 03:53:28 2014 from liniscious -bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) -bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) -bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) patrick@patrick-laptop:~$

   There are a few miscellaneous errors, but they don't seem to cause me any trouble.

   I'm going to poke around on the remote machine and verify to my own satisfaction that I'm actually logged into it:

   patrick@patrick-laptop:~$ cd ~ patrick@patrick-laptop:~$ ls -la total 328 drwxr-xr-x 35 patrick patrick 4096 Jul 16 10:58 . drwxr-xr-x 3 root root 4096 Dec 14 2012 .. drwx------ 2 patrick patrick 4096 Jul 16 10:58 .TrueCrypt -rw------- 1 patrick patrick 59 Jul 9 02:41 .Xauthority -rw-r--r-- 1 patrick patrick 1723 Jul 3 08:03 .Xresources drwx------ 2 patrick patrick 4096 Jul 7 23:55 .aptitude -rw------- 1 patrick patrick 4473 Jul 24 04:06 .bash_history -rw-r--r-- 1 patrick patrick 220 Jul 3 08:03 .bash_logout -rw-r--r-- 1 patrick patrick 3392 Jul 3 08:03 .bashrc drwxr-xr-x 4 patrick patrick 4096 Jul 10 13:22 .bluefish drwxr-xr-x 11 patrick patrick 4096 Jul 10 13:21 .cache drwxr-xr-x 30 patrick patrick 4096 Jul 10 13:21 .config -rw-r--r-- 1 patrick patrick 1814 Jul 3 08:03 .conkyrc drwx------ 3 patrick patrick 4096 Jul 3 14:38 .dbus drwxr-xr-x 2 patrick patrick 4096 Jul 3 14:38 .fontconfig drwxr-xr-x 2 patrick patrick 4096 Jul 3 08:03 .fonts lrwxrwxrwx 1 patrick patrick 43 Jul 4 19:48 .fonts.conf -> /home/patrick/.config/fontconfig/fonts.conf drwx------ 3 patrick patrick 4096 Jul 9 02:41 .gconf -rw-r----- 1 patrick patrick 0 Jul 10 22:51 .gksu.lock -rw-r--r-- 1 patrick patrick 107 Jul 16 10:56 .gmrun_history -rw-r--r-- 1 patrick patrick 404 Jul 3 08:03 .gmrunrc drwx------ 4 patrick patrick 4096 Jul 3 14:38 .gnome2 drwx------ 2 patrick patrick 4096 Jul 3 14:38 .gnome2_private drwx------ 2 patrick patrick 4096 Jul 6 04:53 .gphoto drwxr-xr-x 2 patrick patrick 4096 Jul 9 02:41 .gstreamer-0.10 -rw------- 1 patrick patrick 278 Jul 12 21:57 .gtk-bookmarks -rw-r--r-- 1 patrick patrick 557 Jul 3 08:03 .gtkrc-2.0 -rw-r--r-- 1 patrick patrick 1 Jul 3 08:03 .gtkrc-2.0.mine drwx------ 2 patrick patrick 4096 Jul 3 14:38 .gvfs drwxr-xr-x 2 patrick patrick 4096 Jul 3 08:03 .icons drwx------ 3 patrick patrick 4096 Jul 7 23:54 .kde drwxr-xr-x 3 patrick patrick 4096 Jul 3 08:03 .local drwx------ 4 patrick patrick 4096 Jul 7 11:22 .mozilla -rw-r--r-- 1 patrick patrick 98 Jul 3 08:03 .pbuilderrc -rw-r--r-- 1 patrick patrick 808 Jul 3 08:03 .profile drwx------ 2 patrick patrick 4096 Jul 3 14:38 .pulse -rw------- 1 patrick patrick 256 Jul 3 14:38 .pulse-cookie drwxr-xr-x 2 patrick patrick 4096 Jul 10 23:30 .ssh drwxr-xr-x 2 patrick patrick 4096 Jul 3 08:03 .themes drwx------ 4 patrick patrick 4096 Jul 7 11:03 .thumbnails drwxr-xr-x 2 patrick patrick 4096 Jul 3 08:03 .xchat2 -rw-r--r-- 1 patrick patrick 7470 Jul 3 08:03 .xscreensaver -rw------- 1 patrick patrick 115196 Jul 16 10:58 .xsession-errors drwxr-xr-x 2 patrick patrick 4096 Jul 11 00:15 Desktop drwxr-xr-x 2 patrick patrick 4096 Jul 3 08:03 backup drwxr-xr-x 2 patrick patrick 4096 Jul 3 08:03 bin drwxr-xr-x 2 patrick patrick 4096 Jul 3 08:03 documents drwxr-xr-x 2 patrick patrick 4096 Jul 3 08:03 downloads drwxr-xr-x 3 patrick patrick 4096 Jul 3 08:03 images drwxr-xr-x 2 patrick patrick 4096 Jul 3 08:03 music drwxr-xr-x 2 patrick patrick 4096 Jul 3 08:03 templates drwxr-xr-x 2 patrick patrick 4096 Jul 3 08:03 tmp drwxr-xr-x 2 patrick patrick 4096 Jul 3 08:03 videos

   If I were on my primary computer, there would be many many more files and directories in my home directory. Note that I really can do just about anything on the remote computer through the SSH connection that I could do in a terminal on the machine itself:

   patrick@patrick-laptop:~$ sudo aptitude update; sudo aptitude upgrade [sudo] password for patrick: Get: 1 http://security.debian.org jessie/updates InRelease [73.5 kB] Get: 2 http://http.us.debian.org jessie InRelease [155 kB] Ign http://packages.crunchbang.org waldorf InRelease Get: 3 http://security.debian.org wheezy/updates InRelease [103 kB] [etc.] Fetched 831 kB in 1min 34s (8825 B/s) Current status: 7 updates [+7], 356 new [+1]. The following packages will be upgraded: libnet-ssleay-perl libperl5.18 libsnmp-base libsnmp30 perl perl-base perl-modules 7 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 11.0 MB of archives. After unpacking 455 kB will be freed. Do you want to continue? [Y/n/?]

   It turns out that updating the system remotely via SSH in this way is slower than walking over to the server and typing the same command, but I can do it if I want to.

   When I'm done poking around, logout or exit will end my remote connection:

   patrick@patrick-laptop:~$ exit logout Connection to patrick-laptop closed. patrick@linicious:~$

   Note again that the hostname — the section after the at-sign in my bash prompt — changes to reflect the fact that I'm not connected to the remote machine any more.

3. Being able to log into the remote machine manually is helpful — I can do roughly everything through the terminal that I could do on a terminal if I were sitting in front of the server — but I don't want to have to type in my password every time I connect, since I want to be able to connect from a script, after all.

   The solution here is to set up OpenSSH so that I can connect with a keypair: that is, I need to generate a keypair, keep the private key on the client (my primary laptop) and putting the public key in a known location on the file server. This is pretty easy to do.

   patrick@linicious:~$ ssh-keygen

   This will ask me for some information; every tie I'm asked for something, I'm just going to hit Enter to accept the default value. In particular, I'm not going to add a password to the key, because my backup script can't supply it. The whole point of setting open key-based authentication here is to avoid being prompted for a password.

   The output should look something like this:

   Generating public/private rsa key pair. Enter file in which to save the key (/home/patrick/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /tmp/id_rsa. Your public key has been saved in /tmp/id_rsa.pub. The key fingerprint is: e2:1b:58:b7:d9:ab:eb:a9:91:ea:c9:d5:ee:a8:51:1a patrick@linicious The key's randomart image is: +--[ RSA 2048]----+ | | | | | | | | | E + S | | B = + | | + * + . | | . = * . . | | .*.++Bo. | +-----------------+

4. Now I've got a public/private keypair, I need to put the public key on the file server, in a place where I can find it easily. I'm just going to put it in the home directory for now:

   scp ~/.ssh/id_rsa.pub patrick@patrick-laptop:~/

   puts it there. Then I'm going to connect to the remote machine again:

   patrick@linicious:~$ ssh patrick-laptop

   I'm now in the file server's home directory in my terminal. This is where I left the public key I generated on the client. Now what I need to do is add the public key I generated to the list of keys that the server's SSH trusts:

   patrick@patrick-laptop:~$ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys

   Note that I'm appending the key to the end of the list (<<) rather than overwriting it.

   Since I no longer need the copy of the key I dumped into the home folder on the file server, I can remove it:

   patrick@patrick-laptop:~$ rm ~/id_rsa.pub

5. Now I need to modify the server's SSH configuration options, which involves editing a text file. I could do this by walking over to the server and opening up the relevant file for editing, which would have the advantake of letting me use a graphical text editor, but I'm lazy and don't mind text editing in a console application. Besides, I'm already logged in to the file server from my primary laptop.

   However, if I'd rather use a graphical text editor like pluma, I could walk over to the server and, instead of doing what I'm about to describe in the next paragraph, make a backup with sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.old and then open up the sshd_config file with gksudo pluma /etc/ssh/sshd_config &.

   First, sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.old to make a backup of the existing configuration in case I screw it up, then sudo nano /etc/ssh/sshd_config to open it up in a console editor (nano is plenty easy to use for a simple task).

   I want to find and modify two lines in the file to let me log in with my RSA-based keypair. They may not be found together, but each line should look like this:

   • RSAAuthentication yes
   • PubkeyAuthentication yes

   And then I'm going to turn off the automatic request for a password on login:

   • ChallengeResponseAuthentication no
   • PasswordAuthentication no
   • UsePAM no

   Once again, those lines will probably not be found all together in the sshd_config file, so I'll have to hunt for each one separately.

6. Now I need to reload the SSH config file on the server:

   sudo /etc/init.d/ssh reload

   If it doesn't work, make sure that the server software is installed (sudo aptitude install openssh-server). If it still doesn't work, log out from your connection to the file server from the client (logout), walk over to the server and reboot it.