Linux can serve files to any computer, and most never know it's Linux!
Much like a Taster's Choice commercial from the 1980s, Linux advocates often need to be sneaky in order demonstrate the virtue of open-source software. It seems that fear, uncertainty and doubt (FUD) tend to make people dismiss Linux before it ever gets a chance to prove its worth. The easiest way to infiltrate an organization with Linux is to attack the server room.
Although hordes of penguins armed with machine guns sounds like a blockbuster way to attack a server room, in reality, the best way to get Linux in the door is by using it to replace a few services previously served by proprietary operating systems. The simplest service to replace is usually the Web server. File serving, although a bit more complex, also is effective. When an entity is growing past its licensing, free file services really begin to look attractive.
NFS often gets a bad rap for being insecure. That's really only because it's so insecure! Seriously though, even though NFSv4 has added user authentication, to use NFS in the traditional way, it's important to realize its shortcomings. Many folks (myself included) still use NFS, but it's easy to expose your servers to unneeded threat if you don't understand how it works.
On the server side, you can specify the IP address of the clients allowed to connect. Unfortunately, it's not uncommon to see someone use wild cards to allow any and all computers to connect. That's a bad idea, because NFS (v2 and v3) restricts file access using only standard user permissions. If I connect to an NFS server with my laptop and my UID is 501, I'll have access to the files owned by UID 501 on the server—without authentication. There are options to restrict the root user, but that doesn't really restrict anyone. If I want to access files owned by UID 6224, all I have to do is create a user with that UID, and I have access. Squashing root access on the server is no security at all, just an annoyance to potential hackers.
Because restricting the client IP addresses that are allowed to connect limits the clients to trusted computers, it would seem that NFS is secure as long as the server is configured correctly. Sadly, that's not really true either. As there is no way to verify what computer is using a particular IP, an attacker simply can shut off an allowed client machine, assign the IP address of that client and connect to the NFS server quite happily. For that reason, I restrict my NFS usage to server-to-server sharing on servers in secured locations. Even then, it's important to think through any potential point of entry.
The reason I bring up NFS sharing is because it's perfect for LTSP. Because servers in the server room are secure and physically adjacent, NFS is a simple way to share the /home directory between your LTSP servers. Configuring NFS is simple. Make sure the NFS server packages and its dependencies are installed on your server, and the NFS client packages are installed on your clients. (In this case, by “client” I mean the server acting as an NFS client to the file server. Sorry if that sounds confusing.)
On the server, edit your /etc/exports file. The following example has three separate shares. See if you can spot the “bad” one:
/home 192.168.1.35(rw) /iso 192.168.1.*(ro) /home 192.168.1.*(ro)
To activate the shares you've created in your /etc/exports file, either reboot the server, or type /usr/sbin/exportfs -a to reload the configuration.
In the above example, the first line allows the client with the IP address of 192.168.1.35 to have full read/write access to the /home directory on the server. This is about as secure as you can make NFS on the server. You also can specify hosts with DNS entries, but then you risk compromise by DNS spoofing.
The second line shares the /iso directory in read-only mode to anyone on the 192.168.1.0/24 network. The wild card here means what you'd expect, and anyone in that range can connect. Making this read-only does protect the content of the folder from being molested, but it doesn't stop anyone from reading and copying the contents. In this case, that's the desired result.
The third line looks to be safe, because it's shared only in read-only mode. As any client on the network can connect, however, that means every folder in the /home directory, so that means usually all your users have their personal files exposed! Granted, no one can change the files because they are read-only, but with that single line, you've effectively given free access to everyone's files—definitely not a good idea.
On the client computer, NFS shares are mounted just like any other partition or filesystem. To make a mount permanent and automatic, simply edit /etc/fstab and add a line like:
#<server:/share> <mountpoint> <filesys_type> <options> <dump> <pass> 192.168.1.5:/home /home auto defaults 0 0
To mount the share, either reboot the client machine or run mount -a as root. It's important to note that like any filesystem mounting, the /home directory must be empty in order to mount the NFS share in that location.
The above example tells the client to try connecting to the server 192.168.1.5 (it also can be a DNS name). Once connected, it tries to mount the /home share on the local /home directory. The filesystem type is set to auto, and the options in this case are set to defaults. The last two zeros are the dump and pass options. The options along with dump and pass settings are tweakable, but beyond the scope of this article.
When NFS is used in a closely controlled server-to-server scenario like this, it makes sharing home directories very convenient. Once you realize the shortcomings of the “security” NFS offers, it is possible to include it in very specific scenarios in your infrastructure.
Samba is one of those programs that can wash your car, feed the dog, fly a space shuttle and also serve files. It can act as a Primary Domain Controller (not an Active Directory server yet, unfortunately), along with sharing printers and files. For the purposes of this article, let's take a cursory look at file serving—specifically, sharing the /home directory for your users. By installing Samba on the same file server you installed NFS, those same files can be shared to Windows clients. Oh, and Samba does support user authentication for security!
Configuring Samba could easily turn into a five-part series, but if your goal is simply to serve files in your /home directory, I recommend starting with the default configuration. If you're running a Debian variant, I recommend installing the libpam-smbpass package along with the samba server packages. It is a neat little package that keeps the separate UNIX and Samba passwords in sync. It's certainly possible to configure other authentication schemes, but in its simplest form, keeping user names and passwords in sync with the underlying system is ideal.
If you open the /etc/smb.conf file, you'll see some settings in the [global] section that can be tweaked to best fit your network. Namely, you can set the NETBIOS name and a few other tweakable configurations to better define your server. Even those changes, however, are not required. Simply scrolling down and uncommenting the following three lines will get you a functional Samba server:
[homes] comment = Home Directories browseable = no
After changing those lines, you should be able to go to a Windows machine and browse your server as if it were a Microsoft server (Figure 1). As I mentioned earlier, Samba is a vastly powerful system. Sharing your /home directories to users is barely scratching the surface. Still, even with this little bit of setup, it's quite useful.
Figure 1. As far as Windows is concerned, it's connected to another Windows machine.
With modern OS X machines, connecting to Samba shares is simple. In fact, OS X does its own magic to preserve the resource fork of its files by adding a ._filename file to Samba shares. If you're not familiar with Apple's data fork and resource fork file structure, don't worry. The only frustrating part is all those dot-underscore files everywhere!
If you prefer your file sharing to be native, there's an app for that. As it's not only Windows servers that you may hope to replace with Linux, it's nice to have an Apple native file server even if OS X can connect to Samba. Netatalk is the server program that provides file and print services for Apple products. Apple actually uses LDAP for its Open Directory server, but the configuration is proprietary and uses closed-source management tools. So for the short term, the only thing you can do seamlessly is share files and printers.
The package that comes with most Debian variants comes preconfigured for serving home directories. A simple apt-get install netatalk will install and configure the server without any other effort required on your part. Users then can connect to your server as if it were an Apple-branded file server and never know the difference. For production use, you likely will want to edit the configuration files to set the name of your server, but it really does usually work right out of the box. OS X users often claim their system “just works”, and you can claim the same about your open-source server program for their platform!
You've probably noticed that my solution for Linux clients appears to be the most limited. Rest assured, if you're running Linux on a client that isn't appropriate for NFS, you can connect via Samba without any problems. It might be possible to connect to a Netatalk server from Linux, but I've never seen a reason to try. If you don't want to use Samba, there are other less-common ways to connect.
LTSP thin clients mount a user's home directory using this method. Years ago, if the thin client had to access the /home folder, it was mounted via NFS. For reasons I outlined above, it's clear that isn't a really good idea. As its name suggests, SSHFS mounts a remote filesystem over SSH. This makes mounting very flexible, but it's important to keep in mind that shares mounted over a slow WAN connection often are difficult to use, especially on a regular basis.
In order to use SSHFS in a Debian- or Ubuntu-based system, you need to install the sshfs package. Just like NFS, the folder on which you choose to mount needs to be empty or the mounting process will fail. (Note: the Ubuntu Web site claims users must be in the “fuse” group in order to use sshfs filesystems, but I have not found that to be the case.) To mount a remote filesystem:
sshfs user@remote.system.com:/remote/folder /home/user/local_folder
Once authenticated, the folder /home/user/local_folder (or whatever folder you chose) will be mounted remotely to /remote/folder on the server. Access speed is dependent on network speed, but the files should work the same as any other mounted filesystem. It's really cool!
In order to unmount, use the fusermount command:
fusermount -u /home/user/local_folder
It is possible to add sshfs filesystems to the /etc/fstab file in much the same way that you add an NFS share. Because sshfs uses FUSE, a userspace file-mounting system, it's generally used for individual users as opposed to system mounts. As with most things Linux, this is flexible.
FTP isn't really ideal for file transfers, mainly because it transfers user names and passwords in plain text. Linux still supports FTP file servers, and most systems come with FTP logins jailed in a chroot environment for each user. Although this protocol is insecure, unfortunately, you need to use it sometimes for programs that support only traditional FTP. If I have to set up an FTP server, I prefer vsftp, but I won't go through the setup process here because FTP is just not a great protocol to use.
The “proper” thing to do is use SFTP, which for Linux users is as simple as having an SSH server installed. SFTP is handled by the OpenSSH dæmon on Linux servers, and setting it up on most servers is as simple as doing nothing. If there are security concerns about exposing your server to the Internet, it is possible to configure SSH for chroot jails per user as well. Thankfully, with SSH everything is encrypted, so sniffing the network isn't a concern. Unfortunately, no amount of securing can protect your system from compromised passwords, so make sure your users don't have a habit of using passwords like 1234 for your system.
The server room is by far the easiest place to replace expensive proprietary operating systems with Linux. In fact, the days of sneaking Linux into the server room are largely behind us. Most bosses, even the technologically illiterate ones, expect Linux to be in the server room. They might not know what Linux does, but they know they should have it! If your institution is outgrowing its licensing, or if you'd just like to replace “proprietary” with “open”, file servers are a great place to start. If done carefully, your users will never know. Be sure to mention to your boss how much you've saved in licensing and support, because upper management always likes to brag about how much the department has saved!